Bug#1021338: azure-cli: az webapp commands failing: API version 2022-03-01 does not have operation group 'web_apps'

[David.K]

Package: azure-cli
Version: 2.40.0-1
Severity: normal

Dear Maintainer,

az webapp commands are failing with the following stack trace:

$ az webapp list
The command failed with an unexpected error. Here is the traceback:
API version 2022-03-01 does not have operation group 'web_apps'
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in invoke
cmd_result = self.invocation.execute(args)
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 663, in execute
raise ex
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 726, in _run_jobs_serially
results.append(self._run_job(expanded_arg, cmd_copy))
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 697, in _run_job
result = cmd_copy(params)
  File "/usr/lib/python3/dist-packages/azure/cli/core/commands/__init__.py", 
line 333, in __call__
return self.handler(*args, **kwargs)
  File 
"/usr/lib/python3/dist-packages/azure/cli/core/commands/command_operation.py", 
line 121, in handler
return op(**command_args)
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/appservice/custom.py",
 line 967, in list_webapp
full_list = _list_app(cmd.cli_ctx, resource_group_name)
  File 
"/usr/lib/python3/dist-packages/azure/cli/command_modules/appservice/custom.py",
 line 1006, in _list_app
result = list(client.web_apps.list())
  File 
"/usr/lib/python3/dist-packages/azure/mgmt/web/_web_site_management_client.py", 
line 804, in web_apps
raise ValueError("API version {} does not have operation group 
'web_apps'".format(api_version))
ValueError: API version 2022-03-01 does not have operation group 'web_apps'


According to this issue raised in the github project page, doing an install 
with the
non-Debian installer fixes the issue.  Which seems to indicate that this 
package is in
need of an update.

https://github.com/Azure/azure-cli/issues/23848




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

Versions of packages azure-cli depends on:
ii  python33.10.6-1
ii  python3-azure-cli  2.40.0-1

Bug#1021337: linux-image-5.19.0-2-amd64: Please enable building of the idxd module for the IntelData Accelerator support

[Gunnar Wolf]

Package: linux-image-5.19.0-2-amd64
Severity: normal
X-Debbugs-Cc: jair.de.jesus.gonzalez.plascen...@intel.com, 
miguel.bernal.ma...@intel.com

Hello,

I was recently approached by Intel engineers Jair de Jesús Gonzalez
Plascencia and Miguel Bernal Marín, both Cc:ed here. They asked me for
help to get the needed components for Intel Data Accelerator in
Debian.

A necessary first step towards achieving this is having the needed
module built as part of our kernels; this driver has been part of
Linux since 5.6. This report is to request you to add the module in
Debian. Quoting from their mail to me:

Specifically, the required configuration options to enable all of its
features are:

   CONFIG_INTEL_IDXD=m
   # Intel Data Accelerators support
   # found in Linux kernels: 5.6–5.19, 6.0-rc+HEAD

   CONFIG_INTEL_IDXD_SVM=y
   # Accelerator Shared Virtual Memory Support
   # found in Linux kernels: 5.11–5.19, 6.0-rc+HEAD

   Other required configuration options that are already present in the
   Debian Bullseye and Debian Bookworm kernels are:

   CONFIG_INTEL_IOMMU=y
   CONFIG_INTEL_IOMMU_SVM=y
   CONFIG_IRQ_REMAP=y
   CONFIG_PCI_ATS=y
   CONFIG_PCI_PRI=y
   CONFIG_PCI_PASID=y
   CONFIG_DMA_ENGINE=y

- What does it enable? / What is the use case?

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at

https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification):

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at

https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification
 ):

Intel DSA is a high-performance data copy and transformation
accelerator that will be integrated in future Intel® processors,
targeted for optimizing streaming data movement and transformation
operations common with applications for high-performance storage,
networking, persistent memory, and various data processing
applications.

Intel DSA replaces Intel® QuickData Technology, which is a part of
Intel® I/O Acceleration Technology.

This request comes as a requisite for the packaging of the userspace
components of this functionality (WNPP bug is to be fixed once I got a
bug number assigned for this report).

This functionality is available starting at Intel's fourth generation
of Scalable Xeon server processors, code-named Sapphire
Rapids. Currently some SPR products are planned to be launched on 2022
calendar week 42 and 2022 calendar week 45. High volume SPR processors
have a planned launch window on 2023 calendar week 6 to 9 (Feb. 6,
2023 to March 3, 2023).

Thank you very much!


   - Gunnar
 (but really, this should be signed by Miguel and Jair ;-) )

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

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

-- 



signature.asc
Description: PGP signature

Bug#1021336: Acknowledgement (libpam-modules-bin: trying to overwrite '/usr/share/man/man5/namespace.conf.5.gz')

[Christian Marillat]

On 06 oct. 2022 05:42, "Debian Bug Tracking System"  
wrote:

I see more errors :

trying to overwrite '/usr/share/man/man8/pam_namespace_helper.8.gz', which is 
also in package libpam-modules:powerpc 1.5.2-2

trying to overwrite '/usr/share/man/man5/namespace.conf.5.gz', which is also in 
package libpam-modules-bin 1.5.2-3

Christian

Bug#1021336: libpam-modules-bin: trying to overwrite '/usr/share/man/man5/namespace.conf.5.gz'

[Christian Marillat]

Package: libpam-modules-bin
Version: 1.5.2-2
Severity: important

Dear Maintainer,

After an apt-get dist-upgrade


Unpacking libpam-modules-bin (1.5.2-3) over (1.5.2-2) ...
dpkg: error processing archive 
/var/cache/apt/archives/libpam-modules-bin_1.5.2-3_powerpc.deb (--unpack):
 trying to overwrite '/usr/share/man/man5/namespace.conf.5.gz', which is also 
in package libpam-modules:powerpc 1.5.2-2
Errors were encountered while processing:
 /var/cache/apt/archives/libpam-modules-bin_1.5.2-3_powerpc.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)





Christian

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc64)

