Bug#1031335: lintian: Please backport 2.116.3 to bullseye

[Baptiste Beauplat]

Package: lintian
Severity: wishlist

Dear maintainer,



At mentors.debian.net, we use the bpo version of lintian to run on
uploaded packages. But this 2.115.1 version report the latest
standards-version as unknown.


Could we please have a bpo build for 2.116.3?


Thanks,
-- 
Baptiste Beauplat - lyknode

Bug#1031334: intel-microcode: CVE-2022-21216 CVE-2022-33972 CVE-2022-33196 CVE-2022-38090

[Salvatore Bonaccorso]

Source: intel-microcode
Version: 3.20221108.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.20220510.1~deb11u1
Control: found -1 3.20220510.1~deb10u1

Hi,

The following vulnerabilities were published for intel-microcode.

CVE-2022-21216[0]:
- INTEL-SA-00700

CVE-2022-33972[1]:
- INTEL-SA-00730

CVE-2022-33196[2]:
- INTEL-SA-00738

CVE-2022-38090[3]:
- INTEL-SA-00767

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

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00700.html
[1] https://security-tracker.debian.org/tracker/CVE-2022-33972
https://www.cve.org/CVERecord?id=CVE-2022-33972

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00730.html
[2] https://security-tracker.debian.org/tracker/CVE-2022-33196
https://www.cve.org/CVERecord?id=CVE-2022-33196

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00738.html
[3] https://security-tracker.debian.org/tracker/CVE-2022-38090
https://www.cve.org/CVERecord?id=CVE-2022-38090

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00767.html
[4] 
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20230214

Regards,
Salvatore

Bug#1031332: transition: librnd

[Sebastian Ramacher]

Control: tags -1 moreinfo trixie

On 2023-02-14 22:54:12 -0700, Bdale Garbee wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: lib...@packages.debian.org
> Control: affects -1 + src:librnd
> 
> This is a fairly trivial transition due to upstream rolling to a new ABI 
> version.  I originally uploaded this straight to unstabe, but Thorsten asked 
> me to follow the "via experimental" process.

We asked the FTP masters to accept new binaries only via experimental as
we are in soft freeze for the bookworm release and transition freeze was
already in January.

> Because I didn't previously know about this process, all application packages 
> that depend on this new library version (all of which come from the same 
> upstream) have already been uploaded and accepted into unstable with build
> dependencies on the binary packages delivered by source package librnd.

Let's do this transition early in the trixie release circle.

Cheers

> 
> Bdale
> 
> 
> Ben file:
> 
> title = "librnd";
> is_affected = .depends ~ /librnd3/ | .depends ~ /librnd4/;
> is_good = .depends ~ /librnd4/;
> is_bad = .depends ~ /librnd3/;
> 

-- 
Sebastian Ramacher

Bug#1030455: schedule: FTBFS: AssertionError: ScheduleValueError not raised by until

[Étienne Mollier]

Control: tags -1 confirmed

Good Morning,

Étienne Mollier, on 2023-02-14:
> However, looking at the nature of the test, and the hour at
> which it ran (build log starts at 03:05:50 +), I'm under the
> impression that the build time test failure could occur every
> day in a window between 0:00 and 5:00 am local hour.  I
> scheduled an sbuild attempt `at 3am`, we may see the result
> tomorrow and whether the bug is confirmed or unreproducible.

So, the test ran at 02:00 + and failed with same symptom.
My guess is upstream never intended to run the test out of
office hours.  It might be worth skipping the test as flaky, or
patching it to reduce the ftbfs time window to, say, 00:00 to
00:01 local hour.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/tty1, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1021041: ITP: parallel-hashmap --

[Andrius Merkys]

Hi Steffen,

On Fri, 30 Sep 2022 23:50:47 +0200 Steffen Moeller  
wrote:

Subject: ITP: parallel-hashmap -- 
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist


I found your ITP and initial packaging for parallel-hashmap. I need this 
library to package pytorch-sparse (#1031265). Is it OK if I finalise and 
upload it, or do you prefer to do so yourself?


Best wishes,
Andrius

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Hilmar Preuße]

Am 15.02.2023 um 00:22 teilte Hilmar Preuße mit:

Hi Harald,


I'm building new packages, which do not depend on fonts-ebgaramond: the
fonts in there are not part of TL any more, so the dep is obsolete. I'll
hand them over for testing ASAP.


Here is the link: https://freeshell.de/~hille42/TL_2023-2/

It should be sufficient to replace package texlive-fonts-extra-links by
a new package.

1. You should be able to remove package fonts-ebgaramond after the
update. Please do so.

2. After removal you'll have two broken symlinks:

/usr/share/texlive/texmf-dist/fonts/opentype/public/ebgaramond/EBGaramond12-Italic.otf
/usr/share/texlive/texmf-dist/fonts/opentype/public/ebgaramond/EBGaramond12-Regular.otf

Please remove them manually, I'll remove them in final release of -2.

3. Run "mktexlsr" as user root.

4. Then try again to convert the document and report if that solves the
issue. Provide log files in any case.

Thanks!

Hilmar
--
sigfault

Bug#1031333: golang-docker-credential-helpers: Please demote gnome-keyring to Recommends

[Arto Jantunen]

Package: golang-docker-credential-helpers
Version: 0.6.4+ds1-1+b4
Severity: wishlist
Tags: patch

Dear Maintainer,

The golang-docker-credential-helpers binary package contains two entirely
separate credential helpers.

docker-credential-pass requires the pass tool to work, and
docker-credential-secretservice requires gnome-keyring (or perhaps it could
work with any other package providing the same dbus interface such as
kwalletd, but I haven't checked that).

Users of docker-credential-pass thus have no need to install
gnome-keyring (which fights with the mentioned kwalletd that is required
and running by default for KDE users).

See here for an MR implementing the change: 
https://salsa.debian.org/go-team/packages/golang-github-docker-docker-credential-helpers/-/merge_requests/3

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages golang-docker-credential-helpers depends on:
ii  gnome-keyring  42.1-1+b1
ii  libc6  2.36-8
ii  libglib2.0-0   2.74.5-1
ii  libsecret-1-0  0.20.5-3

golang-docker-credential-helpers recommends no packages.

Versions of packages golang-docker-credential-helpers suggests:
ii  pass  1.7.4-6

Bug#1031188: linux: synaptics speed/sensitivity messed up with 6.1.0-4

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi Christoph,

On Sun, Feb 12, 2023 at 11:28:52PM +0100, Christoph Anton Mitterer wrote:
> Source: linux
> Version: 6.1.11-1
> Severity: normal
> 
> 
> Hey.
> 
> Over the year this has unfortunately happened numerous times, either by 
> changes
> in the Xorg driver, or libinput... and now it seems the kernel caused the
> same:
> 
> After upgrading from linux-image-6.1.0-3-amd64 to linux-image-6.1.0-4-amd64 
> and
> after a reboot, the speed and senstivity of the touchpad were quite messed up.
> 
> Sounds like no issue, but is actually extremely annoying as one typically gets
> quite strongly used to those... and it seem I cannot even restore the previous
> behaviour by the usual switches.
> 
> No other packages (that have remotely to do with X, libinput or so) were 
> upgraded
> so I think it must be something in the kernel.
> OTOH, looking thorough the changelog from .9 to .11 there seems to be nothing
> where they write it would change the settings (though there were in fact some
> libinput/synaptics related commits).
> 
> Any ideas how the previous behaviour can be gotten back?

Just to be sure, that I understood you correctly. That is if on the
current system with the issue you roll back just only the kernel back
to 6.1.8-1, then the issue dissaper? 

If this is the case, would you be testing as well directly 6.1.8 and
6.1.11 upstream (please do as well 6.1.12, 6.1.12-1 though just
uploaded to unstable earlier today), and if reproducible, bisect the
changes between the two versions to find the introducing bad commit?

Regards,
Salvatore

Bug#1031332: transition: librnd

[Bdale Garbee]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lib...@packages.debian.org
Control: affects -1 + src:librnd

This is a fairly trivial transition due to upstream rolling to a new ABI 
version.  I originally uploaded this straight to unstabe, but Thorsten asked 
me to follow the "via experimental" process.

Because I didn't previously know about this process, all application packages 
that depend on this new library version (all of which come from the same 
upstream) have already been uploaded and accepted into unstable with build
dependencies on the binary packages delivered by source package librnd.

Bdale


Ben file:

title = "librnd";
is_affected = .depends ~ /librnd3/ | .depends ~ /librnd4/;
is_good = .depends ~ /librnd4/;
is_bad = .depends ~ /librnd3/;

Bug#1027435: Broke my hold vim* packages

[王昊然]

This 'fix' unnecessarily broke the dependency of my VIM 7.4 packages, which
aren't affected by this bug.

Bug#1031331: ITP: libtemplate-plugin-htmltotext-perl -- plugin interface to HTML::FormatText

[mtj]

Package: wnpp
Owner: Mason James 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libtemplate-plugin-htmltotext-perl
  Version : 0.03
  Upstream Author : Fayland Lam 
* URL : https://metacpan.org/release/Template-Plugin-HtmlToText
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : plugin interface to HTML::FormatText

Template::Plugin::HtmlToText provides an interface to the HTML::FormatText
module which formats HTML as plaintext.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#1031329: [EXTERNAL] Bug#1031329: unixodbc-dev: /usr/include/sqltypes.h refers to unixodbc.h, which is no longer included!

[Shipper, Michael]

Huh,

So it looks like this is a problem with the Microsoft Debian package, not with 
the package provided by Debian.

Please disregard my previous email.

-Original Message-
From: Michael Shipper  
Sent: Tuesday, February 14, 2023 7:07 PM
To: Debian Bug Tracking System 
Subject: [EXTERNAL] Bug#1031329: unixodbc-dev: /usr/include/sqltypes.h refers 
to unixodbc.h, which is no longer included!

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.

Package: unixodbc-dev
Version: 2.3.11
Severity: important
X-Debbugs-Cc: michael.ship...@charter.com

Dear Maintainer,

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

   * What led up to the situation?
   I maintain a custom perl build at the cuompany I work for and when
 I tried to build DBD::ODBC, the build process stopped working 
as of
 the latest update.
 It looks like unixodbc.h was removed from the pakcage?
 make
"/opt/apps/charter-perl/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- 
ODBC.bs blib/arch/auto/DBD/ODBC/ODBC.bs 644
gcc -c -I/usr/include  -I. 
-I/opt/apps/charter-perl/lib/site_perl/5.34.0/x86_64-linux-multi/auto/DBI 
-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/build/repos/charter-perl_1.0-47_amd64.build/charter-perl-5.34.0=.
 -fstack-protector-strong -Wformat -Werror=format-security   -DVERSION=\"1.61\" 
-DXS_VERSION=\"1.61\" -fPIC 
"-I/opt/apps/charter-perl/lib/5.34.0/x86_64-linux-multi/CORE"  -I/usr/include 
ODBC.c
In file included from /usr/include/sql.h:19,
 from dbdodbc.h:6,
 from ODBC.h:8,
 from ODBC.xs:1:
/usr/include/sqltypes.h:56:10: fatal error: unixodbc.h: No such file or 
directory
   56 | #include "unixodbc.h"
  |  ^~~~
compilation terminated.
make: *** [Makefile:394: ODBC.o] Error 1

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 used apt-file to find unixodbc.h.. there is no such file right
 now??
   * What was the outcome of this action?
file not found
   * What outcome did you expect instead?
   I expected this header to be included in unixodbc-dev

Please let me know if I should be installing a different package.
This was working a few weeks ago, but it seems the header files have changed.
*** End of the template - remove these template lines ***


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

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

Versions of packages unixodbc-dev depends on:
ii  libltdl-dev [libltdl3-dev]  2.4.6-15
ii  odbcinst1debian22.3.11
ii  unixodbc2.3.11

unixodbc-dev recommends no packages.

unixodbc-dev suggests no packages.

-- no debconf information

Bug#1031329: Please disregard this bug report

[Shipper, Michael]

So,

It looks like the bug is in the Microsoft odbc package not the Debian odbc 
package.
Please close this ticket.

I apologize for any inconvenience.
E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Bug#1030298: pyopencl: FTBFS on i386: = 1 failed, 304 passed, 7 skipped, 1 deselected, 2 xfailed, 31 warnings in 736.25s (0:12:16) =

[Andreas Beckmann]

Followup-For: Bug #1030298

minimized reproducer (needs only python3-pyopencl):

=
import math
import numpy as np

import pyopencl.array as cl_array
import pyopencl as cl
import pyopencl.clmath as clmath

context = cl.Context()
queue = cl.CommandQueue(context)

for s in [10]:
a = cl_array.arange(queue, s, dtype=np.float32)/10
a2 = cl_array.arange(queue, s, dtype=np.float32)/45.2 + 0.1
b = clmath.fmod(a, a2)

a = a.get()
a2 = a2.get()
b = b.get()

for i in range(s):
f=math.fmod(a[i], a2[i])
d=b[i] - f # should be zero
print("i=", i, " a[i]=", a[i], " a2[i]=", a2[i], " b[i]=clmath.fmod(a, 
a2)[i]=", b[i],
  " fmod(a[i], a2[i])=", f, " diff=", d);
#assert math.fmod(a[i], a2[i]) == b[i]
=

output on testing/i386:
# python3 test_1030298.py
i= 0  a[i]= 0.0  a2[i]= 0.1  b[i]=clmath.fmod(a, a2)[i]= 0.0  fmod(a[i], 
a2[i])= 0.0  diff= 0.0
i= 1  a[i]= 0.1  a2[i]= 0.1221239  b[i]=clmath.fmod(a, a2)[i]= 0.1  fmod(a[i], 
a2[i])= 0.1000149011612  diff= 0.0
i= 2  a[i]= 0.2  a2[i]= 0.14424779  b[i]=clmath.fmod(a, a2)[i]= 0.055752218  
fmod(a[i], a2[i])= 0.0557522177696228  diff= 0.0
i= 3  a[i]= 0.3  a2[i]= 0.16637167  b[i]=clmath.fmod(a, a2)[i]= 0.13362834  
fmod(a[i], a2[i])= 0.13362833857536316  diff= 0.0
i= 4  a[i]= 0.4  a2[i]= 0.18849558  b[i]=clmath.fmod(a, a2)[i]= 0.023008853  
fmod(a[i], a2[i])= 0.02300885319709778  diff= 0.0
i= 5  a[i]= 0.5  a2[i]= 0.21061948  b[i]=clmath.fmod(a, a2)[i]= 0.07876104  
fmod(a[i], a2[i])= 0.0787610411643982  diff= 0.0
i= 6  a[i]= 0.6  a2[i]= 0.23274335  b[i]=clmath.fmod(a, a2)[i]= 0.13451332  
fmod(a[i], a2[i])= 0.13451331853866577  diff= 0.0
i= 7  a[i]= 0.7  a2[i]= 0.25486726  b[i]=clmath.fmod(a, a2)[i]= 0.19026548  
fmod(a[i], a2[i])= 0.1902654767036438  diff= 0.0
i= 8  a[i]= 0.8  a2[i]= 0.27699116  b[i]=clmath.fmod(a, a2)[i]= 0.2460177  
fmod(a[i], a2[i])= 0.2460176944732666  diff= 0.0
i= 9  a[i]= 0.9  a2[i]= 0.29911503  b[i]=clmath.fmod(a, a2)[i]= 0.0026548803  
fmod(a[i], a2[i])= 0.0026548802852630615  diff= 0.0

