Bug#1036940: openbox-menu: File $XDG_CONFIG_DIRS/applications.menu doesn't exist. Can't create menu.

[RAjib]

Package: openbox-menu
Version: 0.8.0+hg20161009-3.1
Severity: important
X-Debbugs-Cc: bkpsusmi...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
Invoking $sudo openbox-menu created the situation.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Couldn't do anything. Copied the report and posted on the debian-user ML
   * What was the outcome of this action?
Was suggested to post a Bug Report
   * What outcome did you expect instead?
Suggestion to bypass the issue. The Live ISO from which the system was
installed:
Official Debian GNU/Linux Live 11.6.0 lxde 2022-12-17T11:46

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


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

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

Versions of packages openbox-menu depends on:
ii  libc6   2.31-13+deb11u5
ii  libglib2.0-02.66.8-1
ii  libgtk2.0-0 2.24.33-2
ii  libmenu-cache3  1.1.0-1.1
ii  lxmenu-data 0.1.5-2.1
ii  openbox 3.6.1-9+deb11u1

openbox-menu recommends no packages.

openbox-menu suggests no packages.

Bug#987283: Fixed

[Salvatore Bonaccorso]

Hi,

On Tue, May 30, 2023 at 06:18:33AM +0200, Anton Gladky wrote:
> MR is merged
> 
> https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/114

Thanks for properly closing the bug, I forgot to do it when deploying
the changes on the live instance.

Regards,
Salvatore

Bug#987283: Fixed

[Anton Gladky]

MR is merged

https://salsa.debian.org/security-tracker-team/security-tracker/-/merge_requests/114

Anton

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/29/23 18:01, Nick Hastings wrote:

Hi,

* Nick Hastings  [230529 12:51]:

* 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 eventually see a lockup of this kernel. On the console I saw:

[  151.035036] vfio-pci :01:00.0 Unable to change power state from D3cold 
to D0, device inaccessible

I did not see the other two lines that were present in earlier lock ups >

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.


Please find attached the output from a "journalctl --system -bN" for a
kernel that has this issue.

Regards,

Nick.


In this log I see nouveau loaded, but I also don't see the failure 
occurring.


As you're actually loading nouveau, can you please try nouveau.runpm=0 
on the kernel command line?


If that helps the issue; I strongly suggest you cross reference the 
latest kernel to see if this bug still exists.

Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

[Dima Kogan]

Johannes Schauer Marin Rodrigues  writes:

> how about an option like this:
>
> --failure-hook='chroot "$1" bash'

I don't care about the exact command, as long as it's documented. This
suggestion sounds reasonable.


> Since all hooks have the MMDEBSTRAP_HOOK variable set, whatever is run in the
> hook would have access to the type of hook that failed.
>
> The information that would be missing would be *which* hook of a certain type
> was the one failing. I do not see a good way to communicate this information.

Ideally, mmdebstrap will tell you which command failed, so the user can
cut/paste the failing command to reproduce the failure. This maybe is
the most important thing to communicate? I might be missing the
subtleties of what you're thinking.


> Another question: what should be done if the failure-hook failed?

Hmmm. The obvious thing to say would be "It doesn't matter; we failed,
so mmdebstrap should just exit regardless". But maybe the hook can fix
whatever the failure was, and if the hook callback succeeds, mmdebstrap
can try again? In my usage of these in sbuild I'm always debugging
failures, so just exiting regardless is the right thing. But maybe
something smarter would be good too.


> Do you know of another software besides sbuild that has a similar interface?
> I'd like to get some more ideas first before I add another interface that
> mmdebstrap would have to support forever.

I can only thing of sbuild off the top of my head. But mmdebstrap
already has a hook system, so extending that in the way you suggested
above sounds like a self-consistent way to do it.


> I would rather not add the percent escapes from sbuild as that would
> mean that any percent sign in the hooks has to be escaped as well.
> This would break existing users of hooks.

Yeah. Let's conform to the existing mmdebstrap conventions


> I'd also like to add that you can already emulate this behaviour by
> running a hook like this:
>
> --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'

I would want to add the '|| chroot "$1" bash' to everything mmdebstrap
does: downloading packages, installing them, doing customization hooks,
etc, etc. The above just applies to customization hooks, right?

The actual failure I'd like to fix today is a failing "apt update"
trying to talk to my apt-cacher-ng server (for some reason the server
returns 502 only when mmdebstrap tries to talk to it). I don't believe
there's a nice way to debug this with mmdebstrap today, right? I tried
to use --SOMETHING-hook (don't remember what SOMETHING was), but it
wasn't clear what the exact failing command was, so I moved on to
something else. Printing the exact failing command for easy
reproducibility would be important. Maybe there's already a verbosity
level that does this?

Thanks much!

Bug#1036939: proj: reproducible-builds: build paths trigger differences

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 5/30/23 02:57, Vagrant Cascadian wrote:

The RPATH contains the build path resulting in different buildid and
various other differences:

   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/proj.html

The attached patch modifies debian/rules to pass
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to dh_auto_configure.


Also applied in git.

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

[Sebastiaan Couwenberg]

Control: tags -1 - moreinfo + pending

On 5/30/23 00:35, Vagrant Cascadian wrote:

On 2023-05-29, Sebastiaan Couwenberg wrote:

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

On 2023-05-29, Sebastiaan Couwenberg wrote:

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?


Tested! Works! Patch attached!


Thanks for confirming the theory. Applied in git.

Kind Regards,

Bas

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

Bug#1019868: godot: ftbfs on riscv64 ("undefined reference to `__atomic_compare_exchange_1'")

[Petter Reinholdtsen]

[Bo YU]
> The patch attached is to fix the issue and I have tested it on my
> local real riscv64 hardware.

The armel architecture need -latomic too.  Might be others as well.  I
am testing a variant of this patch now to verify it work on armel too.
-- 
Happy hacking
Petter Reinholdtsen

Bug#1036939: proj: reproducible-builds: build paths trigger differences

[Vagrant Cascadian]

Source: proj
Version: 9.1.1-1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The RPATH contains the build path resulting in different buildid and
various other differences:

  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/proj.html

The attached patch modifies debian/rules to pass
-DCMAKE_BUILD_RPATH_USE_ORIGIN=ON to dh_auto_configure.

With this patch applied (and the fix for #1035704 for timezone
differences), based on my local tests, proj should build reproducibly on
tests.reproducible-builds.org!

Thanks for maintaining proj!

live well,
  vagrant
From 8d10b60bdf740385e46bdba96b5b457825d34d2a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 29 May 2023 16:13:34 -0700
Subject: [PATCH 2/2] debian/rules: Pass -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON via
 dh_auto_configure.

This avoids embedding the full path in RPATH, which triggers BuildId
differences.

https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 3a624ff..b2ac4a2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,7 @@ override_dh_auto_clean:
 	dh_auto_clean
 
 override_dh_auto_configure: datumgrids
-	dh_auto_configure -- -DRUN_NETWORK_DEPENDENT_TESTS=OFF
+	dh_auto_configure -- -DRUN_NETWORK_DEPENDENT_TESTS=OFF -DCMAKE_BUILD_RPATH_USE_ORIGIN=ON
 
 override_dh_auto_test:
 # Ignore test failures on problematic architectures only
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

It didn't return anything. Neither did "locate 
'v0.9.4.4-ds-git20221205-12a9702d29ab'".

Bug#1036461: Please update to at least v7.0.1

[Nicholas D Steeves]

Control: fixed -1 easyeffects/7.0.1-1~exp1

Hi,

Boyuan Yang  writes:

> We could do bookworm-backport for easyeffects after Debian 12 release, no
> problem. The package belongs to Multimedia Team from the very beginning; its
> packaging repo can be moved to salsa multimedia-team at anytime.
>

Thanks for the quick ACK!  I've asked the Salsa admins to move the
project, and I've uploaded 7.0.1 to experimental, because it appears
that 7.0.2 will not be backportable due to GTK4-related changes that are
unsupported in bookworm's version of GTK4.  This upload also updates the
Vcs links.

I've left this bug open as a reminder to fix in sid (and as proof of
backport request) post-bookworm release.

Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#1036938: Debian Bug Tracking System

[yokota]

Package: libpodofo0.9.8
Version: 0.9.8+dfsg-3+b1
Severity: wishlist
X-Debbugs-Cc: yokota.h...@gmail.com

Dear Maintainer,

"libpodofo" project was moved to GitHub https://github.com/podofo/podofo .
And released 0.10.0 from there.
Please package them.

"calibre" package now needs libpodofo 0.10 API since Calibre 6.18.

PS: libpodofo 0.10 API is changed from 0.9 API. So you might need some package
transition request.

--
YOKOTA Hiroshi

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]

Hi,

* Nick Hastings  [230529 12:51]:
> * 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 eventually see a lockup of this kernel. On the console I saw:

[  151.035036] vfio-pci :01:00.0 Unable to change power state from D3cold 
to D0, device inaccessible

I did not see the other two lines that were present in earlier lock ups

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

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

[Vagrant Cascadian]

On 2023-05-29, Sebastiaan Couwenberg wrote:
> 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.
...
>>> 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.

I am not familiar with shar/unshar, but sure, adding support for
SOURCE_DATE_EPOCH would be welcome...

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

Tested! Works! Patch attached!

> Otherwise we'll have to upload to experimental.

As much as I would love to see it fixed in time for bookworm, my guess
is that it is a bit late already...


live well,
  vagrant
From 24865b8c2cda67a39774415e540dfc24ad243458 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 29 May 2023 15:28:36 -0700
Subject: [PATCH] debian/rules: Use UTC timezone when calling unshar. (Closes:
 #1035704)

Without this, the touch calls in debian/datumgrids*.shar result in
timezone-specific differences in various .gsb and .gtx files.

https://reproducible-builds.org/docs/timezones/
---
 debian/rules | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index a778f4d..3a624ff 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,8 +20,8 @@ UPSTREAM_VERSION = $(shell echo $(DEB_VERSION_UPSTREAM) | sed -e 's/\+.*//')
 
 datumgrids: datumgrids-stamp
 datumgrids-stamp:
-	unshar -c -d $(CURDIR)/data $(CURDIR)/debian/datumgrids.shar
-	unshar -c -d $(CURDIR)/data $(CURDIR)/debian/datumgrids-ch.shar
+	TZ=UTC unshar -c -d $(CURDIR)/data $(CURDIR)/debian/datumgrids.shar
+	TZ=UTC unshar -c -d $(CURDIR)/data $(CURDIR)/debian/datumgrids-ch.shar
 	touch $@
 
 %:
-- 
2.39.2



signature.asc
Description: PGP signature

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Mon, May 29, 2023 at 02:15:55PM -0700, Brian Vaughan wrote:
> Yes, that's what it starts with.
> 
> Metadata-Version: 2.1
> Name: python-lsp-black
> Version: 1.2.1
> [...]

OK, so the bug lies elsewhere  pkg_resources complains about an
invalid version.  Let's see if we can locate it

Does this command return anything?

rgrep v0.9.4.4-ds-git20221205-12a9702d29ab /usr/lib/python3/dist-packages

(For any pedants reading this bug report: yes, '.' is a wildcard and
ought to be escaped, but there is unlikely to be anything that matches
this regex other than an actual '.'.)

Best wishes,

   Julian

Bug#1036937: yaru-theme-gnome-shell: notifications do not disturb slider missing except in default Yaru variant

[Angel Segarra]

Package: yaru-theme-gnome-shell
Version: 22.10.3-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
 Changing gnome-shell theme to a variant other than 'Yaru', e.g. 'Yaru-dark'

   * What was the outcome of this action?
 The notifications do not disturbed slider is missing, the following is 
logged to the journal:
 Failed to load resource:///org/gnome/shell/theme/toggle-off-dark.svg: The 
resource at “/org/gnome/shell/theme/toggle-off-dark.svg” does not exist

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


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

-- no debconf information

Bug#1035741: vfu: Scrollbar works incorrectly

[Vladi Belperchinov-Shabanski]

hi,

fixed :) 

if entries are less than screen size, scroller will be hidden.

will be in the next release but can be pulled from github now.

thanks,
Vladi.

-- 
Vladi Belperchinov-Shabanski  
   
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1036187: vfu: several notes about clipboard

[Vladi Belperchinov-Shabanski]

hi,

I have fixed the clipboard to add the file under cursor and more menu items
for adding and removing files to/from clipboard. this will enter the new 
release.

meanwhile you can test the latest dev version:

  mkdir vfu-tmp
  cd vfu-tmp
  wget https://cade.noxrun.com/projects/vfu/pull-and-build-vfu.sh
  chmod +x pull-and-build-vfu.sh
  ./pull-and-build-vfu.sh

in 'vfu' dir there should be curses and yascreen versions of vfu: vfu and 
vfu.yas

tell me if there are problems?

thanks,
Vladi.
-- 
Vladi Belperchinov-Shabanski  
   
http://cade.noxrun.com
pgp/gpg key 6F35B214 @ http://pgp.mit.edu

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

Yes, that's what it starts with.

Metadata-Version: 2.1
Name: python-lsp-black
Version: 1.2.1
Summary: Black plugin for the Python LSP Server
Home-page: https://github.com/python-lsp/python-lsp-black
Author: Python LSP contributors
Author-email: f...@fidelramos.net
Project-URL: Bug Tracker, 
https://github.com/python-lsp/python-lsp-black/issues
Project-URL: Changelog, 
https://github.com/python-lsp/python-lsp-black/blob/master/CHANGELOG.md

Project-URL: Source Code, https://github.com/python-lsp/python-lsp-black
Classifier: Programming Language :: Python
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Requires-Python: >=3.7
Description-Content-Type: text/markdown
Provides-Extra: dev
License-File: LICENSE

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Mon, May 29, 2023 at 01:35:50PM -0700, Brian Vaughan wrote:
> Yes, the other commands returned "file not found". (I hit send prematurely.)

OK, hmmm.  That is just plain weird.  I wonder where this originates?

What's the content of the file (up to the first blank line):
/usr/lib/python3/dist-packages/python_lsp_black-1.2.1.egg-info/PKG-INFO 

It *should* begin with:

Metadata-Version: 2.1
Name: python-lsp-black
Version: 1.2.1
Summary: Black plugin for the Python LSP Server
[...]

but I wonder if it does?

Best wishes,

   Julian

Bug#1035072: nautilus: The entire Nautilus window turns gray when switching tabs

[Jeremy Bícha]

Control: affects -1 source:libadwaita-1

On Fri, Apr 28, 2023 at 3:21 PM  wrote:
> There is a graphical glitch in the version of Nautilus used in Debian testing 
> that causes the entire Nautilus window to become blank (gray) when switching 
> tabs. This is an upstream issue and has been fixed in Nautilus 44, but not 
> backported into 43.x.
>
> See this upstream ticket for more information: 
> https://gitlab.gnome.org/GNOME/nautilus/-/issues/2379

According to the upstream discussion, this might be a libadwaita bug.

If the bug is still reproducible with the latest libadwaita 1.2
release (1.2.4 which was just uploaded to Unstable), it may be
trickier to bisect since libadwaita 1.3 requires GTK 4.10 which will
not be included in Bookworm.

Thank you,
Jeremy Bícha

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

Yes, the other commands returned "file not found". (I hit send prematurely.)

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

[Olek Wojnar]

Hi Paul,

On 5/29/23 00:22, Paul Gevers wrote:

Hi Olek,

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


Thank you for the apology. I definitely understand how crazy things get 
prior to release!




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?


Yes, please do!

I'm hoping to get to the point of being able to build Debian packages 
with Bazel for the next release so I'll plan to file a release-notes bug 
early for Trixie.


Thanks for following up on this.

-Olek

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Mon, May 29, 2023 at 12:59:05PM -0700, Brian Vaughan wrote:
> $ ls -lR /usr/lib/python3/dist-packages/python_lsp_black*
> /usr/lib/python3/dist-packages/python_lsp_black-1.2.1.egg-info:
> total 20
> [...]

These all look fine; did the other commands all return nothing (or
"file not found" errors)?

Best wishes,

   Julian

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

$ ls -lR /usr/lib/python3/dist-packages/python_lsp_black*
/usr/lib/python3/dist-packages/python_lsp_black-1.2.1.egg-info:
total 20
-rw-r--r-- 1 root root    1 Dec  9 22:58 dependency_links.txt
-rw-r--r-- 1 root root   41 Dec  9 22:58 entry_points.txt
-rw-r--r-- 1 root root 4077 Dec  9 22:58 PKG-INFO
-rw-r--r-- 1 root root   96 Dec  9 22:58 requires.txt
-rw-r--r-- 1 root root   12 Dec  9 22:58 top_level.txt