Kernel: Linux 5.19.0-2-powerpc64 (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpam-modules-bin depends on:
ii  libaudit11:3.0.7-1.1
ii  libc62.35-2
ii  libcrypt11:4.4.28-2
ii  libpam0g 1.5.2-3
ii  libselinux1  3.4-1+b2

libpam-modules-bin recommends no packages.

libpam-modules-bin suggests no packages.

-- no debconf information

Bug#1021335: cloudcompare: GNOME applications issue a warning: "Desktop file '...' should not include extension in Icon key

[Dima Kogan]

Package: cloudcompare
Version: 2.11.3-6
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. This happens when I run unrelated applications. For instance, when
running geeqie, I see this on the console:

  Desktop file '/usr/share/applications/cloudcompare.desktop' should not 
include extension in Icon key: 'cloudcompare.png'
  Desktop file '/usr/share/applications/ccViewer.desktop' should not include 
extension in Icon key: 'ccViewer.png'

Removing the ".png" in the mentioned files makes the warning not happen.
Presumably removing the ".png" is correct? Can you please take a look?

Thanks



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cloudcompare depends on:
ii  libavcodec597:5.1-3
ii  libavformat59   7:5.1-3
ii  libavutil57 7:5.1-3
ii  libc6   2.34-7
ii  libgcc-s1   12.2.0-1
ii  libgl1  1.5.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1
ii  libgomp112.2.0-1
ii  libqt5concurrent5   5.15.4+dfsg-5
ii  libqt5core5a5.15.4+dfsg-5
ii  libqt5gui5  5.15.4+dfsg-5
ii  libqt5opengl5   5.15.4+dfsg-5
ii  libqt5printsupport5 5.15.4+dfsg-5
ii  libqt5widgets5  5.15.4+dfsg-5
ii  libstdc++6  12.2.0-1
ii  libswscale6 7:5.1-3
ii  zlib1g  1:1.2.11.dfsg-4.1

cloudcompare recommends no packages.

cloudcompare suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/applications/ccViewer.desktop (from 
cloudcompare package)
debsums: changed file /usr/share/applications/cloudcompare.desktop (from 
cloudcompare package)

Bug#1021334: Provide the database as XML

[julien . puydt]

Package: unicode-data
Severity: wishlist

I would like to package a software (ocaml-uunf) whose compilation looks
like:
(1) download Unicode character database (big XML file) ;
(2) convert it to some format ;
(3) compile.

and I would like to use unicode-data to drop the problematic step (1).

Can you provide the data also in XML format?

Thanks,

J.Puydt

Bug#1021333: RFP: node-is-ci -- Detect if the current environment is a CI server (Evacuated from NSA/Microsoft Github)

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name:   node-is-ci
  Upstream Author :   Thomas Watson Steen
* URL : https://git.freecumextremist.com/themusicgod1/is-ci
* License : MIT
  Programming Lang: javascript
  Description : Returns true if the current environment is a
Continuous Integration server.

Officially supported CI servers:
Travis CI
CircleCI
Jenkins CI
Hudson
Bamboo
TeamCity
Team Foundation Server
GitLab CI
Codeship
Drone.io
Magnum CI
Semaphore
AppVeyor
Buildkite
TaskCluster
GoCD
Bitbucket Pipelines

node-ci is a prerequisite for node-husky ( #910393 )

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 05/10/2022 22:06, Michael Biebl wrote:
I think if you want to assemble a root/usr fs where you don't want do 
"disturb" the host system, I'd use a debootstrapped chroot but not the 
host fs.


I think the original reason for fakemachine to exist was to build OS 
images from within containers. At first it doesn't sound like a great 
idea, because usually there's not enough capabilities in the container 
for that (ie. no access to the loop device). But systems like Jenkins or 
GitLab CI drop you in a container, you have no choice. So fakemachine 
came as a solution / workaround to spawn a VM from within a container 
(according that you have access to /dev/kvm), and then from within the 
VM you can build an OS image.


Hence this weird approach of "faking a machine", ie. creating a VM by 
reusing bits from the host filesystem. To say it again: if you're 
already within an environment that has been setup for the job (chroot or 
container), no need to debootstrap a chroot again, let's just make sure 
this environment has everything needed, and re-use it for the VM. That's 
the approach of fakemachine, as I understand it.


And so, for this use-case when fakemachine is used from within a 
chroot/container, I must say that the systemd-resolved split is not 
really problematic: all it takes is to add systemd-resolved to the list 
of packages to install in the chroot/container.


The issue is for people installing fakemachine on their own machine. So 
far it worked great (I've been using it a lot to build OS images). Now 
it doesn't anymore. So either I install systemd-resolved, either I start 
a chroot and run fakemachine from there. It doesn't work "out of the 
box" anymore, if you want.



Say you want to install apache2 in your fakemachine managed VM, this 
would also start it on the host system, or not?


Yes, but this comparison is not really relevant here. systemd-resolved 
is needed for the VM to have a functional network, so it's really a 
prerequisite for a functional VM, regardless of what users want to do 
with it. Hence the question of whether it should become a Depends for 
the fakemachine package.


While apache2 will never be a Depend of fakemachine in any case, and if 
users have a need for a particular need for that, it's in their hand to 
decide how to do it.


Maybe fakemachine is more or less a VM counterpart of "systemd-nspawn -D 
/ -xb" (systemd-nspawn(1), example 6)?


I hope that I clarified a few points here. Would be nice to hear more 
from fakemachine maintainers.


Best regards,

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1008296: Workaround for my machine

[Sebastián Lacuesta]

Now added nvidia_drm.modeset=1 as a kernel parameter and doing cat
/sys/module/nvidia_drm/parameters/modeset gives me: Y
Still need to have the `ln -s /dev/null /etc/udev/rules.d/61-gdm.rules`
hack in order to have Wayland properly. I do have the kms-modifiers
activated too.
Versions of libxcb, egl-wayland are 1.15 and 1.1.10 respectively.

Issue starts by not having wayland options in gdm and in turn, my gnome
session later.

El lun, 19 sept 2022 a las 14:27, Alban Browaeys ()
escribió:

> About modeset, ie Kernel Mode Setting being required or not I found
> this about https://wiki.archlinux.org/title/Wayland#Requirements 5.1
> that "Enabling DRM KMS is required.". THe next link points to
>
> https://download.nvidia.com/XFree86/Linux-x86_64/515.48.07/README/xwayland.html
> which tells that:
> "
> Requirements
>
> The following are necessary to enable accelerated rendering on Xwayland
> with the NVIDIA driver:
>
>- DRM KMS must be enabled. See Chapter 36, Direct Rendering Manager
> Kernel Modesetting (DRM KMS) for details.
>
>- The installed copy of Xwayland should be a build from the master
> branch of https://gitlab.freedesktop.org/xorg/xserver at least as
> recent as commit c468d34c. Note that if this requirement is not
> satisfied, the NVIDIA GPU can still be used for rendering, however it
> will fall back to a suboptimal path for presentation resulting in
> degraded performance.
>
>- libxcb version 1.13 or later must be present.
>
>- egl-wayland version 1.1.7 or later must be present (if installed
> separately from the the NVIDIA driver).
>
>- If using the GNOME desktop environment, kms-modifiers must be
> enabled through gsettings. This can be done with the following command
> gsettings set org.gnome.mutter experimental-features [\"kms-
> modifiers\"]
>
> "
>
> So currently, once logged in gnome wayland without modeset enabled, you
> should not have Xwayland application (most games) running hardware
> accelerated.
> To not end up on software acceleration you have to enable KMS (by the
> settings I sent you previously) and also setting an experimental
> feature in the gnome session:
> gsettings set org.gnome.mutter experimental-features [\"kms-modifiers\"]
>
> maybe you can check if you are on software acceleration on Xwayland
> with glxgears/glxinfo . Maybe you can send your glxinfo output without
> nvidia modeset set and logged in a wayland session?
>
>
> Kind regards,
>
> Alban
>

Bug#1021304: bugs.debian.org: "There is no record of Bug #..."

[Don Armstrong]

Control: retitle -1 delay in mirroring new bugs from buxtehude to bembo
Control: severity -1 minor


On Wed, 05 Oct 2022, Piotr Engelking wrote:
> Please only send acknowledgement mail and display the bug in
> pkgreport.cgi after the bug is visible in bugreport.cgi.

That's happening because there is a mirror and it takes some time for
totally new bugs to be picked up by the mirror script and transferred;
that particular part uses polling.

Existing bugs transfer relatively quickly as they use inotify.

There's some optimization here to speed up poling for new bugs (or maybe
automatically triggering new bugs into the mirror script), but it's
"working as designed".

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

If you wish to strive for peace of soul, then believe; if you wish to
be a devotee of truth, then inquire.
 -- Friedrich Nietzsche

Bug#1021332: RFP: libjs-jquery-terminal -- A library for creating command line interpreters in your applications.

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name:   libjs-jquery-terminal
  Upstream Author :  Jakub Jankiewicz 
* URL :
https://git.freecumextremist.com/themusicgod1/jquery-terminal
* License : GPLv3+MIT+3-BSD+WTFPL
  Programming Lang: javascript
  Description : You can use this JavaScript Terminal library to create
interactive web-based terminal application on your website. Where
commands are defined by you. You can define them on the server or in
browser's JavaScript.

This is a vendored prerequisite to ethereum-harmony #926370

Bug#1021331: cclive: reproducible-builds: build path embedded in /usr/bin/cclive

[Vagrant Cascadian]

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

The build path is embedded in /usr/bin/cclive:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cclive.html

  
g++,·-g·-O2·-ffile-prefix-map=/build/1st/cclive-0.9.3=.·-fstack-protector-strong
 ...
  vs.
  
g++,·-g·-O2·-ffile-prefix-map=/build/2/cclive-0.9.3/2nd=.·-fstack-protector-strong
 ...

The attached proof-of-concept patch to src/cc/options.h fixes this by
not embedding CXXFLAGS in the resulting binaries.

A better fix would be to adjust the included CXXFLAGS and replace the
build path with a placeholder string (e.g. BUILDPATH), but maybe someone
who knows cclive specifically would have a better idea where would be
best to do that.

According to my local tests, with this patch applied, cclive should build
reproducibly on tests.reproducible-builds.org!

Thanks for maintaining cclive!

live well,
  vagrant
From cb92801bf7abb55ba8af60a804aebe401f13717a Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 6 Oct 2022 00:37:11 +
Subject: [PATCH] src/cc/options.h: Avoid recording the build flags.

These flags embed the build path, which may vary between builds.

https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html
---
 src/cc/options.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/cc/options.h b/src/cc/options.h
index c8df39b..49ea333 100644
--- a/src/cc/options.h
+++ b/src/cc/options.h
@@ -747,7 +747,7 @@ private:
 #endif
   << "\n  built on " << BUILD_TIME
   << " for " << CANONICAL_TARGET
-  << "\nwith "   << CXX", "CXXFLAGS
+  << "\nwith "   << CXX
   << "\n  libquvi "  << quvi::version()
   << "\n  libquvi-scripts "
   << quvi_version(QUVI_VERSION_SCRIPTS)
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#925473: Accepted tomcat9 9.0.64-2 (source) into unstable

[Thorsten Glaser]

On Thu, 6 Oct 2022, Emmanuel Bourg wrote:

> It appears that this idea has been implemented last year with the
> orphan-sysvinit-scripts package, under the Debian sysvinit maintainers
> umbrella. It was released with Bullseye and already contains an init script
> for tomcat9.

A very broken init script though.

> Could we agree this is a fair compromise, compliant with the result of
> the GR on init systems, and move on?

I’ve still got complaints, but I guess we could at least fix the
status quo. There’s more to this than the script though. Go checkout
the sysvinit branch and look at these, please:

- debian/libexec/sysv-getjre.sh
- debian/libexec/sysv-start.sh

OK to have them in the main package? Some more patches are also
needed, I will need to pick that out, but I don’t have any time
before probably middle of next week for that.

I’d still prefer to have *all* of the logic in the main package,
but this way we can at least keep things somewhat in sync, if you
agree to these scripts. Note that the way of doing it like this
was explicitly recommended to me by someone from the systemd crowd.

The sysvinit branch is tested, btw. I have an extra patch to allow
for compilation on bullseye and installation of the resulting binary
package on buster, and it works on both. While the patch might make
sense to have anyway (so bullseye-security can receive updates) I’d
tackle that separately, as it has no relation to the init foo.

At least orphan-sysvinit-scripts is team-maintained and I’m kinda
in that team as well so I can update both at the same time.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1021330: nvidia-cuda-dev appears to break nvidia xorg

[Timothy Hanson]

Package: nvidia-cuda-dev
Version: 11.5.2-2
Severity: important
X-Debbugs-Cc: sidesk...@gmail.com

Dear Maintainer,

Today ran apt-get upgrade, including updating nvidia-cuda-dev.  The update
seems to have broken nvidia xorg driver; proximal reason seemsto be that it
pulls in nvidia-tesla-alternative nvidia-tesla-kernel-dkms libnvidia-tesla-
cuda1 (and others) which are a conflicting version (510.85.x).  Video driver
is:
ii  nvidia-kernel-dkms  470.141.03-2
amd64NVIDIA binary kernel module DKMS source

Removal of nvidia-cuda-dev, installation from the .run file from Nvidia website
directly, seems to resolve the issue.

I may have mis-configured something, but to my limited knowledge it might be a
package problem.

thank you for the maintenance of these packages.

Cheers,
Tim


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

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

Versions of packages nvidia-cuda-dev depends on:
pn  libaccinj64-11.5   
pn  libaccinj64-9.2
pn  libcublas11
pn  libcublas9.2   
pn  libcublaslt11  
pn  libcuda1 | libnvidia-tesla-cuda1 | libnvidia-tesla-470-cuda1   
pn  libcudart11.0  
pn  libcudart9.2   
pn  libcufft10 
pn  libcufft9.2
pn  libcufftw10
pn  libcufftw9.2   
pn  libcuinj64-11.5
pn  libcuinj64-9.2 
pn  libcupti-dev   
pn  libcurand10
pn  libcurand9.2   
pn  libcusolver11  
pn  libcusolver9.2 
pn  libcusolvermg11
pn  libcusparse11  
pn  libcusparse9.2 
pn  libnppc11  
pn  libnppc9.2 
pn  libnppial11
pn  libnppial9.2   
pn  libnppicc11
pn  libnppicc9.2   
pn  libnppicom9.2  
pn  libnppidei11   
pn  libnppidei9.2  
pn  libnppif11 
pn  libnppif9.2
pn  libnppig11 
pn  libnppig9.2
pn  libnppim11 
pn  libnppim9.2
pn  libnppist11
pn  libnppist9.2   
pn  libnppisu11
pn  libnppisu9.2   
pn  libnppitc11
pn  libnppitc9.2   
pn  libnpps11  
pn  libnpps9.2 
pn  libnvblas11
pn  libnvblas9.2   
pn  libnvgraph9.2  
pn  libnvidia-ml-dev   
ii  libnvidia-ml1  470.141.03-2
pn  libnvjpeg11
pn  libnvrtc-builtins11.5  
pn  libnvrtc11.2

Bug#925473: Accepted tomcat9 9.0.64-2 (source) into unstable

[Emmanuel Bourg]

Le 23/06/2022 à 00:52, Emmanuel Bourg a écrit :


To avoid the proliferation of sysvinit script packages the best approach
would be to group the scripts into a common package (maybe using a trigger
to install the script when a supported daemon is installed on the system).
This would lift the burden of maintaining these scripts off most DDs and
delegate the work to a small set of dedicated maintainers, properly
optimizing and harmonizing these scripts.


It appears that this idea has been implemented last year with the 
orphan-sysvinit-scripts package, under the Debian sysvinit maintainers 
umbrella. It was released with Bullseye and already contains an init 
script for tomcat9.


So at this point, we have a tomcat9 package with a systemd service file, 
which plays nice on systems without systemd, and can be started with 
sysvinit by installing an extra package.


Could we agree this is a fair compromise, compliant with the result of 
the GR on init systems, and move on?


Emmanuel Bourg

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Steve Langasek]

On Wed, Oct 05, 2022 at 02:13:16PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
> Hi Steve,

> Quoting Steve Langasek (2022-09-09 07:09:32)
> > My feedback to you on IRC was that I think it's inappropriate for you to go
> > package-by-package in the BTS to the packages in the base set expecting
> > support for a feature that has to my knowledge never been surfaced for
> > project-wide discussion on debian-devel or similar.

> > So if you want to take that discussion to the Technical Committee to ratify
> > as something that base packages must support, well, I don't think that's the
> > best use of the TC vs just starting a thread on debian-devel,

> I agree that this is not the best use of the TC's time. Since we both agree on
> that and since it has been more than three weeks since our post to d-devel [1]
> without any concerns or otherwise negative feedback, do you still want to wait
> for the TC to decide or do you want to cut it short by applying our patch?

> [1] https://lists.debian.org/166289720850.2390.3729551131862514967@localhost

No need to wait on the TC at all; your post and the subsequent discussion on
debian-devel (and -policy) addresses my concerns, thank you.  At this point
committing and uploading is blocked only on me having the time to context
switch, review the diff (because I deeply trust Sam's technical judgement,
nevertheless won't commit/upload something in my own name without looking at
it myself for accountability purposes), and upload.  I hope I might get this
done this week.

> > but it does satisfy my expectation that there be a project-level review of
> > the design prior to obligating base package maintainers to support this
> > feature.

> We are working on some changes to Debian policy in #1020323 but we are not
> planning to put any "must" statements in the text. Our intention is not to
> obligate anybody to do anything other than apply reasonable patches that we
> provide. If it breaks, it is not your responsibility to fix it. Since the
> DPKG_ROOT variable is empty during normal installations I hope you agree that
> our patch will not be able to introduce any bugs during normal package
> installation. If the chrootless bootstrapping should fail in the future, it is
> not the obligation of package maintainers to fix it. We have said so multiple
> times in the past already...

Hmm, possibly paralleling some other discussions elsewhere.  I understand
and appreciate your position that you will do the work to fix any bugs in
this feature.  As a maintainer, I am happy to work with you on this.  I
don't mean obligation in a policy sense, there was clearly no Debian Policy
language around this at all at the time!  I mean it in a more general sense
encompassing both "social expectations of a fellow maintainer to cooperate"
and "decision imposed by the TC".

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


signature.asc
Description: PGP signature

Bug#1013034: Bug fix now in sane-backends

[Ralph Little]

Hi,
Upstream now has a fix for this issue:

https://gitlab.com/sane-project/backends/-/merge_requests/757

You may perhaps pull this change and drop the patch.

Thanks for the report!

Cheers,
Ralph Little

Bug#999785: built-using-field-on-arch-all-package emitted for non-Go packages

[Sean Whitton]

Hello,

On Tue 16 Nov 2021 at 10:19PM +05, Andrey Rahmatullin wrote:

> Package: lintian
> Version: 2.112.0
> Severity: normal
>
> When lib/Lintian/Check/Debian/Control.pm was split, the Build-Depends: golang-
> go | golang-any check was removed from built-using-field-on-arch-all-package
> and so now it's emitted for all arch:all packages with Built-Using.
>
> If it was done intentionally, which the tag name and description would 
> suggest,
> then I don't think they are correct. The statement in the description makes no
> sense outside of Go context, and the tag name as submitted in
> https://bugs.debian.org/891072 was golang-built-using-on-arch-all but was
> changed by Lamby when applying.

This just confused a sponsee of mine.  The blanket statement that
built-using never makes sense for arch:all is indeed not right.  Could
the tag just be dropped for the time being?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#612607: Connecting to older ssh version has cipher negotiation problem

[Thorsten Glaser]

For the record, -hpn is a contemporary patchset for high-performance
SSH throughput and actively maintained, from what I gather from the
OpenSSH mailing list.

And the bug isn’t restricted to that… I had the corresponding Launchpad
bug subscribed, so it must have hit me at some point.

I agree that 7 years after the last complaint it can probably be closed
but think it’s sad that the cause and fix were never found.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#1020456: cypari2 FTBFS with PARI 2.15.0

[Bill Allombert]

On Wed, Sep 21, 2022 at 11:57:40PM +0300, Adrian Bunk wrote:
> Testing cypari2.gen
> **
> File 
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
>  line ?, in cypari2.gen.Gen.__complex__
> Failed example:
> complex(g)
> Differences (ndiff with -expected +actual):
> - (2.2847006554165614+0j)
> + (1.118033988749895+0j)
> **
> File 
> "/<>/.pybuild/cpython3_3.10_cypari2/build/cypari2/gen.cpython-310-x86_64-linux-gnu.so",
>  line ?, in cypari2.gen.__test__.Gen.__complex__ (line 2006)
> Failed example:
> complex(g)
> Differences (ndiff with -expected +actual):
> - (2.2847006554165614+0j)
> + (1.118033988749895+0j)
> **
> 2 items had failures:
>1 of  13 in cypari2.gen.Gen.__complex__
>1 of  13 in cypari2.gen.__test__.Gen.__complex__ (line 2006)

This one is a bug in PARI/GP, that has been fixed in master.
Once we get to the point it is the only remaining show stopper, I will
update PARI/GP in sid.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#1003658: geary: Search stops working after a while

[Jeremy Bicha]

On Wed, Oct 5, 2022 at 6:27 PM Andres Salomon  wrote:
>
> On Thu, 13 Jan 2022 12:04:45 +0100 Matthias Brennwald
>  wrote:
>  > Package: geary
>  > Version: 40.0-1
>  > Severity: normal
>  > Tags: patch
>  > X-Debbugs-Cc: mbren...@gmail.com
>  >
>  > Dear Maintainer
>  >
>  > The function to search for emails stops working after running Geary
> for a
>  > while. I can get it to work again either by rebooting the computer,
> or by doing
>  > "killall geary" and then restart Geary. Just restarting Geary alone
> does not
>  > help. I guess there is some background process related to the Geary
> search,
>  > which gets stuck and then causes the search to stop working.
>
>
>
> I've experienced this bug as well. However, it's in debian stable
> (bullseye) with geary 3.38.1-1. Oddly enough, upgrading to (a backport
> of) geary 40.0-7 seems to have fixed the issue.  3.38.1-1 worked fine
> for me for at least a year, and then suddenly I couldn't search any
> more and no amount of restarting seemed to fix it.

When did you start experiencing the bug?

Thank you,
Jeremy Bicha

Bug#1021297: cruft-ng: only processes files with . in their path name

[Alexandre Detiste]

Thanks a lot, I see now there's a lot more to fix.

Bug#1021329: pytest-runner: Import current upstream version

[Bastian Germann]

Source: pytest-runner
Severity: minor
Version: 2.11.1-2

Please import the latest upstream version, which is 6.0.0 currently.

Bug#1003658: geary: Search stops working after a while

[Andres Salomon]

On Thu, 13 Jan 2022 12:04:45 +0100 Matthias Brennwald 
 wrote:

> Package: geary
> Version: 40.0-1
> Severity: normal
> Tags: patch
> X-Debbugs-Cc: mbren...@gmail.com
>
> Dear Maintainer
>
> The function to search for emails stops working after running Geary 
for a
> while. I can get it to work again either by rebooting the computer, 
or by doing
> "killall geary" and then restart Geary. Just restarting Geary alone 
does not
> help. I guess there is some background process related to the Geary 
search,

> which gets stuck and then causes the search to stop working.



I've experienced this bug as well. However, it's in debian stable 
(bullseye) with geary 3.38.1-1. Oddly enough, upgrading to (a backport 
of) geary 40.0-7 seems to have fixed the issue.  3.38.1-1 worked fine 
for me for at least a year, and then suddenly I couldn't search any 
more and no amount of restarting seemed to fix it.

Bug#1021328: RFP: libspring-boot-java -- a radically faster getting started experience for all Spring development

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name: libspring-boot-java
  Upstream Author :spring.io crontributors
* URL : https://gitgud.io/themusicgod1/spring-boot
* License : Apache
  Programming Lang: java
  Description : A radically faster 'getting started' experience
for all Spring development

Spring Boot makes it easy to create Spring-powered, production-grade
applications and services with absolute minimum fuss. It takes an
opinionated view of the Spring platform so that new and existing users
can quickly get to the bits they need.
You can use Spring Boot to create stand-alone Java applications that
can be started using java -jar or more traditional WAR deployments. We
also provide a command line tool that runs spring scripts.

Bug#1019824: 3depict: Please transition to wxwidgets3.2

[D Haley]

Hi,


I will address this in a few weeks - I think there are only minor
changes required to make the transition. I've patched the upstream
repository, but not tested it against the latest wx packages. I will
update as soon as I can.


Thanks!

Bug#1019745: RFP: sphinx-enum-tools -- expand Python's enum module in Sphinx documentation

[Bastian Germann]

Nilson, please consider making #1021204 your ITP and package whey under the 
python team:
https://salsa.debian.org/python-team/packages/whey. Else enum-tools cannot be 
built.

Bug#1014078: RFS: librosa/0.9.2-1 [ITP] -- Python package for music and audio analysis

[Bastian Germann]

On Sun, 17 Jul 2022 13:41:24 +0200 Bastian Germann  wrote:

On Wed, 29 Jun 2022 22:41:43 + Nilson Silva  
wrote:
>   dget -x 
https://mentors.debian.net/debian/pool/main/libr/librosa/librosa_0.9.2-1.dsc
>   salsahttps://salsa.debian.org/nilsonfsilva/librosa
> 
> Changes for the initial release:
> 
>  librosa (0.9.2-1) experimental; urgency=medium

>  .
>* Initial release. (Closes: #968467)

The debian directory is not available in the repo anymore, so I am closing this 
RFS.
Please reopen or file a new one when the dependencies are in unstable and you 
got the -doc package ready.


Please remove your repo and use https://salsa.debian.org/debian/librosa from 
now on.

Bug#508376: Many years later...

[Iustin Pop]

Many years later, any chance of changing the default? Or nobody runs
mail servers maybe?

Just saw the same behaviour on one of my machines, and was surprised at
the duplicate contents.


thanks,
iustin

Bug#1021292: dpkg-dev: Please add support for pointer authentication on arm64

[Guillem Jover]

Control: tag -1 moreinfo

Hi!

On Wed, 2022-10-05 at 03:46:06 +0100, Wookey wrote:
> Package: dpkg-dev
> Version: 1.19.7
> Severity: wishlist
> Tags: patch

> As discussed in the below-linked thread on dpkg-dev, we should enable
> PAC and BTI on arm64 as a standard hardening flag.
> https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
> 
> Attached is Guillem's proposed patch which does the trick, updated for
> current dpkg (I opened this bug file in June, but forgot to actually
> press send, so now updated for the current 1.21.9)

Yes, I've had this locally as a branch since then:

  


:)

> Despite this delay, I hope we can can have this in for bookworm.

As mentioned on the thread, I was expecting a thread to be started on
debian-devel, as this changes the current default for both amd64 and
arm64. As mentioned on the thread on d-dpkg, we can always detangle
the arch support and postpone either if they seem controversial. So,
if you could start that discussion, that would be great. If there is
pushbach, then I guess this would not be currently mergeable as-is,
even disabled by default. But then we could entertain what I've
recently mentioned elsewhere about versioning the features surface
and the “all” selector in particular to be able to add it anyway (at
least disabled though).

Thanks,
Guillem

Bug#1021327: firefox-esr: TPM not usable

[Björn Siebke]

Package: firefox-esr
Version: 102.3.0esr-1~deb11u1
Severity: normal
X-Debbugs-Cc: bjoernsie...@web.de

Dear Maintainer,

I reported this bug on Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=1793854

Steps to reproduce:
Tried to make a sample registration using FIDO2/WebAuthn Authentication method
on https://webauthn.io/

Actual results:
Text is displayed that I should connect a secure token although my computer has
a TPM

Expected results:
Firefox to connect to the TPM and offer to use it.

I tried to fix this by registering a PKCS#11 module in Firefox on my Debian 11
GNU/Linux desktop. Did not succeed.
On my Android phone the exact same thing in the Firefox browser app worked
using the TPM. As far as I know on Windows it also works.


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libasound2   1.2.4-1.1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1+deb11u1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4+deb11u2
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.2-1
ii  libx11-xcb1  2:1.7.2-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  libxtst6 2:1.2.3-1
ii  procps   2:3.3.17-5
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.3.4-0+deb11u1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.18.3-6+deb11u2
ii  pulseaudio 14.2-2

-- no debconf information

Bug#1021326: wiki.debian.org: Incorrect ami id on Cloud/AmazonEC2Image/Stretch

[Boyuan Yang]

Control: affects -1 cloud.debian.org

Hi,

在 2022-10-05星期三的 20:27 +，Anders Carling写道：
> Package: wiki.debian.org
> 
> 
> On https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch arm64 ami id is
> indicated as ami-0d78ea9dc521d7ed3 for both region ca-central-1 and eu-
> central-1.
> 
> The ami id seems to be correct for eu-central-1, but does not exist in ca-
> central-1. The correct ami id for ca-central-1 seems to be ami-
> 0bd9e6cecc0099058 based of the documented ami name and AWS account ID
> documented on the same wiki page.

Forwarding your issue to Debian Cloud Team.

Thanks,
Boyuan Yang


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

Bug#1011358: RFP: tpm2-pytss -- TPM2 TSS Python bindings

[Bastian Germann]

On Mon, 12 Sep 2022 11:51:28 +0200 Claudius Heine  wrote:

The tpm2-pytss package is on its way into the repos:

https://ftp-master.debian.org/new.html


I guess this was rejected because of the missing license that was added in
https://salsa.debian.org/python-team/packages/tpm2-pytss/-/commit/945a898fb27a3bd2.
Do you need this to be sponsored again?

Bug#1021326: wiki.debian.org: Incorrect ami id on Cloud/AmazonEC2Image/Stretch

[Anders Carling]

Package: wiki.debian.org


On https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch arm64 ami id is 
indicated as ami-0d78ea9dc521d7ed3 for both region ca-central-1 and 
eu-central-1.

The ami id seems to be correct for eu-central-1, but does not exist in 
ca-central-1. The correct ami id for ca-central-1 seems to be 
ami-0bd9e6cecc0099058 based of the documented ami name and AWS account ID 
documented on the same wiki page.

Bug#1021325: irrlicht: non-free files included

[Bastian Germann]

Source: irrlicht
Version: 1.8.5+ds-2
Severity: serious

The irrlicht source includes the media/dwarf* files which have a non-free 
license.
Please repack getting rid of it. The package will still build without them.

Bug#1021297: cruft-ng: only processes files with . in their path name

[Alexandre Detiste]

Hi,

Can you provide examples and/or an excerpt of the cruft report ?

I still plan to read placate and dpkg data using C libraries instead
of shelling out
to popen(), as it was the case before for mlocate.

Greetings,

Alexandre

Le mer. 5 oct. 2022 à 08:33, Piotr Engelking  a écrit :
>
> Package: cruft-ng
> Version: 0.9.44
> Severity: normal
>
> The cruft-ng utility only processes files with dot (.) in their path name.
>
> The problem is caused by plocate.cc using 'plocate .' to find files. The
> simplest fix is probably to replace it with 'plocate /'.
>

Bug#1021032: VLC Black screen

[Markus Huber]

> By the way, once updated to the new VLC version (3.0.17.4-5) in a fully
> updated Sid I noticed after seeing a few videos the player goes black again
> and nothing until a reboot is issued.
> 
> Anyone else noticed this?

Yes (also on current sid with VLC 3.0.17.4-5) i can confirm: after switching to 
another videos in my playlist it turns to black again.
Disabling "Integrate video in interface" is a workaround (reported in #1021140).

Bug#1019353: transition: perl 5.36

[Niko Tyni]

Control: tag -1 - moreinfo
Control: block -1 with 1021324

On Wed, Sep 07, 2022 at 09:47:39PM +0300, Niko Tyni wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> Tags: moreinfo
> X-Debbugs-Cc: p...@packages.debian.org
> Control: block -1 with 1016761
> 
> We'd like to get Perl 5.36 in bookworm. Filing this to get it on the
> radar properly, but I'd like to do a few more checks first. So tagging
> 'moreinfo' for now. I'll remove that when I'm done with the checks,
> hopefully in a couple of weeks at the latest.

That was a bit optimistic (no real problems, I just couldn't find the
time), but I think we're ready now.

I've just test rebuilt the packages needing a binNMU one more time, and
the only one failing in testing is redland-bindings (#1021324, should be
trivial to fix.)  I'm marking that as a blocker, but I haven't checked
if it could be removed easily if necessary.

#1019757 is still open but I've worked around the one autopkgtest
regression that it triggered. I don't think it should be a blocker for
the transition.  I'm not aware of any other autopkgtest regressions
(but I've only tested on amd64.)

Hope this addresses any concerns you might have. Please let us know
when there is a free transition window.  An advance notice of a few days
would be appreciated.

Thanks for your work as always,
-- 
Niko

Bug#1019187: junior-games-sim: Please update freeciv reommendation

[Stefan Kropp]

Control: owner -1 !

Merge request has been merged. Thanks

Bug#1021324: redland-bindings: FTBFS: missing build dependency on pkg-config

[Niko Tyni]

Source: redland-bindings
Version: 1.0.17.1+dfsg-2
Severity: serious
Tags: ftbfs

This package fails to build from source on current sid.

Log excerpt:

  checking for swig... swig
  checking for pkg-config... no
  checking SWIG support... 4.0.2 - OK
[...]
  checking Enable PHP API... no
  checking Enable Ruby API... no
  checking for redland... ./configure: line 13855: --exists: command not found
  not found
  configure: error: Redland is not installed - see http://librdf.org/ to get a 
version 1.0.17 or newer

The (regenerated) configure script has this around line 13855:

  printf %s "checking for redland... " >&6; }
  if $PKG_CONFIG --exists redland; then
REDLAND_CONFIG="$PKG_CONFIG redland"

Clearly the problem is that pkg-config no longer gets pulled in.

It looks like this regressed with libraptor2-dev 2.0.15-3, which dropped
its dependency on pkg-config, triggering a latent bug in redland-bindings
of a missing a build dependency.

A full build log is available at

  
http://perl.debian.net/rebuild-logs/sid/redland-bindings_1.0.17.1+dfsg-2/redland-bindings_1.0.17.1+dfsg-2.buildlog

-- 
Niko Tyni   nt...@debian.org

Bug#1021322: librust-pyo3-dev: impossible to install

[Jonas Smedegaard]

Package: librust-pyo3-dev
Version: 0.16.5-1
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package is impossible to install: Depends on missing 
librust-inventory-0.2+default-dev

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmM90pIACgkQLHwxRsGg
ASHNsRAAgohwRXMv6v9rUb3Qgji0shgFe5Bg73+Oy4CR1cMPlsVCYQLe5dd6z3aH
jJXtx73ImezOjamLamXzPH09jEtPCT8yFczfmFtqC5IrRgVXcRupJXEzZ/56pYML
gnrKVIUPDkzX1KHkEUyyY9JJ3xsGw7lEKUOwN/kqGXx2xQIibECRDEPT0djdcu9O
OjraEgonD7aYz8h/eratqVyO9OdxvToO1u4FNxxcck/7eLmKOfZJspm2Rbp7eltW
Fk8DoVucqTmKc0ZcTv7mr1cUfeoxEd4Vwnvo331fzzdKQsEbjB63uxdCQ8zARaWj
Smcb/pYQXnO5eS3mGDwX0NqZMQC/oFGA1reyfZ5FwvMF3wGKFLk8xgu6l0uT699T
b0NNU1sAR97j7uL28ftIPadT4m+183uwEQOOytIcMYf+5i4b+Q+8FuFu9i5+lKT0
nM5y2gPCvKILDfWPKnPRh8JSgYFhVcr73CiU76RWxjguYs0gwpTq8XoeLxwyTVQ3
KEKC1idgqbNCTSm8KV7WaXzRcDGzJyhrxLGLOo+OQ93kXJtrcDNpNDs4O15vMjZQ
6D03aUE+Pzqr3god8J5abQ0bi6mmo5ANJ7f5Y/kD9OzRw0FBY9+pPPH0Ka6p1Rc4
OkNkrreiPXFTFQJbgOLl18BTTCkPBeSofcx1i4l2xofN9FglocI=
=7z4k
-END PGP SIGNATURE-

Bug#1021323: Uploading address book give "Error: 400", should handle input or give more useful error message

[Petter Reinholdtsen]

Package: radicale
Version: 3.1.8-1

I am testing a recently configured Freedombox image, where I configured
radicale to test as a calendar and address book server.

My address book is a 518KiB vcard file exported from evolution, with my
collection of addresses.  When I try to use the radicale web interface
to "Upload addressbook or calendar", I get "please wait" for a while
until I finally get 'Error: 400' and no address book has shown up in the
list of sources in evolution.

I had a look at journalctl -f to see if I could find the error, and
found this one:

  okt. 05 18:50:51 freedombox apache-access[20633]: 127.0.1.1:443
192.168.0.28 - pere [05/Oct/2022:18:50:48 +] "PUT
/radicale/pere/e6a92736-e44d-8628-9581-babb888059de/ HTTP/2.0" 400
240 "https://192.168.0.17/radicale/.web/"; "Mozilla/5.0 (X11; Linux
x86_64) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.15.2
Chrome/83.0.4103.122 Safari/537.36 Konqueror (WebEnginePart)"

Nothing showed up under /var/lib/radicale/.  In
/var/log/uwsgi/app/radicale.log I found the following:

  [2022-10-05 18:50:48 +] [13882] [WARNING] Base prefix (from
HTTP_X_SCRIPT_NAME) must not end with '/': '/radicale/'
  [2022-10-05 18:50:51 +] [13882] [WARNING] Bad PUT request on
'/pere/e6a92736-e44d-8628-9581-babb888059de/': Failed to serialize
item None from 'pere/e6a92736-e44d-8628-9581-babb888059de': 'VCARD
components must contain at least 1 FN'
  [pid: 13882|app: 0|req: 122/226] 192.168.0.28 (pere) {98 vars in 1735
bytes} [Wed Oct 5 18:50:48 2022] PUT
/radicale/pere/e6a92736-e44d-8628-9581-babb888059de/ => generated 31
bytes in 2715 msecs (HTTP/2.0 400) 3 headers in 113 bytes (65
switches on core 0)

It look like radicale do not like the vcard file generated by evolution
from an earlier radicale address book collection.  I got more than 1000
addresses there, so it will be some work to figure out why it did not
like the format with so little information.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1021321: src:openrazer: fails to migrate to testing for too long: unresolved RC bugs

[Paul Gevers]

Source: openrazer
Version: 3.3.0+dfsg-2
Severity: serious
Control: close -1 3.4.0+dfsg-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1018789 1020039

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:openrazer has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package has unresolved RC 
bugs.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=openrazer



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021320: isc-dhcp: CVE-2022-2928 CVE-2022-2929

[Salvatore Bonaccorso]

Source: isc-dhcp
Version: 4.4.3-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 4.4.1-2.3
Control: fixed -1 4.4.1-2.3+deb11u1

Hi,

The following vulnerabilities were published for isc-dhcp.

CVE-2022-2928[0]:
| An option refcount overflow exists in dhcpd

CVE-2022-2929[1]:
| DHCP memory leak

4.4.1-2.3+deb11u1 is uploaded to security-master and pending a DSA
release.

If needed I can try to contribute a NMU for unstable/bookworm.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-2928
https://www.cve.org/CVERecord?id=CVE-2022-2928
https://kb.isc.org/docs/cve-2022-2928
[1] https://security-tracker.debian.org/tracker/CVE-2022-2929
https://www.cve.org/CVERecord?id=CVE-2022-2929
https://kb.isc.org/docs/cve-2022-2929
[2] https://lists.isc.org/pipermail/dhcp-announce/2022-October/000437.html

Regards,
Salvatore

Bug#1021319: GIMP crashed with a fatal error: fatal error: Segmentation fault

[Md Adil]

Package: GIMP
Version: 2.10.32

I am Using Windows 10

*


```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: org.gimp.GIMP_official rev 1 for windows
# C compiler #
Using built-in specs.
COLLECT_GCC=W:\msys64-gtk2\mingw32\bin\gcc.exe

COLLECT_LTO_WRAPPER=W:/msys64-gtk2/mingw32/bin/../lib/gcc/i686-w64-mingw32/12.1.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-12.1.0/configure --prefix=/mingw32
--with-local-prefix=/mingw32/local --build=i686-w64-mingw32
--host=i686-w64-mingw32 --target=i686-w64-mingw32
--with-native-system-header-dir=/mingw32/include
--libexecdir=/mingw32/lib --enable-bootstrap --enable-checking=release
--with-arch=i686 --with-tune=generic
--enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic
--enable-threads=posix --enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp
--disable-multilib --disable-rpath --disable-win32-registry
--disable-nls --disable-werror --disable-symvers --with-libiconv
--with-system-zlib --with-gmp=/mingw32 --with-mpfr=/mingw32
--with-mpc=/mingw32 --with-isl=/mingw32 --with-pkgversion='Rev2, Built
by MSYS2 project'
--with-bugurl=https://github.com/msys2/MINGW-packages/issues
 --with-gnu-as
--with-gnu-ld --disable-libstdcxx-debug --disable-sjlj-exceptions
--with-dwarf2 --with-boot-ldflags=-static-libstdc++
--with-stage1-ldflags=-static-libstdc++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Rev2, Built by MSYS2 project)

# Libraries #
using babl version 0.1.92 (compiled against version 0.1.92)
using GEGL version 0.4.36 (compiled against version 0.4.36)
using GLib version 2.72.2 (compiled against version 2.72.2)
using GdkPixbuf version 2.42.8 (compiled against version 2.42.8)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.7 (compiled against version 1.50.7)
using Fontconfig version 2.14.0 (compiled against version 2.14.0)
using Cairo version 1.17.6 (compiled against version 1.17.6)

```
> fatal error: unhandled exception

Stack trace:
```
---

Error occurred on Wednesday, October 5, 2022 at 23:45:40.

gimp-2.10.exe caused an Access Violation at location 65A47134 in
module libbabl-0.1-0.dll Writing to location .

Registers:
eax=0010 ebx=0010 ecx=0400 edx= esi=0004 edi=03c687b0
eip=65a47134 esp=04ddf360 ebp=04ddf638 iopl=0 nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs= efl=00010202

AddrPC   Params
65A47134 03C687B0 38230C80 1C45DA78  libbabl-0.1-0.dll!babl_extension_quiet_log
65A4BF1A 0E718098 0E736360 017F  libbabl-0.1-0.dll!babl_process_rows
65C0A792     libglib-2.0-0.dll!g_rec_mutex_unlock

gimp-2.10.exe   2.10.32.0
ntdll.dll   10.0.19041.2075
KERNEL32.DLL10.0.19041.1889
KERNELBASE.dll  10.0.19041.2075
msvcrt.dll  7.0.19041.546
ole32.dll   10.0.19041.1202
ucrtbase.dll10.0.19041.789
RPCRT4.dll  10.0.19041.1806
combase.dll 10.0.19041.1949
GDI32.dll   10.0.19041.2075
win32u.dll  10.0.19041.2075
gdi32full.dll   10.0.19041.2075
msvcp_win.dll   10.0.19041.789
USER32.dll  10.0.19041.2075
SHELL32.dll 10.0.19041.2075
libgimpcolor-2.0-0.dll
libgimpconfig-2.0-0.dll
libgimpmath-2.0-0.dll
libgimpmodule-2.0-0.dll
libgimpthumb-2.0-0.dll
libgimpwidgets-2.0-0.dll
exchndl.dll 0.8.2.0
PSAPI.DLL   10.0.19041.546
libgimpbase-2.0-0.dll
libcairo-2.dll
ADVAPI32.dll10.0.19041.1682
sechost.dll 10.0.19041.1865
dbghelp.dll 6.3.9600.17336
libfontconfig-1.dll
libfreetype-6.dll   2.12.1.0
libgdk_pixbuf-2.0-0.dll 2.42.8.0
libgexiv2-2.dll
libglib-2.0-0.dll   2.72.2.0
WS2_32.dll  10.0.19041.546
libgio-2.0-0.dll2.72.2.0
SHLWAPI.dll 10.0.19041.2075
libgobject-2.0-0.dll2.72.2.0
libbabl-0.1-0.dll
libharfbuzz-0.dll
libintl-8.dll   0.21.0.0
libjson-glib-1.0-0.dll
liblcms2-2.dll
libmypaint-0.dll
libpango-1.0-0.dll  1.50.7.0
libpangocairo-1.0-0.dll 1.50.7.0
libpangoft2-1.0-0.dll   1.50.7.0
zlib1.dll
libgegl-npd-0.4.dll
libgegl-0.4-0.dll
libgdk-win32-2.0-0.dll  2.24.33.0
libgtk-win32-2.0-0.dll  2.24.33.0
libgmodule-2.0-0.dll2.72.2.0
libgcc_s_dw2-1.dll
COMDLG32.DLL10.0.19041.1806
shcore.dll  10.0.19041.1645
IMM32.DLL   10.0.19041.546
mscms.dll   10.0.19041.746
VERSION.dll 10.0.19041.546
libstdc++-6.dll
MSIMG32.DLL 10.0.19041.1466
libpng16-16.dll
libexpat-1.dll
libiconv-2.dll  1.17.0.0
libbz2-1.dll
libbrotlidec.dll
gdiplus.dll 10.0.19041.2006
libexiv2.dll
DNSAPI.dll  10.0.19041.1865
IPHLPAPI.DLL10.0.19041.546
libpcre-1.dll
libffi-7.dll
DWrite.dll  10.0.19041.1566
USP10.dll   10.0.19041.546
libgraphite2.dll
libpixman-1-0.dll
libjson-c-5.dll
libfrib

Bug#1020414: The patch have been merged upstream

[Vincent-Xavier JUMEL]

https://github.com/neomutt/neomutt/pull/3524 closes 
https://github.com/neomutt/neomutt/issues/3514
so neomutt could be updated with the latest master to reenable back sasl 
support via GNU SASL


Thank you,
--
Vincent-Xavier JUMEL GPG Id: 0x14ABB3F2 http://thetys-retz.net

Rejoignez les 5334 adhérents de l'April http://www.april.org/adherer
Parinux, logiciel libre à Paris : http://www.parinux.org

0xBF70C781.asc
Description: application/pgp-keys

Bug#1021318: lightdm: New upstream version 1.32.0

[Jonatas]

Package: lightdm
Version: 1.26.0-8
Severity: normal
X-Debbugs-Cc: jonatas.eletr...@gmail.com

Dear Maintainer,

The current version in sid is 1.26 and the current version of the project is
1.32.0 and contains many important fixes, as follows:
https://github.com/canonical/lightdm/releases

Thanks,

Jonatas


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

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

Versions of packages lightdm depends on:
ii  adduser3.129
ii  dbus   1.14.2-1
ii  debconf [debconf-2.0]  1.5.79
ii  libaudit1  1:3.0.7-1.1
ii  libc6  2.35-2
ii  libgcrypt201.10.1-2
ii  libglib2.0-0   2.74.0-2
ii  libpam-systemd [logind]251.5-1
ii  libpam0g   1.5.2-2
ii  libxcb11.15-1
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.8-2+b1
ii  lsb-base   11.4
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+23

Versions of packages lightdm suggests:
pn  accountsservice  
ii  upower   0.99.20-1
pn  xserver-xephyr   

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm

Bug#1019510: marked as done (systemd-sysv: annoying beep during shutdown or reboot)

[Michael Biebl]

Control: reopen -1
Control: forwarded -1 https://github.com/systemd/systemd/issues/23520

I'm tentatively reopening this bug report as there is an upstream bug 
report that was just reopened.



I can reproduce the beeps once I unmuted "Beep" via alsamixer. 
Interestingly also got those beeps on suspend.


It's my understanding, that the "traditional" behaviour of sysvinit was 
actually to send a wall message on reboot (and wall triggering the beep).


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1020323: debian-policy: document DPKG_ROOT

[Helmut Grohne]

Hi Joshannes,

On Wed, Oct 05, 2022 at 02:35:30PM +0200, Johannes Schauer Marin Rodrigues 
wrote:
>To enable creating a foreign architecture Debian chroot during the early
>bootstrap of a new Debian architecture, maintainer scripts and utilities
>called by maintainer scripts of packages in the essential and
>build-essential set, should support operating on a custom chroot directory.
>This is to avoid running any of the foreign architecture utilities from the
>chroot, because those cannot be executed during the early bootstrapping
>phase of a new architecture.  Instead, by avoiding the chroot() call,
>utilities from the outside should operate on the chroot path given via the
>`DPKG_ROOT` environment variable.  This environment variable is set but
>empty during normal package installations.  If the `DPKG_ROOT` environment
>variable is not empty, then this indicates to the maintainer scripts and 
> the
>tools it executes, that a chroot is being built as part of an early
>architecture bootstrap and all operations should be performed in the chroot
>path given by the contents of the `DPKG_ROOT` environment variable. In that
>case, the maintainer script should not modify anything outside the chroot
>directory.

Thank you for writing this.

> I refrained from using "must" because we promised maintainers that they would
> not need to do the work themselves but will get patches sent from us. We do 
> not
> want to force work on maintainers by making it an RC bug if they do not 
> support
> DPKG_ROOT.
> 
> Helmut, what do you think?

I think this text is already quite good. I am yet wondering about the
scope of support that we mention here.

1. You write that we want essential + build-essential. In practice, we
   also want things such as apt or systemd. I am wondering whether we
   should rephrase this in a less specific way that leaves open some
   packages beyond the mentioned set. Vagueness can be avoided by
   explaining the purpose: We target packages that are relevant to
   setting up an initial build daemon.

2. We should likely mention that package upgrade and removal paths can
   freely ignore DPKG_ROOT. Maintainer scripts can assume that when
   DPKG_ROOT is in effect, it will be an initial installation. Something
   along this would have helped Michael in determining whether his
   recent changes to init script handling would affect DPKG_ROOT.

Let me try to extend your text:

To enable creating a foreign architecture Debian chroot during the early
bootstrap of a new Debian architecture, maintainer scripts and utilities
called by maintainer scripts of packages relevant to setting up a
build daemon, should support operating on a custom chroot directory.
[... keep rest of the text unchanged ...]
Support for `DPKG_ROOT` in code that handles package upgrades or
package removal is not needed.

Helmut

Bug#1020691: debos should depend on systemd-resolved

[Patrice Duroux]

Hi,

> > So far, the package fakemachine Depends on systemd, and that was enough. 
> > Now with the split, and since we need systemd-resolved, we should make 
> > fakemachine Depend on systemd-resolved as well. However, and if I 
> > understand properly, installing systemd-resolved also *enables* it. A 
> > user installing the package is saying: I want name resolution to be done 
> > by systemd-resolved. Therefore it's not really suitable to put it in a 
> > Depend or a Recommend. fakemachine only needs the code from 
> > systemd-resolved (lib and binary, I suppose), but it definitely doesn't 
> > want to enable it: this decision belongs to the user.
> > 
> > Does that make sense so far?

Many times I have got the same feeling/need about packages like apache2, tomcat,
etc.
I would like to install and maintain them up-to-date using their Debian package
distribution, but having a facility to not activate their (default) root/system-
land and provide a facility for a user-land activation.
In general it is possible in fact, I have achieved such for at least the two
apache2 and tomcat ones. I mean for such packages providing a way to activate
them-self in the root/system-land as well as a (general?) facility for a user-
land service. I know that having a general approach to solve this is somehow
infeasible. But despite this could it be really interesting (at least for my
pov) to think about it and therefore a good candidate for a grow-your-idea-for-
Debian-Project ticket?

Best,
Patrice

Bug#1021317: salt-master: Fails to start with "zmq.error.ZMQError: Invalid argument"

[Vincas Dargis]

Package: salt-master
Version: 3004.1+dfsg-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

salt-master fails to start.

journalctl shows:

```
spal. 05 20:47:04 salt-master[11925]: Traceback (most recent call last):
spal. 05 20:47:04 salt-master[11925]:   File 
"/usr/lib/python3.10/multiprocessing/process.py", line 314, in _bootstrap
spal. 05 20:47:04 salt-master[11925]: self.run()
spal. 05 20:47:04 salt-master[11925]:   File 
"/usr/lib/python3.10/multiprocessing/process.py", line 108, in run
spal. 05 20:47:04 salt-master[11925]: self._target(*self._args, 
**self._kwargs)
spal. 05 20:47:04 salt-master[11925]:   File 
"/usr/lib/python3/dist-packages/salt/transport/zeromq.py", line 899, in 
_publish_daemon
spal. 05 20:47:04 salt-master[11925]: pub_sock.setsockopt(zmq.HWM, 
self.opts.get("pub_hwm", 1000))
spal. 05 20:47:04 salt-master[11925]:   File "zmq/backend/cython/socket.pyx", 
line 453, in zmq.backend.cython.socket.Socket.set
spal. 05 20:47:04 salt-master[11925]:   File "zmq/backend/cython/socket.pyx", 
line 285, in zmq.backend.cython.socket._setsockopt
spal. 05 20:47:04 salt-master[11925]:   File "zmq/backend/cython/checkrc.pxd", 
line 28, in zmq.backend.cython.checkrc._check_rc
spal. 05 20:47:04 salt-master[11925]: zmq.error.ZMQError: Invalid argument
```


-- System Information:
Debian Release: bookworm/sid
  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 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE=lt
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages salt-master depends on:
ii  adduser3.129
ii  init-system-helpers1.65.2
ii  python33.10.6-1
ii  python3-pycryptodome   3.11.0+dfsg1-3+b1
ii  python3-systemd235-1
ii  python3-zmq24.0.1-1
ii  salt-common3004.1+dfsg-2
ii  sysvinit-utils [lsb-base]  3.05-6

Versions of packages salt-master recommends:
ii  python3-pygit2  1.10.1-2

salt-master suggests no packages.

-- no debconf information

Bug#1021316: rust-kvm-bindings: FTBFS on i386

[Sebastian Ramacher]

Source: rust-kvm-bindings
Version: 0.5.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

https://buildd.debian.org/status/fetch.php?pkg=rust-kvm-bindings&arch=i386&ver=0.5.0-1&stamp=1664239343&raw=0

 
x86::bindings::bindgen_test_layout_kvm_xen_vcpu_attr__bindgen_ty_1__bindgen_ty_1
 stdout 
thread 
'x86::bindings::bindgen_test_layout_kvm_xen_vcpu_attr__bindgen_ty_1__bindgen_ty_1'
 panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `8`: Alignment of kvm_xen_vcpu_attr__bindgen_ty_1__bindgen_ty_1', 
src/x86/bindings.rs:11503:5
stack backtrace:
   0: rust_begin_unwind
 at /usr/src/rustc-1.61.0/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
 at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:143:14
   2: core::panicking::assert_failed_inner
   3: core::panicking::assert_failed
 at /usr/src/rustc-1.61.0/library/core/src/panicking.rs:182:5
   4: 
kvm_bindings::x86::bindings::bindgen_test_layout_kvm_xen_vcpu_attr__bindgen_ty_1__bindgen_ty_1
 at 
/usr/share/cargo/registry/kvm-bindings-0.5.0/src/x86/bindings.rs:11503:5
   5: 
kvm_bindings::x86::bindings::bindgen_test_layout_kvm_xen_vcpu_attr__bindgen_ty_1__bindgen_ty_1::{{closure}}
 at 
/usr/share/cargo/registry/kvm-bindings-0.5.0/src/x86/bindings.rs:11494:1
   6: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.61.0/library/core/src/ops/function.rs:227:5
   7: core::ops::function::FnOnce::call_once
 at /usr/src/rustc-1.61.0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose 
backtrace.


failures:
x86::bindings::bindgen_test_layout___kernel_fd_set
x86::bindings::bindgen_test_layout_kvm_arm_device_addr
x86::bindings::bindgen_test_layout_kvm_breakpoint
x86::bindings::bindgen_test_layout_kvm_clear_dirty_log
x86::bindings::bindgen_test_layout_kvm_clear_dirty_log__bindgen_ty_1
x86::bindings::bindgen_test_layout_kvm_clock_data
x86::bindings::bindgen_test_layout_kvm_coalesced_mmio
x86::bindings::bindgen_test_layout_kvm_coalesced_mmio_ring
x86::bindings::bindgen_test_layout_kvm_coalesced_mmio_zone
x86::bindings::bindgen_test_layout_kvm_config_tlb
x86::bindings::bindgen_test_layout_kvm_debug_exit_arch
x86::bindings::bindgen_test_layout_kvm_debug_guest
x86::bindings::bindgen_test_layout_kvm_debugregs
x86::bindings::bindgen_test_layout_kvm_device_attr
x86::bindings::bindgen_test_layout_kvm_dirty_gfn
x86::bindings::bindgen_test_layout_kvm_dirty_log
x86::bindings::bindgen_test_layout_kvm_dirty_log__bindgen_ty_1
x86::bindings::bindgen_test_layout_kvm_dirty_tlb
x86::bindings::bindgen_test_layout_kvm_dtable
x86::bindings::bindgen_test_layout_kvm_enable_cap
x86::bindings::bindgen_test_layout_kvm_enc_region
x86::bindings::bindgen_test_layout_kvm_fpu
x86::bindings::bindgen_test_layout_kvm_guest_debug
x86::bindings::bindgen_test_layout_kvm_guest_debug_arch
x86::bindings::bindgen_test_layout_kvm_hyperv_exit
x86::bindings::bindgen_test_layout_kvm_hyperv_exit__bindgen_ty_1

x86::bindings::bindgen_test_layout_kvm_hyperv_exit__bindgen_ty_1__bindgen_ty_1

x86::bindings::bindgen_test_layout_kvm_hyperv_exit__bindgen_ty_1__bindgen_ty_2

x86::bindings::bindgen_test_layout_kvm_hyperv_exit__bindgen_ty_1__bindgen_ty_3
x86::bindings::bindgen_test_layout_kvm_ioapic_state
x86::bindings::bindgen_test_layout_kvm_ioapic_state__bindgen_ty_1
x86::bindings::bindgen_test_layout_kvm_ioeventfd
x86::bindings::bindgen_test_layout_kvm_irq_routing
x86::bindings::bindgen_test_layout_kvm_irq_routing_entry
x86::bindings::bindgen_test_layout_kvm_irq_routing_entry__bindgen_ty_1
x86::bindings::bindgen_test_layout_kvm_irq_routing_s390_adapter
x86::bindings::bindgen_test_layout_kvm_irqchip
x86::bindings::bindgen_test_layout_kvm_irqchip__bindgen_ty_1
x86::bindings::bindgen_test_layout_kvm_memory_alias
x86::bindings::bindgen_test_layout_kvm_memory_region
x86::bindings::bindgen_test_layout_kvm_msr_entry
x86::bindings::bindgen_test_layout_kvm_msr_filter
x86::bindings::bindgen_test_layout_kvm_msr_filter_range
x86::bindings::bindgen_test_layout_kvm_msrs
x86::bindings::bindgen_test_layout_kvm_nested_state
x86::bindings::bindgen_test_layout_kvm_nested_state__bindgen_ty_1
x86::bindings::bindgen_test_layout_kvm_one_reg
x86::bindings::bindgen_test_layout_kvm_pit_channel_state
x86::bindings::bindgen_test_layout_kvm_pit_state
x86::bindings::bindgen_test_layout_kvm_pit_state2
x86::bindings::bindgen_test_layout_kvm_pmu_event_filter
x86::bindings::bindgen_test_layout_kvm_ppc_resize_hpt
x86::bindings::bindgen_test_layout_kvm_ppc_smmu_info
x86::bindings::bindgen_test_layout_kvm_pv_cmd
x86::bindings::bindgen_test_layou

Bug#1020819: subtitlecomposer: Cannot load any video: "Option refcounted_frames not found" error (removed from FFmpeg)

[Diederik de Haas]

On Mon, 26 Sep 2022 21:40:03 -0700 Cy Kyanos  wrote:
> Package: subtitlecomposer
> Version: 0.7.1-3
> Severity: grave
> Tags: fixed-upstream patch
> Justification: renders package unusable
> Forwarded: https://invent.kde.org/multimedia/subtitlecomposer/-/issues/68

I can confirm this issue exists, although I don't think it's 'grave' as I 
haven't used this functionality before, but do use subtitlecomposer 
on a regular basis.

I've created a MR to add the patch to the Debian package here:
https://salsa.debian.org/qt-kde-team/extras/subtitlecomposer/-/merge_requests/1/diffs

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

Bug#1021315: Linux kernel very slow to boot

[eHenry Berg]

Package: linux-image-5.19.0-2-arm64
Version: 5.19.0-2

Computer:   Raspberry Pi 3b
Environment:Debian Unstable arm64
uname -a:   Linux atlas 5.19.0-2-arm64 #1 SMP Debian 5.19.11-1
(2022-09-24) aarch64 GNU/Linux

2022-07-26 If I have noted right, the slowness began when I upgraded
linux version from 5.18.0-2 to 5.18.0-3.
2022-10-04 I updated firmware from 2019-08-18 to 2022-10-04 (from
master). Still very slow to boot.

# cat /boot/firmware/cmdline.txt
dwc_otg.lpm_enable=0 console=tty0 root=/dev/mmcblk0p3 rootfstype=f2fs
elevator=deadline fsck.repair=yes rootwait cma=416M

# cat /boot/firmware/config.txt
arm_64bit=1
#device_tree=bcm2837-rpi-3-b-plus.dtb.5.19
device_tree=bcm2837-rpi-3-b.dtb.5.19
kernel=vmlinuz-5.19.0-2-arm64
initramfs initrd.img-5.19.0-2-arm64 followkernel

# cat /etc/initramfs-tools/modules
crc32
crc32c
f2fs

# cat /etc/modules
vc4

# cat /etc/dphys-swapfile
CONF_SWAPSIZE=1024

# cat /etc/fstab
#
proc/proc   procdefaults  0   0
/dev/mmcblk0p1  /boot/firmware  vfatnoauto,noatime0   2
/dev/mmcblk0p2  /boot   ext2defaults,noatime  0   0
/dev/mmcblk0p3  /   f2fsdefaults,noatime  0   0

# cat /etc/apt/sources.list
deb http://ftp.fi.debian.org/debian sid main contrib non-free

# systemd-analyze time
Startup finished in 5min 50.088s (kernel) + 21.179s (userspace) = 6min 11.268s
graphical.target reached after 21.110s in userspace.

# dmesg -T > dmesg_5.19.0-2.txt
I attach the whole file dmesg_5.19.0-2.txt.

dmesg_5.19.0-2.txt:
[Wed Oct  5 15:49:10 2022] rc rc0: vc4 as
/devices/platform/soc/3f902000.hdmi/rc/rc0
[Wed Oct  5 15:49:10 2022] input: vc4 as
/devices/platform/soc/3f902000.hdmi/rc/rc0/input14
[Wed Oct  5 15:54:48 2022] F2FS-fs (mmcblk0p3): recover fsync data on
readonly fs
[Wed Oct  5 15:54:48 2022] F2FS-fs (mmcblk0p3): Mounted with
checkpoint version = 1ba098

Why is it delayed from clock 15:49:10 to 15:54:48 in dmesg?

The kernel boot time has been fast for years. The kernel startup time
has been around 10 seconds and now it is almost 6 minutes.

Best Regards,
Evald
[Wed Oct  5 15:48:59 2022] Booting Linux on physical CPU 0x00 
[0x410fd034]
[Wed Oct  5 15:48:59 2022] Linux version 5.19.0-2-arm64 
(debian-ker...@lists.debian.org) (gcc-11 (Debian 11.3.0-6) 11.3.0, GNU ld (GNU 
Binutils for Debian) 2.39) #1 SMP Debian 5.19.11-1 (2022-09-24)
[Wed Oct  5 15:48:59 2022] random: crng init done
[Wed Oct  5 15:48:59 2022] Machine model: Raspberry Pi 3 Model B Rev 1.2
[Wed Oct  5 15:48:59 2022] efi: UEFI not found.
[Wed Oct  5 15:48:59 2022] Reserved memory: bypass linux,cma node, using 
cmdline CMA params instead
[Wed Oct  5 15:48:59 2022] OF: reserved mem: node linux,cma compatible matching 
fail
[Wed Oct  5 15:48:59 2022] NUMA: No NUMA configuration found
[Wed Oct  5 15:48:59 2022] NUMA: Faking a node at [mem 
0x-0x3b3f]
[Wed Oct  5 15:48:59 2022] NUMA: NODE_DATA [mem 0x3b20d940-0x3b20]
[Wed Oct  5 15:48:59 2022] Zone ranges:
[Wed Oct  5 15:48:59 2022]   DMA  [mem 
0x-0x3b3f]
[Wed Oct  5 15:48:59 2022]   DMA32empty
[Wed Oct  5 15:48:59 2022]   Normal   empty
[Wed Oct  5 15:48:59 2022] Movable zone start for each node
[Wed Oct  5 15:48:59 2022] Early memory node ranges
[Wed Oct  5 15:48:59 2022]   node   0: [mem 
0x-0x3b3f]
[Wed Oct  5 15:48:59 2022] Initmem setup node 0 [mem 
0x-0x3b3f]
[Wed Oct  5 15:48:59 2022] On node 0, zone DMA: 19456 pages in unavailable 
ranges
[Wed Oct  5 15:48:59 2022] cma: Reserved 416 MiB at 0x1260
[Wed Oct  5 15:48:59 2022] percpu: Embedded 30 pages/cpu s83176 r8192 d31512 
u122880
[Wed Oct  5 15:48:59 2022] pcpu-alloc: s83176 r8192 d31512 u122880 alloc=30*4096
[Wed Oct  5 15:48:59 2022] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 
[Wed Oct  5 15:48:59 2022] Detected VIPT I-cache on CPU0
[Wed Oct  5 15:48:59 2022] CPU features: kernel page table isolation forced ON 
by KASLR
[Wed Oct  5 15:48:59 2022] CPU features: detected: Kernel page table isolation 
(KPTI)
[Wed Oct  5 15:48:59 2022] CPU features: detected: ARM erratum 843419
[Wed Oct  5 15:48:59 2022] CPU features: detected: ARM erratum 845719
[Wed Oct  5 15:48:59 2022] Fallback order for Node 0: 0 
[Wed Oct  5 15:48:59 2022] Built 1 zonelists, mobility grouping on.  Total 
pages: 238896
[Wed Oct  5 15:48:59 2022] Policy zone: DMA
[Wed Oct  5 15:48:59 2022] Kernel command line: video=HDMI-A-1:1920x1080M@60 
dma.dmachans=0x7ff5 bcm2709.boardrev=0xa02082 bcm2709.serial=0x3f3d54e2 
bcm2709.uart_clock=4800 smsc95xx.macaddr=B8:27:EB:3D:54:E2 
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000  dwc_otg.lpm_enable=0 
console=tty0 root=/dev/mmcblk0p3 rootfstype=f2fs elevator=deadline 
fsck.repair=yes rootwait cma=416M
[Wed Oct  5 15:48:59 2022] Kernel parameter elevator= does not have any effect 
anymore.
   Please use sysfs to set IO scheduler for in

Bug#1021314: hol88: license issues

[Bastian Germann]

Source: hol88
Severity: serious
Version: 2.02.19940316-35.1

hol88 has one certain license issue: It bundles an old copy of NOWEB, which has 
a non-free license.
Please repack so that NOWEB is not included.

Furthermore, the license of hol88 might be non-free as well. debian/copyright claims it is public domain, which might 
not necessarily be true. There is a license included in License/{READ-ME,License.tex}. Please check carefully if this 
can stay in main at all.

Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1

[Gabriel Corona]

Le 05/10/2022 à 08:56, Gabriel Corona a écrit :
I collected some stack traces and apparently the problem happens in 
libcanberra-pulse :


If anyone else is affected by this bug, I guess uninstalling the 
libcanberra-pulse package should fix the problem.


Gabriel

Bug#1021301: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt

[Ansgar]

Control: retitle -1 grub-pc: use persistent disk identifier stored in 
configuration file
Control: affects -1 - release.debian.org

[ Cc'ed -release@ to notify them it's not a regression after all ]

On Wed, 05 Oct 2022 10:27:29 +0200 Ansgar wrote:
> On Wed, 2022-10-05 at 09:48 +0200, Ansgar wrote:
> > the upgrade to grub-pc 2.06-3~deb11u2 fails:
> > 
> > +---
> > > Setting up grub-pc (2.06-3~deb11u2) ...
> > > Installing for i386-pc platform.
> > > grub-install: warning: this GPT partition label contains no BIOS
> > > Boot Partition; embedding won't be possible.
> > > grub-install: error: embedding is not possible, but this is
> > > required for cross-disk install.
> > > You must correct your GRUB install devices before proceeding:
> > > 
> > >   DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
> > >   dpkg --configure -a
> > > dpkg: error processing package grub-pc (--configure):
> > >  installed grub-pc package post-installation script subprocess
> > > returned error exit status 1
> > > Errors were encountered while processing:
> > >  grub-pc
> > > Log ended: 2022-09-23  06:09:42
> > +---
> [...]
> > /dev/sda uses GPT and has one partition /dev/sda1; it was created
> > this way by d-i (though it has the setting to use gpt enabled).
> 
> Ah, but this was a distraction: /dev/sda isn't the boot device. The
> boot device is currently /dev/sdb. That still has a DOS disk label; the
> systems using GPT for the boot device as well have a small 1M partition
> for BIOS boot.
> 
> So grub-install shouldn't try to install to /dev/sda, but I find
> nothing in /etc referencing /dev/sda at all (except for a comment in
> /etc/fstab). So I'm not sure why the system tries to install grub
> there.
> 
> I now also checked /var/log/installer/syslog and when installing the
> system /dev/sda and /dev/sdb were the other way around. And it looks
> like that was the case before the previous reboot as well.
> 
> So possibly one of the race conditions I read about? (FWIW, this is a
> VM running under VMware.)

>From some more investigation and chat on IRC:

- Currently the only place where the configuration where grub should be
installed is debconf, in particular grub-pc/install_devices.
This should be moved to a configuration file in /etc.

- grub should use a persistent device identifier instead of /dev/sda
and similar. Steve McIntyre said on #-devel:

| so we go to all the effort finding out the device details in a 
| sustainable way, then don't store it :facepalm:
| we should be using a persistent device identifier here
| and each time we run grub-install that should be re-resolved to a 
| /dev/*** reference
| for added cleverness, we should also warn users that disks have moved
| if we no longer find the disk(s) we expect to install ointo
| and prompt for an update
| so we pick up on disk replacement, etc.

I think one has to check that grub doesn't get confused as well: in my
case the device can be /dev/sda or /dev/sdb for Linux, but it should
always be (hd0) for grub.

Implementing this probably also requires changes to the grub-installer
package.

Ansgar

Bug#1021313: ITP: golang-github-aymanbagabas-go-osc52 -- Golang terminal ANSI OSC52 wrapper

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 
X-Debbugs-Cc: debian-de...@lists.debian.org, vil...@debian.org

* Package name: golang-github-aymanbagabas-go-osc52
  Version : 1.0.3-1
  Upstream Author : Ayman Bagabas 
* URL : https://github.com/aymanbagabas/go-osc52
* License : Expat
  Programming Lang: Go
  Description : Golang terminal ANSI OSC52 wrapper

  A terminal Go library to copy text to clipboard from anywhere.
  It does so using ANSI OSC52. The Copy() function defaults to
  copying text from terminals running locally.


  This package is a new B-D for golang-github-muesli-termenv.

Bug#987953: more info

[Roderich Schupp]

Hi,

the problem is the compile command:

/usr/bin/cc -I/<> -g -O2 ... -Wall -I
-I/usr/include/vte-2.91 -I/usr/include/glib-2.0 ...

The "-I" after "-Wall" gobbles up the following "-I/usr/include/vte-2.9" as
option value. This adds a non-existent directory to the include search path,
but gcc doesn't complain about this unless you run it with "-v".

The lone "-I" is also present in a successful build (w/pkg-config), cf.
https://buildd.debian.org/status/fetch.php?pkg=termit&arch=amd64&ver=3.1-2&stamp=1662940248&raw=0
but there the order of arguments for cc is different:

... Wall -I -pthread -I/usr/include/vte-2.91 ...

so that "-I" gobbles up "-pthread" instead which apparently causes no harm.

Cheers, Roderich

Bug#1020691: debos should depend on systemd-resolved

[Luca Boccassi]

On Wed, 5 Oct 2022 at 17:06, Michael Biebl  wrote:
>
> Am 05.10.22 um 16:08 schrieb Arnaud Rebillout:
> > On 05/10/2022 16:58, Christopher Obbard wrote:
> >> Hi Arnaud,
> >>
> >> Thanks for shedding the extra light. This is not a nice bug !
> >>
> >> I think we should ask the systemd maintainer if they'd accept a patch
> >> to make the enabling of systemd-resolved service a manual operation, or
> >> at least to split the binary into a separate package, something like
> >> systemd-standalone-resolved ?
> >
> >
> > Dear systemd maintainers,
> >
> > the packages fakemachine & debos (which uses fakemachine) are facing an
> > issue now that systemd-resolved was split in a separate package.
> >
> > For the background: fakemachine is a program that spawns a QEMU VM that
> > "mimics" the host. It does so mainly by mounting /usr from the host into
> > the VM, plus a few other bits from here and there. For the network to
> > work in the VM, it relies on systemd-networkd and systemd-resolved.
> > These programs need to be present on the host, so that they are
> > available in the VM.
> >
> > For more details, you can just run "fakemachine" in a shell, then "ps
> > fax | grep qemu" in another shell: you will see how fakemachine uses qemu.
> >
> > So far, the package fakemachine Depends on systemd, and that was enough.
> > Now with the split, and since we need systemd-resolved, we should make
> > fakemachine Depend on systemd-resolved as well. However, and if I
> > understand properly, installing systemd-resolved also *enables* it. A
> > user installing the package is saying: I want name resolution to be done
> > by systemd-resolved. Therefore it's not really suitable to put it in a
> > Depend or a Recommend. fakemachine only needs the code from
> > systemd-resolved (lib and binary, I suppose), but it definitely doesn't
> > want to enable it: this decision belongs to the user.
> >
> > Does that make sense so far?
>
> Not really, tbh. I think if you want to assemble a root/usr fs where you
> don't want do "disturb" the host system, I'd use a debootstrapped chroot
> but not the host fs.
> Say you want to install apache2 in your fakemachine managed VM, this
> would also start it on the host system, or not?
> I don't know why fakemachine does it this way and it's possible I'm
> missing something, but this approache feels "weird" to me, for the lack
> of a better word.

Indeed, and the approach should be the opposite - if you want the
binary but not to run it, then for that special case you should script
it to disable it. Enablement is done via postinst.

The semantics that we _want_ are that installing the package means
"use this as my resolver", i.e., the default is very much
intentionally that installing it also enables it, so that for the
supported case there's no manual step to do, it "just works" out of
the box. This is the approach that upstream recommends.

Kind regards,
Luca Boccassi

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

[Soren Stoutner]

On Wednesday, October 5, 2022 5:07:50 AM MST Agustin Martin wrote:
> El jue, 22 sept 2022 a las 21:30, Soren Stoutner
> One noticeable thing is that bdic generation  failed for some hunspell
> dicts I have installed

That’s concerning.

> ++ processing an_ES.aff
> [1003/125813.760330:FATAL:aff_reader.cc(305)] Did not find a space in 'y   
> i'. Trace/breakpoint trap

This is caused by line 90 of an_ES.aff:

REP yi

All the previous instances of REP in this file have a space between the two 
arguments.  This is the first one to use a tab.  Following line 90 both tabs 
and spaces are used.

I don’t know enough about the Hunspell file format to know what is expected.  
Is this an example of an incorrectly formatted .aff file or is this an example 
of qwebengine_convet_dict not knowing how to read appropriate Hunspell 
formatting?

> ++ processing ar.aff
> [1003/125813.796753:FATAL:aff_reader.cc(123)] We don't support the
> IGNORE command yet. This would change how we would insert things in
> our lookup table.

Based on this error message, it seems fairly obvious that 
qwebengine_convert_dict does not fully support the Hunspell format.  The line 
in question is 24142 from ar.aff which reads as follows:

IGNORE ٌٍَُِّْ

I will file an upstream bug to see if that can be corrected in some way, but I 
think I will wait until I have the answers to these other questions to decide 
if I should file one bug or three.

> ++ processing gl_ES.aff
> gl_ES.dic_delta not found.
> Reading gl_ES.aff
> Reading gl_ES.dic
> Serializing...
> Verifying...
> Word does not match!
>   Index:2126
>   Expected: Abū po:antropónimo
> is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_
> Ṣabiʾ_al_Battānī Actual:   Abū po:antropónimo
> is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_
> Ṣabiʾ_al_Battā ERROR converting, the dictionary does not check out OK.

I am not exactly sure what is causing this error, but I would assume that it 
is some mismatch between the .aff and the .dic files.  The line it appears to 
be 
complaining about is 2095 from gl_ES.dic, which reads as follows:

Abū po:antropónimo 
is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_Ṣabiʾ_al_Battānī

However, for some reason it is expecting the line to be shorter.

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

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

Bug#1021308: gitolite3: repository "disappears" after upgrade from 3.6.6-1 to 3.6.12-1

[David Bremner]

Control: tag -1 unreproducible

I've tagged this as unreproducible because I don't think there's a
recipe here that permits me to understand what the actual bug in
gitolite is.

Eventually I might find time to investigate it more myself, but if you
want to speed things up, you could provice a sequence of steps that
doesn't involve any private configuration.

BTW, upgrading directly from oldoldstable to stable without going
through oldstable is not supported in general. I don't know if this is
related to your issue, but you can try going to oldstable (3.6.11-2)
first.

It may also help to provide the correct version of all of the
information you say is wrong in the original report.

Bug#926424:

[Nicholas Brown]

This should address this:
https://salsa.debian.org/cloud-team/cloud-init/-/merge_requests/6

Bug#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[John David Anglin]

On 2022-10-05 11:11 a.m., Simon McVittie wrote:

It seems to be reliable on release architectures, including i386 which is
32-bit and s390x which is big-endian.

Seems to be a 32-bit big-endian issue as same fail occurs on powerpc but not 
ppc64 or ppc64el.
Possibly, wrong word in 64-bit type is being tested on hppa and powerpc.

Dave

--
John David Anglin  dave.ang...@bell.net

Bug#890550: parity situation

[Jeffrey Cliff]

so whereas
1) older versions of parity were subject to an ethereum-stealing bug
https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html
2) development got stuck, there was, for a time, a fork of parity
called 'feather'  but even that is no longer listed as one of the main
ethereum clients on
https://ethereum.org/en/developers/docs/nodes-and-clients/
3) there's no particular reason to prefer old-as-balls parity
especially considering (1)
4) the source code to parity is stored on a gitlab which doesn't even
allow the public access(!) unless they have a github account
5) at one point, some of the ethereum codebase (not sure if including
parity???) relicensed away from GPL3 and so now it's unclear if this
is even FLOSS anymore
6) i was the one who requested it in the first place, so that debian
could have an ethereum client
7) i've requested enough things

therefor
I'm closing this rfp and if someone else wants parity or one of its
forks they can file a new frp

Jeff Cliff
-- 

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

Bug#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[Simon McVittie]

Control: severity -1 normal
Control: tags -1 + help

On Wed, 05 Oct 2022 at 14:43:00 +, John David Anglin wrote:
> Justification: fails to build from source (but built successfully in the past)

hppa is not a release architecture, so FTBFS on hppa is not RC.

This test-case seems to have been failing on hppa around 75% of the time
since it was added. I don't know why it would do that, because this
test-case should be deterministic: it's inspecting a simulation of the
capabilitities info that we would have received from the kernel for a
particular input device, and running SDL's algorithm to guess what type
of input device it represents (keyboard, mouse, gamepad, etc.). When it
fails on hppa, the failure mode is that none of the bits representing a
device type get set.

It seems to be reliable on release architectures, including i386 which is
32-bit and s390x which is big-endian.

Non-release architecture porters are welcome to investigate why this
is going wrong on their favourite architecture, and if the root cause
turns out to be a bug in SDL, I'm sure upstream would appreciate a patch.

smcv

Bug#1020691: debos should depend on systemd-resolved

[Michael Biebl]

Am 05.10.22 um 16:08 schrieb Arnaud Rebillout:

On 05/10/2022 16:58, Christopher Obbard wrote:

Hi Arnaud,

Thanks for shedding the extra light. This is not a nice bug !

I think we should ask the systemd maintainer if they'd accept a patch
to make the enabling of systemd-resolved service a manual operation, or
at least to split the binary into a separate package, something like
systemd-standalone-resolved ?



Dear systemd maintainers,

the packages fakemachine & debos (which uses fakemachine) are facing an 
issue now that systemd-resolved was split in a separate package.


For the background: fakemachine is a program that spawns a QEMU VM that 
"mimics" the host. It does so mainly by mounting /usr from the host into 
the VM, plus a few other bits from here and there. For the network to 
work in the VM, it relies on systemd-networkd and systemd-resolved. 
These programs need to be present on the host, so that they are 
available in the VM.


For more details, you can just run "fakemachine" in a shell, then "ps 
fax | grep qemu" in another shell: you will see how fakemachine uses qemu.


So far, the package fakemachine Depends on systemd, and that was enough. 
Now with the split, and since we need systemd-resolved, we should make 
fakemachine Depend on systemd-resolved as well. However, and if I 
understand properly, installing systemd-resolved also *enables* it. A 
user installing the package is saying: I want name resolution to be done 
by systemd-resolved. Therefore it's not really suitable to put it in a 
Depend or a Recommend. fakemachine only needs the code from 
systemd-resolved (lib and binary, I suppose), but it definitely doesn't 
want to enable it: this decision belongs to the user.


Does that make sense so far?


Not really, tbh. I think if you want to assemble a root/usr fs where you 
don't want do "disturb" the host system, I'd use a debootstrapped chroot 
but not the host fs.
Say you want to install apache2 in your fakemachine managed VM, this 
would also start it on the host system, or not?
I don't know why fakemachine does it this way and it's possible I'm 
missing something, but this approache feels "weird" to me, for the lack 
of a better word.


Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021312: qtquickcontrols-opensource-src: FTBFS on hppa - Tests_TreeView::test_pressAndHold

[John David Anglin]

Source: qtquickcontrols-opensource-src
Version: 5.15.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Testsuite fails with following error:

PASS   : qtquickcontrols::Tests_TreeView::test_keys_navigation()
FAIL!  : qtquickcontrols::Tests_TreeView::test_pressAndHold() Compared values 
are not the same
   Actual   (): 0
   Expected (): 1
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(274)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_contiguousSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_extendedSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_multiSelection()
PASS   : qtquickcontrols::Tests_TreeView::test_selection_noSelection()
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(402)]
XFAIL  : qtquickcontrols::Tests_TreeView::test_selection_singleSelection() BUG 
selected state not updated with Command/Control when SingleSelection
   Loc: [/<>/tests/auto/controls/data/tst_treeview.qml(404)]
PASS   : qtquickcontrols::Tests_TreeView::test_selection_singleSelection()
PASS   : qtquickcontrols::Tests_TreeView::cleanupTestCase()
Totals: 498 passed, 1 failed, 6 skipped, 0 blacklisted, 410752ms
* Finished testing of qtquickcontrols *
make[5]: *** [Makefile:318: check] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=qtquickcontrols-opensource-src&arch=hppa&ver=5.15.6-2&stamp=1664978713&raw=0

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1021311: vlc: No sound with some AAC encoded MKV videos

[Miguel A. Vallejo]

Package: vlc
X-Debbugs-Cc: ea4...@gmail.com
Version: 3.0.17.4-5
Severity: important

Dear Maintainer,

I noticed VLC does not play sound from some videos. I noticed it with AAC
encoded audio in MKV files. Video just plays fine, but no audio.

The same video plays and sounds nicely with other players, like Dragon
player, mpv or ffplay.

This is (I think) the relevant output of vlc -vvv :

[hevc @ 0x7fa9b8c2bc40] Output frame with POC 0.
[hevc @ 0x7fa9b8c4b480] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8c4b480] nal_unit_type: 1(TRAIL_R), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8c4b480] Decoding SEI
[hevc @ 0x7fa9b8c4b480] Output frame with POC 1.
[hevc @ 0x7fa9b8e88580] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8e88580] nal_unit_type: 1(TRAIL_R), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8e88580] Decoding SEI
[hevc @ 0x7fa9b8e88580] Output frame with POC 2.
[hevc @ 0x7fa9b8f4aa00] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8f4aa00] nal_unit_type: 1(TRAIL_R), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8f4aa00] Decoding SEI
[hevc @ 0x7fa9b8f4aa00] Output frame with POC 3.
[hevc @ 0x7fa9b900cec0] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b900cec0] nal_unit_type: 1(TRAIL_R), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b900cec0] Decoding SEI
[hevc @ 0x7fa9b8c2bc40] Decoded frame with POC 0.
[7fa9b8c19980] main decoder debug: Received first picture
[hevc @ 0x7fa9b8c4b480] Decoded frame with POC 1.
[hevc @ 0x7fa9b8e88580] Decoded frame with POC 2.
[hevc @ 0x7fa9b900cec0] Output frame with POC 4.
[7fa9cc90] main input debug: Decoder wait done in 258 ms
[hevc @ 0x7fa9b8c2bc40] nal_unit_type: 39(SEI_PREFIX), nuh_layer_id: 0,
temporal_id: 0
[hevc @ 0x7fa9b8c2bc40] [556972927f00] pulse audio output debug:
deferring start (296073 us)
[556972927f00] pulse audio output debug: deferring start (232490 us)
[556972927f00] pulse audio output debug: deferring start (168491 us)
[556972927f00] pulse audio output debug: deferring start (104491 us)
[556972927f00] pulse audio output debug: deferring start (40491 us)
nal_unit_type: 1(TRAIL_R), nuh_layer_id: 0, temporal_id: 0
[hevc @ 0x7fa9b8f4aa00] Decoded frame with POC 3.
[hevc @ 0x7fa9b8c2bc40] Decoding SEI
[hevc @ 0x7fa9b900cec0] Decoded frame with POC 4.
[556972927f00] pulse audio output warning: starting late (-23509 us)
[556972927f00] pulse audio output debug: started
[556972927f00] pulse audio output debug: changing sink 1:
alsa_output.pci-_00_1f.3.analog-stereo (Audio Interno Estéreo analógico)
[556972927f00] main audio output warning: playback way too late
(230646): flushing buffers
[556972927f00] vlcpulse audio output debug: write index corrupt
[556972927f00] pulse audio output debug: cannot synchronize start
[556972927f00] pulse audio output debug: deferring start (152073 us)
[556972927f00] vlcpulse audio output debug: write index corrupt
[556972927f00] pulse audio output debug: cannot synchronize start
[556972927f00] pulse audio output debug: deferring start (151966 us)
[556972927f00] pulse audio output debug: deferring start (49693 us)
[556972927f00] pulse audio output debug: deferring start (49693 us)
[556972927f00] pulse audio output debug: deferring start (49693 us)
[556972927f00] pulse audio output debug: deferring start (49693 us)
[556972927f00] pulse audio output debug: changing sink 1:
alsa_output.pci-_00_1f.3.analog-stereo (Audio Interno Estéreo analógico)
[556972927f00] pulse audio output debug: deferring start (49693 us)
[556972927f00] pulse audio output warning: starting late (-14307 us)
[556972927f00] pulse audio output debug: started
[556972927f00] pulse audio output debug: changing sink 1:
alsa_output.pci-_00_1f.3.analog-stereo (Audio Interno Estéreo analógico)
[556972927f00] main audio output warning: playback too late (60231):
up-sampling
[556972927f00] main audio output warning: timing screwed (drift: 145565
us): stopping resampling
[556972927f00] main audio output warning: playback way too late
(188231): flushing buffers
[556972927f00] vlcpulse audio output debug: write index corrupt
[556972927f00] pulse audio output debug: cannot synchronize start
[556972927f00] pulse audio output debug: deferring start (294840 us)
[556972927f00] vlcpulse audio output debug: write index corrupt
[556972927f00] pulse audio output debug: cannot synchronize start
[556972927f00] pulse audio output debug: deferring start (294485 us)
[556972927f00] pulse audio output debug: deferring start (191256 us)
[556972927f00] pulse audio output debug: deferring start (191257 us)
[556972927f00] pulse audio output debug: deferring start (191256 us)
[556972927f00] pulse audio output debug: deferring start (191257 us)
[556972927f00] pulse audio output debug: c

Bug#951805: Help with glbinding

[Ghislain VAILLANT]

If you need sponsorship and access to the repo, feel free to request 
them to the Debian Science mailing list.


Cheers,
Ghis

Le dim., oct. 2 2022 at 22:04:07 +0200, Andrea Pappacoda 
 a écrit :
Il giorno dom 2 ott 2022 alle 20:54:01 +02:00:00, Ghislain Vaillant 
mailto:ghisv...@gmail.com>> ha scritto:
Feel free to assist with maintenance of any of my packages under the 
Debian science team umbrella.


You don't need to ask for permission 👍


Thanks for the fast reply, Ghislain! I'll start working on this in a 
few days. Would you be able to sponsor my first upload and/or grant 
me DM rights to the package? If you prefer, I can publish my changes 
in a Salsa fork so that you can take a look at them before trusting 
me too much :)


--
OpenPGP key: 66DE F152 8299 0C21 99EF  A801 A8A1 28A8 AB1C EE49

Bug#1021310: libsdl2: FTBFS on hppa - testevdev: FAILED: 1

[John David Anglin]

Source: libsdl2
Version: 2.24.0+dfsg-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Build fails in testsuite:

Thinkpad USB keyboard with Trackpoint - Trackpoint...
Expected 0x0003
MOUSE
KEYBOARD
Got  0x
No information...
OK
testevdev: FAILED: 1
testfilesystem...
INFO: base path: '/<>/debian/build-tests/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/libsdl/test_filesystem/'
INFO: pref path: 
'/<>/debian/.debhelper/generated/_source/home/.local/share/test_filesystem/'
testfilesystem: OK
...
testdisplayinfo: OK
make[2]: *** [Makefile:416: check] Error 1
make[2]: Leaving directory '/<>/debian/build-tests'
dh_auto_test: error: cd debian/build-tests && make -j4 check 
"TESTSUITEFLAGS=-j4 --verbose" VERBOSE=1 V=1 returned exit code 2
make[1]: *** [debian/rules:142: override_dh_auto_test-arch] Error 25
make[1]: Leaving directory '/<>'
make: *** [debian/rules:81: binary-arch] Error 2
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libsdl2&arch=hppa&ver=2.24.1%2Bdfsg-1&stamp=1664977752&raw=0

Similar fail occurs on powerpc.

Regards,
Dave Anglin

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.19.13+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1020691: debos should depend on systemd-resolved

[Arnaud Rebillout]

On 05/10/2022 16:58, Christopher Obbard wrote:

Hi Arnaud,

Thanks for shedding the extra light. This is not a nice bug !

I think we should ask the systemd maintainer if they'd accept a patch
to make the enabling of systemd-resolved service a manual operation, or
at least to split the binary into a separate package, something like
systemd-standalone-resolved ?



Dear systemd maintainers,

the packages fakemachine & debos (which uses fakemachine) are facing an 
issue now that systemd-resolved was split in a separate package.


For the background: fakemachine is a program that spawns a QEMU VM that 
"mimics" the host. It does so mainly by mounting /usr from the host into 
the VM, plus a few other bits from here and there. For the network to 
work in the VM, it relies on systemd-networkd and systemd-resolved. 
These programs need to be present on the host, so that they are 
available in the VM.


For more details, you can just run "fakemachine" in a shell, then "ps 
fax | grep qemu" in another shell: you will see how fakemachine uses qemu.


So far, the package fakemachine Depends on systemd, and that was enough. 
Now with the split, and since we need systemd-resolved, we should make 
fakemachine Depend on systemd-resolved as well. However, and if I 
understand properly, installing systemd-resolved also *enables* it. A 
user installing the package is saying: I want name resolution to be done 
by systemd-resolved. Therefore it's not really suitable to put it in a 
Depend or a Recommend. fakemachine only needs the code from 
systemd-resolved (lib and binary, I suppose), but it definitely doesn't 
want to enable it: this decision belongs to the user.


Does that make sense so far?

I don't know how to solve best this situation. Maybe the the lib and 
binaries could go back into the systemd package, leaving only the 
"enablement" part in systemd-resolved?


Thanks!

--
Arnaud Rebillout / Offensive Security / Kali Linux Developer

Bug#1020697: nvidia-alternative fails update

[Marc Glisse]

On Wed, 5 Oct 2022, Riccardo Gagliarducci wrote:


I think I have, on bookworm, a related or similar bug/problem to the one
highlighted here.


See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020761 . A new
version was uploaded today, you need to give it a few days for it to
build, migrate to testing, propagate to mirrors, etc.

--
Marc Glisse

Bug#1020765: Does Debian 11.x 32 bit support NVDIMM?

[Adam Borowski]

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

On Tue, Oct 04, 2022 at 05:57:12PM +, Williams, Dan J wrote:
> On Mon, 26 Sep 2022 08:26:56 + Winnie Yue  wrote:
> > Package: ndctl
> > Version: 71.1-1
> > Severity: serious

> > For Debian 11.5 32 bit, I got below info:
> > But I found that Debian 11.5 32 bit vm couldn’t recognize the NVDIMM device:
> > # dmesg | grep -i bios-e820 | grep persistent
> > [ 0.00] BIOS-e820: [mem 0x00024000-0x00043fff] 
> > persistent (type 7)
> 
> Note that this is not sufficient for advertising NVDIMM resources.  A
> Type-7 memory range still requires an ACPI NFIT to advertise the memory
> range.

Thanks Dan for this bit, I've missed it.

Winnie: please try passing the proper ACPI data; your email address suggests
that your VM is one I don't know how to operate.

> That said, why are you trying to run a 32-bit environment.  If you need a
> 32-bit userspace you can still use a 64-bit kernel.  32-bit x86 is not
> well looked after by the kernel community in general these days.

That's another point; time spent validating a 32-bit kernel isn't that
useful.  I was really shocked it can use NVDIMM at all.  In the userland,
you can't count on the stack other than the very lowest level (ie, ndctl).


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ It's time to migrate your Imaginary Protocol from version 4i to 6i.
⢿⡄⠘⠷⠚⠋⠀
⠈⠳⣄

Bug#1019854: firmware-nonfree: Please consider to update this package and its binaries

[Michael Meier]

Package: firmware-linux-nonfree
Version: 20210818-1
Followup-For: Bug #1019854
X-Debbugs-Cc: schissdra...@rmm.li

I support this request. It's way too much work to get debian testing/unstable
working on new Hardware, since way too many firmwares are missing.
Took me forever to get the installer find at least the wifi firmware.


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

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

Versions of packages firmware-linux-nonfree depends on:
ii  firmware-amd-graphics  20210818-1
ii  firmware-misc-nonfree  20210818-1

Versions of packages firmware-linux-nonfree recommends:
pn  amd64-microcode  
ii  intel-microcode  3.20220809.1

firmware-linux-nonfree suggests no packages.

-- no debconf information

Bug#1021249: new upstream version required

[Daniel Baumann]

Hi,

I've took the liberty to upload a NMU to delayed 5, diff is attached:

  * If you're ok with the diff, I would be happy to cancel it and upload
directly to unstable.
  * If you're not ok with the diff, I'm happy to cancel the upload and
let you do it.

Regards,
Danieldiff -Naurp psycopg3-3.0.1-1/debian/changelog psycopg3-3.1.3-0.1/debian/changelog
--- psycopg3-3.0.1-1/debian/changelog	2022-04-19 18:24:23.0 +
+++ psycopg3-3.1.3-0.1/debian/changelog	2022-10-05 13:04:30.264758092 +
@@ -1,3 +1,13 @@
+psycopg3 (3.1.3-0.1) unstable; urgency=medium
+
+  * Non-maintainer source-only upload (Closes: #1014833).
+  * Updating to current upstream as needed by pgcli (Closes: #1021249):
+- rediffing change-Sphinx-theme.patch.
+- rediffing use-local-documentation.patch.
+- adding newly required python3-typing-extensions to build-depends.
+
+ -- Daniel Baumann   Wed, 05 Oct 2022 10:48:22 +0200
+
 psycopg3 (3.0.1-1) unstable; urgency=medium
 
   * Initial release (Closes: #995447).
diff -Naurp psycopg3-3.0.1-1/debian/control psycopg3-3.1.3-0.1/debian/control
--- psycopg3-3.0.1-1/debian/control	2021-10-26 19:12:58.0 +
+++ psycopg3-3.1.3-0.1/debian/control	2022-10-05 13:05:14.02472 +
@@ -12,7 +12,8 @@ Build-Depends:
  python3-pytest ,
  python3-dnspython ,
  python3-shapely ,
- python3-tenacity 
+ python3-tenacity ,
+ python3-typing-extensions,
 Build-Depends-Indep:
  python3-doc ,
  python-psycopg2-doc ,
diff -Naurp psycopg3-3.0.1-1/debian/patches/change-Sphinx-theme.patch psycopg3-3.1.3-0.1/debian/patches/change-Sphinx-theme.patch
--- psycopg3-3.0.1-1/debian/patches/change-Sphinx-theme.patch	2021-10-26 19:12:58.0 +
+++ psycopg3-3.1.3-0.1/debian/patches/change-Sphinx-theme.patch	2022-10-05 11:20:31.833502894 +
@@ -3,17 +3,18 @@ Description: Change generated Sphinx doc
 Forwarded: not-needed
 Author: Tomasz Rybak 
 Last-Update: 2021-10-17
-Index: psycopg3-3.0.1/docs/conf.py
-===
 psycopg3-3.0.1.orig/docs/conf.py
-+++ psycopg3-3.0.1/docs/conf.py
-@@ -75,17 +75,17 @@ pygments_style = "tango"
+
+diff -Naurp psycopg3.orig/docs/conf.py psycopg3/docs/conf.py
+--- psycopg3.orig/docs/conf.py
 psycopg3/docs/conf.py
+@@ -75,18 +75,18 @@ pygments_style = "tango"
  
  # The theme to use for HTML and HTML Help pages.  See the documentation for
  # a list of builtin themes.
 -html_theme = "furo"
 +html_theme = "alabaster"
- html_show_sphinx = False
+ html_show_sphinx = True
+ html_show_sourcelink = False
 -html_theme_options = {
 -"announcement": announcement,
 -"sidebar_hide_name": False,
diff -Naurp psycopg3-3.0.1-1/debian/patches/use-local-documentation.patch psycopg3-3.1.3-0.1/debian/patches/use-local-documentation.patch
--- psycopg3-3.0.1-1/debian/patches/use-local-documentation.patch	2021-10-26 19:12:58.0 +
+++ psycopg3-3.1.3-0.1/debian/patches/use-local-documentation.patch	2022-10-05 13:02:03.724863329 +
@@ -3,11 +3,11 @@ Description: Ensure reproducible documen
 Forwarded: not-needed
 Author: Tomasz Rybak 
 Last-Update: 2021-10-17
-Index: psycopg3-3.0.1/docs/conf.py
-===
 psycopg3-3.0.1.orig/docs/conf.py
-+++ psycopg3-3.0.1/docs/conf.py
-@@ -96,8 +96,10 @@ html_static_path = ["_static"]
+
+diff -Naurp psycopg3.orig/docs/conf.py psycopg3/docs/conf.py
+--- psycopg3.orig/docs/conf.py
 psycopg3/docs/conf.py
+@@ -97,8 +97,10 @@ html_static_path = ["_static"]
  default_role = "obj"
  
  intersphinx_mapping = {
@@ -20,25 +20,26 @@ Index: psycopg3-3.0.1/docs/conf.py
  }
  
  autodoc_member_order = "bysource"
-Index: psycopg3-3.0.1/docs/lib/libpq_docs.py
-===
 psycopg3-3.0.1.orig/docs/lib/libpq_docs.py
-+++ psycopg3-3.0.1/docs/lib/libpq_docs.py
-@@ -7,6 +7,8 @@ Add the ``:pq:`` role, to create a link
+diff -Naurp psycopg3.orig/docs/lib/libpq_docs.py psycopg3/docs/lib/libpq_docs.py
+--- psycopg3.orig/docs/lib/libpq_docs.py
 psycopg3/docs/lib/libpq_docs.py
+@@ -6,7 +6,8 @@ Add the ``:pq:`` role, to create a link
+ :pq:`PQlibVersion()`
  
  will link to::
- 
+-
 +file:///usr/share/doc/postgresql-doc-13/html/libpq-misc.html #LIBPQ-PQLIBVERSION
 +previously to:
  https://www.postgresql.org/docs/current/libpq-misc.html #LIBPQ-PQLIBVERSION
  
  """
-@@ -81,7 +83,7 @@ class LibpqParser(HTMLParser):
- )
+@@ -89,8 +90,7 @@ class LibpqReader:
+ app = None
  
  _url_pattern = (
--"https://www.postgresql.org/docs/{version}/{section}.html#{func_id}";
+-"https://raw.githubusercontent.com/postgres/postgres/REL_{ver}_STABLE";
+-"/doc/src/sgml/libpq.sgml"
 +"file:///usr/share/doc/postgresql-doc-{version}/html/{section}.html#{func_id}"
  )
  
- 
+ data = None

Bug#1014815: kiwipy initial packaging

[Bastian Germann]

Am 05.10.22 um 14:59 schrieb Guilherme Xavier:

Hi,

Agree, downgrading would be an option.
I don't know how this can be done, but I'm open to doing it.


You import the older version as 8.1.1+really6.8.1-1


I believe we have no other use of this package apart from kiwipy.

Em ter., 4 de out. de 2022 às 15:21, Bastian Germann  escreveu:


Am 04.10.22 um 20:20 schrieb Guilherme de Paula Xavier Segundo:

Yes,
I believe it is the best solution. If there is any other suggestion
I am available.


Another solution would be downgrading. Is the package used by something else in 
the archive?

Bug#1014815: kiwipy initial packaging

[Guilherme Xavier]

Hi,

Agree, downgrading would be an option.
I don't know how this can be done, but I'm open to doing it.

I believe we have no other use of this package apart from kiwipy.

Em ter., 4 de out. de 2022 às 15:21, Bastian Germann  escreveu:
>
> Am 04.10.22 um 20:20 schrieb Guilherme de Paula Xavier Segundo:
> > Yes,
> > I believe it is the best solution. If there is any other suggestion
> > I am available.
>
> Another solution would be downgrading. Is the package used by something else 
> in the archive?
>


-- 
Guilherme de Paula Xavier Segundo
GPG: 4096R/976B8AC9
GPG Fingerprint: 1808D92674863C2E07B7B08C1B140644976B8AC9

Bug#1020323: debian-policy: document DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Russ,

thank you for your explanations, things are quite a bit clearer now.

Quoting Russ Allbery (2022-09-20 05:47:45)
> The point of putting this in Policy is to provide guidance to the
> packagers, not to the bootstrappers.  Presumably you already have other
> documentation that you maintain about how to bootstrap Debian that spells
> out what to do in what order; that's outside of Policy's remit.  What
> Policy is trying to do is to define for packagers what interface they have
> to implement, and DPKG_ROOT is now part of that interface.
> 
> So in other words, you can just say something like:
> 
> Maintainer scripts in essential or build-essential packages must
> preface all paths they act on in maintainer scripts with an expansion
> of the DPKG_ROOT environment variable.  This will normally be empty
> (and thus normally will not change anything), but in some situations
> it may be set to a bootstrapping path to tell packages to act under
> that path instead of on the root file system.
> 
> That wording probably isn't quite right, but I think that's the general
> idea.

okay, if you think this should be a new section, then let me try to come up
with a text here.

   To enable creating a foreign architecture Debian chroot during the early
   bootstrap of a new Debian architecture, maintainer scripts and utilities
   called by maintainer scripts of packages in the essential and
   build-essential set, should support operating on a custom chroot directory.
   This is to avoid running any of the foreign architecture utilities from the
   chroot, because those cannot be executed during the early bootstrapping
   phase of a new architecture.  Instead, by avoiding the chroot() call,
   utilities from the outside should operate on the chroot path given via the
   `DPKG_ROOT` environment variable.  This environment variable is set but
   empty during normal package installations.  If the `DPKG_ROOT` environment
   variable is not empty, then this indicates to the maintainer scripts and the
   tools it executes, that a chroot is being built as part of an early
   architecture bootstrap and all operations should be performed in the chroot
   path given by the contents of the `DPKG_ROOT` environment variable. In that
   case, the maintainer script should not modify anything outside the chroot
   directory.

I refrained from using "must" because we promised maintainers that they would
not need to do the work themselves but will get patches sent from us. We do not
want to force work on maintainers by making it an RC bug if they do not support
DPKG_ROOT.

Helmut, what do you think?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT

[Johannes Schauer Marin Rodrigues]

Hi Steve,

Quoting Steve Langasek (2022-09-09 07:09:32)
> My feedback to you on IRC was that I think it's inappropriate for you to go
> package-by-package in the BTS to the packages in the base set expecting
> support for a feature that has to my knowledge never been surfaced for
> project-wide discussion on debian-devel or similar.
> 
> So if you want to take that discussion to the Technical Committee to ratify
> as something that base packages must support, well, I don't think that's the
> best use of the TC vs just starting a thread on debian-devel,

I agree that this is not the best use of the TC's time. Since we both agree on
that and since it has been more than three weeks since our post to d-devel [1]
without any concerns or otherwise negative feedback, do you still want to wait
for the TC to decide or do you want to cut it short by applying our patch?

[1] https://lists.debian.org/166289720850.2390.3729551131862514967@localhost

> but it does satisfy my expectation that there be a project-level review of
> the design prior to obligating base package maintainers to support this
> feature.

We are working on some changes to Debian policy in #1020323 but we are not
planning to put any "must" statements in the text. Our intention is not to
obligate anybody to do anything other than apply reasonable patches that we
provide. If it breaks, it is not your responsibility to fix it. Since the
DPKG_ROOT variable is empty during normal installations I hope you agree that
our patch will not be able to introduce any bugs during normal package
installation. If the chrootless bootstrapping should fail in the future, it is
not the obligation of package maintainers to fix it. We have said so multiple
times in the past already...

josch

signature.asc
Description: signature

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

[Agustin Martin]

El jue, 22 sept 2022 a las 21:30, Soren Stoutner
() escribió:
>
> On Thursday, September 22, 2022 9:20:46 AM MST Agustin Martin wrote:
>
> > First of all, I am curious about the reasons behind this new format,
> > the problems it deals with and its advantages. I assume they are valid
> > enough, but they imply yet another spellchecking engine/format. We
> > currently have goog old ispell, aspell and hunspell. vim has its own
> > spellchecker engine using its own format, with dicts that can be
> > created from old myspell2 dicts. We did not add vim format dicts (from
> > aspell dicts sources) since there seems to be some work to make vim
> > use hunspell directly. And now these bdict dicts.
>
> The .bdic format is specified by the upstream Chromium project, and is 
> required by anything that is based off of Chromium's code, like Qt WebEngine. 
>  I do not know why they went with a proprietary binary format, but I would 
> assume that if they went to so much trouble to not use the standard Hunspell 
> format there must have been something to make it worthwhile, like some 
> performance improvement.  Perhaps I am giving Google too much credit for 
> having logical reasons instead of making arbitrary decisions.

Hi, Soren

It s a pity not to have more info about the reasons for this new
format. Even if using it is more effficient in terms of plain
performance, I do not think that is noticeable in stuff like chromium.

Another question is whether that bdic format is expected to change or
that is very unlikely.

Thinking about this, I have done some tests about these bdic files
being generated at postinst, like emacs byte-compiled files (although
my tests were  more rude), delegating everything to the qtwebengine
packages. . bdic generation is not very slow, but IMHO is not fast
enough to go this way (which woud require moving
qwebengine_convert_dic to Qt WebEngine runtime package and control
everything from it).

One noticeable thing is that bdic generation  failed for some hunspell
dicts I have installed

++ processing an_ES.aff
[1003/125813.760330:FATAL:aff_reader.cc(305)] Did not find a space in 'yi'.
Trace/breakpoint trap
++ processing ar.aff
[1003/125813.796753:FATAL:aff_reader.cc(123)] We don't support the
IGNORE command yet. This would change how we would insert things in
our lookup table.
++ processing gl_ES.aff
gl_ES.dic_delta not found.
Reading gl_ES.aff
Reading gl_ES.dic
Serializing...
Verifying...
Word does not match!
  Index:2126
  Expected: Abū po:antropónimo
is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_Ṣabiʾ_al_Battānī
  Actual:   Abū po:antropónimo
is:ngrama_Abū_ʿAbdullāh_Muḥammad_ibn_Jābir_ibn_Sinān_ar_Raqqī_al_Ḥarrani_aṣ_Ṣabiʾ_al_Battā
ERROR converting, the dictionary does not check out OK.

Regards,

-- 
Agustin

Bug#1021309: add support for ed25519

[Daniel Baumann]

Package: monkeysphere
Severity: wishlist

Hi Daniel,

thank you for monkeysphere.. I'm trying to migrate my debian key to
ed255519 - however, when I gave it another try with monkeysphere,
unfortunately I didn't work (using pem2openpgp).

It would be nice if this could be added.

Regards,
Daniel

Bug#1021308: gitolite3: repository "disappears" after upgrade from 3.6.6-1 to 3.6.12-1

[lkcl]

Package: gitolite3
Version: 3.6.12-1
Severity: important

please note this bugreport is for a completely different system from the
one on which it is reported: please *IGNORE* the system information below

an upgrade on libre-soc.org to 3.6.12-1 resulted in just one of the
repositories disappearing after a cosmetic change to the gitolite.conf
file.  there are over 60 repositories on that server, and there is
cross-integration with ikiwiki

the only one that disappeared was the one to which ikiwiki has to have
write-permission

the group-perms for the wiki.git are www-data and group-set (rwxrwsrxx)

however...

changing those permissions to gitolite3 (which would have destroyed
ikiwiki's ability to commit to the repo back-end as www-data)
did not "fix" the problem and gitolite3 ultimately had to be
reverted to 3.6.6-1


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1

[Gabriel Corona]

Hi Dylan,

I reported this issue to pipewire:

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2745

Regards,

Gabriel

Bug#1021032: VLC Black screen

[Miguel A. Vallejo]

Thank you. I'll open a new bug.

By the way, once updated to the new VLC version (3.0.17.4-5) in a fully
updated Sid I noticed after seeing a few videos the player goes black again
and nothing until a reboot is issued.

Anyone else noticed this?

Bug#1020966: anacron: after update anacron.service is disabled

[Gábor Gombás]

Package: anacron
Version: 2.3-35
Followup-For: Bug #1020966

Hi,

This happened here as well:

diff --git a/systemd/system/multi-user.target.wants/anacron.service 
b/systemd/system/multi-user.target.wants/anacron.service
deleted file mode 12
index 18167769..
--- a/systemd/system/multi-user.target.wants/anacron.service
+++ /dev/null
@@ -1 +0,0 @@
-/lib/systemd/system/anacron.service
\ No newline at end of file
diff --git a/systemd/system/timers.target.wants/anacron.timer 
b/systemd/system/timers.target.wants/anacron.timer
deleted file mode 12
index 0acf85ee..
--- a/systemd/system/timers.target.wants/anacron.timer
+++ /dev/null
@@ -1 +0,0 @@
-/lib/systemd/system/anacron.timer
\ No newline at end of file

Regards,
Gabor

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'stable-security'), (103, 'testing'), (102, 'unstable'), (101, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.12-1-g6b8ac68e5f67 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages anacron depends on:
ii  libc6 2.35-1
ii  lsb-base  11.2

Versions of packages anacron recommends:
ii  cron [cron-daemon]  3.0pl1-150

Versions of packages anacron suggests:
ii  postfix [mail-transport-agent]  3.6.4-1+b3
ii  powermgmt-base  1.37
ii  syslog-ng-core [system-log-daemon]  3.35.1-1+b2

-- no debconf information

Bug#1021307: irssi-plugin-rocketchat: Please add README.md to irssi-plugin-rocketchat

[Nicolas Schier]

Package: irssi-plugin-rocketchat
Version: 0.6.0-1
Severity: wishlist

Dear Rhonda,

can you please add README.md to the binary package?  It was quite helpful for
me for the initial irssi setup.

Thanks and kind regards,
Nicolas

Bug#1021306: irssi-plugin-rocketchat: Please add libwebsockets-evlib-glib (or comparable?) as dependency

[Nicolas Schier]

Package: irssi-plugin-rocketchat
Version: 0.6.0-1
Severity: normal

Dear Rhonda,

on my system, I had to install libwebsockets-evlib-glib; otherwise I saw only

  11:30 LWS: 4.1.6-, loglevel 1031
  11:30 
  11:30 NET CLI SRV H1 H2 WS IPV6-on
  11:30 
  11:30 lws_create_context: unable to load evlib plugin evlib_glib
  11:30 
  11:30 ::: Unable to connect server chat.avm.de port 443 lws init failed

when attempting to connect to the configured rocketchat network.  Installing 
libwebsockets-evlib-glib (4.1.6-3) from testing/unstable leads to messages like:

  11:31 LWS: 4.1.6-, loglevel 1031
  11:31 
  11:31 NET CLI SRV H1 H2 WS IPV6-on
  11:31 
  11:31/usr/lib/aarch64-linux-gnu/libwebsockets-evlib_glib.so
  11:31 
  11:31 Unhandled lws callback reason: 19
  11:31 Unhandled lws callback reason: 58
  11:31 Unhandled lws callback reason: 58
  11:31 Unhandled lws callback reason: 58
  11:31 Unhandled lws callback reason: 44
  11:31 ::: Connection to chat.myrocketchat.domain established

and usable rocketchat connection.

Thanks for packaging irssi-plugin-rocketchat!

Kind regards,
Nicolas


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

Kernel: Linux 5.17.0-rc2+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
nb_NO.UTF-8), LANGUAGE=C.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages irssi-plugin-rocketchat depends on:
ii  libc62.34-7
ii  libglib2.0-0 2.72.3-1+b1
ii  libjansson4  2.14-2
ii  libwebsockets17  4.1.6-3

irssi-plugin-rocketchat recommends no packages.

irssi-plugin-rocketchat suggests no packages.

-- no debconf information

Bug#1021305: tryton-server french translation

[bubub]

Package: tryton-server
Severity: wishlist
Tags: patch l10n

  Dear Mainteners,

  Hello,
   please find the updated french translation for tryton-server
attached, proofread by the debian-l10n-french contributors.

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

 Kind regards,
  bubu

fr.po.xz
Description: application/xz

Bug#1021298: debian/bullseye64 vagrant box does not boot if there is no video card present

[Evgeni Golov]

On Wed, Oct 05, 2022 at 08:31:58AM +0200, Evgeni Golov wrote:
> As a workaround, manually adding a  section to the XML, or making
> libvirt call QEMU otherwise with `-device cirrus-us,id=video0` works,
> but is clearly not how it was intended to be.

This obviously should read `-device cirrus-vga,id=video0`, no idea why I
typed "us".

Bug#1020690: fakemachine should depend on systemd-resolved

[Christopher Obbard]

On Sun, 25 Sep 2022 12:25:27 +0100 Christopher Obbard
 wrote:
> Package: fakemachine
> Version: 0.0~git20210901.fc48786-1+b2
> Severity: important
> 
> Dear Maintainer,
> 
> The latest systemd packages do not include systemd-resolved; it was
split out
> into a seperate package.
> 
> Because of this, on a machine which does not have systemd-resolved
installed,
> fakemachine no longer works as intended.
> 
> Please add systemd-resolved as a runtime dependency to fakemachine.

Turns out it is not as simple as including it as a dependency:
installing systemd-resolved makes it the default name resolution
service and could cause some users confusion.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288 for more
detail.

Bug#1020691: debos should depend on systemd-resolved

[Christopher Obbard]

merge 1020288 1020691

On Wed, 2022-10-05 at 14:36 +0700, Arnaud Rebillout wrote:
> 
>  > On Sun, 25 Sep 2022 12:28:19 +0100 Christopher Obbard
>  >  wrote:
>  > > Because of this, on a machine which does not have
>  > > systemd-resolved installed, debos no longer works as
>  > > intended.
>  > >
>  > > Please add systemd-resolved as a runtime dependency to debos.
>  >
>  > It will fix debos but might break user's setup, or at least
> surprise
>  > user, because systemd-resolved will take over name resolution
>  > on the machine where it's installed.
>  >
>  > Cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020288
> 
> This comment also applies to fakemachine bug:
> https://bugs.debian.org/1020690
> 

Hi Arnaud,

Thanks for shedding the extra light. This is not a nice bug !

I think we should ask the systemd maintainer if they'd accept a patch
to make the enabling of systemd-resolved service a manual operation, or
at least to split the binary into a separate package, something like
systemd-standalone-resolved ?

Bug#778950: Fixed in Upstream

[Bálint Réczey]

Hi Jeff,

On Mon, 3 Oct 2022 09:10:33 -0500 Jeffrey Hawkins
 wrote:
> It appears the CVE-2013-4235 has been fixed in the upstream project,
> Release:  4.11.  Is there any intent by Debian to backport the fix?
> https://github.com/shadow-maint/shadow/releases/tag/v4.11

Not really. This marked as an unimportant issue by the Security Team.
https://security-tracker.debian.org/tracker/source-package/shadow

Cheers,
Balint

Bug#1021304: bugs.debian.org: "There is no record of Bug #..."

[Piotr Engelking]

Package: bugs.debian.org
Severity: normal

After receiving acknowledgement mail for bug #1021297, and after the
bug was visible on:

  https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=yes;src=cruft-ng

the bug report (linked from both places) was not available for some
time, giving error:

  "There is no record of Bug #1021297. Try the search page instead."

Please only send acknowledgement mail and display the bug in
pkgreport.cgi after the bug is visible in bugreport.cgi.

Bug#1021179: pipewire-pulse: KDE Plasma+ALC4080 onboard card: unable to select working profile

[Maurizio Avogadro]

tags 1021179 + upstream
thanks

https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2744

Bug#1021303: ITP: btllib -- Bioinformatics Technology Lab common code library

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: btllib -- Bioinformatics Technology Lab common code library
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: btllib
  Version : 1.4.9
  Upstream Author : Vladimir Nikolić, Parham Kazemi, Murathan Goktas, Lauren 
Coombe 
* URL : https://github.com/bcgsc/btllib
* License : GPL-3+
  Programming Lang: C++
  Description : Bioinformatics Technology Lab common code library
 Bioinformatics Technology Lab common code library in C++ with
 Python wrappers.
 .
 This package contains the header files and the static library.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/btllib

Bug#1020799: transition: pkg-config

[Andrej Shadura]

Hi,

On Wed, 5 Oct 2022, at 10:22, Sebastian Ramacher wrote:
>> I’m currently running a rebuild of all packages using pkg-config [2] to
>> determine if there are issues that need addressing during this
>> transition. So far I found one issue [3] that affects a couple of
>> packages, I’m going to discuss it with the pkgconf upstream.
>
> Did you find any new issues in the current round of rebuilds?

Indeed, I have:
* SPIRV had a Debian-specific patch, where .pc files were indented by 4 spaces; 
pkgconf didn’t support it
-> reported upstream with a patch, pkgconf patched, Debian patch to SPIRV 
adjusted to workaround
* three more packages so far are found to FTBFS with pkgconf but not pkg-config
-> bugs reported: 
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=andrewsh%40debian.org&tag=pkgconf-rebuild-ftbfs

The rebuild is still on-going: http://pkgconf-migration.debian.net/

-- 
Cheers,
  Andrej

Bug#951805: Help with glbinding

[Nilesh Patra]

On Sun, Oct 02, 2022 at 10:04:07PM +0200, Andrea Pappacoda wrote:
> Il giorno dom 2 ott 2022 alle 20:54:01 +02:00:00, Ghislain Vaillant
>  ha scritto:
> > Feel free to assist with maintenance of any of my packages under the
> > Debian science team umbrella.
> > 
> > You don't need to ask for permission 👍
> 
> Thanks for the fast reply, Ghislain! I'll start working on this in a few
> days. Would you be able to sponsor my first upload and/or grant me DM rights
> to the package?

Ghislain is not a DM or a DD (yet). So I guess they can't do so.
That said, feel free to ping me on the mailing list for any access requests - 
I'll be happy
to push the buttons.

But anyway, for now, here you go:

| $ dcut dm --uid and...@pappacoda.it --allow glbinding   
| Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
| Picking DM Andrea Pappacoda (Tachi's main key)  with 
fingerprint 66DEF15282990C2199EFA801A8A128A8AB1CEE49
| Uploading nilesh-1664959544.dak-commands to ftp-master

> If you prefer, I can publish my changes in a Salsa fork so
> that you can take a look at them before trusting me too much :)

That's kinda un-necessary. If you screw something up mistakenly in commits, we 
can
always revert/fix those, quickly.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1021301: grub-pc: regression: update to 2.06-3~deb11u2 fails with gpt

[Ansgar]

On Wed, 2022-10-05 at 09:48 +0200, Ansgar wrote:
> the upgrade to grub-pc 2.06-3~deb11u2 fails:
> 
> +---
> > Setting up grub-pc (2.06-3~deb11u2) ...
> > Installing for i386-pc platform.
> > grub-install: warning: this GPT partition label contains no BIOS
> > Boot Partition; embedding won't be possible.
> > grub-install: error: embedding is not possible, but this is
> > required for cross-disk install.
> > You must correct your GRUB install devices before proceeding:
> > 
> >   DEBIAN_FRONTEND=dialog dpkg --configure grub-pc
> >   dpkg --configure -a
> > dpkg: error processing package grub-pc (--configure):
> >  installed grub-pc package post-installation script subprocess
> > returned error exit status 1
> > Errors were encountered while processing:
> >  grub-pc
> > Log ended: 2022-09-23  06:09:42
> +---
[...]
> /dev/sda uses GPT and has one partition /dev/sda1; it was created
> this way by d-i (though it has the setting to use gpt enabled).

Ah, but this was a distraction: /dev/sda isn't the boot device. The
boot device is currently /dev/sdb. That still has a DOS disk label; the
systems using GPT for the boot device as well have a small 1M partition
for BIOS boot.

So grub-install shouldn't try to install to /dev/sda, but I find
nothing in /etc referencing /dev/sda at all (except for a comment in
/etc/fstab). So I'm not sure why the system tries to install grub
there.

I now also checked /var/log/installer/syslog and when installing the
system /dev/sda and /dev/sdb were the other way around. And it looks
like that was the case before the previous reboot as well.

So possibly one of the race conditions I read about? (FWIW, this is a
VM running under VMware.)

Ansgar

Bug#1020799: transition: pkg-config

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2022-09-26 23:48:12 +0200, Andrej Shadura wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi,
> 
> As described in [1], I’d like to go ahead with a replacing the Freedesktop.org
> implementation of pkg-config with pkgconf. This will involve pkgconf
> taking over the binary package pkg-config.
> 
> I’m currently running a rebuild of all packages using pkg-config [2] to
> determine if there are issues that need addressing during this
> transition. So far I found one issue [3] that affects a couple of
> packages, I’m going to discuss it with the pkgconf upstream.

Did you find any new issues in the current round of rebuilds?

Cheers

> 
> Results of a previous rebuild from the last year are available at [4],
> but they’re not very relevant anymore as some packages are no longer in
> Debian, and some failures were unrelated to pkgconf itself.
> 
> The current pkg-config maintainer gave me a go-ahead [5], so I’d like to
> start with the process as soon as possible.
> 
> Thanks,
> Andrej
> 
> [1]: https://lists.debian.org/debian-devel/2022/07/msg00252.html
> [2]: http://pkgconf-migration.debian.net/
> [3]: https://bugs.debian.org/1016922
> [4]: http://pkgconf-migration.debian.net/old/
> [5]: https://lists.debian.org/debian-devel/2022/09/msg00271.html

-- 
Sebastian Ramacher