output on sid/i386:
# python3 test_1030298.py
i= 0  a[i]= 0.0  a2[i]= 0.1  b[i]=clmath.fmod(a, a2)[i]= 0.0  fmod(a[i], 
a2[i])= 0.0  diff= 0.0
i= 1  a[i]= 0.1  a2[i]= 0.1221239  b[i]=clmath.fmod(a, a2)[i]= 0.1  fmod(a[i], 
a2[i])= 0.1000149011612  diff= 0.0
i= 2  a[i]= 0.2  a2[i]= 0.14424779  b[i]=clmath.fmod(a, a2)[i]= 0.055752218  
fmod(a[i], a2[i])= 0.0557522177696228  diff= 0.0
i= 3  a[i]= 0.3  a2[i]= 0.16637167  b[i]=clmath.fmod(a, a2)[i]= 0.13362834  
fmod(a[i], a2[i])= 0.13362833857536316  diff= 0.0
i= 4  a[i]= 0.4  a2[i]= 0.18849558  b[i]=clmath.fmod(a, a2)[i]= 0.023008853  
fmod(a[i], a2[i])= 0.02300885319709778  diff= 0.0
i= 5  a[i]= 0.5  a2[i]= 0.21061948  b[i]=clmath.fmod(a, a2)[i]= 0.07876104  
fmod(a[i], a2[i])= 0.0787610411643982  diff= 0.0
i= 6  a[i]= 0.6  a2[i]= 0.23274335  b[i]=clmath.fmod(a, a2)[i]= 0.13451329  
fmod(a[i], a2[i])= 0.13451331853866577  diff= -2.9802322387695312e-08
i= 7  a[i]= 0.7  a2[i]= 0.25486726  b[i]=clmath.fmod(a, a2)[i]= 0.19026548  
fmod(a[i], a2[i])= 0.1902654767036438  diff= 0.0
i= 8  a[i]= 0.8  a2[i]= 0.27699116  b[i]=clmath.fmod(a, a2)[i]= 0.24601772  
fmod(a[i], a2[i])= 0.2460176944732666  diff= 2.9802322387695312e-08
i= 9  a[i]= 0.9  a2[i]= 0.29911503  b[i]=clmath.fmod(a, a2)[i]= 0.0026548505  
fmod(a[i], a2[i])= 0.0026548802852630615  diff= -2.9802322387695312e-08

output on sid/amd64:
# python3 test_1030298.py
i= 0  a[i]= 0.0  a2[i]= 0.1  b[i]=clmath.fmod(a, a2)[i]= 0.0  fmod(a[i], 
a2[i])= 0.0  diff= 0.0
i= 1  a[i]= 0.1  a2[i]= 0.1221239  b[i]=clmath.fmod(a, a2)[i]= 0.1  fmod(a[i], 
a2[i])= 0.1000149011612  diff= 0.0
i= 2  a[i]= 0.2  a2[i]= 0.14424779  b[i]=clmath.fmod(a, a2)[i]= 0.055752218  
fmod(a[i], a2[i])= 0.0557522177696228  diff= 0.0
i= 3  a[i]= 0.3  a2[i]= 0.16637167  b[i]=clmath.fmod(a, a2)[i]= 0.13362834  
fmod(a[i], a2[i])= 0.13362833857536316  diff= 0.0
i= 4  a[i]= 0.4  a2[i]= 0.18849558  b[i]=clmath.fmod(a, a2)[i]= 0.023008853  
fmod(a[i], a2[i])= 0.02300885319709778  diff= 0.0
i= 5  a[i]= 0.5  a2[i]= 0.21061948  b[i]=clmath.fmod(a, a2)[i]= 0.07876104  
fmod(a[i], a2[i])= 0.0787610411643982  diff= 0.0
i= 6  a[i]= 0.6  a2[i]= 0.23274335  b[i]=clmath.fmod(a, a2)[i]= 0.13451332  
fmod(a[i], a2[i])= 0.13451331853866577  diff= 0.0
i= 7  a[i]= 0.7  a2[i]= 0.25486726  b[i]=clmath.fmod(a, a2)[i]= 0.19026548  
fmod(a[i], a2[i])= 0.1902654767036438  diff= 0.0
i= 8  a[i]= 0.8  a2[i]= 0.27699116  b[i]=clmath.fmod(a, a2)[i]= 0.2460177  
fmod(a[i], a2[i])= 0.2460176944732666  diff= 0.0
i= 9  a[i]= 0.9  a2[i]= 0.29911503  b[i]=clmath.fmod(a, a2)[i]= 0.0026548803  
fmod(a[i], a2[i])= 0.0026548802852630615  diff= 0.0

Andreas

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Theodore Ts'o]

There is more about this in the referenced bugs, but I dispute
Daniel's characterization of the issue.

I will draw the analogy of building a program which links against
glibc for Bookworm resulting in a binary that will not run on Buster.
We expect that, and we tell people to use build chroots.  This is not
something which is actionable, and we don't hold back glibc updates
just because you can no longer build on Debian 10.0 something that
won't work on Debian 9.0, or 8.0.

The same is true for file system featuers.  We add new features to
improve the user experience.  This is true for all file systems: ext4,
xfs, btrfs.  For example, in Bookworm, the version of xfsprogs is
going to enable the incompat "bigtime" feature for the first time.
This fixes XFS's 2038 problem.  A file system has the bigtime feature
enabled won't boot on Grub versions older than 2.06.  That is just the
way of the world.

As it truns out, for e2fsprogs, users (or distributions) can very
easily change the default file system features by editing the
configuration file /etc/mke2fs.conf.  So if a user wants to ask mke2fs
to disable certain features by default, and "dumb down" the
capabilities of the file system, they can to do that --- on the
command line, by tuning the file system after the fact, or by editing
the /etc/mke2fs.conf file.  They can even set the MKE2FS_CONFIG
environment variable to point at their own custom config file if they
would like.

We can change the default for mke2fs.conf file for Debian.  I don't
think it's warranted, and I'm not aware of any other distribution
doing this.  The fact that file system featuers that fix certain
problems (such as the 2038 bug) will cause older versions the
distribution to fail to accept that file system is always going to be
the case.  So how long do we hold back some new feature?  A year?  Two
years?  Five years?  Ten years?  Again, we don't do this with shared
library linkages; we just tell people to use a build chroot.

I would gently suggest that the most general solution to this problem
is to do the same for building VM images, if people won't want to be
bothered to learn how to configure the mfks program.  After all,
according to popcon, there are 960 times as many people who have use
gcc-10 recently (7685) as vmdb2 (8).

So if we are to hold e2fsprogs and xfsprogs to the standard that a
file system created by default must work on all older Debian and
Ubuntu distributions to some arbitrary point in history, should we
1000 times as much hold gcc-10 and clang to the same standard?

Obviously, that is a ridiculous thing to do.

Best regards,

- Ted

Bug#1031329: unixodbc-dev: /usr/include/sqltypes.h refers to unixodbc.h, which is no longer included!

[Michael Shipper]

Package: unixodbc-dev
Version: 2.3.11
Severity: important
X-Debbugs-Cc: michael.ship...@charter.com

Dear Maintainer,

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

   * What led up to the situation?
   I maintain a custom perl build at the cuompany I work for and when
 I tried to build DBD::ODBC, the build process stopped working 
as of
 the latest update.
 It looks like unixodbc.h was removed from the pakcage?
 make
"/opt/apps/charter-perl/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- 
ODBC.bs blib/arch/auto/DBD/ODBC/ODBC.bs 644
gcc -c -I/usr/include  -I. 
-I/opt/apps/charter-perl/lib/site_perl/5.34.0/x86_64-linux-multi/auto/DBI 
-fwrapv -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector-strong 
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 
-D_FORTIFY_SOURCE=2 -g -O2 
-ffile-prefix-map=/build/repos/charter-perl_1.0-47_amd64.build/charter-perl-5.34.0=.
 -fstack-protector-strong -Wformat -Werror=format-security   -DVERSION=\"1.61\" 
-DXS_VERSION=\"1.61\" -fPIC 
"-I/opt/apps/charter-perl/lib/5.34.0/x86_64-linux-multi/CORE"  -I/usr/include 
ODBC.c
In file included from /usr/include/sql.h:19,
 from dbdodbc.h:6,
 from ODBC.h:8,
 from ODBC.xs:1:
/usr/include/sqltypes.h:56:10: fatal error: unixodbc.h: No such file or 
directory
   56 | #include "unixodbc.h"
  |  ^~~~
compilation terminated.
make: *** [Makefile:394: ODBC.o] Error 1

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 used apt-file to find unixodbc.h.. there is no such file right
 now??
   * What was the outcome of this action?
file not found
   * What outcome did you expect instead?
   I expected this header to be included in unixodbc-dev

Please let me know if I should be installing a different package.
This was working a few weeks ago, but it seems the header files have
changed.
*** End of the template - remove these template lines ***


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

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

Versions of packages unixodbc-dev depends on:
ii  libltdl-dev [libltdl3-dev]  2.4.6-15
ii  odbcinst1debian22.3.11
ii  unixodbc2.3.11

unixodbc-dev recommends no packages.

unixodbc-dev suggests no packages.

-- no debconf information

Bug#1025350: qt6ct: changing font has no effect on GNOME

[Christopher Cramer]

On 2/11/23 1:58 PM, Peter B wrote:

"Just tested font changing for qt6ct itself and qtcreator, and fonts 
are changing just fine,

    so I can't reproduce this problem.

    However, I'm using Xfce, so maybe this is a Gnome issue?
    Fonts do take a little while to change though.

    Is qt5ct working for you?"



Maybe it is a Gnome issue. I don't know how or if Gnome intereacts with 
Qt. Anyway, I selected the same fonts in qt6ct that I use for Gnome.


qt5ct does not work either.



"One further thought.

    I assume you are using TrueType fonts.
    Which specific font(s) are you having the issue with?

    I'm using liberation fonts here.  {fonts-liberation2}"



I have it set to Cantarell 18 (in fonts-cantarell) and Cousine 18 
(fonts-croscore).

Bug#1031328: crowdsec: symlink-target-in-build-tree for some test files

[Cyril Brulebois]

Package: crowdsec
Version: 1.4.2-1
Severity: normal

Hi,

This was spotted during the final stages of 1.4.2-* preparations but it
seemed not important enough to delay an upload:

E: golang-github-crowdsecurity-crowdsec-dev: symlink-target-in-build-tree 
/build/crowdsec-1.4.2/_build/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/hubdir/collections/crowdsecurity/test_collection.yaml
 
[usr/share/gocode/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/install/collections/test_collection.yaml]
E: golang-github-crowdsecurity-crowdsec-dev: symlink-target-in-build-tree 
/build/crowdsec-1.4.2/_build/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/hubdir/scenarios/crowdsecurity/barfoo_scenario.yaml
 
[usr/share/gocode/src/github.com/crowdsecurity/crowdsec/pkg/cwhub/install/scenarios/barfoo_scenario.yaml]

Those are test files, and they don't trigger a test suite failure
within an autopkgtest test bed, that's why I proceeded with an upload
without a fix.

That being said, that means the build is not reproducible, and it'd be
far better to have that addressed once we have 1.4.2 into testing.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1023391: texlive-full: The EB Garamond font is not installed properly within debian texlive-full

[Hilmar Preuße]

Am 14.02.2023 um 13:41 teilte Hilmar Preuße mit:

Am 14.02.2023 um 13:29 teilte Jele, Harald mit:


Hi Harald,


removing the fonts-ebgaramond seems not to be a good idea:
apt remove fonts-ebgaramond
would remove almost the whole texlive installation because of it's
dependencies.


Could you nevertheless try that step, just to prove that is is the
faulty package? Thanks!


I'm building new packages, which do not depend on fonts-ebgaramond: the
fonts in there are not part of TL any more, so the dep is obsolete. I'll
hand them over for testing ASAP.

Hilmar
--
sigfault

Bug#1031327: gbp-rpm-ch: Wrong changelog header format (missing dash before version)

[Samuel Henrique]

Package: git-buildpackage
X-Debbugs-Cc: samuel...@debian.org
Version: 0.9.30
Severity: normal
Tags: patch

As stated in the title, the changelog header has the wrong format.

Specfile documentation:
https://rpm-packaging-guide.github.io/#working-with-spec-files
...
 Follow this format for the first line:

 * Day-of-Week Month Day Year Name Surname  - Version-Release
...

I have provided a patch on Github at
https://github.com/agx/git-buildpackage/pull/89

The patch is also attached to this bug report.

Thank you,

-- 
Samuel Henrique 
From 310db2177f3a43e1584682f21c43ac0de6c495e6 Mon Sep 17 00:00:00 2001
From: Samuel Henrique 
Date: Mon, 1 Aug 2022 18:49:19 +0100
Subject: [PATCH] Fix RPM changelog header format (missing dash before version)

 As stated in the documentation at:
 https://rpm-packaging-guide.github.io/#working-with-spec-files

 "...
 Follow this format for the first line:

 * Day-of-Week Month Day Year Name Surname  - Version-Release
 ..."
---
 gbp/rpm/policy.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gbp/rpm/policy.py b/gbp/rpm/policy.py
index a2155e20..59989bb8 100644
--- a/gbp/rpm/policy.py
+++ b/gbp/rpm/policy.py
@@ -85,7 +85,7 @@ class Changelog(object):
 body_name_re = r'\[(?P.*)\]'
 
 # Changelog header format (when writing out changelog)
-header_format = "* %(time)s %(name)s <%(email)s> %(revision)s"
+header_format = "* %(time)s %(name)s <%(email)s> - %(revision)s"
 header_time_format = "%a %b %d %Y"
 header_rev_format = "%(version)s"
 

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Daniel Leidert]

Am Dienstag, dem 14.02.2023 um 16:53 -0500 schrieb Theodore Ts'o:

[snip]

Your arrogant and ignorant attitude is frustrating, to say the least.
You don't care about the mess you create, for a feature, that probably
only a handful of people will ever need (I did a quick search and
didn't find anything regarding this feature - so why turn it on by
default then?). But yet you have to make it the default and break
running toolchains and methods. Talking to you is pointless. You cost
me hours of useless work yesterday and today because you ignore the
rules we have set out as a project to not frustrate each other.

I have reported this to the release team now.

Daniel

Bug#990206: crowdsec: Program (and doc prompts to) access internal dpkg database

[Cyril Brulebois]

Control: found -1 1.4.2-1

Cyril Brulebois  (2021-06-23):
> I'm in touch with upstream, and various things should get improved in
> their next major release regarding “configuration management” in a broad
> sense (including the way assets are handled). The initial packaging was
> an opportunity to discover a number of constraints/needs that weren't
> necessarily clear or expressed in the first place (a shell wizard did
> the job for source-based deployment).
> 
> We tried to get something in shape before the bullseye freeze, and it
> seemed we could speed things up a little by (ab)using the postinst in
> this way; we expect to perform some heavy clean-up during the bookworm
> release cycle, replacing a lot of (if not all of) Debian-specific code
> with upstream things that are being developed, partly based on the
> feedback gathered during initial packaging.

This didn't happen in the 1.4.x series, and last I heard about it (a few
weeks back), the plan was for 1.5.x to start featuring some assistant;
but that's definitely post-bookworm.

There were too many things to handle already, I haven't even tried to
rework the internal dpkg database part…


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1031326: crowdsec: delays during upgrade from 1.0.9-*

[Cyril Brulebois]

Package: crowdsec
Version: 1.4.2-1
Severity: important

Hi,

Seen during upgrade tests, starting at 1.0.9-*: there's an important
delay (~ 1 minute) during the upgrade, with no apparent activity.
According to crowdsec.log, we're waiting for the existing process to
shut down following the SIGTERM:

time="14-02-2023 22:27:53" level=info msg="Crowdsec engine shutting down"

I'll ask upstream to comment on this. Gut feeling would be: it might be
acceptable to be a little more aggressive, tweaking the postinst script
to include some sort of timeout, and killing the existing process after
say 10 seconds (if terminating didn't return by then). Of course, if a
clean shutdown is preferable (internal data that need to be stored,
etc.), maybe it'll be better to actually dig into why the old version is
taking so long to shut down. But a fix would likely involve pushing an
update to stable, which would be more work for everyone…


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Daniel Leidert]

Package: release.debian.org
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

