Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

[Paul Gevers]

Hi,

[reducing the people in CC, hope I didn't drop too many and those still 
there are interested]


On Mon, 29 May 2023 00:14:10 + Mathias Gibbens  
wrote:

  What version of lxcfs is currently installed on the ci.debian.net
machines? I'm guessing from the kernel version they've been upgraded to
bookworm, so lxcfs should be at 5.0.3-1, but I'd like to clarify that.


I just ran $(apt-cache show lxcfs | grep Version) on all the worker 
hosts and indeed they all run 5.0.3-1.



  lxcfs 5.0.3-1 does indeed include the referenced fix for upstream
issue #553, and has been in testing since 2023-01-22. If the CI
machines have that version installed, then I'd lean towards a related
but distinct issue than the one identified at the moment.


Is there more information I can get for you from one of the effected 
architectures?


Paul
PS: I missed former messages due to a minor mistake in my address, but 
I'm now subscribed.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036826: po4a: Escape sequence \c encountered. This is not completely handled yet.

[Helge Kreutzmann]

Hello Bjarni,
On Sun, May 28, 2023 at 09:37:46PM +, Bjarni Ingi Gislason wrote:
> On Sun, May 28, 2023 at 07:03:28AM +0200, Helge Kreutzmann wrote:
> > Hello Bjarni,
> > On Sat, May 27, 2023 at 04:12:07PM +, Bjarni Ingi Gislason wrote:
> > > On Sat, May 27, 2023 at 01:59:40PM +0200, Helge Kreutzmann wrote:
> > > >[...]
> > > > .BI \-f " program-file\fR,\fP "\c
> > > > .BI \-\^\-file " program-file"
> > >   This is a wrong use of '\c', as its purpose is to join the output of
> > > two macros _without_ an intervening space character.
> > > 
> > >   So remove ' ' and '\c', changing
> > > 
> > > .BI \-f " program-file\fR,\fP "\c
> > > 
> > >   to
> > > 
> > > .BI \-f " program-file\fR,\fP"
> > 
>   My change is wrong as I ignored the 'TP' macro, which uses only one
> (logical) line, but I made two physical lines.

>   The simples change is to join the two lines with an '\', and put the
> space after the comma (punctuation), so

.TP
.BI something\c
.BI somethingelse

needs to become
.TP
.BI something\
somethingelse

The problem is, that I use sed to fix this (until either upstream
fixes its man page or po4a has a workaround). (And I don't care about
space etc, the translator will need to make her own anyway.)

From trial and error I noticed the the second ".BI" does not cunfuse
po4a.

So I check if

.BI something\c → .BI something\

I unique enough to only apply to the two man pages using it and does
th trick.

Thanks for your efforts!

Greetings

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


signature.asc
Description: PGP signature

Bug#980079: Bug Report #980079: mumble-server start/stop scripts broken

[James Tuttle]

I ran into this issue last week on a brand-new install of Raspbian 'Bullseye' 
running on a RPi 3.  It essentially makes it impossible to control the daemon 
using normal systemd tools, and often results in multiple instances of murmurd 
running simultaneously.

All I did to run into it was install the OS, `apt upgrade` everything, install 
a handful of common packages (emacs-nox, screen, chrony; nothing exotic), then 
install mumble-server from the default Raspbian repos.  

Both the 'start on boot' and 'high priority' dpkg configuration options were 
enabled.

I didn't install, nor am I trying to use, any custom SSL certs (or SSL certs at 
all, except as they might be used in the default configuration).

I encountered the problem almost immediately, because after `apt install 
mumble-server` completed, the first thing I did was lightly edit 
/etc/mumble-server.ini and then attempt to restart the service:

# systemctl restart mumble-server.service
<-- APPROX. 4 MINUTES PASS... -->
Job for mumble-server.service failed because a timeout was exceeded.
See "systemctl status mumble-server.service" and "journalctl -xe" for 
details.

The journal contains, among other things, these lines:

mumble-server.service: Found left-over process 1469 (murmurd) in control
 group while starting unit. Ignoring.
This usually indicates unclean termination of a previous run, or service
 implementation deficiencies.

And it appears there are now two instances of murmurd:

# ps aux | grep murmurd
mumble-+   650  0.0  2.4  78920 23324 ?Sl   May28   0:06 
 /usr/sbin/murmurd -ini /etc/mumble-server.ini
mumble-+  5194  0.0  2.4  70700 23236 ?SMay28   0:03 
 /usr/sbin/murmurd -ini /etc/mumble-server.ini

And if I run `systemctl restart mumble-server` again, it will create a 3rd 
instance of murmurd and so on.

It's clear from reading about this issue that I'm not the first to run into it, 
and there appear to be a variety of solutions, but it's unclear what tradeoffs 
(if any) they involve.  It would really be ideal if the package just worked 
'out of the box' with sane defaults.

Happy to provide additional information as needed.

V/R,
James

Bug#992113: release-notes: Initial availability of Bazel build system in Debian

[Paul Gevers]

Hi Olek,

First and foremost, I'm sorry this bug report dropped completely from 
the radar during the major part of bullseye being stable.


On 11-08-2021 21:28, Olek Wojnar wrote:

If possible, please include the following in section 2.2 (What's new in the
distribution?) of the release notes for the following architectures:
amd64, arm64, ppc64el, s390x, ppc64, riscv64



2.2.x Initial availability of the Bazel build system
The [Bazel](https://bazel.build/) build system is available in Debian starting 
with this release. This is a bootstrap variant that will not include local 
versions of the extended Bazel ecosystem. However, the current package **does** 
provide identical functionality to core upstream Bazel, with the advantage of 
convenient Debian package management for the installation. While building 
Debian packages is not currently recommended, any software that supports Bazel 
builds should build normally using this Debian-native Bazel package. This 
includes build-time downloads of required dependencies.

The [Debian Bazel Team](https://salsa.debian.org/bazel-team/meta) is working to 
package an extensible version of Bazel for future Debian releases. This 
extensible version will allow additional components of the Bazel ecosystem to 
be included as native Debian packages. More importantly, this version will 
allow Debian packages to be built using Bazel. Contributions to the team are 
welcome!


We can still add it to the bullseye release notes. Should we do that still?

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Sebastiaan Couwenberg]

On 5/29/23 06:13, Vagrant Cascadian wrote:

On 2023-05-29, Sebastiaan Couwenberg wrote:

On 5/28/23 23:38, Vagrant Cascadian wrote:

That said, I think it really is the touch commands in debian/datumgrids*
as touch's timestamp modification is timezone dependent in many cases...

The attached patch fixes this by setting the TZ=UTC as an environment
variable in the debian/datumgrids*.shar files.

I also had success with a patch where the touch calls are done with
--date=${SOURCE_DATE_EPOCH} which also worked for me (as touch assumes
to be TZ=UTC in this case)... if that would be preferable, I can also
provide a patch for that.


Patching the shar files is not ideal, when their content is modified
these changes will be lost.

shar/unshar should be more likely be patched.

Does TZ=UTC also work when set in the environment? If so, that could be
passed to the unshar commands in d/rules.


I would expect that to work as well, which I though of shortly after
sending the updated patch... though did not yet test it!


Can you test that? Otherwise we'll have to upload to experimental.

Kind Regards,

Bas

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

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Vagrant Cascadian]

On 2023-05-29, Sebastiaan Couwenberg wrote:
> On 5/28/23 23:38, Vagrant Cascadian wrote:
>> That said, I think it really is the touch commands in debian/datumgrids*
>> as touch's timestamp modification is timezone dependent in many cases...
>> 
>> The attached patch fixes this by setting the TZ=UTC as an environment
>> variable in the debian/datumgrids*.shar files.
>> 
>> I also had success with a patch where the touch calls are done with
>> --date=${SOURCE_DATE_EPOCH} which also worked for me (as touch assumes
>> to be TZ=UTC in this case)... if that would be preferable, I can also
>> provide a patch for that.
>
> Patching the shar files is not ideal, when their content is modified 
> these changes will be lost.
>
> shar/unshar should be more likely be patched.
>
> Does TZ=UTC also work when set in the environment? If so, that could be 
> passed to the unshar commands in d/rules.

I would expect that to work as well, which I though of shortly after
sending the updated patch... though did not yet test it!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1032994: unblock: node-webpack/5.76.1+dfsg1+~cs17.16.16-1

[Yadd]

On 5/28/23 10:29, Graham Inggs wrote:

tags -1 + moreinfo

Hi Yadd

On Wed, 3 May 2023 at 04:51, Yadd  wrote:

here is the current debdiff (without the big removal of useless
discoveryjs-json-ext/benchmarks)


I removed the moreinfo tag before realizing this is exactly the same
as the first debdiff.

You seem to have missed this comment:

On Wed, 15 Mar 2023 at 22:15, Paul Gevers  wrote:

This doesn't look like a targeted fix, but rather seems to include much
more.

How about reverting and providing a fix only for that CVE please?


Hi,

instead of reverting and have a too long version 
(5.76.1+dfsg1+~cs17.16.16+really-5.75.0+dfsg+~cs17.16.14-1), if upload 
to bookworm is allowed, I'm able to push this debdiff.