$ ls -lR /usr/lib/python3/dist-packages/pylsp_black*
/usr/lib/python3/dist-packages/pylsp_black:
total 12
-rw-r--r-- 1 root root    0 Apr 12  2022 __init__.py
-rw-r--r-- 1 root root 6337 Apr 12  2022 plugin.py
drwxr-xr-x 2 root root 4096 May 24 16:59 __pycache__

/usr/lib/python3/dist-packages/pylsp_black/__pycache__:
total 16
-rw-r--r-- 1 root root  163 May 24 16:59 __init__.cpython-311.pyc
-rw-r--r-- 1 root root 8963 May 24 16:59 plugin.cpython-311.pyc

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Mon, May 29, 2023 at 09:51:48AM -0700, Brian Vaughan wrote:
> Thank you for the clear instructions. I appreciate it.

Thanks Brian!

> The complete output is here:
> 
> https://www.geany.org/p/TQ2R2/

Though for some reason this gives a 404 Not Found error.  But it
doesn't matter, as I think the snippet quoted below is enough.

> I believe this is the relevant part:
> 
> 2023-05-29 09:28:09,387 [DEBUG] [spyder.dependencies] -> Dependency(pylsp,
> pytho
> n_lsp_server) starting
> 2023-05-29 09:28:09,387 [DEBUG] [spyder.dependencies] -> Dependency:
> get_module_version returned 1.7.1 for pylsp
> 2023-05-29 09:28:09,387 [DEBUG] [spyder.dependencies] ->
> Dependency(pylsp_black, python_lsp_black) starting
> 2023-05-29 09:28:09,471 [DEBUG] [spyder.dependencies] -> Dependency:
> exception raised: Invalid version: 'v0.9.4.4-ds-git20221205-12a9702d29ab'
> 2023-05-29 09:28:09,471 [DEBUG] [spyder.dependencies] -> Dependency: when
> exception raised: sys.path = ['',
> '/usr/lib/python3/dist-packages/spyder/plugins/help/utils', '/usr/bin',
> '/usr/lib/python311.zip', '/usr/lib/python3.11',
> '/usr/lib/python3.11/lib-dynload',
> '/usr/local/lib/python3.11/dist-packages', '/usr/lib/python3/dist-packages',
> '/usr/lib/python3.11/dist-packages']

OK, this is strange.  pkg_resources is picking up an old or broken
version of python_lsp_black-*.egg-info.  Could you try

ls -R /usr/local/lib/python3.11/dist-packages/python_lsp_black*
ls -R /usr/local/lib/python3.11/dist-packages/pylsp_black*

ls -R /usr/lib/python3/dist-packages/python_lsp_black*
ls -R /usr/lib/python3/dist-packages/pylsp_black*

ls -R /usr/lib/python3.11/dist-packages/python_lsp_black*
ls -R /usr/lib/python3.11/dist-packages/pylsp_black*

One of these pairs of commands is likely to identify the culprit!

Best wishes,

   Julian

Bug#1036933: screen-udeb: Should screen really be installed setgid utmp?

[Cyril Brulebois]

Hallo Sven,

Sven Joachim  (2023-05-29):
> Recently I noticed that the screen program in the screen-udeb package
> is installed setgid utmp, and I wonder if this actually makes any
> sense.  While I do not have much experience with the installer, I
> would expect it to run all programs as root anyway, so there should be
> no need for setgid there.

Without being specifically knowledgeable about screen in general or
in the installer's context in particular, I'm 100% with you here.

> Having screen installed setgid sets up a secure execution environment
> that precludes the use of certain environment variables, see the
> "Secure-execution mode" section in ld.so(8).  Recently ncurses has
> also started to restrict such programs, see #1034372.
> 
> Hopefully none of this matters much.  I have CC'ed debian-boot, as the
> people working on the installer will be much more qualified to give
> advice than I am.

Given the first sentence of this last paragraph, it looks like we're not
considering doing anything for Bookworm at this time (or at all). We
could try it out with Trixie Alpha 1, and see how it goes?


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


signature.asc
Description: PGP signature

Bug#1036936: gnome-maps: Share button doesn't work if other geo app is installed

[Jeremy Bícha]

Source: gnome-maps
Version: 43.4-1
Severity: important
Tags: bookworm

Test Case
--
sudo apt install josm # You could install marble instead
Open the GNOME Maps app
Search for Empire State Building
Choose Empire State Building from the results list
In the popup for the location, click the Share Location button
The Share Location dialog should pop up

Other Info
-
The fix is in the upstream 43.x branch. We can cherry-pick this fix
now along with the minimal 43.5 bugfix update.

Thank you,
Jeremy Bícha

Bug#1036935: autoconf: uses deprecated stage1 build profile

[Sven Joachim]

Source: autoconf
Version: 2.71-3

This package uses the stage1 build profile, which is deprecated
according to https://wiki.debian.org/BuildProfileSpec.  It probably
ought to use the nodoc profile instead, and also tag the build
dependencies accordingly.

See #737936 for the reason why the profile was added.  The patch there
left the build dependencies untouched, most likely because at that time
there was no support for build profiles in dpkg.

Bug#1036930: (no subject)

[snd]

Sorry, there is a mistake for the URL, which should be:

* URL : https://github.com/x42/robtk


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036934: RM: librdf-lazy-perl/experimental -- ROM; dead upstream

[Jonas Smedegaard]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: librdf-lazy-p...@packages.debian.org
Control: affects -1 + src:librdf-lazy-perl

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

 ftpmasters.

Please drop librdf-lazy-perl from Debian.  It was reported broken
upstream in 2015 and has seen no activity upstream since then.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmR09zIACgkQLHwxRsGg
ASFzPRAAkjjx94D9PRGIdGJtiz2GPzwbH2AlTk6hskEu9irYtfxe3Iv3VKip0Un3
XGk1SWDmnIIsXOp1o4O+JlFpVaKz6NAfyiR+Yqrhx0MpWMArzuEsG9h0AfhDpOl+
TndDMeVkGHwIBDLMbSI3J84DuSWbpIoB3GsDC1Kmy+f5OihHJG2/PSlmCU8JFzq3
Q+MG9zPFyGBeD9Bcgv6vE453B43AdoB3jYqltaACOwDlER6gx1Zu0kHruz77S9WB
WX5z8iIm252j5SF8SzpMbFM9MNdAdrfl8j+0pmuJa/5HinU6n0te/s6ava9YlO0a
yydhhXLGrBZKaa07zPkvx5iLUM33y/VQOqZ1CPcskTeNUKQIHx/iSCCtG8sppP/Y
zfNzwnlwcrwbZepKFdtTuD4+Gbh0dhMkBP7XEkjd6eOdG4B7FqXO1JS0d0Bqr/QF
CUIi03GNWyR8Cx6/kl9o1DefPxGJCd27XqRH3WJ39pNmZ51A3nBHTYFGNCcX6UiP
cn1Z4FysZC4wn5zyWtX7xqJIn9DfGC+6lLAwElxC4AiVisRU6MBGk16K4WjylyAP
/I0fJq4owU6bLy0eusV7JaTALoZsgHaRS1q7geGtDKO92eoTZ4UUVW7VCjiz1R3d
LXJenQzDrZ9V8/oGYciGAqDsaiZBX3E2Xy9HsraGdn6I0db/zDo=
=/dpQ
-END PGP SIGNATURE-

Bug#1036933: screen-udeb: Should screen really be installed setgid utmp?

[Sven Joachim]

Package: screen-udeb
Version: 4.9.0-4
Tags: d-i
X-Debbugs-Cc: Sven Joachim , debian-b...@lists.debian.org

Recently I noticed that the screen program in the screen-udeb package is
installed setgid utmp, and I wonder if this actually makes any sense.
While I do not have much experience with the installer, I would expect
it to run all programs as root anyway, so there should be no need for
setgid there.

Having screen installed setgid sets up a secure execution environment
that precludes the use of certain environment variables, see the
"Secure-execution mode" section in ld.so(8).  Recently ncurses has also
started to restrict such programs, see #1034372.

Hopefully none of this matters much.  I have CC'ed debian-boot, as the
people working on the installer will be much more qualified to give
advice than I am.

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

[Martin Hostettler]

> unblock vdr-plugin-xineliboutput/2.2.0+git20211212-2.2

Now also attaching the *source* debdiff. Sorry for the confusion.

diff -Nru vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 
vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog
--- vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 2022-01-25 
19:06:50.0 +0100
+++ vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 2023-05-18 
13:40:36.0 +0200
@@ -1,3 +1,11 @@
+vdr-plugin-xineliboutput (2.2.0+git20211212-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing Breaks/Replaces for correction of xineliboutput-fbfe desktop
+icon. Closes: #1034915
+
+ -- Andreas Metzler   Thu, 18 May 2023 13:40:36 +0200
+
 vdr-plugin-xineliboutput (2.2.0+git20211212-2.1) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control 
vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control
--- vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control   2022-01-25 
19:06:50.0 +0100
+++ vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control   2023-05-18 
13:39:22.0 +0200
@@ -54,6 +54,8 @@
 Package: xineliboutput-fbfe
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, libxine2-xvdr (= 
${binary:Version}), libxine2-console
+Breaks: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)
+Replaces: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)
 Description: Remote Framebuffer frontend for vdr-plugin-xineliboutput
  This frambuffer remote frontend plays back streams provided by
  vdr-plugin-xineliboutput.
diff -Nru vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 
vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog
--- vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 2022-01-25 
19:06:50.0 +0100
+++ vdr-plugin-xineliboutput-2.2.0+git20211212/debian/changelog 2023-05-18 
13:40:36.0 +0200
@@ -1,3 +1,11 @@
+vdr-plugin-xineliboutput (2.2.0+git20211212-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing Breaks/Replaces for correction of xineliboutput-fbfe desktop
+icon. Closes: #1034915
+
+ -- Andreas Metzler   Thu, 18 May 2023 13:40:36 +0200
+
 vdr-plugin-xineliboutput (2.2.0+git20211212-2.1) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control 
vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control
--- vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control   2022-01-25 
19:06:50.0 +0100
+++ vdr-plugin-xineliboutput-2.2.0+git20211212/debian/control   2023-05-18 
13:39:22.0 +0200
@@ -54,6 +54,8 @@
 Package: xineliboutput-fbfe
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}, libxine2-xvdr (= 
${binary:Version}), libxine2-console
+Breaks: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)
+Replaces: xineliboutput-sxfe (<< 2.2.0+git20211212-2.1)
 Description: Remote Framebuffer frontend for vdr-plugin-xineliboutput
  This frambuffer remote frontend plays back streams provided by
  vdr-plugin-xineliboutput.

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

[Martin Hostettler]

> unblock inventor/2.1.5-10+dfsg-2

Now also attaching the *source* debdiff. Sorry for the confusion.

diff -Nru inventor-2.1.5-10+dfsg/debian/changelog 
inventor-2.1.5-10+dfsg/debian/changelog
--- inventor-2.1.5-10+dfsg/debian/changelog 2023-02-06 00:50:57.0 
+0100
+++ inventor-2.1.5-10+dfsg/debian/changelog 2023-05-28 03:08:52.0 
+0200
@@ -1,3 +1,13 @@
+inventor (2.1.5-10+dfsg-2) unstable; urgency=medium
+
+  [ Steve Robbins ]
+  * [6c3239d] Fix broken symlinks to Century-Schoolbook fonts.
+Closes: #1036603.
+  * [d2a2a86] Remove dep from transitional dummy package gsfonts-x11
+  * [54dce68] Change dep from transitional libfreetype6-dev to libfreetype-dev.
+
+ -- Steve M. Robbins   Sat, 27 May 2023 20:08:52 -0500
+
 inventor (2.1.5-10+dfsg-1) unstable; urgency=high
 
   * Team upload
diff -Nru inventor-2.1.5-10+dfsg/debian/control 
inventor-2.1.5-10+dfsg/debian/control
--- inventor-2.1.5-10+dfsg/debian/control   2023-02-05 23:50:02.0 
+0100
+++ inventor-2.1.5-10+dfsg/debian/control   2023-05-28 03:08:52.0 
+0200
@@ -12,7 +12,7 @@
libmotif-dev,
libglw1-mesa-dev,
libglu1-mesa-dev,
-   libfreetype6-dev,
+   libfreetype-dev,
libjpeg-dev,
bison
 Standards-Version: 4.6.1
@@ -27,7 +27,7 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  xfonts-scalable,
- fonts-urw-base35 | gsfonts-x11
+ fonts-urw-base35
 Recommends: xdg-utils,
 xpdf | pdf-viewer
 Conflicts: libinventor0
diff -Nru inventor-2.1.5-10+dfsg/debian/link-fonts.sh 
inventor-2.1.5-10+dfsg/debian/link-fonts.sh
--- inventor-2.1.5-10+dfsg/debian/link-fonts.sh 2023-02-05 23:50:02.0 
+0100
+++ inventor-2.1.5-10+dfsg/debian/link-fonts.sh 2023-05-28 03:08:52.0 
+0200
@@ -2,6 +2,7 @@
 
 fontpath=/usr/share/inventor/fonts
 type1=/usr/share/fonts/X11/Type1
+urw=/usr/share/fonts/type1/urw-base35
 
 mkdir -p $fontpath
 cd $fontpath
@@ -10,10 +11,10 @@
 ln -s -f $type1/c0582bt_.pfb  Courier-Italic
 ln -s -f $type1/c0583bt_.pfb  Courier-Bold
 ln -s -f $type1/c0611bt_.pfb  Courier-BoldItalic