A week ago, Theodore Ts'o uploaded e2fsprogs 1.47.0 into Debian unstable. This
version contains a unannounced change that basically breaks grub2 (and
grub-install). This issue has been reported as #1030939 [1] and #1030846 [2].
To "fix" the issue, instead of turning the feature off, a patch to grub2 in Sid
has been committed recently. Unfortunately, that only fixes grub in Sid. Grub
in Bullseye or any current Ubuntu release *cannot* deal with a filesystem
created by this version of e2fsprogs. This basically breaks the debootstrap
method of installing a Debian or Ubuntu. If e2fsprogs 1.47.0 is allowed into
Testing, we can no longer use the debootstrap method to install a Debian
Bullseye (or older) or any Ubuntu release. It requires to manually change the
filesystem features before it can be used again. It also makes e.g. vmdb2 in
Sid unusable to create images of Bullseye or older Debian releases, or Ubuntu
releases.

The gain of enabling the metadata_csum_seed feature by default is not
noteworthy. It is a feature that hardly anybody needs. I have not seen one
use-case nor even relevant search hits. But the loss is heavy. User's can no
longer simply follow [3] to install any Debian or Ubuntu system if the
filesystem has been created with e2fsprogs 1.47.0. It also breaks software in
the midst of the freeze.

I hereby ask the release team to step in and either make sure that the
metadata_csum_seed feature is not turned on by default in e2fsprogs in Bookworm
or that version 1.47.0 is not shipped as part of Bookworm.

Reasons:

- - this breaks existing tools for no apparant reason

- - introducing this breaking change is too late in the release cycle to deal
  with it properly

- - the metadata_csum_seed feature is hardly useful or requested; it can be
  turned on if necessary; no need to make it the default in Bookworm

- - there is no grub upstream release with support for it; only patched grub
  versions can cope with it

- - the change makes it impossible to create filesystems with this version of
  e2fsprogs and then run a grub-install from a target system that does not cope
  with that feature; basically breaking the debootstrap method of installing
  Debian or Ubuntu onto a server (violating #4 of the Debian social contract)

- - to cope with the former issues, users will have to know about that
  incompatibility and ways to deal with it; none of that is prepared; the
  package maintainer even refuses a NEWS entry

- - it breaks vmdb2, only allowing to make images of Debian Bookworm and Sid (if
  grub is involved)

- - pushing this metadata_csum_seed feature violates #4 of the Debian social
  contract

Instead, turning on this feature should be postponed for the next release cycle
where a proper transition can be done.

[1] https://bugs.debian.org/1030939
[2] https://bugs.debian.org/1030846
[3] https://www.debian.org/releases/stable/amd64/apds03

Daniel Leidert

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmPsE8UACgkQS80FZ8KW
0F0Aug/+Kb6xrQcILq+VYpKk/161UXgQA47ccydz78uT3r1eRBVJIPReULZPdjvk
W4PDDOYypScsx4+EahdOVViAMiOyzI0eroivZmDItxY1HR6LpKdeQFPLET6FdbfM
pDHezFKXqsulYQWLu5M6yPCtMWGCmAtiH9NeppzUY7+dnBr2yzZGitH4pPSh7MmS
9jxRIKG0xGa3wF+a1yEgHE0nPvqD5a97GlwL5+MTg580k/e1VRpaQaYrTRr3CHyK
EJbVOu70K+qXgP837x6B5eyYmihJWiNBMxm9JqF1TrwTKXwk26zpZ2+T1uKVgVKj
Y5AlZX8Gypdxq0Q3uFPSlzBhetd2wvrUt9hKEb52fdzw3L4AsY2Ken98sAhqy7Xi
PGVdihiUSAT5gslthm3qB3fGQQMIEXI3UdHqSx7ARgZJ6Gkf/zIjk5sKl/xiGe+t
jJExPdCR7H8+tPNZhJEhx6BLtLs8tLm+zhOAr3rZVekEn3PJJAHOKPs1KPBWinYr
FsVBsWBWzOgKNARu31u/o4s5BFV99M45gZqHLs3Mp5TvJqIxkbwS0FDoCa/TausP
vojuW4kDPM7Jjw568W4O8csXBiI/qEcEPXZGPrgGVs3Yo1hV/KkJUOkQ9y/VvRps
POx+RwF400ov8zOxGPqETkqDjl/2JQ47OOvogJMi6FDRQk+YE2w=
=bKh7
-END PGP SIGNATURE-

Bug#1031324: crowdsec: 404 on cscli hub update

[Cyril Brulebois]

Package: crowdsec
Version: 1.4.2-1
Severity: important

Hi,

The crowdsec binary package comes with a copy of hub files (“offline
hub”) so that it's immediately useful. It's also possible to switch
to using the “online hub” by running:

cscli hub update

With 1.4.2-1, an error is returned:

Failed to get Hub index : failed to download index: bad http code 404 while 
requesting https://hub-cdn.crowdsec.net/1.4.2/.index.json

I'll ask upstream to help debug this issue but since we have a copy
shipped in the package, this seems to be important at most.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1031323: crowdsec: Disable displaying messages about the outdated version

[Cyril Brulebois]

Package: crowdsec
Version: 1.4.2-1
Severity: normal

Hi,

Seen while testing 1.4.2 while 1.4.6 is available upstream:

Crowdsec is not the latest version. Current version is '1.4.2' and the 
latest stable version is 'v1.4.6'. Please update it!

We're in touch with upstream and they will support the release that ends
up in stable (security updates and important fixes). There's no need to
worry users with such warnings, so they should be disabled.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1031282: joe: Vcs points to upstream repo

[Bastian Germann]

I am uploading a NMU to DELAYED/10 to fix this. The debdiff is attached.diff -Nru joe-4.6/debian/changelog joe-4.6/debian/changelog
--- joe-4.6/debian/changelog2018-02-17 21:10:49.0 +0100
+++ joe-4.6/debian/changelog2023-02-14 23:52:07.0 +0100
@@ -1,3 +1,10 @@
+joe (4.6-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop Vcs fields, closes: #1031282.
+
+ -- Bastian Germann   Tue, 14 Feb 2023 23:52:07 +0100
+
 joe (4.6-1) unstable; urgency=low
 
   * New upstream version, closes: #887435.
diff -Nru joe-4.6/debian/control joe-4.6/debian/control
--- joe-4.6/debian/control  2017-01-25 22:40:23.0 +0100
+++ joe-4.6/debian/control  2023-02-14 23:50:43.0 +0100
@@ -5,8 +5,6 @@
 Build-Depends: libncurses-dev, dh-autoreconf
 Standards-Version: 3.9.6
 Homepage: http://joe-editor.sourceforge.net/
-Vcs-Browser: https://sourceforge.net/p/joe-editor/mercurial/ci/default/tree/
-Vcs-Hg: http://hg.code.sf.net/p/joe-editor/mercurial
 
 Package: joe
 Architecture: any

Bug#1031322: crowdsec: New upstream release available: 1.4.6

[Cyril Brulebois]

Package: crowdsec
Version: 1.4.2-1
Severity: normal

Hi,

A bunch of extra packages were needed to be able to upload 1.4.2, but
that's done now. It would be best to catch up with the latest release
from the 1.4.x upstream series (if feasible) before bookworm freezes
deeper.

At the moment, v1.4.6 is the greatest, and doesn't show any diff in its
go.mod compared to v1.4.2, which is encouraging.


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/

Bug#1031321: mruby: FTBFS on i386

[Adrian Bunk]

Source: mruby
Version: 3.1.0-1
Severity: important
Tags: patch

The patch below fixes the FTBFS on i386 (and perhaps also on m68k).

The change in 3.1.0-2 is not necessary.

--- debian/rules.old2023-02-14 22:24:06.359165557 +
+++ debian/rules2023-02-14 22:25:04.935110237 +
@@ -1,6 +1,10 @@
 #!/usr/bin/make -f
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU),i386 m68k))
+  export DEB_CFLAGS_MAINT_APPEND += -ffloat-store
+endif
+
 RAKE="rake --verbose"
 
 %:

Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x

[James Addison]

Source: qemu
Followup-For: Bug #1030545

> In the build logs for libguestfs, I see last successful builds were done
> on 5.10.0-20-s390x kernel, and on 5.10.0-21-s390x, all builds fails.
> 5.10.0-21-s390x is the one running on zelenka too.

Sorry for what I now worry may have been distractions in my previous comments.

There is at least one failed build where the cause seem unrelated to qemu-img:

https://buildd.debian.org/status/fetch.php?pkg=libguestfs=s390x=1%3A1.48.6-1%2Bb3=1675540466=1

That build (libguestfs 1:1.48.6-1+b3, kernel 5.10.0-21-s390x) passes qemu-img
steps, but later fails to find the 'getenforce' binary (from selinux-utils):

> SELinux: sh: 1: getenforce: not found

Could that mean there's a missing build-dep on selinux-utils? (and perhaps the
kernel version upgrade has introduced/exposed that?)

Bug#1031281: wsgicors: Vcs not available

[Bastian Germann]