Cheers,
Yadddiff --git a/debian/changelog b/debian/changelog
index 0053d7ee..a07dd9d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-webpack (5.75.0+dfsg+~cs17.16.14-1+deb12u1) bookworm; urgency=medium
+
+  * Team upload
+  * Avoid cross-realm objects (Closes: #1032904, CVE-2023-28154)
+
+ -- Yadd   Mon, 29 May 2023 07:53:16 +0400
+
 node-webpack (5.75.0+dfsg+~cs17.16.14-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2023-28154.patch 
b/debian/patches/CVE-2023-28154.patch
new file mode 100644
index ..2f651167
--- /dev/null
+++ b/debian/patches/CVE-2023-28154.patch
@@ -0,0 +1,80 @@
+Description: avoid cross-realm objects
+Author: Jack Works 
+Origin: upstream, https://github.com/webpack/webpack/commit/4b4ca3bb
+Bug: https://www.cve.org/CVERecord?id=CVE-2023-28154
+Bug-Debian: https://bugs.debian.org/1032904
+Forwarded: not-needed
+Applied-Upstream: 5.76.1, commit:4b4ca3bb
+Reviewed-By: Yadd 
+Last-Update: 2023-05-29
+
+--- a/lib/dependencies/ImportParserPlugin.js
 b/lib/dependencies/ImportParserPlugin.js
+@@ -137,7 +137,7 @@
+   if (importOptions.webpackInclude !== undefined) 
{
+   if (
+   !importOptions.webpackInclude ||
+-  
importOptions.webpackInclude.constructor.name !== "RegExp"
++  !(importOptions.webpackInclude 
instanceof RegExp)
+   ) {
+   parser.state.module.addWarning(
+   new 
UnsupportedFeatureWarning(
+@@ -146,13 +146,13 @@
+   )
+   );
+   } else {
+-  include = new 
RegExp(importOptions.webpackInclude);
++  include = 
importOptions.webpackInclude;
+   }
+   }
+   if (importOptions.webpackExclude !== undefined) 
{
+   if (
+   !importOptions.webpackExclude ||
+-  
importOptions.webpackExclude.constructor.name !== "RegExp"
++  !(importOptions.webpackExclude 
instanceof RegExp)
+   ) {
+   parser.state.module.addWarning(
+   new 
UnsupportedFeatureWarning(
+@@ -161,7 +161,7 @@
+   )
+   );
+   } else {
+-  exclude = new 
RegExp(importOptions.webpackExclude);
++  exclude = 
importOptions.webpackExclude;
+   }
+   }
+   if (importOptions.webpackExports !== undefined) 
{
+--- a/lib/javascript/JavascriptParser.js
 b/lib/javascript/JavascriptParser.js
+@@ -3635,17 +3635,27 @@
+   return EMPTY_COMMENT_OPTIONS;
+   }
+   let options = {};
++  /** @type {unknown[]} */
+   let errors = [];
+   for (const comment of comments) {
+   const { value } = comment;
+   if (value && webpackCommentRegExp.test(value)) {
+   // try compile only if webpack options comment 
is present
+   try {
+-  const val = 
vm.runInNewContext(`(function(){return {${value}};})()`);
+-  Object.assign(options, val);
++  for (let [key, val] of Object.entries(
++  

Bug#1036023: same problem on armhf

[Joey Hess]

I rebuilt cabal-install from source, turning off the lukko build
flag, and confirmed that fixed this problem.

My recommendation would be to just do that for now, until lukko gets
fixed.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Nick Hastings]

* Mario Limonciello  [230529 10:14]:
> On 5/28/23 19:56, Nick Hastings wrote:
> > Hi,
> > 
> > * Mario Limonciello  [230528 21:44]:
> > > On 5/28/23 01:49, Salvatore Bonaccorso wrote:
> > > > Hi Mario
> > > > 
> > > > Nick Hastings reported in Debian in https://bugs.debian.org/1036530
> > > > lockups from his system after updating from a 6.0 based version to
> > > > 6.1.y. >
> > > > #regzbot ^introduced 24867516f06d
> > > > 
> > > > he bisected the issue and tracked it down to:
> > > > 
> > > > On Sun, May 28, 2023 at 10:14:51AM +0900, Nick Hastings wrote:
> > > > > Control: tags -1 - moreinfo
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > I repeated the git bisect, and the bad commit seems to be:
> > > > > 
> > > > > (git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
> > > > > 24867516f06dabedef3be7eea0ef0846b91538bc is the first bad commit
> > > > > commit 24867516f06dabedef3be7eea0ef0846b91538bc
> > > > > Author: Mario Limonciello 
> > > > > Date:   Tue Aug 23 13:51:31 2022 -0500
> > > > > 
> > > > >   ACPI: OSI: Remove Linux-Dell-Video _OSI string
> > > > >   This string was introduced because drivers for NVIDIA hardware
> > > > >   had bugs supporting RTD3 in the past.
> > > > >   Before proprietary NVIDIA driver started to support RTD3, 
> > > > > Ubuntu had
> > > > >   had a mechanism for switching PRIME on and off, though it had 
> > > > > required
> > > > >   to logout/login to make the library switch happen.
> > > > >   When the PRIME had been off, the mechanism had unloaded the 
> > > > > NVIDIA
> > > > >   driver and put the device into D3cold, but the GPU had never 
> > > > > come back
> > > > >   to D0 again which is why ODMs used the _OSI to expose an old 
> > > > > _DSM
> > > > >   method to switch the power on/off.
> > > > >   That has been fixed by commit 5775b843a619 ("PCI: Restore 
> > > > > config space
> > > > >   on runtime resume despite being unbound"). so vendors shouldn't 
> > > > > be
> > > > >   using this string to modify ASL any more.
> > > > >   Reviewed-by: Lyude Paul 
> > > > >   Signed-off-by: Mario Limonciello 
> > > > >   Signed-off-by: Rafael J. Wysocki 
> > > > > 
> > > > >drivers/acpi/osi.c | 9 -
> > > > >1 file changed, 9 deletions(-)
> > > > > 
> > > > > This machine is a Dell with an nvidia chip so it looks like this 
> > > > > really
> > > > > could be the commit that that is causing the problems. The description
> > > > > of the commit also seems (to my untrained eye) to be consistent with 
> > > > > the
> > > > > error reported on the console when the lockup occurs:
> > > > > 
> > > > > [   58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due to 
> > > > > previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > [   58.729904] ACPI Error: Aborting method \_SB.PCI0.PEG0.PG00._ON 
> > > > > due to previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
> > > > > [   60.083261] vfio-pci :01:00.0 Unable to change power state 
> > > > > from D3cold to D0, device inaccessible
> > > > > 
> > > > > Hopefully this is enough information for experts to resolve this.
> > > > 
> > > > Does this ring some bell for you? Do you need any further information
> > > > from Nick?
> > > > 
> > > > Regards,
> > > > Salvatore
> > > 
> > 
> > > Have Nick try using "pcie_port_pm=off" and see if it helps the issue.
> > 
> > I booted into a 6.1 kernel with this option. It has been running without
> > problems for 1.5 hours. Usually I would expect the lockup to have
> > occurred by now.

I let this run for 3 hours without issue.

> > > Does this happen in the latest 6.4 RC as well?
> > 
> > I have compiled that kernel and will boot into it after running this one
> > with the pcie_port_pm=off for another hour or so.

I'm now running 6.4.0-rc4 without seeing the problem after 1 hour.

I did however see two unrelated problems that I include here for
completeness:
1. iwlwifi module did not automatically load
2. Xwayland used huge amount of CPU even though was not running any X
programs. Recompiling my wayland compositor without XWayland support
"fixed" this.

> > > I think we need to see a full dmesg and acpidump to better
> > > characterize it.
> > 
> > Please find attached. Let me know if there is anything else I can provide.
> > 
> > Regards,
> > 
> > Nick.
> 
> I don't see nouveau loading, are you explicitly preventing it from
> loading?

Yes nouveau is blacklisted.

> Can I see the journal from a boot when it reproduced?

Hmm not sure which n for "journalctl -b n" maps to which kernel (is that
what you are requesting?). The commit hash doesn't not seem to be
listed. I may have to boot into a bad kernel again.

Regards,

Ncik.

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Sebastiaan Couwenberg]

On 5/28/23 23:38, Vagrant Cascadian wrote:

On 2023-05-08, Vagrant Cascadian wrote:

On 2023-05-09, Sebastiaan Couwenberg wrote:

On 5/9/23 05:47, Sebastiaan Couwenberg wrote:

On 5/8/23 22:43, Vagrant Cascadian wrote:

On 2023-05-08, Sebastiaan Couwenberg wrote:

On 5/8/23 02:07, Vagrant Cascadian wrote:

The attached patch fixes this by not touching these files during the
build process.


   From shar(1):

"
     -m, --no-timestamp
    do not restore modification times.

...

That should be used when generating the archives instead of your patch
to not have the mtimes touched when unpacking the archives.

...

But the diffoscope-results only show a few of the files from the shar
archives with different mtimes, and all of them get touched when
unpacking the archive just before the configure target is executed.


Well, I too was perplexed why other files were not affected, but it is
consistently those .gsb and .gtx files, and the submitted patch allows
to consistently build reproducibly in the dozens of times I've build
it...



shar actually makes the timestamps reproducible by always using the
mtime recorded in the archive instead of the time the files were
unpacked.

Something else is likely changing the mtime after the files are
unpacked. Some of these grids are used by the testsuite for example.


I will try to look into it further, but without really being familiar
with the proj codebase (or even what proj itself does)... any additional
very specific suggestions where to look next would definitely be
appreciated!  :)


CMake's configure_file() is used to copy the .gsb & .gtx files from
CMAKE_CURRENT_SOURCE_DIR to CMAKE_CURRENT_BINARY_DIR, that might be
touching the mtimes too. See: data/CMakeLists.txt


Thanks, that is definitely worth taking a look at...

...

Will try to poke at it more tomorrow...


I had no luck with poking at that approach... though did not have great
ideas what to even try there.

That said, I think it really is the touch commands in debian/datumgrids*
as touch's timestamp modification is timezone dependent in many cases...

The attached patch fixes this by setting the TZ=UTC as an environment
variable in the debian/datumgrids*.shar files.

I also had success with a patch where the touch calls are done with
--date=${SOURCE_DATE_EPOCH} which also worked for me (as touch assumes
to be TZ=UTC in this case)... if that would be preferable, I can also
provide a patch for that.


Patching the shar files is not ideal, when their content is modified 
these changes will be lost.


shar/unshar should be more likely be patched.

Does TZ=UTC also work when set in the environment? If so, that could be 
passed to the unshar commands in d/rules.


Kind Regards,

Bas

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

Bug#1036901: provide the erofsfuse binary as package

[Gao Xiang]

Hi!

On 2023/5/29 05:51, Norbert Lange wrote:

Package: erofs-utils
Version: 1.6-1
Severity: normal
Tags: patch
X-Debbugs-Cc: nolang...@gmail.com

Hello,

this tool is quite usefull, but it should be its own package.

I added a patch implementing this


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

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

Versions of packages erofs-utils depends on:
ii  libc62.36-9
ii  liblz4-1 1.9.4-1
ii  liblzma5 5.4.1-0.2
ii  libselinux1  3.4-1+b5
ii  libuuid1 2.38.1-5+b1

erofs-utils recommends no packages.

erofs-utils suggests no packages.


Thanks, I think we could upload it after new release is done.

Thanks,
Gao Xiang



-- no debconf information

Bug#1036902: logiops: Logid does not start, "[ERROR] Orphan Receiver, missing DeviceManager"

[Mikolaj Kuranowski]

Package: logiops
Version: 0.3.1-1
Severity: important
X-Debbugs-Cc: mkuranowski+debianb...@gmail.com

This issue affects the `logid` program, regardless of whether it's run as a
systemd unit; or standalone.

Running `sudo logid -v` gives the following output:

```
[DEBUG] Unsupported device /dev/hidraw0 ignored
[DEBUG] Ignoring virtual node on /dev/hidraw3
[DEBUG] Ignoring virtual node on /dev/hidraw4
[INFO] Detected receiver at /dev/hidraw1
[DEBUG] /dev/hidraw2: Device 0x0aa7 ignored.
[DEBUG] Failed to add device /dev/hidraw1:1 on try 1, backing off for 250ms
[ERROR] Orphan Receiver, missing DeviceManager
[ERROR] Fatal error, file a bug report. Program will now exit.
terminate called without an active exception
zsh: IOT instruction  sudo logid -v
```

There seems to be an upstream bug about this issue:
https://github.com/PixlOne/logiops/issues/371. This report mentions that the
file /usr/share/dbus-1/system.d/pizza.pixl.LogiOps.conf is missing. In fact,
this file is missing on my computer. Shouldn't the package include this file?


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.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 logiops depends on:
ii  libc6   2.36-9
ii  libconfig++9v5  1.5-0.4
ii  libevdev2   1.13.0+dfsg-1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libstdc++6  12.2.0-14
ii  libudev1252.6-1

logiops recommends no packages.

logiops suggests no packages.

-- Configuration Files:
/etc/logid.cfg changed:
ignore: [0x0aa7]
devices: (
{
name: "MX Keys Wireless Keyboard";
},
{
name: "Wireless Mouse MX Master 3";
smarthshift: { on: true; threshold: 35; };
hirresscroll: { hires: true };
buttons: (
// Gesture button
{
cid: 0xc3;
action: {
type: "Gestures";
gestures: (
{ direction: "Left"; action: { 
type: "Keypress"; keys: ["KEY_LEFTMETA", "KEY_PAGEUP"] }; },
{ direction: "Right"; action: { 
type: "Keypress"; keys: ["KEY_LEFTMETA", "KEY_PAGEDOWN"] }; },
{ direction: "Up"; action: { 
type: "Keypress"; keys: ["KEY_LEFTMETA"] }; },
{ direction: "Down"; action: { 
type: "Keypress"; keys: ["KEY_LEFTMETA", "KEY_V"] }; }
);
};
}
);
}
)


-- no debconf information

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Mario Limonciello]

On 5/28/23 19:56, Nick Hastings wrote:

Hi,

* Mario Limonciello  [230528 21:44]:

On 5/28/23 01:49, Salvatore Bonaccorso wrote:

Hi Mario

Nick Hastings reported in Debian in https://bugs.debian.org/1036530
lockups from his system after updating from a 6.0 based version to
6.1.y. >
#regzbot ^introduced 24867516f06d

he bisected the issue and tracked it down to:

On Sun, May 28, 2023 at 10:14:51AM +0900, Nick Hastings wrote:

Control: tags -1 - moreinfo

Hi,

I repeated the git bisect, and the bad commit seems to be:

(git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
24867516f06dabedef3be7eea0ef0846b91538bc is the first bad commit
commit 24867516f06dabedef3be7eea0ef0846b91538bc
Author: Mario Limonciello 
Date:   Tue Aug 23 13:51:31 2022 -0500

  ACPI: OSI: Remove Linux-Dell-Video _OSI string
  This string was introduced because drivers for NVIDIA hardware
  had bugs supporting RTD3 in the past.
  Before proprietary NVIDIA driver started to support RTD3, Ubuntu had
  had a mechanism for switching PRIME on and off, though it had required
  to logout/login to make the library switch happen.
  When the PRIME had been off, the mechanism had unloaded the NVIDIA
  driver and put the device into D3cold, but the GPU had never come back
  to D0 again which is why ODMs used the _OSI to expose an old _DSM
  method to switch the power on/off.
  That has been fixed by commit 5775b843a619 ("PCI: Restore config space
  on runtime resume despite being unbound"). so vendors shouldn't be
  using this string to modify ASL any more.
  Reviewed-by: Lyude Paul 
  Signed-off-by: Mario Limonciello 
  Signed-off-by: Rafael J. Wysocki 

   drivers/acpi/osi.c | 9 -
   1 file changed, 9 deletions(-)

This machine is a Dell with an nvidia chip so it looks like this really
could be the commit that that is causing the problems. The description
of the commit also seems (to my untrained eye) to be consistent with the
error reported on the console when the lockup occurs:

[   58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due to previous error 
(AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
[   58.729904] ACPI Error: Aborting method \_SB.PCI0.PEG0.PG00._ON due to 
previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
[   60.083261] vfio-pci :01:00.0 Unable to change power state from D3cold 
to D0, device inaccessible

Hopefully this is enough information for experts to resolve this.


Does this ring some bell for you? Do you need any further information
from Nick?

Regards,
Salvatore





Have Nick try using "pcie_port_pm=off" and see if it helps the issue.


I booted into a 6.1 kernel with this option. It has been running without
problems for 1.5 hours. Usually I would expect the lockup to have
occurred by now.


Does this happen in the latest 6.4 RC as well?


I have compiled that kernel and will boot into it after running this one
with the pcie_port_pm=off for another hour or so.


I think we need to see a full dmesg and acpidump to better
characterize it.


Please find attached. Let me know if there is anything else I can provide.

Regards,

Nick.


I don't see nouveau loading, are you explicitly preventing it from 
loading?  Can I see the journal from a boot when it reproduced?

Bug#1036818: linux on armel/armhf: Perl library unable to access get CPU info from /proc/cpu or kstat

[Mathias Gibbens]

  What version of lxcfs is currently installed on the ci.debian.net
machines? I'm guessing from the kernel version they've been upgraded to
bookworm, so lxcfs should be at 5.0.3-1, but I'd like to clarify that.

  lxcfs 5.0.3-1 does indeed include the referenced fix for upstream
issue #553, and has been in testing since 2023-01-22. If the CI
machines have that version installed, then I'd lean towards a related
but distinct issue than the one identified at the moment. If not, let's
upgrade lxcfs and see if that fixes the issue.

Mathias


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

Bug#932957: Please migrate Release Notes to reStructuredText

[James Addison]

Package: release-notes
Followup-For: Bug #932957
X-Debbugs-Cc: hwans...@mailbox.org

Oops - there were a couple of problems with my most recent message here:

  * Forgot to cc you on the details, Holger (in short summary: the ReST 'only'
directive[1] may be helpful here, and could be used with a '-t '
command-line option to sphinx-build from the Makefile)

  * I didn't read the documentation!  The tags for the 'only' directive must be
valid Python identifiers, so 'arch_i386' would work as a tag name, but
'arch-i386' (that I had suggested previously) would not.

[1] - 
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#including-content-based-on-tags

Bug#932957: Please migrate Release Notes to reStructuredText

[James Addison]

Package: release-notes
Followup-For: Bug #932957

> Yes, filtering the content for the different architectures does not work yet.

Ah, and I said I would help with that :)

Although I don't yet know exactly how it's going to interact with the build
process, I _think_ that a feature we could use for this is the 'only'
directive:

  
https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only

Although this could benefit from more thought, initially I suggest we adopt a
tag format something like 'arch-{debarch}' to handle this (so the conditional
clause here would be placed within a '.. only:: arch-i386' block.

>From there, we could pass the corresponding tag on the commandline using the
'-t' option, I guess in the Makefile:

  
https://salsa.debian.org/holgerw/release-notes/-/blob/a2ba839790573915a80db75405abf8ef9212ac8e/Makefile#L103

Bug#1036113: libpurple0: license conflict with libsasl2

[Bastian Germann]

Am 26.05.23 um 04:26 schrieb Richard Laager:

Are the problems just limited to MD5? If so:


I do not think so.


5) Replace the MD5 implementation in Cyrus SASL with a different one.

6) Cyrus SASL uses OpenSSL for MD5 instead of its built-in MD5 code.


See https://github.com/cyrusimap/cyrus-sasl/issues/513 for an implementation 
that leaves only one RSA-MD licensed file.

Bug#1036901: provide the erofsfuse binary as package

[Norbert Lange]

Package: erofs-utils
Version: 1.6-1
Severity: normal
Tags: patch
X-Debbugs-Cc: nolang...@gmail.com

Hello,

this tool is quite usefull, but it should be its own package.

I added a patch implementing this


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

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

Versions of packages erofs-utils depends on:
ii  libc62.36-9
ii  liblz4-1 1.9.4-1
ii  liblzma5 5.4.1-0.2
ii  libselinux1  3.4-1+b5
ii  libuuid1 2.38.1-5+b1

erofs-utils recommends no packages.

erofs-utils suggests no packages.

-- no debconf information
diff -burN erofs-utils_1.6-1.debian.orig/debian/control 
erofs-utils_1.6-1.debian/debian/control
--- erofs-utils_1.6-1.debian.orig/debian/control2023-03-11 
17:00:00.0 +0100
+++ erofs-utils_1.6-1.debian/debian/control 2023-03-11 17:00:00.0 
+0100
@@ -4,6 +4,7 @@
 Build-Depends:
  debhelper-compat (= 10),
  pkg-config,
+ libfuse-dev,
  liblz4-dev,
  liblzma-dev,
  libselinux1-dev,
@@ -27,3 +28,21 @@
  which improves storage density, keeps relatively higher
  compression ratios, which is more useful to achieve high
  performance for embedded devices with limited memory.
+
+Package: erofsfuse
+Architecture: linux-any
+Depends: ${misc:Depends}, ${shlibs:Depends}
+Description: FUSE Mount Utility for EROFS File System
+ EROFS (Enhanced Read-Only File System) is a lightweight
+ read-only file system with modern designs (eg. page-sized
+ blocks, inline xattrs/data, etc.) for scenarios which need
+ high-performance read-only requirements, e.g. Android OS
+ for smartphones and LIVECDs.
+ .
+ It also provides fixed-sized output compression support,
+ which improves storage density, keeps relatively higher
+ compression ratios, which is more useful to achieve high
+ performance for embedded devices with limited memory.
+ .
+ This package contains a utility to mount EROFS images
+ using FUSE.
diff -burN erofs-utils_1.6-1.debian.orig/debian/erofsfuse.install 
erofs-utils_1.6-1.debian/debian/erofsfuse.install
--- erofs-utils_1.6-1.debian.orig/debian/erofsfuse.install  1970-01-01 
01:00:00.0 +0100
+++ erofs-utils_1.6-1.debian/debian/erofsfuse.install   2023-03-11 
17:00:00.0 +0100
@@ -0,0 +1,2 @@
+usr/bin/erofsfuse
+usr/share/man/man1/erofsfuse.1
diff -burN erofs-utils_1.6-1.debian.orig/debian/erofs-utils.install 
erofs-utils_1.6-1.debian/debian/erofs-utils.install
--- erofs-utils_1.6-1.debian.orig/debian/erofs-utils.install1970-01-01 
01:00:00.0 +0100
+++ erofs-utils_1.6-1.debian/debian/erofs-utils.install 2023-03-11 
17:00:00.0 +0100
@@ -0,0 +1,2 @@
+usr/bin/*.erofs
+usr/share/man/man1/*.erofs.1
diff -burN erofs-utils_1.6-1.debian.orig/debian/rules 
erofs-utils_1.6-1.debian/debian/rules
--- erofs-utils_1.6-1.debian.orig/debian/rules  2023-03-11 17:00:00.0 
+0100
+++ erofs-utils_1.6-1.debian/debian/rules   2023-03-11 17:00:00.0 
+0100
@@ -6,8 +6,6 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 
-SKIP_FUSE2FS=yes
-
 COMMON_CONF_FLAGS = --with-uuid --with-selinux --enable-lzma \
${EXTRA_CONF_FLAGS}
 

Bug#1036826: po4a: Escape sequence \c encountered. This is not completely handled yet.

[Bjarni Ingi Gislason]

On Sun, May 28, 2023 at 07:03:28AM +0200, Helge Kreutzmann wrote:
> Hello Bjarni,
> On Sat, May 27, 2023 at 04:12:07PM +, Bjarni Ingi Gislason wrote:
> > On Sat, May 27, 2023 at 01:59:40PM +0200, Helge Kreutzmann wrote:
> > >[...]
> > > .BI \-f " program-file\fR,\fP "\c
> > > .BI \-\^\-file " program-file"
> >   This is a wrong use of '\c', as its purpose is to join the output of
> > two macros _without_ an intervening space character.
> > 
> >   So remove ' ' and '\c', changing
> > 
> > .BI \-f " program-file\fR,\fP "\c
> > 
> >   to
> > 
> > .BI \-f " program-file\fR,\fP"
> 
  My change is wrong as I ignored the 'TP' macro, which uses only one
(logical) line, but I made two physical lines.

  The simples change is to join the two lines with an '\', and put the
space after the comma (punctuation), so

.BI \-f " program-file\fR, \fP" \
\-\^\-file " program-file"

  One can construct a one line expression by including a temporary
roman font change in one of the arguments for a two-fonts macro.

  I find it is best to include the space with the punctuation, so

.BI \-f " program-file\fR, \fP" \-\^\-file " program-file"

> Thanks, this make the build proceed, however, now it dies in the
> following line:
> .TP
> .BI \-F " fs\fR, \fP"\c
> .BI \-\^\-field-separator " fs"
> 
> Escape sequence \c encountered. This is not completely handled yet.
> 
> Note that here there is no space before the "
> 
> Removing also this (and subsequent) "\c" makes the build proceed,
> however, in other files "\c" exists as well and I'm vary of removing
> the as well. 
> 
> I *think* the difference is that the failing lines have a ".BI" at the
> beginnig. (And the non failing do not.) Does this make sense to you?
> 

  Transform this to one line (as the arguments are of short length)

.TP
.BI \-F " fs\fR, \fP" \-\^\-field-separator " fs"

Bug#1035704: proj: reproducible-builds: timezone-dependent timestamps in .gsb/.gtx files

[Vagrant Cascadian]

On 2023-05-08, Vagrant Cascadian wrote:
> On 2023-05-09, Sebastiaan Couwenberg wrote:
>> On 5/9/23 05:47, Sebastiaan Couwenberg wrote:
>>> On 5/8/23 22:43, Vagrant Cascadian wrote:
 On 2023-05-08, Sebastiaan Couwenberg wrote:
> On 5/8/23 02:07, Vagrant Cascadian wrote:
>> The attached patch fixes this by not touching these files during the
>> build process.
>
>   From shar(1):
>
> "
>     -m, --no-timestamp
>    do not restore modification times.
...
> That should be used when generating the archives instead of your patch
> to not have the mtimes touched when unpacking the archives.
...
> But the diffoscope-results only show a few of the files from the shar
> archives with different mtimes, and all of them get touched when
> unpacking the archive just before the configure target is executed.

 Well, I too was perplexed why other files were not affected, but it is
 consistently those .gsb and .gtx files, and the submitted patch allows
 to consistently build reproducibly in the dozens of times I've build
 it...


> shar actually makes the timestamps reproducible by always using the
> mtime recorded in the archive instead of the time the files were 
> unpacked.
>
> Something else is likely changing the mtime after the files are
> unpacked. Some of these grids are used by the testsuite for example.

 I will try to look into it further, but without really being familiar
 with the proj codebase (or even what proj itself does)... any additional
 very specific suggestions where to look next would definitely be
 appreciated!  :)
>>> 
>>> CMake's configure_file() is used to copy the .gsb & .gtx files from 
>>> CMAKE_CURRENT_SOURCE_DIR to CMAKE_CURRENT_BINARY_DIR, that might be 
>>> touching the mtimes too. See: data/CMakeLists.txt
>
> Thanks, that is definitely worth taking a look at...
...
> Will try to poke at it more tomorrow...

I had no luck with poking at that approach... though did not have great
ideas what to even try there.

That said, I think it really is the touch commands in debian/datumgrids*
as touch's timestamp modification is timezone dependent in many cases...

The attached patch fixes this by setting the TZ=UTC as an environment
variable in the debian/datumgrids*.shar files.

I also had success with a patch where the touch calls are done with
--date=${SOURCE_DATE_EPOCH} which also worked for me (as touch assumes
to be TZ=UTC in this case)... if that would be preferable, I can also
provide a patch for that.


live well,
  vagrant
From 5e019591780bcf0b61511cc242d1636c9ec909ca Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 28 May 2023 12:54:59 -0700
Subject: [PATCH] debian/datumgrids*.shar: Use UTC timezone when touching
 files.

Without this, the touch calls result in timezone-specific differences
in various .gsb and .gtx files.

https://reproducible-builds.org/docs/timezones/
---
 debian/datumgrids-ch.shar | 4 
 debian/datumgrids.shar| 4 
 2 files changed, 8 insertions(+)

diff --git a/debian/datumgrids-ch.shar b/debian/datumgrids-ch.shar
index 308ca93..313a3c6 100644
--- a/debian/datumgrids-ch.shar
+++ b/debian/datumgrids-ch.shar
@@ -35,6 +35,10 @@ gettext_dir=
 locale_dir=
 set_echo=false
 
+# reproducible builds: Use UTC timezone to ensure consistent
+# timestamps on touched files.
+export TZ=UTC
+
 for dir in $PATH
 do
   if test -f $dir/gettext \
diff --git a/debian/datumgrids.shar b/debian/datumgrids.shar
index d9a0161..2dec48e 100644
--- a/debian/datumgrids.shar
+++ b/debian/datumgrids.shar
@@ -48,6 +48,10 @@ gettext_dir=
 locale_dir=
 set_echo=false
 
+# reproducible builds: Use UTC timezone to ensure consistent
+# timestamps on touched files.
+export TZ=UTC
+
 for dir in $PATH
 do
   if test -f $dir/gettext \
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1036023: same problem on armhf

[Joey Hess]

I'm experiencing the same bug on armhf with cabal-install 3.4.1.0-3.

My workaround was to downgrade it to 3.0.0.0-3+b1.

This may be a relevant upstream issue:
https://github.com/haskellari/lukko/issues/15

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#1036900: linux: "NETDEV WATCHDOG: enp3s0 (r8169): transmit queue 0 timed out"

[Christian]

Source: linux
Version: Linux 6.1.0-9
Severity: important
X-Debbugs-Cc: list-christ...@web.de

Dear Maintainer,

Building a new system, I encounter a problem -reproducible- when the system 
comes under load. As soon as it is more than idle (e.g. a compile),
I get the following exception, network goes down and SATA fails, rendering the 
system unusable.

Trace from my logs:

2023-05-28T17:51:04.834075+02:00 diskstation kernel: [ 2220.049106] 
[ cut here ]
2023-05-28T17:51:04.846514+02:00 diskstation kernel: [ 2220.049110] NETDEV 
WATCHDOG: enp3s0 (r8169): transmit queue 0 timed out
2023-05-28T17:51:04.846519+02:00 diskstation kernel: [ 2220.049118] WARNING: 
CPU: 5 PID: 0 at net/sched/sch_generic.c:525 dev_watchdog+0x207/0x210
2023-05-28T17:51:04.846520+02:00 diskstation kernel: [ 2220.049123] Modules 
linked in: xt_nat veth eq3_char_loop(OE) rpi_rf_mod_led(OE) ledtrig_timer 
ledtrig_default_on xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo 
xt_addrtype br_netfilter bridge stp llc overlay ip6t_rt nft_chain_nat nf_nat 
xt_set qrtr xt_tcpmss xt_tcpudp xt_conntrack nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 nft_compat nf_tables ip_set_hash_ip ip_set nfnetlink binfmt_misc 
nls_ascii nls_cp437 vfat fat amdgpu iwlmvm btusb btrtl btbcm btintel btmtk 
bluetooth snd_hda_codec_realtek mac80211 snd_hda_codec_generic ledtrig_audio 
snd_hda_codec_hdmi intel_rapl_msr intel_rapl_common snd_hda_intel gpu_sched 
edac_mce_amd libarc4 snd_intel_dspcfg drm_buddy snd_intel_sdw_acpi 
snd_hda_codec drm_display_helper iwlwifi snd_hda_core kvm_amd jitterentropy_rng 
cec snd_hwdep hb_rf_usb_2(OE) kvm rc_core cfg80211 generic_raw_uart(OE) snd_pcm 
drbg drm_ttm_helper irqbypass ttm ansi_cprng snd_timer rapl wmi_bmof 
ecdh_generic drm_kms_helper snd ccp pcspkr sp5100_tco rfkill i2c_algo_bit
2023-05-28T17:51:04.846522+02:00 diskstation kernel: [ 2220.049164]  soundcore 
k10temp ecc rng_core watchdog joydev evdev acpi_cpufreq button sg nct6775 
nct6775_core hwmon_vid drm msr fuse loop efi_pstore configfs efivarfs ip_tables 
x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic xor raid6_pq 
zstd_compress libcrc32c crc32c_generic dm_crypt dm_mod hid_generic usbhid hid 
sd_mod crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sha512_ssse3 
sha512_generic ahci nvme_core libahci xhci_pci t10_pi libata 
crc64_rocksoft_generic xhci_hcd aesni_intel r8169 crc64_rocksoft crc_t10dif 
realtek crct10dif_generic crypto_simd mdio_devres crct10dif_pclmul usbcore 
scsi_mod cryptd libphy crc64 i2c_piix4 crct10dif_common usb_common scsi_common 
video wmi gpio_amdpt gpio_generic
2023-05-28T17:51:04.846523+02:00 diskstation kernel: [ 2220.049196] CPU: 5 PID: 
0 Comm: swapper/5 Tainted: G   OE  6.1.0-9-amd64 #1  Debian 6.1.27-1
2023-05-28T17:51:04.846523+02:00 diskstation kernel: [ 2220.049199] Hardware 
name: To Be Filled By O.E.M. B550M-ITX/ac/B550M-ITX/ac, BIOS L2.62 01/31/2023
2023-05-28T17:51:04.846525+02:00 diskstation kernel: [ 2220.049200] RIP: 
0010:dev_watchdog+0x207/0x210
2023-05-28T17:51:04.846525+02:00 diskstation kernel: [ 2220.049202] Code: 00 e9 
40 ff ff ff 48 89 df c6 05 ff 5f 3d 01 01 e8 be 79 f9 ff 44 89 e9 48 89 de 48 
c7 c7 c8 16 7b 87 48 89 c2 e8 09 d2 86 ff <0f> 0b e9 22 ff ff ff 66 90 0f 1f 44 
00 00 55 53 48 89 fb 48 8b 6f
2023-05-28T17:51:04.846526+02:00 diskstation kernel: [ 2220.049203] RSP: 
0018:b1e2802b8e80 EFLAGS: 00010286
2023-05-28T17:51:04.846526+02:00 diskstation kernel: [ 2220.049204] RAX: 
 RBX: 9ad241704000 RCX: 
2023-05-28T17:51:04.846527+02:00 diskstation kernel: [ 2220.049205] RDX: 
0104 RSI: 8773fa66 RDI: 
2023-05-28T17:51:04.846527+02:00 diskstation kernel: [ 2220.049206] RBP: 
9ad241704488 R08:  R09: b1e2802b8cf0
2023-05-28T17:51:04.846528+02:00 diskstation kernel: [ 2220.049207] R10: 
0003 R11: 9ad97e27afe8 R12: 9ad2417043dc
2023-05-28T17:51:04.846529+02:00 diskstation kernel: [ 2220.049208] R13: 
 R14: 86c2e7a0 R15: 9ad241704488
2023-05-28T17:51:04.846529+02:00 diskstation kernel: [ 2220.049209] FS:  
() GS:9ad95e34() knlGS:
2023-05-28T17:51:04.846530+02:00 diskstation kernel: [ 2220.049210] CS:  0010 
DS:  ES:  CR0: 80050033
2023-05-28T17:51:04.846530+02:00 diskstation kernel: [ 2220.049211] CR2: 
7f73a5a0b440 CR3: 0001089fa000 CR4: 00750ee0
2023-05-28T17:51:04.846531+02:00 diskstation kernel: [ 2220.049212] PKRU: 
5554
2023-05-28T17:51:04.846532+02:00 diskstation kernel: [ 2220.049213] Call Trace:
2023-05-28T17:51:04.846532+02:00 diskstation kernel: [ 2220.049214]  
2023-05-28T17:51:04.846533+02:00 diskstation kernel: [ 2220.049217]  ? 
pfifo_fast_reset+0x140/0x140
2023-05-28T17:51:04.846533+02:00 diskstation kernel: [ 2220.049219]  
call_timer_fn+0x27/0x130
2023-05-28T17:51:04.846534+02:00 diskstation kernel: [ 2220.049222]  

Bug#1036899: logiops: logid does not work for MX Master 3

[Hendrik Tews]

Package: logiops
Version: 0.3.1-1
Severity: important
X-Debbugs-Cc: none, Hendrik Tews 

Dear Maintainer,

after upgrading to logiops version 0.3.1-1 the logid daemon does not
seem to do anything any more. For my configuration the symptom is that
the thumb button is no longer mapped to button 2. The problem seems to
be also present in the current upstream version (v0.3.2), see upstream
issue 387 (https://github.com/PixlOne/logiops/issues/387).

For now I downgraded to 0.2.3-1+b1, which is still working fine.

Best regards,

Hendrik


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, 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 logiops depends on:
ii  libc6   2.36-9
ii  libconfig++9v5  1.5-0.4
ii  libevdev2   1.13.0+dfsg-1
ii  libgcc-s1   12.2.0-14
ii  libglib2.0-02.74.6-2
ii  libstdc++6  12.2.0-14
ii  libudev1252.6-1

logiops recommends no packages.

logiops suggests no packages.

-- Configuration Files:
/etc/logid.cfg changed:
devices: ({
  name: "Wireless Mouse MX Master 3";
  # A lower threshold number makes the wheel switch to free-spin mode
  # quicker when scrolling fast.
  smartshift: {
on: false;
threshold: 3;
  };
  hiresscroll: {
hires: true;
invert: false;
target: false;
  };
  # Higher numbers make the mouse more sensitive (cursor moves faster),
  # 4000 max for MX Master 3.
  dpi: 1000;
  buttons: (
# Make thumb button 2.
{ cid: 0xc3;
  action = {
type: "Keypress";
keys: ["BTN_MIDDLE"];
  };
},
# top button
{ cid: 0xc4;
  action = {
type = "ToggleSmartshift";
  };
}
  );
});


-- no debconf information

Bug#932957: Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

James Addison  wrote (Fri, 26 May 2023 13:02:53 +0100):
> I noticed one more problem with the output of the ReST release-notes:
> 
> Filtering of architecture-specific sections does not seem to be taking place,
> so the 'Supported Architectures'[1] section for AMD64 currently contains the
> text:
> 
>   The ARCH-TITLE support (known as the Debian architecture amd64) now 
> requires the “long NOP” instruction. Please refer to Baseline for 64-bit PC 
> is now i686 for more information.
> 
> (the ARCH-TITLE placeholder is probably a small fixup - the problem I'd like
> to draw attention to is the reference to 64-bit PC / amd64 as i686)
> 
> In the Docbook source, there is an 'arch="i386"' annotation[2] on the 
> section's
> XML element, so perhaps that is used to filter the content.

Yes, filtering the content for the different architectures does not work yet.
That's one open point, where I have requested help for.

I have fixed the forgotten ARCH-TITLE placeholder now.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

[James Addison]

Followup-For: Bug #1026277

On Sun, 28 May 2023 16:50:31 +0100, James wrote:
>   * My release signing has been inconsistent, partly because I'm not sure I
> have a long-term commitment to being a Debian Maintainer/Developer, and
> partly because I'm not sure I can reliably keep those keys secure (so, at
> best I think they would provide some integrity verification support, but
> I don't think they really attest highly that I'm the sole or uncompromised
> author).  Not a particularly useful mindset to have, some might argue, but
> it does lead to me towards using ephemeral keypairs (somewhere, once, I 
> had
> some web-of-trust identity, but I haven't continued to use or maintain 
> it).

In retrospect, I think this is probably an argument for exploring and learning
better signing practices rather than a packaging problem.

(also, to nitpick / clarify: when referring to authorship there, that was only
in reference to the packaging and edits made from the existing published open
source game engine code)

Bug#947685: still occuring on Linux 6.1.0-9-amd64 x86_64

[Ben Hutchings]

On Sun, 2023-05-28 at 21:22 +0200, Christian wrote:
> I am plagued with this on current Linux 6.1.0-9-amd64 x86_64.
> 
> As soon as load on the system increases, the error comes up and
> apparently it takes some other things (SATA) with it. Leaving the
> system workable, but slowly failing.
> 
> Happy to provide more information or test things.

Please open a new bug report.  Seeing the same message doesn't mean
you're seeing the same bug.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken


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

Bug#1014517: apt - Fails in FIPS mode in libgcrypt

[A. Maitland Bottoms]

So I see in the changes to libgcrypt since bullseye that there have
been some changes in the initialization on systems where FIPS is
enabled.

The attached patch has "works for me" status, and I feel that it is the
correct way to continue to have apt function as expected on a FIPS
enabled system.

I added a GCRYCTL_NO_FIPS_MODE setting in maybeInit() in
apt-pkg/contrib/hashes.cc
And, since the value of the enum GCRYCTL_NO_FIPS_MODE appeared just
before the release of libgcrypt 1.10.0, I added that version dependency
to the debian/control file.

Control: tag -1 patch

-Maitland

enc:
0001-Do-not-fail-on-systems-running-in-FIPSmode.patch

From 4df25d8781f56036e921792fdd48abd5f2084d98 Mon Sep 17 00:00:00 2001
From: "A. Maitland Bottoms" 
Date: Sun, 28 May 2023 15:12:36 -0400
Subject: [PATCH] Do not fail on systems running in FIPSmode.

Initialize using gcrypt's GCRYCTL_NO_FIPS_MODE, available since
gcrypt version 1.10.0, otherwise apt aborts on FIPS enabled systems.
---
 apt-pkg/contrib/hashes.cc | 3 +++
 debian/changelog  | 6 ++
 debian/control| 2 +-
 3 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/apt-pkg/contrib/hashes.cc b/apt-pkg/contrib/hashes.cc
index 313b1d37d..80b9bbf3f 100644
--- a/apt-pkg/contrib/hashes.cc
+++ b/apt-pkg/contrib/hashes.cc
@@ -330,6 +330,9 @@ public:
 	exit(2);
 	 }
 
+	 // It is OK for apt to use MD5.
+	 gcry_control(GCRYCTL_NO_FIPS_MODE, 0);
+
 	 gcry_control(GCRYCTL_INITIALIZATION_FINISHED, 0);
   }
}
diff --git a/debian/changelog b/debian/changelog
index 5961148d2..e279ad0d5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+apt (2.6.2) unstable; urgency=medium
+
+  * Do not fail on systems running in FIPSmode. (Closes: #1014517)
+
+ -- A. Maitland Bottoms   Sun, 28 May 2023 11:28:37 -0400
+
 apt (2.6.1) unstable; urgency=medium
 
   * Restore adduser dependency for bookworm.
diff --git a/debian/control b/debian/control
index 58c6be15e..6f3ceb81e 100644
--- a/debian/control
+++ b/debian/control
@@ -17,7 +17,7 @@ Build-Depends: cmake (>= 3.4),
libbz2-dev,
libdb-dev,
libgnutls28-dev (>= 3.4.6),
-   libgcrypt20-dev,
+   libgcrypt20-dev (>=1.10.0),
liblz4-dev (>= 0.0~r126),
liblzma-dev,
libseccomp-dev (>= 2.4.2) [amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el s390x hppa powerpc powerpcspe ppc64 x32],
-- 
2.39.2

Bug#932957: Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

Stéphane Blondon  wrote (Sun, 28 May 2023 13:16:24 
+0200):
> > > Richard Lewis  wrote (Fri, 19 May
> > 2023 00:58:26 +0100):
> >
> > > - are the red hyphens in eg the 'deb...' line near the top of
> > > >
> > https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html
> > > > meant to be red? (maybe it is a syntax error?)
> > >
> 
> 
> 
> Sphinx uses Pygments to highlight source code. I guess no language is
> defined so Sphinx uses a wrong lexer. We should force Sphinx to use
> 'SourceListLexer' with:
> .. code-block :: sources.list

The highlighting feature is great, thanks for pointing this out!
However, we cannot use it here in most cases for sources.list entries,
since resolving substitutions does not work within such lines :-(
like in
   deb https://deb.debian.org/debian |RELEASENAME| main contrib


But in many cases the highlighting gives us a great benefit, so I will
merge your MR and adapt the rare cases, where it does not work.

Thanks again!

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1036464: Acknowledgement (tzdata: [INTL:de] updated German debconf translation)

[Helge Kreutzmann]

Hello Benjamin,
On Sun, May 28, 2023 at 08:06:37PM +, Benjamin Drung wrote:
> On Sun, 2023-05-28 at 07:49 +0200, Helge Kreutzmann wrote:
> > Hello tzdata maintainers,
> > a week ago I provided the update for the German Debconf translation. 
> > 
> > Since we are now in hard freeze and the release quickly approaching,
> > could you kindly upload this translation so that it reaches bookworm?
> > 
> > I'm pretty sure release managers will accept this small but important
> > change (one string in de.po only).
> 
> Okay. Uploaded 2023c-5 with the translation update.

Thank you very much!

Greetings

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


signature.asc
Description: PGP signature

Bug#1036464: Acknowledgement (tzdata: [INTL:de] updated German debconf translation)

[Benjamin Drung]

On Sun, 2023-05-28 at 07:49 +0200, Helge Kreutzmann wrote:
> Hello tzdata maintainers,
> a week ago I provided the update for the German Debconf translation. 
> 
> Since we are now in hard freeze and the release quickly approaching,
> could you kindly upload this translation so that it reaches bookworm?
> 
> I'm pretty sure release managers will accept this small but important
> change (one string in de.po only).

Okay. Uploaded 2023c-5 with the translation update.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1036897: unblock: tzdata/2023c-5

[Benjamin Drung]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: tzd...@packages.debian.org, bdr...@debian.org
Control: affects -1 + src:tzdata

Please unblock package tzdata

[ Reason ]
This upload only contains translation updates.

[ Tests ]
tzdata has several autopkgtest to cover regressions.

[ Risks ]
The risk of this update is low since it only touches debconf
translations.

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

unblock tzdata/2023c-5
diff -Nru tzdata-2023c/debian/changelog tzdata-2023c/debian/changelog
--- tzdata-2023c/debian/changelog   2023-05-10 00:00:40.0 +0200
+++ tzdata-2023c/debian/changelog   2023-05-28 21:54:34.0 +0200
@@ -1,3 +1,10 @@
+tzdata (2023c-5) unstable; urgency=medium
+
+  * Update German debconf translation.
+Thanks to Helge Kreutzmann  (Closes: #1036464)
+
+ -- Benjamin Drung   Sun, 28 May 2023 21:54:34 +0200
+
 tzdata (2023c-4) unstable; urgency=medium
 
   * Sort timezones naturally in debconf
diff -Nru tzdata-2023c/debian/po/de.po tzdata-2023c/debian/po/de.po
--- tzdata-2023c/debian/po/de.po2023-05-06 13:15:17.0 +0200
+++ tzdata-2023c/debian/po/de.po2023-05-27 13:38:23.0 +0200
@@ -1,5 +1,5 @@
 # Translation of tzdata debconf templates to German
-# Copyright (C) Helge Kreutzmann , 2007, 2008.
+# Copyright (C) Helge Kreutzmann , 2007, 2008, 2023.
 # Copyright (C) Holger Wansing , 2010, 2011, 2013, 
2016, 2017.
 # This file is distributed under the same license as the tzdata package.
 # Holger Wansing , 2019.
@@ -8,7 +8,7 @@
 "Project-Id-Version: tzdata 2021c-1\n"
 "Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
 "POT-Creation-Date: 2023-02-06 11:44+0100\n"
-"PO-Revision-Date: 2021-10-02 20:04+0200\n"
+"PO-Revision-Date: 2023-05-21 10:53+0200\n"
 "Last-Translator: Holger Wansing \n"
 "Language-Team: German \n"
 "Language: de\n"
@@ -3412,3 +3412,8 @@
 "negative values for those east of Greenwich (e.g., 'Etc/GMT+6' refers to 6 "
 "hours west of Greenwich, commonly called 'UTC-6')."
 msgstr ""
+"Bitte wählen Sie Ihre Zeitzone. Entgegen den Gepflogenheiten verwenden diese "
+"POSIX-kompatiblen Zeitzonen positive Werte für Zonen westlichen von "
+"Greenwich und negative Werte für diese östlich von Greenwich (z.B. bezieht "
+"sich »Etc/GMT+6« auf 6 Studen westlich von Greenwich, was normalerweise "
+"»UTC-6« genannt wird)."

Bug#1036896: unblock: vdr-plugin-xineliboutput/2.2.0+git20211212-2.2

[Martin Hostettler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: vdr-plugin-xinelibout...@packages.debian.org, Andreas Metzler 

Control: affects -1 + src:vdr-plugin-xineliboutput

[I'm not the uploader of the update, but filing to meet the deadline]

Please unblock package vdr-plugin-xineliboutput

[ Reason ]
QA work by Helmut Grohne uncovered that xineliboutput-fbfe is missing
Breaks+Replaces for upgrades without unpack errors.

[ Impact ]
Possible unpack errors when users upgrade to bookworm.

[ Tests ]
No package provided tests found this bug. I did not do upgrade tests, but i
am relying that the uploader of the nmu (Andreas Metzler) did.

[ Risks ]
The exact version for the breaks+replaces could be wrong, but the version
of the package in bullseye is covered so the risks should be minor.

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

[ Other info ]
I've reviewed the complete diffoscope
--exclude-directory-metadata=recursive output and there are only the
expected changes and changes that are consistent with a rebuild of a
package after the debian archive evolved for a year or so since the last
build.

[ Full debdiff ]
$ debdiff *.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/doc/xineliboutput-fbfe/changelog.Debian.amd64.gz

Control files: lines which differ (wdiff format)

{+Breaks: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)+}
Depends: libc6 (>= [-2.33),-] {+2.34),+} libcec6 (>= 6.0.2), libjpeg62-turbo 
(>= 1.3.1), libxine2 (>= 1.2.0), libxine2-xvdr (= 
[-2.2.0+git20211212-2.1+b1),-] {+2.2.0+git20211212-2.2),+} libxine2-console
Installed-Size: [-278-] {+270+}
{+Replaces: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)+}
Source: vdr-plugin-xineliboutput [-(2.2.0+git20211212-2.1)-]
Version: [-2.2.0+git20211212-2.1+b1-] {+2.2.0+git20211212-2.2+}


unblock vdr-plugin-xineliboutput/2.2.0+git20211212-2.2
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/doc/xineliboutput-fbfe/changelog.Debian.amd64.gz

Control files: lines which differ (wdiff format)

{+Breaks: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)+}
Depends: libc6 (>= [-2.33),-] {+2.34),+} libcec6 (>= 6.0.2), libjpeg62-turbo 
(>= 1.3.1), libxine2 (>= 1.2.0), libxine2-xvdr (= 
[-2.2.0+git20211212-2.1+b1),-] {+2.2.0+git20211212-2.2),+} libxine2-console
Installed-Size: [-278-] {+270+}
{+Replaces: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)+}
Source: vdr-plugin-xineliboutput [-(2.2.0+git20211212-2.1)-]
Version: [-2.2.0+git20211212-2.1+b1-] {+2.2.0+git20211212-2.2+}

Bug#1034344: Bug#1028002: dash: sid dash globs no longer allow [^...] to negate a class; upcoming breaking change from bullseye

[Paul Gevers]

Control: tags -1 pending patch

Hi,

On Thu, 13 Apr 2023 11:48:10 +0200 Paul Gevers  wrote:

On 12-04-2023 16:57, Santiago Ruano Rincón wrote:
> If the current behaviour
> would be part of bookworm, a NEWS entry would be great.

And a release note would be worth it too I guess.


Our (crafted with Andrej) proposal is here:
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/181

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036895: installation-reports: successful installation on X1 Carbon gen 1

[Étienne Mollier]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: emoll...@debian.org

Boot method: netinst
Image version: debian installer 12 RC 4
Date: 2023-05-28

Machine: Lenovo X1 Carbon generation 1 (2012)
Partitions:
$ df -Tl
Filesystem   Type 1K-blocks Used Available Use% Mounted 
on
udev devtmpfs   39372440   3937244   0% /dev
tmpfstmpfs   794508 1344793164   1% /run
/dev/mapper/charbon--vg-root xfs   29229056  4625584  24603472  16% /
tmpfstmpfs  39725240   3972524   0% /dev/shm
tmpfstmpfs 51208  5112   1% 
/run/lock
/dev/mapper/charbon--vg-home xfs  218615508 15372176 203243332   8% /home
/dev/sda2ext445781682293346442  20% /boot
/dev/sda1vfat523244 5972517272   2% 
/boot/efi
tmpfstmpfs   794504   48794456   1% 
/run/user/1000
$ lsblk
NAME MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda8:00 238.5G  0 disk  
├─sda1 8:10   512M  0 part  /boot/efi
├─sda2 8:20   488M  0 part  /boot
└─sda3 8:30 237.5G  0 part  
  └─sda3_crypt   254:00 237.5G  0 crypt 
├─charbon--vg-root   254:10  27.9G  0 lvm   /
├─charbon--vg-swap_1 254:20   976M  0 lvm   [SWAP]
└─charbon--vg-home   254:30 208.6G  0 lvm   /home

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

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

Comments/Problems:
The install went overall boringly great, which is how it should
be.  :)

One thing worth mentionning is that I proceeded to the install
on the Wifi, and that the connectivity went flaky.  This caused
the mirror selection and scanning to error with a message about
the bookworm release to not be supported by all the mirrors I
selected.  I had to investigate via the system console to
identify the network drop.  I'm not sure that I have a good idea
to improve how to feed this back through the d-i interface, but
Paul Gevers, who was is the vicinity, suggested that I raise the
issue anyway.

-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230526"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux charbon 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 
(2023-05-08) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core 
processor DRAM Controller [8086:0154] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen 
Core processor Graphics Controller [8086:0166] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 
Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 
Series/C216 Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C216 
Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C216 
Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C216 Chipset 
Family PCI Express Root Port 1 [8086:1e10] (rev c4)
lspci -knn: Subsystem: Lenovo Device [17aa:21f9]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series 
Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4)
lspci -knn: Subsystem: Lenovo Device 

Bug#1035748: unblock: modsecurity/3.0.9-1

[Alberto Gonzalez Iniesta]

Hi, Salvatore. Thanks for the heads up!

Hi, Paul et al.

Answering the questions on the referred page:
1) Yes, mainly a bugfix release as noted in its changelog [1]
2) The risks on the release quality are almost zero. Only
libnginx-mod-http-modsecurity depends on it (being modsecurity a
library).
3) No idea
4) No idea
5) Yes, including its Debian co-maintainer, Ervin Hegedus.
6) Yes
7) Its too long but mainly because of line numbers being updated in code
comments, like:
-#line 1459 "seclang-parser.yy"
+#line 1461 "seclang-parser.yy"
8) Not that many code changes
9) Not that difficult :-)

Cheers,

Alberto



[1] https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.9



On Sat, May 27, 2023 at 10:33:27PM +0200, Salvatore Bonaccorso wrote:
> Hi Alberto,
> 
> On Wed, May 24, 2023 at 12:26:33PM +0200, Paul Gevers wrote:
> > control: tags -1 moreinfo
> > 
> > Hi,
> > 
> > On Mon, 08 May 2023 18:16:51 +0200 Alberto Gonzalez Iniesta
> >  wrote:
> > > A new upstream version of modsecurity fixes a security bug
> > > (CVE-2023-28882, #1035083).
> > > We also fixed a FTBFS in the meantime (#1034760).
> > > Also nginx moved to pcre2, which we also did after the current version
> > > in bookworm.
> > 
> > Your message didn't reach our mail list, which typically is a bad sign
> > because it means your debdiff is big. New upstream releases are typically
> > not what we consider targeted fixes which are all we accept in this phase of
> > the release. Please read the FAQ [1] and provide all relevant information
> > pointed out there, particularly about upstream's policy on new releases.
> 
> Did you saw Paul's query? I'm asking since the deadline for unblock
> requests is tomorrow already.
> 
> Regards,
> Salvatore

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#1036881: whitedune: segfaults

[Paul Gevers]

tags 1036881 bookworm-ignore
user release.debian@packages.debian.org
usertag 1036881 bookworm-can-defer
thanks

Hi,
On 28-05-2023 20:17, Andrey Rakhmatullin wrote:

whitedune 0.30.10 was uploaded to Debian in 2011, the current version
(the new homepage is https://wdune.ourproject.org/) is 1.956, released, I
assume, in 2020, and its SFNode::SFNode() doesn't do this anymore. I don't
see a VCS so I can't find a change that did this.


For the avoidance of doubt, it's too late in the freeze to actually fix 
this issue and because there are reverse (build) dependencies involved 
which still work without whitedune functioning, I'll not remove the 
package, hence the tags. I'll try to remember to remove the 
bookworm-ignore tag after the release.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#947685: still occuring on Linux 6.1.0-9-amd64 x86_64

[Christian]

I am plagued with this on current Linux 6.1.0-9-amd64 x86_64.

As soon as load on the system increases, the error comes up and
apparently it takes some other things (SATA) with it. Leaving the
system workable, but slowly failing.

Happy to provide more information or test things.

Bug#1036894: unblock: closure-compiler/20130227+rhino-1

[Markus Koschany]

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

Please unblock package closure-compiler

[ Reason ]

It turned out that closure-compiler would not function correctly with
the latest version of librhino-java in Debian. I had to revert the
previous patch to fix the FTBFS. I bundled the source package of rhino
1.7.7.2 with src:closure-compiler instead. This was the last one that
worked correctly. Please see #1036249 for the full discussion. The
debdiff is huge because of the new rhino sources hence why it is not
attached to this bug report but I made only minimal changes to
debian/rules and the build_xml.patch.

[ Impact ]

Half of closure-compiler's r-deps would FTBFS with a parsing error.

[ Tests ]

I have sucessfully rebuilt all reverse-dependencies twice.

[ Risks ]

Since rhino is now embedded, rebuilds are no longer required. The tool
appears to work again as in February before I had to upgrade the system
library of rhino.

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


unblock closure-compiler/20130227+rhino-1

Bug#1036893: cyrus-sasl2. Frequent autopkgtest failures on 'connect() : No such file or directory'

[Otto Kekäläinen]

Package: cyrus-sasl2
Version: 2.1.28+dfsg-10
Affects: src:mariadb

As the src:mariadb maintainer I've noticed that the autopkgtests that
get triggered by new src:mariadb uploads frequently fail the
autopkgtest 'saslauthd' on:


Setting up saslauthd with mecanism sasldb
Authentication of user user2415 with correct password should succeed... FAIL
exit status: 255
output:
connect() : No such file or directory
0:
autopkgtest [15:10:15]: test saslauthd: ---]
saslauthdFAIL non-zero exit status 1


This seems intermittent, as reruns pass. However this is annoying and
slows down the MariaDB release process. Could you please look into the
test if it can be stabilized?


Example of fail:
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cyrus-sasl2/33905803/log.gz

Example of passing for reference:
https://ci.debian.net/data/autopkgtest/testing/amd64/c/cyrus-sasl2/33816691/log.gz

Bug#1036892: unblock: tomcat9/9.0.70-2

[Markus Koschany]

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

Please unblock package tomcat9

[ Reason ]

We can support only one major Tomcat version per release. I have
dropped all server packages and kept only the libtomcat9-java binary
package for compatibility reasons. It does not require security
support. Please see #1034824 for the full discussion.

[ Impact ]

We would have to support two major Tomcat versions in Bookworm.

[ Tests ]

I have successfully rebuilt all reverse-dependencies of
libtomcat9-java. There is currently no package in testing that
build-depends or depends on other binary packages from src:tomcat9.

[ Risks ]

None, if the test results are correct.

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


unblock tomcat9/9.0.70-2
diff -Nru tomcat9-9.0.70/debian/changelog tomcat9-9.0.70/debian/changelog
--- tomcat9-9.0.70/debian/changelog 2022-12-05 18:50:40.0 +0100
+++ tomcat9-9.0.70/debian/changelog 2023-05-27 17:51:32.0 +0200
@@ -1,3 +1,13 @@
+tomcat9 (9.0.70-2) unstable; urgency=medium
+
+  * Team upload.
+  * Drop tomcat9 server packages because only one Tomcat version is supported
+per release. Only retain libtomcat9-java because of compatibility reasons
+for now. Users are strongly encouraged to switch to Tomcat 10 instead.
+(Closes: #1034824)
+
+ -- Markus Koschany   Sat, 27 May 2023 17:51:32 +0200
+
 tomcat9 (9.0.70-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru tomcat9-9.0.70/debian/control tomcat9-9.0.70/debian/control
--- tomcat9-9.0.70/debian/control   2022-12-05 16:29:55.0 +0100
+++ tomcat9-9.0.70/debian/control   2023-05-27 17:51:32.0 +0200
@@ -29,67 +29,6 @@
 Vcs-Browser: https://salsa.debian.org/java-team/tomcat9
 Homepage: http://tomcat.apache.org
 
-Package: tomcat9-common
-Architecture: all
-Depends:
- default-jre-headless | java11-runtime-headless | java11-runtime,
- libtomcat9-java (>= ${source:Version}),
- ${misc:Depends}
-Description: Apache Tomcat 9 - Servlet and JSP engine -- common files
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains common files needed by the tomcat9 and tomcat9-user
- packages (Tomcat 9 scripts and libraries).
-
-Package: tomcat9
-Architecture: all
-Depends:
- lsb-base (>= 3.0-6),
- systemd (>= 238) | systemd-sysusers,
- systemd (>= 238) | systemd-tmpfiles,
- tomcat9-common (>= ${source:Version}),
- ucf,
- ${misc:Depends}
-Recommends:
- libtcnative-1 (>= 1.2.18)
-Suggests:
- tomcat9-admin (>= ${source:Version}),
- tomcat9-docs (>= ${source:Version}),
- tomcat9-examples (>= ${source:Version}),
- tomcat9-user (>= ${source:Version})
-Description: Apache Tomcat 9 - Servlet and JSP engine
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains only the startup scripts for the system-wide daemon.
- No documentation or web applications are included here, please install
- the tomcat9-docs and tomcat9-examples packages if you want them.
- Install tomcat9-user instead of this package if you don't want Tomcat to
- start as a service.
-
-Package: tomcat9-user
-Architecture: all
-Depends:
- netcat-openbsd,
- tomcat9-common (>= ${source:Version}),
- ${misc:Depends}
-Suggests:
- tomcat9 (>= ${source:Version}),
- tomcat9-admin (>= ${source:Version}),
- tomcat9-docs (>= ${source:Version}),
- tomcat9-examples (>= ${source:Version})
-Description: Apache Tomcat 9 - Servlet and JSP engine -- tools to create user 
instances
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains files needed to create a user Tomcat instance.
- This user Tomcat instance can be started and stopped using the scripts
- provided in the Tomcat instance directory.
-
 Package: libtomcat9-java
 Architecture: all
 Depends: libeclipse-jdt-core-java (>= 3.26.0), ${misc:Depends}
@@ -102,48 +41,4 @@
  This package contains the Tomcat core classes which can be used by other
  Java applications to embed Tomcat.
 
-Package: libtomcat9-embed-java
-Architecture: all
-Depends: libeclipse-jdt-core-java (>= 3.26.0), ${misc:Depends}
-Description: Apache Tomcat 9 - Servlet and JSP engine -- embed libraries
- Apache Tomcat implements the Java Servlet and the JavaServer Pages (JSP)
- specifications from Oracle, and provides a "pure Java" HTTP web
- server environment for Java code to run.
- .
- This package contains the libraries required to embed Tomcat into Java
- 

Bug#1036891: texlive-binaries: Error "attempt to call method 'read' (a nil value)" makes lualatex unusable

[Philippe SWARTVAGHER]

Package: texlive-binaries
Version: 2018.20181218.49446-1+deb10u1
Severity: important

Dear Maintainer,

(not sure if this bug report should be against texlive-luatex or
texlive-binaries...)

I upgraded texlive-binaries (and other related packages) from
2018.20181218.49446-1 to 2018.20181218.49446-1+deb10u1 on a Debian
Buster. Since then, I cannot use lualatex because of an error.

Here is how to reproduce the problem (I used Docker with `docker run -it
debian:buster`):
```
apt update
apt install texlive-latex-base texlive-luatex
cd
cat > test.tex <
...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:292: attempt to cal
l method 'read' (a nil value)
stack traceback:
...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:292: in 
function '
task'
...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:923: in 
function <
...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:919>
(...tail calls...)
...-dist/tex/luatex/luaotfload/luaotfload-configuration.lua:1030: in 
function
'init'
...ive/texmf-dist/tex/luatex/luaotfload/luaotfload-main.lua:243: in 
function '
initialize'
...ive/texmf-dist/tex/luatex/luaotfload/luaotfload-main.lua:284: in 
function '
main'
[\directlua]:1: in main chunk.
 ...ring \\def\string \\encodingdefault{OT1}')end }
  \let \f@encoding \encoding...

l.1
  \documentclass{article}
?
```

Some remarks:
- it works as expected with version 2018.20181218.49446-1 (tested by removing
  buster/updates from sources.list)
- it works as expected as long as I don't install texlive-luatex
- I didn't test with Debian stable / testing / unstable


Thanks,

Philippe.


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

Kernel: Linux 5.15.49-linuxkit (SMP w/1 CPU core)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_RANDSTRUCT
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages texlive-binaries depends on:
ii  dpkg  1.19.8
ii  libbrotli11.0.7-2+deb10u1
ii  libc6 2.28-10+deb10u2
ii  libcairo2 1.16.0-4+deb10u1
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3+deb10u3
ii  libgcc1   1:8.3.0-6
ii  libgmp10  2:6.1.2+dfsg-4+deb10u1
ii  libgraphite2-31.3.13-7
ii  libgs99.27~dfsg-2+deb10u7
ii  libharfbuzz-icu0  2.3.1-1
ii  libharfbuzz0b 2.3.1-1
ii  libice6   2:1.0.9-2
ii  libicu63  63.1-6+deb10u3
ii  libkpathsea6  2018.20181218.49446-1+deb10u1
ii  libmpfr6  4.0.2-1
ii  libpaper1 1.1.28
ii  libpixman-1-0 0.36.0-1+deb10u1
ii  libpng16-16   1.6.36-6
ii  libpotrace0   1.15-1
ii  libptexenc1   2018.20181218.49446-1+deb10u1
ii  libsm62:1.2.3-1
ii  libstdc++68.3.0-6
ii  libsynctex2   2018.20181218.49446-1+deb10u1
ii  libteckit02.5.8+ds2-5
ii  libtexlua52   2018.20181218.49446-1+deb10u1
ii  libtexlua53   2018.20181218.49446-1+deb10u1
ii  libtexluajit2 2018.20181218.49446-1+deb10u1
ii  libwoff1  1.0.2-1
ii  libx11-6  2:1.6.7-1+deb10u2
ii  libxaw7   2:1.0.13-1+b2
ii  libxext6  2:1.3.3-1+b2
ii  libxi62:1.7.9-1
ii  libxmu6   2:1.1.2-2+b3
ii  libxpm4   1:3.5.12-1
ii  libxt61:1.1.5-1+b3
ii  libxxhash00.6.5-2
ii  libzzip-0-13  0.13.62-3.2+deb10u1
ii  perl  5.28.1-6+deb10u1
ii  t1utils   1.41-3
ii  tex-common6.11
ii  zlib1g1:1.2.11.dfsg-1+deb10u2

Versions of packages texlive-binaries recommends:
ii  texlive-base  2018.20190227-2

texlive-binaries suggests no packages.

-- no debconf information

Bug#1036890: unblock: jetty9/9.4.50-4

[Markus Koschany]

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

Please unblock package jetty9

[ Reason ]

It was discovered that jetty9 would throw a ServiceConfigurationError
when running web applications. (#1036798) We couldn't find a targeted
fix to improve our tomcat10-migration.patch from the previous upload.
Time is running out hence why I have reverted back to libtomcat9-java.

[ Impact ]

Web applications will not work when using the jetty9 server package.

[ Tests ]

Confirmed that reverting back to libtomcat9-java fixes the problem.

[ Risks ]

We are back to square one.

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


unblock jetty9/9.4.50-4
diff -Nru jetty9-9.4.50/debian/changelog jetty9-9.4.50/debian/changelog
--- jetty9-9.4.50/debian/changelog  2023-02-19 13:41:00.0 +0100
+++ jetty9-9.4.50/debian/changelog  2023-05-27 16:28:19.0 +0200
@@ -1,3 +1,11 @@
+jetty9 (9.4.50-4) unstable; urgency=medium
+
+  * Team upload.
+  * Revert the switch to libtomcat10-java. For now Jetty 9 only works correctly
+with libtomcat9-java. (Closes: #1036798)
+
+ -- Markus Koschany   Sat, 27 May 2023 16:28:19 +0200
+
 jetty9 (9.4.50-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru jetty9-9.4.50/debian/control jetty9-9.4.50/debian/control
--- jetty9-9.4.50/debian/control2023-02-19 13:41:00.0 +0100
+++ jetty9-9.4.50/debian/control2023-05-27 16:28:19.0 +0200
@@ -29,7 +29,7 @@
  libspring-beans-java,
  libtaglibs-standard-impl-java,
  libtaglibs-standard-spec-java,
- libtomcat10-java,
+ libtomcat9-java,
  libwebsocket-api-java,
  maven-debian-helper (>= 2.2.8~),
  maven-repo-helper
@@ -60,7 +60,7 @@
  libspring-beans-java,
  libtaglibs-standard-impl-java,
  libtaglibs-standard-spec-java,
- libtomcat10-java,
+ libtomcat9-java,
  ${misc:Depends}
 Suggests: jetty9
 Description: Java servlet engine and webserver -- extra libraries
diff -Nru jetty9-9.4.50/debian/jetty9.links jetty9-9.4.50/debian/jetty9.links
--- jetty9-9.4.50/debian/jetty9.links   2023-02-19 13:41:00.0 +0100
+++ jetty9-9.4.50/debian/jetty9.links   2023-05-27 16:28:19.0 +0200
@@ -50,22 +50,22 @@
 usr/share/java/jetty9-xml.jar   
usr/share/jetty9/lib/jetty-xml-${VERSION}.jar
 
 usr/share/java/servlet-api.jar  
usr/share/jetty9/lib/servlet-api-3.1.jar
-usr/share/java/tomcat10-annotations-api.jar  
usr/share/jetty9/lib/annotations/javax.annotation.jar
+usr/share/java/tomcat9-annotations-api.jar  
usr/share/jetty9/lib/annotations/javax.annotation.jar
 usr/share/java/asm.jar  
usr/share/jetty9/lib/annotations/asm.jar
 usr/share/java/asm-analysis.jar 
usr/share/jetty9/lib/annotations/asm-analysis.jar
 usr/share/java/asm-commons.jar  
usr/share/jetty9/lib/annotations/asm-commons.jar
 usr/share/java/asm-tree.jar 
usr/share/jetty9/lib/annotations/asm-tree.jar
 usr/share/java/eclipse-jdt-core.jar 
usr/share/jetty9/lib/apache-jsp/jdt-core.jar
-usr/share/java/tomcat10-api.jar  
usr/share/jetty9/lib/apache-jsp/tomcat-api.jar
-usr/share/java/tomcat10-el-api.jar   
usr/share/jetty9/lib/apache-jsp/tomcat-el-api.jar
-usr/share/java/tomcat10-jasper.jar   
usr/share/jetty9/lib/apache-jsp/tomcat-jasper.jar
-usr/share/java/tomcat10-jasper-el.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jasper-el.jar
-usr/share/java/tomcat10-jsp-api.jar  
usr/share/jetty9/lib/apache-jsp/tomcat-jsp-api.jar
-usr/share/java/tomcat10-juli.jar 
usr/share/jetty9/lib/apache-jsp/tomcat-juli.jar
-usr/share/java/tomcat10-util.jar 
usr/share/jetty9/lib/apache-jsp/tomcat-util.jar
-usr/share/java/tomcat10-util-scan.jar
usr/share/jetty9/lib/apache-jsp/tomcat-util-scan.jar
+usr/share/java/tomcat9-api.jar  
usr/share/jetty9/lib/apache-jsp/tomcat-api.jar
+usr/share/java/tomcat9-el-api.jar   
usr/share/jetty9/lib/apache-jsp/tomcat-el-api.jar
+usr/share/java/tomcat9-jasper.jar   
usr/share/jetty9/lib/apache-jsp/tomcat-jasper.jar
+usr/share/java/tomcat9-jasper-el.jar
usr/share/jetty9/lib/apache-jsp/tomcat-jasper-el.jar
+usr/share/java/tomcat9-jsp-api.jar  
usr/share/jetty9/lib/apache-jsp/tomcat-jsp-api.jar
+usr/share/java/tomcat9-juli.jar 
usr/share/jetty9/lib/apache-jsp/tomcat-juli.jar
+usr/share/java/tomcat9-util.jar 
usr/share/jetty9/lib/apache-jsp/tomcat-util.jar
+usr/share/java/tomcat9-util-scan.jar
usr/share/jetty9/lib/apache-jsp/tomcat-util-scan.jar
 usr/share/java/taglibs-standard-spec.jar
usr/share/jetty9/lib/apache-jstl/org.apache.taglibs.taglibs-standard-spec.jar
 

Bug#932957: Please migrate Release Notes to reStructuredText

[Stéphane Blondon]

Le dim. 28 mai 2023 à 13:16, Stéphane Blondon
 a écrit :
> Sphinx uses Pygments to highlight source code. I guess no language is defined 
> so Sphinx uses a wrong lexer. We should force Sphinx to use 'SourceListLexer' 
> with:
> .. code-block :: sources.list

I sent a Merge Request on Holger's repository to implement it:
https://salsa.debian.org/holgerw/release-notes/-/merge_requests/2

Bug#1036883: unblock: inventor/2.1.5-10+dfsg-2

[Steven Robbins]

On Sunday, May 28, 2023 11:08:52 A.M. CDT Martin Hostettler wrote:

> [ Risks ]
> 
> Steven Robbins described the problem the following way:
> > I couldn't say "harmless", but "mostly harmless", I'd think.

If it helps: Inventor is a system for visualizing 3D scenes.  The elements in 
the scenes are geometric objects like spheres, cuboids, cones, etc, described 
in a structured "scene graph" input file.  One possible node type in the scene 
is "text".  This bug will manifest only for input data that contains a text 
node; when it manifests the text will be absent in the view but no other ill 
effects are observed.
 
> And uploaded a fix to unstable.
> 
> The risks should be minimal given that the change in the package are
> minimal.

The fix is just to link to the new file names.  I tested the fix by viewing an 
example scene file that does contain text: 

ivview /usr/share/inventor/data/demos/jackInTheBox.iv

Regards,
-Steve



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

Bug#1013729:

[matthias . geiger1024]

Version: 3.12.0-1

Uploaded 3.12.0 to experimental, still needs two packages currently in NEW to 
build.

regards,

---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8HuohT7K3/pcsEt0jvYSwvvDFUIz5WdOR5RmB7WkDRGh8Zaior3z
tzx6AKhx/aXmAc/i4BDavDxZeFC0d79H3S1+TvFsvhyIZXIFTB0sTzWreZZxSOjk
Mz6xxgWGdc27lsbZbKU7N+c+GnWrRlTjimU1AfPLJQgehIejR9pSyZ2Y5BAqB7Qr
f8Tvc8jc1kDx473sUUla6ELEuJMIISK1qam/B7buxZ1r/ngWRiQsqAHznm7OYk69
ttXBeHxS1b+HrcJMWfROkzsTuG6G//axMCb6x0MuyOgLXk87aDnDx1fPn62R+tq7
T4JvW51TSnlNNh75zA+8w3UzDHy2By0H6NSfiLerNnF7LGCXk7AiwQsaplrEjo/1
/4NraAqy1eO69SyozSiRuuA5KemlyPwJokpp2HMJX3cry2J7lV0+wnaaorQzz5Fi
7gRRlqXrOGwEcEG6i62VbIv2VW3Zy+qjaD3HRWXfKXXjpXske41Trv2qPI2/kGtJ
TRWSWdTQ42oYOaEg/KUh0GnEoZerj50JC1qGmwElKYgd+2XQ8qR7uIB5qQARAQAB
tDFNYXR0aGlhcyBHZWlnZXIgPG1hdHRoaWFzLmdlaWdlcjEwMjRAdHV0YW5vdGEu
ZGU+iQJUBBMBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmJGNsQCGwMFCQPC
ZwAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQGL0QaztsVHVMxQ/+M5JEQ5wk
DDblHGUlK8IBnPM5peuDrMdQAsOQ5nSv90gl4z4HkRgomS70xMpvoS+g/8hPym4G
PXpSFJsZWjFevACWMzZO84pqJhPaFnmjh3utkkiblNf8Wi350K+luAlRvT1FVD6i
HM6kOxU0P9t9+PU38FH299oRw2qEqDw5Wx+Hrnp4gaGv1mssvAMiXeaaPGx4KSz8
sNXADHJDo78U6RGJM/rSng/8M7zd3c6E8MIH958mlWjUb8T10AZ/otH3nFSRIfds
5MdnnrsKAK3DMW4RanRWHPvTsICDDkuRvigd32waQRdZeA3dNbPxM6tKDL9GEH8Q
AnkShJ7VmTXP9CV20vj15mleoeDMgqhX5KEOsc3DMnKcVqdb9CzHj6jNSFUverk1
bBNaJpIiWwtwjueR4Hgdof80AAgRin4YnWaOaPTSusrKyN8dCRVcRIbauVooWLil
q2OrWftDVmmNciwoHr5/WDPNgkv9DAgY+DX8Y8LMWAkXgpB0KniiQaLzrW34zjnP
ALTLTIvNid6YX8KOY6KhAVWfVdMC5j6GEGfbfyMLz63YPxA9Q1Af6oXS8MbdHyBw
JV8ns2xm5fD2vZVw6JI1e8AMMDjH2fAqmH23MG0fN0zd2NUToHmvhX9APSzJIbET
doFPn/mI/az4Oh24WHf3Ozr+XEDyWcyy1y+5Ag0EYkY2xAEQANL26Ixtq1QMUM+5
MHl2FK4foRODoKHe4ZzdOAumUBPJE/pxGVlVxCqzC+LUeFvA8LTYCt1B60yRveYR
4mmPTA7nAerG2m4aQPeIfzz6HXWkiu9mzgxqjhPxitiMR5f1du1rAWGPZxSkhdW6
fDWT4PkHoY78jbQXWYEnV85rwtZIZIduHGKWzyxln3qjrefmB04QkPJ2BDOsRTtD
YeNddHAvcgZtyepqZka9lpowQTY6TXwM8uYArEa7Hll/4r9rcvkVQUxf8jqYpZ3v
PLSzvvaDouH7WAg5nUaTeWAQdSq108rNRSTgScLZWjwmhFBA46RneRpij2OJ0lW4
QqFTlldjWXzgGj6u4nbXrSERGaPwyLGIkHoKbnTAm7791d/Y5UQImuPb1tIg5Pf7
OhtyWw3bstVDa5MvIUuGpi5yKPirhrtAfdZ3H2/HR814JuL2BYdjyCuR/Sj/lZTx
+gJ0bm+Llr0KZDhjKMeWaqVqsD4bybgEe4d3zE4sj9GZ0tNUvXfPaRGY6tgh9sgT
Iy28vnyYpFX+oSIZXRreDpfzyjDhvNbB+AFsPN5OXqaBpmu/378T5nRpUj/qbqEZ
EsloCbAmgHfvIysQWYdJ+63S3ZqpbEQRa4Y7DeybaLi8xTMfdWa19T7vQY3mVWn5
ZooycK4fkbedu19+5l8zfhR7oWyBABEBAAGJAjwEGAEKACYWIQTC4abL/ezlEaik
F20YvRBrO2xUdQUCYkY2xAIbDAUJA8JnAAAKCRAYvRBrO2xUdRuPD/4tdAf8nxsA
upo5O99E4AS59OTXPQuVgt1U2Z7ssDvZ3O6qbZvIBWQ0NqnCsprCt71M6cWC2dkq
WUs3oRRu4IzuB4LErcTr597k+iltJ60rhDL/hxSumToH6FSX1w8EWJVg3xgP4U39
HSx6QOlZ3bTgd9dS5S46jOptIYzX5wYkNzyMj1hbmTg0lVyMtWjqfCLNmF3EzGGC
BLR3tMOxZURrxx8tL48iJlFyxJG3XahoyxDSNepo5HZ+AUnNq2TJPoPJQfb1/GB/
/LycKSXWgblyWuGRlgoCE1JcdwuRM5hI2xugZQrhgZaPUBch1MSoiIqwgR1A8NPL
iypUPnwG4vEaVbMtem7OUghsx+fYwuGq0T7/ezjyVRv86U2gU1bmbxojct1AXSCT
FCCR3Y8QAHV9o8U/eZ1XzcEZsXFd6siO5nEBl9HaTHh5gWDrk/molP85S7Y9JIBP
wZygBjWOPCCkFlIuiPQlXsJezVu93ydz7uCNIJfHv30oVedcYHN1Wr7B/1j8wXMy
wqW4Nw54yZ8zaJIo01Khym6cFFVXoAUZa+5QRvSmjnm1Go+ZwZA9i7zo/6LLSpeR
04+4a1Daysk0fTf+DscrxQbUBZX17e1n/EtLS8/pp+Xb/k1JK1iiNcdpfLJ7RNik
GX00szhWs5riRMzIibFDsE/FyYVNX2VHQg==
=onWA
-END PGP PUBLIC KEY BLOCK-

Bug#1036889: unblock: ignition-physics/5.1.0+ds1-4.1

[Martin Hostettler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: ignition-phys...@packages.debian.org, gregor herrmann 

Control: affects -1 + src:ignition-physics

[I'm not the uploader of the update, but filing to meet the deadline]

Please unblock package ignition-physics

[ Reason ]
QA work by Andreas Beckmann uncovered that libignition-physics-dev is
missing a Depends on libignition-physics5-bullet-plugin5.

[ Impact ]
If the current package is shipped with bookworm, users of
libignition-physics-dev will have to manually install
libignition-physics5-bullet-plugin5 to properly compile sources using that
plugin.

If the current package is removed, users of bookworm will not be able to
use ignition-physics from debian packages.

[ Tests ]
No package provided tests found this bug. I've manually tested that the
symlinks that are created are no longer pointing to non existing files.

[ Risks ]
Only a dependency was added, so the risk should be minimal.

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

[ Other info ]
I've reviewed the complete diffoscope
--exclude-directory-metadata=recursive output and there are only the
expected changes and changes that would be expected for a rebuild of a
package that is not fully reproducable (build dir paths in the build
package changed).

[ Full debdiff ]
$ debdiff *.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/doc/libignition-physics-dev/changelog.Debian.amd64.gz

Control files: lines which differ (wdiff format)

Depends: libignition-physics-core-dev, libignition-physics-mesh-dev, 
libignition-physics-sdf-dev, libignition-physics-tpe-dev, 
{+libignition-physics5-bullet-plugin5 (= 5.1.0+ds1-4.1),+} 
libignition-physics5-dartsim-plugin5 (= [-5.1.0+ds1-4+b1),-] 
{+5.1.0+ds1-4.1),+} libbullet-dev, libignition-common-dev (>= 4.0.0), 
libignition-math-dev (>= 6.0.0), libignition-plugin-dev (>= 1.1.0), libdart-dev 
(>= 6.12.1+dfsg4), libdart-external-convhull-3d-dev (>= 6.12.1+dfsg4), 
libdart-collision-ode-dev (>= 6.12.1+dfsg4), libdart-utils-urdf-dev (>= 
6.12.1+dfsg4), libdart-utils-dev (>= 6.12.1+dfsg4), 
libdart-external-odelcpsolver-dev (>= 6.12.1+dfsg4), 
libdart-external-ikfast-dev (>= 6.12.1+dfsg4), libdart-collision-bullet-dev (>= 
6.12.1+dfsg4), libsdformat-dev (>= 12.0.0)
Installed-Size: [-592-] {+591+}
Source: ignition-physics [-(5.1.0+ds1-4)-]
Version: [-5.1.0+ds1-4+b1-] {+5.1.0+ds1-4.1+}


unblock ignition-physics/5.1.0+ds1-4.1
[The following lists of changes regard files as different if they have
different names, permissions or owners.]

Files in first .deb but not in second
-
-rw-r--r--  root/root   
/usr/share/doc/libignition-physics-dev/changelog.Debian.amd64.gz

Control files: lines which differ (wdiff format)

Depends: libignition-physics-core-dev, libignition-physics-mesh-dev, 
libignition-physics-sdf-dev, libignition-physics-tpe-dev, 
{+libignition-physics5-bullet-plugin5 (= 5.1.0+ds1-4.1),+} 
libignition-physics5-dartsim-plugin5 (= [-5.1.0+ds1-4+b1),-] 
{+5.1.0+ds1-4.1),+} libbullet-dev, libignition-common-dev (>= 4.0.0), 
libignition-math-dev (>= 6.0.0), libignition-plugin-dev (>= 1.1.0), libdart-dev 
(>= 6.12.1+dfsg4), libdart-external-convhull-3d-dev (>= 6.12.1+dfsg4), 
libdart-collision-ode-dev (>= 6.12.1+dfsg4), libdart-utils-urdf-dev (>= 
6.12.1+dfsg4), libdart-utils-dev (>= 6.12.1+dfsg4), 
libdart-external-odelcpsolver-dev (>= 6.12.1+dfsg4), 
libdart-external-ikfast-dev (>= 6.12.1+dfsg4), libdart-collision-bullet-dev (>= 
6.12.1+dfsg4), libsdformat-dev (>= 12.0.0)
Installed-Size: [-592-] {+591+}
Source: ignition-physics [-(5.1.0+ds1-4)-]
Version: [-5.1.0+ds1-4+b1-] {+5.1.0+ds1-4.1+}

Bug#1036881: whitedune: segfaults

[Andrey Rakhmatullin]

Control: tags -1 + confirmed upstream fixed-upstream

On Sun, May 28, 2023 at 05:07:33PM +0200, Paul Gevers wrote:
> I just tried to run whitedune, but it segfaults.
> 
> paul@mulciber ~ $ whitedune 
> Segmentation fault (core dumped)
Can confirm.

#0  SFNode::SFNode (this=0x55c2dba0, value=0x0) at SFNode.cpp:36
#1  0x557272aa in Proto::Proto (this=0x55c2ce60, 
scene=0x55c28fd0, name=...) at Proto.cpp:61
#2  0x557efa6f in GroupProto::GroupProto (this=0x55c2ce60, 
scene=0x55c28fd0, name=, extraChrildrenNodeClass=0) at 
GroupNode.cpp:35
#3  0x558bddae in ProtoStaticGroup::ProtoStaticGroup 
(this=0x55c2ce60, scene=, name=, 
extraChrildrenNodeClass=) at NodeStaticGroup.cpp:35
#4  0x55845e40 in ProtoGroup::ProtoGroup (this=0x55c2ce60, 
scene=, name=) at NodeGroup.cpp:38
#5  0x557ff3bd in ProtoAnchor::ProtoAnchor (this=0x55c2ce60, 
scene=) at NodeAnchor.cpp:34
#6  0x556d5dfc in SceneProtoMap::createProtoMap 
(protos=protos@entry=0x55c29060, scene=scene@entry=0x55c28fd0) at 
SceneProtoMap.cpp:304
#7  0x556d3030 in Scene::Scene (this=0x55c28fd0) at Scene.cpp:135
#8  0x5578e07c in DuneApp::OnFileNewWindow (this=0x55bfae00) at 
DuneApp.cpp:364
#9  0x556be331 in main (argc=, argv=0x7fffe308) at 
main.cpp:350

Same bt for `whitedune --help`.

The code there is weird but my C++ is rusty so I don't know if it's
permissible to do (but Google says it's UB so maybe it was a coincidence
that it worked before): Proto::Proto() calls SFNode::SFNode(NULL) which
calls ->ref0() on this NULL, the said method specifically checking for
"this != NULL".

whitedune 0.30.10 was uploaded to Debian in 2011, the current version
(the new homepage is https://wdune.ourproject.org/) is 1.956, released, I
assume, in 2020, and its SFNode::SFNode() doesn't do this anymore. I don't
see a VCS so I can't find a change that did this.

Bug#1024683: ITP: helix -- efficient console-based modal text editor

[Jonas Smedegaard]

Control: owner !
Control: retitle: ITP: helix -- efficient console-based modal text editor

Release 23.05 succesfully builds as an unofficial draft package,
embedding 68 crates (57 missing, 1 unwanted, 10 outdated)
which needs to be packaged before this can officially enter Debian.

Hi Laurent!

I have taken the initiative to create a draft packaging of Helix.  You
are quite welcome to collaborate with me on maintaining it, and/or help
by packaging some of the crates still missing in Debian.

I am not in the Rust team, since we disagree on the style of packaging.
That should not hold you back from working in that team on crates needed
for Helix.

If you - or anyone else reading this - is interested in collaborating
directly on Helix packaging for Debian, then please join its Salsa
project here: https://salsa.debian.org/debian/hx

If you want to work on simpler tasks then please join the Rust team and
work with them on packaging some of the crates needed for Helix:
https://salsa.debian.org/debian/hx/-/blob/debian/latest/debian/TODO

NB! If you choose to help by packaging needed crates, then please file
an ITP bugreport for each crate that you package, as that helps
coordinate our efforts.  I mention this because the Rust team consider
it superfluous to file ITPs for crates, but I disagree: It really is
helpful for coordinating efforts.


 - Jonas

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

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

signature.asc
Description: signature

Bug#1036888: wiki.debian.org: Link on SSDOptimization dead

[Mateusz Grochowski]

Package: wiki.debian.org
Severity: minor
X-Debbugs-Cc: mateusz.grochowski...@gmail.com

Dear Maintainer,

I've found a dead link while browsing https://wiki.debian.org/SSDOptimization. 
The link "Aligning SSD Partitions (Linux magazine)" under "Partitions and 
aligned" is dead and redirects to wrong site.

Thank you for the good work
Mateusz Grochowski

Bug#889635: Also interested in dh_installsystemd templates support

[Aurélien COUDERC]

Package: debhelper
Version: 13.11.4
Followup-For: Bug #889635
X-Debbugs-Cc: Debian Qt/KDE Maintainers 

Hi,

I’m also interested in this feature, needed for the drkonqi KDE crash
manager to be started when systemd-coredump starts.

Drkonqi ships a drkonqi-coredump-processor@.service unit with a
WantedBy=systemd-coredump@.service and I had to reimplement [0] part of
what dh_installsystemd does in the maintainer scripts.

Note that in this case we don’t have a DefaultInstance so unlike what
Vinctor wrote above we *don’t want* to start / restart the unit on
install / upgrade as this would make no sense in this situation.

[0] https://salsa.debian.org/qt-kde-team/kde/drkonqi/-/tree/master/debian


Happy hacking,
--
Aurélien


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

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

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

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.202301

-- no debconf information

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Martin-Éric Racine]

On Sun, May 28, 2023 at 7:15 PM Martin-Éric Racine
 wrote:
>
> On Sun, May 28, 2023 at 6:36 PM Paul Gevers  wrote:
> > On 11-05-2023 20:20, Paul Gevers wrote:
> > > Please review my proposal here:
> > >
> > > https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
> >
> > The release notes now document that the baseline has been bumped.
>
> Please note that I never received the previous message you quoted.
> Anyhow, I commented. on Salsa.

See my other comments in the same thread on Salsa.

This should be made more explicit. Merely stating "something with
NOPL" really won't help anyone who isn't familiar with the intricacies
of x86 variants.

If the expected baseline nowadays is hardware that can run the
-686-pae kernel, it should be explicitly stated in the release notes.

I'm not sure of whether there is any way to grep /proc/cpuinfo to
check whether a host meets the minimal requirement for Bookwormor not,
let alone which package should perform that check, before allowing a
dist-upgrade, but this definitely needs to be implemented now before
Bookworm is released.

Anyhow, given the baseline bump, it appears that the last of the Geode
processors is no longer supported on i386 (even though -686 is
configured for MGEODE and stil ships with Bookworm). Oh well. It was
fun while it lasted.

Martin-Éric

Bug#1036887: unblock: rocrand/5.3.3-4

[Christian Kastner]

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

Please unblock package rocrand

Note that the changes to bookworm are minimal and the only effective
change is fixing the missing dependencies in d/control, as stated under
Reason below.

However: d/changelog is noisy because we had changes in unstable that I
reverted for this -4 release, so that the fix can go through unstable.
(We had changes in unstable, rather than experimental, due to an
extremely poor judgment call on my end. Sorry.)

[ Reason ]
rocrand is missing explicit dependencies on libamdhip64-dev.

[ Impact ]
Users installing librocrand-dev or libhiprand-dev will not be able to
use them without also installing libamdhip64-dev, and it is not
immediately made clear what the actual cause of the error is.

[ Tests ]
This package does not yet have autopkgtests but in this particular case,
the change is minimal and only affects d/control.

[ Risks ]
None, compared to the previous release in bookworm -1.

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

[ Other info ]
None.

unblock rocrand/5.3.3-4diff -Nru rocrand-5.3.3/debian/changelog rocrand-5.3.3/debian/changelog
--- rocrand-5.3.3/debian/changelog  2023-02-07 08:06:45.0 +0100
+++ rocrand-5.3.3/debian/changelog  2023-05-28 18:25:03.0 +0200
@@ -1,3 +1,33 @@
+rocrand (5.3.3-4) unstable; urgency=medium
+
+  * Temporarily revert fixes unfit for bookworm.
+Specifically, revert all changes from after 5.3.3-1.
+
+  * Add missing dependency on libamdhip64-dev (Closes: #1035784, #1035787)
+
+ -- Christian Kastner   Sun, 28 May 2023 18:25:03 +0200
+
+rocrand (5.3.3-3) unstable; urgency=medium
+
+  * Upload to unstable.
+
+ -- Christian Kastner   Sun, 16 Apr 2023 22:45:08 +0200
+
+rocrand (5.3.3-3~exp1) experimental; urgency=medium
+
+  * Add myself to Uploaders
+  * Fix Maintainer name
+  * Add packages librocrand1-test, libhiprand1-test providing autopkgtests
+
+ -- Christian Kastner   Thu, 13 Apr 2023 23:41:30 +0200
+
+rocrand (5.3.3-2) unstable; urgency=medium
+
+  * d/rules: enable hardening flags
+  * d/rules: enable gfx1010 and gfx1011
+
+ -- Cordell Bloor   Mon, 06 Mar 2023 00:41:11 -0700
+
 rocrand (5.3.3-1) unstable; urgency=medium
 
   * d/{watch,gbp.conf}: recombine with hiprand as MUT
diff -Nru rocrand-5.3.3/debian/control rocrand-5.3.3/debian/control
--- rocrand-5.3.3/debian/control2023-02-07 07:22:45.0 +0100
+++ rocrand-5.3.3/debian/control2023-05-28 18:25:03.0 +0200
@@ -14,6 +14,7 @@
hipcc,
git,
libamd-comgr-dev,
+   libamdhip64-dev,
libhsa-runtime-dev,
patchelf,
rocminfo,
@@ -38,7 +39,10 @@
 Package: librocrand-dev
 Section: libdevel
 Architecture: any
-Depends: librocrand1 (= ${binary:Version}),${misc:Depends}, ${shlibs:Depends},
+Depends: librocrand1 (= ${binary:Version}),
+ libamdhip64-dev,
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: generate pseudo- and quasi-random numbers - headers
  The rocRAND project provides functions that generate pseudo-random and
  quasi-random numbers.
@@ -64,7 +68,10 @@
 Package: libhiprand-dev
 Section: libdevel
 Architecture: any
-Depends: libhiprand1 (= ${binary:Version}),${misc:Depends}, ${shlibs:Depends},
+Depends: libhiprand1 (= ${binary:Version}),
+ libamdhip64-dev,
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: wrapper library to port from cuRAND applications to HIP - headers
  The rocRAND project includes a wrapper library called hipRAND which allows
  user to easily port CUDA applications that use cuRAND library to the HIP

Bug#808839: How does it affect scilab?

[Pierre Gruet]

Control: affects -1 - src:scilab

Hi Julien,

On Thu, 30 Apr 2020 09:41:03 +0200 Julien Puydt  
wrote:

> Hi,
>
> can I know how it affects scilab?

It does not affect scilab, at least not anymore! This can be seen in the 
version of scilab currently in experimental: 6.1.1+dfsg2-7~exp0.


The various examples in the "Math rendering in Scilab graphics" page of 
help can all be run (there are only some issues with mathml, but there 
is Bug #1036872 for it).


>
> Cheers,
>
> JP
>

Best regards,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036886: Text input fields very hard to identify in high contrast / dark mode

[Aurélien COUDERC]

Source: rootskel-gtk
Severity: normal
Tags: a11y

Dear Mantainer,

running the installer in graphical dark / high contrast mode, it’s very
hard to identify text input fields in the installer pages, making it
very difficult to see where things need to be input.

The default theme does a must better job at it whereas the high contrast
theme uses (almost ?) the same color for the global page background and
the text input fields background, and the input fields have no visible
border.

If we don’t want to reduce the contrast of either the static text or the
input fields an option could be for text input fields to have a border
with the same color as the text that would make them clearly
identifiable.



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

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

Bug#1036535: unblock: altos/1.9.16-2

[Bdale Garbee]

Graham Inggs  writes:

> If this was an upload of 1.9.15-2 with only that change, altos would
> already have been unblocked.

Right, I understand.  However, there would be no value to me or to the
users altos to create such a version, it would "only" resolve the Debian
file overlap packaging bug which they likely just don't care about.
That's why I didn't take that path.

> You didn't attach a debdiff, but I generated one in order to review
> the changes between 1.9.15-1 in testing and 1.9.16-2 in unstable.

The reason I didn't generate it was exactly what you discovered, which
is that there's a lot of "noise" in the diff that is unrelated to the
code that runs on Linux and/or is actually relevant to the Debian package.

> As far as I could see, the only change according to the upstream
> release notes was:
> * Add TeleGPS v3.0 support
>
> However, the debdiff showed a lot more, including the addition of
> several fonts.

The font stuff is all related to working on firmware support for a
graphic LCD display we need to support in a future ground station
hardware product.  Those changes have no impact at all on the code
that's executable on a Linux system.  Even the addition of support for
TeleGPS v3.0 is largely creation of a new firmware object that's not
executed on Debian, plus some very minor changes to the Java ground
station software to enable support for it, all of which is very low
risk.  Specifically, because the ground station code is in Java, that
change has already been massively tested by our users on other platforms
since the 1.9.16 change giving me extremely high confidence there's no
risk to including those changes here.

> As upstream, please comment on risks of the other changes between
> 1.9.15 and 1.9.16.

As I stated in the original bug filing, I believe the risk of the other
changes is negligible.  A large number of customers of Altus Metrum
hardware products have been running 1.9.16 for a while now on platforms
including Windows, MacOS, Android, and other Linux distributions with
.. literally .. no new bugs reported.

We will of course support whatever decision you choose to make, but I am
quite serious about believing 1.9.16-2 is the best choice of altos
version for inclusion in testing and therefore in the upcoming stable
release. 

Thanks for your time on this, and best regards,

Bdale


signature.asc
Description: PGP signature

Bug#1036885: unblock: hipsparse/5.3.3+dfsg-2

[Christian Kastner]

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

Please unblock package hipsparse

[ Reason ]
hipsparse is missing explicit dependencies on libamdhip64-dev.

[ Impact ]
Users installing libhipsparse-dev will not be able to use it without
also installing libamdhip64-dev, and it is not immediately made clear
what the actual cause of the error is.

[ Tests ]
This package does not yet have autopkgtests but in this particular case,
the change is minimal and only affects d/control.

[ Risks ]
None, compared to the previous release -1.

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

[ Other info ]
None.

unblock hipsparse/5.3.3+dfsg-2diff -Nru hipsparse-5.3.3+dfsg/debian/changelog 
hipsparse-5.3.3+dfsg/debian/changelog
--- hipsparse-5.3.3+dfsg/debian/changelog   2023-01-24 11:35:25.0 
+0100
+++ hipsparse-5.3.3+dfsg/debian/changelog   2023-05-28 17:17:36.0 
+0200
@@ -1,3 +1,15 @@
+hipsparse (5.3.3+dfsg-2) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Cordell Bloor ]
+  * d/control: explicitly depend on libamdhip64-dev
+hipsparse.h includes hip/hip_complex.h and hip/hip_runtime.h, so users
+must have the hip headers installed to use the hipsparse headers.
+(Closes: #1035789)
+
+ -- Christian Kastner   Sun, 28 May 2023 17:17:36 +0200
+
 hipsparse (5.3.3+dfsg-1) unstable; urgency=medium
 
   * Initial release. (Closes: #1023092)
diff -Nru hipsparse-5.3.3+dfsg/debian/control 
hipsparse-5.3.3+dfsg/debian/control
--- hipsparse-5.3.3+dfsg/debian/control 2023-01-24 11:35:25.0 +0100
+++ hipsparse-5.3.3+dfsg/debian/control 2023-05-28 17:17:36.0 +0200
@@ -15,6 +15,7 @@
hipcc,
libamd-comgr-dev,
libhsa-runtime-dev,
+   libamdhip64-dev,
librocsparse-dev,
libgtest-dev 
 Rules-Requires-Root: no
@@ -33,7 +34,8 @@
 Package: libhipsparse-dev
 Section: libdevel
 Architecture: any
-Depends: libhipsparse0 (= ${binary:Version}),${misc:Depends}, 
${shlibs:Depends},
+Depends: libhipsparse0 (= ${binary:Version}), ${misc:Depends}, 
${shlibs:Depends},
+ libamdhip64-dev
 Description: portable interface for sparse linear algebra on the GPU - headers
  hipSPARSE is a wrapper library that provides a common interface to rocSPARSE
  and cuSPARSE. The hipSPARSE library is designed to help applications using

Bug#1036884: transition: time64_t

[Steve Langasek]

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

Dear Release Team,

I had started a thread on debian-devel[1] about the need to migrate 32-bit
architectures to 64-bit time_t in preparation for 2038, an ABI-breaking
change.

As the discussion on debian-devel has died down, I think it's time to
formally put this request on debian-release's radar.

I believe the last time we had an archive ABI change was before the Release
Team's current policy on transitions was put into place.  As mentioned in
that thread, there are probably more than 400 libraries whose ABIs/package
names are affected (380 identified to date); a list of these is attached. 
I've provided a mock ben config below; a real one could be synthesized once
the analysis is finished, though I'm not sure how useful it would be.

Also mentioned in the thread[2], it would be quite cumbersome to start this
transition in experimental (since it's toolchain-driven rather than
source-driven) but getting all of the binary packages through NEW in
experimental (with the wrong ABI) may help with timing.  I'm open to
guidance here.

Due to the broad and disruptive nature of this change, I am writing to
request a slot for the transition, preferably the first in the upcoming
trixie cycle.

I have not build-tested the reverse-build-dependencies.  There are at least
5000 source packages in unstable that need rebuilt as part of this
transition.  Some of them will likely show they have regressed in
buildability, including some that are currently in testing; hopefully a very
small number since we are about to release.  There is discussion of whether
we should enable -Werror=implicit-function-declaration as part of the ABI
transition.  If so, that will increase the number of build failures, though
also hopefully only a bit.  I do not expect build failures as a direct
result of the ABI transition.  If you do want build tests before upload to
unstable, guidance is welcome.

Ben file:

title = "time64_t";
is_affected = .depends ~ "old=/^.*$/" | .depends ~ "new=/^.*64t$/";
is_good = .depends ~ "new=/^.*64t$/";
is_bad = .depends ~ "old=/^.*$/";

-- 
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

[1] https://lists.debian.org/debian-devel/2023/05/msg00168.html
[2] https://lists.debian.org/debian-devel/2023/05/msg00260.html
libevince-dev
binutils-dev
libabsl-dev
libaio-dev
libapr1-dev
libaprutil1-dev
libarchive-dev
libasound2-dev
libatm1-dev
libatspi2.0-dev
libauparse-dev
libbtrfsutil-dev
libc-ares-dev
libcamel1.2-dev
libclamav-dev
libcups2-dev
libcupsfilters-dev
libcupsimage2-dev
libcurl4-gnutls-dev
libcurl4-nss-dev
libcurl4-openssl-dev
libdb5.3++-dev
libdb5.3-dev
libdb5.3-stl-dev
libdbi-dev
libdv4-dev
libelf-dev
libevent-dev
libfcgi-dev
libfido2-dev
libgnutls28-dev
libgphoto2-dev
libgpod-dev
libgps-dev
libgsound-dev
libgxps-dev
libieee1284-3-dev
libipa-hbac-dev
libisofs-dev
libiw-dev
libknet-dev
libmemcached-dev
libmtdev-dev
libmtp-dev
libnatpmp-dev
libnpth0-dev
libnutclient-dev
liboath-dev
libp11-dev
libpam0g-dev
libparted-dev
libpath-utils-dev
libpcap0.8-dev
libpkcs11-helper1-dev
libpng-dev
libpoppler-glib-dev
libpsl-dev
librados-dev
librasqal3-dev
libraw-dev
librdf0-dev
libreadline-dev
librrd-dev
librsync-dev
libsoup2.4-dev
libstatgrab-dev
libtevent-dev
libtokyocabinet-dev
libudf-dev
libupsclient-dev
libv4l-dev
libvformat-dev
pacemaker-dev
uuid-dev
libopenzwave1.6-dev
libricohcamerasdk-dev
android-libboringssl-dev
libext2fs-dev
libglibmm-2.4-dev
libgnome-bg-4-dev
libgnome-desktop-4-dev
apache2-ssl-dev
libglib2.0-dev
android-liblog-dev
clearsilver-dev
davix-dev
drac-dev
hexchat-dev
itcl3-dev
itk3-dev
libace-flreactor-dev
libace-foxreactor-dev
libace-htbp-dev
libace-inet-dev
libace-inet-ssl-dev
libace-rmcast-dev
libace-ssl-dev
libace-tmcast-dev
libace-xtreactor-dev
libacexml-dev
libadns1-dev
libaldmb1-dev
liballegro-acodec5-dev
liballegro-audio5-dev
liballegro-dialog5-dev
liballegro-physfs5-dev
liballegro-ttf5-dev
liballegro-video5-dev
libapache2-mod-form-dev
libaribb24-dev
libbamf3-dev
libbitstream-dev
libbpp-phyl-omics-dev
libbpp-popgen-dev
libbpp-qt-dev
libbpp-raa-dev
libbpp-seq-dev
libcapi20-dev
libcbf-dev
libccrtp-dev
libcdk5-dev
libchicken-dev
libclalsadrv-dev
libcli-dev
libclthreads-dev
libcmis-dev
libcmph-dev
libcmtspeechdata-dev
libcoap2-dev
libcppdb-dev
libcpuset-dev
libctemplate-dev
libcudf-dev
libcw-dev
libcwiid-dev
libczmq-dev
libdaq-dev
libdigidoc-dev
libdmtx-dev
libeasyloggingpp-dev
libeb16-dev
libebook-contacts1.2-dev
libebook1.2-dev
libecal2.0-dev
libedata-book1.2-dev
libedata-cal2.0-dev
libedataserverui4-dev
libev-dev
libev-libevent-dev
libevemu-dev
libexplain-dev
libfixbuf-dev
libfizmo-dev
libfko3-dev
libfreecontact-dev
libfreenect-dev

Bug#1030835: [debian] ITP: ruff -- linter for Python, written in Rust

[Charlie Marsh]

Hi James — yes of course, feel free to list me as the upstream contact. Thanks 
for checking.

Best,
Charlie


> On May 28, 2023, at 12:09 PM, James Addison  wrote:
> 
> Followup-For: Bug #1030835
> X-Debbugs-Cc: charlie.r.ma...@gmail.com
> 
> Hi Charlie,
> 
> I'd like for 'ruff' to be packaged in Debian at some point, and am beginning
> that process, although it could take some time (I'm not all that familiar with
> Rust yet, and from what I've learned about the Debian rust utilities, 
> automated
> packaging is available for cargo-installable codebases, but is a more manual
> process otherwise.  I've found and will follow the issuetracker item[1]).
> 
> Would you be OK with being listed as the upstream contact for a Debian 'ruff'
> package, if-and-when it becomes available?
> 
> (as context: generally the Debian package maintainer will handle and filter
> bugreports from Debian users without any need for your involvement (although
> you could subscribe to activity if interested).  In some cases they could then
> contact you with details about problems found and/or fixes discovered.  When
> that process is working effectively, it should be mutually beneficial.
> 
> Cheers,
> James
> 
> [1] - https://github.com/RustPython/RustPython/issues/4179

Bug#1036880: unblock: pyocd/0.13.1+dfsg-3

[Sebastian Ramacher]

On 2023-05-28 16:15:38 +0200, Martin Hostettler wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> X-Debbugs-Cc: py...@packages.debian.org, Adrian Bunk 
> Control: affects -1 + src:pyocd
> 
> [I'm not the uploader of the update, but filing to meet the deadline]
> 
> Please unblock package pyocd
> 
> This upload backports upstream changes to support the python version in
> bookworm.
> 
> [ Reason ]
> The current version in bookworm is not compatible with the python version
> in bookworm.
> 
> [ Impact ]
> Using pyocd-gdbserver currently crashes.
> 
> [ Tests ]
> Manually tested that it no longer crashes on start. I did not test further.
> 
> [ Risks ]
> If the fix did not work debian would be shipping a broken package, if this
> package is not removed before release.
> 
> On the other hand if the upstream fix works as expected debian bookworm
> users will still be able to debug their microcontroller projects and will
> still have packages for yotta and firmware-microbit-micropython.
> 
> [ 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

The debdiff was missing, but unblocked.

Cheers
-- 
Sebastian Ramacher

Bug#1036259: [Pkg-javascript-devel] Bug#1036259: moment-timezone.js: FTBFS in testing: make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1

[gregor herrmann]

On Sun, 28 May 2023 20:05:09 +0400, Yadd wrote:

> > This looked reasonably easy to fix (cf. attached patch), but the
> > tests fail as follows:
> I fixed it in salsa (needs an update to import 2023 data). I'm waiting for
> Martina review who maintains it.

Ack, I've seen your commits in salsa but as the pipeline fails
(probably the version in d/changelog?) and as a new upstream release
2 weeks before the release might not be accepted by the release team,
I thougt I'd give it a try as well; but well, it was not that
quick :)
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Martin-Éric Racine]

On Sun, May 28, 2023 at 6:36 PM Paul Gevers  wrote:
> On 11-05-2023 20:20, Paul Gevers wrote:
> > Please review my proposal here:
> >
> > https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166
>
> The release notes now document that the baseline has been bumped.

Please note that I never received the previous message you quoted.
Anyhow, I commented. on Salsa.

Martin-Éric

Bug#1035065: Bookworm release notes: sssd cache becomes invalid on upgrade

[Paul Gevers]

Hi,

On 28-04-2023 18:04, Paul Gevers wrote:

On 28-04-2023 16:38, Harald Dunkel wrote:

AFAIU the sssd cache becomes invalid on the upgrade to Bookworm due to a
new format. If you are using the company account to login on your laptop
you might get locked out at upgrade time. This affects FreeIPA and maybe
AD accounts.


Do you know what the way forward is for users? How should users having 
an sssd cache upgrade their system?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036883: unblock: inventor/2.1.5-10+dfsg-2

[Martin Hostettler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: inven...@packages.debian.org, Steve M. Robbins 
Control: affects -1 + src:inventor

[I'm not the uploader of the update, but filing to meet the deadline]

Please unblock package inventor

[ Reason ]
QA work by Andreas Beckmann uncovered that libinventor1 created broken
symlinks to font files that have been renamed.

[ Impact ]
Some broken font symlinks will be created and the application might fail to
find some fonts.

[ Tests ]
No package provided tests found this bug. I've manually tested that the
symlinks that are created are no longer pointing to non existing files.

[ Risks ]

Steven Robbins described the problem the following way:
> I couldn't say "harmless", but "mostly harmless", I'd think.  

And uploaded a fix to unstable.

The risks should be minimal given that the change in the package are
minimal.


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

[ Other info ]
I've reviewed the complete diffoscope
--exclude-directory-metadata=recursive output and there are only the
expected changes and changes that would be expected for a rebuild of a
package that is not fully reproducable (gnu debuglink and build id).

[ Full debdiff ]
$ debdiff *.deb
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Depends: libc6 (>= 2.34), libfreetype6 (>= 2.2.1), libgcc-s1 (>= 3.0), libgl1, 
libglu1-mesa | libglu1, libjpeg62-turbo (>= 1.3.1), libstdc++6 (>= 5), 
libx11-6, libxi6, libxm4 (>= 2.3.4), libxt6, xfonts-scalable, fonts-urw-base35 
[-| gsfonts-x11-]
Version: [-2.1.5-10+dfsg-1-] {+2.1.5-10+dfsg-2+}


unblock inventor/2.1.5-10+dfsg-2

Bug#1036259: [Pkg-javascript-devel] Bug#1036259: moment-timezone.js: FTBFS in testing: make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1

[Yadd]

On 5/28/23 19:56, gregor herrmann wrote:

On Thu, 18 May 2023 09:00:03 +0200, Lucas Nussbaum wrote:


During a rebuild of all packages in testing (bookworm), your package failed
to build on amd64.


Relevant part (hopefully):

  debian/rules binary
dh binary
dh_update_autotools_config
dh_autoreconf
debian/rules execute_before_dh_auto_configure
make[1]: Entering directory '/<>'
# Fail the build if the tzdata package does not match TZVER.
grep -q '^# version 2022g$' /usr/share/zoneinfo/tzdata.zi
make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1


This looked reasonably easy to fix (cf. attached patch), but the
tests fail as follows:


Hi,

I fixed it in salsa (needs an update to import 2023 data). I'm waiting 
for Martina review who maintains it.


Cheers,
Yadd


#v+
Running "nodeunit:countries" (nodeunit) task
Testing countries.jsFF

countries - zone_countries
Error: [] deepEqual [ 'CA' ]
at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at Object.zone_countries (tests/countries/countries.js:230:8)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at /usr/share/nodejs/nodeunit/lib/core.js:236:16
at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
at /usr/share/nodejs/nodeunit/lib/core.js:118:25
at /usr/share/javascript/async/async.js:665:13
at iterate (/usr/share/javascript/async/async.js:149:13)
at async.eachSeries (/usr/share/javascript/async/async.js:165:9)



countries - zone_countries
Error: [ 'US' ] deepEqual [ 'UM', 'US' ]
at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at Object.zone_countries (tests/countries/countries.js:552:8)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at /usr/share/nodejs/nodeunit/lib/core.js:236:16
at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
at /usr/share/nodejs/nodeunit/lib/core.js:118:25
at /usr/share/javascript/async/async.js:665:13
at iterate (/usr/share/javascript/async/async.js:149:13)
at async.eachSeries (/usr/share/javascript/async/async.js:165:9)



countries - country_zones
Actual:
   [
 'America/Atikokan',  'America/Blanc-Sablon',
 'America/Cambridge_Bay', 'America/Creston',
 'America/Dawson','America/Dawson_Creek',
 'America/Edmonton',  'America/Fort_Nelson',
 'America/Glace_Bay', 'America/Goose_Bay',
 'America/Halifax',   'America/Inuvik',
 'America/Iqaluit',   'America/Moncton',
 'America/Panama','America/Phoenix',
 'America/Puerto_Rico',   'America/Rankin_Inlet',
 'America/Regina','America/Resolute',
 'America/St_Johns',  'America/Swift_Current',
 'America/Toronto',   'America/Vancouver',
 'America/Whitehorse','America/Winnipeg'
   ]
Operator:
   deepEqual
Expected:
   [
 'America/Atikokan',  'America/Blanc-Sablon',
 'America/Cambridge_Bay', 'America/Creston',
 'America/Dawson','America/Dawson_Creek',
 'America/Edmonton',  'America/Fort_Nelson',
 'America/Glace_Bay', 'America/Goose_Bay',
 'America/Halifax',   'America/Inuvik',
 'America/Iqaluit',   'America/Moncton',
 'America/Panama','America/Phoenix',
 'America/Puerto_Rico',   'America/Rankin_Inlet',
 'America/Regina','America/Resolute',
 'America/St_Johns',  'America/Swift_Current',
 'America/Toronto',   'America/Vancouver',
 'America/Whitehorse','America/Winnipeg',
 'America/Yellowknife'
   ]
at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at Object.country_zones (tests/countries/countries.js:646:8)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at /usr/share/nodejs/nodeunit/lib/core.js:236:16
at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
at /usr/share/nodejs/nodeunit/lib/core.js:118:25
at /usr/share/javascript/async/async.js:665:13
at iterate (/usr/share/javascript/async/async.js:149:13)
at /usr/share/javascript/async/async.js:160:25



countries - country_zones
Actual:
   [
 'Pacific/Midway',
 'Pacific/Pago_Pago',
 'Pacific/Tarawa',
 'Pacific/Wake'
   ]
Operator:
   deepEqual
Expected:
   [
 'Pacific/Honolulu',
 'Pacific/Midway',
 'Pacific/Pago_Pago',
 'Pacific/Tarawa',
 'Pacific/Wake'
   ]
at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
at Object.country_zones (tests/countries/countries.js:839:8)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
at /usr/share/nodejs/nodeunit/lib/core.js:236:16
at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
at /usr/share/nodejs/nodeunit/lib/core.js:118:25
at /usr/share/javascript/async/async.js:665:13
at iterate 

Bug#1036658: release-notes: 5.1.8. rsyslog creates fewer log files - mail.log is not dropped

[Paul Gevers]

Hi,

On 24-05-2023 16:36, Michael Biebl wrote:

Am 24.05.23 um 15:25 schrieb Christoph Anton Mitterer:

Anyway... if everyone agrees that we should leave out the rotated files
and leave that up to the user (which a note bout that being the case in
the release notes)... it would IMO be safer.

I could make a PR if desired so.


In the interest of keeping the list of file names short, I wouldn't 
duplicate them (one with .* and one without). But that's just a personal 
preference.


My proposal is here: 
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/180 (I 
don't like the repetition, but I feel it's best like that)


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1030835: [debian] ITP: ruff -- linter for Python, written in Rust

[James Addison]

Followup-For: Bug #1030835
X-Debbugs-Cc: charlie.r.ma...@gmail.com

Hi Charlie,

I'd like for 'ruff' to be packaged in Debian at some point, and am beginning
that process, although it could take some time (I'm not all that familiar with
Rust yet, and from what I've learned about the Debian rust utilities, automated
packaging is available for cargo-installable codebases, but is a more manual
process otherwise.  I've found and will follow the issuetracker item[1]).

Would you be OK with being listed as the upstream contact for a Debian 'ruff'
package, if-and-when it becomes available?

(as context: generally the Debian package maintainer will handle and filter
bugreports from Debian users without any need for your involvement (although
you could subscribe to activity if interested).  In some cases they could then
contact you with details about problems found and/or fixes discovered.  When
that process is working effectively, it should be mutually beneficial.

Cheers,
James

[1] - https://github.com/RustPython/RustPython/issues/4179

Bug#1036259: moment-timezone.js: FTBFS in testing: make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1

[gregor herrmann]

On Thu, 18 May 2023 09:00:03 +0200, Lucas Nussbaum wrote:

> During a rebuild of all packages in testing (bookworm), your package failed
> to build on amd64.
> 
> 
> Relevant part (hopefully):
> >  debian/rules binary
> > dh binary
> >dh_update_autotools_config
> >dh_autoreconf
> >debian/rules execute_before_dh_auto_configure
> > make[1]: Entering directory '/<>'
> > # Fail the build if the tzdata package does not match TZVER.
> > grep -q '^# version 2022g$' /usr/share/zoneinfo/tzdata.zi
> > make[1]: *** [debian/rules:28: execute_before_dh_auto_configure] Error 1

This looked reasonably easy to fix (cf. attached patch), but the
tests fail as follows:

#v+
Running "nodeunit:countries" (nodeunit) task
Testing countries.jsFF
>> countries - zone_countries
>> Error: [] deepEqual [ 'CA' ]
>> at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
>> at Object.zone_countries (tests/countries/countries.js:230:8)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at /usr/share/nodejs/nodeunit/lib/core.js:236:16
>> at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
>> at /usr/share/nodejs/nodeunit/lib/core.js:118:25
>> at /usr/share/javascript/async/async.js:665:13
>> at iterate (/usr/share/javascript/async/async.js:149:13)
>> at async.eachSeries (/usr/share/javascript/async/async.js:165:9)

>> countries - zone_countries
>> Error: [ 'US' ] deepEqual [ 'UM', 'US' ]
>> at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
>> at Object.zone_countries (tests/countries/countries.js:552:8)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at /usr/share/nodejs/nodeunit/lib/core.js:236:16
>> at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
>> at /usr/share/nodejs/nodeunit/lib/core.js:118:25
>> at /usr/share/javascript/async/async.js:665:13
>> at iterate (/usr/share/javascript/async/async.js:149:13)
>> at async.eachSeries (/usr/share/javascript/async/async.js:165:9)

>> countries - country_zones
>> Actual:
>>   [
>> 'America/Atikokan',  'America/Blanc-Sablon',
>> 'America/Cambridge_Bay', 'America/Creston',
>> 'America/Dawson','America/Dawson_Creek',
>> 'America/Edmonton',  'America/Fort_Nelson',
>> 'America/Glace_Bay', 'America/Goose_Bay',
>> 'America/Halifax',   'America/Inuvik',
>> 'America/Iqaluit',   'America/Moncton',
>> 'America/Panama','America/Phoenix',
>> 'America/Puerto_Rico',   'America/Rankin_Inlet',
>> 'America/Regina','America/Resolute',
>> 'America/St_Johns',  'America/Swift_Current',
>> 'America/Toronto',   'America/Vancouver',
>> 'America/Whitehorse','America/Winnipeg'
>>   ]
>> Operator:
>>   deepEqual
>> Expected:
>>   [
>> 'America/Atikokan',  'America/Blanc-Sablon',
>> 'America/Cambridge_Bay', 'America/Creston',
>> 'America/Dawson','America/Dawson_Creek',
>> 'America/Edmonton',  'America/Fort_Nelson',
>> 'America/Glace_Bay', 'America/Goose_Bay',
>> 'America/Halifax',   'America/Inuvik',
>> 'America/Iqaluit',   'America/Moncton',
>> 'America/Panama','America/Phoenix',
>> 'America/Puerto_Rico',   'America/Rankin_Inlet',
>> 'America/Regina','America/Resolute',
>> 'America/St_Johns',  'America/Swift_Current',
>> 'America/Toronto',   'America/Vancouver',
>> 'America/Whitehorse','America/Winnipeg',
>> 'America/Yellowknife'
>>   ]
>> at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
>> at Object.country_zones (tests/countries/countries.js:646:8)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at /usr/share/nodejs/nodeunit/lib/core.js:236:16
>> at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
>> at /usr/share/nodejs/nodeunit/lib/core.js:118:25
>> at /usr/share/javascript/async/async.js:665:13
>> at iterate (/usr/share/javascript/async/async.js:149:13)
>> at /usr/share/javascript/async/async.js:160:25

>> countries - country_zones
>> Actual:
>>   [
>> 'Pacific/Midway',
>> 'Pacific/Pago_Pago',
>> 'Pacific/Tarawa',
>> 'Pacific/Wake'
>>   ]
>> Operator:
>>   deepEqual
>> Expected:
>>   [
>> 'Pacific/Honolulu',
>> 'Pacific/Midway',
>> 'Pacific/Pago_Pago',
>> 'Pacific/Tarawa',
>> 'Pacific/Wake'
>>   ]
>> at Object.deepEqual (/usr/share/nodejs/nodeunit/lib/types.js:83:39)
>> at Object.country_zones (tests/countries/countries.js:839:8)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at Object. (/usr/share/nodejs/nodeunit/lib/core.js:236:16)
>> at /usr/share/nodejs/nodeunit/lib/core.js:236:16
>> at Object.exports.runTest (/usr/share/nodejs/nodeunit/lib/core.js:70:9)
>> at 

Bug#712781: src:scilab: please use SLICOT Debian package instead of embedded copy

[Sébastien Villemot]

Hi Pierre,

Le mercredi 24 mai 2023 à 10:45 +0200, Pierre Gruet a écrit :
> This is quite an old bug, bu I guess you might still have some interest in it.

Thanks for looking into it.

> I tried to use the contents of the slicot Debian package instead of the
> embedded files in scilab, but I get
> 
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `zb02mw_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `ricdmf_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `riccsl_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `fstair_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to `polmc_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `zb02ow_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `zb02mv_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to `ssxmc_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `ricdsl_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to `inva_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `ereduc_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `zb02ox_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `riccms_'
> /usr/bin/ld: ./modules/.libs/libscilab-cli.so: undefined reference to 
> `zb03od_'
> 
> At least some of the missing routines here are defined in
>   scilab/modules/cacsd/src/slicot/Ex-schur.f
> which has no equivalent in the source of the slicot Debian package.
> 
> By looking at the slicot website and at the contents of the Debian package
> for slicot, I guess no newer version of slicot should be expected to land
> into Debian?

The Debian package src:slicot contains a pre-release of version 5.0 of
Slicot, which was the last version distributed by upstream under the
GPL (later versions are proprietary).

However at some point upstream changed their mind and decided to stop
distributing the 5.0 release under the GPL, so they removed it from
their website. The website now has only has version 4.5 under the GPL.
We kept 5.0 in Debian because there is nothing that prevents us from
doing so from a legal point of view. Other projects (e.g. the “control”
package for Octave) do the same.

But it looks like the version of Slicot embedded in Scilab is even
older than 4.5, and corresponds to version 4.0. My guess is that the
missing symbols that you get correspond to functions that were removed
between 4.0 and 5.0.

Unfortunately this probably means that fixing the present bug requires
more work than just patching the build system (i.e. Scilab upstream
needs to move to a more recent Slicot).

Best wishes,

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



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

Bug#1026277: ITP: quadrilateralcowboy -- first-person cyberpunk adventure game

[James Addison]

Followup-For: Bug #1026277

There are a bunch of mistakes that I've made along the way while attempting to
package this game.  Some that I'd note are:

  * I could've made more of an effort and waiting longer for upstream contact
before listing an upstream email address (sorry for any resulting spam
received at the Blendo Games domain!).

  * Related, I could've made clear that I was the upstream source code provider
instead of leaning on an ambiguous Salsa-as-both-origin-and-package-VCS for
a while.

  * The number of package uploads to mentors.debian.net was large and noisy;
I was iterating fairly quickly on improvements and adjustments, and had not
yet discovered all the linting utilities available and how to run them
locally.

  * Version history is somewhat unclear - there is a mix of what I would call
the 'upstream' version numbers (timestamps in the format MMDD) - these
are what I have used to tag upstream versions of the code (where no
packaging information exists) and 'package' version numbers (these include
single-digit prefixes, plus a package-version suffix).

This is most relevant in the case of the 20160725 release, which I think
could be the point at where my upstream version begins to more-clearly
diverge from the original Blendo Games codebase (by the addition of a
second architecture).

As part of the packaging process, upstream version 20160725 became version
0~20160725-1 of the package, and I'd consider the changes between there and
1~20160725-1 to be Debian-related: they weren't particularly relevant to my
identity as upstream developer, but they did help the package become more
applicable to Debian's architectures (not all, unfortunately, but I think
that adding support for a second runtime architecture can be a big step
for compiled software).

That change, and the change to add a manual, have been included into the
'upstream' codebase.  Strictly speaking, the additional architecture
support probably should've been a patch, followed by merge upstream,
followed by inclusion and then patch-drop in the package.  They have been
offered to the 'original upstream' codebase, for possible integration there
if that's something that Brendan / Blendo Games would find useful.

I guess that some remaining confusion arises from the fact that despite
me managing both upstream and Debian packages currently, there are still
patches in the 'debian/patches' directory.  That does seem odd to me and I
should probably take another look at including those into the upstream
codebase.  I think my original plan with those was to gradually offer them
to 'original upstream' and drop them from the Debian package if-and-when
accepted.  Trying to remember/figure out my logic for why not all of them
are offered upstream.. my best guess is that I've only offered ones that I
think were unlikely to cause compatibility difficulties (so changing file
paths, for example, is _not_ offered upstream) with the original.  But I
could be retroactively making that up.

  * Insufficient testing on the second architecture port - I got it running
incredibly slowly in an emulator -- enough to confirm that it runs,
basically, but not more than that.

  * My release signing has been inconsistent, partly because I'm not sure I
have a long-term commitment to being a Debian Maintainer/Developer, and
partly because I'm not sure I can reliably keep those keys secure (so, at
best I think they would provide some integrity verification support, but
I don't think they really attest highly that I'm the sole or uncompromised
author).  Not a particularly useful mindset to have, some might argue, but
it does lead to me towards using ephemeral keypairs (somewhere, once, I had
some web-of-trust identity, but I haven't continued to use or maintain it).

All of these are avoidable problems - and in fact most of them are documented,
but I found it tricky to find all of those details and to keep them in mind;
even now I expect I would notice and learn more when reading through the
packaging guidelines again.  Generally it's been a good learning experience
though.  If any of the problems with the package make it ineligible for some
reason, that's a shame, but I can manage.  Otherwise, I'll be glad to fix
things up where required and think about ideas to make those problems less
likely for others to encounter (without reducing resulting package quality).

Bug#566801: jeuclid-cli does not work on simple example

[Mathieu Malaterre]

Control: fixed -1 3.1.9-5

On Sun, May 28, 2023 at 5:39 PM Mathieu Malaterre  wrote:
>
> On Sun, May 28, 2023 at 3:21 PM Pierre Gruet  wrote:
> >
> > Control: tags -1 moreinfo unreproducible
> >
> > Hi Matthieu,
> >
> > Doing some bug triaging...
> >
> > Does the issue you submitted still show up? On my machine with
> > jeuclid-cli/3.1.9-5, is does not.
>
> Can you post your exact command line ?

Nevermind this is included in my original report.

I cannot reproduce it today. Let's close this issue for good.

Thank you

Bug#1036882: RFS: jimtcl/0.82-1 -- small-footprint implementation of Tcl - shared library

[Bo YU]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : jimtcl
   Version  : 0.82-1
   Upstream contact : [fill in name and email of upstream]
 * URL  : http://jim.tcl.tk/
 * License  : BSD-2-clause, TCL
 * Vcs  : https://salsa.debian.org/debian/jimtcl
   Section  : devel

The source builds the following binary packages:

  jimsh - small-footprint implementation of Tcl named Jim
  libjim-dev - small-footprint implementation of Tcl - development files
  libjim0.82 - small-footprint implementation of Tcl - shared library

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/j/jimtcl/jimtcl_0.82-1.dsc

Changes since the last upload:

 jimtcl (0.82-1) experimental; urgency=medium
 .
   * New upstream release.
   * set --full default build options from upstream.(Closes: #1016657)

-- 
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1033065: release-notes: i386 notes should specify minimum CPU requirements

[Paul Gevers]

Hi,

On 11-05-2023 20:20, Paul Gevers wrote:

Please review my proposal here:

https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/166


The release notes now document that the baseline has been bumped.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036412: appconfig: diff for NMU version 1.71-2.2

[gregor herrmann]

Control: tags 1036412 + patch
Control: tags 1036412 + pending


Dear maintainer,

I've prepared an NMU for appconfig (versioned as 1.71-2.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   
diff -u appconfig-1.71/debian/changelog appconfig-1.71/debian/changelog
--- appconfig-1.71/debian/changelog
+++ appconfig-1.71/debian/changelog
@@ -1,3 +1,12 @@
+appconfig (1.71-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "Missing copyright info in d/copyright":
+add additional copyright holder, and update copyright years.
+(Closes: #1036412)
+
+ -- gregor herrmann   Sun, 28 May 2023 17:11:56 +0200
+
 appconfig (1.71-2.1) unstable; urgency=medium
 
   * Non maintainer upload by the Reproducible Builds team.
diff -u appconfig-1.71/debian/copyright appconfig-1.71/debian/copyright
--- appconfig-1.71/debian/copyright
+++ appconfig-1.71/debian/copyright
@@ -7,8 +7,9 @@
 The AppConfig copyright is as follows:
 
 COPYRIGHT
-Copyright (C) 1998 Canon Research Centre Europe Ltd. All Rights
-Reserved.
+Copyright (C) 1997,1998 Canon Research Centre Europe Ltd.
+Copyright (C) 1997-2007 Andy Wardley.
+All Rights Reserved.
 
 This module is free software; you can redistribute it and/or modify it
 under the same terms as Perl itself.


signature.asc
Description: Digital Signature

Bug#1036881: whitedune: segfaults

[Paul Gevers]

Package: whitedune
Version: 0.30.10-2.2
Severity: serious
Justification: segfaults

Hi,

I just tried to run whitedune, but it segfaults.

paul@mulciber ~ $ whitedune 
Segmentation fault (core dumped)
paul@mulciber ~ $ whitedune --version
white_dune whitedune-0.30.10
paul@mulciber ~ $ whitedune --help
Segmentation fault (core dumped)

Paul

-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages whitedune depends on:
ii  libc6   2.36-9
ii  libexpat1   2.5.0-1
ii  libgcc-s1 [libgcc1] 12.2.0-14
ii  libgl1  1.6.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1.1
ii  libjpeg62-turbo 1:2.1.5-2
ii  libpng16-16 1.6.39-2
ii  libstdc++6  12.2.0-14
ii  libx11-62:1.8.4-2
ii  libxi6  2:1.8-1+b1
ii  libxm4  2.3.8-3
ii  libxmu6 2:1.1.3-3
ii  libxt6  1:1.2.1-1.1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages whitedune recommends:
ii  xfonts-100dpi  1:1.0.5
ii  xfonts-75dpi   1:1.0.5

Versions of packages whitedune suggests:
pn  whitedune-docs  
pn  x-www-browser   

-- no debconf information

Bug#1034943: closed by Debian FTP Masters (reply to Andrew Lee (李健秋) ) (Bug#1034943: fixed in liblxqt 1.2.0-7)

[Helmut Grohne]

Control: reopen -1

Hi,

On Sat, May 13, 2023 at 10:24:06AM +, Debian Bug Tracking System wrote:
> #1034943: liblxqt1-dev: missing Breaks+Replaces for liblxqt0-dev when 
> upgrading from bullseye
> 
> It has been closed by Debian FTP Masters  
> (reply to Andrew Lee (李健秋) ).

When this was fixed, Breaks and Replaces were declared agains liblxqt0
rather than liblxqt0-dev. In effect, this means that the bug still
applies and liblxqt1-dev is RC buggy.

You can no longer fix this for the initial bookworm release. Please send
a spu bug to the release team to update the first stable point release
instead.

Helmut

Bug#922815: insserv: FATAL: service mountkernfs has to be enabled to use service keyboard-setup.sh

[Thomas Deutschmann]

Hi,

I saw that message today while upgrading bookworm RC3 to RC4:


[...]
Setting up console-setup-linux (1.221) ...
insserv: FATAL: service mountkernfs has to be enabled to use service 
keyboard-setup.sh
[...]


Note: The system was recently upgraded from Debian 8 (without systemd) 
to Debian 9 (where I switched to systemd) to Debian 12.


In my case it looks like insserv was a leftover of


$ aptitude why insserv
i   chkconfig Recommends insserv


I purged both packages.


--
Regards,
Thomas

Bug#1036880: unblock: pyocd/0.13.1+dfsg-3

[Martin Hostettler]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: py...@packages.debian.org, Adrian Bunk 
Control: affects -1 + src:pyocd

[I'm not the uploader of the update, but filing to meet the deadline]

Please unblock package pyocd

This upload backports upstream changes to support the python version in
bookworm.

[ Reason ]
The current version in bookworm is not compatible with the python version
in bookworm.

[ Impact ]
Using pyocd-gdbserver currently crashes.

[ Tests ]
Manually tested that it no longer crashes on start. I did not test further.

[ Risks ]
If the fix did not work debian would be shipping a broken package, if this
package is not removed before release.

On the other hand if the upstream fix works as expected debian bookworm
users will still be able to debug their microcontroller projects and will
still have packages for yotta and firmware-microbit-micropython.

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

[ Other info ]
I've reviewed the complete diffoscope
--exclude-directory-metadata=recursive output and there are only the
expected changes in the python code for importing, some minor changes from
building with a more up to date dh_python3/debhelper version and very minor
changes in man pages. 

[ Full debdiff ]
File lists identical (after any substitutions)

Control files: lines which differ (wdiff format)

Version: [-0.13.1+dfsg-2-] {+0.13.1+dfsg-3+}


unblock pyocd/0.13.1+dfsg-3

Bug#1035679: [Pkg-zsh-devel] Bug#1035679: zsh: can misprocess continue in a loop

[brian m. carlson]

On 2023-05-08 at 00:58:24, Axel Beckert wrote:
> brian m. carlson wrote:
> > This breaks the Git testsuite under zsh's sh mode,
> 
> Hmmm, actually, your example code shows "set" for me even without sh
> emulation mode:
> 
>   → zsh continue.sh
>   set
>   → zsh --emulate sh continue.sh
>   set

Correct.  The Git testsuite only runs under sh mode, not zsh mode, but
it affects all modes.

> > which was formerly passing.
> 
> When was "formerly", i.e. in which package or upstream version?

Git 2.25.  It may be that Git has changed the testsuite to make use of
that syntax between now and then, but as of that revision, it passed.

> > since the release cycle tends to be long
> 
> Well, 5.9 is out for quite a while already. So I think we can expect a
> new release before the the Debian 13 release. ;-)
> 
> But yeah, I think we can cherry-pick this from upstream after the
> Bookworm release.

Great, I appreciate that.

> > and it prevents the shell from being effectively used as a POSIX sh.
> 
> Well, zsh's POSIX mode is officially declared as being incomplete and
> it's IIRC also not recommended to actually use it or at least not rely
> on it.

zsh should be able to run as a POSIX sh.  The reason that we only
support sh mode in Git is that we rely on every command in a pipeline
being run in a subshell, since we only recently introduced the use of
`local` in the shell and otherwise our variables get messed up.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA


signature.asc
Description: PGP signature

Bug#1036879: oce: should this package be removed for trixie?

[Timo Röhling]

Source: oce
Version: 0.18.3-2
Severity: serious
Tags: trixie sid
User: debian...@lists.debian.org
Usertags: proposed-removal
Control: block -1 by 1036878

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

the package src:oce has just the single reverse dependency src:horizon-eda,
which also builds with src:opencascade. Given that src:oce has been
abandoned by upstream, we suggest to remove it once bookworm is released and
src:horizon-eda is confirmed to work correctly with src:opencascade.


Cheers
Timo


-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmRzYAUACgkQ+C8H+466
LVmB0AwA398NKpFpC8xI/OnIST1nE26Jy+Bz92i8QNAXQRS1J0qcw3kRmY6GGxYG
LzEwYArm1vCzL3bV6SADHhCP1/RHXupz+0EDLFx+C/L3frbzVKItuxVAoydJo5rb
Pf11wsXK8F3pq3dbJHeQM33Vd1c3zrtJP68qgzFjavWiIiMcQfbXbhB4YV2H+nIR
ZMuqM+94z2eFN7MP7GymIx9JJkxy+PZ0uP0o6xyKx4I9FNxY+OpvEQ41C6Q753Xl
/E5qlPNqdnrNOG9kfFnY2wABOUNmYUpKJTVJFB+8rwiNKbSiv2uYEOMz1o8uCV3m
iYVisO35HK3WAiZs80l7LqQ0gAga+Jc/TVz5UFrpDzxduWLhDnyqIrukd6EgO+Tq
sRbWNKbAG0Cp5LceoBtjEs8Pa/uREPZA/MH96SnooAmHg3Ax9o5sGoj34cCka6Mx
8Y7hvhp9pAsjmGyRsPlToEmaOBGve+Jwhlrh4pUl+Ae1n0kUWOd/2yuO0m/eLXt5
VFqKpjGn
=bAcG
-END PGP SIGNATURE-

Bug#1036878: horizon-eda: Please migrate from oce to occt

[Tobias Frost]

Source: horizon-eda
Severity: important
Tags: patch

Hi,

we are planing to remove oce from Debian in the trixie release cycle
and only keep occt (src:opencascade)

horizon-eda is the last package that depends on oce. Changing the B-D
from liboce-ocaf-dev to libocct-data-exchange-dev should do the trick,
at least it still compiles :)

Attached the patch I've used to compile it.

-- 
Thanks and Cheers,
tobi


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_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
diff -Naur horizon-eda-2.4.0.orig/debian/control 
horizon-eda-2.4.0/debian/control
--- horizon-eda-2.4.0.orig/debian/control   2022-08-22 15:01:24.0 
+0200
+++ horizon-eda-2.4.0/debian/control2023-05-28 15:51:37.507412919 +0200
@@ -7,7 +7,7 @@
  libsqlite3-dev, util-linux (>= 2.29), librsvg2-dev, libcairomm-1.0-dev,
  libepoxy-dev, libgtkmm-3.0-dev, uuid-dev, libboost-dev, libzmq5,
  cppzmq-dev, libglm-dev, libgit2-dev, libcurl4-gnutls-dev,
- liboce-ocaf-dev, libdxflib-dev (>> 3.17.0), libspnav-dev, libarchive-dev,
+ libocct-data-exchange-dev, libdxflib-dev (>> 3.17.0), libspnav-dev, 
libarchive-dev,
  libzip-dev, libglib2.0-dev, libpodofo-dev, python3-cairo-dev, libosmesa6-dev,
  libpython3-dev, dh-python
 Standards-Version: 4.4.0

Bug#1036877: ecasound: Homepage is wrong

[Francesco Ariis]

Package: ecasound
Version: 2.9.3-4+b1
Severity: minor
X-Debbugs-Cc: fa...@ariis.it

Dear Maintainer,

ecasound homepage has sadly been snatched up by cryptocrap.
See:

$ apt-cache show ecasound | grep http
Homepage: https://www.eca.cx/ecasound/

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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 ecasound depends on:
ii  libasound21.2.8-1+b1
ii  libaudiofile1 0.3.6-5+b1
ii  libc6 2.36-9
ii  libgcc-s1 12.2.0-14
ii  libjack0 [libjack-0.125]  1:0.126.0-2
ii  liblilv-0-0   0.24.14-1
ii  liblo70.31-1
ii  libreadline8  8.2-1.3
ii  libsamplerate00.2.2-3
ii  libsndfile1   1.2.0-1
ii  libstdc++612.2.0-14
ii  libtinfo6 6.4-4

Versions of packages ecasound recommends:
ii  faad  2.10.1-1
ii  lame  3.100-6
ii  mikmod3.2.8-3
ii  mpg1231.31.2-1
ii  timidity  2.14.0-8.1
ii  vorbis-tools  1.4.2-1+b1

Versions of packages ecasound suggests:
pn  ecatools 
pn  nama 
ii  swh-plugins [ladspa-plugin]  0.4.17-2

-- no debconf information

Bug#1036591: reaver: segmentation fault

[Bartosz Fenski]

Hey,

I'm fine with NMUing it. Thanks for your effort.

regards
Bartosz Fenski

W dniu 23.05.2023 o 23:21, Samuel Henrique pisze:

Control: tags -1 patch fixed-upstream

Hello Bartosz,

We are planning to perform an NMU, changing the package's maintership
to the Security Tools team (while keeping you as an Uploader), fixing
this RC bug and filling an unblock request so we can ship this package
for bookworm.

Please let me know if you disagree, we will have to act quickly due to
the freeze.

Andrey, Leandro meant to use the "patch" tag instead of "fixed", here's his fix:
https://salsa.debian.org/leandrocunha/reaver

Cheers,

Bug#1036876: Consider documenting that booting from partial volume groups is no longer supported.

[Martin Hostettler]

Package: release-notes
Severity: wishlist
X-Debbugs-Cc: Debian LVM Team , Guilhem Moulin 
, Bastian Blank 

In
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018730
we have learned that debian was previously able to boot from lvm volume
groups that were not complete while running in the initramfs and that
bookworm will no longer support this.

Please consider adding this change to the release notes, if appropriate.

 - Martin

Bug#1036871: task-lxqt-desktop: When the laptop wakes up from sleep, the display is garbled.

[Cyril Brulebois]

Hi kalanga,

kalanga  (2023-05-28):
> Package:    task-lxqt-desktop
> Version:    3.73
> Severity:    important
> X-Debbugs-Cc:    kala...@gmail.com
> 
> Dear Maintainer,
> 
> Installed task-lxqt-desktop using bookworm rc3 installer.
> Sleeping the laptop by closing the lid appears to function.
> Opening the lid to wake the laptop results in a garbled screen.
> I can enter the password on what I think is the screen saver as it causes a
> change in the garbled screen but the screen is still garbled and
> consequently the system is usuable.
> 
> I tried other desktops including mate and xfce and sleep functionality and
> waking work as expected  with the same hardware.
> I note that the lxqt is using wayland while the other desktops I tried are
> using x11 for their graphics.

Thanks for your report. Looping in the lxqt team.

Note that Bookworm RC 4 released a few hours ago has an important tweak
regarding which packages are pulled by task-lxqt-desktop. I have no idea
whether having only the packages installed by RC 4 would help for this
specific issue though.


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


signature.asc
Description: PGP signature

Bug#1036875: python-tornado: CVE-2023-28370

[Salvatore Bonaccorso]

Source: python-tornado
Version: 6.2.0-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-tornado.

CVE-2023-28370[0]:
| Open redirect vulnerability in Tornado versions 6.3.1 and earlier
| allows a remote unauthenticated attacker to redirect a user to an
| arbitrary web site and conduct a phishing attack by having user access
| a specially crafted URL.


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-28370
https://www.cve.org/CVERecord?id=CVE-2023-28370
[1] 
https://github.com/tornadoweb/tornado/commit/32ad07c54e607839273b4e1819c347f5c8976b2f

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1036874: kanboard: CVE-2023-32685

[Salvatore Bonaccorso]

Source: kanboard
Version: 1.2.26+ds-2
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for kanboard.

CVE-2023-32685[0]:
| Clipboard based cross-site scripting (blocked with default CSP)

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-32685
https://www.cve.org/CVERecord?id=CVE-2023-32685
[1] https://github.com/kanboard/kanboard/security/advisories/GHSA-hjmw-gm82-r4gv

Regards,
Salvatore

Bug#1036873: Don't Depend on transitional package ghostscript-x

[Dan Jacobson]

Package: gv
Version: 1:3.7.4-2+b1

# aptitude show ghostscript-x
Description: transitional package for ghostscript
 This is a transitional package and can safely be removed.

# dpkg -P ghostscript-x
dpkg: dependency problems prevent removal of ghostscript-x:amd64:
 gv depends on ghostscript-x.

Bug#1036872: net.sourceforge.jeuclid.MathMLParserSupport fails to parse XML strings

[Pierre Gruet]

Package: libjeuclid-core-java
Version: 3.1.9-5
Severity: normal

Dear Maintainer,

While running scilab, I met an issue with MathML labels for axes, that were not
showing up. After digging into this, I saw this was a bug in
libjeuclid-core-java and I built the following minimal non-working example:

8<--

import java.io.IOException;
import javax.xml.parsers.ParserConfigurationException;
import org.xml.sax.SAXException;
import net.sourceforge.jeuclid.MathMLParserSupport;

public class Main {
public static void main(String[] args) throws IOException, 
ParserConfigurationException, SAXException {
String str = new 
String("dydx=1y2");
System.out.println(MathMLParserSupport.parseString(str));
}
}

8<--

The output is:

8<--
[#document: null]
8<--

Thanks a lot for your help on this,

Cheers,

-- 
Pierre

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

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

Versions of packages libjeuclid-core-java depends on:
ii  libbatik-java1.16+dfsg-1
ii  libcommons-logging-java  1.2-3
ii  libxmlgraphics-commons-java  2.8-2

libjeuclid-core-java recommends no packages.

libjeuclid-core-java suggests no packages.

-- no debconf information

Bug#1036871: task-lxqt-desktop: When the laptop wakes up from sleep, the display is garbled.

[kalanga]

Package:    task-lxqt-desktop

Version:    3.73

Severity:    important

X-Debbugs-Cc:    kala...@gmail.com

Dear Maintainer,


Installed task-lxqt-desktop using bookworm rc3 installer.
Sleeping the laptop by closing the lid appears to function.
Opening the lid to wake the laptop results in a garbled screen.
I can enter the password on what I think is the screen saver as it 
causes a change in the garbled screen but the screen is still garbled 
and consequently the system is usuable.


I tried other desktops including mate and xfce and sleep functionality 
and waking work as expected  with the same hardware.
I note that the lxqt is using wayland while the other desktops I tried 
are using x11 for their graphics.


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages task-lxqt-desktop depends on:
ii  lxqt   31
ii  sddm   0.19.0-5
ii  sddm-theme-breeze [sddm-theme] 4:5.27.2-1
ii  sddm-theme-debian-breeze [sddm-theme]  4:5.27.2-1
ii  sddm-theme-debian-elarun [sddm-theme]  0.19.0-5
ii  task-desktop   3.73
ii  tasksel    3.73

Versions of packages task-lxqt-desktop recommends:
ii  hunspell-en-us  1:2020.12.07-2
ii  hyphen-en-us    2.8.8-7
ii  libreoffice-calc    4:7.4.5-2
ii  libreoffice-gtk3    4:7.4.5-2
ii  libreoffice-help-en-us  4:7.4.5-2
ii  libreoffice-impress 4:7.4.5-2
ii  libreoffice-qt5 4:7.4.5-2
ii  libreoffice-writer  4:7.4.5-2
ii  mythes-en-us    1:7.5.0-1
ii  orca    43.1-1
ii  synaptic    0.91.3
ii  system-config-printer   1.5.18-1
ii  xsane   0.999-12+b1

task-lxqt-desktop suggests no packages.

-- no debconf information

lspci output:

00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 
15h (Models 10h-1fh) Processor Root Complex [1022:1410]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) Processor Root Complex [1022:1410]
00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Richland [Radeon HD 8650G] [1002:990b]

    DeviceName: 16
    Subsystem: Hewlett-Packard Company Richland [Radeon HD 8650G] 
[103c:1992]

    Kernel driver in use: radeon
    Kernel modules: radeon, amdgpu
00:01.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] 
Trinity HDMI Audio Controller [1002:9902]
    Subsystem: Hewlett-Packard Company Trinity HDMI Audio Controller 
[103c:1992]

    Kernel driver in use: snd_hda_intel
    Kernel modules: snd_hda_intel
00:04.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1414]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Trinity A-series APU 
[1022:1234]

    Kernel driver in use: pcieport
00:05.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1415]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) Processor Root Port [1022:1234]

    Kernel driver in use: pcieport
00:07.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Family 15h 
(Models 10h-1fh) Processor Root Port [1022:1417]
    Subsystem: Advanced Micro Devices, Inc. [AMD] Family 15h (Models 
10h-1fh) Processor Root Port [1022:1234]

    Kernel driver in use: pcieport
00:10.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH 
USB XHCI Controller [1022:7814] (rev 09)

    Subsystem: Hewlett-Packard Company FCH USB XHCI Controller [103c:1992]
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci
00:10.1 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH 
USB XHCI Controller [1022:7814] (rev 09)

    Subsystem: Hewlett-Packard Company FCH USB XHCI Controller [103c:1992]
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci
00:11.0 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] FCH 
SATA Controller [AHCI mode] [1022:7801] (rev 40)
    Subsystem: Hewlett-Packard Company FCH SATA Controller [AHCI mode] 
[103c:1992]

    Kernel driver in use: ahci
    Kernel modules: ahci
00:12.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH 
USB OHCI Controller [1022:7807] (rev 11)

    Subsystem: Hewlett-Packard Company FCH USB OHCI Controller [103c:1992]
    Kernel driver in use: ohci-pci
    Kernel modules: ohci_pci
00:12.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] FCH 
USB EHCI Controller [1022:7808] (rev 11)

    Subsystem: Hewlett-Packard Company FCH USB EHCI Controller [103c:1992]
    Kernel driver in use: ehci-pci
    Kernel 

Bug#1036870: sane-backends: Please update .tarball-version

[Jan Binder]

Source: sane-backends
Version: 1.2.1-2
Severity: minor

Dear Maintainer,

please consider updating the .tarball-version file that 0040-remove_git.patch
creates to accurately reflect the version of the source code.

The version in that file does show up in debug traces.


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

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

Bug#1036869: ghostscript: Needs commitment for Debian downstream maintenance

[Salvatore Bonaccorso]

Source: ghostscript
Version: 10.0.0~dfsg-11
Severity: serious
Justification: commitment for maintenance
X-Debbugs-Cc: car...@debian.org, t...@security.debian.org

Hi

ghostscript is orphaned and unter the Debian QA group. ghostscript
beeing a package with recurring need of maintenance and in particular
which from time to time needs addressing CVEs needs active
maintainership.

This bug serves to make the package appear on the radar of packages
requiring active maintainers.

Regards,
Salvatore

Bug#1036530: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)

[Mario Limonciello]

On 5/28/23 01:49, Salvatore Bonaccorso wrote:

Hi Mario

Nick Hastings reported in Debian in https://bugs.debian.org/1036530
lockups from his system after updating from a 6.0 based version to
6.1.y. >
#regzbot ^introduced 24867516f06d

he bisected the issue and tracked it down to:

On Sun, May 28, 2023 at 10:14:51AM +0900, Nick Hastings wrote:

Control: tags -1 - moreinfo

Hi,

I repeated the git bisect, and the bad commit seems to be:

(git)-[v6.1-rc1~206^2~4^5~3|bisect] % git bisect bad
24867516f06dabedef3be7eea0ef0846b91538bc is the first bad commit
commit 24867516f06dabedef3be7eea0ef0846b91538bc
Author: Mario Limonciello 
Date:   Tue Aug 23 13:51:31 2022 -0500

 ACPI: OSI: Remove Linux-Dell-Video _OSI string
 
 This string was introduced because drivers for NVIDIA hardware

 had bugs supporting RTD3 in the past.
 
 Before proprietary NVIDIA driver started to support RTD3, Ubuntu had

 had a mechanism for switching PRIME on and off, though it had required
 to logout/login to make the library switch happen.
 
 When the PRIME had been off, the mechanism had unloaded the NVIDIA

 driver and put the device into D3cold, but the GPU had never come back
 to D0 again which is why ODMs used the _OSI to expose an old _DSM
 method to switch the power on/off.
 
 That has been fixed by commit 5775b843a619 ("PCI: Restore config space

 on runtime resume despite being unbound"). so vendors shouldn't be
 using this string to modify ASL any more.
 
 Reviewed-by: Lyude Paul 

 Signed-off-by: Mario Limonciello 
 Signed-off-by: Rafael J. Wysocki 

  drivers/acpi/osi.c | 9 -
  1 file changed, 9 deletions(-)

This machine is a Dell with an nvidia chip so it looks like this really
could be the commit that that is causing the problems. The description
of the commit also seems (to my untrained eye) to be consistent with the
error reported on the console when the lockup occurs:

[   58.729863] ACPI Error: Aborting method \_SB.PCI0.PGON due to previous error 
(AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
[   58.729904] ACPI Error: Aborting method \_SB.PCI0.PEG0.PG00._ON due to 
previous error (AE_AML_LOOP_TIMEOUT) (20220331/psparse-529)
[   60.083261] vfio-pci :01:00.0 Unable to change power state from D3cold 
to D0, device inaccessible

Hopefully this is enough information for experts to resolve this.


Does this ring some bell for you? Do you need any further information
from Nick?

Regards,
Salvatore


Hi Salvatore,

Have Nick try using "pcie_port_pm=off" and see if it helps the issue.

Does this happen in the latest 6.4 RC as well?

I think we need to see a full dmesg and acpidump to better characterize it.

Bug#1036033: upgrade-reports: bullseye -> bookworm kernel package upgrade fails when ddcci-dkms package installed

[Stephen Kitt]

Control: severity -1 normal
Control: tag -1 +moreinfo

Hi Tim,

On Sun, 14 May 2023 22:44:41 +0200, Andreas Beckmann  wrote:
> On 14/05/2023 19.43, Paul Gevers wrote:
> >> /etc/kernel/postinst.d/dkms:
> >> dkms: running auto installation service for kernel 6.1.0-7-amd64.
> >> Error! Could not locate dkms.conf file.
> >> File: /var/lib/dkms/ddcci/0.3.3/source/dkms.conf does not exist.
> >> dkms: autoinstall for kernel: 6.1.0-7-amd64 failed!  
> 
> How has ddcci-dkms been installed?
> How did the dkms.conf go missing?
> Please show the current layout of the source tree:
>ls -laR /usr/src/ddcci-*
> Why hasn't ddcci been upgraded to the bookworm version (0.4.2)?

Would it be possible for you to provide an update with the information
requested above? It would also be useful if you could provide the information
requested in the upgrade-reports template (the output of COLUMNS=200 dpkg
-l). I’m downgrading the bug’s severity pending this, since yours is the only
report so far with an upgrade error related to ddcci-dkms.

I’ve been trying to reproduce this, but have so far been unable to,
regardless of the upgrade order or combination (upgrading dkms but not
ddcci-dkms, upgrading the kernel, etc.).

In particular, I would very much like to understand why dkms is complaining
about /var/lib/dkms/ddcci/0.3.3/source/dkms.conf even though the ddcci-dkms
package has seemingly been upgraded.

> PS: I don't see any errors during piuparts upgrade tests of ddcci-dkms + 
> linux-headers-amd64
> 
> PPS: Of course the bullseye version (0.3.3) will fail to build for a 6.1 
> kernel (if it gets that far), but that's nothing unexpected
> 
> PPPS: if you install the bookworm version of ddcci-dkms, it should a) 
> restore the missing file and b) be compatible with current kernels

Regards,

Stephen Kitt


pgpQXk30MAMaD.pgp
Description: OpenPGP digital signature

Bug#1036868: mlpack 4.1.0 available

[Dirk Eddelbuettel]

Severity: normal
Package: mlpack

mlpack 4.1.0 came out (relatively quietly) a month ago.  I think it should be
a fairly simple upgrade over 4.0.1. It would be nice if you could update it.

I stuck your 4.0.1 it my launchpad PPA for use on Ubuntu 22.04 which worked
fine as usual.  It needed python3-pip added to Build-Depends, no other
issues. Really nice to be able to use mlpack in header-only mode from R via
Rcpp now.

Dirk

--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#1036806: matrix-synapse: not suitable for inclusion in bookworm

[Salvatore Bonaccorso]

Hi

For those following the bugreport:

On Fri, May 26, 2023 at 09:19:59PM +0200, Salvatore Bonaccorso wrote:
> Hi Andrej,
> 
> On Fri, May 26, 2023 at 08:51:13PM +0200, Andrej Shadura wrote:
> > Hi,
> > 
> > On Fri, 26 May 2023, at 19:28, Salvatore Bonaccorso wrote:
> > > I believe matrix-synapse is still in the same status as for #982991
> > > back for the bullseye release, and not suitable to be included in
> > > bookworm as stable release.
> > 
> > In fact, I believe the situation has changed. Synapse it much more
> > stable, as is the Matrix protocol itself, and there weren’t that
> > many security issues.
> 
> For reference for the discussion: So there were at least the following
> CVEs I think since the removal (maybe more, this is just rought
> checking based on the CVE years):
> 
> https://security-tracker.debian.org/tracker/CVE-2023-32323
> https://security-tracker.debian.org/tracker/CVE-2022-41952
> https://security-tracker.debian.org/tracker/CVE-2022-39374
> https://security-tracker.debian.org/tracker/CVE-2022-39335
> https://security-tracker.debian.org/tracker/CVE-2022-31152
> https://security-tracker.debian.org/tracker/CVE-2022-31052
> 
> > > As such let it have removed from bookworm if you agree. If this is not
> > > correct, we need to have assurance security fixes arising during the
> > > bookworm cycle can be addressed.
> > 
> > I believe I will be able to backport fixes — or ask for removal
> > later if and when the need arises.
> 
> For the above CVEs, would have the fixes be isolated and backportable
> enough to guarantee that? If so and you are confident you will be able
> to backport the fixes, then please go ahead with closing this bug.
> 
> Personally I just would like to avoid we release bookworm with it, and
> after while we have already to go trought the removal request from
> stable.

Andrej checking on the above. If it's deemed feasible we will give it
a go.

Ideally though we should remove id now before the release if it's
unfeasable to maintain, because otheweise there are higher
expectations if it's in the initial release.

A removal needs to be requested directly as respective bug to the
release team, as autoremovals will likely not trigger right now for
this case.

Andrej, do yu have already some information?

Regards,
Salvatore

Bug#1035056: [pre-approval] plasma-desktop 5.27.X

[Aurélien COUDERC]

Le dimanche 28 mai 2023, 08:26:16 CEST Paul Gevers a écrit :
> Control: tags -1 confirmed moreinfo
> 
> Hi all,
> 
> [For those following at home, I had multiple live discussions with 
> Aurélien at the Debian Reunion Hamburg.]
> 
> On 27-05-2023 22:44, Aurélien COUDERC wrote:
> > I don’t have particular bugs in mind, I think the selection that upstream
> > makes of bugs that deserve a fix in their stable 5.27 branch makes sense 
> > for us to follow.
> 
> Ok, it's terribly late but let's go for this then.

❤❤❤

> You'll need to help a 
> bit more though. You want the full set to migrate together, so please 
> check the status of the upload you did yesterday and let me know when 
> everything is ready. That means that no package should be blocked on 
> anything except age and the freeze. Piuparts and autopkgtest runs must 
> have finished and when finished neither must block migration. Did you 
> mention you have a web page for that already, can you share the link?

Yes, that is [0].

[0] https://deb.li/plasma

The packages on the dashboard are sorted by layers of build dependencies then 
alphabetically in each layer. So you will find the packages further in the 
dependency tree at the bottom, and not all built yet.
The same dashboard for bookworm incorrectly reports breeze-grub as sucessfully 
built for mips64el and s390x but this was not the case.

We I don’t think we have the equivalent for autopkgtests / puiparts so I’ll 
check these manually.

> Also please prepare the correct set of hints, they need to be in the 
> form of:
> unblock package-name/version-in-unstable

That would be the list at the bottom.

We will confirm when all builds / tests have passed.


Cheers
--
Aurélien


unblock bluedevil/4:5.27.5-2
unblock breeze-grub/5.27.5-2
unblock breeze-plymouth/5.27.5-2
unblock drkonqi/5.27.5-2
unblock flatpak-kcm/5.27.5-2
unblock kactivitymanagerd/5.27.5-2
unblock kdecoration/4:5.27.5-2
unblock kgamma5/5.27.5-2
unblock kinfocenter/4:5.27.5-2
unblock kmenuedit/4:5.27.5-2
unblock kpipewire/5.27.5-3
unblock ksshaskpass/4:5.27.5-2
unblock kwallet-pam/5.27.5-2
unblock kwayland-integration/5.27.5-2
unblock kwrited/4:5.27.5-2
unblock layer-shell-qt/5.27.5-2
unblock libkscreen/4:5.27.5-2
unblock libksysguard/4:5.27.5-2
unblock milou/4:5.27.5-2
unblock oxygen-sounds/4:5.27.5-2
unblock plasma-discover/5.27.5-2
unblock plasma-disks/5.27.5-2
unblock plasma-firewall/5.27.5-2
unblock plasma-nano/5.27.5-2
unblock plasma-nm/4:5.27.5-2
unblock plasma-pa/4:5.27.5-2
unblock plasma-sdk/5.27.5-2
unblock plasma-thunderbolt/5.27.5-2
unblock plasma-welcome/5.27.5-2
unblock plasma-workspace-wallpapers/4:5.27.5-2
unblock plymouth-kcm/5.27.5-2
unblock polkit-kde-agent-1/4:5.27.5-2
unblock qqc2-breeze-style/5.27.5-2
unblock sddm-kcm/4:5.27.5-2
unblock xdg-desktop-portal-kde/5.27.5-2
unblock breeze/4:5.27.5-2
unblock kde-gtk-config/4:5.27.5-2
unblock kscreen/4:5.27.5-2
unblock kscreenlocker/5.27.5-2
unblock ksystemstats/5.27.5-2
unblock oxygen/4:5.27.5-2
unblock plasma-systemmonitor/5.27.5-2
unblock plasma-vault/5.27.5-2
unblock breeze-gtk/5.27.5-2
unblock kwin/4:5.27.5-3
unblock plasma-integration/5.27.5-2
unblock plasma-workspace/4:5.27.5-2
unblock kde-cli-tools/4:5.27.5.1-2
unblock kdeplasma-addons/4:5.27.5-2
unblock khotkeys/4:5.27.5-2
unblock plasma-bigscreen/5.27.5-2
unblock plasma-browser-integration/5.27.5-2
unblock plasma-desktop/4:5.27.5-2
unblock plasma-remotecontrollers/5.27.5-2
unblock powerdevil/4:5.27.5-2
unblock systemsettings/4:5.27.5-2

Bug#1036801: unblock: curl/7.88.1-10

[Salvatore Bonaccorso]

Hi Samuel,

On Sun, May 28, 2023 at 12:17:21PM +0100, Samuel Henrique wrote:
> Hello Salvatore,
> 
> > After a short discussion with Paul, wouldn't that imply though that
> > there is an soname bump needed? Do you know has upstream considered
> > this and if/or why not? Is there enough assurance nobody (even outside
> > Debian world) is using that symbol?
> 
> Those are all good questions, I should have done a better job at
> explaining this, so let me try doing it now.
> 
> sergiodj@ did a lot of work investigating this as well, so most of the
> things I'll be saying here are his findings (although if I say
> anything wrong here, blame it on me).
> 
> The "curl_jmpenv" variable declaration was guarded by a "#ifdef
> HAVE_SIGSETJMP", but the variable would only be used on "#ifdef
> USE_ALARM_TIMEOUT".
> For Debian, "HAVE_SIGSETJMP" is true but "USE_ALARM_TIMEOUT" is false,
> this is because we use the threaded resolver.
> 
> This means that "curl_jmpenv" was dead code, and double checking for
> mentions of "curl_jmpenv" on codesearch.d.n only returns packages
> which bundles curl, nothing using it.
> 
> Considering the variable was exposed, but not used anywhere (in our
> builds with threaded resolver), I don't think there was any possible
> way dependencies could be making use of it in any meaningful way (this
> is talking about things outside of our official repositories now).

Thank you, I believe this is very important information to allow to
decide on the unblock. Make sense now to me and for security-tracker
point of view I have marked the issue as unimportant (due the
implication of binary packages not affected from the affected source).

> It doesn't make sense for upstream to bump SONAME because the variable
> can still be exposed depending on the build config, it's just that it
> wasn't supposed to be exposed for threaded resolvers first of all.

Understood, I think.

> The CVE that is being fixed by that change should not affect our
> binaries since we build with the threaded resolver, but I ended up
> making a decision to still apply the patch to safeguard even the
> sources.

Ok. I have updated the security-tracker accordingly, since we have
source fixed, but binary packages not affected.

> > These are just a couple of question trying to understand what
> > potential question from release team members my come for your unblock
> > request.
> 
> Thank you for reviewing this.

Did not do much, but was sitting together with Paul from the release
team to go trough some unblock requests fixing CVEs and curl was yet
still on the radar of packages which did not pass.

> > p.s.: note it looks autopkgtest view for curl was still blocking it
> > because cwltool has a flaky test (on armel).
> 
> Yeah, curl suffers quite a bit from these since tons of reverse-deps
> use it to fetch resources over the network and that's always flaky
> (not sure if it's the case with cwitool specifically, but I'm used to
> this sort of thing by now).

Ok.

Regards and thanks for your work on curl!
Salvatore

Bug#1035543: init-system-helpers: new systemd units may not get enabled on upgrades from bullseye if systemd is installed

[Andreas Beckmann]

On 28/05/2023 11.58, Jochen Sprickerhof wrote:
The point of piuparts is that an upgraded system is different to a newly 
installed system, i.e. that the e2scrub_reap.service symlink lies in a 
different directory.


Actually the difference is between the minimal bullseye chroot upgraded 
to bookworm and the bullseye chroot with some packages to be tested 
installed (here: systemd) and upgraded to bookworm. Ideally, after 
removing the packages to be tested and their dependencies, the two 
bookworm chroots should be identical ...



Andreas

Bug#932957: Please migrate Release Notes to reStructuredText

[Stéphane Blondon]

> > Richard Lewis  wrote (Fri, 19 May
> 2023 00:58:26 +0100):
>
> > - are the red hyphens in eg the 'deb...' line near the top of
> > >
> https://people.debian.org/~holgerw/release-notes_sphinx/en/html/issues.html
> > > meant to be red? (maybe it is a syntax error?)
> >



Sphinx uses Pygments to highlight source code. I guess no language is
defined so Sphinx uses a wrong lexer. We should force Sphinx to use
'SourceListLexer' with:
.. code-block :: sources.list

Bug#1036801: unblock: curl/7.88.1-10

[Samuel Henrique]

Hello Salvatore,

> After a short discussion with Paul, wouldn't that imply though that
> there is an soname bump needed? Do you know has upstream considered
> this and if/or why not? Is there enough assurance nobody (even outside
> Debian world) is using that symbol?

Those are all good questions, I should have done a better job at
explaining this, so let me try doing it now.

sergiodj@ did a lot of work investigating this as well, so most of the
things I'll be saying here are his findings (although if I say
anything wrong here, blame it on me).

The "curl_jmpenv" variable declaration was guarded by a "#ifdef
HAVE_SIGSETJMP", but the variable would only be used on "#ifdef
USE_ALARM_TIMEOUT".
For Debian, "HAVE_SIGSETJMP" is true but "USE_ALARM_TIMEOUT" is false,
this is because we use the threaded resolver.

This means that "curl_jmpenv" was dead code, and double checking for
mentions of "curl_jmpenv" on codesearch.d.n only returns packages
which bundles curl, nothing using it.

Considering the variable was exposed, but not used anywhere (in our
builds with threaded resolver), I don't think there was any possible
way dependencies could be making use of it in any meaningful way (this
is talking about things outside of our official repositories now).

It doesn't make sense for upstream to bump SONAME because the variable
can still be exposed depending on the build config, it's just that it
wasn't supposed to be exposed for threaded resolvers first of all.

The CVE that is being fixed by that change should not affect our
binaries since we build with the threaded resolver, but I ended up
making a decision to still apply the patch to safeguard even the
sources.

> These are just a couple of question trying to understand what
> potential question from release team members my come for your unblock
> request.

Thank you for reviewing this.

> p.s.: note it looks autopkgtest view for curl was still blocking it
> because cwltool has a flaky test (on armel).

Yeah, curl suffers quite a bit from these since tons of reverse-deps
use it to fetch resources over the network and that's always flaky
(not sure if it's the case with cwitool specifically, but I'm used to
this sort of thing by now).

Cheers,

-- 
Samuel Henrique