-ln -s -f $type1/c059013l.pfb  Century-Schoolbook-Roman
-ln -s -f $type1/c059016l.pfb  Century-Schoolbook-Bold
-ln -s -f $type1/c059033l.pfb  Century-Schoolbook-Italic
-ln -s -f $type1/c059036l.pfb  Century-Schoolbook-BoldItalic
+ln -s -f $urw/C059-Roman.t1  Century-Schoolbook-Roman
+ln -s -f $urw/C059-Bold.t1  Century-Schoolbook-Bold
+ln -s -f $urw/C059-Italic.t1  Century-Schoolbook-Italic
+ln -s -f $urw/C059-BdIta.t1  Century-Schoolbook-BoldItalic
 
 
 for i in $type1/*.pfa; do
diff -Nru inventor-2.1.5-10+dfsg/debian/changelog 
inventor-2.1.5-10+dfsg/debian/changelog
--- inventor-2.1.5-10+dfsg/debian/changelog 2023-02-06 00:50:57.0 
+0100
+++ inventor-2.1.5-10+dfsg/debian/changelog 2023-05-28 03:08:52.0 
+0200
@@ -1,3 +1,13 @@
+inventor (2.1.5-10+dfsg-2) unstable; urgency=medium
+
+  [ Steve Robbins ]
+  * [6c3239d] Fix broken symlinks to Century-Schoolbook fonts.
+Closes: #1036603.
+  * [d2a2a86] Remove dep from transitional dummy package gsfonts-x11
+  * [54dce68] Change dep from transitional libfreetype6-dev to libfreetype-dev.
+
+ -- Steve M. Robbins   Sat, 27 May 2023 20:08:52 -0500
+
 inventor (2.1.5-10+dfsg-1) unstable; urgency=high
 
   * Team upload
diff -Nru inventor-2.1.5-10+dfsg/debian/control 
inventor-2.1.5-10+dfsg/debian/control
--- inventor-2.1.5-10+dfsg/debian/control   2023-02-05 23:50:02.0 
+0100
+++ inventor-2.1.5-10+dfsg/debian/control   2023-05-28 03:08:52.0 
+0200
@@ -12,7 +12,7 @@
libmotif-dev,
libglw1-mesa-dev,
libglu1-mesa-dev,
-   libfreetype6-dev,
+   libfreetype-dev,
libjpeg-dev,
bison
 Standards-Version: 4.6.1
@@ -27,7 +27,7 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  xfonts-scalable,
- fonts-urw-base35 | gsfonts-x11
+ fonts-urw-base35
 Recommends: xdg-utils,
 xpdf | pdf-viewer
 Conflicts: libinventor0
diff -Nru inventor-2.1.5-10+dfsg/debian/link-fonts.sh 
inventor-2.1.5-10+dfsg/debian/link-fonts.sh
--- inventor-2.1.5-10+dfsg/debian/link-fonts.sh 2023-02-05 23:50:02.0 
+0100
+++ inventor-2.1.5-10+dfsg/debian/link-fonts.sh 2023-05-28 03:08:52.0 
+0200
@@ -2,6 +2,7 @@
 
 fontpath=/usr/share/inventor/fonts
 type1=/usr/share/fonts/X11/Type1
+urw=/usr/share/fonts/type1/urw-base35
 
 mkdir -p $fontpath
 cd $fontpath
@@ -10,10 +11,10 @@
 ln -s -f $type1/c0582bt_.pfb  Courier-Italic
 ln -s -f $type1/c0583bt_.pfb  Courier-Bold
 ln -s -f $type1/c0611bt_.pfb  Courier-BoldItalic
-ln -s -f $type1/c059013l.pfb  Century-Schoolbook-Roman
-ln -s -f $type1/c059016l.pfb  Century-Schoolbook-Bold
-ln -s -f $type1/c059033l.pfb  Century-Schoolbook-Italic
-ln -s -f $type1/c059036l.pfb  Century-Schoolbook-BoldItalic
+ln -s -f 

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Luca Boccassi]

Control: severity -1 important

On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann 
wrote:
> Package: systemd
> Version: 252.6-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts

Given what was discussed:

- bookworm is in hard freeze
- there is no functional impact
- unmerged-usr paths are no longer supported
- as soon as trixie opens for business we might just canonicalize
everything (assuming all the ducks will be in a row)

if it's all right with you Andreas, I am going to go ahead and
downgrade this. If we don't manage to canonicalize early in trixie's
cycle we can revisit.

-- 
Kind regards,
Luca Boccassi


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

Bug#1036919: debvm: singleshot mode

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 debvm's autopkgtests should be marked as flaky
Control: submitter -2 !
Control: severity -2 important

Hi Wouter,

On Mon, May 29, 2023 at 02:28:08PM +0200, Wouter Verhelst wrote:
> I would like to use debvm to run autopkgtests for nbd-client. In order
> to do that, I would need to run the vm noninteractively, do some in-vm
> tests, and then shut it down again, with the result of the test
> affecting the exit state.

Thanks for caring about debvm! Before we delve into your problem, let me
point out that I had a rather longer talk with Paul Gevers about my
autopkgtests. In effect, these tests - when executed in testing - still
test unstable packages. As such, a problem in unstable may make the test
in stable or testing fail. This is bad. I am at fault here. Please avoid
repeating my mistake.

That being said, would you spend a moment on my autopkgtests anyway? The
usual interaction happens on stdin/stdout via serial by default, but you
can also background it and interact with it via ssh, which is what my
tests do. I think this is the easiest way to script it. Does that suit
your needs? If not, can you add more detail to how you see this
happening?

I also note that autopkgtest has a qemu backend. While this backend is
not available in the Debian infrastructure, it is being asked for
repeatedly. Maybe Paul knows more here, but it seems to me that a test
restriction asking for a VM is more useful for your use case in
principle.

Helmut

Bug#1036918: debvm: manual mounting of root image

[Helmut Grohne]

Hi Wouter,

On Mon, May 29, 2023 at 02:20:09PM +0200, Wouter Verhelst wrote:
> I am exploring the possibility to write an autopkgtest for the initramfs
> stuff that I wrote for nbd-client.

Please see my other mail regarding the use of debvm in autopkgtests.
Let's not duplicate that topic here. I note that this fully applies in
the exact way to the projected use of mmdebstrap below.

> In order to do so, I want to run a client VM that has no root hard disk
> configured, but is configured to attempt to mount the VM image over the
> network, using NBD. This is accomplished by way of a few kernel command
> line parameters.
> 
> I tried running
> 
> debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0'

May I suggest that this is a quite unusual use case and that debvm may
not be the right hammer for your job? While debvm gives you a complete
rootfs, you seem to be satisfied with a kernel an an initrd. How about
peeking at debvm's source and extracting the useful bits from it? In
effect you can skip much of what debvm does and construct a manageable
mmdebstrap invocation directly. The following draft is entirely
untested:

mmdebstrap \
--variant=apt \
unstable \
/dev/null \
--include=linux-image-"$(dpkg --print-architecture)" \
--customize-hook="download /initrd ./initrd" \
--customize-hook="download /vmlinuz ./vmlinuz"

> I would like to see an option to tell debvm-run not to mount the
> filesystem image but to let the user handle that. However, the
> extracting of the kernel and initramfs which debvm-run does would still
> be necessary; it's just that I want to fiddle with how we get to the
> filesystem.

Given the images, I think you can pass them to qemu directly. Do you
agree that for this use case, using the underlying tools directly does a
better job?

Helmut

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

[Martin Hostettler]

> unblock ignition-physics/5.1.0+ds1-4.1

Now also attaching the *source* debdiff. Sorry for the confusion.

diff -Nru ignition-physics-5.1.0+ds1/debian/changelog 
ignition-physics-5.1.0+ds1/debian/changelog
--- ignition-physics-5.1.0+ds1/debian/changelog 2022-02-14 23:29:14.0 
+0100
+++ ignition-physics-5.1.0+ds1/debian/changelog 2023-05-21 20:50:53.0 
+0200
@@ -1,3 +1,13 @@
+ignition-physics (5.1.0+ds1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing Depends: libignition-physics5-bullet-plugin5 (=
+${binary:Version})": add missing dependency to libignition-physics-dev
+package.
+(Closes: #1035865)
+
+ -- gregor herrmann   Sun, 21 May 2023 20:50:53 +0200
+
 ignition-physics (5.1.0+ds1-4) unstable; urgency=medium
 
   * Include more debug information in FAKE patch
diff -Nru ignition-physics-5.1.0+ds1/debian/control 
ignition-physics-5.1.0+ds1/debian/control
--- ignition-physics-5.1.0+ds1/debian/control   2022-02-14 14:41:23.0 
+0100
+++ ignition-physics-5.1.0+ds1/debian/control   2023-05-21 20:50:52.0 
+0200
@@ -177,6 +177,7 @@
  libignition-physics-mesh-dev,
  libignition-physics-sdf-dev,
  libignition-physics-tpe-dev,
+ libignition-physics5-bullet-plugin5 (= ${binary:Version}),
  libignition-physics5-dartsim-plugin5 (= ${binary:Version}),
 # Bullet component dependencies
  libbullet-dev,
diff -Nru ignition-physics-5.1.0+ds1/debian/changelog 
ignition-physics-5.1.0+ds1/debian/changelog
--- ignition-physics-5.1.0+ds1/debian/changelog 2022-02-14 23:29:14.0 
+0100
+++ ignition-physics-5.1.0+ds1/debian/changelog 2023-05-21 20:50:53.0 
+0200
@@ -1,3 +1,13 @@
+ignition-physics (5.1.0+ds1-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix "missing Depends: libignition-physics5-bullet-plugin5 (=
+${binary:Version})": add missing dependency to libignition-physics-dev
+package.
+(Closes: #1035865)
+
+ -- gregor herrmann   Sun, 21 May 2023 20:50:53 +0200
+
 ignition-physics (5.1.0+ds1-4) unstable; urgency=medium
 
   * Include more debug information in FAKE patch
diff -Nru ignition-physics-5.1.0+ds1/debian/control 
ignition-physics-5.1.0+ds1/debian/control
--- ignition-physics-5.1.0+ds1/debian/control   2022-02-14 14:41:23.0 
+0100
+++ ignition-physics-5.1.0+ds1/debian/control   2023-05-21 20:50:52.0 
+0200
@@ -177,6 +177,7 @@
  libignition-physics-mesh-dev,
  libignition-physics-sdf-dev,
  libignition-physics-tpe-dev,
+ libignition-physics5-bullet-plugin5 (= ${binary:Version}),
  libignition-physics5-dartsim-plugin5 (= ${binary:Version}),
 # Bullet component dependencies
  libbullet-dev,

Bug#1036931: RFS: vulkanscenegraph/1.0.6-1 [ITP] -- 3D vulkan scene graph, shared libs

[bret curtis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : vulkanscenegraph
   Version  : 1.0.6-1
   Upstream contact : Robert Osfield 
* URL  : https://vsg-dev.github.io/VulkanSceneGraph/
* License  : MIT
* Vcs  : https://salsa.debian.org/games-team/vulkanscenegraph
   Section  : devel

The source builds the following binary packages:

  libvsg-dev - 3D vulkan scene graph, development files
  libvsg13 - 3D vulkan scene graph, shared libs

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/v/vulkanscenegraph/vulkanscenegraph_1.0.6-1.dsc


Changes for the initial release:

vulkanscenegraph (1.0.6-1) unstable; urgency=low
.
   [ Bret Curtis ]
   * Upstream release: VulkanSceneGraph-1.0.6 (Closes: #1016991)

Regards,
- --
  Bret Curtis
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.4.7
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCAAnBYJkdOzzCZDCN3t9WEy5MBYhBOvlFRLAKf4mCA8flsI3e31Y
TLkwAACZOQ//e7fG0UFUCSLi8PNkr9HskFP1pFrfeBM9/yZCeg4mUoiKoZUp
pV1bQQFrXRNMOnsp3QuNGwVI3gqkWaoUwHhIpGUgpQYWi7vj36/OKhwaE0sI
rfvxufF/9/SwEhGswEsNd6N9ll6pZai7A/dv6EN5kONuNXlnytMuuCTbGXV6
23PsBuUOZC+FpnMQ7PMd8TGmdh2OSrnZqU/yd4IdLTWMC53CvXyEL+1VcgZn
WgPFxYlv88GvEMLeH4lYLggkupyyikKn58IjivjD0jzQW+xtYhtNZH8UevV3
vE/8ZpFVUCahJI4BEYdnK710bS8k39h92PUerUA22Iab08m9CNbFp3leIm/g
VLYSzAV79G93K+hnSlQSvOwlRPL/ucjxOwHKAaP4kLnUamDEiIFbXJIhmpKz
c4NCxiul3AmFHTE07tmYhy7rH0gV0z3PfuSFMrk0f5h3YltZ2vDxHohFbqVT
bzJKW5uuM2nOMa0EvVGfa6uj++Gtib1vtHXgzFL013ARmq+qzcpsG3BCVBTV
7yu5ko/k136394DMXtLRG7hlBnAQ/gWSfdsIB+XrnC3TEJR0pM6V7ESOkLwY
PB7FMRym7ewgIhF+JlXlzznTm7R/jMr2k7rG0AQOGkqR5fUiZCPaQbTb6vAG
YrGvTDcYo0leotDTr3nloSdoW8PvQOk4ojE=
=ncs7
-END PGP SIGNATURE-

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

[Paul Gevers]

Hi,

On 29-05-2023 15:58, Mathias Gibbens wrote:

On Mon, 2023-05-29 at 14:26 +0200, Pierre-Elliott Bécue wrote:

On Mon, 2023-05-29 at 07:37 +0200, Paul Gevers wrote:

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


   Can you grab /proc/cpuinfo from a physical CI host as well as from
within a container for the armel, armhf, and arm64 architectures? That
will let us see what difference(s) lxcfs is presenting and might give a
clue for the root issue. Since only the 32bit arm architectures appear
to be affected, I'm also curious to see what the arm64 cpuinfo is.


We have three layers here. The bare metal is arm64. It hosts several 
arm* QEMU VM. Inside the VM we run the lxc. I put the output of all 
three at the bottom. *Maybe* it's relevant that the bare metal still 
runs bullseye while the VM's run bookworm. I'll also share the content 
for an arm64 host (which is a VM where I don't have access to the bare 
metal.)


Paul

# The armhf VM
debian@ci-worker-armhf-01:~$ cat /proc/cpuinfo
processor   : 0
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

processor   : 1
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

[... repeat until ...]

processor   : 15
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

# generating the container and showing inside
debian@ci-worker-armhf-01:~$ sudo lxc-copy -N elbrus 
autopkgtest-unstable-armhf && sudo lxc-start elbrus && sudo lxc-attach 
elbrus

root@elbrus:/# cat /proc/cpuinfo
root@elbrus:/# ls -al /proc/cpuinfo
-r--r--r-- 1 root root 3878 May 29 17:48 /proc/cpuinfo

# the bare metal machine used for armhf and armel VM's
root@altra:~# cat /proc/cpuinfo
processor   : 0
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

processor   : 1
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1

[ repeat until ...]

processor   : 159
BogoMIPS: 50.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs

CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part: 0xd0c
CPU revision: 1


# the arm64 VM (at Huawei)
root@ci-worker-arm64-02:~# cat /proc/cpuinfo
processor   : 0
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

CPU implementer : 0x48
CPU architecture: 8
CPU variant : 0x1
CPU part: 0xd01
CPU revision: 0

processor   : 1
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

CPU implementer : 0x48
CPU architecture: 8
CPU variant : 0x1
CPU part: 0xd01
CPU revision: 0

processor   : 2
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

CPU implementer : 0x48
CPU architecture: 8
CPU variant : 0x1
CPU part: 0xd01
CPU revision: 0

processor   : 3
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

CPU implementer : 0x48
CPU architecture: 8
CPU variant : 0x1
CPU part: 0xd01
CPU revision: 0

root@ci-worker-arm64-02:~# lxc-copy autopkgtest-unstable-arm64 -N elbrus 
&& lxc-start elbrus && lxc-attach elbrus

root@elbrus:~# cat /proc/cpuinfo
processor   : 0
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

CPU implementer : 0x48
CPU architecture: 8
CPU variant : 0x1
CPU part: 0xd01
CPU revision: 0

processor   : 1
BogoMIPS: 200.00
Features: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics 
fphp asimdhp cpuid asimdrdm jscvt fcma dcpop asimddp asimdfhm

CPU 

Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

[Johannes Schauer Marin Rodrigues]

Hi Dima,

I'm putting Helmut in CC who is in favour of such an option as well and who
might have more ideas.

Quoting Dima Kogan (2023-05-29 18:42:57)
> Hi. Currently it's possible to do
> 
>   sbuild --anything-failed-commands '%s'
> 
> to get an interactive shell in response to any step of the process
> failing. This makes it much easier to debug problems. It would be great
> if mmdebstrap had a similar function.
> 
> I'm currently trying to debug an issue with an apt-cacher-based server
> failing when mmdebstrap is pulling from it (but not when anything else
> is pulling from it), and that option would make this process much easier.

how about an option like this:

--failure-hook='chroot "$1" bash'

Since all hooks have the MMDEBSTRAP_HOOK variable set, whatever is run in the
hook would have access to the type of hook that failed.

The information that would be missing would be *which* hook of a certain type
was the one failing. I do not see a good way to communicate this information.

Another question: what should be done if the failure-hook failed?

Do you know of another software besides sbuild that has a similar interface?
I'd like to get some more ideas first before I add another interface that
mmdebstrap would have to support forever.

I would rather not add the percent escapes from sbuild as that would mean that
any percent sign in the hooks has to be escaped as well. This would break
existing users of hooks.

I'd also like to add that you can already emulate this behaviour by running a
hook like this:

--customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'

So do we need another option for this?

What do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1036809: unblock: reaver/1.6.6-0.1

[Samuel Henrique]

Hey everyone,

Considering this will be the only fix we get, leaving the release team
to decide between not shipping reaver at all or shipping "1.6.6-0.1",
I went ahead and sponsored the upload from Leandro.

The debdiff is attached.

Thank you,

-- 
Samuel Henrique 


reaver_1.6.6-0.1.debdiff
Description: Binary data

Bug#1036930: ITP : robtk -- Robin's LV2 UI ToolKit

[Dennis Braun]

Package: wnpp
Severity: wishlist
Owner: s...@debian.org

* Package name : robtk
  Version : 0.8.4
  Upstream Author : Robin Gareus 
* URL : Robin Gareus 
* License : GPL-2+, ISC, Expat
  Programming Lang: C, Objective-C++, C++
  Description : Robtk facilitates creating LV2 plugins UIs with emphasis to
allow porting existing GTK+ plugin UIs

This package i prepared here https://salsa.debian.org/multimedia-team/robtk,
and some more changes will come soon


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

Kernel: Linux 6.1.0-9-amd64 (SMP w/4 CPU threads; PREEMPT)
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#1036461: Please update to at least v7.0.1

[Boyuan Yang]

Hi,

在 2023-05-22星期一的 20:55 -0400，Nicholas D Steeves写道：
> Roman Lebedev  writes:
> 
> > Package: easyeffects
> > Version: 7.0.0-1
> > Severity: normal
> > 
> > Dear maintainer, out of all the improvements in newer versions, there is
> > one
> > change that brings high UX improvements for doing live audio post-
> > processing:
> > "exposing support for the "the Min and Max sidechain modes"
> > https://github.com/wwmm/easyeffects/commit/3cf99f74747b5a318e6818423b89f867ceaac988
> > https://github.com/wwmm/easyeffects/issues/2042
> > which adds UI for lsp-plugin's 
> > https://github.com/sadko4u/lsp-plugins/issues/274
> > which was implemented in lsp-plugins v1.2.4 (and debian has v1.2.5)
> > 
> > It would be really great to update!
> > 
> 
> Easyeffects v7.0.1 is v7.0.0 plus 339 commits, and it looks like these
> are mostly translation-related, plus a mix of feature, refactoring, and
> bug fix commits.  The translations and bug fixes are ok, but at this
> stage of the upcoming bookworm (Debian 12) release, v7.0.1 cannot be
> imported in its entirety:
> https://release.debian.org/testing/freeze_policy.html
> 
> It was arguably too late at the beginning of the soft freeze
> (2023-02-12).  That said, "Only small, targeted fixes" is up to
> maintainer discretion, so it may have been possible before 2023-03-12.
> Now that we're in the "hard freeze", and because easyeffects doesn't
> have autpkgtests, someone on the Release Team would need to unblock an
> upload of v7.0.1; The Release Team is almost certainly not going to sign
> off on such a large delta, so the best case scenario appears to be to
> request a bookworm-backport of easyeffects after the bookworm release.
> That will become possible about a week after this bug is closed (were I
> to guess, probably July or August).
> 
> Boyuan Yang: Would you please acknowledge if this package belongs to the
> Multimedia Team?  It's still in Debian/collab-maint namespace, and if
> it's team-maintained then it should be moved here:
> 
>   https://salsa.debian.org/multimedia-team


We could do bookworm-backport for easyeffects after Debian 12 release, no
problem. The package belongs to Multimedia Team from the very beginning; its
packaging repo can be moved to salsa multimedia-team at anytime.

Thanks,
Boyuan Yang


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

Bug#1036900: Things I tried

[Christian]

After googling, I tried a few things:

Memory has correct timing, frequencies and voltage (no improvement)

kernel parameters => no improvement
- idle=nomwait
- processor.max_cstate=5
- rcu_nocbs=0-11

Undervolting / Overclocking => seems to make the system a bit more
stable
- Reducing PPT to 45W 
- PBS Curve all cores: -10
- Boost limit: -300 (ending around 4Ghz)

Deactivate SMT => no improvement

Deactivate selective CPUs (Error always showed on CPU5) => no
improvement

Deactivating tx, sg, tso offloading => no improvement

Overall it seems the system crashes when doing load changes, e.g. like
compiling. It then takes SATA, network, etc. down, leading to an
unusable system.

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Brian Vaughan]

Thank you for the clear instructions. I appreciate it.

The complete output is here:

https://www.geany.org/p/TQ2R2/

I believe this is the relevant part:

2023-05-29 09:28:09,387 [DEBUG] [spyder.dependencies] -> 
Dependency(pylsp, pytho

n_lsp_server) starting
2023-05-29 09:28:09,387 [DEBUG] [spyder.dependencies] -> Dependency: 
get_module_version returned 1.7.1 for pylsp
2023-05-29 09:28:09,387 [DEBUG] [spyder.dependencies] -> 
Dependency(pylsp_black, python_lsp_black) starting
2023-05-29 09:28:09,471 [DEBUG] [spyder.dependencies] -> Dependency: 
exception raised: Invalid version: 'v0.9.4.4-ds-git20221205-12a9702d29ab'
2023-05-29 09:28:09,471 [DEBUG] [spyder.dependencies] -> Dependency: 
when exception raised: sys.path = ['', 
'/usr/lib/python3/dist-packages/spyder/plugins/help/utils', '/usr/bin', 
'/usr/lib/python311.zip', '/usr/lib/python3.11', 
'/usr/lib/python3.11/lib-dynload', 
'/usr/local/lib/python3.11/dist-packages', 
'/usr/lib/python3/dist-packages', '/usr/lib/python3.11/dist-packages']

Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

[Dima Kogan]

Package: mmdebstrap
Version: 1.3.3-6.1
Severity: wishlist
X-Debbugs-Cc: none, Dima Kogan 

Hi. Currently it's possible to do

  sbuild --anything-failed-commands '%s'

to get an interactive shell in response to any step of the process
failing. This makes it much easier to debug problems. It would be great
if mmdebstrap had a similar function.

I'm currently trying to debug an issue with an apt-cacher-based server
failing when mmdebstrap is pulling from it (but not when anything else
is pulling from it), and that option would make this process much
easier.

Thanks

Bug#1036928: RFP: astro -- a gemini web browser

[Brian Mayer]

Package: astro
Severity: wishlist

* Package name: astro
  Version : 0.20.0
  Upstream Author : blmayer
* URL : https://github.com/blmayer/astro
* License : MIT
  Programming Lang: Shell
  Description : A Gemini web browser written in POSIX shell script

Hi Debian Team.

The Gemini web is a new protocol for content publishing that is focused on
content and user privacy. It stays between Gopher and HTTP, as the authors
describe it.

Astro is a browser that helps users to find and navigate the Gemini web, it
is a FOSS  with a stable version with all needed features described on the
protocol. Using only a few utilities it has minimal dependencies, as it is
written in POSIX shell script it is know to work well on many platforms.
Currently it is being packaged for Archlinux and it's user base is
increasing, hence, having it on Debian systems would be a great addition to
the community.

The Gemini community is growing fast and having astro packaged will
continue this movement.

Thank you!

Bug#1036927: unblock: liblxqt/1.2.0-8

[陳昌倬]

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

Please unblock package liblxqt

[ Reason ]

Fix RC bug https://bugs.debian.org/1034943 due to wrong
Breaks/Replaces.

[ Impact ]

Althrough the Breaks/Replaces are wrong, upgrading from liblxqt0-dev in
Bullseye to unfixed liblxqt1-dev=1.2.0-7 in Bookworm is still good in my
test due to wrongly Breaks/Replaces on liblxqt0.


[ Tests ]

Manual test to upgrade liblxqt0-dev to liblxqt1-dev from 0.16.0-1 to
1.2.0-8.

[ Risks ]

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

unblock liblxqt/1.2.0-8

-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
https://czchen.org/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B
diff -Nru liblxqt-1.2.0/debian/changelog liblxqt-1.2.0/debian/changelog
--- liblxqt-1.2.0/debian/changelog	2023-05-13 17:41:17.0 +0800
+++ liblxqt-1.2.0/debian/changelog	2023-05-29 03:12:02.0 +0800
@@ -1,3 +1,9 @@
+liblxqt (1.2.0-8) unstable; urgency=medium
+
+  * Fix wrong Breaks/Replaces in liblxqt1-dev. (Closes: #1034943)
+
+ -- ChangZhuo Chen (陳昌倬)   Mon, 29 May 2023 03:12:02 +0800
+
 liblxqt (1.2.0-7) unstable; urgency=medium
 
   * liblxqt1-dev: sufficient Breaks and Replaces declarations.
diff -Nru liblxqt-1.2.0/debian/control liblxqt-1.2.0/debian/control
--- liblxqt-1.2.0/debian/control	2023-05-13 17:41:17.0 +0800
+++ liblxqt-1.2.0/debian/control	2023-05-29 03:03:01.0 +0800
@@ -51,8 +51,8 @@
  libqt5xdgiconloader-dev (>= 3.10.0~),
  lxqt-build-tools (>= 0.12.0~),
  ${misc:Depends}
-Breaks: liblxqt0 (<< 0.99)
-Replaces: liblxqt0 (<< 0.99)
+Breaks: liblxqt0-dev (<< 0.99)
+Replaces: liblxqt0-dev (<< 0.99)
 Description: Shared libraries for LXQt desktop environment (dev)
  LXQt is an advanced, easy-to-use, and fast desktop environment based on Qt
  technologies. It has been tailored for users who value simplicity, speed, and


signature.asc
Description: PGP signature

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

[James Addison]

Followup-For: Bug #1035543
X-Debbugs-Cc: ty...@mit.edu, bi...@debian.org, hel...@subdivi.de, 
jspri...@debian.org, ans...@debian.org, a...@debian.org, 
debian.bugrep...@wodny.org

I've been 'approximately' testing this locally on bookworm by:

  * Editing the Install.WantedBy in /lib/systemd/system/e2scrub_reap.service

  * Reconfiguring the package using 'dpkg-reconfigure e2fsprogs'

(I know, it's not a comprehensive workflow - but I think that it calls the
relevant deb-systemd-helper and e2fsprogs postinst script sections)

Also: Marcin's patch[1] from #985787 is also intended to fix a very similar
problem (perhaps exactly the same issue).

Some puzzles:

  * Why does the 'deb-systemd-helper disable' invocation not work (as found
by Helmut and Jochen)?  It seems like it should read the symlink path to
remove from the dsh-also state file, so the Install.WantedBy change should
not affect it.

  * Is the /var/lib/systemd/deb-systemd-helper-enabled/ path relevant?  This
seems to contain a shadow copy of much of the /etc/systemd/system service
state.

   * Is the 'create links unless no links installed' logic correct?  (that
 sounds like it could be incorrect, but I'm not sure)


I did manage to get something kinda-working locally with a combination of an
'update-state' call and Marcin's patch.  However, I'd like to understand more
about the 'deb-systemd-helper disable' call failure before recommending that.


And, quoting Andreas:

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

I agree on the goals there.  Being unhappy about systemd and maintaining a
package that has divergent on-filesystem results depending on how users
upgraded seems distinctly worse than being unhappy about systemd while
maintaining a consistently-deployed package.

[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985787#25

[2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035543#62

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Luca Boccassi]

On Mon, 29 May 2023 15:17:51 +0200 Andreas Beckmann 
wrote:
> On 29/05/2023 14.57, Luca Boccassi wrote:
> >> Side question first: does systemd evaluate both
> >> /usr/lib/modules-load.d/* and /lib/modules-load.d/* ?
> >> Otherwise all packages shipping something in /lib/modules-load.d/
are
> >> broken on unmerged-/usr because their config snippets are not
being
> >> taken into account.
> > 
> > The correct path since bullseye was /usr/lib/modules-load.d, see:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971282
> 
> I read this as these packages have been buggy on unmerged-/usr in 
> bullseye. Why weren't there bugs filed?

Good question, I guess nobody ever noticed because most users are on
merged-usr anyway? But as you can see from the bug, it's been years.

> > Anyway, we don't really care about what happens on unmerged
> > installations, as they are no longer supported since Bookworm.
> 
> Well, there is still limited support, e.g. for buildd usage. But 
> probably (hopefully?) for the last time.

IIRC the plan was to switch buildds as soon as bookworm ships, but I
don't think that's finalised. Also I don't think it's supported to
install and load kernel modules for a package build, at least I've
never came across that, but I might be wrong.

-- 
Kind regards,
Luca Boccassi


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

Bug#1026026: /usr/sbin/needrestart: typo prevents vm detection and leads to error in microcode check

[Antoine Beaupré]

A workaround for this issue is to enable another check mechanism by
installing libimvirt-perl if I understand correctly.

Bug#1007031: "patch" available

[Rene Engelhard]

Am Thu, Mar 10, 2022 at 10:30:41PM +0100 schrieb Lucas Nussbaum:
> Please also see
> https://lists.debian.org/debian-devel/2022/03/msg00096.html , where it
> was noticed that the conversion for this package is trivial, and builds
> bit-by-bit identical binary packages.

Wrong. Those instructins assume a single debian patch which this one is
not. It has patches and I explicitely do NOT want a single debian patch.

And some patches are -p0, some -p1 and I think one even is -p2 from the
log.

So no, it's not as trivial as you want to say. Please look at packages
before you comment - which you here obviously did not and just posted a
hilaroioud "patch" link to all regardless of their nature.

Regards,

Rene

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Marco d'Itri]

On May 29, Luca Boccassi  wrote:

> Does it matter that much if the empty directory is removed? Next time
> a package shipping a modules-load config is installed it will be just
> re-added, no? Or are there functional issues?
I do not think that it is a big deal if /usr/lib/modules-load.d/ 
disappears from time to time. Local users are expected to install local 
files in /etc/modules-load.d/ anyway.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1036926: ITP: lxd-ui -- A browser interface for LXD

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: lxd-ui
  Version : 0.0~git20230526.416dc86
  Upstream Author : Canonical
* URL : https://github.com/canonical/lxd-ui
* License : GPL-3
  Programming Lang: HTML, JavaScript, TypeScript
  Description : A browser interface for LXD

 LXD-UI is a browser frontend for LXD. It enables easy and
 accessible container and virtual machine management. Targets
 small and large scale private clouds.

Canonical is working on a web-based GUI for LXD that would be useful to
have available in Debian. There's another third-party project
(LXDWARE's lxd-dashboard) as well -- I haven't directly compared the
two projects in too much depth, but I would expect Canonical's version
to likely end up the best integrated and supported.


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

Bug#1036925: ITP: python3-pylxd -- Python module for LXD

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python3-pylxd
  Version : 2.3.1
  Upstream Author : Canonical
* URL : https://github.com/lxc/pylxd
* License : Apache-2.0
  Programming Lang: Python
  Description : Python module for LXD

 A Python library for interacting with the LXD REST API.

I'm planning to package the python bindings for LXD. I think it would
make sense to team-maintain it under the Python Team umbrella.


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

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

[Mathias Gibbens]

Control: notforwarded -1

On Mon, 2023-05-29 at 14:26 +0200, Pierre-Elliott Bécue wrote:
> On Mon, 2023-05-29 at 07:37 +0200, Paul Gevers wrote:
> > 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.

  Thanks for confirming that -- for the time being I've unforwarded
this bug from upstream issue #553 as it looks like this is a new
problem.

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

  Can you grab /proc/cpuinfo from a physical CI host as well as from
within a container for the armel, armhf, and arm64 architectures? That
will let us see what difference(s) lxcfs is presenting and might give a
clue for the root issue. Since only the 32bit arm architectures appear
to be affected, I'm also curious to see what the arm64 cpuinfo is.

> > 
> > Paul
> > PS: I missed former messages due to a minor mistake in my address,
> > but I'm now subscribed.
> I think you should keep gibmat in the Cc list. :)

  +1 :)

Mathias


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

Bug#1036924: ITP: obfuscate -- Censor private information from images

[Matthias Geiger]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: obfuscate
  Version : 0.0.9
  Upstream Contact: Bilal Elmoussaoui 
* URL : https://apps.gnome.org/app/com.belmoussaoui.Obfuscate/
* License : GPL-3+
  Programming Lang: Rust
  Description : Censor private information from images

I intend to package obfuscate. It's a neat little program to censor private 
information
from images. This is useful if you hace to send sensitive information to 
gouvernments for instance.
As of now it is missing two rust libraries I already prepared and a subsequent
update of the gtk-rs stack. This package will be maintained under the GNOME 
teams' umbrella.

thanks,

werdahias


-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmR0rqggHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHWwvw//XU+O1bTIvziV
QUlYaORwPo2tuzOls0spbsrZuZG3pt71cvRzK3SlorBTIXXXQAMTgjV8r4PkvaXY
w2b7HL0Y76HjXOZyrBMcs/vmSvt5xS4IxCMsiAs+yxI9OO98j9sn4kszsCC842ge
uwogrpn4odGlajWke5P1OZUAJ//FsboRnQrQI8RYFEhxGeARNYw1a046l/ocbWEB
zwVrpc6X7wDgG/x64UfLUchPybAUetKpXMuFLNgkeFzScuQaX7hTg+yNOVD9D+By
51CGYGEkx3vxIRGnScA+dtG52hPh7I5qsOm8aTWF7TLd98dLVgvFCZum3cqBGQ+H
YsMch/ak9sLnqtgYj7fOa+Oxc7E0ydz+FTdGa3uJpghNPAvLpymKf2xk0HIbq+ao
9+e+e9RhTqJw6HW7gcww4i8ybX25nnb0AD+dVAv2CYt+FBo9xnnulrUVVljk9dng
hRQ5C129RmtBoXp1LVy/65vEDisuxJLSbTsc3LCyLx2mcI6HOwO2Fkl1RvOfK0O7
TAEGTMPUSoGcq4Ii2+SEiauTvl906znIxDr88OzeQz4oFi6U/JE/Kg/4v9698jKE
FkzLb6pTCgjkChPEB2h2ZHHSc78ZSYoAOTNkepDqc2dQoT93gIF6msu6AOdqf5V5
04JGpkBBnytVHSjYbwhuEquO1ENWSaA=
=WUh6
-END PGP SIGNATURE-

Bug#1030312: avoid aptitude

[Thomas Lange]

Yes, this is a bug.

I suggest to use apt-get instead. Therefore use PACKAGES install or
PACKAGES install-norec.

aptitude is not inside the nfsroot by default. That's why this will be
a low priority for me to fix.

Bug#1036923: radare2-cutter wrong name and package version

[XVilka]

Package: radare2-cutter
Version: 1.12.0

Since Cutter 2.x versions, it switched from Radare2 to Rizin as a backend (a 
fork of Radare2). Meanwhile, Radare2 developers renamed their GUI to "Iaito":

"radare2-cutter" should become just "cutter-re", like it's already called in 
some distributions (Fedora, for example).

Some of the packages are called "radare2-cutter", right, but with time they 
will either update to Rizin-based Cutter or Radare2-based Iaito 
(https://repology.org/project/iaito/versions); thus, the name is misleading 
from the point of view of both projects.

The latest available Cutter release (May 29, 2023) is 2.2.1, and the 
corresponding Rizin release is 0.5.2.

**Links for the reference**

- https://cutter.re
- https://github.com/rizinorg/cutter
- https://rizin.re/posts/faq/
- https://github.com/radareorg/iaito
- https://repology.org/project/cutter-re/versions
- https://repology.org/project/rizin/versions

**Release links**

- https://github.com/rizinorg/cutter/releases/tag/v2.2.1
- https://github.com/rizinorg/rizin/releases/tag/v0.5.2

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Helmut Grohne]

Hi Andreas,

On Mon, May 29, 2023 at 02:42:14PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package ships an empty
> directory (/usr/lib/modules-load.d/) which disappears after installation
> and removal of another package (e.g. multipath-tools) in a merged-/usr
> setup. This is not a bug in the other package, but an effect of our
> merged-/usr implementation.

Thank you Andreas for your attention to detail in locating and reporting
these kind of issues. Your QA work is being very useful again as it was
when you noticed how we broke adduser users.

I caution that this is an instance of a generic problem that affects all
sorts of packages shipping empty directories in aliased locations. It is
a problem that has not previously been on my radar of things to watch
out for and now is. I have yet to do the math of figuring out how many
other packages are affected in a similar way and intend to follow up
with that on d-devel@l.d.o.

> This is happening to trigger the bug: 

In what sense is the behaviour actually buggy? Quite obviously, this is
a reproducibility issue, because depending on how you order operations,
different things happen. I somewhat question though that this is a
serious issue and would expect systemd to deal with the absence in a
sane way. Do you have any evidence of it behaving otherwise?

If you file further bugs pertaining issues related to /usr-merge, I'd
appreciate an X-Debbugs-Cc.

Helmut

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Andreas Beckmann]

On 29/05/2023 14.57, Luca Boccassi wrote:

Side question first: does systemd evaluate both
/usr/lib/modules-load.d/* and /lib/modules-load.d/* ?
Otherwise all packages shipping something in /lib/modules-load.d/ are
broken on unmerged-/usr because their config snippets are not being
taken into account.


The correct path since bullseye was /usr/lib/modules-load.d, see:

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


I read this as these packages have been buggy on unmerged-/usr in 
bullseye. Why weren't there bugs filed?



Anyway, we don't really care about what happens on unmerged
installations, as they are no longer supported since Bookworm.


Well, there is still limited support, e.g. for buildd usage. But 
probably (hopefully?) for the last time.



Andreas

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Luca Boccassi]

On Mon, 29 May 2023 at 14:07, Andreas Beckmann  wrote:
>
> On 29/05/2023 14.57, Luca Boccassi wrote:
> > Wouldn't the correct workaround be to list /usr/lib/modules-load.d in
> > systemd.dirs so that dpkg leaves it alone? Seems way too late for
> > Bookworm though?
>
> for dpkg, /usr/lib/modules-load.d is already owned by systemd, dpkg only
> accidentally deletes it while removing /lib/modules-load.d
>
> That's the reason for adding some placeholder file there, to prevent
> accidental removal of the (no longer empty) directory.
> Could be part of the first bookworm point release.

Does it matter that much if the empty directory is removed? Next time
a package shipping a modules-load config is installed it will be just
re-added, no? Or are there functional issues?

Kind regards,
Luca Boccassi

Bug#1036922: RFP: duckdb -- DuckDB is an in-process SQL OLAP Database Management System

[James Healy]

Package: wnpp
Severity: wishlist

* Package name: duckdb
  Version : 0.8.0
  Upstream Contact: ??
* URL : https://duckdb.org/
* License : MIT
  Programming Lang: C/C++
  Description : DuckDB is an in-process SQL OLAP Database Management System

DuckDB is an interesting new inprocess databse library. Similar to
sqlite, but with a focus on OLAP shaped analytical queries rather than
transaction queries.

It's popular in data science and data platform circles. Upstream
maintains official bindings for some languages, as well as a native cli
tool. Having the c library and cli available in debian will make it easier
for users to experiment with duckdb in a variety on languages and tools.

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Andreas Beckmann]

On 29/05/2023 14.57, Luca Boccassi wrote:

Wouldn't the correct workaround be to list /usr/lib/modules-load.d in
systemd.dirs so that dpkg leaves it alone? Seems way too late for
Bookworm though?


for dpkg, /usr/lib/modules-load.d is already owned by systemd, dpkg only 
accidentally deletes it while removing /lib/modules-load.d


That's the reason for adding some placeholder file there, to prevent 
accidental removal of the (no longer empty) directory.

Could be part of the first bookworm point release.


Andreas

Bug#898259: codium status

[matthias . geiger1024]

Hi all,

linking those two bugreports because they are related. Since vscode shouldn't 
be distributed in debian because of the telemetry I think packaging codium is 
best solution here. Like you probably know Microsoft takes the source and adds 
telemetry on top. (vs)codium takes the source code and a) strips the branding 
and b) removes the telemetry. I created a wiki page [1] to track the packaging 
effort. There doesn't seem to be missing much; afaik it also needs electron, 
unfortunately.
Also vscodium doesn't release the amended source from what I can tell but 
rather their scripts to create it.
This also might be an obstacle.

regards,
---
Matthias Geiger (werdahias)

[1] https://wiki.debian.org/Javascript/Nodejs/Tasks/codium-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#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Luca Boccassi]

On Mon, 29 May 2023 14:42:14 +0200 Andreas Beckmann 
wrote:
> Package: systemd
> Version: 252.6-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships an empty
> directory (/usr/lib/modules-load.d/) which disappears after
installation
> and removal of another package (e.g. multipath-tools) in a merged-
/usr
> setup. This is not a bug in the other package, but an effect of our
> merged-/usr implementation.
> 
> Side question first: does systemd evaluate both
> /usr/lib/modules-load.d/* and /lib/modules-load.d/* ?
> Otherwise all packages shipping something in /lib/modules-load.d/ are
> broken on unmerged-/usr because their config snippets are not being
> taken into account.

The correct path since bullseye was /usr/lib/modules-load.d, see:

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

Anyway, we don't really care about what happens on unmerged
installations, as they are no longer supported since Bookworm.

> This is happening to trigger the bug: 
> 
> systemd ships /usr/lib/modules-load.d/ (empty directory)
> multipath-tools ships /lib/modules-load.d/multipath.conf
> dpkg doesn't know that /lib/modules-load.d/ and /usr/lib/modules-
load.d/
> are the same, and therefore removal of multipath-tools causes removal
of
> * /lib/modules-load.d/multipath.conf (OK)
> * /lib/modules-load.d/ (if it was the last owner of that directory),
while
>   it effectively is /usr/lib/modules-load.d/ getting removed
> 
> When adding a placeholder file, it needs to be something that is
ignored 
> by the processing of the .d directory (the pattern could be *.conf,
but I
> might be mistaken here).
> 
> An alternative to shipping a placeholder file could be shipping
> /lib/modules-load.d/ as additional empty directory, but I don't know
> whether this would be allowed w.r.t. merged-/usr.
> 
> 
> From the attached log (scroll to the bottom...):
> 
> 0m39.2s ERROR: FAIL: After purging files have disappeared:
>   /usr/lib/modules-load.d/   owned by: systemd
> 
> 
> This is not caught by default piuparts tests as there is no test with
> systemd explicitly installed.
> 
> I could not reproduce this issue in bullseye (and haven't tried to
> reproduce it in earlier releases).

Wouldn't the correct workaround be to list /usr/lib/modules-load.d in
systemd.dirs so that dpkg leaves it alone? Seems way too late for
Bookworm though?

-- 
Kind regards,
Luca Boccassi


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

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

[Andreas Hasenack]

Hi,

On Sun, May 28, 2023 at 4:12 PM Otto Kekäläinen  wrote:
> 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

I spotted a similar failure in Ubuntu, but mostly on arm64. Maybe it's
just a simple race between starting saslauthd and using it. I'll take
a look.

Bug#1036921: ITP: fortune-dhp/0.1-1 -- Dhammapada Fortune

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "fortune-dhp":

 The alternative to the "display-dhammapada" application It is a collection
of
 Buddhist sayings and is available in CLI (Command Line Interface)
  and GUI (Graphical User Interface) modes. It supports the Gnome
 and KDE desktop environments.

 The "Dhammapada Fortune" application utilizes the "fortune-mod"
 program to provide its functionality. It retrieves Dhammapada data
 from SuttaCentral.net, a popular online resource for Buddhist texts.

 The application offers translations in 19 different languages and
 includes 25 translation cookies. The supported languages are Catalan,
 Czech, German, English, Spanish, French, Hebrew, Hungarian, Italian,
 Japanese, Marathi, Burmese, Dutch, Norwegian, Polish, Portuguese,
 Singhalese, Slovenian, and Tamil.


 * Package name : fortune-dhp
   Version  : 0.1-1
   Upstream contact : 
 * URL  : https://github.com/kokoye2007/fortune-dhp
 * License  : LGPL-3.0+
 * Vcs  : https://github.com/kokoye2007/fortune-dhp
   Section  : games

The source builds the following binary packages:

  fortune-dhp - Dhammapada Fortune

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

  https://mentors.debian.net/package/fortune-dhp/

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

  dget -x
https://mentors.debian.net/debian/pool/main/f/fortune-dhp/fortune-dhp_0.1-1.dsc

Changes for the initial release:

 fortune-dhp (0.1-1) unstable; urgency=medium
 .
   * Initial release

Regards,

Bug#1031046: Error while trying to create asterisk-20.3.0 deb file

[Daniel Huhardeaux]

Hi,

I try to create a deb file using dh_make or cowbuilder and it fail with 
the same error:


configure.ac:508: error: possibly undefined macro: AC_MSG_WARN
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.ac:849: error: possibly undefined macro: AC_LANG_PROGRAM
autoreconf: error: /usr/bin/autoconf failed with exit status: 1
dh_autoreconf: error: autoreconf -f -i returned exit code 1
make: *** [debian/rules:19: binary] Error 255
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2

I: copying local configuration
E: Failed autobuilding of package
I: unmounting dev/ptmx filesystem
I: unmounting dev/pts filesystem
I: unmounting dev/shm filesystem
I: unmounting proc filesystem
I: unmounting sys filesystem
I: Cleaning COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.76107
root@cherry:/home/dh/packages#

Base package is asterisk-20-current.tar.gz

Any clue?

--
Daniel

Bug#1036539: nbd-client: not working inside initrd due to unresolved library dependencies

[Wouter Verhelst]

Control: tags -1 unreproducible
thanks

Hi Tomasz,

On Mon, May 22, 2023 at 09:03:12AM +0200, Tomasz Wolak wrote:
> Package: nbd-client
> Version: 1:3.21-1+deb11u1
> Severity: important
> Tags: d-i
> X-Debbugs-Cc: tomas.wo...@gmail.com
> 
> 
> The nbd-client binary (/sbin/nbd-client), while working fine on the regular
> system,
> is not working inside initrd images (which have very limited set of 
> libraries).
> During system startup, it is failing with:
> /sbin/nbd-client: error while loading shared libraries: libgnutls.so.30: 
> cannot
> open shared object file: No such file or directory
> 
> Currently the nbd-client used for building initrd images is copied the
> initramfs hook
> /usr/share/initramfs-tools/hooks/nbd
> which uses the regular /sbin/nbd-client, which has the following dependencies
> (the example is for i386, but, of course, similar for others):
> 
> # ldd /sbin/nbd-client
> linux-gate.so.1 (0xb7f3f000)
> libgnutls.so.30 => /lib/i386-linux-gnu/libgnutls.so.30 (0xb7cf5000)
> libnl-genl-3.so.200 => /lib/i386-linux-gnu/libnl-genl-3.so.200
> (0xb7cec000)
> libnl-3.so.200 => /lib/i386-linux-gnu/libnl-3.so.200 (0xb7cc7000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7adf000)
> libp11-kit.so.0 => /lib/i386-linux-gnu/libp11-kit.so.0 (0xb798a000)
> libidn2.so.0 => /lib/i386-linux-gnu/libidn2.so.0 (0xb7968000)
> libunistring.so.2 => /lib/i386-linux-gnu/libunistring.so.2 
> (0xb77e6000)
> libtasn1.so.6 => /lib/i386-linux-gnu/libtasn1.so.6 (0xb77cf000)
> libnettle.so.8 => /lib/i386-linux-gnu/libnettle.so.8 (0xb7784000)
> libhogweed.so.6 => /lib/i386-linux-gnu/libhogweed.so.6 (0xb773b000)
> libgmp.so.10 => /lib/i386-linux-gnu/libgmp.so.10 (0xb76ab000)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7689000)
> /lib/ld-linux.so.2 (0xb7f41000)
> libffi.so.7 => /lib/i386-linux-gnu/libffi.so.7 (0xb767f000)
> libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7679000)
> 
> which, as one can expect, are not met inside an initrd...

So, actually, this bit is not true.

/usr/share/initramfs-tools/hooks/nbd looks like this:

-8<-
#!/bin/sh

# We don't have any prerequirements
case $1 in
prereqs)
exit 0
;;
esac

. /usr/share/initramfs-tools/hook-functions

manual_add_modules nbd
auto_add_modules net
copy_exec /sbin/nbd-client /sbin
->8-

The "copy_exec" in there is a shell function, defined in the
/usr/share/initramfs-tools/hook-functions library, which copies a
program *and all the libraries it requires* into the initramfs.

I checked, and on my system the initramfs does in fact contain all the
necessary libraries. You can check yourself; for instance, to check
libnettle you would do:

wouter@pc220518:~/scratch$ lsinitramfs /boot/initrd.img-$(uname -r)|grep 
libnettle
usr/lib/x86_64-linux-gnu/libnettle.so.8
usr/lib/x86_64-linux-gnu/libnettle.so.8.6

or for gnutls:

wouter@pc220518:~/scratch$ lsinitramfs /boot/initrd.img-$(uname -r)|grep gnutls
usr/lib/x86_64-linux-gnu/libgnutls.so.30
usr/lib/x86_64-linux-gnu/libgnutls.so.30.34.3

If this doesn't work for you for some reason, then either you have
misconfigured initramfs-tools or something else is going on -- but at
any rate it is not a problem in nbd-client.

I'm leaving this open for the time being in case I missed something; but
unless you can show me that something is going wrong in the nbd-client
package, I'm going to close this bug a few weeks from now.

Thanks,

-- 
 w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

Bug#1036920: systemd: please ship a placeholder in /usr/lib/modules-load.d/

[Andreas Beckmann]

Package: systemd
Version: 252.6-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships an empty
directory (/usr/lib/modules-load.d/) which disappears after installation
and removal of another package (e.g. multipath-tools) in a merged-/usr
setup. This is not a bug in the other package, but an effect of our
merged-/usr implementation.

Side question first: does systemd evaluate both
/usr/lib/modules-load.d/* and /lib/modules-load.d/* ?
Otherwise all packages shipping something in /lib/modules-load.d/ are
broken on unmerged-/usr because their config snippets are not being
taken into account.

This is happening to trigger the bug: 

systemd ships /usr/lib/modules-load.d/ (empty directory)
multipath-tools ships /lib/modules-load.d/multipath.conf
dpkg doesn't know that /lib/modules-load.d/ and /usr/lib/modules-load.d/
are the same, and therefore removal of multipath-tools causes removal of
* /lib/modules-load.d/multipath.conf (OK)
* /lib/modules-load.d/ (if it was the last owner of that directory), while
  it effectively is /usr/lib/modules-load.d/ getting removed

When adding a placeholder file, it needs to be something that is ignored 
by the processing of the .d directory (the pattern could be *.conf, but I
might be mistaken here).

An alternative to shipping a placeholder file could be shipping
/lib/modules-load.d/ as additional empty directory, but I don't know
whether this would be allowed w.r.t. merged-/usr.


>From the attached log (scroll to the bottom...):

0m39.2s ERROR: FAIL: After purging files have disappeared:
  /usr/lib/modules-load.d/   owned by: systemd


This is not caught by default piuparts tests as there is no test with
systemd explicitly installed.

I could not reproduce this issue in bullseye (and haven't tried to
reproduce it in earlier releases).


cheers,

Andreas

PS: packages shipping files in modules-load.d/ (in sid):

# apt-file search /lib/modules-load.d/
aoetools: /usr/lib/modules-load.d/aoetools.conf
dlm-controld: /usr/lib/modules-load.d/configfs.conf
drbd-utils: /lib/modules-load.d/drbd.conf
ecryptfs-utils: /lib/modules-load.d/ecryptfs.conf
fwupd: /usr/lib/modules-load.d/fwupd-msr.conf
iwd: /usr/lib/modules-load.d/pkcs8.conf
libddccontrol0: /usr/lib/modules-load.d/ddccontrol-i2c-dev.conf
mbpfan: /lib/modules-load.d/mbpfan.depend.conf
multipath-tools: /lib/modules-load.d/multipath.conf
open-vm-tools-desktop: /usr/lib/modules-load.d/open-vm-tools-desktop.conf
osspd: /lib/modules-load.d/osspd.conf
zfsutils-linux: /lib/modules-load.d/zfs.conf


systemd-modules-load.d.log.gz
Description: application/gzip

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

[Pierre-Elliott Bécue]

De : Paul Gevers 
À : 1036...@bugs.debian.org
Cc : Evgeni Golov ; Pierre-Elliott Bécue ; 
Jochen Sprickerhof 
Date : 29 mai 2023 07:41:30
Objet : Re: Bug#1036818: linux on armel/armhf: Perl library unable to access 
get CPU info from /proc/cpu or kstat

> 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.
I think you should keep gibmat in the Cc list. :)

-- 
Pierre-Elliott Bécue

Bug#1036919: debvm: singleshot mode

[Wouter Verhelst]

Package: debvm
Version: 0.2.10
Severity: wishlist

Hi,

I would like to use debvm to run autopkgtests for nbd-client. In order
to do that, I would need to run the vm noninteractively, do some in-vm
tests, and then shut it down again, with the result of the test
affecting the exit state.

Perhaps I missed it, but I didn't see a way to do this.

Please make something like this easier :)

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

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

Versions of packages debvm depends on:
ii  e2fsprogs   1.47.0-2
ii  genext2fs   1.5.0-3
ii  ipxe-qemu   1.0.0+git-20190125.36a4c85-5.1
ii  mmdebstrap  1.3.5-7
ii  passwd  1:4.13+dfsg1-1+b1
ii  qemu-system-arm 1:7.2+dfsg-7
ii  qemu-system-mips1:7.2+dfsg-7
ii  qemu-system-misc1:7.2+dfsg-7
ii  qemu-system-ppc 1:7.2+dfsg-7
ii  qemu-system-sparc   1:7.2+dfsg-7
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-7

Versions of packages debvm recommends:
ii  arch-test 0.20-1
ii  binfmt-support2.2.2-2
ii  fakechroot2.20.1+ds-15
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  openssh-client1:9.2p1-2
ii  qemu-system   1:7.2+dfsg-7
ii  qemu-user-static  1:7.2+dfsg-7
ii  seabios   1.16.2-1
ii  systemd   252.6-1
ii  uidmap1:4.13+dfsg1-1+b1

Versions of packages debvm suggests:
ii  qemu-system-gui  1:7.2+dfsg-7

-- no debconf information

Bug#1036918: debvm: manual mounting of root image

[Wouter Verhelst]

Package: debvm
Version: 0.2.10
Severity: wishlist

Hi,

I am exploring the possibility to write an autopkgtest for the initramfs
stuff that I wrote for nbd-client.

In order to do so, I want to run a client VM that has no root hard disk
configured, but is configured to attempt to mount the VM image over the
network, using NBD. This is accomplished by way of a few kernel command
line parameters.

I tried running

debvm-run -- -append 'nbdroot=192.168.88.103,root_export,nbd0'

however, since debvm-run had by this point already mounted the hard
drive, the kernel sees the same root device twice, and let's just say
that this didn't go very well.

I would like to see an option to tell debvm-run not to mount the
filesystem image but to let the user handle that. However, the
extracting of the kernel and initramfs which debvm-run does would still
be necessary; it's just that I want to fiddle with how we get to the
filesystem.

Thanks,

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

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

Versions of packages debvm depends on:
ii  e2fsprogs   1.47.0-2
ii  genext2fs   1.5.0-3
ii  ipxe-qemu   1.0.0+git-20190125.36a4c85-5.1
ii  mmdebstrap  1.3.5-7
ii  passwd  1:4.13+dfsg1-1+b1
ii  qemu-system-arm 1:7.2+dfsg-7
ii  qemu-system-mips1:7.2+dfsg-7
ii  qemu-system-misc1:7.2+dfsg-7
ii  qemu-system-ppc 1:7.2+dfsg-7
ii  qemu-system-sparc   1:7.2+dfsg-7
ii  qemu-system-x86 [qemu-kvm]  1:7.2+dfsg-7

Versions of packages debvm recommends:
ii  arch-test 0.20-1
ii  binfmt-support2.2.2-2
ii  fakechroot2.20.1+ds-15
ii  fakeroot  1.31-1.2
ii  file  1:5.44-3
ii  openssh-client1:9.2p1-2
ii  qemu-system   1:7.2+dfsg-7
ii  qemu-user-static  1:7.2+dfsg-7
ii  seabios   1.16.2-1
ii  systemd   252.6-1
ii  uidmap1:4.13+dfsg1-1+b1

Versions of packages debvm suggests:
ii  qemu-system-gui  1:7.2+dfsg-7

-- no debconf information

Bug#1036907: release-notes: dash in bookworm drops debconf selector for /bin/sh

[Andrej Shadura]

Hi,

On Mon, 29 May 2023, at 12:34, Paul Gevers wrote:
> On 29-05-2023 11:22, Andrej Shadura wrote:
>> I wasn’t 100% sure, but I have now verified and yes, dash reclaims /bin/sh 
>> on upgrades.
>
> Ack (and a bit of ugh).
>
>> I could have handled that smarter and given users one release to adjust, but 
>> I guess it’s probably a bit late for that?
>
> Absolutely.
>
> How was this technically done in the past, diversions, 
> update-alternatives, something else?

Diversions, but since it’s /bin/sh, it also involved a bit of tricks to prevent 
things from breaking in bad ways.

-- 
Cheers,
  Andrej

Bug#1034043: RFS: git-credential-oauth/0.5.2-1 -- Git credential helper for GitHub and other forges using OAuth

[Tobias Frost]

Control: tags -1 moreinfo

Hi, 

upstream is at version 0.7, can you update to it?

-- 
tobi

Bug#1036910: cyrus-sasl2: [INTL:tr] turkish translation of debconf messages

[Atila KOÇ]

Yes, I do.

If there is any modification I need to do for the translation file (in 
the header), let me know.



29.05.2023 13:26 tarihinde Bastian Germann yazdı:

Am 29.05.23 um 12:07 schrieb Atila KOÇ:
Find attached the Turkish translation of the cyrus-sasl2 debconf 
messages=


Do you also allow distribution under BSD-2-clause? This is my 
condition for including it.
I try to keep the debian files under standard licenses that are 
compatible with GPL.

--- YASAL UYARI ---

Bug#1036917: lintian: add checks for polkit rules

[Simon McVittie]

Package: lintian
Version: 2.116.3
Severity: wishlist

It would be useful for Lintian to have some checks for the policy rules
used by polkit (formerly PolicyKit) to decide whether to allow privileged
actions to be done on behalf of unprivileged users:

* packages with JavaScript polkit rules should install them into
  /usr/share/polkit-1/rules.d/*.rules, and not into
  /etc/polkit-1/rules.d/*.rules which is reserved for the sysadmin

  - very similar to udev-rule-in-etc
  - pseudocode: foreach $path (/etc/polkit-1/rules.d/*.rules) {
emit polkit-rule-in-etc $path
}
  - possible text:
This package ships polkit rules and installs them under /etc/polkit-1,
which is reserved for user-installed files. The correct location for
system rules is /usr/share/polkit-1/rules.d/*.rules for JavaScript
rules, or /var/lib/polkit-1/localauthority/10-vendor.d/*.pkla for
legacy .pkla rules.

* similarly packages should not have legacy .pkla rules in
  /etc/polkit-1/localauthority/*.d/*.pkla

  - very similar to udev-rule-in-etc
  - pseudocode: foreach $path (/etc/polkit-1/localauthority/*.d/*.pkla)
emit polkit-rule-in-etc $path
}
  - same text as above

* if a package ships legacy .pkla rules then it should ship a JavaScript
  equivalent, so that it will work as intended without installing
  polkitd-pkla

  - pseudocode: foreach $path (
   /var/lib/polkit-1/localauthority/*.d/*.pkla
   /etc/polkit-1/localauthority/*.d/*.pkla
) {
if package does not contain /etc/polkit-1/rules.d/*.rules
or /usr/share/polkit-1/rules.d/*.rules {
emit polkit-rule-without-js-equivalent $path
}
}
  - possible text:
This package ships legacy polkit rules in .pkla format, but does not
provide an equivalent in the newer JavaScript rules format. Rules
in .pkla format will be ignored if the polkitd-pkla package is
not installed. The package should install a JavaScript equivalent
of the legacy rules into /usr/share/polkit-1/rules.d/*.rules.
Reference: 
https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/170
   (or the actual release notes after that MR is merged)
Reference: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/66

* emit a classification or info tag for packages with legacy polkit rules
  (still necessary if the package should be backported to Debian 11
  or Ubuntu 23.04, unnecessary since Debian 12, will hopefully become
  unnecessary in Ubuntu 23.10 at which point this can become a warning)

  - pseudocode: foreach $path (
   /var/lib/polkit-1/localauthority/*.d/*.pkla
   /etc/polkit-1/localauthority/*.d/*.pkla
) {
emit polkit-rule-in-pkla-format $path
}
  - possible text:
This package ships legacy polkit rules in .pkla format, which have
been superseded by the newer JavaScript rules format.

Thanks,
smcv

Bug#1036916: RM: librust-wayland-commons-dev -- ROM; Obsolete, blocks other packages from migrating

[Jeremy Bícha]

Control: tags -1 +moreinfo

This package isn't ready for removal until the rust-wayland-* packages
that Build-Depend on it are uploaded to Unstable without that
dependency. When that happens, please remove the moreinfo tag.

Thank you,
Jeremy Bícha

Bug#1036913: wildmidi: update d/watch file with a patch

[Patrice Duroux]

Package: wildmidi
Version: 0.4.3-1
Followup-For: Bug #1036913

Oops, with the patch attached this time.


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 wildmidi depends on:
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9
ii  libwildmidi2  0.4.3-1

Versions of packages wildmidi recommends:
ii  libwildmidi-config  0.4.3-1

wildmidi suggests no packages.

-- no debconf information
diff --git a/debian/watch b/debian/watch
index b2f0067..39096af 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,2 +1,4 @@
 version=4
-https://github.com/psi29a/wildmidi/releases 
.*wildmidi-([0-9]+\.[0-9]+\.[0-9]+).tar.gz
+opts="filenamemangle=s%(?:.*?)?v?@ANY_VERSION@(@ARCHIVE_EXT@)%@PACKAGE@-$1$2%" 
\
+  https://github.com/Mindwerks/@PACKAGE@/tags \
+  (?:.*?/)@PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@

Bug#1036915: apt crash in parser

[Ritesh Raj Sarraf]

Package: apt
Version: 2.6.1
Severity: important
X-Debbugs-Cc: r...@debian.org

Dear maintainer,

While trying to rebuild another package from Bookworm, it came a
surprise that `apt` crashed. Below are some details, which should help
you reproduce the crash. Note that the issue is, so far, only seen wile
building the `eckit` package.


```
rrs@priyasi:~/.../eckit (debian/bookworm)$ apt build-dep .
Note, using directory '.' to get the build dependencies
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_M_create
Aborted (core dumped)
16:37 ♒ ॐ ♅ ♄ ⛢  ☹ => 134

rrs@priyasi:~/.../eckit (debian/bookworm)$ apt -v
apt 2.6.1 (amd64)
16:37 ♒ ॐ ♅ ♄ ⛢ ☺ 
```

Here's the stacktrace:


```
Module libsystemd.so.0 from deb systemd-252.6-1.amd64
Module libudev.so.1 from deb systemd-252.6-1.amd64
Stack trace of thread 158831:
#0  0x7f3b9d2a9ccc __pthread_kill_implementation (libc.so.6 
+ 0x8accc)
#1  0x7f3b9d25aef2 __GI_raise (libc.so.6 + 0x3bef2)
#2  0x7f3b9d245472 __GI_abort (libc.so.6 + 0x26472)
#3  0x7f3b9d49d919 n/a (libstdc++.so.6 + 0x9d919)
#4  0x7f3b9d4a8e1a n/a (libstdc++.so.6 + 0xa8e1a)
#5  0x7f3b9d4a8e85 _ZSt9terminatev (libstdc++.so.6 + 
0xa8e85)
#6  0x7f3b9d4a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8)
#7  0x7f3b9d4a01e9 _ZSt20__throw_length_errorPKc 
(libstdc++.so.6 + 0xa01e9)
#8  0x7f3b9d53f8b9 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE9_M_createERmm 
(libstdc++.so.6 + 0x13f8b9)
#9  0x7f3b9d8490aa n/a (libapt-pkg.so.6.0 + 0x1000aa)
#10 0x7f3b9d84b3f2 
_ZN13debListParser12ParseDependsEPKcS1_RN3APT10StringViewES4_RjbbbNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 (libapt-pkg.so.6.0 + 0x1023f2)
#11 0x7f3b9d84bde3 
_ZN13debListParser12ParseDependsEPKcS1_RNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_RjRKbSB_SB_RKS7_
 (libapt-pkg.so.6.0 + 0x102de3)
#12 0x7f3b9d86404c n/a (libapt-pkg.so.6.0 + 0x11b04c)
#13 0x7f3b9d99dafe n/a (libapt-private.so.0.0 + 0x59afe)
#14 0x7f3b9d9a1da3 _Z10DoBuildDepR11CommandLine 
(libapt-private.so.0.0 + 0x5dda3)
#15 0x7f3b9d816097 
_ZN11CommandLine11DispatchArgEPKNS_8DispatchEb (libapt-pkg.so.6.0 + 0xcd097)
#16 0x7f3b9d96453e 
_Z19DispatchCommandLineR11CommandLineRKSt6vectorINS_8DispatchESaIS2_EE 
(libapt-private.so.0.0 + 0x2053e)
#17 0x56202509f29f n/a (apt + 0x229f)
#18 0x7f3b9d24618a __libc_start_call_main (libc.so.6 + 
0x2718a)
#19 0x7f3b9d246245 __libc_start_main_impl (libc.so.6 + 
0x27245)
#20 0x56202509f371 n/a (apt + 0x2371)
ELF object binary architecture: AMD x86-64
```

Of particular relevance should be:

```
#10 0x7f3b9d84b3f2 
_ZN13debListParser12ParseDependsEPKcS1_RN3APT10StringViewES4_RjbbbNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
 (libapt-pkg.so.6.0 + 0x1023f2)
#11 0x7f3b9d84bde3 
_ZN13debListParser12ParseDependsEPKcS1_RNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES8_RjRKbSB_SB_RKS7_
 (libapt-pkg.so.6.0 + 0x102de3)
```


The problem seems to be reproducible with the following snippet from `eckit`:

```
Build-Depends: debhelper-compat (= 13),
  dh-buildinfo,
  ecbuild (>= 3.6.1-1~),
  chrpath,
  flex,
  bison,
  libopenblas-dev [ amd64 arm64 armhf i386 mips64el ppc64el s390x ppc64 ],
  libblas-dev [ !amd64 !arm64 !armhf !i386 !mips64el !ppc64el !s390x !ppc64 ],
  liblapack-dev [ !amd64 !arm64 !armhf !i386 !mips64el !ppc64el !s390x !ppc64],
  libaec-dev,
  libxxhash-dev,
  libjemalloc-dev,
  librados-dev [!hurd-i386  !kfreebsd-amd64 !kfreebsd-i386 !riscv64 !sh4 !ia64 
!alpha !hppa !powerpc !mipsel] ,
  libradospp-dev [!hurd-i386  !kfreebsd-amd64 !kfreebsd-i386 !riscv64 !sh4 
!ia64 !alpha !hppa !powerpc !mipsel],
  libbz2-dev,
  liblz4-dev,
  libeigen3-dev,
  libsnappy-dev,
  librsync-dev,
  mpi-default-dev,
  doxygen,
  python3-all,
  libssl-dev,
  libcurl4-gnutls-dev (>=  7.20),
  libncurses-dev
```

If I drop the architecture specific bits from the packages, `apt` then
does not crash. In short, revise the above to:

```
Build-Depends: debhelper-compat (= 13),
  dh-buildinfo,
  ecbuild (>= 3.6.1-1~),
  chrpath,
  flex,
  bison,
  libopenblas-dev,
  libblas-dev,
  liblapack-dev,
  libaec-dev,
  libxxhash-dev,
  libjemalloc-dev,
  librados-dev,
  libradospp-dev,
  libbz2-dev,
  liblz4-dev,
  libeigen3-dev,
  libsnappy-dev,
  librsync-dev,
  mpi-default-dev,
  doxygen,
  python3-all,
  libssl-dev,
  libcurl4-gnutls-dev (>=  7.20),
  libncurses-dev
```



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";

Bug#1036916: RM: librust-wayland-commons-dev -- ROM; Obsolete, blocks other packages from migrating

[Matthias Geiger]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: rust-wayland-comm...@packages.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net, matthias.geiger1...@tutanota.de
Control: affects -1 + src:rust-wayland-commons

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi ftpmasters,

please remove rust-wayland-commons from unstable. It is obsolete in the newer 
wayland stack 
and will prevent packages from migrating.

Thanks,

werdahias


-BEGIN PGP SIGNATURE-

iQJUBAEBCgA+FiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmR0itUgHG1hdHRoaWFz
LmdlaWdlcjEwMjRAdHV0YW5vdGEuZGUACgkQGL0QaztsVHV9wBAAjUacv3qJ/c92
Kdfy5J+yMr3/VYhrO+YkFj+8IQy+jJP8++DTLbFkRX8BcuPGrP226/sIUomqGUO3
eLPWwiXcHX7tVCQNu3gBX9lDOAAlP+gCIlTXuDHCVS+0DZxw73he4YeP9PQLjjtT
wheG48AXED8taTMLmbB+To8Z3nFSP3547UHbTXZLpesIXDV/ItBMHclkj64fRMSq
spSYHDN8xuz4YCsYhn/YM9a9Ir6xwf7KCvOqiYYjyugBQeCMSWOlZyfu0Tm7FWWU
E8T4RAv7A2knRkRpGwDnlXb7lpE8Unkf9clxFXR1Ry/kQArPjI3ekrJlIr4qiihU
0U73q65Nqs/0fhvQ/bM3+uk6CK3jY7AO43ISgiwxpTnzlMJGeNax1H1AzYDnfz+U
Qb+wxu7pyHck6eu5X1JP7H325Em65J7kldn65RC9KhiTFu+0nl1JDZYV8kmDT+R+
PinvZfsj87jqMZqOlN8k0KpCUNSezy1NF+P6aubkACxd6F2Ilc/l1KkAMaIAgiUd
mYYr+NaTJJcZ1JCUtWtfcajg83ETL5dvxZvJq96lMvgZ3OOAQZXYvcEYAe/KTiAz
QwQYxT3A1I0Y/YOX+Kw6yb6JCyzFh/yOiW7Gf+5cPqL/kMTwLhXjyiiauC283HoW
4lGmrOS3GPrwcxCF+i9HGPyxCmM0c34=
=F3Fy
-END PGP SIGNATURE-

Bug#1036914: unblock: librem5-flash-image/0.0.3-1

[Guido Günther]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: librem5-flash-im...@packages.debian.org
Control: affects -1 + src:librem5-flash-image

Please unblock package librem5-flash-image

The tool is used to flash images to Librem 5 phones.

[ Reason ]
This adds support for stable image downloads (rather than
always fetching the latest image to flash to the phone)
hence it seems appropriate to have that in a stable relase.
It also makes downloading a bit more robust by allowing for longer
timeouts.

[ Impact ]
Users will have to manually go out and search for stable images.

[ Tests ]
- Tested flashing manually
- CI tests (that download images) pass upstream in a Debian container

[ Risks ]
Risks should be low as the package is in use on other distros since some
time.

[ 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 apologize for being late here, I simply missed that the version
is outdated. I could have backported the patch but just using the
upstream version (which didn't bring any other features) seemed more
reasonable here.

unblock librem5-flash-image/0.0.3-1
diff --git a/debian/changelog b/debian/changelog
index 2c0f47f..d94dbf9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+librem5-flash-image (0.0.3-1) unstable; urgency=medium
+
+  * New upstream release
+
+ -- Guido Günther   Fri, 24 Feb 2023 17:53:10 +0100
+
 librem5-flash-image (0.0.2-1) unstable; urgency=medium
 
   * New upstream release 0.0.2
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 3d0bb65..b2eeae8 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,4 +1,17 @@
 [DEFAULT]
-debian-branch=debian/master
+debian-branch = debian/master
+debian-tag = debian/%(version)s
+upstream-branch = upstream/latest
+upstream-tag = upstream/%(version)s
+upstream-vcs-tag = v%(version)s
 pristine-tar = True
-upstream-tag = v%(version)s
+
+[tag]
+sign-tags = true
+
+[dch]
+multimaint-merge = True
+
+[import-orig]
+postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit
+upstream-vcs-tag = v%(version%~%_)s
diff --git a/scripts/librem5-flash-image b/scripts/librem5-flash-image
index be28869..3896d8c 100755
--- a/scripts/librem5-flash-image
+++ b/scripts/librem5-flash-image
@@ -35,6 +35,12 @@ except ImportError:
 
 from urllib.parse import urljoin
 
+IMAGES = {
+'stable': {
+'url': 'https://storage.puri.sm/librem5/images/',
+}
+}
+
 JENKINS = 'https://arm01.puri.sm'
 BOARD_TYPE = 'librem5r4'
 VALID_PHONE_BOARD_TYPES = ['librem5r2', 'librem5r3', 'librem5r4']
@@ -130,7 +136,8 @@ def resuming_stream(url, expected_size, max_attempts):
 try:
 resp = requests.get(url,
 stream=True,
-headers={'Range': 'bytes={}-'.format(position)}
+headers={'Range': 'bytes={}-'.format(position)},
+timeout=10
 )
 resp.raise_for_status()
 
@@ -145,7 +152,9 @@ def resuming_stream(url, expected_size, max_attempts):
 if position < expected_size:
 raise PrematureEndException()
 return
-except (requests.exceptions.ConnectionError, PrematureEndException):
+except (requests.exceptions.ConnectionError,
+requests.exceptions.Timeout,
+PrematureEndException):
 if i == max_attempts - 1:
 logging.error("Max connection errors reached, aborting")
 raise
@@ -207,7 +216,7 @@ def download_image(url, target, attempts):
 verify_image(target, meta)
 
 
-def find_image(jobname, type, variant, dist):
+def find_image_jenkins(jobname, type, variant, dist):
 server = jenkins.Jenkins(JENKINS)
 logging.info("Looking for {} {} {} image".format(type, variant, dist))
 try:
@@ -219,6 +228,8 @@ def find_image(jobname, type, variant, dist):
 resp = requests.get(build['url'] + '/api/json')
 resp.raise_for_status()
 json = resp.json()
+if json['description'] is None:
+continue
 if (json['description'].startswith(variant + ' ' + type) and
 dist in json['description'] and
 json['result'] == 'SUCCESS'):
@@ -229,6 +240,40 @@ def find_image(jobname, type, variant, dist):
 return found
 
 
+def find_image_stable(board, variant, dist):
+remote = IMAGES['stable']
+logging.info("Looking for {} {} {} image".format(board, variant, dist))
+found = None
+
+path = f"{dist}/latest/{board}/{variant}/"
+url = urljoin(remote['url'], f"{path}/artifact/{IMAGE.format(board)}.xz")
+try:
+resp = requests.head(url, timeout=10)
+if resp.ok:
+d = 

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

[Max Nikulin]

On 29/05/2023 17:59, Paul Gevers wrote:


On 29-05-2023 12:51, Max Nikulin wrote:
I am unaware of another dash implementation. Do you mean ash from 
which dash was forked?


No, I understood from Andrej that dash *internally* has two ways to do 
the matching. One embedded implementation, and one using system library 
calls.


Thank you for clarification, I did not realized that you were writing 
about glob/fnmatch implementation that supports [^c] negation in glibc 
while the internal alternative treats its as a literal. Other libc 
variants are out of the scope of the debian package.

Bug#1036913: wildmidi: update d/watch file with a patch

[Patrice Duroux]

Package: wildmidi
Version: 0.4.3-1
Severity: wishlist

Dear Maintainer,

It reaches the last upstream version (0.4.5)

Regards,
Patrice


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

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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 wildmidi depends on:
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9
ii  libwildmidi2  0.4.3-1

Versions of packages wildmidi recommends:
ii  libwildmidi-config  0.4.3-1

wildmidi suggests no packages.

-- no debconf information

Bug#1036912: pipewire-pulse: "address already in use" when enabling tcp server due to race condition on user switching

[Micha Moskovic]

Package: pipewire-pulse
Version: 0.3.65-3
Severity: normal
X-Debbugs-Cc: micha...@gmail.com

Dear Maintainer,

I want to have pipewire-pulse listen on a TCP socket in order to be able
to play music from an mpd deamon running as a different user, which is
configured to use pulseaudio output on localhost (there might be a
better way to play sound from a different user now with pipewire but
couldn't find anything conclusive online).

I enabled it by modifying the example configuration and setting the
following in /etc/pipewire/pipewire-pulse.conf:

pulse.properties = {
# the addresses this server listens on
server.address = [
"unix:native"
"tcp:127.0.0.1:4713"   # IPv4 on a single address
]
# [more default config]
}

The problem is that when the "pipewire-pulse" service starts as part of
the session of the interactive user, it can't bind to this port. The
following is displayed in the logs for the service:

mai 29 11:43:55 baraddur systemd[2281]: Started pipewire-pulse.service - 
PipeWire PulseAudio.
mai 29 11:43:55 baraddur pipewire-pulse[2320]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
mai 29 11:43:55 baraddur pipewire-pulse[2320]: mod.rt: found session bus but no 
portal
mai 29 11:43:55 baraddur pipewire-pulse[2320]: mod.protocol-pulse: server 
0x5580e6aa9160: bind() failed: Adresse déjà utilisée
mai 29 11:43:55 baraddur pipewire-pulse[2320]: mod.protocol-pulse: pulse-server 
0x5580e6aa8ab0: failed to start server on 'tcp:127.0.0.1:4713': Adresse déjà 
util>

("Adresse déjà utilisée" is French for "address already in use").

Manually restarting the service with "systemctl --user restart
pipewire-pulse.service" fixes the issue and the service starts without
any warnings or errors.

I strongly suspect that this is due to a race condition with the
pipewire-pulse server of the gdm display manager. Indeed, if right after
starting the computer computer I open a shell on a different tty instead
of my graphical GNOME session and run "lsof -n -i :4713", I see that
"pipewire-pulse" is already listening on that port for user
"Debian-gdm". Presumably, it is still running while the user service
starts, preventing it from binding to the port.

Would there be any way to fix that?

Best regards,
Micha

-- 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=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 pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.65-3

Versions of packages pipewire-pulse recommends:
ii  wireplumber  0.4.13-1

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.65-3
ii  pulseaudio-utils  16.1+dfsg1-2+b1

-- no debconf information

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

[Paul Gevers]

Hi,

On 29-05-2023 12:51, Max Nikulin wrote:
I am unaware of another dash implementation. Do you mean ash from which 
dash was forked?


No, I understood from Andrej that dash *internally* has two ways to do 
the matching. One embedded implementation, and one using system library 
calls. Which one is used depends on the configure options during the 
build. Both code paths are now made consistent (with the way dash 
maintainers always ment it to be).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Max Nikulin]

On 29/05/2023 17:30, Paul Gevers wrote:

On 29-05-2023 12:02, Max Nikulin wrote:

Strictly speaking, behavior of circumflex is *unspecified* in POSIX:


... A bracket expression
    starting with an unquoted  character produces 
unspecified

    results.


Right. Maybe better to say it now matches the other implementation (dash 
has two implementations and they were behaving differently).


I am unaware of another dash implementation. Do you mean ash from which 
dash was forked? I have checked 
https://en.wikipedia.org/wiki/Debian_Almquist_shell and noticed that 
busybox ash implementation was derived from dash, but the similar issue 
is still open in their tracker.


I would recommend users to check scripts by the "shellcheck" static 
analyzer, but I am unsure if such suggestion is suitable for release 
notes or for Debian news in the dash package.

https://www.shellcheck.net/wiki/SC3026

Bug#1036907: release-notes: dash in bookworm drops debconf selector for /bin/sh

[Paul Gevers]

Hi Andrej,

On 29-05-2023 11:22, Andrej Shadura wrote:

I wasn’t 100% sure, but I have now verified and yes, dash reclaims /bin/sh on 
upgrades.


Ack (and a bit of ugh).


I could have handled that smarter and given users one release to adjust, but I 
guess it’s probably a bit late for that?


Absolutely.

How was this technically done in the past, diversions, 
update-alternatives, something else?


Paul


OpenPGP_signature
Description: OpenPGP digital signature

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

[Paul Gevers]

Hi,

On 29-05-2023 12:02, Max Nikulin wrote:

Strictly speaking, behavior of circumflex is *unspecified* in POSIX:


... A bracket expression
    starting with an unquoted  character produces unspecified
    results.


Right. Maybe better to say it now matches the other implementation (dash 
has two implementations and they were behaving differently).


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036910: cyrus-sasl2: [INTL:tr] turkish translation of debconf messages

[Bastian Germann]

Am 29.05.23 um 12:07 schrieb Atila KOÇ:

Find attached the Turkish translation of the cyrus-sasl2 debconf messages=


Do you also allow distribution under BSD-2-clause? This is my condition for 
including it.
I try to keep the debian files under standard licenses that are compatible with 
GPL.

Bug#1036911: libpsm_infinipath alternative is incompatible with Multi-Arch

[Helmut Grohne]

Package: libpsm2-2-compat,libpsm-infinipath1
Severity: important
X-Debbugs-Cc: gla...@debian.org, emoll...@debian.org, 
debian-cr...@lists.debian.org

Hi Roland et al,

in Hamburg, I've been looking to cross building some openmpi-dependent
packages with Étienne Mollier. We ended up figuring that the psm
packages probably need to support Multi-Arch on the shared-library level
in order to support cross building higher up in the stack as openmpi
ends up depending on both and this is where it gets non-trivial.

So in effect, we are looking into what it would take to make these
packages Multi-Arch: same. And while that has some minor problems on
various levels, there is a bigger one sticking out and that's their use
of update-alternatives. While the actual library as is used by
downstream packages is
/usr/lib/@DEB_HOST_MULTIARCH@/libpsm_infinipath.so.@PSM_LIB_MAJOR@ and
thus is fine from a multi-arch point of view, the name of the
alternative being libpsm_infinipath.so.@PSM_LIB_MAJOR@ presents a
problem. If we were to co-install two instances of a libpsm_infinipath
implementation, those would clash on their alternative name. This is not
a new problem and it has need been solved e.g. by blas and lapack by
appending the multiarch tuple to the alternative name. In effect, doing
what they did to these packages is a prerequisite to making them
Multi-Arch: same (regardless of all the other details). Related to that
the alternative values also do not reside in multiarch locations.
They're relatively easy to move as their only consumer is the
alternative, but the alternative is a public interface used by users and
we break it both by renamining it and by moving its providers. This is
bad.

The simplest way to fix this would be waiting for an soname bump (which
breaks users anyway) and taking that as an opportunity to apply
multiarch. We fear that a soname bump is not about to be happening. So
we probably have to break it anyway as openmpi is quite of an important
piece of software. It's not clear how to migrate that properly. If the
expected number of users installing both implementations is low, we can
just break it (remove the old alternative and add a new one loosing the
user configuration state) and inform the user via NEWS.Debian. Is that
an acceptable procedure? When doing that, we probably have change both
implementations to remove all alternative providers in order to create
the new one. This will work, because update-alternatives is happy about
--remove'ing a non-existent alternative.

Do you agree with this plan? If yes, Helmut can look into writing a patch.

Helmut and Étienne from Hamburg

Bug#1032995: spyder: Spyder on startup says there is a missing dependency (pylsp_black) but it is correctly installed

[Julian Gilbey]

On Thu, May 25, 2023 at 08:03:19PM +0100, Julian Gilbey wrote:
> On Thu, May 25, 2023 at 09:25:50AM -0700, Brian Vaughan wrote:
> > # Spyder, Help > Dependencies
> > [...]
> > pylsp >=1.7.1;<1.8.0  :  1.7.1 (OK)
> > pylsp_black >=1.2.0   :  None (NOK)
> 
> Hi Brian,
> 
> Thanks for sending all this through.  This is so weird.
> [...]
> All looks normal here.
> 
> I am utterly mystified why spyder is not finding pylsp_black.  I'll
> have a think about it and get back to you.

If you're able to do the following tests, it might help shed some
light on what's going wrong.  The attached is a patch for the file
/usr/lib/python3/dist-packages/spyder/dependencies.py
to give more debugging output.  Please apply the patch; you can do
this by saving the patch to a file, say /tmp/dependencies.py.diff,
then running the commands:

cd /usr/lib/python3/dist-packages/spyder/dependencies.py
patch --backup < /tmp/dependencies.py.diff

where the "--backup" option saves a copy of the original
dependencies.py file as dependencies.py.orig.

Once this patch is applied, start spyder from a terminal using the
command:

spyder --debug-info verbose

and let it run at least until it gives the warning message about
pylsp_black not being found, then quit spyder.  There will be lots of
messages written to the terminal, but they will also be saved in the
file .config/spyder-py3/spyder-debug.log

Have a look through this file for "pylsp_black".  Here's what I see:

2023-05-29 11:00:24,689 [DEBUG] [spyder.dependencies] -> 
Dependency(pylsp_black, python_lsp_black) starting
2023-05-29 11:00:24,931 [DEBUG] [spyder.dependencies] -> Dependency: 
get_module_version returned None for pylsp_black
2023-05-29 11:00:24,932 [DEBUG] [spyder.dependencies] -> Dependency: 
get_package_version returned 1.2.1 for pylsp_black

I'm guessing you'll get something quite different, probably with some
further debugging output following it (perhaps "Dependency: exception
raised..." followed by "Dependency: when exception raised...").  If
you're able to do this experiment, please could you send me these
lines of the log file.  (I don't imagine that I would need any more of
the log file at this point.)

I do hope this will help to find the source of the problem!

Best wishes,

   Julian
--- dependencies.py.orig	2023-02-23 10:59:49.0 +
+++ dependencies.py	2023-05-29 10:59:40.056580272 +0100
@@ -10,6 +10,7 @@
 import os
 import os.path as osp
 import sys
+import logging
 
 # Local imports
 from spyder.config.base import _, is_pynsist, running_in_ci, running_in_mac_app
@@ -17,6 +18,8 @@
 
 HERE = osp.dirname(osp.abspath(__file__))
 
+logger = logging.getLogger(__name__)
+
 # =
 # Kind of dependency
 # =
@@ -319,21 +322,37 @@
 # * Package name: python-lsp-black.
 # * Distribution name: python_lsp_black
 self.distribution_name = self.package_name.replace('-', '_')
-
+logger.debug(
+"Dependency(%s, %s) starting", modname, self.distribution_name
+)
+
 if installed_version is None:
 try:
 self.installed_version = programs.get_module_version(modname)
+logger.debug(
+"Dependency: get_module_version returned %s for %s",
+self.installed_version, modname
+)
 if not self.installed_version:
 # Use get_package_version and the distribution name
 # because there are cases for which the version can't
 # be obtained from the module (e.g. pylsp_black).
 self.installed_version = programs.get_package_version(
 self.distribution_name)
-except Exception:
+logger.debug(
+"Dependency: get_package_version returned %s for %s",
+self.installed_version, modname
+)
+except Exception as exc:
 # NOTE: Don't add any exception type here!
 # Modules can fail to import in several ways besides
 # ImportError
 self.installed_version = None
+logger.debug("Dependency: exception raised: %s", exc)
+logger.debug(
+"Dependency: when exception raised: sys.path = %s",
+sys.path
+)
 else:
 self.installed_version = installed_version
 

Bug#1036910: cyrus-sasl2: [INTL:tr] turkish translation of debconf messages

[Atila KOÇ]

Package: cyrus-sasl2
Version: N/A
Severity: wishlist
Tags: l10n patch

Hello,

Find attached the Turkish translation of the cyrus-sasl2 debconf messages.
It has been submitted for review to the debian-l10n-turkish mailing list.

Regards,
Atila KOÇ
--- YASAL UYARI ---

# Turkish debconf translation of cyrus-sasl2
# This file is distributed under the same license as the cyrus-sasl2 package.
# Atila KOÇ , 2023.
#
msgid ""
msgstr ""
"Project-Id-Version: cyrus-sasl2\n"
"Report-Msgid-Bugs-To: pkg-cyrus-sasl2-debian-de...@lists.alioth.debian.org\n"
"POT-Creation-Date: 2007-10-02 07:23+0200\n"
"PO-Revision-Date: 2023-03-26 22:47+0300\n"
"Last-Translator: Atila KOÇ \n"
"Language-Team: Debian L10n Turkish \n"
"Language: tr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"
"X-Generator: Poedit 2.4.2\n"

#. Type: boolean
#. Description
#: ../sasl2-bin.templates:2001
msgid "Remove /etc/sasldb2?"
msgstr "/etc/sasldb2 kaldırılsın mı?"

#. Type: boolean
#. Description
#: ../sasl2-bin.templates:2001
msgid ""
"Cyrus SASL can store usernames and passwords in the /etc/sasldb2 database "
"file."
msgstr ""
"Cyrus SASL kullanıcı adlarını ve parolalarını /etc/sasldb2 veritabanı "
"dosyasında saklayabilir."

#. Type: boolean
#. Description
#: ../sasl2-bin.templates:2001
msgid ""
"If important data is stored in that file, you should back it up now or "
"choose not to remove the file."
msgstr ""
"Eğer o dosyada önemli veriler saklanıyorsa, onu şimdi yedeklemelisiniz veya "
"kaldırmamayı seçmelisiniz."

#. Type: string
#. Description
#: ../sasl2-bin.templates:3001
msgid "Backup file name for /etc/sasldb2:"
msgstr "/etc/sasldb2 için yedek dosyası adı:"

#. Type: string
#. Description
#: ../sasl2-bin.templates:3001
msgid ""
"Cyrus SASL has stored usernames and passwords in the /etc/sasldb2 database "
"file."
msgstr ""
"/etc/sasldb2 veritabanı dosyasında, Cyrus SASL tarafından saklanmış "
"kullanıcı adları ve parolalar var."

#. Type: string
#. Description
#: ../sasl2-bin.templates:3001
msgid ""
"That file has to be upgraded to a newer database format. First, a backup of "
"the current file will be created. You can use that if you need to manually "
"downgrade Cyrus SASL. However, automatic downgrades are not supported."
msgstr ""
"Bu dosya yeni bir veritabanı biçimine yükseltilmek zorunda. Önce, varolan "
"dosyanın bir yedeği alınacak. Otomatik düşürmeler desteklenmediği halde, "
"eğer Cyrus SASL'yi önceki sürümüne elle düşürmeniz gerekirse bu dosyayı "
"kullanabilirsiniz."

#. Type: string
#. Description
#: ../sasl2-bin.templates:3001
msgid ""
"Please specify the backup file name. You should check the available disk "
"space in that location. If the backup file already exists, it will be "
"overwritten. Leaving this field empty will select the default value (/var/"
"backups/sasldb2.bak)."
msgstr ""
"Yedek dosya adını belirtin. Eğer orada eskisi varsa, yenisi onun üzerine "
"yazılacaktır. Dosyanın saklanacağı yerdeki kullanılabilir disk alanını "
"denetleyin. Bu alanı boş bırakırsanız, veritabanı yedeği /var/backups/"
"sasldb2.bak dosyasına alınacaktır."

#. Type: error
#. Description
#: ../sasl2-bin.templates:4001
msgid "Failed to back up /etc/sasldb2"
msgstr "/etc/sasldb2 yedeklemesi başarısız oldu"

#. Type: error
#. Description
#: ../sasl2-bin.templates:4001
msgid ""
"The /etc/sasldb2 file could not be backed up with the file name you "
"specified."
msgstr "/etc/sasldb2 dosyası belirttiğiniz dosya adı ile yedeklenemedi."

#. Type: error
#. Description
#: ../sasl2-bin.templates:4001 ../sasl2-bin.templates:5001
msgid "This is a fatal error and will cause the package installation to fail."
msgstr ""
"Bu ölümcül bir hata olup, paket kurulumunun başarısız olmasına neden "
"olacaktır."

#. Type: error
#. Description
#: ../sasl2-bin.templates:4001
msgid ""
"Please eliminate all possible reasons that might lead to this failure, and "
"try to configure this package again."
msgstr ""
"Bu başarısızlığa neden olabilecek tüm olası sebepleri eleyin ve bu paketi "
"yeniden yapılandırmayı deneyin."

#. Type: error
#. Description
#: ../sasl2-bin.templates:5001
msgid "Failed to upgrade /etc/sasldb2"
msgstr "/etc/sasldb2 yükseltmesi başarısız oldu"

#. Type: error
#. Description
#: ../sasl2-bin.templates:5001
msgid "The /etc/sasldb2 file could not be upgraded to the new database format."
msgstr "/etc/sasldb2 dosyası yeni veritabanı biçimine yükseltilemedi."

#. Type: error
#. Description
#: ../sasl2-bin.templates:5001
msgid ""
"The configuration process will attempt to restore the backup of this file to "
"its original location."
msgstr ""
"Yapılandırma süreci bu dosyanın yedeğini asıl konumuna geri yükleme "
"girişiminde bulunacak."

#. Type: error
#. Description
#: ../sasl2-bin.templates:5001
msgid ""
"Please eliminate all possible reasons that might lead to this failure, then "
"try to configure this package again."
msgstr ""
"Bu başarısızlığa 

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

[Max Nikulin]

On 29/05/2023 02:53, Paul Gevers wrote:

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


from the diff:

... as a literal
character, as was always the intended POSIX-compliant
behavior.


Strictly speaking, behavior of circumflex is *unspecified* in POSIX:


... A bracket expression
starting with an unquoted  character produces unspecified
results.


Moreover, it is intentionally left unspecified:
https://www.austingroupbugs.net/view.php?id=1558

Bug#932957: Please migrate Release Notes to reStructuredText

[Holger Wansing]

Hi,

James Addison  wrote (Mon, 29 May 2023 00:18:36 +0100):
> [[Holger Wansing wrote:]]
> > 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

I have implemented such things now in
https://salsa.debian.org/holgerw/release-notes/-/commit/0304c87400432e1905d1bb04d39468a632876978
as a first step for arch-depending filtering.

Works so far, if the wanted arch is set in the Makefile (line 175) via the -t 
option.

Thanks for your help on this!

Now we just need an infrastructure, to loop over all architectures for build 
targets...


Holger



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

Bug#1036909: unblock: sofia-sip/1.12.11+20110422.1+1e14eea~dfsg-6

[Evangelos Ribeiro Tzaras]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package sofia-sip

I was made aware of another CVE in sofia-sips STUN handling
and have made an upload (debdiff attached) to sid.

Thanks in advance.

PS: I was told I can do it until 12:00 CEST :))


unblock sofia-sip/1.12.11+20110422.1+1e14eea~dfsg-6


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEuThlVLfdJmvLjimpkPDJsYprShkFAmR0dcMACgkQkPDJsYpr
ShmYKw/9Eyjl90pBOM3PRe15EzUhfL1L047bN73goqIuYgfqXOzSBSg/7agi07ux
JmefVPpilU/tTjtA6We+E7uU26ik41WpNeydgznY495Y1ijy0FZXAazJ8iThVNqL
BQWmY0jUITgUhYnpRke+mfQjvhIIibWN22k33aHb37u+WVsao/LYLJw90SseC3zp
mGd1oiFzP8WDMhUpH8RgDaecI8Uw2nygXKVQxGhXFOnXIgSffQvfLVgS95C2h1SF
9nNIUoKeQgcyw9cqwK+xAlQHFGnS72x+oF3sX289hQcXgPdeyxnLGdukUvCBxWgH
GlQ+etTXHzaNeNScCfMJArrSSk2fIxdkR+NcGbGS7nDbKC8ztpYOEeOpM5vR23WK
0gqLeb+VOApwZpE0HdNbXvSHrF1xOs8EyqsTl51lTfRIO++kf3S99Se7tdP1+PQL
8IpQXZQxeL9hcz8EXZMyNZIvVDLcJ8068W6IajD71rapGWSVW+VlPGbCDOpOpJLl
GQiK8+6QQhHmaWOyjzQxxKrjLdsac3JZQn25dinrRIIyBdzrvolPiaoTxFHeBYlQ
YguSjrUf38NOeZj0psL8sQPR+HPG3esGZltN5gqnChIm8k0qYDdPD0Bvmm67mH1J
+L+j3hM8uD84sY0HXRbSlaQBv65e48YtgPJNllzAKW43TWoC7io=
=Lb2h
-END PGP SIGNATURE-
diff -Nru sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/changelog 
sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/changelog
--- sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/changelog  2023-05-23 
05:53:48.0 +0200
+++ sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/changelog  2023-05-29 
11:36:38.0 +0200
@@ -1,3 +1,13 @@
+sofia-sip (1.12.11+20110422.1+1e14eea~dfsg-6) unstable; urgency=medium
+
+  * Add patch to fix reported CVE-2023-32307.
+For further information see:
+- CVE-2023-32307[0]
+[0] https://security-tracker.debian.org/tracker/CVE-2023-32307
+   https://www.cve.org/CVERecord?id=CVE-2023-32307 (closes: bug#1036847)
+
+ -- Evangelos Ribeiro Tzaras   Mon, 29 May 
2023 11:36:38 +0200
+
 sofia-sip (1.12.11+20110422.1+1e14eea~dfsg-5) unstable; urgency=medium
 
   * Add patch to fix reported CVE; add copyright of patch.
diff -Nru 
sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/0008-stun-add-checks-for-attribute-length-before-read-fro.patch
 
sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/0008-stun-add-checks-for-attribute-length-before-read-fro.patch
--- 
sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/0008-stun-add-checks-for-attribute-length-before-read-fro.patch
1970-01-01 01:00:00.0 +0100
+++ 
sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/0008-stun-add-checks-for-attribute-length-before-read-fro.patch
2023-05-29 11:31:03.0 +0200
@@ -0,0 +1,36 @@
+From: Xu Biang 
+Date: Sat, 6 May 2023 05:51:55 +0800
+Subject: stun: add checks for attribute length before read from it
+
+(cherry picked from commit c3bbc50c88d168065de34ca01b9b1d98c1b0e810)
+---
+ libsofia-sip-ua/stun/stun_common.c | 9 +
+ 1 file changed, 9 insertions(+)
+
+diff --git a/libsofia-sip-ua/stun/stun_common.c 
b/libsofia-sip-ua/stun/stun_common.c
+index 93b53ec..5540d16 100644
+--- a/libsofia-sip-ua/stun/stun_common.c
 b/libsofia-sip-ua/stun/stun_common.c
+@@ -250,6 +250,10 @@ int stun_parse_attr_error_code(stun_attr_t *attr, const 
unsigned char *p, unsign
+   uint32_t tmp;
+   stun_attr_errorcode_t *error;
+ 
++  if (len < 4) {
++return -1;
++  }
++
+   memcpy(, p, sizeof(uint32_t));
+   tmp = ntohl(tmp);
+   error = (stun_attr_errorcode_t *) malloc(sizeof(*error));
+@@ -271,6 +275,11 @@ int stun_parse_attr_uint32(stun_attr_t *attr, const 
unsigned char *p, unsigned l
+ {
+   uint32_t tmp;
+   stun_attr_changerequest_t *cr;
++
++  if (len < 4) {
++return -1;
++  }
++
+   cr = (stun_attr_changerequest_t *) malloc(sizeof(*cr));
+   memcpy(, p, sizeof(uint32_t));
+   cr->value = ntohl(tmp);
diff -Nru sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/series 
sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/series
--- sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/series 
2023-05-23 05:53:48.0 +0200
+++ sofia-sip-1.12.11+20110422.1+1e14eea~dfsg/debian/patches/series 
2023-05-29 11:31:03.0 +0200
@@ -5,3 +5,4 @@
 0003-cve-fix-heap-overflow-by-two.patch
 0004-cve-check-stun-message-and-attr-len.patch
 0005-cve-dos-wrong-assert.patch
+0008-stun-add-checks-for-attribute-length-before-read-fro.patch

Bug#1036907: release-notes: dash in bookworm drops debconf selector for /bin/sh

[Andrej Shadura]

Hi,

On Mon, 29 May 2023, at 11:09, Paul Gevers wrote:
> On 29-05-2023 11:02, Andrej Shadura wrote:
>> I think the release notes should probably mention that dash
>> 0.5.11+git20210903+057cd650a4ed-4 has dropped all debconf code to allow
>> using a different shell as /bin/sh.
>
> Does this only effects new installations, or is this relevant for 
> upgrades too?

I wasn’t 100% sure, but I have now verified and yes, dash reclaims /bin/sh on 
upgrades.
I could have handled that smarter and given users one release to adjust, but I 
guess it’s probably a bit late for that?

-- 
Cheers,
  Andrej

Bug#1036907: release-notes: dash in bookworm drops debconf selector for /bin/sh

[Paul Gevers]

HI,

On 29-05-2023 11:42, Justin B Rye wrote:

Either way, we'll need to amend that release-notes entry for
^-handling, and presumably we'll want a new entry about this to go
along with that one.


That was exactly my idea too.

Paul


OpenPGP_signature
Description: OpenPGP digital signature