I am uploading a NMU to DELAYED/10. The debdiff is attached.diff -Nru wsgicors-0.4.1/debian/changelog wsgicors-0.4.1/debian/changelog
--- wsgicors-0.4.1/debian/changelog 2019-10-06 20:25:37.0 +0200
+++ wsgicors-0.4.1/debian/changelog 2023-02-14 23:33:55.0 +0100
@@ -1,3 +1,11 @@
+wsgicors (0.4.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Move Homepage from PyPI to GitHub
+  * Drop Vcs fields (Closes: #1031281)
+
+ -- Bastian Germann   Tue, 14 Feb 2023 23:33:55 +0100
+
 wsgicors (0.4.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru wsgicors-0.4.1/debian/control wsgicors-0.4.1/debian/control
--- wsgicors-0.4.1/debian/control   2019-10-06 20:24:09.0 +0200
+++ wsgicors-0.4.1/debian/control   2023-02-14 23:33:44.0 +0100
@@ -2,9 +2,7 @@
 Section: python
 Priority: optional
 Maintainer: David Douard 
-Homepage: https://pypi.python.org/pypi/wsgicors
-Vcs-Hg: http://hg.logilab.org/master/debian/wsgicors
-Vcs-Browser: http://hg.logilab.org/master/debian/wsgicors
+Homepage: https://github.com/may-day/wsgicors
 Build-Depends:
   debhelper (>= 9),
   dh-python,

Bug#1031320: bugs.debian.org: Scanner Programs Are Slow To Find USB Scanner

[Roger]

Package: bugs.debian.org
Severity: normal
X-Debbugs-Cc: slow_sp...@att.net

Dear Maintainer,

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

   * What led up to the situation?  I turn on the multifunction printer with
scanner.  I start a scanner program. I wait upwards of 90 seconds for it to
find the scanner.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?  Tried different programs, and all have the same timeout
issue.
   * What was the outcome of this action?
   * What outcome did you expect instead?  Should immediately find the scanner
that is turned on and waiting.

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

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Soren Stoutner]

Which part do you not understand about not being needed on both Qt 5 and Qt 6?  
The part about building the .bdic files or the part about Qt WebEngine using 
the .bdic files at runtime?

On Tuesday, February 14, 2023 12:25:20 PM MST Lisandro Damián Nicanor Pérez 
Meyer wrote:
> One thing I do not understand is why is this needed on both Qt 5 and Qt 6?
> What I understand from the thread is that currently any of them can provide
> the dictionaries, so why not keeping this under just one source package?


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

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

Bug#1031319: partman-cros: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: partman-cros
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.

--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031318: firebuild: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: firebuild
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.


--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007401: renaissance: please consider upgrading to 3.0 source format

[Bastian Germann]

X-Debbugs-Cc: ya...@gnu.org

On Tue, 15 Mar 2022 08:51:59 +0100 Lucas Nussbaum  wrote:

This package is among the few (1.9%) that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.


I see that this was fixed with
https://salsa.debian.org/gnustep-team/renaissance/-/commit/65ee7c99e08710d1c60f032b1fb19e60866ea128

What is keeping this from being uploaded? If it is a sponsor, I can probably 
help.

Bug#1031317: depthcharge-tools-installer: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Paulo Henrique de Lima Santana]

Package: depthcharge-tools-installer
Tags: l10n patch
Severity: wishlist

Hello,

Could you please update this Brazilian Portuguese translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and
tested with msgfmt and podebconf-display-po.

Kind regards.


--
Paulo Henrique de Lima Santana (phls)
Belo Horizonte - Brasil
Debian Developer
Site: http://phls.com.br
GPG ID: 0443C450


pt_BR.po.gz
Description: application/gzip


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1007567: mpdcon.app: please consider upgrading to 3.0 source format

[Bastian Germann]

X-Debbugs-Cc: ya...@gnu.org

On Tue, 15 Mar 2022 08:52:01 +0100 Lucas Nussbaum  wrote:

This package is among the few (1.9%) that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging practices.


I see that this was fixed with
https://salsa.debian.org/gnustep-team/mpdcon.app/-/commit/5b38acf5071bf3c241ea43d12cbeb6053604978c

What is keeping this from being uploaded? If it is a sponsor, I can probably 
help.

Bug#1031316: depthcharge-tools-installer: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: depthcharge-tools-installer 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the Dutch translation of depthcharge-tools-
installer debconf messages. A draft has been posted to the debian-l10n-
dutch mailing list allowing for review. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#1031315: libjpeg9: libjpeg.so.9* missing

[Roy Clark (kralcyor)]

Package: libjpeg9
Version: 1:9d-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

/usr/lib/*/{libjpeg.so.9,libjpeg.so.9.4.0} are missing in the package, making 
it completely unusable:
$ dpkg -L libjpeg9 
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libjpeg9
/usr/share/doc/libjpeg9/README.gz
/usr/share/doc/libjpeg9/changelog.Debian.gz
/usr/share/doc/libjpeg9/changelog.gz
/usr/share/doc/libjpeg9/copyright

This issue may related to changes in the build system. While libjpeg.so.9* 
appear in the old version 1:9d-1, a rebuilt package of version 1:9d-1 on a 
latest unstable Debian system also lacks libjpeg.so.9*.

The following lines appeared in the latest build log on buildd[1]:
   checking whether the x86_64-linux-gnu-gcc linker (/usr/bin/ld -m elf_x86_64) 
supports shared libraries... ./configure: line 11202: : supported targets:.* 
elf: command not found
   no
which corresponds to the following lines in the regenerated `configure':
   if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
&& test no = "$tmp_diet"

It can be found from `config.status' that $EGREP is empty, which may cause this 
issue:
EGREP=''

I didn't figure out why $EGREP is empty, but adding the following line into 
debian/rules will generate a normal package with libjpeg.so.9* included:

diff -Nru libjpeg9-9d/debian/rules libjpeg9-9d/debian/rules
--- libjpeg9-9d/debian/rules2023-02-15 03:52:51.0 +0800
+++ libjpeg9-9d/debian/rules2022-11-04 03:14:38.0 +0800
@@ -18,8 +18,6 @@
 CFLAGS += -O2
 endif
  
-export EGREP = grep -E
-
 export AUTOMAKE = automake-1.16
 export ACLOCAL = aclocal-1.16
 export AUTOHEADER = true

[1] 
https://buildd.debian.org/status/fetch.php?pkg=libjpeg9=amd64=1%3A9d-1.1=1667678775=0

Regards,
Roy Clark

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

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

-- debconf-show failed

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

On Tue, Feb 14, 2023 at 07:35:51PM +0100, Daniel Leidert wrote:
> 
> As soon as this version hits testing, you have successfully disabled
> the last working environment to use vmdb2 to create images of Ubuntu
> and Debian. As soon as this version hits Testing, one then can no
> longer build images for either any Ubuntu release nor Debian Bullseye
> or older. I can then only build images for Bookworm and Sid. Please
> think about that.

The number of users who use vmdb2 are quite small; for those users who
do, there is a simple fix.  You can either diable the feature using
tune2fs, or you can just make an edit to your /etc/mke2fs.conf file to
not enable the feature.  A one line change to /etc/mke2fs.conf is
hardly what I'd call "impossible".

> You *seriously* break the debootstrap method of installing Debian or
> Ubuntu.

As you have pointed out, this is not a debootstrap issue, since it
doesn't create the file system.  The uestion is in how the file system
is created, and this is not hard to fix.  You can just run "mke2fs -O
^metadata_csum_seed _file_or_block_device_"; you can run "tune2fs -O
^metadata_csum_seed _file_or_block_device"; you can make a one-line
change to /etc/mke2fs.conf.

> You haven't documented how to disable that
> breaking change when creating filesystems for distributions where grub
> does not support this (there is not even a NEWS entry). You haven't
> even announced that breaking change. And yet you are going to break one
> of our two standard methods of installing Debian or Ubuntu. How is any
> of what you have been saying so far addressing any of these issues?

Sorry, as far as I'm concerned, vmdb2 is not that important.  We don't
document in a NEWS entry or anywhere else, how to build a binary that
links against a newer version of glibc so it will work on an older
system.  And I would consider the compiler toolchain to be far more
common a usecase than vmdb2.  Indeed, your use of "toolchain" for file
system utilities is a new one for me.  I've never heard the term
"toolchain" used in such a way before.

> I do not understand why you are pushing 1.47.0 over 1.46.6, which you
> had uploaded just five days before the former. You haven't even
> presented a reason yet.

It has anumber of new features that will improve ext4's performance on
highly parallel workloads; it makes it possible for cloud VM's to be
able to safely update the root file systems's UUID while it is
mounted, among other changes.

- Ted

Bug#1025509: NMU: Drop/replace the Vcs

[Bastian Germann]

I am uploading a NMU to DELAYED/10. The debdiff is attached.diff -Nru etoile-0+20080616+dfsg/debian/changelog 
etoile-0+20080616+dfsg/debian/changelog
--- etoile-0+20080616+dfsg/debian/changelog 2023-02-14 22:44:04.0 
+0100
+++ etoile-0+20080616+dfsg/debian/changelog 2023-02-14 22:40:25.0 
+0100
@@ -1,3 +1,11 @@
+etoile (0+20080616+dfsg-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert to 3.0 (quilt) format (Closes: #1007453).
+  * Move Vcs to salsa (Closes: #1025509).
+
+ -- Bastian Germann   Tue, 14 Feb 2023 22:40:25 +0100
+
 etoile (0+20080616+dfsg-2) unstable; urgency=low
 
   * debian/compat: Bump to 7.
diff -Nru etoile-0+20080616+dfsg/debian/control 
etoile-0+20080616+dfsg/debian/control
--- etoile-0+20080616+dfsg/debian/control   2023-02-14 22:44:04.0 
+0100
+++ etoile-0+20080616+dfsg/debian/control   2023-02-14 22:40:25.0 
+0100
@@ -7,7 +7,8 @@
   libgnustep-gui-dev,
   imagemagick
 Standards-Version: 3.8.4
-Vcs-Arch: http://arch.debian.org/arch/pkg-gnustep/gnustep/etoile--debian--1.0
+Vcs-Git: https://salsa.debian.org/gnustep-team/etoile.git
+Vcs-Browser: https://salsa.debian.org/gnustep-team/etoile
 Homepage: http://etoileos.com
 
 Package: dictionaryreader.app
diff -Nru etoile-0+20080616+dfsg/debian/source/format 
etoile-0+20080616+dfsg/debian/source/format
--- etoile-0+20080616+dfsg/debian/source/format 2023-02-14 22:44:04.0 
+0100
+++ etoile-0+20080616+dfsg/debian/source/format 2023-02-14 22:39:17.0 
+0100
@@ -1 +1 @@
-1.0
+3.0 (quilt)

Bug#1031314: ibus-tests: Please revert the #1018871 change on armel

[Adrian Bunk]

Source: ibus-tests
Version: 1.5.27-2
Severity: important

gnome-shell was never actually removed from unstable since mozjs102
was fixed, please revert the #1018871 change on armel.

Bug#976036: Please depend and build-depend on libgdk-pixbuf-2.0-dev

[matthias . geiger1024]

Hi Simon.

>
> but if this package is unlikely to be backported, you can simplify that
> to just the new package:
>
>   libgdk-pixbuf-2.0-dev
>

Updating the rust-gtk stack involves/affects +44 packages. My wip update for 
gtk-rs 0.5 contains this fix:

https://salsa.debian.org/rust-team/debcargo-conf/-/commit/c5d560e14217d6871ce40fa7c75588be8cad2737

I will add a dch entry and reference this bug. Uploading will happen after the 
freeze has ended.

cheers werdahias

Bug#1031231: tries to overwrite /etc/cron.yearly/.placeholder from systemd-cron

[Alexandre Detiste]

To be explicit: on your side you'd need yet another upload with a

   Conflicts: systemd-cron (<<1.15.19-5~)

(and/or a Breaks?)

Bug#995156: easy-rsa: vars Autodetection

[Lee Garrett]

I'm bumping the bug severity because currently it will ignore 
security-relevant settings like keysize and algo, and the defaults are 
pretty weak.

Bug#1031231: tries to overwrite /etc/cron.yearly/.placeholder from systemd-cron

[Alexandre Detiste]

Hi,

I uploaded systemd-cron_1.15.19-5 , without the file.

I'm not sure if the handover of this non-file
is done correctly, you can NMU if you know better.

[lament placeholder]

Alexandre

Bug#1030956: Acknowledgement (yarnpkg key is out of date)

[David Mandelberg]

I made
https://salsa.debian.org/extrepo-team/extrepo-data/-/merge_requests/209 to
fix this.

Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed

[Lee Garrett]

Bumped severity as this makes bts currently unusable, and probably 
breaks for quite a few DDs their workflow.

Bug#1030455: schedule: FTBFS: AssertionError: ScheduleValueError not raised by until

[Étienne Mollier]

Hello,

Jumping in because this bug is causing autoremoval of a reverse
depency in my radar.  The test failure below did not appear when
I ran the build time tests a dozen of times in a row:
> > test_until_time (test_schedule.SchedulerTests.test_until_time) ... FAIL
> > test_weekday_at_todady 
> > (test_schedule.SchedulerTests.test_weekday_at_todady) ... ok
> > 
> > ==
> > FAIL: test_until_time (test_schedule.SchedulerTests.test_until_time)
> > --
> > Traceback (most recent call last):
> >   File 
> > "/<>/.pybuild/cpython3_3.11_schedule/build/test_schedule.py", 
> > line 317, in test_until_time
> > self.assertRaises(ScheduleValueError, every().day.until, 
> > datetime.time(hour=5))
> > AssertionError: ScheduleValueError not raised by until

However, looking at the nature of the test, and the hour at
which it ran (build log starts at 03:05:50 +), I'm under the
impression that the build time test failure could occur every
day in a window between 0:00 and 5:00 am local hour.  I
scheduled an sbuild attempt `at 3am`, we may see the result
tomorrow and whether the bug is confirmed or unreproducible.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent at ftbfs o'clock.


signature.asc
Description: PGP signature

Bug#1031196: spamass-milter: 'Could not retrieve sendmail macro "b"' with postfix: PATCH

[Don Armstrong]

Control: tag -1 moreinfo - patch

On Mon, 13 Feb 2023, none wrote:
> In this patch I've included a fix for this problem, which includes a
> new option for the /etc/default config. By default it is commented out
> so that the behaviour doesn't change.
> 
> This introduces the -Y command line flag for "postfix compatibility
> mode" which explicitly sets default values for macros which postfix
> doesn't support, or doesn't support in the ENVRCPT context.

It's not clear to me why we'd add this flag. If the macros aren't
supported, the code already falls back to reasonable defaults. The only
change this seems to make is to silence warnings (and breaks the macros
that postfix already supports).

Am I missing something?

> You only see the 'b' macro and never the '{auth_type}' macro failing
> because 'b' is requested first.

That's because warnmacro only warns on the first warning. You're
probably missing the correct configuration in your main.cf:

  # spamass-milter configuration
  smtpd_milters = unix:/spamass/spamass.sock
  # milter macros useful for spamass-milter
  milter_connect_macros = j {daemon_name} v {if_name} _
  milter_data_macros = j i {auth_type} {daemon_name} v {if_name} _
  milter_rcpt_macros = j {auth_type} {daemon_name} v {if_name} _



-- 
Don Armstrong  https://www.donarmstrong.com

Taxes are not levied for the benefit of the taxed.
 -- Robert Heinlein _Time Enough For Love_ p250

Bug#1031212: unblock: util-linux/2.38.1-5

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2023-02-13 10:32:12 +0100, Chris Hofstaedtler wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package util-linux, to fix a bug in logger(1).
> 
> [ Reason ]
> Bug #1030285 reports that logger(1) does not update the syslog header
> information for each line received on stdin. A similar report went
> upstream a longer time ago and upstream fixed this, but did not make a
> release yet.
> 
> [ Impact ]
> logger(1) would report incorrect timestamps for common `stuff | logger`
> usecases.
> 
> [ Tests ]
> Manual test succeeded.
> 
> [ Risks ]
> Patch is from upstream and can be trivially tested.
> 
> [ 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
> 
> As the debdiff will be a diff of a diff, here is the "first layer of
> diff":
> https://salsa.debian.org/debian/util-linux/-/commit/82443e63149b2da9a4b226e01fa07429955ea052#c428a8aed70931706a24001ebaee2aaa216085e2
> 
> unblock util-linux/2.38.1-5

That version is not in the archive. In case you wanted to ask for
pre-approval, please go ahead.

Cheers


> diff -Nru util-linux-2.38.1/debian/changelog 
> util-linux-2.38.1/debian/changelog
> --- util-linux-2.38.1/debian/changelog2022-11-25 15:19:08.0 
> +
> +++ util-linux-2.38.1/debian/changelog2023-02-13 08:48:21.0 
> +
> @@ -1,3 +1,9 @@
> +util-linux (2.38.1-5) unstable; urgency=medium
> +
> +  * Apply upstream patch to fix logger timestamp for stdin (Closes: #1030285)
> +
> + -- Chris Hofstaedtler   Mon, 13 Feb 2023 08:48:21 +
> +
>  util-linux (2.38.1-4) unstable; urgency=medium
>  
>[ Helmut Grohne ]
> diff -Nru util-linux-2.38.1/debian/patches/series 
> util-linux-2.38.1/debian/patches/series
> --- util-linux-2.38.1/debian/patches/series   2022-11-25 15:19:08.0 
> +
> +++ util-linux-2.38.1/debian/patches/series   2023-02-13 08:48:21.0 
> +
> @@ -34,3 +34,4 @@
>  upstream/PATCH-1-2-lib-pty-Put-master-PTY-into-non-blocking-mode-a.patch
>  upstream/PATCH-2-2-lib-pty-minor-cleanups.patch
>  upstream/PATCH-script-abort-if-unused-arguments-are-given.patch
> +upstream/logger-always-update-header-when-read-from-stdin.patch
> diff -Nru 
> util-linux-2.38.1/debian/patches/upstream/logger-always-update-header-when-read-from-stdin.patch
>  
> util-linux-2.38.1/debian/patches/upstream/logger-always-update-header-when-read-from-stdin.patch
> --- 
> util-linux-2.38.1/debian/patches/upstream/logger-always-update-header-when-read-from-stdin.patch
>   1970-01-01 00:00:00.0 +
> +++ 
> util-linux-2.38.1/debian/patches/upstream/logger-always-update-header-when-read-from-stdin.patch
>   2023-02-13 08:48:21.0 +
> @@ -0,0 +1,94 @@
> +From: Karel Zak 
> +Date: Tue, 1 Nov 2022 10:30:06 +0100
> +Subject: logger: always update header when read from stdin
> +
> +The current code updates the header only when the priority has been
> +changed. It's incorrect because wanted is a valid header or each entry
> +(don't forget that logger for stdin use-case is used in pipe to log
> +long-time running processes).
> +
> +This patch also fixes the initial timestamp; it was originally generated
> +on logger startup, it now generates the header on the first message.
> +
> +$ (sleep 2; date; sleep 2; date; sleep 2; date) | logger --stderr --no-act
> +
> +old:
> +<13>Nov  1 10:42:14 kzak: Tue Nov  1 10:42:16 AM CET 2022
> +<13>Nov  1 10:42:14 kzak: Tue Nov  1 10:42:18 AM CET 2022
> +<13>Nov  1 10:42:14 kzak: Tue Nov  1 10:42:20 AM CET 2022
> +
> +new:
> +<13>Nov  1 10:19:02 kzak: Tue Nov  1 10:19:02 AM CET 2022
> +<13>Nov  1 10:19:04 kzak: Tue Nov  1 10:19:04 AM CET 2022
> +<13>Nov  1 10:19:06 kzak: Tue Nov  1 10:19:06 AM CET 2022
> +
> +Fixes: https://github.com/util-linux/util-linux/issues/1866
> +Signed-off-by: Karel Zak 
> +---
> + misc-utils/logger.c | 18 +++---
> + 1 file changed, 7 insertions(+), 11 deletions(-)
> +
> +diff --git a/misc-utils/logger.c b/misc-utils/logger.c
> +index bec684f..e2b0b41 100644
> +--- a/misc-utils/logger.c
>  b/misc-utils/logger.c
> +@@ -945,8 +945,6 @@ static void logger_open(struct logger_ctl *ctl)
> + ctl->tag = ctl->login = xgetlogin();
> + if (!ctl->tag)
> + ctl->tag = "";
> +-
> +-generate_syslog_header(ctl);
> + }
> + 
> + /* re-open; usually after failed connection */
> +@@ -996,10 +994,8 @@ static void logger_stdin(struct logger_ctl *ctl)
> + {
> + /* note: we re-generate the syslog header for each log message to
> +  * update header timestamps and to reflect possible priority changes.
> +- * The initial header is generated by logger_open().
> +  */
> + int default_priority = ctl->pri;
> +-int last_pri = default_priority;
> + char *buf = xmalloc(ctl->max_message_size + 2 + 2);
> + int pri;
> +   

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Samuel Thibault]

Samuel Thibault, le mar. 14 févr. 2023 18:10:11 +0100, a ecrit:
> E: Unable to locate package sound-modules-6.1.0-4-arm64-di
> E: Unable to locate package speakup-modules-6.1.0-4-arm64-di
> 
> and indeed, it seems these modules are getting built only for amd64,
> 686, mips, sh4.
> 
> Could we consider adding them on arm64 in the linux package?

Which boils down to:

cp debian/installer/modules/{i386,arm64}/speakup-modules
cp debian/installer/modules/{i386,arm64}/sound-modules
rm -f debian/control.md5sum
./debian/rules debian/control

Samuel

Bug#1031313: oinkmaster: Vcs-Cvs points to upstream CVS

[Bastian Germann]

Source: oinkmaster
Version: 2.0-4.1

Vcs-Cvs and Vcs-Browser point to the upstream CVS. They have to point to the 
packaging CVS.
So please drop them.

Bug#1031312: libdisasm: Vcs-Cvs points to read-only upstream CVS

[Bastian Germann]

Source: libdisasm
Version: 0.23-6

Vcs-Cvs and Vcs-Browser point to the upstream CVS. They have to point to the 
packaging CVS.
So please drop them.

Bug#1031311: stunnel4: Starting with systemd does not create /var/run/stunnel4

[Oron Peled]

Package: stunnel4
Version: 3:5.56+dfsg-10
Severity: important
X-Debbugs-Cc: oron.pe...@harmonicinc.com

Dear Maintainer,

   * This problem is relevant when starting an "stunnel4" instance from systemd
 E.g: "systemct start stunnel@foobar.service"

   * The service fails with the following errors (taken from the journal):
 ---
-
 Feb 14 21:42:36 sync2-cableos stunnel[559]: LOG3[ui]: Cannot create pid
file /var/run/stunnel4/rsync-ssl.pid
 Feb 14 21:42:36 sync2-cableos stunnel[559]: LOG3[ui]: create: No such file
or directory (2)
 ---
-

   * The reason is clear:
 - Path "/var/run" is a symlink to "/run"
   (on Debian/bullseye, as most modern Linux systems)

 - Path "/run" is mounted as tmpfs

 - No mechanism create "/run/stunnel4" during service startup or boot

   * There are several possible solutions -- I tested the "tmpfiles.d" mechanism

   * This is how I locally fixed the issue:
 - I created "/usr/lib/tmpfiles.d/stunnel4.conf" with the following
contents:

 #Type   PathModeUID GID   
Age Arguments
 d   /run/stunnel4   0755stunnel4stunnel4  
-   -

 - During boot an OS that use systemd will run "systemd-tmpfiles-
setup.service"
 - This service reads all "tmpfile.d" configurations and generate the needed
files/directories
 - With the simple file described above the service run correctly.

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

Kernel: Linux 5.10.0-20-amd64 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_AUX
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages stunnel4 depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u5
ii  libssl1.11.1.1n-0+deb11u3
ii  libsystemd0  247.3-7+deb11u1
ii  libwrap0 7.6.q-31
ii  lsb-base 11.1.0
ii  netbase  6.3
ii  openssl  1.1.1n-0+deb11u3
ii  perl 5.32.1-4+deb11u2

stunnel4 recommends no packages.

Versions of packages stunnel4 suggests:
pn  logcheck-database  

-- no debconf information

Bug#1014653: nvidia-driver: RTX-3050 is not supported by 470.129.06 driver

[Andreas Beckmann]

On 09/07/2022 19.53, root wrote:

Nvidia driver 470.129.06 does not support RTX-3050 videocard, however 
nvidia-detect says the opposite.


Does it work with the newer 470 driver in stable (or the tesla-470 
driver in sid/bookworm?)



Andreas

Bug#809034: Vcs-Git point to upstream repository

[Bastian Germann]

I am uploading a NMU to DELAYED/10 to fix this.
The debdiff is attached.diff -u netselect-0.3.ds1/debian/README.source 
netselect-0.3.ds1/debian/README.source
--- netselect-0.3.ds1/debian/README.source
+++ netselect-0.3.ds1/debian/README.source
@@ -1,12 +1,6 @@
 
 Netselect's sources in Debian have been somewhat modified from upstream's.
 
-Upstream's repository is accesible in https://github.com/apenwarr/netselect
-
-Debian repository for the the code used in netselect packages is
-available in SVN at
-svn://svn.debian.org/svn/collab-maint/deb-maint/netselect/trunk
-
 
 Javier Fernandez-Sanguino 
 Wed, 01 Dec 2010 00:00:09 +0100
diff -u netselect-0.3.ds1/debian/TODO netselect-0.3.ds1/debian/TODO
--- netselect-0.3.ds1/debian/TODO
+++ netselect-0.3.ds1/debian/TODO
@@ -41,4 +41,4 @@
 package:
 ---
 
-* move to collab-qa (git)
+* move to salsa (git)
diff -u netselect-0.3.ds1/debian/changelog netselect-0.3.ds1/debian/changelog
--- netselect-0.3.ds1/debian/changelog
+++ netselect-0.3.ds1/debian/changelog
@@ -1,3 +1,11 @@
+netselect (0.3.ds1-30.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Drop Vcs-* fields (Closes: #809034)
+  * Move upstream repo info from d/README.source to d/copyright
+
+ -- Bastian Germann   Tue, 14 Feb 2023 21:10:32 +0100
+
 netselect (0.3.ds1-30) unstable; urgency=high
 
   * netselect-apt: 
diff -u netselect-0.3.ds1/debian/control netselect-0.3.ds1/debian/control
--- netselect-0.3.ds1/debian/control
+++ netselect-0.3.ds1/debian/control
@@ -4,9 +4,6 @@
 Maintainer: Javier Fernández-Sanguino Peña 
 Standards-Version: 4.5.1
 Build-Depends: debhelper (>= 13), po-debconf
-VCS-Git: git://github.com/apenwarr/netselect.git
-VCS-Browser: http://github.com/apenwarr/netselect
-VCS-Svn: svn://svn.debian.org/svn/collab-maint/deb-maint/netselect/trunk
 Homepage: http://github.com/apenwarr/netselect
 
 Package: netselect
diff -u netselect-0.3.ds1/debian/copyright netselect-0.3.ds1/debian/copyright
--- netselect-0.3.ds1/debian/copyright
+++ netselect-0.3.ds1/debian/copyright
@@ -1,7 +1,7 @@
 This is the Debian GNU/Linux packaged version of netselect.  It was written and
 then Debian-packaged by Avery Pennarun .
 It was downloaded from:
-http://people.nit.ca/~apenwarr/netselect/index.html
+https://github.com/apenwarr/netselect
 It was derived from Van Jacobson's traceroute, and shares its license, which
 follows:
 

Bug#1031146: RFS: lighttpd/1.4.69-1 [NMU] -- light, fast, functional web server

[Glenn Strauss]

On Tue, Feb 14, 2023 at 05:50:12PM +0100, Santiago Ruano Rincón wrote:
> Hello Glenn,
> 
> El 12/02/23 a las 08:54, Glenn Strauss escribió:
> > > Since you are listed in Uploaders:, this shouldn't be a NMU. I don't
> > > understand why lintian doesn't complain about this in this job:
> > > https://salsa.debian.org/debian/lighttpd/-/jobs/3931309
> > > but don't have the time to investigate that right now.
> > > 
> > > Please, fix the changelog.
> > 
> > changelog updated.  Thanks for your guidance.
> > Cheers, Glenn
> > 
> 
> Sorry I was unable to give you more feedback the first time. So I am
> iterating. ENOTIME…

Iterating makes progress!  Thank you!

> I am afraid I cannot parse that entry. What are the changes related to
> 1.4.68?

I had prepared a release for 1.4.68, and earlier for 1.4.67-2.
It was a separate changelog entry, but nmudiff did not work since
it detected 1.4.68 (not released) as a prior version.  Therefore,
I had merged the changelog entries.  I've now edited that entry to
simply be the combination, without reference to 1.4.68.

>   * Remove deprecated lighttpd modules.
>   * Skip installing modules now built into lighttpd.
>   * Add to not-installed mods now built into lighttpd.
> 
> Is it worth to list those modules?
> Is there any impact for the uses to they should be warned via e.g.
> debian/NEWS too?

There should be no impact for end users.
The change impacts packaging.

> 2. d/lighttpd.NEWS:
> 
> As lintian complains, this entry relates a release not known by debian:
> 
> lighttpd (1.4.67-2) experimental; urgency=medium
> 
> Do you think NEWS could be updated?

Updated to 1.4.69-1, as this will be the release that contains the
change.

Cheers, Glenn

Bug#1031160: reason for removal of zeroc-ice on armhf and arm64.

[Paul Gevers]

Hi Adrian,

On 14-02-2023 14:25, Adrian Bunk wrote:

This will require a hint from the release team I have not yet requested,
since installability of binary-all packages is tested on amd64 and arm64
but there is no requirement that a binary-all package is installable on
arm64 and several are not.[1]


And dose suggests [2] there are much more:

[2] https://qa.debian.org/dose/debcheck/testing_main/index.html

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1028356: procmail: Variable set with stdin pipe action fails leaving empty variable

[Santiago Vila]

Hello.

This is what I did today. Maybe someone can follow my steps
and arrive at something.

I'm using this $HOME/.procmailrc file:

-
LOGFILE=$HOME/.cache/procmail.log
VERBOSE=yes

:0 h
SUBJECT=|formail -cXSubject:|cat

MYVAR=$SUBJECT

:0
/dev/null
-

and this command to test it:

echo "Subject: thesubject" | formail | procmail

A non-buggy procmail (for example, the one in bullseye) will
produce a $HOME/.cache/procmail.log file like this:

procmail: [2236560] Tue Feb 14 20:27:41 2023
procmail: Assigning "SUBJECT="
procmail: [2236560] Tue Feb 14 20:27:41 2023
procmail: Executing "formail -cXSubject:|cat"
procmail: Assigning "MYVAR=Subject: thesubject"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
procmail: Notified comsat: "bluser@0:/dev/null"
From foo@bar  Tue Feb 14 20:27:41 2023
 Subject: thesubject
  Folder: /dev/null  60


However, a buggy procmail (for example, procmail_3.24-1) will
produce a $HOME/.cache/procmail.log file like this:

procmail: [2236823] Tue Feb 14 20:30:28 2023
procmail: Assigning "SUBJECT="
procmail: [2236823] Tue Feb 14 20:30:28 2023
procmail: Executing "formail -cXSubject:|cat"
procmail: Assigning "MYVAR="
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
procmail: Notified comsat: "bluser@0:/dev/null"
From foo@bar  Tue Feb 14 20:30:28 2023
 Subject: thesubject
  Folder: /dev/null  60

The relevant thing here is that MYVAR is empty.


Now, to do a git-bisect (or something which resembles it),
I'm doing this:

git checkout some-git-id --force

To avoid putting the debian/* files on top of this,
I'm using this simple script "make-procmail" to compile:

#!/bin/sh
set -e
make CC=gcc CFLAGS0="" LDFLAGS0="" SEARCHLIBS="-lm" LOCKINGTEST=100
cat src/procmail > /usr/bin/procmail

where I've previously made /usr/bin/procmail mode 777 for that to work.
(This is naturally in a test machine).

It is possible that the above fails with "text file busy", then
I execute this other script as root:

#!/bin/sh
set -e
cd /usr/bin
rm -f procmail
touch procmail
chmod 777 procmail


If "some-git-id" is too old, the following error may arise:

formisc.h:20:2: error: conflicting types for ‘getline’
   20 |  getline P((void));
  |  ^~~
In file included from includes.h:41,
 from formail.c:16:
/usr/include/stdio.h:616:18: note: previous declaration of ‘getline’ was here
  616 | extern __ssize_t getline (char **__restrict __lineptr,

(This was Bug #549426 fixed in version 3.22-18).

In such case this is enough to get rid of such error:

git show 2df8bdb0d2557d6cdc7632e | patch -p1


Now the bad news:

According to my tests, this commit, tagged v3.23pre, is already buggy:

commit 98ca67898b3f38ea09f1a0d1119d0794c044f9b6 (HEAD, tag: v3.23pre)
Author: Philip Guenther 
Date:   Tue Nov 1 03:15:48 2005 +

Fixed properties

The previous commit is huge and it's already buggy:

commit 5281aac102d92966c5963ea8694d95e4f1103747
Author: Philip Guenther 
Date:   Tue Nov 1 01:44:56 2005 +

Various fixes.

[lots of stuff]


And finally, the commit before that makes this simple command

echo "Subject: thesubject" | formail  | procmail

to take some time to return (locking problems?) and
the log output on procmail.log is like this:

procmail: [2243217] Tue Feb 14 21:04:28 2023
procmail: Assigning "SUBJECT="
procmail: [2243217] Tue Feb 14 21:04:28 2023
procmail: Executing "formail -cXSubject:|cat"
procmail: Out of memory
buffer 0: "formail -cXSubject:|cat"
buffer 1: "formail -cXSubject:|cat"
procmail: Notified comsat: "bluser@:**Bounced**"
From foo@bar  Tue Feb 14 21:04:28 2023
  Folder: **Bounced** 0

Because there is not a MYVAR= line, I'm not even able
to tell if this is also buggy or not.

So, to summarize: I still need help to fix this...

Thanks.

Bug#1031310: git: CVE-2023-22490 CVE-2023-23946

[Salvatore Bonaccorso]

Source: git
Version: 1:2.30.2-1
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:2.39.1-0.1

Hi,

The following vulnerabilities were published for git.

CVE-2023-22490[0] and CVE-2023-23946[1].

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-22490
https://www.cve.org/CVERecord?id=CVE-2023-22490
[1] https://security-tracker.debian.org/tracker/CVE-2023-23946
https://www.cve.org/CVERecord?id=CVE-2023-23946
[2] https://www.openwall.com/lists/oss-security/2023/02/14/5

Regards,
Salvatore

Bug#1031246: systemd-udevd.service: Failed to call EVIOCSKEYCODE: Invalid argument

[Michael Biebl]

Am 14.02.23 um 20:20 schrieb Dominik S:

Yes, same error.
I added in the description this version because the error occurred on 
it. Reportbug prompted me to try 253~rc1-1 and there is the same error.






Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: Processing device 
(SEQNUM=3309, ACTION=add)
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: 
/usr/lib/udev/rules.d/50-udev-default.rules:18 Importing properties from 
results of builtin command 'hwdb --subsystem=platform'
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: hwdb modalias key: 
"platform:eeepc-wmi"
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: No entry found from hwdb.
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: 
/usr/lib/udev/rules.d/50-udev-default.rules:18 Failed to run builtin 'hwdb 
--subsystem=platform': No data available
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: 
/usr/lib/udev/rules.d/60-drm.rules:3 Importing properties from results of 
builtin command 'path_id'
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: 
/usr/lib/udev/rules.d/80-drivers.rules:5 RUN 'kmod load'
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: sd-device: Created db file 
'/run/udev/data/+platform:eeepc-wmi' for '/devices/platform/eeepc-wmi'
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: Running built-in command "kmod 
load"
Feb 14 20:12:43 amdpc (udev-worker)[545]: Loading module: platform:eeepc-wmi
Feb 14 20:12:43 amdpc (udev-worker)[545]: Failed to find module 
'platform:eeepc-wmi'
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: Device processed 
(SEQNUM=3309, ACTION=add)
Feb 14 20:12:43 amdpc (udev-worker)[545]: eeepc-wmi: sd-device-monitor(worker): 
Passed 270 byte to netlink monitor.
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: Processing device 
(SEQNUM=3312, ACTION=add)
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/50-udev-default.rules:18 Importing properties from 
results of builtin command 'hwdb --subsystem=input'
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: hwdb modalias key: 
"input:b0019vpe-e0,1,4,14,k71,72,73,8B,94,98,AB,AC,B8,B9,D4,E0,E1,E3,EE,F0,1AF,212,215,216,217,218,219,21A,ram4,lsfw"
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: No entry found from hwdb.
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/50-udev-default.rules:18 Failed to run builtin 'hwdb 
--subsystem=input': No data available
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/60-input-id.rules:5 Importing properties from results of 
builtin command 'input_id'
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: capabilities/ev raw kernel 
attribute: 100013
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: capabilities/abs raw kernel 
attribute: 0
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: capabilities/rel raw kernel 
attribute: 0
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: capabilities/key raw kernel 
attribute: 7e4 0 8000 0 0 1400b0010 300180001100800 
e 2
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: properties raw kernel 
attribute: 0
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: test_key: checking bit block 
0 for any keys; found=yes
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/60-input-id.rules:6 Importing properties from results of 
builtin command 'hwdb --subsystem=input --lookup-prefix=id-input:modalias:'
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: hwdb modalias key: 
"input:b0019vpe-e0,1,4,14,k71,72,73,8B,94,98,AB,AC,B8,B9,D4,E0,E1,E3,EE,F0,1AF,212,215,216,217,218,219,21A,ram4,lsfw"
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: No entry found from hwdb.
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/60-input-id.rules:6 Failed to run builtin 'hwdb 
--subsystem=input --lookup-prefix=id-input:modalias:': No data available
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/60-persistent-input.rules:35 Importing properties from 
results of builtin command 'path_id'
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: 
/usr/lib/udev/rules.d/80-drivers.rules:5 RUN 'kmod load'
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: sd-device: Created db file 
'/run/udev/data/+input:input9' for '/devices/platform/eeepc-wmi/input/input9'
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: Running built-in command "kmod 
load"
Feb 14 20:12:43 amdpc (udev-worker)[545]: Loading module: 
input:b0019vpe-e0,1,4,14,k71,72,73,8B,94,98,AB,AC,B8,B9,D4,E0,E1,E3,EE,F0,1AF,212,215,216,217,218,219,21A,ram4,lsfw
Feb 14 20:12:43 amdpc (udev-worker)[545]: Module 'evdev' is already loaded
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: Device processed 
(SEQNUM=3312, ACTION=add)
Feb 14 20:12:43 amdpc (udev-worker)[545]: input9: sd-device-monitor(worker): 
Passed 635 byte to netlink monitor.
Feb 14 20:12:43 amdpc (udev-worker)[545]: event9: Processing device 
(SEQNUM=3313, ACTION=add)
Feb 14 

Bug#1031309: accountsservice: accounts-daemon service will prevent system boot if shadowconfig is off

[john amidon]

Package: accountsservice
Version: 22.08.8-5
Severity: critical
Justification: breaks the whole system
X-Debbugs-Cc: jami...@helixinnovations.io

Dear Maintainer,

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

   * What led up to the situation?
I set shadowconfig to 'off' when I edited '/etc/group' and forgot to reset it.
Sometime later, I ran 'apt upgrade', rebooted, and found that the boot did not
complete, complaining about accounts-daemon.service not starting.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
booted into recovery mode, looked at journal and discovered that 'shadowconfig'
was set to 'off' and re-enabled it

   * What was the outcome of this action?
machine successfully rebooted


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

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

Versions of packages accountsservice depends on:
ii  dbus [default-dbus-system-bus]  1.14.6-1
ii  libaccountsservice0 22.08.8-5
ii  libc6   2.36-8
ii  libglib2.0-02.74.5-1
ii  libpolkit-gobject-1-0   122-3

Versions of packages accountsservice recommends:
ii  libpam-systemd [logind]  252.5-2
ii  polkitd  122-3

Versions of packages accountsservice suggests:
ii  gnome-control-center  1:43.2-2

-- no debconf information

Bug#1031308: redmine FTBFS: test failure

[Adrian Bunk]

Source: redmine
Version: 5.0.4-3
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=redmine=all

...
PARALLEL_WORKERS=2 bin/rake test RAILS_ENV=test
sh: 1: gs: not found
(GhostScript convert not available)
Bazaar test repository NOT FOUND. Skipping functional tests !!!
CVS test repository NOT FOUND. Skipping functional tests !!!
Filesystem test repository NOT FOUND. Skipping functional tests !!!
Git test repository NOT FOUND. Skipping functional tests !!!
Mercurial test repository NOT FOUND. Skipping functional tests !!!
Subversion test repository NOT FOUND. Skipping functional tests !!!
Git test repository NOT FOUND. Skipping integration tests !!!
(Test LDAP server not configured)
Bazaar test repository NOT FOUND. Skipping unit tests !!!
Cvs test repository NOT FOUND. Skipping unit tests !!!
Filesystem test repository NOT FOUND. Skipping unit tests !!! See 
doc/RUNNING_TESTS.
Git test repository NOT FOUND. Skipping unit tests !!!
Mercurial test repository NOT FOUND. Skipping unit tests !!!
Subversion test repository NOT FOUND. Skipping unit tests !!!
Bazaar test repository NOT FOUND. Skipping unit tests !!!
CVS test repository NOT FOUND. Skipping unit tests !!!
Filesystem test repository NOT FOUND. Skipping unit tests !!! See 
doc/RUNNING_TESTS.
Git test repository NOT FOUND. Skipping unit tests !!!
Git UTF-8 test repository NOT FOUND. Skipping unit tests !!!
Mercurial test repository NOT FOUND. Skipping unit tests !!!
Subversion test repository NOT FOUND. Skipping unit tests !!!
Skipping LDAP tests.
Run options: --seed 22796

# Running:

..SSSE

Error:
Redmine::PluginLoaderTest#test_mirror_assets:
RuntimeError: Could not copy 
/<>/test/fixtures/plugins/foo_plugin/assets/stylesheets/foo.css to 
/<>/tmp/public/plugin_assets/foo_plugin/stylesheets/foo.css: No 
such file or directory @ rb_sysopen - 
/<>/tmp/public/plugin_assets/foo_plugin/stylesheets/foo.css
lib/redmine/plugin_loader.rb:71:in `rescue in block in mirror_assets'
lib/redmine/plugin_loader.rb:66:in `block in mirror_assets'
lib/redmine/plugin_loader.rb:65:in `each'
lib/redmine/plugin_loader.rb:65:in `mirror_assets'
lib/redmine/plugin_loader.rb:143:in `each'
lib/redmine/plugin_loader.rb:143:in `mirror_assets'
test/unit/lib/redmine/plugin_loader_test.rb:45:in `test_mirror_assets'

rails test test/unit/lib/redmine/plugin_loader_test.rb:44

(Ghostscript
 not available)

Bug#1031307: ruby-oj: buf.h #includes mem.h that is not shipped

[Adrian Bunk]

Package: ruby-oj
Version: 3.14.1-3
Severity: serious
Tags: ftbfs
Control: affects -1 src:ruby-oj-introspect

https://buildd.debian.org/status/fetch.php?pkg=ruby-oj-introspect=armhf=0.7.1-3=1676220273=0

...
In file included from /usr/include/ruby-3.1.0/vendor_ruby/oj/parser.h:10,
 from introspect.c:3:
/usr/include/ruby-3.1.0/vendor_ruby/oj/buf.h:8:10: fatal error: mem.h: No such 
file or directory
8 | #include "mem.h"
  |  ^~~
...

Bug#1031306: rust-criterion: autopkgtest regression

[Adrian Bunk]

Source: rust-criterion
Version: 0.4.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/rust-criterion/31329906/log.gz

...
error[E0004]: non-exhaustive patterns: `Some(BytesDecimal(_))` not covered
  --> src/csv_report.rs:36:55
   |
36 | let (throughput_num, throughput_type) = match id.throughput {
   |   ^ 
pattern `Some(BytesDecimal(_))` not covered
   |
note: `std::option::Option` defined here
   = note: the matched value is of type `std::option::Option`
help: ensure that all possible cases are being handled by adding a match arm 
with a wildcard pattern or an explicit pattern as shown
   |
39 ~ None => (None, None),
40 ~ Some(BytesDecimal(_)) => todo!(),
   |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `criterion` due to previous error
...
autopkgtest [01:29:46]:  summary
rust-criterion-0.4:@ FAIL non-zero exit status 101
rust-criterion-0.4:cargo_bench_support PASS
rust-criterion-0.4:csv_output FAIL non-zero exit status 101
rust-criterion-0.4:default PASS
rust-criterion-0.4:html_reports PASS
rust-criterion-0.4:  PASS
rust-criterion-0.4:async_futures PASS
rust-criterion-0.4:async_smol PASS
rust-criterion-0.4:async_std PASS
rust-criterion-0.4:async_tokio PASS
rust-criterion-0.4:stable FAIL non-zero exit status 101

Bug#1031305: libhttp-daemon-ssl-perl: autopkgtest regression with libio-socket-ssl-perl_2.081-2

[Adrian Bunk]

Source: libhttp-daemon-ssl-perl
Version: 1.05-01-4
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/libh/libhttp-daemon-ssl-perl/31328850/log.gz

...
t/testmodule.t .. 
1..14
ok #authority certificate generated 1
ok #server certificate generated 2
ok #authority certificate saved 3
ok #server certificate saved 4
ok #server key saved 5
ok #server init port=43389 6
ok #server fileno 7
ok #server url test 8
ok #client bad connection test 7
ok #bad request handled 9
Use of uninitialized value $2 in concatenation (.) or string at 
/usr/share/perl5/IO/Socket/SSL.pm line 792.
ok #client good connection test 8
ok #valid request handled 10
ok #server method processing 11
ok #client permission test 9
ok
All tests successful.
Files=3, Tests=37,  2 wallclock secs ( 0.01 usr  0.00 sys +  1.41 cusr  0.05 
csys =  1.47 CPU)
Result: PASS
autopkgtest [00:12:47]: test autodep8-perl-build-deps: ---]
autopkgtest [00:12:47]: test autodep8-perl-build-deps:  - - - - - - - - - - 
results - - - - - - - - - -
autodep8-perl-build-deps FAIL stderr: Use of uninitialized value $2 in 
concatenation (.) or string at /usr/share/perl5/IO/Socket/SSL.pm line 792.
...
autopkgtest [00:13:17]:  summary
autodep8-perl-build-deps FAIL stderr: Use of uninitialized value $2 in 
concatenation (.) or string at /usr/share/perl5/IO/Socket/SSL.pm line 792.
autodep8-perlPASS (superficial)
autodep8-perl-recommends PASS (superficial)

Bug#1031304: linux-image-6.1.0-3-amd64: Slow and unstable wifi connection with Realtek RTL8188EUS

[Ulrich Möhrke]

Package: src:linux
Version: 6.1.8-1
Severity: normal

Dear Maintainer,

I noticed a slow and unstable wifi connection with
Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter 
(usb id 0bda:8179).
Web browsers could not open websites. Mail client thunderbird had 
problems to reach servers. With ping pages get lost. I do not notice 
such problems when I change back to linux-image-5.10.0-..-amd64.


(Sorry if you get the report a second time. First time my mail alias for
bug reports had been deactivated. Therefore I write again.)

I don't know, which information are helpful at the moment.
Maybe the part from lsusb -v for this device:
Bus 001 Device 002: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 
802.11n

Wireless Network Adapter
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0bda Realtek Semiconductor Corp.
  idProduct  0x8179 RTL8188EUS 802.11n Wireless Network Adapter
  bcdDevice0.00
  iManufacturer   1 Realtek
  iProduct2 802.11n NIC
  iSerial 3 00E04C0001
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   0x0027
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0
bmAttributes 0xa0
  (Bus Powered)
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval   0

Kind regards,
Ulrich


-- Package-specific info:
** Version:
Linux version 6.1.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-12 
(Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.8-1 (2023-01-29)


** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-3-amd64 
root=UUID=6196b7dc-a3fa-4a75-a280-3179902ecfe9 ro


** Tainted: COE (13312)
 * staging driver was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
[7.672568] usb 1-3: new high-speed USB device number 2 using ehci-pci
[7.684980] e1000e :00:19.0 eth0: (PCI Express:2.5GT/s:Width x1) 
00:1c:25:80:bf:3f
[7.684988] e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network 
Connection

[7.685017] e1000e :00:19.0 eth0: MAC: 6, PHY: 6, PBA No: 1008FF-0FF
[7.689390] yenta_cardbus :15:00.0: ISA IRQ mask 0x0cb8, PCI irq 16
[7.689400] yenta_cardbus :15:00.0: Socket status: 3006
[7.689406] yenta_cardbus :15:00.0: pcmcia: parent PCI bridge 
window: [io  0x7000-0xafff]
[7.689410] yenta_cardbus :15:00.0: pcmcia: parent PCI bridge 
window: [mem 0xf830-0xfbff]
[7.689414] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xf830-0xfbff:

[7.689419]  excluding 0xf830-0xf86c
[7.689431] yenta_cardbus :15:00.0: pcmcia: parent PCI bridge 
window: [mem 0xf400-0xf7ff 64bit pref]
[7.689434] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xf400-0xf7ff:

[7.689440]  excluding 0xf400-0xf7ff
[7.695121] snd_hda_intel :00:1b.0: probe_mask set to 0x1 for 
device 17aa:20ac

[7.708730] uhci_hcd :00:1d.1: UHCI Host Controller
[7.747350] iTCO_vendor_support: vendor-support=0
[7.750874] e1000e :00:19.0 enp0s25: renamed from eth0
[7.764620] uhci_hcd :00:1d.1: new USB bus registered, 

Bug#1031303: silver-platter: autopkgtest regression

[Adrian Bunk]

Source: silver-platter
Version: 0.5.6-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/s/silver-platter/31340548/log.gz

...
==
ERROR: tests (unittest.loader._FailedTest.tests)
--
ImportError: Failed to import test module: tests
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 154, in loadTestsFromName
module = __import__(module_name)
 ^^^
ModuleNotFoundError: No module named 'silver_platter.tests'


--
Ran 1 test in 0.000s

FAILED (errors=1)
autopkgtest [07:13:29]: test testsuite: ---]
autopkgtest [07:13:30]: test testsuite:  - - - - - - - - - - results - - - - - 
- - - - -
testsuiteFAIL non-zero exit status 1

Bug#1020387: dictionaries-common: Consensus regarding the packaging of the Qt WebEngine hunspell binary dictionaries

[Lisandro Damián Nicanor Pérez Meyer]

One thing I do not understand is why is this needed on both Qt 5 and Qt 6? 
What I understand from the thread is that currently any of them can provide 
the dictionaries, so why not keeping this under just one source package?




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

Bug#1031302: devscripts FTBFS with black 23.1.0

[Adrian Bunk]

Source: devscripts
Version: 2.23.1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=devscripts=s390x=2.23.1=1676400700=0
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/devscripts.html

...
==
FAIL: test_black (devscripts.test.test_black.BlackTestCase.test_black)
Test: Run black code formatter on Python source code.
--
Traceback (most recent call last):
  File "/build/1st/devscripts-2.23.1/scripts/devscripts/test/test_black.py", 
line 43, in test_black
self.fail(
AssertionError: black found code that needs reformatting:
--- wrap-and-sort   2023-02-04 23:33:58 +
+++ wrap-and-sort   2024-03-19 01:21:02.603765 +
@@ -193,11 +193,10 @@
 return True
 return False
 
 
 class InstallContent:
-
 __slots__ = ("content", "comments")
 
 def __init__(self, content, comments=None):
 self.content = content
 self.comments = comments
--- sadt2023-02-04 23:33:58 +
+++ sadt2024-03-19 01:21:02.593172 +
@@ -129,11 +129,10 @@
 def close(self):
 pass
 
 
 class DefaultProgress(Progress):
-
 _hourglass = r"/-\|"
 
 def __init__(self):
 self._counter = 0
 self._output = False
--- debootsnap  2023-02-04 23:33:58 +
+++ debootsnap  2024-03-19 01:21:02.985582 +
@@ -652,11 +652,10 @@
 for source in sources:
 print(source.deb_line(), end="")
 sys.exit(0)
 
 with tempfile.TemporaryDirectory() as tmpdirname:
-
 download_packages(tmpdirname, sources, pkgs, nativearch, foreignarches)
 
 create_repo(tmpdirname, pkgs)
 
 newpkgs = run_mmdebstrap(

--
Ran 17 tests in 37.834s

FAILED (failures=1)
Test failed: 
error: Test failed: 
make[3]: *** [Makefile:103: test_py] Error 1

Bug#1030285: bsdutils: logger: regressed to reusing initial timestamp

[Thorsten Glaser]

Hi,

ping? Please do merge the upstream fix.

Thanks,
//mirabilos

Bug#1031301: node-http-server: CVE-2021-23797

[Moritz Mühlenhoff]

Source: node-http-server
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for node-http-server.

CVE-2021-23797[0]:
| All versions of package http-server-node are vulnerable to Directory
| Traversal via use of --path-as-is.

https://security.snyk.io/vuln/SNYK-JS-HTTPSERVERNODE-1727656

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

Please adjust the affected versions in the BTS as needed.

Bug#1031300: ITP: sphinx-argparse-cli -- Sphinx extension to render CLI arguments defined by the argparse module

[Faidon Liambotis]

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

* Package name: sphinx-argparse-cli
  Version : 1.11.0
  Upstream Author : Bernát Gábor 
* URL : https://github.com/tox-dev/sphinx-argparse-cli/
* License : Expat
  Programming Lang: Python
  Description : Sphinx extension to render CLI arguments defined by the 
argparse module

 sphinx-argparse-cli is an extension for Sphinx to render documentation for
 command-line interface (CLI) arguments defined by the argparse module.
 .
 Unlike the sphinx-argparse module, this module is more capable with regards to
 CLI interfaces that utilize sub-commands. A notable example is the "tox"
 project, from which this module originates.

The package is trivial, but if anyone is interested in helping maintain
it, or with tox's maintenance, you're more than welcome!

Bug#1031299: r-cran-ggalluvial: autopkgtest regression

[Adrian Bunk]

Source: r-cran-ggalluvial
Version: 0.12.4-1
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-ggalluvial/31321147/log.gz

...
══ Failed tests 
── Error ('test-stat-flow.r:10'): `stat_flow` weights computed variables but 
drops weight ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  "B", deposit = 1, fissure = 1, link = 1, flow = from, adj_deposit = 1.1.3,
  adj_fissure = 1.1.1.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─base::as.data.frame(StatFlow$compute_panel(data)) at 
test-stat-flow.r:10:2
  2. ├─StatFlow$compute_panel(data)
  3. │ └─ggalluvial (local) compute_panel(..., self = self)
  4. │   └─dplyr::summarize_at(data, "lode", distill)
  5. │ ├─dplyr::summarise(.tbl, !!!funs)
  6. │ └─dplyr:::summarise.grouped_df(.tbl, !!!funs)
  7. │   └─dplyr:::summarise_cols(.data, dplyr_quosures(...), caller_env = 
caller_env())
  8. │ ├─base::withCallingHandlers(...)
  9. │ └─dplyr:::map(quosures, summarise_eval_one, mask = mask)
 10. │   └─base::lapply(.x, .f, ...)
 11. │ └─dplyr (local) FUN(X[[i]], ...)
 12. │   └─mask$eval_all_summarise(quo)
 13. ├─dplyr (local) ``(lode)
 14. └─base::.handleSimpleError(...)
 15.   └─dplyr (local) h(simpleError(msg, call))
 16. └─rlang::abort(bullets, call = error_call, parent = 
skip_internal_condition(e))
── Error ('test-stat-flow.r:28'): `stat_flow` orders flows correctly with 
negative values ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  "A", deposit = 2, fissure = 1, link = 1, flow = from, adj_deposit = 1.2.3,
  adj_fissure = 1.1.1.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─StatFlow$compute_panel(data) at test-stat-flow.r:28:2
  2. │ └─ggalluvial (local) compute_panel(..., self = self)
  3. │   └─dplyr::summarize_at(data, "lode", distill)
  4. │ ├─dplyr::summarise(.tbl, !!!funs)
  5. │ └─dplyr:::summarise.grouped_df(.tbl, !!!funs)
  6. │   └─dplyr:::summarise_cols(.data, dplyr_quosures(...), caller_env = 
caller_env())
  7. │ ├─base::withCallingHandlers(...)
  8. │ └─dplyr:::map(quosures, summarise_eval_one, mask = mask)
  9. │   └─base::lapply(.x, .f, ...)
 10. │ └─dplyr (local) FUN(X[[i]], ...)
 11. │   └─mask$eval_all_summarise(quo)
 12. ├─dplyr (local) ``(lode)
 13. └─base::.handleSimpleError(...)
 14.   └─dplyr (local) h(simpleError(msg, call))
 15. └─rlang::abort(bullets, call = error_call, parent = 
skip_internal_condition(e))
── Error ('test-stat-flow.r:56'): `stat_flow` orders alluvia correctly 
according to `aes.bind` ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  "A", deposit = 2, fissure = -2, link = 1, flow = from, adj_deposit = 1.2.4,
  adj_fissure = 1.-2.-2.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─StatFlow$compute_panel(data) at test-stat-flow.r:56:2
  2. │ └─ggalluvial (local) compute_panel(..., self = self)
  3. │   └─dplyr::summarize_at(data, "lode", distill)
  4. │ ├─dplyr::summarise(.tbl, !!!funs)
  5. │ └─dplyr:::summarise.grouped_df(.tbl, !!!funs)
  6. │   └─dplyr:::summarise_cols(.data, dplyr_quosures(...), caller_env = 
caller_env())
  7. │ ├─base::withCallingHandlers(...)
  8. │ └─dplyr:::map(quosures, summarise_eval_one, mask = mask)
  9. │   └─base::lapply(.x, .f, ...)
 10. │ └─dplyr (local) FUN(X[[i]], ...)
 11. │   └─mask$eval_all_summarise(quo)
 12. ├─dplyr (local) ``(lode)
 13. └─base::.handleSimpleError(...)
 14.   └─dplyr (local) h(simpleError(msg, call))
 15. └─rlang::abort(bullets, call = error_call, parent = 
skip_internal_condition(e))
── Error ('test-stat-flow.r:78'): `stat_flow` preserves missingness to position 
flows ──
Error in `summarise(.tbl, !!!funs)`: Problem while computing `lode = (function 
(x, order_by = NULL, default =
NULL, na_rm = FALSE) ...`.
ℹ The error occurred in group 1: alluvium = 1, x = 1, yneg = FALSE, stratum =
  A, deposit = 1, fissure = 1, link = 1, flow = from, adj_deposit = 1.1.3,
  adj_fissure = 1.1.1.
Caused by error in `nth()`:
! unused argument (na_rm = na_rm)
Backtrace:
 ▆
  1. ├─StatFlow$compute_panel(data) at test-stat-flow.r:78:2
  2. │ └─ggalluvial (local) compute_panel(..., self = self)
  3. │   └─dplyr::summarize_at(data, "lode", distill)
  4. │ 

Bug#1031298: ITP: pyproject-api -- API to interact with Python pyproject.toml-based projects

[Faidon Liambotis]

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

* Package name: pyproject-api
  Version : 1.5.0
  Upstream Author : Bernát Gábor 
* URL : https://github.com/tox-dev/pyproject-api
* License : Expat
  Programming Lang: Python
  Description : API to interact with Python pyproject.toml-based projects

  pyproject-api aims to abstract away interaction with pyproject.toml
  style projects in a flexible way.

pyproject-api is a new dependency of tox, in the 4.x series, currently
slated for experimental. I intend to maintain this package as part of
the DPT.

The package is trivial, but if anyone is interested in helping maintain
it, or with tox's maintenance, you're more than welcome!

Bug#1017921: mpd tries to start on non-interactive sessions

[Antoine Beaupré]

On 2023-02-14 18:27:02, kal...@debian.org wrote:

[...]

> I suggest to close this bug.
> Would it be fine with you ?

As you wish, of course. :)

Bug#1031297: diffoscope: autopkgtest regression due to unavailable Recommends on several architectures

[Adrian Bunk]

Source: diffoscope
Version: 235
Severity: serious

Issues preventing migration:
∙ ∙ autopkgtest for diffoscope/235: amd64: Pass, arm64: Pass, armel: Regression 
♻ (reference ♻), armhf: Pass, i386: Pass, ppc64el: Regression ♻ (reference ♻), 
s390x: Regression ♻ (reference ♻)


pytest-with-recommends FAIL badpkg
blame: diffoscope
badpkg: Test dependencies are unsatisfiable. A common reason is that your 
testbed is out of date with respect to the archive, and you need to use a 
current testbed or run apt-get update or use -U.




aapt   | 1:10.0.0+r36-10 | unstable| amd64, arm64, armel, 
armhf, i386, mips64el, mipsel
dexdump| 11.0.0+r48-5  | unstable | amd64, arm64, armhf, i386

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Daniel Leidert]

Am Dienstag, dem 14.02.2023 um 12:34 -0500 schrieb Theodore Ts'o:
> 
[..]
> In any case, a version of grub that will support the csum_seed feature
> will be landing in Bookworm in just a few days.  So at that point,
> you'll be able to create VM images for Bookworm and Sid that will work
> with the e2fsprogs in sid.  The current plan of record is that it will
> only be at that point that e2fsprogs will be allowed to migrate into
> Bookworm.

As soon as this version hits testing, you have successfully disabled
the last working environment to use vmdb2 to create images of Ubuntu
and Debian. As soon as this version hits Testing, one then can no
longer build images for either any Ubuntu release nor Debian Bullseye
or older. I can then only build images for Bookworm and Sid. Please
think about that.

You *seriously* break the debootstrap method of installing Debian or
Ubuntu. vmdb2 ist just another tool that is broken by now, a tool that
I use very often. I explained the impacts of what you are doing often
enough now. By now the impact should be clear. And you are still not
dealing with the aftermath of your intended action?! You haven't done a
proper transition. You haven't given any affected toolchain the
necessary time to adopt. You haven't documented how to disable that
breaking change when creating filesystems for distributions where grub
does not support this (there is not even a NEWS entry). You haven't
even announced that breaking change. And yet you are going to break one
of our two standard methods of installing Debian or Ubuntu. How is any
of what you have been saying so far addressing any of these issues? 

> [..]
> By the way, in the case of the csum_seed feature, it's pretty
> straightforward to just run "tune2fs -O ^metadata_csum_seed
> /tmp/boot.img".  If the UUID has been changed since the file system
> was created, you'll have to do this while the file system is
> unmounted
> and it will take a few seconds, but that's almost certainly not the
> case with vmdb2.

Well, how do you intend to distribute that information, so people who
have to use the deboostrap method to install a Debian or Ubuntu release
with a grub not supporting csum_seed (basically all existing releases,
except for the upcoming Bookworm) know that?

I do not understand why you are pushing 1.47.0 over 1.46.6, which you
had uploaded just five days before the former. You haven't even
presented a reason yet.

Regards, Daniel

Bug#1018023: Update on this bug?

[Jose Antonio Jimenez Madrid]

Thanks Matthew for the links.

I will test this patch and let you to know whether the bug is fixed.

Sincerely,
Jose

Matthew Vernon wrote:
> Hi,
>
> Do you have plans to fix this before the bookworm freeze, please?
>
> I think netbsd at least have patched eterm to work with the newer
> imlib; at least per the comment here
> https://github.com/mej/Eterm/issues/4
>
> That linked to
> http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/eterm/patches/
>
> Which has a couple of patches that seem like they'd do the trick...
>
> Thanks,
>
> Matthew

Bug#1031120: does not reset hyperlinks with -R

[Marco d'Itri]

On Feb 12, Marco d'Itri  wrote:

> Package: less
> Version: 590-1.1
> Severity: normal
> 
> When using less -R it does not correctly reset the hyperlink escape 
> sequences (i.e. "ESC]8;;"), causing the hyperlink to be extended to the 
> following terminal output.

While this looks quite similar to the issue described in #1030825, of
which I was not aware when I filed this bug, it is not fixed in less
590-1.2.
Does this issue too have security implications?

> This can be partially reproduced with something like:
> 
> printf 
> "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\e]8;;file://localhost/usr/share/initramfs-tools/scripts/init-top/udev\a/usr/share/initramfs-tools/scripts/init-top/udev
>  we need a longer line... 
> /usr/share/initramfs-tools/scripts/init-top/udev\e]8;;\a\n\n\n\n\n\n\n\n" | 
> less -RS
> 
> in gnome-terminal.
> 
> In this case the link will affect only the less interface, but when 
> using bootctl I can reliably make the link stay open even after quitting 
> less.
> 
> Using -S is not a requirement to reproduce this, it just makes it 
> easier: the bug is also triggered by quitting less when the first line 
> of a multiline link is the bottom line in the screen.
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
> Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages less depends on:
> ii  libc6  2.36-8
> ii  libtinfo6  6.4-2
> 
> less recommends no packages.
> 
> less suggests no packages.
> 
> -- no debconf information
> 
> -- 
> ciao,
> Marco



-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1031296: sccache FTBFS (on non-i386 32bit?)

[Adrian Bunk]

Source: sccache
Version: 0.4.0~~pre7-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=sccache=0.4.0%7E%7Epre7-1

...
[io-lifetimes 0.7.2] error[E0554]: `#![feature]` may not be used on the stable 
release channel
[io-lifetimes 0.7.2]  --> :1:1
[io-lifetimes 0.7.2]   |
[io-lifetimes 0.7.2] 1 | #![feature(rustc_attrs)]
[io-lifetimes 0.7.2]   | 
[io-lifetimes 0.7.2] 
[io-lifetimes 0.7.2] error: aborting due to previous error
[io-lifetimes 0.7.2] 
[io-lifetimes 0.7.2] For more information about this error, try `rustc 
--explain E0554`.
...

Bug#1031295: pcp fails to install without systemd

[Adrian Bunk]

Package: pcp
Version: 6.0.2-1
Severity: serious

https://piuparts.debian.org/sid/fail/pcp_6.0.2-1.log

...
Setting up pcp (6.0.2-1) ...
  /var/lib/dpkg/info/pcp.postinst: 242: systemctl: not found
  dpkg: error processing package pcp (--configure):
   installed pcp package post-installation script subprocess returned error 
exit status 127
  Processing triggers for libc-bin (2.36-8) ...
  Errors were encountered while processing:
   pcp
  E: Sub-process /usr/bin/dpkg returned an error code (1)

Bug#1031294: doc-debian: misspelled "Control: forwarded"

[Jakub Wilk]

Package: doc-debian
Version: 6.5

bug-reporting.txt gives the following example:

Control: forward -1 https://bugs.debian.org/nnn

This should be "forwarded", not "forward".

It's been already fixed on the website: #863069

--
Jakub Wilk

Bug#1031293: python3-zstandard 0.19.0-3 supports only libzstd 1.5.2

[Adrian Bunk]

Package: python3-zstandard
Version: 0.19.0-3
Severity: serious
Control: affects -1 src:libzstd src:rpmlint

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-zstandard/31313975/log.gz

...
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/zstandard/__init__.py", line 39, in 

from .backend_c import *  # type: ignore

ImportError: zstd C API versions mismatch; Python bindings were not 
compiled/linked against expected zstd version (10504 returned by the lib, 10502 
hardcoded in zstd headers, 10502 hardcoded in the cext)
...


Due to
https://sources.debian.org/src/python-zstandard/0.19.0-3/c-ext/backend_c.c/#L155

Please remove this version check, it is not supportable and does not
seem to be necessary in practice:
https://github.com/indygreg/python-zstandard/commit/964141349479070486ea25253bd4cc106929b2fc
https://github.com/indygreg/python-zstandard/commit/a1c567edd15cb735f1ae8b91fd994db2fe39f19b

Bug#801065: Documenting how to not fail postinst on service fails to start

[Steve Langasek]

On Mon, Feb 13, 2023 at 09:03:34AM -0500, Marvin Renich wrote:
> * Steve Langasek  [230212 00:03]:
> > FWIW I think that it's the wrong thing to do if the "circumstances" include
> > reverse-dependencies on the package which expect to interact with the
> > service the package provides, as these packages may themselves do such
> > interaction in the maintainer script, resulting in cascading damage.

> > And the decision for whether there are reverse-dependencies on your package
> > is non-local and asynchronous.

> > Therefore I think it's always wrong for a package's postinst to exit 0 if:

> >  - it ships a service,
> >  - it is a new install or an upgrade on a system where the service was
> >previously started successfully, and
> >  - the service fails to start in the postinst.

> I have to strongly disagree with this.  Suppose package A ships a
> service, and package B depends on A and requires A's service to be
> running in order for package B to be useful.  If I install A and disable
> its service, and then install B, I would be very disappointed if B's
> postinst script failed and left B in what dpkg considers an unconfigured
> state.

> Succeeding the install and requiring the user to manually run some
> documented configuration steps is _so_ much more user friendly than
> leaving a broken package (from dpkg's POV).  I intentionally disabled A,
> so when I want to use B, I will take the necessary steps.  I would
> expect that attempting to use B without completing the configuration
> would produce a useful error message.

Up until now the conversation has been about the semantics of exit codes for
package A's maintainer script.

You are now arguing that a package *B* is not allowed to fail on install if
the conditions for its full configuration have not been met.

And I absolutely disagree!  Your rationale that it's user-unfriendly to
leave a package in an unconfigured state, if followed to its logical
conclusion, applies to *any* package.  We might as well not care about
postinst exit codes at all!

This is not hyperbolic.  By imposing restrictions on the ability of packages
to raise error conditions, you are forcing the propagation of erroneous
system state up the dependency stack, breaking untold numbers of assumptions
in the reverse-dependencies.  Keeping the error handling *local* and forcing
the admin to correct the error before proceeding is part of what makes
Debian's system robust.

On 'apt dist-upgrade', having a failing maintainer script can be problematic
wrt the package manager's full state.  But there is no such counterargument
wrt robustness for the simple case of an 'apt install foo' failing its
initial configuration because the system preconditions are not met.

> Package relationships and the idea of "properly configured" have gotten
> much more complex (in a relatively small set of packages) since early
> Debian days.  Packages whose configuration has complex requirements
> should be installable without complete configuration and should be
> resilient and provide good user feedback when run before being properly
> set up.

> I also think that such packages are the exception, rather than the rule,
> and they are usually being administered by people capable of dealing
> with postponing the configuration step.

They are also capable of dealing with 'apt -f install'.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#557730: /etc/{protocols,network,services} not schroot's to scribble over

[Ian Jackson]

Wookey writes ("Re: Bug#557730: /etc/{protocols,network,services} not schroot's 
to scribble over"):
> On 2023-02-14 16:02 +, Ian Jackson wrote:
> > The fake netbase.deb could be contained within schroot.deb, in
> > /usr/share, so schroot wouldn't need to gain runtime build-deps on
> > dpkg tooling.
> 
> Except that it has to build this package live in order to contain the
> /etc/protocols and /etc/services files from the host
> environment. Having these default files with standard contents in a
> pre-built .deb is pointless, isn't it?

No, I thinko it's fine.  They mostly contain standardised constants.

schroot could build-depend on netbase and copy the files from there,
or just have fixed copies which would be updated manually once a
release or something.

These files, especially services, do change, but it is rare for
low-level basic things (or build systems) to actually depend on the
new entries.

> > > Whilst having the passwd database reflected in the chroot is
> > > incredibly useful it's not clear how often the services and protocols
> > > are needed, but I assume people do find that functionality useful.
> > 
> > I had a package that failed its build-time tests due to lack of
> > /etc/protocols.  The missing build-dep was detected in the buildds,
> > because my own local sid build chroot has netbase installed, precisely
> > because of this bug.
> 
> Right, which gets back to having a proper minimal environment used by
> sbuild to do a clean build. I have that (and it doesn't mount home,
> using the 'sbuild' profile). I use it once things are working
> reasonably well to get at least one clean build before uploading. This
> bug is a problem in the 'less clean, but more useful' 'default' chroot
> environment which is best for diagnostic work and builds of various
> sorts where some file persistence (of user files) is needed.

IME having a somewhat-dirty build environment is both convenient and
not a problem.

For example, my own sid chroot which *does* mount /home and import my
passwd and so on, reproducibily-builds the same .debs as the buildds
even for src:xen, whose build system is hardly straightforward.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#982099: lxpanel: randomly fails to display one of the configured launchers

[Francesco Poli]

On Sun, 9 May 2021 12:04:38 +0200 Francesco Poli wrote:

[...]
> Hello again,
> any news on bug [#982099]?
> 
> [#982099]: 
[...]

For anyone else who is experiencing this same bug, I seem to have found
a workaround: the trick is to create one separate Application Launch
Bar for each application launcher you need to define.

After applying this trick, each configured launcher seems to be always
displayed, without any issues...

The resulting panel configuration is something like:

  $ cat ~/.config/lxpanel/default/panels/panel 
  # lxpanel  config file. Manually editing is not recommended.
  # Use preference dialog in lxpanel to adjust config when you can.
  
  Global {
edge=bottom
allign=left
margin=275
widthtype=percent
width=100
height=28
transparent=1
tintcolor=#dcdad5
alpha=255
setdocktype=1
setpartialstrut=1
usefontcolor=1
fontcolor=#10394d
usefontsize=0
fontsize=10
background=0
backgroundfile=/usr/share/lxpanel/images/background.png
align=right
  }
  Plugin {
type=launchbar
Config {
  Button {
id=uxterm-start-login.desktop
  }
}
  }
  Plugin {
type=launchbar
Config {
  Button {
id=xscreensaver-lock-screen.desktop
  }
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=pager
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=taskbar
Config {
  ShowAllDesks=0
  MaxTaskWidth=150
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=tray
Config {
}
  }
  Plugin {
type=space
Config {
  Size=10
}
  }
  Plugin {
type=dclock
Config {
  ClockFmt=%R
  TooltipFmt=%a, %d %b %Y
  BoldFont=1
  IconOnly=0
  CenterText=1
}
  }
  Plugin {
type=space
Config {
  Size=5
}
  }


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpVjUI2yMSOZ.pgp
Description: PGP signature

Bug#1030846: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Theodore Ts'o]

There is another issue with vmdb2 if you are using XFS.  Starting with
xfsprogs 5.15 (which is already in testing), bigtime is enabled by
default, so that newly created XFS file systems won't be subject to
timestamp overflow in 2038.  Grub didn't land support for this feature
until 8b1e5d1936ff ("fs/xfs: Add bigtime incompat feature support") in
May 2021, despite the fact that XFS has had this feature for years and
years and years.

So if you aren't using the latest security fixes, and you are using
XFS as the boot partition --- it won't work on buster and bullseye.
"Fortunately", there were were massive number security vulnerabilities
in grub2 which forced a backport of grub2 2.06 to bullseye and buster,
so if you have the security updates enabled, you'll probably be OK ---
but it was only because of massive number of security problems forced
that backport.


In any case, a version of grub that will support the csum_seed feature
will be landing in Bookworm in just a few days.  So at that point,
you'll be able to create VM images for Bookworm and Sid that will work
with the e2fsprogs in sid.  The current plan of record is that it will
only be at that point that e2fsprogs will be allowed to migrate into
Bookworm.

For slowly moving upstreams like grub2, distributions *have* to take
updates before grub2 finally gets around to doing a release --- to get
security fixes if nothing else!  The support for csum_seed has been in
Fedora and other distributions for a while, since the patches had
landed in grub2 in June 2021.  I probably should have made sure the
feature had landed in Debian's grub2 packaging earlier; that's my bad,
and my apologies for that.

Note that Debian's grub2 has well over 100 patches, nearly all of
which are backports from grub2's git repo.  So the argument that
"there doesn't exist a formally released grub2 release" isn't
particularly compelling, since all the distros are backporting
patches.  The only question is how *many* commits release has an
individual distribution taken.


By the way, in the case of the csum_seed feature, it's pretty
straightforward to just run "tune2fs -O ^metadata_csum_seed
/tmp/boot.img".  If the UUID has been changed since the file system
was created, you'll have to do this while the file system is unmounted
and it will take a few seconds, but that's almost certainly not the
case with vmdb2.

   - Ted

Bug#1014782: xscreensaver: fails to activate via "Preview" button or via "Blank after" setting

[Aaron Rainbolt]

On 2/14/23 05:25, Jonathan Dowland wrote:

On Sat, Jan 21, 2023 at 09:26:03PM -0600, Aaron Rainbolt wrote:
If the XScreenSaver configuration file is included as a part of the 
core xscreensaver package itself, as a file that is simply unpacked, 
the following situation will result:

…
If the configuration file is split out into its own separate 
xscreensaver-config package

…

This is totally orthogonal to a solution to the bug reporter's issue.
Splitting the xscreensaver package up and shipping the same files in
different sub-packages and adding alternatives or other metapackage
complications will do nothing to solve their problem.

Your motivation for all that extra complexity is also orthogonal to
Debian: you're talking about an enhancement for Ubuntu. As it stands,
you're talking about making Debian worse to make Ubuntu better, and
that's a hard sell.


I don't really understand the purpose of this message - the bug report 
is closed and a solution was already uploaded.


--
Aaron Rainbolt
Lubuntu Developer
https://github.com/ArrayBolt3
https://launchpad.net/~arraybolt3
@arraybolt3:lubuntu.me on Matrix, arraybolt3 on irc.libera.chat



OpenPGP_0x6169B9B4248C0464.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031154: prelude-manager could not load pgsql plugin

[Krzysztof Jastrzębski]

Package: prelude-manager
Version: 5.2.0-2

Under Centos-like distros, postgres backend is usable.

EPEL RPM:
preludedb-pgsql.x86_64  5.2.0-2.el9  @epel

[root@rocky ~]# rpm -ql preludedb-pgsql | grep pgsql.so
/usr/lib64/libpreludedb/plugins/sql/pgsql.so
Above driver is found by prelude-manager, loaded and used.
So if same upstrem sources were used, maybe problem is with Debian 
libpq-dev package?


BTW: also trying pgsql driver with prewikka Debian package ends with:
/usr/lib/x86_64-linux-gnu/libpreludedb/plugins/sql/pgsql: file not found.
(also in 5.2.0-2 version under bookworm)

Centos is not planned - good to see prelude at production...

--
Pozdrawiam Krzysztof Jastrzębski <><
krzysztof[at]jastrzebscy[dot]pl http://www.jastrzebscy.pl/

Bug#1017921: mpd tries to start on non-interactive sessions

[kaliko]

Hi Antoine,

Le 24/08/2022 à 14:54, Antoine Beaupré a écrit :

[…]
In any case, I think you're right this might not be an actual bug,
although I can't help but think that the [Install] block could target
graphical-session.target instead of default.target, which would possibly
remove a lot of those problems in the future.


Actually my use of MPD requires default.target for users mpd service.
I'm sharing a server with a friend, we both run our own instance of MPD 
to stream music through icecast (and we only have a shell to manage our 
accounts, no graphical env.).


I've always seen MPD as an audio player for advanced *nix users, I don't 
think we should make it too much "foolproof". I believe the current 
defaults for user/system services are a good trade off: user service 
disabled and system service enabled/started. It's well documented both 
in /usr/share/doc/mpd and on the https://wiki.debian.org/mpd


I suggest to close this bug.
Would it be fine with you ?
Cheers
k

ps: sorry for this late reply

Bug#1031292: lvm2: Please ship the lvmautoactivation man page

[Ferenc Wágner]

Package: lvm2
Version: 2.03.11-2.1
Severity: normal

Dear Maintainer,

The lvmautoactivation(7) man page is missing from the lvm2 binary
package.  Please consider looking for other possible omissions as well.
-- 
Thanks,
Feri.

Bug#1004588: libzip: New upstream release (1.8.0, 2021 Jun 18)

[Florian Ernst]

Control: retitle -1 libzip: New upstream release (1.9.2, 2022 Jun 28)

Dear maintainer,

by now there are several new upstream releases available, cf.
.

The additional changes contain

| libzip 1.9.2
| June 28, 2022
| Fix version number in header file.
| 
| libzip 1.9.1
| June 28, 2022
| Fix zip_file_is_seekable().
| 
| libzip 1.9.0
| June 13, 2022
| Add zip_file_is_seekable().
| Improve compatibility with WinAES.
| Fix encoding handling in zip_name_locate().
| Add option to zipcmp to output summary of changes.
| Various bug fixes and documentation improvements.

which seem nice enough to eventually have in Debian.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1027706: gourmand: Instructions not saved

[Christian Marillat]

On 14 févr. 2023 18:07, "thierry.jeanmou...@cegetel.net" 
 wrote:

> I guess they are automatically installed by apt (see below)
> If more updates are needed, I'd rather not break my system, and wait
> for the new version in testing.

The best is to test the unstable package now. Broken package in unstable
will never enter testing if broken as we are in the freeze period.

Christian

Bug#1031291: uchardet: New upstream release (0.0.8, 2022-12-08)

[Florian Ernst]

Source: uchardet
Version: 0.0.7-1
Severity: wishlist

Dear maintainer,

there is a new upstream release available, cf.
:

| - New supports:
|   * Norwegian: IBM865, ISO-8859-1, ISO-8859-15 and WINDOWS-1252.
|   * Danish: IBM865.
| - Minimum CMake version bumped to 3.1 (requirement was 2.8.5 before) to
|   have CMake exported targets:
|   * The executable uchardet::uchardet
|   * The library uchardet::libuchardet
|   * The static library uchardet::libuchardet_static
| - Fix build issues for UWP on Windows.
| - Add uchardet CLI tool building support for MSVC.
| - Various bug fixes and docs/README tweaks.

Please update the package when you think it is due time.

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1031290: python-django: CVE-2023-24580 (denial-of-service vulnerability in file uploads)

[Chris Lamb]

Package: python-django
Version: 1:1.11.29-1+deb10u6
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for python-django.

CVE-2023-24580[0]:

  Potential denial-of-service vulnerability in file uploads

  Passing certain inputs to multipart forms could result in too many
  open files or memory exhaustion, and provided a potential vector for
  a denial-of-service attack.

  The number of files parts parsed is now limited via the new
  DATA_UPLOAD_MAX_NUMBER_FILES setting.

  

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1031289: linux: Missing sound drivers (and speakup) in d-i on arm64

[Samuel Thibault]

Source: linux
Version: 6.1.8-1
Severity: normal
Tags: a11y d-i

Hello,

Some people on debian-accessibility wanted to install debian in arm64
under the utm wrapped qemu on Macos. The current installation images
however do not include sound drivers and speakup. Applying the attached
patch to d-i brings:

E: Unable to locate package sound-modules-6.1.0-4-arm64-di
E: Unable to locate package speakup-modules-6.1.0-4-arm64-di

and indeed, it seems these modules are getting built only for amd64,
686, mips, sh4.

Could we consider adding them on arm64 in the linux package?

Thanks,
Samuel

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

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

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/build/pkg-lists/cdrom/grub/gtk/arm64.cfg 
b/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
index 25992fbe8..def0e98d5 100644
--- a/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
+++ b/build/pkg-lists/cdrom/grub/gtk/arm64.cfg
@@ -5,7 +5,7 @@ event-modules-${kernel:Version}
 xserver-xorg-input-libinput-udeb
 xserver-xorg-video-fbdev-udeb
 
-#speakup-modules-${kernel:Version}
-#sound-modules-${kernel:Version}
-#console-setup-linux-fonts-udeb
-#espeakup-udeb
+speakup-modules-${kernel:Version}
+sound-modules-${kernel:Version}
+console-setup-linux-fonts-udeb
+espeakup-udeb
diff --git a/build/pkg-lists/netboot/gtk/arm64.cfg 
b/build/pkg-lists/netboot/gtk/arm64.cfg
index 25992fbe8..def0e98d5 100644
--- a/build/pkg-lists/netboot/gtk/arm64.cfg
+++ b/build/pkg-lists/netboot/gtk/arm64.cfg
@@ -5,7 +5,7 @@ event-modules-${kernel:Version}
 xserver-xorg-input-libinput-udeb
 xserver-xorg-video-fbdev-udeb
 
-#speakup-modules-${kernel:Version}
-#sound-modules-${kernel:Version}
-#console-setup-linux-fonts-udeb
-#espeakup-udeb
+speakup-modules-${kernel:Version}
+sound-modules-${kernel:Version}
+console-setup-linux-fonts-udeb
+espeakup-udeb

Bug#1027706: gourmand: Instructions not saved

[thierry.jeanmou...@cegetel.net]

I guess they are automatically installed by apt (see below)
If more updates are needed, I'd rather not break my system, and wait for 
the new version in testing.


$ sudo apt install gourmand/unstable
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait
Version choisie « 1.1.0+really1.1.0~rc3-2 » (Debian:unstable [all]) pour 
« gourmand »

Les paquets supplémentaires suivants seront installés :
  python3-isodate python3-recipe-scrapers
Les NOUVEAUX paquets suivants seront installés :
  python3-isodate python3-recipe-scrapers
Les paquets suivants seront mis à jour :
  gourmand

Le 14/02/2023 à 17:10, Christian Marillat a écrit :

On 14 févr. 2023 16:55, "thierry.jeanmou...@cegetel.net" 
 wrote:


This version crashes, maybe a compatibility issue with Bookworm.
Better wait till it's moved to testing.

Did you install all python packages dependencies ?

Christian