Bug#1063757:

[Mario Limonciello]

Could you please also capture the value in
/sys/devices/system/cpu/intel_pstate/turbo_pct when you reproduced the
issue?

Bug#1063757:

[Mario Limonciello]

In that case can you please modify the daemon's systemd unit to run
the daemon with -vv in the ExecStart command then share the unit's
journal output from a boot this occurs to better understand it?

Bug#1063757:

[Mario Limonciello]

Can this still reproduce using power-profiles-daemon 0.21-1?  It's
available in unstable.

If so, can you please check the value of
"/sys/devices/system/cpu/intel_pstate/no_turbo" at the time of the
problem?

If the kernel doesn't advertise turbo support then
power-profiles-daemon can't do anything about it.

Bug#1064659: (no subject)

[Mario Limonciello]

Thanks! But we can go a step farther.  We haven't needed it since 
switching to meson.  Will drop in the next upload.


https://salsa.debian.org/efi-team/fwupd/-/commit/e57b1114f8c0299eb6e2b68e2a14ef3e2ff0f0d3

Bug#1027486: (no subject)

[Mario Limonciello]

Can you still reproduce this with fwupd 1.9.15-2?  I believe it should 
be fixed now.

Bug#1062820: (no subject)

[Mario Limonciello]

This will be fixed in the next upload by this change.

https://salsa.debian.org/efi-team/fwupd/-/commit/08001e21ccbb71902429dc3096086b35114c822f

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Mario Limonciello]

On 2/15/2024 12:39, Henrique de Moraes Holschuh wrote:

While adding linux-firmware's amdtee/ directory to the Debian amd64-microcode 
package, I have noticed that  the linux-firmware WHENCE file mentions a 
symbolic link that is not present in the git repository.

The missing symlink is:
amdtee/amd_pmf_v3.bin -> 773bd96f-b83f-4d52-b12dc529b13d8543.bin

Is the amd_pmf driver functional without that symlink ?



symlinks are created by copy-firmware.sh

$ make install DESTDIR=tmp
install -d tmp/lib/firmware
./copy-firmware.sh  tmp/lib/firmware

$ ls tmp/lib/firmware/amdtee/ -l
total 16
-rw-r--r-- 1 supermario supermario 12864 Feb 15 12:44 
773bd96f-b83f-4d52-b12dc529b13d8543.bin
lrwxrwxrwx 1 supermario supermario39 Feb 15 12:44 amd_pmf_v3.bin -> 
773bd96f-b83f-4d52-b12dc529b13d8543.bin

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Mario Limonciello]

'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries
will go to linux-firmware.git and then where do those go?


My (current) thinking is to have 2 categories:
- AMD CPU related
- AMD GPU/graphics related


Current products only put the IPU/NPU in APU chips, but who is to stay;
those might end up in SoCs without graphics in the future too.


I think it's important to facilitate people having f.e. the following combos:
- Intel CPU with AMD GPU
- AMD CPU with Nvidia GPU
- AMD CPU with AMD GPU (discrete or integrated)

Preferably without having to install 100s of MB of firmware files of which 95%
the user doesn't actually need. (See f.e. https://bugs.debian.org/1057786)


You don't currently split up the AMD APU integrated graphics and dGPU, 
and I doing this is a bad idea as it's possible to reuse IP versions on 
APU and dGPU hardware.  If they are the same then they would use the 
same firmware binaries.


For reference on the size:

$ du -sh amdgpu
60M amdgpu

$ du -sh du -sh amdtee/
20K amdtee/

$ du -sh amd-ucode/
112Kamd-ucode/

$ du -sh amd
268Kamd

These aren't yet upstream, but so you can see the size:

$ du -sh amdnpu/
3.3Mamdnpu/




How would you feel about making a master "amd" metapackage that pulls
them all?  You can split as you see fit then and people who want the
'easy button' can just install that package.


I'm not much of a fan of such metapackages. I think it mostly indicates that
the purpose of the various packages isn't clear, so let's install all of them.
Clarifying the purpose better is a better solution imo.
I'm aware others feel different: https://bugs.debian.org/522415

I prefer to keep that discussion out of this bug though, feel free to open a
new bug for that if you do want it.


I think your suggestion to combine all the non graphics related binaries 
to a single package and all graphics related binaries to another is fine.

Bug#1062678: amd64-microcode: Package upstream's amdtee dir in amd64-microcode?

[Mario Limonciello]

On 2/12/2024 14:11, Diederik de Haas wrote:

On Monday, 12 February 2024 19:38:12 CET Henrique de Moraes Holschuh wrote:

On Fri, Feb 2, 2024, at 13:50, Diederik de Haas wrote:

This is about "AMD Platform Management Framework TA", which seems to be
about AMD CPU features. The first (and only) commit message has this:

```
amd_pmf: Add initial PMF TA for Smart PC Solution Builder

AMD PMF driver loads the PMF TA (Trusted Application) into the AMD
ASP's (AMD Security Processor) TEE (Trusted Execution Environment).
```

Firmware for AMD graphics belongs in firmware-nonfree, but the
``amdtee`` directory seems to fit better in amd64-microcode?


Could be, yes.  It isn't needed at early boot at all, but then neither is
AMD-SEV, and it is in amd64-microcode.

So yeah, I could carry it on amd64-microcode, but we need to coordinate it
re. linux-firmware packages, since it has to move from one package to the
other.  Unless it has never made it to any linux-firmware packages ?


It has never made it into any firmware-nonfree package, so nothing needs to
move.
I'm working on a 20230804 update where I have added AMD-SEV to the Files-
Excluded section. I then came across the 'amdtee' dir and was wondering what
(best) to do with that, hence this bug.


And I need to know what I should do about it on the backport branches and
security update branches.


I don't know/understand what you mean by this. Can you clarify?

On Wed, 7 Feb 2024 18:38:30 -0600 Mario Limonciello
 wrote:

The firmware is only used on mobile APUs (which contain graphics).  So
if needing to pick an existing binary package instead of a new one I can
see a stronger argument to bundle it with the graphics package.


My logic was that this is about AMD TEE (Trusted Execution Environment), which
I *assumed* is part of/tied to the CPU. This thought is based on that on ARM
platforms, you also have a TEE and that is part of the CPU (and implemented in
TF-A IIUC). I can be wrong here ofc.


To me using the nomenclature of "CPU" is confusing.  We should be 
calling these SoCs.


Notably AMD APUs have X86 cores, IPU/NPU cores, GPU cores, ASP (formerly 
called PSP) and various others.


The TEE environment is part of the ASP, which is present on all Zen and 
later SoCs.




That it *currently* is only used on mobile APUs is something I consider to be
an implementation detail. I can be wrong on this too.


This specific TEE firmware is only for mobile APUs, but you're right the 
TEE environment is on socketed client desktop SoCs too.




There's no need to pick an existing binary package. I could add it to amd-
graphics, but I consider that a poor choice. I could create a new binary
package `amdtee` in firmware-nonfree (source package).
That would be fine afaic.

But as I assumed AMD TEE is a CPU feature, adding it to a package which
already deals with AMD CPU features seems the most logical.
And if AMD TEE becomes available in the future in 'normal' desktop CPUs
(without graphics) it would be 'weird' to have to install firmware-amd-graphics
to make use of it (and then a move probably would be needed).

So I have no strong feelings about it, just trying to find the best place for
the `amdtee` dir.

Cheers,
   Diederik


My general feeling is that having separated binary packages for all the 
AMD 'things' makes things "generally" confusing for end users and is 
needless extra work for you to maintain.


'amdtee' is the one thing right now, but soon (TM) the IPU/NPU binaries 
will go to linux-firmware.git and then where do those go?


Current products only put the IPU/NPU in APU chips, but who is to stay; 
those might end up in SoCs without graphics in the future too.


How would you feel about making a master "amd" metapackage that pulls 
them all?  You can split as you see fit then and people who want the 
'easy button' can just install that package.

Bug#1062678: (no subject)

[Mario Limonciello]

The firmware is only used on mobile APUs (which contain graphics).  So 
if needing to pick an existing binary package instead of a new one I can 
see a stronger argument to bundle it with the graphics package.

Bug#1063161: Processed: Re: Bug#1063161: Add amd_pmf module

[Mario Limonciello]

Yes, please set CONFIG_AMDTEE and CONFIG_AMD_PMF both.  The firmware is 
optional, certain functions for amd-pmf will be non-functional without it.

Bug#1059606: (no subject)

[Mario Limonciello]

It looks like it's still failing to build, but it's outside of fwupd 
code now.


https://buildd.debian.org/status/fetch.php?pkg=fwupd=loong64=1.9.12-3=1706130974=0

Bug#974220: #974220 libreoffice-writer: Double paste in Writer

[Mario J]

I just installed Debian 12 and bug still happens.

Bug#1059606: fwupd: add build support for loongarch64

[Mario Limonciello]

This will be fixed by the next upload with this change:
https://salsa.debian.org/efi-team/fwupd/-/commit/493293f60f78ed8c67d4839437765be140ebb25f
 


Sent with Shortwave 

Bug#1058701: RM: pm-utils; abandoned upstream

[Mario Limonciello]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: mario.limoncie...@amd.com

The pm-utils package hasn't had any activity in Debian since 2019.
All bugs have been ignored.

Upstream [1] has been dead since 2010.

Modern userspace uses systemd to perform suspend/resume instead.

[1] https://cgit.freedesktop.org/pm-utils/

Bug#1055694: klibc-utils: Patch to fix cp warning

[Mario Izquierdo (mariodebian)]

Package: klibc-utils
Version: 2.0.13-2
Followup-For: Bug #1055694

Dear Maintainer,

I found a small typo in initramfs-tools klibc-utils script:

# diff -ur klibc-utils /usr/share/initramfs-tools/hooks/klibc-utils
--- klibc-utils 2023-12-07 10:35:52.738502916 +0100
+++ /usr/share/initramfs-tools/hooks/klibc-utils2023-12-07 
10:36:02.686695427 +0100
@@ -27,7 +27,7 @@
;;
*)
# Don't install commands that already exist in /bin or /sbin
-   if ! [ -e "${DESTDIR}/sbin/$command" ]; then
+   if ! [ -e "${DESTDIR}/bin/$command" ]; then
cp -pnL "$src" "${DESTDIR}/bin"
fi
;;


With this change "if" works ok detecting file exists and don't try to overwrite.

Greetings


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

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

Versions of packages klibc-utils depends on:
ii  libklibc  2.0.13-2

klibc-utils recommends no packages.

klibc-utils suggests no packages.

-- no debconf information

Bug#1010492: 

[Mario Limonciello]

This is intentional behavior because some devices require AC to be plugged in 
to perform updates. It won't be changed for Debian, if you disagree with it you 
can raise a discussion upstream.

Bug#1055979: 

[Mario Limonciello]

This should be fixed in 1.9.9, can you try it?

Bug#1040245: 

[Mario Limonciello]

As you correctly pointed out this is unexpected and it definitely (used to) 
work properly.
Can you add —verbose to the fwupd-refresh unit that causes this behavior? Maybe 
we'll get some more hints.

Also if you raise this bug upstream (https://github.com/fwupd/fwupd 
) others may have more ideas.

Bug#1056185: /usr/lib/python3/dist-packages/gidocgen/gir/ast.py: Debian specific multiarch detection fails when called outside of dpkg build

[Mario]

Package: gi-docgen
Version: 2023.1+ds-4
Severity: normal
File: /usr/lib/python3/dist-packages/gidocgen/gir/ast.py
X-Debbugs-Cc: supe...@gmail.com


When running gi-docgen outside of a package (such as a test build by hand)
it will fail with the following:

usr/bin/gi-docgen generate --quiet 
--add-include-path=/github/workspace/fwupd/bulid/docs/../libfwupd 
--config=docs/fwupd.toml --output-dir=docs/libfwupd --no-namespace-dir 
--content-dir=/github/workspace/fwupd/docs libfwupd/Fwupd-2.0.gir
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gidocgen/gidocmain.py", line 78, in run
res = options.run_func(options)
  ^
  File "/usr/lib/python3/dist-packages/gidocgen/gdgenerate.py", line 3134, in 
run
paths.extend(utils.default_search_paths())
 
  File "/usr/lib/python3/dist-packages/gidocgen/utils.py", line 826, in 
default_search_paths
multiarch = sysconfig.get_config_var('MULTIARCH')
^
NameError: name 'sysconfig' is not defined


This looks specific to a Debian patch that forgot to import sysconfig.


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

Kernel: Linux 6.5.11-300.fc39.x86_64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gi-docgen depends on:
ii  python3 3.11.4-5+b1
ii  python3-jinja2  3.1.2-1
ii  python3-markdown3.4.4-1
ii  python3-markupsafe  2.1.3-1
ii  python3-pygments2.15.1+dfsg-1
ii  python3-typogrify   1:2.0.7-3

gi-docgen recommends no packages.

gi-docgen suggests no packages.

-- no debconf information

Bug#1052993: (no subject)

[Mario Limonciello]

Sorry; I missed this bug in the last upload.

I've submitted your changes to the VCS for review and they should be 
part of the next version.


https://github.com/fwupd/fwupd/pull/6378

Bug#1053856: (no subject)

[Mario Limonciello]

The specific issue here is that there is a firmware binary in upstream 
linux-firwmare.git, also documented in WHENCE upstream but not installed 
in Debian's package.

Bug#1053764: radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch unnecessary for amdgpu now

[Mario Limonciello]

Package: linux
Version: 6.5.0-1

Hi,

The patch carried by the Debian kernel 
bugfix/all/radeon-amdgpu-firmware-is-required-for-drm-and-kms-on-r600-onward.patch 
isn't necessary specifically for amdgpu anymore with modern kernels.


AMDGPU has been modified to check for the existence of firmware as part 
of the IP discovery enumeration process.  If firmware is missing, the 
GPU probe will fail and the framebuffer provided by the boot firmware 
will continue to be used.


I think the patch can be modified now to only cover radeon.

Thanks!

Bug#1051294: This appears t

[Mario Limonciello]

This appears to be a bug in libxmlb-dev, it's missing a dependency
on libzstd-dev.

Bug#802539: closed by Julien Cristau (Re: Bug#802539: Please properly configure HTTPS in security.debian.org)

[Mario Xerxes Castelán Castro «Ksenia»]

I filled this bug when I was a kid. In the time it took you to do 
anything about this, I became an adult. You suck.

Bug#934938: [cargo-docs] missing files

[Mario González Troncoso]

Hey, I might be able to help build deb packages. Because I've been
learning rust for a few, this seems a good place to start contributing
to Debian.

May I know what's the bug's latest status and where should I start first?
Thanks!

-- 
https://www.linkedin.com/in/gonzalemario

Bug#1043582: New upstream version for pocketsphinx and Co

[Mario Fux]

Am Sonntag, 13. August 2023, 17:33:42 CEST schrieb Samuel Thibault:
> Hello,

Good morning Samuel

Thanks for your work and your quick reaction.

> Mario Fux, le dim. 13 août 2023 11:49:37 +0200, a ecrit:
> > Announcement of PocketSphinx 5.0.0: https://cmusphinx.github.io/2022/10/
> > release/
> 
> It apparently intentionally broke its API... I have left bug reports on

Yes indeed. I needed to port (trying to get it back to work) Simon 
(simon.kde.org) as well.

>   - parlatype https://github.com/gkarsay/parlatype/issues/109
>   - subtitlecomposer
> https://invent.kde.org/multimedia/subtitlecomposer/-/issues/83 - ffmpeg
> https://trac.ffmpeg.org/ticket/10520#ticket

I might git subtitlecomposer a try in the coming days.

> Samuel

Thanks
Mario

Bug#1043582: New upstream version for pocketsphinx and Co

[Mario Fux]

Package: pocketsphinx
Version: 5.0.1

Since October 2022 there is a new upstream version (5.0.0, since May 2023 
there is 5.0.1). Some for Sphinxtrain. Sphinxbase is abandoned.

Announcement of PocketSphinx 5.0.0: https://cmusphinx.github.io/2022/10/
release/
Announcement of SphinxTrain 5.0.0: https://cmusphinx.github.io/2022/10/
release/
Announcement of PocketSphinx 5.0.1: https://cmusphinx.github.io/2023/05/
release/

Thanks for your work on this package.
Mario

Bug#1041752: fwupd: ships empty directory /lib/systemd/system-preset

[Mario Limonciello]

On Sun, 23 Jul 2023 06:58:25 +0200 Helmut Grohne  wrote:
> Source: fwupd
> Version: 1.9.3-1
> Severity: important
> Tags: patch
>
> fwupd ships an empty directory /lib/systemd/system-preset. This
> directory is prone to loss since we implemented the /usr-merge using
> aliasing. Another package may install a file into
> /usr/lib/systemd/system-preset and when that package is removed, this
> empty directory is deleted as well.
>
> fwupd used to install a preset file there, but no longer does. This
> directory is not crucial to fwupd and can be deleted as well. Once
> deleted, it can no longer be lost. I'm attaching a patch for your
> convenience.
>
> Helmut

Thanks, I've submitted this upstream.
https://github.com/fwupd/fwupd/pull/6030

It should be in the upcoming 1.9.4 release.

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

[Limonciello, Mario]

Nevertheless: thx for your report your help through this thread.


No problem. I am willing to try to do more, but right now I don't know
how to do what has been suggested.



Here is where to report Nouveau bugs:

https://gitlab.freedesktop.org/drm/nouveau/-/issues/

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

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Nick Hastings 
> Sent: Thursday, June 1, 2023 7:02 PM
> To: Karol Herbst 
> Cc: Limonciello, Mario ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> Hi,
>
> * Karol Herbst  [230602 03:10]:
> > On Thu, Jun 1, 2023 at 7:21 PM Limonciello, Mario
> >  wrote:
> > > > -Original Message-
> > > > From: Karol Herbst 
> > > > Sent: Thursday, June 1, 2023 12:19 PM
> > > > To: Limonciello, Mario 
> > > > Cc: Nick Hastings ; Lyude Paul
> > > > ; Lukas Wunner ; Salvatore
> > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > > Wysocki ; Len Brown ; linux-
> > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > regressi...@lists.linux.dev
> > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> system)
> > > >
> > > > On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
> > > >  wrote:
> > > > >
> > > > > [AMD Official Use Only - General]
> > > > >
> > > > > > -Original Message-
> > > > > > From: Karol Herbst 
> > > > > > Sent: Thursday, June 1, 2023 11:33 AM
> > > > > > To: Limonciello, Mario 
> > > > > > Cc: Nick Hastings ; Lyude Paul
> > > > > > ; Lukas Wunner ; Salvatore
> > > > > > Bonaccorso ; 1036...@bugs.debian.org; Rafael
> J.
> > > > > > Wysocki ; Len Brown ; linux-
> > > > > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > > > > regressi...@lists.linux.dev
> > > > > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video
> _OSI
> > > > > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> > > > system)
> > > > > >
> > > > > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > > > > > >
> > > > > > > Lyude, Lukas, Karol
> > > > > > >
> > > > > > > This thread is in relation to this commit:
> > > > > > >
> > > > > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > > > > >
> > > > > > > Nick has found that runtime PM is *not* working for nouveau.
> > > > > > >
> > > > > >
> > > > > > keep in mind we have a list of PCIe controllers where we apply a
> > > > > > workaround:
> > > > > >
> > > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > > > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > > > > >
> > > > > > And I suspect there might be one or two more IDs we'll have to add
> > > > > > there. Do we have any logs?
> > > > >
> > > > > There's some archived onto the distro bug.  Search this page for
> > > > "journalctl.log.gz"
> > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530
> > > > >
> > > >
> > > > interesting.. It seems to be the same controller used here. I wonder
> > > > if the pci topology is different or if the workaround is applied at
> > > > all.
> > >
> > > I didn't see the message in the log about the workaround being applied
> > > in that log, so I guess PCI topology difference is a likely suspect.
> > >
> >
> > yeah, but I also couldn't see a log with the usual nouveau messages,
> > so it's kinda weird.
> >
> > Anyway, the output of `lspci -tvnn` would help
>
> % lspci -tvnn
> -[:00]-+-00.0  Intel Corporation Device [8086:3e20]
>+-01.0-[01]00.0  NVIDIA Corporation TU117M [GeForce GTX 1650
> Mobile / Max-Q] [10de:1f91]

So the bridge it's connected to is the same that the quirk *should have been* 
triggering.

May 29 15:02:42 xps kernel: pci :00:01.0: [8086:1901] type 01 class 0x060400

Since the quirk isn't wor

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

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Karol Herbst 
> Sent: Thursday, June 1, 2023 12:19 PM
> To: Limonciello, Mario 
> Cc: Nick Hastings ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> On Thu, Jun 1, 2023 at 6:54 PM Limonciello, Mario
>  wrote:
> >
> > [AMD Official Use Only - General]
> >
> > > -Original Message-
> > > From: Karol Herbst 
> > > Sent: Thursday, June 1, 2023 11:33 AM
> > > To: Limonciello, Mario 
> > > Cc: Nick Hastings ; Lyude Paul
> > > ; Lukas Wunner ; Salvatore
> > > Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> > > Wysocki ; Len Brown ; linux-
> > > a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> > > regressi...@lists.linux.dev
> > > Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> > > string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of
> system)
> > >
> > > On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
> > >  wrote:
> > > >
> > > > +Lyude, Lukas, Karol
> > > >
> > > > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > > > Hi,
> > > > >
> > > > > * Nick Hastings  [230530 16:01]:
> > > > >> * Mario Limonciello  [230530 13:00]:
> > > > > 
> > > > >>> As you're actually loading nouveau, can you please try
> > > nouveau.runpm=0 on
> > > > >>> the kernel command line?
> > > > >> I'm not intentionally loading it. This machine also has intel 
> > > > >> graphics
> > > > >> which is what I prefer. Checking my
> > > > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > > > >> I see:
> > > > >>
> > > > >> blacklist nvidia
> > > > >> blacklist nvidia-drm
> > > > >> blacklist nvidia-modeset
> > > > >> blacklist nvidia-uvm
> > > > >> blacklist ipmi_msghandler
> > > > >> blacklist ipmi_devintf
> > > > >>
> > > > >> So I thought I had blacklisted it but it seems I did not. Since I do 
> > > > >> not
> > > > >> want to use it maybe it is better to check if the lock up occurs with
> > > > >> nouveau blacklisted. I will try that now.
> > > > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > > > % uname -a
> > > > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> > > (2023-05-08) x86_64 GNU/Linux
> > > > >
> > > > > It has been running without problems for nearly two days now:
> > > > > % uptime
> > > > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > > > >
> > > > > Regards,
> > > > >
> > > > > Nick.
> > > >
> > > > Thanks, that makes a lot more sense now.
> > > >
> > > > Nick, Can you please test if nouveau works with runtime PM in the
> > > > latest 6.4-rc?
> > > >
> > > > If it works in 6.4-rc, there are probably nouveau commits that need
> > > > to be backported to 6.1 LTS.
> > > >
> > > > If it's still broken in 6.4-rc, I believe you should file a bug:
> > > >
> > > > https://gitlab.freedesktop.org/drm/nouveau/
> > > >
> > > >
> > > > Lyude, Lukas, Karol
> > > >
> > > > This thread is in relation to this commit:
> > > >
> > > > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> > > >
> > > > Nick has found that runtime PM is *not* working for nouveau.
> > > >
> > >
> > > keep in mind we have a list of PCIe controllers where we apply a
> > > workaround:
> > >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> > > /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
> > >
> > > And I suspect there might be one or two more IDs we'll have to add
> > > there. Do we have any logs?
> >
> &g

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

[Limonciello, Mario]

[AMD Official Use Only - General]

> -Original Message-
> From: Karol Herbst 
> Sent: Thursday, June 1, 2023 11:33 AM
> To: Limonciello, Mario 
> Cc: Nick Hastings ; Lyude Paul
> ; Lukas Wunner ; Salvatore
> Bonaccorso ; 1036...@bugs.debian.org; Rafael J.
> Wysocki ; Len Brown ; linux-
> a...@vger.kernel.org; linux-ker...@vger.kernel.org;
> regressi...@lists.linux.dev
> Subject: Re: Regression from "ACPI: OSI: Remove Linux-Dell-Video _OSI
> string"? (was: Re: Bug#1036530: linux-signed-amd64: Hard lock up of system)
>
> On Thu, Jun 1, 2023 at 6:18 PM Limonciello, Mario
>  wrote:
> >
> > +Lyude, Lukas, Karol
> >
> > On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > > Hi,
> > >
> > > * Nick Hastings  [230530 16:01]:
> > >> * Mario Limonciello  [230530 13:00]:
> > > 
> > >>> As you're actually loading nouveau, can you please try
> nouveau.runpm=0 on
> > >>> the kernel command line?
> > >> I'm not intentionally loading it. This machine also has intel graphics
> > >> which is what I prefer. Checking my
> > >> /etc/modprobe.d/blacklist-nvidia-nouveau.conf
> > >> I see:
> > >>
> > >> blacklist nvidia
> > >> blacklist nvidia-drm
> > >> blacklist nvidia-modeset
> > >> blacklist nvidia-uvm
> > >> blacklist ipmi_msghandler
> > >> blacklist ipmi_devintf
> > >>
> > >> So I thought I had blacklisted it but it seems I did not. Since I do not
> > >> want to use it maybe it is better to check if the lock up occurs with
> > >> nouveau blacklisted. I will try that now.
> > > I blacklisted nouveau and booted into a 6.1 kernel:
> > > % uname -a
> > > Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1
> (2023-05-08) x86_64 GNU/Linux
> > >
> > > It has been running without problems for nearly two days now:
> > > % uptime
> > >   08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27
> > >
> > > Regards,
> > >
> > > Nick.
> >
> > Thanks, that makes a lot more sense now.
> >
> > Nick, Can you please test if nouveau works with runtime PM in the
> > latest 6.4-rc?
> >
> > If it works in 6.4-rc, there are probably nouveau commits that need
> > to be backported to 6.1 LTS.
> >
> > If it's still broken in 6.4-rc, I believe you should file a bug:
> >
> > https://gitlab.freedesktop.org/drm/nouveau/
> >
> >
> > Lyude, Lukas, Karol
> >
> > This thread is in relation to this commit:
> >
> > 24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")
> >
> > Nick has found that runtime PM is *not* working for nouveau.
> >
>
> keep in mind we have a list of PCIe controllers where we apply a
> workaround:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers
> /gpu/drm/nouveau/nouveau_drm.c?h=v6.4-rc4#n682
>
> And I suspect there might be one or two more IDs we'll have to add
> there. Do we have any logs?

There's some archived onto the distro bug.  Search this page for 
"journalctl.log.gz"
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036530

> And could anybody test if adding the
> controller in play here does resolve the problem?
>
> > If you recall we did 24867516f06d because 5775b843a619 was
> > supposed to have fixed it.
> >

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

[Limonciello, Mario]

+Lyude, Lukas, Karol

On 5/31/2023 6:40 PM, Nick Hastings wrote:

Hi,

* Nick Hastings  [230530 16:01]:

* Mario Limonciello  [230530 13:00]:



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

I'm not intentionally loading it. This machine also has intel graphics
which is what I prefer. Checking my
/etc/modprobe.d/blacklist-nvidia-nouveau.conf
I see:

blacklist nvidia
blacklist nvidia-drm
blacklist nvidia-modeset
blacklist nvidia-uvm
blacklist ipmi_msghandler
blacklist ipmi_devintf

So I thought I had blacklisted it but it seems I did not. Since I do not
want to use it maybe it is better to check if the lock up occurs with
nouveau blacklisted. I will try that now.

I blacklisted nouveau and booted into a 6.1 kernel:
% uname -a
Linux xps 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) 
x86_64 GNU/Linux

It has been running without problems for nearly two days now:
% uptime
  08:34:48 up 1 day, 16:22,  2 users,  load average: 1.33, 1.26, 1.27

Regards,

Nick.


Thanks, that makes a lot more sense now.

Nick, Can you please test if nouveau works with runtime PM in the
latest 6.4-rc?

If it works in 6.4-rc, there are probably nouveau commits that need
to be backported to 6.1 LTS.

If it's still broken in 6.4-rc, I believe you should file a bug:

https://gitlab.freedesktop.org/drm/nouveau/


Lyude, Lukas, Karol

This thread is in relation to this commit:

24867516f06d ("ACPI: OSI: Remove Linux-Dell-Video _OSI string")

Nick has found that runtime PM is *not* working for nouveau.

If you recall we did 24867516f06d because 5775b843a619 was
supposed to have fixed it.

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

[Mario Limonciello]

On 5/29/23 18:01, Nick Hastings wrote:

Hi,

* Nick Hastings  [230529 12:51]:

* Mario Limonciello  [230529 10:14]:

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

Hi,

* Mario Limonciello  [230528 21:44]:

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

Hi Mario

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

he bisected the issue and tracked it down to:

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

Control: tags -1 - moreinfo

Hi,

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

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

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

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

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

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

Hopefully this is enough information for experts to resolve this.


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

Regards,
Salvatore





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


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


I let this run for 3 hours without issue.


Does this happen in the latest 6.4 RC as well?


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


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


I did eventually see a lockup of this kernel. On the console I saw:

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

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

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


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


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

Regards,

Nick.


I don't see nouveau loading, are you explicitly preventing it from
loading?


Yes nouveau is blacklisted.


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


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


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

Regards,

Nick.


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


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


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

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

[Mario Limonciello]

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

Hi,

* Mario Limonciello  [230528 21:44]:

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

Hi Mario

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

he bisected the issue and tracked it down to:

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

Control: tags -1 - moreinfo

Hi,

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

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

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

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

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

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

Hopefully this is enough information for experts to resolve this.


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

Regards,
Salvatore





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


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


Does this happen in the latest 6.4 RC as well?


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


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


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

Regards,

Nick.


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

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

[Mario Limonciello]

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

Hi Mario

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

he bisected the issue and tracked it down to:

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

Control: tags -1 - moreinfo

Hi,

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

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

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

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

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

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

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

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

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

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

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

Hopefully this is enough information for experts to resolve this.


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

Regards,
Salvatore


Hi Salvatore,

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

Does this happen in the latest 6.4 RC as well?

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

Bug#1035397: pm-utils is abandoned, should be removed from Debian

[Limonciello, Mario]

[Public]

There was a comment on #852167 that there are no non-systemd tools, but that's 
simply not true.

All you need for a suspend is

echo mem | sudo tee /sys/power/state

BTW - there's a reason that systemd refuses to include a lot of hooks and 
quirks.
The scripts/quirks/etc that pm-utils does are presumptuous and generally not 
correct.

Bug#1035397: pm-utils is abandoned, should be removed from Debian

[Mario Limonciello]

Package: pm-utils
Severity: important
X-Debbugs-Cc: mario.limoncie...@amd.com

Dear Maintainer,

pm-utils hasn't had any changed in 13 years upstream.  It's been effectively 
replaced by
systemd-sleep in all practical ways.

It should be removed from the archive.


-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages pm-utils depends on:
ii  powermgmt-base  1.36

Versions of packages pm-utils recommends:
pn  ethtool  
ii  hdparm   9.60+ds-1build3
pn  vbetool  

Versions of packages pm-utils suggests:
pn  cpufrequtils
pn  radeontool  

Bug#1032706: [pkg-lxc-devel] Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend

[Sperl, Mario]

Hi Mathias,

I submitted an issue on github: https://github.com/lxc/lxc/issues/4289

Step-by-step is explained there.

Thank you,

Mario

On 3/11/23 17:59, Mathias Gibbens wrote:

Hi Mario,

   I'm currently on travel with not-so-great network connectivity, so I
haven't been able to reproduce this on my travel laptop, but will
attempt to do so when I'm back from my trip.

   I expect that this issue will have to be forwarded to the lxc
developers; if you want to do so you can submit an issue at
https://github.com/lxc/lxc/issues, otherwise I'll so after reproducing
the issue myself.

   To help ensure I'll be following exactly what you did, could you
share the commands you used to setup the loop storage backend, the
creation of the container, snapshoting, and attempted restoration of
that snapshot?

Thanks,
Mathias

Bug#1032706: lxc-snapshot cannot restore containers with loop storage backend

[Sperl, Mario]

Package: lxc
Version: 1:5.0.2-1
Severity: grave
Justification: causes data loss

Dear Maintainer,

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

   * What led up to the situation? I tried to generate a snapshot with 
lxc-snapshot for a test container that is more than 1G of size. Snapshot 
generation does not show any problems but the restore does only restore 1G so 
the container is not able to start after restore.
   * What exactly did you do (or not do) that was effective (or
 ineffective)? One can create a new loop file with correct size and copy 
the snapshot contents in here but this renders this command absolute useless 
when using loop backend
   * What was the outcome of this action? Container cannot start 
   * What outcome did you expect instead? A container that does start normally 
after restoring.


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

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

Versions of packages lxc depends on:
ii  debconf [debconf-2.0]1.5.82
ii  dnsmasq-base [dnsmasq-base]  2.89-1
ii  iproute2 6.1.0-2
ii  iptables 1.8.9-2
ii  libapparmor1 3.0.8-3
ii  libc62.36-8
ii  libcap2  1:2.66-3
ii  libgcc-s112.2.0-14
ii  liblxc-common1:5.0.2-1
ii  liblxc1  1:5.0.2-1
ii  libseccomp2  2.5.4-1+b3
ii  libselinux1  3.4-1+b5
ii  lsb-base 11.6
ii  nftables 1.0.6-2
ii  sysvinit-utils [lsb-base]3.06-2

Versions of packages lxc recommends:
ii  apparmor   3.0.8-3
ii  debootstrap1.0.128+nmu2
ii  dirmngr2.2.40-1
ii  gnupg  2.2.40-1
ii  libpam-cgfs1:5.0.2-1
ii  lxc-templates  3.0.4.48.g4765da8-1
ii  lxcfs  5.0.3-1
ii  openssl3.0.8-1
ii  rsync  3.2.7-1
ii  uidmap 1:4.13+dfsg1-1
ii  wget   1.21.3-1+b2

Versions of packages lxc suggests:
pn  btrfs-progs  
ii  lvm2 2.03.16-2
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#1008025:

[Limonciello, Mario]

[AMD Official Use Only - General]

I believe this should be fixed in the latest version which drops the efi-cc and 
uses CC variable directly.

Can you confirm it?

Bug#1023329:

[Limonciello, Mario]

[Public]

FYI - the patch was originally targeted to ath-next (6.2), but because of the 
severity of this deadlock issue it's going to go to 6.1-rc with a CC to stable.
[v6.1] wifi: ath11k: avoid deadlock during regulatory update in 
ath11k_regd_update() - Patchwork 
(kernel.org)

Bug#1022187: upgrade-reports: Watching videos on the web doesn't work.

[Mario Luppi]

Package: upgrade-reports
Severity: important
X-Debbugs-Cc: mario_lu...@tiscali.it


 Hello everyone.
As per object trying to watch videos on any site that publishes videos 
(youtube, twitch, etc., etc.) the same hangs and is not displayed.

I tried with both Firefox and Chromium but the result is the same.
Firefox 102.3.0esr (64-bit)
Chromium 106.0.5249.119 (Official Build)

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

My previous release is: 
I am upgrading to: 
Archive date: 
Upgrade date: 
uname -a before upgrade: 
uname -a after upgrade: 
Method: 

Contents of /etc/apt/sources.list:


- Were there any non-Debian packages installed before the upgrade?  If
  so, what were they?

- Was the system pre-update a 'pure' system only containing packages
  from the previous release? If not, which packages were not from that
  release?

- Did any packages fail to upgrade?

- Were there any problems with the system after upgrading?


Further Comments/Problems:


Please attach the output of "COLUMNS=200 dpkg -l" (or "env COLUMNS ...",
depending on your shell) from before and after the upgrade so that we
know what packages were installed on your system.

Bug#1011511:

[Limonciello, Mario]

[Public]

https://github.com/fwupd/fwupd/pull/5041 may help your problem, can you try 
that?

Bug#1016920: libopenscenegraph-dev: openscenegraph for Testing/Bookworm

[Mario Luppi]

Package: libopenscenegraph-dev
Severity: normal
X-Debbugs-Cc: mario_lu...@tiscali.it

Dear Maintainer,

Howdy.
It seems to me that there is no package in Testing/Bookworm referring to 
openscenegraph, whether it is libraries, development libraries or the actual 
package.
Am I wrong? Do you plan to add it sooner or later?
Thank you.

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Bug#1010490:

[Mario Limonciello]

It was validated  to be fixed in 1.8.0, but the fix is present in 1.5.8 and
later.  Debian testing has 1.7.7, which picks up this fix.

-- 
Mario Limonciello
supe...@gmail.com

Bug#1005339: [Solved] This issue is not a Debian bullseye problem

[Mario Natiello]

[Solved]
The issue is solved if the external monitor is connected natively to the
laptop's displayport instead of using displaymanager-debian through a
dock.

-- 
Mario Natiello

Bug#1006390: Incorrect entry in SEE ALSO section of lintian(1)

[Mario Blättermann]

Package: lintian
Version: 2.114.0

Hello,

the SEE ALSO section of the man page lintian(1) contains a link
without target. The man page dh_make(8) is actually dh_make(1). You
can see this online [1]. The dh_make(8) entry is not clickable,
because this man page doesn't exist.

This applies also to other versions in Bullseye, Bullseye-Backports and Testing.

[1] https://manpages.debian.org/unstable/lintian/lintian.1.en.html#SEE_ALSO

Best Regards,
Mario

Bug#1005339: general: usbmouse+keyboard lag on closing the lid or issuing xrandr --output eDP-1 --off

[Mario Natiello]

Package: general
Severity: normal

Dear Maintainer,

   * What led up to the situation?
with an external monitor attached, closing the lid or issuing
  xrandr --output eDP-1 --off
to disable the laptop screen.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 close laptop lid or issue above xrandr command
 
   * What was the outcome of this action?
the usbmouse and keyboard lag

   * What outcome did you expect instead?
normal behaviour of usbmouse and keyboard

Note: By issuing
xrandr --auto
usbmouse+keyboard return to normal, but the laptop screen is on, even
if lid is closed

Linux  5.10.0-11-amd64 #1 SMP Debian 5.10.92-1 (2022-01-18)
x86_64 GNU/Linux
Debian 11 bullseye

-- 
Mario Natiello

Bug#1003575: portaudio19: Request for update of Portaudio to v19.7.0

[Mario Kleiner]

Source: portaudio19
Severity: normal

Dear Maintainer,

i'd like to request an update of the portaudio19 package to version 19.7.0,
which was released already in April 2021, see:

https://github.com/PortAudio/portaudio/releases/tag/v19.7.0

Release notes list various fixes for ALSA and Jack support, also in relation to
make it usable with Pipewire.

It would be great if we could have this in unstable before the end of package
sync for the Ubuntu 22.04-LTS release around mid-february 2022. I was asked to
file a bug report with update request here, instead of directly against Ubuntu.

My main reason for this request is that an up to date package would benefit
scientific use cases provided by the octave-psychtoolbox-3 package in Debian,
Ubuntu, and the NeuroDebian project which is part of Debian/Science.

Many thanks and happy new year!
Mario (the upstream maintainer of octave-psychtoolbox-3)



-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.18-surface (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1001908: manpages-de: manpage of "shutdown" not up-to-date

[Mario Blättermann]

Hello,

Am So., 26. Dez. 2021 um 01:43 Uhr schrieb Jesse Smith
:
>
> On 2021-12-25 3:35 p.m., Mario Blättermann wrote:
> > OK, it is in my favor to both keep existing man page translations
> > alive (acknowledging the work of the previous translators) and
> > integrate Po4a-based translations into upstream projects, instead of
> > maintaining them in an external translation project. Give me some days
> > to prepare a Po4a framework and migrate the existing .po files. I've
> > already checked out the Git repo at savannah.nongnu.org. I would
> > create the changes in one single (and quite big) Git diff, is this OK
> > for you? Or is there even a mirror at Github or Gitlab or wherever
> > else where I could create a pull request?
> >
>
> Hi Mario. I'm the upstream maintainer for sysvinit. You can e-mail me
> the git patch if you like and I'll test & apply it upstream. One big
> text file produced from "git diff" works fine for me. At this time there
> isn't a mirror for sysvinit. I've been thinking about it, or even
> migrating to a more popular platform as the Savannah infrastructure has
> some drawbacks.
>
> For now though the easiest way to send changes upstream is to e-mail
> them to me, or open a bug report on Savannah.
>
While creating the Po4a framework, I found many issues in the man
pages worth to fix. See the attachment. As a temporary playground,
I've forked the Savannah repo at Github [1], where you can also view
the patch [2]

[1] https://github.com/mariobl/sysvinit
[2] 
https://github.com/mariobl/sysvinit/commit/2bfc3618a0fa343856581ed3b39cc5dac215ace8

Best Regards,
Mario
From 2bfc3618a0fa343856581ed3b39cc5dac215ace8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mario=20Bl=C3=A4ttermann?= 
Date: Mon, 27 Dec 2021 13:11:15 +0100
Subject: [PATCH] Fix markup and typos in man pages

---
 man/bootlogd.8 |  35 ---
 man/fstab-decode.8 |  21 -
 man/halt.8 |  20 +
 man/init.8 | 104 +++--
 man/initctl.5  |  76 +
 man/initscript.5   |  15 ---
 man/inittab.5  |  28 +++-
 man/killall5.8 |  24 ++-
 man/last.1 |  18 
 man/logsave.8  |  12 +++---
 man/mesg.1 |  10 +++--
 man/mountpoint.1   |  26 ++--
 man/pidof.8|  46 ++--
 man/readbootlog.1  |  10 +++--
 man/runlevel.8 |  10 +++--
 man/shutdown.8 |  82 ++-
 man/sulogin.8  |  43 ++-
 man/utmpdump.1 |   2 +-
 man/wall.1 |  30 +++--
 19 files changed, 327 insertions(+), 285 deletions(-)

diff --git a/man/bootlogd.8 b/man/bootlogd.8
index 4f90270..440fc62 100644
--- a/man/bootlogd.8
+++ b/man/bootlogd.8
@@ -15,7 +15,7 @@
 .\" along with this program; if not, write to the Free Software
 .\" Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
 .\"
-.TH BOOTLOGD 8 "Jul 21, 2003" "" "Linux System Administrator's Manual"
+.TH BOOTLOGD 8 "Jul 21, 2003" "sysvinit @VERSION@" "Linux System Administrator's Manual"
 .SH NAME
 bootlogd \- record boot messages
 .SH SYNOPSIS
@@ -26,25 +26,24 @@ bootlogd \- record boot messages
 .RB [ \-r ]
 .RB [ \-s ]
 .RB [ \-v ]
-.RB [ " -l logfile " ]
-.RB [ " -p pidfile " ]
+.RI [ " \fB-l\fP logfile " ]
+.RI [ " \fB-p\fP pidfile " ]
 .SH DESCRIPTION
-\fBBootlogd\fP runs in the background and copies all strings sent to the
-\fI/dev/console\fP device to a logfile. If the logfile is not accessible,
+\fBbootlogd\fP runs in the background and copies all strings sent to the
+\fI/dev/console\fP device to a logfile. If the \fIlogfile\fP is not accessible,
 the messages will be kept in memory until it is.
 .SH OPTIONS
 .IP \fB\-d\fP
 Do not fork and run in the background.
 .IP \fB\-e\fP
 Print escape characters to the boot log file. This turns off filtering of
-escape characters and allows tools like GNU Less to see and use colour control
-characters (show the log in colour).
+escape characters and allows tools like GNU \fBless\fP(1) to see and use
+colour control characters (show the log in colour).
 .IP \fB\-c\fP
 Attempt to write to the logfile even if it does not yet exist.
-Without this option,
-.B bootlogd
-will wait for the logfile to appear before attempting to write to it.
-This behavior prevents bootlogd from creating logfiles under mount points.
+Without this option, \fBbootlogd\fP will wait for the logfile to appear before
+attempting to write to it. This behavior prevents \fBbootlogd\fP from creating
+logfiles under mount points.
 .IP \fB\-r\fP
 If there is an existing logfile called \fIlogfile\fP rename it to
 \fIlogfile~\fP unless \fIlogfile~\fP already exists.
@@ -61,12 +60,12 @@ Log to this logfile.

Bug#1001908: manpages-de: manpage of "shutdown" not up-to-date

[Mario Blättermann]

Hello all,

Am Fr., 24. Dez. 2021 um 10:27 Uhr schrieb Helge Kreutzmann
:
>
> Hello Mark,
> On Fri, Dec 24, 2021 at 08:13:56AM +, Mark Hindley wrote:
> > [Adding CC debian-init-divers...@chiark.greenend.org.uk]
>
> And adding Mario, manpages-l10n upstream maintainer as well.
>
> > Thanks for this.
>
> You are welcome, and thanks for considering.
>
> > On Thu, Dec 23, 2021 at 05:39:20PM +0100, Helge Kreutzmann wrote:
> > > In Debian we have the situation that some man pages are shipped by
> > > several packages. This is fine for the english versions, as there the
> > > alternatives mechanism takes care of this.
> > >
> > > For translated man pages this is not possible (at least currently), so
> > > as manpages-l10n we have to decide which upstream to follow.
> > >
> > > Until now we chose System-V over Systemd. However, this bug report
> > > showed that this causes confusion and I will ask manpage-l10n upstream
> > > to switch Debian to Systemd as well.
> >
> > I see that manpage-l10n upstream switching to the default init makes sense 
> > for
> > the majority.
> >
> > > Since all other distributions we support already use the Systemd
> > > version, this means the translations we currently have we vanish for
> > > Sysv-Init users if nothing else happens. (#3 below)
> > >
> > > I can propose three courses of action, in the order of my preference:
> > >
> > > 1. Sysv core adopts po4a and includes the translation framework as
> > >well as the translations (see below for the overview). I will
> > >provide you help on this (in January), probably Mario (the upstream
> > >maintainer of manpage-l10n) might give you some help as well. Then
> > >the man pages will keep up to date (see rationale in 2) and more
> > >translators / languages can be easily integrated, if translators
> > >pop up.
> >
> > Indeed, to me, this seems the cleanest solution in the long run. Thanks for 
> > the
> > offer of help.
>
> Yes, this offer stands. I'll can support you in January 2022 on doing
> this, meanwhile Mario, who is helped other projects adopting po4a,
> might give some advice as well.
>
OK, it is in my favor to both keep existing man page translations
alive (acknowledging the work of the previous translators) and
integrate Po4a-based translations into upstream projects, instead of
maintaining them in an external translation project. Give me some days
to prepare a Po4a framework and migrate the existing .po files. I've
already checked out the Git repo at savannah.nongnu.org. I would
create the changes in one single (and quite big) Git diff, is this OK
for you? Or is there even a mirror at Github or Gitlab or wherever
else where I could create a pull request?

Best Regards,
Mario

Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready

[Mario Volterra]

Hello Marc and Corey,
This really helped a lot!
I have added to /lib/systemd/system/ser2net.service

After=network-online.target
Wants=network-online.target

ad below and rebooted the pi and upon restart ser2net started successfully!

```
[Unit]
Description=Serial port to network proxy
Documentation=man:ser2net(8)
After=network-online.target
Wants=network-online.target

[Service]
EnvironmentFile=-/etc/default/ser2net
ExecStart=/usr/sbin/ser2net -n -c $CONFFILE -P /run/ser2net.pid
Type=exec
Restart=on-failure

[Install]
WantedBy=multi-user.target
```

Thank you a lot!!!

Best Regards,

Mario

‐‐‐ Original Message ‐‐‐

Il sabato 27 novembre 2021 12:25 PM, Marc Haber 
 ha scritto:

> Hi Mario,
>
> after Corey has given some input, we can try finding out what happens on
>
> your Pi. Does Raspbian use Network-Manager? systemd-networkd? ifupdown?
>
> You can try adding
>
> After=network-online.target
>
> Wants=network-online.target
>
> to the [Unit] stanza of ser2net.service.
>
> According to
>
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ you
>
> need to enable the correct wait-online.service matching your network
>
> management software (NetworkManager, systemd-networkd, ifupdown etc) for
>
> this to reliably work.
>
> Greetings
>
> Marc

Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready

[Mario V]

Package: ser2net
Version: 4.3.3-1
Severity: important
X-Debbugs-Cc: mario@volterra.cloud

Dear Maintainer,

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

   * What led up to the situation?
Installed, before upgrade to Debian Bullseye it worked fine on buster 
(raspberry Pi0 W)
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
sudo apt install ser2net , edit /etc/ser2net/ser2net.conf, sudo systemctl 
enable ser2net && sudo systemctl start ser2net
   * What was the outcome of this action?
the service started
   * What outcome did you expect instead?
When rebooting the Pi0 on sudo systemctl status ser2net I get
```
 ser2net[625]: Invalid port name/number: Invalid data to parameter on line 30 
column 0
```

and it's not working until I run again `sudo systemctl restart ser2net` , in 
buster it was working just fine.


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv6l

Kernel: Linux 5.10.63+
Kernel taint flags: TAINT_CRAP
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)

Versions of packages ser2net depends on:
ii  init-system-helpers  1.60
ii  libc62.31-13+rpt2+rpi1
ii  libgensio0   2.2.4-1
ii  libyaml-0-2  0.2.2-1
ii  lsb-base 11.1.0+rpi1

ser2net recommends no packages.

Versions of packages ser2net suggests:
pn  telnet  

-- Configuration Files:
/etc/ser2net.yaml changed:
%YAML 1.1
---
define:  \r\nser2net port \p device \d [\B] (Debian GNU/Linux)\r\n\r\n
connection: 
  accepter: tcp,20108
  connector: serialdev,/dev/ttyAMA0,115200n81,local
  options:
kickolduser: true


-- no debconf information

Bug#994250: simple-scan: Brightness and Contrast settings do not have any effect (CanoScan Lide 35)

[Mario Sperl]

Package: simple-scan
Version: 3.38.1-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
I often need b/w scans, but these are always too dark
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to set the brightness control to higher levels
   * What was the outcome of this action?
No effect
   * What outcome did you expect instead?
Controllable image brightness/contrast

The problem occured both on a upgraded system and on a fresh Debian 11
installation.


-- Package-specific info:

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.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 simple-scan depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-2
ii  dbus-x11 [dbus-session-bus]   1.12.20-2
ii  dconf-gsettings-backend [gsettings-backend]   0.38.0-2
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libcolord21.4.5-3
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libglib2.0-0  2.66.8-1
ii  libgtk-3-03.24.24-4
ii  libgusb2  0.3.5-1
ii  libpackagekit-glib2-181.2.2-2
ii  libsane1  1.0.31-4.1
ii  libwebp6  0.6.1-2.1
ii  libwebpmux3   0.6.1-2.1
ii  xdg-utils 1.1.3-4.1
ii  zlib1g1:1.2.11.dfsg-2

simple-scan recommends no packages.

simple-scan suggests no packages.

-- no debconf information

Bug#993257: bind9: /etc/default/bind9 renamed in bullseye

[Mario Thomann]

Package: bind9
Version: 1:9.16.15-1
Severity: normal
Tags: d-i

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

in bullseye /etc/default/bind9 is not considered anymore (like in
previous versions). Now it have to be /etc/default/named 
This should be mentioned in the upgrade process




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

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

Versions of packages bind9 depends on:
ii  adduser3.118
ii  bind9-libs 1:9.16.15-1
ii  bind9-utils1:9.16.15-1
ii  debconf [debconf-2.0]  1.5.77
ii  dns-root-data  2021011101
ii  init-system-helpers1.60
ii  iproute2   5.10.0-4
ii  libc6  2.31-13
ii  libcap21:2.44-1
ii  libfstrm0  0.6.0-1+b1
ii  libjson-c5 0.15-2
ii  liblmdb0   0.9.24-1
ii  libmaxminddb0  1.5.2-1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libssl1.1  1.1.1k-1
ii  libuv1 1.40.0-2
ii  libxml22.9.10+dfsg-6.7
ii  lsb-base   11.1.0
ii  netbase6.3
ii  zlib1g 1:1.2.11.dfsg-2

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind-doc   
ii  bind9-dnsutils [dnsutils]  1:9.16.15-1
ii  dnsutils   1:9.16.15-1
pn  resolvconf 
pn  ufw

-- Configuration Files:
/etc/bind/db.root [Errno 2] No such file or directory: '/etc/bind/db.root'
/etc/bind/named.conf.local changed [not included]
/etc/bind/named.conf.options changed [not included]
/etc/default/named changed [not included]

-- debconf information:
  bind9/start-as-user: bind
  bind9/different-configuration-file:
  bind9/run-resolvconf: false

Bug#993160: xz-utils doesn't contain translated man pages

[Mario Blättermann]

Package: xz-utils
Version: 5.2.5-2

Hello,

the upstream tarball contains some man pages translated into German.
Please add them to the downstream package (this applies also to
xzdec). To get the man pages installed, probably po4a is needed as a
build requirement.

Best Regards,
Mario

Bug#974220: #974220 libreoffice-writer: Double paste in Writer

[Mario J]

Double paste happens in Writer, Calc and other LO app.

This problem is specific for KDE-LO integration through Qt.

Ii tested:

Without following packages installed:
libreoffice-kde5 1:7.0.4-4
libreoffice-kf5 1:7.0.4-4
libreoffice-plasma 1:7.0.4-4
libreoffice-qt5 1:7.0.4-4

$libreoffice
Works, but with uggly GTK interface


Only with libreoffice-qt5 1:7.0.4-4 installed.

$libreoffice
Works, but with uggly GTK interface

$export SAL_USE_VCLPLUGIN=qt5; libreoffice --writer
Do not works. Past twice any text.

Linux user 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 
GNU/Linux

libc6 2.31-12
LibreOffice 7.0.4.2 00(Build:2)

Best regards,

Mario

Bug#988584: manpages-hu: Contains undistributable content - All rights reserved

[Mario Blättermann]

Hello,

Helge Kreutzmann  schrieb am So., 16. Mai 2021, 12:27:

> Package: manpages-hu
> Version: 20010119-7
> Severity: serious
> Justification: Policy 2.3
> X-Debbugs-Cc: Mario Blättermann 
>
> Short:
> man8/ssh.8 states:
> .\" Copyright (c) 1995 Tatu Ylonen , Espoo, Finland
> .\"All rights reserved
>
> Long:
> The copyright situation is very unclear. I reviewed some files and besides
> the above one some are "GNU licensed" (without version), some require
> redistribution of copyright information in binary versions (I'm not sure
> if
> 2.3 Nr.3 remedies this), while others don't come with any statement at all.
> And debian/copyright places the burden of proof on the users in case
> comercial
> distribution is intended (e.g. Debian downstreams like Ubuntu). I wonder
> how
> this passed debian-legal?
>
> (This is just a selection, e.g. man.7,tsort.1,as.1 are interesting as
> well…)
>
> I tried looking at the mentioned upstream homepage, i.e.
> http://lme.linux.hu/forditas/index.html
> but this page is down atm.
>
> To resolve this bug, I suggest the following:
> 1. Remove all pages like ssh.8 which are clearly not distributable
>(After contacting with upstream or the respective authors they might
> be included in later versions again, if the license is updated)
>
> 2. Create a machine readable copyright including all authors (both of the
>english version and the respective translators) and the respective
> licenses.
>
> 3. Get the copyrights reviewed, e.g. on debian-legal, possibly catching
> more pages
>which cannot be distributed.
>
> 4. Check with upstream about a newer version. The pages are *old*. Is this
> really a
>service to your users?


See below for the plans to get rid of this outdated stuff.


> 5. Talk to manpages-l10n for integration of those pages, where copyright
> allows so.
>This way the maintance both for legal reasons and for updating (we use
> po4a) is
>vastly improved. Bonus if some translators are available, who could
> update the
>pages (its much easier with po4a).
>

We are planning to merge the remaining outdated manpages-* packages into
manpages-l10n anyway. So manpages-hu will be the next candidate for the
import. I will create a framework for Hungarian soon, and import the old
files step by step. The creation of the translated versions remains
disabled until the import is finished; once it is done, manpages-hu needs
to be removed from Debian to avoid package conflicts.

Best Regards,
Mario

Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c error:0 in fwupdmgr[423000+15000]

[Limonciello, Mario]

As an experiment, can you please try to disable the "cpu" plugin in 
/etc/fwupd/daemon.conf?
Add to "BlacklistPlugins" list.

> -Original Message-
> From: Martin-Éric Racine 
> Sent: Wednesday, March 10, 2021 5:14
> To: Julien Cristau
> Cc: 977...@bugs.debian.org; Bernhard Übelacker
> Subject: Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c
> error:0 in fwupdmgr[423000+15000]
> 
> 
> [EXTERNAL EMAIL]
> 
> ke 10. maalisk. 2021 klo 13.08 Julien Cristau (jcris...@debian.org) kirjoitti:
> >
> > On Wed, Mar 10, 2021 at 01:01:30PM +0200, Martin-Éric Racine wrote:
> > > This could indeed be it. The baseline for Bullseye still is a basic
> > > 686. Additionally, the lowest Linux kernel for i386 is linux-image-686
> > > which is configured for Geode. Still, the bug just appeared a few days
> > > ago when the package in Testing was updated. This seems like a
> > > regression.
> > >
> > You filed this 4 months ago, so it seems rather older?
> 
> Apparently, it comes and goes.  It started showing up in 'coredumpctl
> list' just a few days ago. That's when I sent the output to the bug.
> 
> Martin-Éric

Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0 sp:bf98504c error:0 in fwupdmgr[423000+15000]

[Limonciello, Mario]

Yes, I forgot it renamed - that's right.
Also I didn't properly acknowledge the crash was in the client not the daemon, 
so this wouldn't have done anything anyway.

I tend to think this is a compiler issue, not a fwupd upstream or packaging 
issue.

> -Original Message-
> From: Martin-Éric Racine 
> Sent: Wednesday, March 10, 2021 10:25
> To: Limonciello, Mario
> Cc: 977...@bugs.debian.org; Julien Cristau; Bernhard Übelacker
> Subject: Re: Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0
> sp:bf98504c error:0 in fwupdmgr[423000+15000]
> 
> 
> [EXTERNAL EMAIL]
> 
> You probably meant this:
> 
> DisabledPlugins=test;test_ble;invalid;cpu
> 
> Still signal 4.
> 
> TIMEPID   UID   GID SIG COREFILE  EXE
> Wed 2021-03-10 18:23:39 EET1322 0 0   4 error
> /usr/bin/fwupdmgr
> 
> ke 10. maalisk. 2021 klo 17.49 Limonciello, Mario
> (mario.limoncie...@dell.com) kirjoitti:
> >
> > As an experiment, can you please try to disable the "cpu" plugin in
> /etc/fwupd/daemon.conf?
> > Add to "BlacklistPlugins" list.
> >
> > > -Original Message-
> > > From: Martin-Éric Racine 
> > > Sent: Wednesday, March 10, 2021 5:14
> > > To: Julien Cristau
> > > Cc: 977...@bugs.debian.org; Bernhard Übelacker
> > > Subject: Bug#977043: fwupdmgr[1191] trap invalid opcode ip:4247d0
> sp:bf98504c
> > > error:0 in fwupdmgr[423000+15000]
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > ke 10. maalisk. 2021 klo 13.08 Julien Cristau (jcris...@debian.org)
> kirjoitti:
> > > >
> > > > On Wed, Mar 10, 2021 at 01:01:30PM +0200, Martin-Éric Racine wrote:
> > > > > This could indeed be it. The baseline for Bullseye still is a basic
> > > > > 686. Additionally, the lowest Linux kernel for i386 is linux-image-686
> > > > > which is configured for Geode. Still, the bug just appeared a few days
> > > > > ago when the package in Testing was updated. This seems like a
> > > > > regression.
> > > > >
> > > > You filed this 4 months ago, so it seems rather older?
> > >
> > > Apparently, it comes and goes.  It started showing up in 'coredumpctl
> > > list' just a few days ago. That's when I sent the output to the bug.
> > >
> > > Martin-Éric
> >

Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Limonciello, Mario]

Paul,

I don't have the power to manually run it. So there is nothing I can do. With 
the new 1.5.6-1 upload someone will need to manually run it again.

Get Outlook for Android<https://aka.ms/ghei36>


From: Paul Gevers 
Sent: Thursday, February 18, 2021, 00:09
To: 973...@bugs.debian.org
Subject: Bug#973715: RE: Bug#973715: fwupd-amd64-signed holding off fwupd 
update results in segfaulting binary

Hi Mario,

LOn Mon, 16 Nov 2020 16:01:34 + "Limonciello, Mario"
 wrote:
> As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
> It needs to be done when 1.5.1-2 is ready to migrate.

There's users of unstable too. In my opinion, if you can't relax the
constraints, you'll have to kick it off as soon as it's needed in
unstable, not when it's ready to migrate.

Paul

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

[Mario Blättermann]

Am Mi., 10. Feb. 2021 um 16:52 Uhr schrieb Helge Kreutzmann
:
>
> Hello Mario,
> On Wed, Feb 10, 2021 at 02:53:14PM +0100, Mario Blättermann wrote:
> > to mention that Craig just released procps-ng-3.3.17 which also ships
> > translated man pages. To avoid file conflicts, I've fixed the procps
> > .po files in manpages-l10n in a way that the man pages don't get built
> > anymore, except for Buster (for possible backports). Then I've
> > released v4.9.2 which now needs to be packaged to fix the file
> > conflicts.
>
> I saw your update and release. Does this version already have a file
> conflict with manpages-es-extra? I think the initial plan was to
> include them in march, correct?
>
The plan is to ship the imported (and until then hopefully somewhat
updated) files with the next major release of manpages-l10n in
march/april. But it wouldn't make sense to add the files to the Git
repo as late as possible, giving translators no time to work on the
updates.

> I contacted the maintainer (cf. #980885, which you also contributed
> to), but he did not respond yet, unfortunately.
>
I know... The more time we loose, the less chance is to get rid of the
manpages-es-extra package before Bullseye gets frozen. But let's
concentrate first on the file conflicts raised with psmisc and procps.

Best Regards,
Mario

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

[Mario Blättermann]

Hello,

to mention that Craig just released procps-ng-3.3.17 which also ships
translated man pages. To avoid file conflicts, I've fixed the procps
.po files in manpages-l10n in a way that the man pages don't get built
anymore, except for Buster (for possible backports). Then I've
released v4.9.2 which now needs to be packaged to fix the file
conflicts.

Best Regards,
Mario


Am Di., 9. Feb. 2021 um 19:40 Uhr schrieb Helge Kreutzmann
:
>
> Hello Craig,
> thank you very much for your support. I was tired and frustrated
> yesterday.
>
> On Mon, Feb 08, 2021 at 04:34:19PM -0500, Craig Small wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >   The first problem I can see is you haven't pushed the git tags. Salsa
> > doesn't know about the 4.9.1 update[1]
> > git push --tags should do it
>
> This says "Everything up-to-date"
>
> > So it fails to build for me here
> > $ gbp buildpackage --git-pbuilder
> > gbp:info: Building with (cowbuilder) for sid
> > gbp:error: upstream/4.9.1 is not a valid treeish
> >
> > "not valid teeish" = cant find the tag.
>
> I resolved this one by (manually) copying the build tree in place. But
> this build system is very opaque to me.
>
> > For your problem, I think you've not included some file, but can't see the
> > problem myself as I need the tag.
> >
> > Don't give up, it does look all bewildering but you'll get there in the
> > end.
>
> Based on the (never uploaded 4.9.1-1 version) I build version 4.9.1-2 "the
> good old way", i.e. without using git, gbp and similar. This worked
> just fine.
>
> You can pick it up from:
> https://www.helgefjell.de/data/manpages-l10n_4.9.1-2_set.tar.xz
> https://www.helgefjell.de/data/manpages-l10n_4.9.1-2_set.tar.xz.sig
>
> Again, this contains all files for and from the build.
>
> When Tobias has more time again, we might need to repair the git
> repository (I'm confident Tobias is able to fix everything), but
> right now I'm more interested in working packages for users.
>
> As reported by Sedat in 982372 the version I prepared now worked for
> him, so could you upload this version?
>
> Thanks again for your support.
>
> Greetings
>
>helge
>
> --
>   Dr. Helge Kreutzmann deb...@helgefjell.de
>Dipl.-Phys.   http://www.helgefjell.de/debian.php
> 64bit GNU powered gpg signed mail preferred
>Help keep free software "libre": http://www.ffii.de/

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

[Mario Blättermann]

Hello,


> > 23.4-2, which I will have to update with these control lines, will have:
> > Breaks: manpages-de (<< 4.9.1-1)
> > Replaces: manpages-de (<< 4.9.1-1)
>
> > Does that seem to make sense to everyone?
>
> Although it appears a little counter-intuitive, according to
> https://www.debian.org/doc/debian-policy/ch-relationships.html
>
> This appears to be correct.
>
I'm not familiar with Debian packaging, but it looks a bit strange...
The »Breaks:« line seems to be OK, but if psmisc »replaces«
manpages-de-4.2.0 and someone installs psmisc-23.4, could it happen
that manpages-de-4.2.0 will be deleted, without updating it to v4.9.1?

Best Regards,
Mario

Bug#982059: manpages-de,psmisc: File conflict between psmisc and manpages-de: '/usr/share/man/de/man1/fuser.1.gz

[Mario Blättermann]

Hello all,

our project manpages-l10n is actually the second best solution to
provide translated man pages. The files are always somewhat older than
the original ones, because we download distribution packages, extract
the man pages, translate the contents and release a new version every
three months. If man page translations are maintained directly in the
appropriate upstream projects, there's no delay, and the translated
versions are always up-to-date. That's why the latter way is always to
prefer. For this reason I try to encourage upstream projects to
implement a po4a stack -- with varying degrees of success...

Of course, I knew about the raised file conflicts. Yesterday we have
released manpages-l10n v4.9.1 [1], without the psmisc translations.
This solves the problem without forcing packagers to find some
workarounds -- at the risk of that they disable the conflicting man
pages in psmisc instead of manpages-l10n. Once the maintainers of the
Debian package (CC'ing them) have updated it, all is fine again.

BTW, the same applies to procps-ng. Once the final v3.3.17 has been
released, I will do a bugfix release of manpages-l10n with the procps
man pages removed.

[1] https://salsa.debian.org/manpages-l10n-team/manpages-l10n/-/tags/v4.9.1

Best Regards,
Mario


Am So., 7. Feb. 2021 um 01:51 Uhr schrieb Craig Small :
>
> Yep, psmisc now ships with translated packages. So fuser.1 and friends are in 
> two places.
>
> So manpages-de has fuser, killall, peekfd, pslog and pstree but not prstat. 
> There is also manpages-nl and manpages-pl but neither of those languages are 
> in psmisc. psmisc has ft, pt_BR, ru and uk and the corresponding manpage-* 
> packages don't have the psmisc man pages.
>
> So the psmisc overlap is only with manpages-de.
>
> We can tackle this a few ways, but Debian should only ship one! As luck would 
> have it, both manpages-de[1] and the upstream issue for psmisc[2] come the 
> same person, Mario Blättermann who I have CC'ed.
>
> Hi Mario, as upstream for both sets of translations, what's your future 
> plans? Keep both? Ship only one or prefer one over the other?  I've happy 
> enough to either remove the clashing de manpages or put a Replaces line in to 
> override it, but I'd like to line it up with what upstream for both is 
> planning on doing.
>
>  - Craig
>
> 1: 
> https://salsa.debian.org/debian/manpages-l10n/-/blob/master/debian/copyright#L1890
> 2: https://gitlab.com/psmisc/psmisc/-/issues/22
>
>
> On Sat, 6 Feb 2021 at 16:48, Axel Beckert  wrote:
>>
>> Package: manpages-de,psmisc
>> Severity: serious
>> Version: manpages-de/4.2.0-1
>> Version: psmisc/23.4-1
>>
>> Hi,
>>
>> there seems a new file conflict between manpages-de (uploaded in
>> December) and the most recent psmisc upload:
>>
>> As I first run into it:
>>
>> Unpacking psmisc (23.4-1) over (23.3-1) ...
>> dpkg: error processing archive 
>> /tmp/apt-dpkg-install-IViNm3/17-psmisc_23.4-1_i386.deb (--unpack):
>>  trying to overwrite '/usr/share/man/de/man1/fuser.1.gz', which is also in 
>> package manpages-de 4.2.0-1
>>
>> But of course also happens the opposite way:
>>
>> Unpacking manpages-de (4.2.0-1) ...
>> dpkg: error processing archive 
>> /var/cache/apt/archives/manpages-de_4.2.0-1_all.deb (--unpack):
>>  trying to overwrite '/usr/share/man/de/man1/fuser.1.gz', which is also in 
>> package psmisc 23.4-1
>>
>> Please decide which package should ship that man page.
>>
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers unstable
>>   APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
>> (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), 
>> (1, 'buildd-experimental')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 5.10.0-1-amd64 (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 /bin/dash
>> Init: sysvinit (via /sbin/init)
>> LSM: AppArmor: enabled

Bug#980885: manpages-es-extra: Suitable for Bullseye?

[Mario Blättermann]

Hello Javier,

as Helge already wrote, manpages-es-extra is far too outdated to worth
shipping it in Bullseye. It is *now* the time to get rid of this
package.

Tomorrow we will release a new version of manpages-l10n, which will
contain Spanish translations for the first time, after manpages-es
vanished from Debian (for good reasons). I'm almost finished with the
import of the plain text translations from manpages-es-extra, so I
think the .po files will be available for translators a few days after
the upcoming release. This means in return: Because manpages-l10n
doesn't distinguish between »es« and »es-extra« files, the release in
march will include the newly imported .po files – and raise file
conflicts. I think you agree with me that it's better to have 100 .po
files (at least 80% translated) which are up-to-date than 200 terribly
outdated plain text translations which nobody benefits of.

Best Regards,
Mario

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

I'm unsure what to do here, it seems to me that there is a problem with systemd 
using DynamicUser and sssd when the service uses dbus.
Perhaps this should be re-assigned to systemd.

> -Original Message-
> From: Thomas Stewart 
> Sent: Thursday, January 28, 2021 1:36
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: RE: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> Yes, I'm using sssd against FreeIPA.
> 
> Tom
> 
> 
> On 28 January 2021 02:12:11 GMT, "Limonciello, Mario"
>  wrote:
> >Are you by chance using NFS mounted directories?  Or external entity
> >for authentication such as LDAP or SSSD?

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

Are you by chance using NFS mounted directories?  Or external entity for 
authentication such as LDAP or SSSD?

> -Original Message-
> From: Thomas Stewart 
> Sent: Wednesday, January 27, 2021 8:33
> To: Limonciello, Mario
> Cc: 943...@bugs.debian.org
> Subject: Re: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> On 27 Jan 2021, at 14:18, Limonciello, Mario wrote:
> > Can you check if fwupdmgr works as a standard user to talk to the daemon for
> you?
> 
> As a normal user I can run "fwupdmgr --version" fine[0].
> 
> However if I amend the unit to run the above[1] the output stops before
> daemon version[2].
> 
> Kind Regards
> --
> Tom
> 
> [0]
> $ id
> uid=1000(thomas) gid=1000(thomas)
> groups=1000(thomas),20(dialout),27(sudo),128(docker)
> $
> $ /usr/bin/fwupdmgr --version
> client version: 1.5.5
> compile-time dependency versions
> gusb:   0.3.5
> 
> daemon version: 1.5.5
> $
> 
> [1]
> ExecStart=/usr/bin/fwupdmgr --version
> 
> [2]
> Jan 27 14:24:38 systemd[1]: Starting Refresh fwupd metadata and update motd...
> Jan 27 14:24:38 fwupdmgr[199579]: client version:1.5.5
> Jan 27 14:24:38 fwupdmgr[199579]: compile-time dependency versions
> Jan 27 14:24:38 fwupdmgr[199579]: gusb:0.3.5
> Jan 27 14:24:38 fwupdmgr[199579]: Failed to connect to daemon: Exhausted all
> available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)
> Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE
> Jan 27 14:24:38 systemd[1]: fwupd-refresh.service: Failed with result 'exit-
> code'.
> Jan 27 14:24:38 systemd[1]: Failed to start Refresh fwupd metadata and update
> motd.

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

Can you check if fwupdmgr works as a standard user to talk to the daemon for 
you?

> -Original Message-
> From: Thomas Stewart 
> Sent: Wednesday, January 27, 2021 5:42
> To: 943...@bugs.debian.org
> Subject: Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh
> fwupd metadata and update motd.
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> I'm running testing/sid and have fwupd-1.5.5-2 installed. I have found
> that when fwupd-refresh.service restarts either with the timer or
> manually that if DynamicUser=yes is enabled then the service fails to
> start[0]. When I remove DynamicUser from the unit it restarts fine.
> 
> I noticed that the unit has: CacheDirectory=fwupdmgr but the
> metadata seems to live in /var/cache/fwupd[1].
> 
> After purging the package and removing /var/cache/fwup* /var/lib/fwupd
> /var/cache/private/fwupd and reinstalling I can see the /var/cache dirs
> created[2] but the service does not start.
> 
> When removing the "StandardError=null" directive from the unit I get an
> additional error[3], which seems to indicate it's having trouble
> talking to dbus.
> 
> Kind Regards
> --
> Tom
> 
> [0]
> $ sudo systemctl restart fwupd-refresh.service
> Job for fwupd-refresh.service failed because the control process exited with
> error code.
> See "systemctl status fwupd-refresh.service" and "journalctl -xe" for details.
> $
> 
> $ sudo journalctl -f
> Jan 27 10:09:30 systemd[1]: Starting Refresh fwupd metadata and update motd...
> Jan 27 10:09:31 fwupdmgr[176638]: (fwupdmgr:176638): GLib-DEBUG: 10:09:31.089:
> setenv()/putenv() are not thread-safe and should not be used after threads are
> created
> Jan 27 10:09:31 systemd[1]: fwupd-refresh.service: Main process exited,
> code=exited, status=1/FAILURE
> Jan 27 10:09:31 systemd[1]: fwupd-refresh.service: Failed with result 'exit-
> code'.
> Jan 27 10:09:31 systemd[1]: Failed to start Refresh fwupd metadata and update
> motd.
> $
> 
> [1]
> $ find /var/cache/fw*
> /var/cache/fwupd
> /var/cache/fwupd/metadata.xmlb
> /var/cache/fwupd/quirks.xmlb
> /var/cache/fwupd/metainfo.xmlb
> /var/cache/fwupdmgr
> $
> 
> [2]
> $ sudo ls -la /var/cache/fwupdmgr /var/cache/private/fwupdmgr
> lrwxrwxrwx 1 root  root16 Jan 27 10:57 /var/cache/fwupdmgr ->
> private/fwupdmgr
> 
> /var/cache/private/fwupdmgr:
> total 8
> drwxr-xr-x 2 62803 62803 4096 Jan 27 10:57 .
> drwx-- 3 root  root  4096 Jan 27 10:57 ..
> $
> 
> [3]
> Jan 27 11:09:30 fwupdmgr[189035]: Failed to connect to daemon: Exhausted all
> available authentication mechanisms (tried: EXTERNAL) (available: EXTERNAL)

Bug#980570: fwupd: obsolete-conffile /etc/fwupd/ata.conf

[Limonciello, Mario]

Thanks for the report.  It's an oversight that it didn't get removed.  Will 
have a future upload resolve it.

> -Original Message-
> From: Thorsten Glaser 
> Sent: Wednesday, January 20, 2021 12:25
> To: Debian Bug Tracking System
> Subject: Bug#980570: fwupd: obsolete-conffile /etc/fwupd/ata.conf
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.5.5-2
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: adequate obsolete-conffile
> X-Debbugs-Cc: t...@mirbsd.de
> 
> adequate reports:
> 
> fwupd: obsolete-conffile /etc/fwupd/ata.conf
> 
> Is this file really to be removed or is there a bug in the package
> that it’s not shipped any more?
> 
> If the former, please integrate relevant maintainer script magic to
> make it disappear properly.
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
> 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-
> debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads)
> Kernel taint flags: TAINT_WARN
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /bin/lksh
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-9
> ii  libcurl3-gnutls7.74.0-1
> ii  libefiboot137-6
> ii  libelf10.182-3
> ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.5.5-2
> ii  libfwupdplugin11.5.5-2
> ii  libglib2.0-0   2.66.4-1
> ii  libgnutls303.7.0-5
> ii  libgudev-1.0-0 234-1
> ii  libgusb2   0.3.5-1
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.6.0-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsqlite3-0   3.34.0-1
> ii  libtss2-esys-3.0.2-0   3.0.3-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   2.0-1
> 
> Versions of packages fwupd recommends:
> pn  bolt   
> ii  dbus   1.12.20-1
> pn  fwupd-signed   
> ii  python33.9.1-1
> pn  secureboot-db  
> ii  udisks2-without-systemd [udisks2]  2.1.3-5~wtf2
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#943343: fwupd: fwupd-refresh.service failed to start Refresh fwupd metadata and update motd.

[Limonciello, Mario]

On Thu, 19 Mar 2020 15:02:13 +0100 Diederik de Haas  
wrote:
> On donderdag 19 maart 2020 14:59:56 CET mario.limoncie...@dell.com wrote:
> > Sorry - I see now that was from a while back.
>
> And also a different user (OP).

After some upstream discussion, any remaining issues with 1.3.x this is 
expected to be root caused in a CDN caching problem that will be transient.  
The architecture was changed in the 1.4.x series, so please if this is still 
present in 1.4.x or 1.5.x please notify.

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Limonciello, Mario]

> -Original Message-
> From: Lukas Pirl 
> Sent: Wednesday, January 13, 2021 13:51
> To: Limonciello, Mario
> Cc: 980...@bugs.debian.org
> Subject: Re: Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
> 
> Thanks for your quick reply, Mario.
> 
> On Wed, 2021-01-13 16:10 +, Limonciello, Mario wrote as excerpted:
> > I don't think it's a true dependency.  You can use fwupdtool without it.
> > It's only needed for fwupdmgr.
> > Perhaps a Recommends would be better?
> 
> I didn't know if fwupd is really useful without fwupdmgr. If using fwupd
> without fwupdmgr is a common use case then yes, listing dbus as recommended
> package is probably appropriate.
> 

I don't believe we have any evidence to say which use cases are more "common".
But it's a use case that is supported by upstream, particularly since you can
now optionally build without daemon/client and fwupdtool is placed in PATH by
default.

As such, I'll add a Recommends.

> > That being said I don't think it would solve it for you.  Systemd has dbus
> > as a Recommends and you still appear to not have it.
> 
> Even if systems are configured to not install recommended packages by default
> (you are right, it does not solve it for me), then the list of recommended
> packages can provide helpful clues, at least.

OK.

Bug#980049: fwupd: Should fwupd specify dbus as a dependency?

[Limonciello, Mario]

I don't think it's a true dependency.  You can use fwupdtool without it.  It's 
only needed for fwupdmgr.
Perhaps a Recommends would be better?

That being said I don't think it would solve it for you.  Systemd has dbus as a 
Recommends and you still appear to not have it.

> -Original Message-
> From: lukas 
> Sent: Wednesday, January 13, 2021 6:55
> To: Debian Bug Tracking System
> Subject: Bug#980049: fwupd: Should fwupd specify dbus as a dependency?
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.5.3-2
> Severity: important
> 
> Dear Maintainers,
> 
> thanks for maintaining this package and taking the time to consider this bug
> report.
> 
> On a minimal system, it happened to me that when installing fwupd, dbus is
> has not been installed as a dependency.
> Without dbus, fwupd turned out to be unusable ("Failed to connect to daemon"
> on ``fwupdmgr refresh``).
> 
> Do we maybe need to list the package "dbus" as a dependency of "fwupd"?
> 
> Cheers,
> 
> Lukas
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-9
> ii  libcurl3-gnutls7.74.0-1
> ii  libefiboot137-6
> ii  libelf10.182-3
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.5.3-2
> ii  libfwupdplugin11.5.3-2
> ii  libglib2.0-0   2.66.4-1
> ii  libgudev-1.0-0 234-1
> ii  libgusb2   0.3.5-1
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.6.0-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsqlite3-0   3.34.0-1
> ii  libsystemd0247.2-4
> ii  libtss2-esys-3.0.2-0   3.0.3-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   2.0-1
> 
> Versions of packages fwupd recommends:
> pn  bolt   
> pn  fwupd-signed   
> ii  python33.9.1-1
> pn  secureboot-db  
> ii  udisks22.9.1-2
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#976639: flashrom does not support jlink_spi

[Limonciello, Mario]

> 
> On Tue, 2020-12-08 at 05:45 +, Limonciello, Mario wrote:
> > I checked and meson.build is missing jlink support.  So this needs to
> > be fixed upstream to enable in the package.
> 
> Thanks, I didn't know that there is a meson build option. I pushed a
> fix upstream: https://review.coreboot.org/c/flashrom/+/48478

Thanks!  I'll watch for that to be merged and then pull it into the Debian 
package when ready.

Bug#976639: flashrom does not support jlink_spi

[Limonciello, Mario]

I checked and meson.build is missing jlink support.  So this needs to be fixed 
upstream to enable in the package.

Bug#944247: xen domU crashes under high i/o load if you use qcow2 images

[Mario Bregulla]

i unfortunately don't have the time and financial capacity to procure identical 
servers for testing. since the machines are running in production we now use 
raw images, since then everything is running stable.

> Have you been able to find out more about the problem yet, in the last
> year? Have you taken steps to try narrow down the problem by
> investigating other combinations of used software with/without xen? I
> mean, for example, reboot into just Linux and mount the qcow2 image
> somewhere and do the same load test to see if it's also happening when
> eliminating Xen from the equation?
> 



-- 
-- 
Mit freundlichen Grüßen
Mario Bregulla

muneX

Mobil: 0160 / 94 62 09 02

i...@munex.de
www.munex.de

UStNr: DE 149371863
Steuernummer: 31/020/33191

Bug#973715: fwupd-amd64-signed holding off fwupd update results in segfaulting binary

[Limonciello, Mario]

> -Original Message-
> From: Matteo Settenvini  On Behalf Of Matteo Settenvini
> Sent: Saturday, November 14, 2020 7:35
> To: 973...@bugs.debian.org
> Subject: Bug#973715: fwupd-amd64-signed holding off fwupd update results in
> segfaulting binary
> 
> The problem suddenly become worse.
> 
> Now that fwupd 1.5.1 has landed in sid, and some dependencies
> apparently changed, the fwupd-amd64-signed package holding off fwupd
> upgrade and forcing it to stay at version 1.4.6-2, is breaking the
> system:
> 
> nov 14 14:29:52 rosebud kernel: fwupd[11192]: segfault at 8 ip
> 56035dbcc548 sp 7ffddfa64b00 error 4 in
> fwupd[56035dbaf000+2]
> nov 14 14:29:52 rosebud kernel: Code: c7 44 24 08 00 00 00 00 66 2e 0f
> 1f 84 00 00 00 00 00 48 8b 11 8b 44 24 10 be 01 00 00 00 4c 8b 34 c2>
> nov 14 14:29:52 rosebud systemd[1]: fwupd.service: Main process exited,
> code=killed, status=11/SEGV
> 
> This goes away after uninstalling the fwupd-amd64-signed package and
> installing fwupd 1.5.1, but of course on a system with SecureBoot
> enabled, this is not helping much if you have pending BIOS updates.
> 
> Cheers,
> Matteo

1.5.1-1 won't migrate to testing as other issues came up with non-x86
architectures.  I've uploaded a 1.5.1-2 this morning that should hopefully
sort those out.

As @Steve McIntyre mentions, it's a manual process to kick off the re-signing.
It needs to be done when 1.5.1-2 is ready to migrate.  If there is another
problem that comes up (say autopkgtest fails, or some other arch still fails)
then we'll probably need to do a 1.5.1-3 and then kick it off.

Bug#974738: fwupd: FTBFS on various architectures

[Limonciello, Mario]

Yes, I'm aware. I fixed all but ppc64le in the upstream packaging. That one is 
under discussion. Will wait until that one is also fixed for next upload.

Get Outlook for Android


From: Salvatore Bonaccorso 
Sent: Saturday, November 14, 2020 7:33:16 AM
To: Debian Bug Tracking System 
Subject: Bug#974738: fwupd: FTBFS on various architectures


[EXTERNAL EMAIL]

Source: fwupd
Version: 1.5.1-1
Severity: serious
Tags: ftbfs
Justification: fails to builds from source on various architectures
X-Debbugs-Cc: car...@debian.org

Hi

The last upload of fwupd fails to build on various architectures:

https://buildd.debian.org/status/logs.php?pkg=fwupd=1.5.1-1=sid

Regards,
Salvatore

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> -Original Message-
> From: Boyuan Yang 
> Sent: Tuesday, November 3, 2020 23:45
> To: Limonciello, Mario; 973...@bugs.debian.org
> Subject: Re: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> friendly
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> 在 2020-11-03星期二的 22:21 +，Limonciello, Mario写道：
> > > -Original Message-
> > > From: Boyuan Yang 
> > > Sent: Tuesday, November 3, 2020 13:09
> > > To: sub...@bugs.debian.org
> > > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> > > friendly
> > >
> > > Package: fwupd-amd64-signed
> > > Severity: grave
> > > Version: 1.4.6+2
> > > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> > >
> > > Dear EFI Team,
> > >
> > > Package fwupd-amd64-signed currently cannot be installed on Debian
> > > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has
> > > fwupd
> > > (= 1.4.6-2+b1).
> >
> > I'm sorry can you show me where this +b1 build is?
> >
> > I don't see it mentioned in https://tracker.debian.org/pkg/fwupd
> 
> It is shown at https://buildd.debian.org/status/package.php?p=fwupd .
> If you actually install a Debian Sid system, you can also find the
> package with this version string.
> 
> 
> > > It seems obvious that such dependency relationship made
> > > fwupd/fwupd-
> > > amd64-signed not binNMU-friendly. Please consider setting a version
> > > range to allow binNMU-ed package to satisfy the dependency
> > > relationship.
> 
> Please consider reading https://wiki.debian.org/binNMU and see how can
> things be improved.
> 
> Thanks,
> Boyuan Yang

I think the problem here is that the EFI binary sign process just didn't
run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> 
> On Wed, Nov 04, 2020 at 06:30:54PM +, Limonciello, Mario wrote:
> >> 在 2020-11-03星期二的 22:21 +0000，Limonciello, Mario写道：
> >> > > -Original Message-
> >> > > From: Boyuan Yang 
> >> > > Sent: Tuesday, November 3, 2020 13:09
> >> > > To: sub...@bugs.debian.org
> >> > > Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-
> >> > > friendly
> >> > >
> >> > > Package: fwupd-amd64-signed
> >> > > Severity: grave
> >> > > Version: 1.4.6+2
> >> > > X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> >> > >
> >> > > Dear EFI Team,
> >> > >
> >> > > Package fwupd-amd64-signed currently cannot be installed on Debian
> >> > > Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has
> >> > > fwupd
> >> > > (= 1.4.6-2+b1).
> >> >
> >> > I'm sorry can you show me where this +b1 build is?
> >> >
> >> > I don't see it mentioned in https://tracker.debian.org/pkg/fwupd
> >>
> >> It is shown at https://buildd.debian.org/status/package.php?p=fwupd .
> >> If you actually install a Debian Sid system, you can also find the
> >> package with this version string.
> >>
> >>
> >> > > It seems obvious that such dependency relationship made
> >> > > fwupd/fwupd-
> >> > > amd64-signed not binNMU-friendly. Please consider setting a version
> >> > > range to allow binNMU-ed package to satisfy the dependency
> >> > > relationship.
> >>
> >> Please consider reading https://wiki.debian.org/binNMU and see how can
> >> things be improved.
> >>
> >> Thanks,
> >> Boyuan Yang
> >
> >I think the problem here is that the EFI binary sign process just didn't
> >run.  @Steve McIntyre is that supposed to be automatic now?  Or still manual?
> 
> I saw earlier that it's just happened. It's still run manually. What
> we've done for the other -signed packages to deal with the delay and
> potentially inconsistent versioning is change the dependencies.
> Instead of depending on *exactly* the same version as the signed
> package (==), we switch to >= so that a delay in the new -signed
> package being processed won't break installations.
> 

99.9% of the time that's probably sufficient.  But the moment the structure
of the NVRAM variable used by linux user space and EFI application changes
this would break.  So because of that it's safer to block installation.

Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly

[Limonciello, Mario]

> -Original Message-
> From: Boyuan Yang 
> Sent: Tuesday, November 3, 2020 13:09
> To: sub...@bugs.debian.org
> Subject: Bug#973715: fwupd-amd64-signed: Uninstallable; not binNMU-friendly
> 
> Package: fwupd-amd64-signed
> Severity: grave
> Version: 1.4.6+2
> X-Debbugs-CC: 93...@debian.org mario.limoncie...@dell.com
> 
> Dear EFI Team,
> 
> Package fwupd-amd64-signed currently cannot be installed on Debian
> Unstable/Sid. It depends on fwupd (= 1.4.6-2) while Sid only has fwupd
> (= 1.4.6-2+b1).

I'm sorry can you show me where this +b1 build is?

I don't see it mentioned in https://tracker.debian.org/pkg/fwupd

> 
> It seems obvious that such dependency relationship made fwupd/fwupd-
> amd64-signed not binNMU-friendly. Please consider setting a version
> range to allow binNMU-ed package to satisfy the dependency
> relationship.
> 
> Thanks,
> Boyuan Yang

Bug#973267: Acknowledgement (libtss2-dev: pkgconfig file included with libtss2-dev has invalid path)

[Limonciello, Mario]

Submitted this to upstream project:
https://github.com/tpm2-software/tpm2-tss/issues/1876

Bug#973267: libtss2-dev: pkgconfig file included with libtss2-dev has invalid path

[Mario Limonciello]

Package: libtss2-dev
Version: 3.0.0-1
Severity: normal
X-Debbugs-Cc: mario.limoncie...@dell.com

Dear Maintainer,

The pkgconfig file included in libtss2-dev contains an invalid path:

Name: tss2-esys
Description: TPM2 Enhanced System API library.
URL: https://github.com/tpm2-software/tpm2-tss
Version: 3.0.1
Requires.private: tss2-mu tss2-sys
Cflags: -I${includedir} -I${includedir}/tss
Libs: -ltss2-esys -L${libdir}
Libs.private: -ldl   -lcrypto

The Cflags field includes /usr/include/tss, but the include files are actually
in /usr/include/tss2.

This causes build failures like this in fwupd:

cc -Iplugins/tpm-eventlog/libfu_plugin_tpm_eventlog.so.p -Iplugins/tpm-eventlog 
-I../plugins/tpm-eventlog -I. -I.. -Ilibfwupd -I../libfwupd -Ilibfwupdplugin 
-I../libfwupdplugin -I/usr/include/libxmlb-1 -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0 
-I/usr/include/gusb-1 -I/usr/include/libusb-1.0 -I/usr/include/libsoup-2.4 
-I/usr/include/libxml2 -I/usr/include/gudev-1.0 -I/usr/include/json-glib-1.0 
-I/usr/include/tss -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 
-Werror -std=c99 -Waggregate-return -Wunused -Warray-bounds -Wcast-align 
-Wclobbered -Wdeclaration-after-statement -Wdiscarded-qualifiers 
-Wduplicated-branches -Wduplicated-cond -Wempty-body -Wformat=2 
-Wformat-nonliteral -Wformat-security -Wformat-signedness -Wignored-qualifiers 
-Wimplicit-function-declaration -Winit-self -Wlogical-op -Wmaybe-uninitialized 
-Wmissing-declarations -Wmissing-format-attribute -Wmissing-include-dirs 
-Wmissing-noreturn -Wmissing-parameter-type -Wmissing-prototypes 
-Wnested-externs -Wno-cast-function-type -Wno-address-of-packed-member 
-Wno-unknown-pragmas -Wno-deprecated-declarations 
-Wno-missing-field-initializers -Wno-strict-aliasing 
-Wno-suggest-attribute=format -Wno-unused-parameter -Wold-style-definition 
-Woverride-init -Wpointer-arith -Wredundant-decls -Wreturn-type -Wshadow 
-Wsign-compare -Wstrict-aliasing -Wstrict-prototypes -Wswitch-default 
-Wtype-limits -Wundef -Wuninitialized -Wunused-but-set-variable 
-Wunused-variable -Wvla -Wwrite-strings -fstack-protector-strong 
-D_DEFAULT_SOURCE -DFWUPD_DISABLE_DEPRECATED -D_BSD_SOURCE -D_XOPEN_SOURCE=700 
-D_GNU_SOURCE -g -O2 -fdebug-prefix-map=/build/build=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
'-DG_LOG_DOMAIN="FuPluginTpmEventlog"' -MD -MQ 
plugins/tpm-eventlog/libfu_plugin_tpm_eventlog.so.p/fu-tpm-eventlog-common.c.o 
-MF 
plugins/tpm-eventlog/libfu_plugin_tpm_eventlog.so.p/fu-tpm-eventlog-common.c.o.d
 -o 
plugins/tpm-eventlog/libfu_plugin_tpm_eventlog.so.p/fu-tpm-eventlog-common.c.o 
-c ../plugins/tpm-eventlog/fu-tpm-eventlog-common.c
cc1: error: /usr/include/tss: No such file or directory 
[-Werror=missing-include-dirs]

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

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

Versions of packages libtss2-dev depends on:
ii  libgcrypt20-dev  1.8.6-2
ii  libtss2-esys03.0.0-1

libtss2-dev recommends no packages.

libtss2-dev suggests no packages.

-- no debconf information

Bug#971238: Expose RPCNFSDOPTS in /etc/default/nfs-kernel-server

[Mario Lang]

Package: nfs-utils
Version: 1:1.3.4-4
Severity: wishlist
Tag: patch

The ability to pass extra options (like --rdma) to rpc.nfsd
is currently rather obscured.
Looking at /lib/systemd/scripts/nfs-utils_env.sh,
I see that RPCNFSDOPTS is being used.
However, there is no stub for it in /etc/default/nfs-kernel-server.

Since I was trying to enable RDMA,
mentioning that option as an example
seemed loke a good idea.

--- nfs-utils-1.3.4/debian/nfs-kernel-server.default.orig	2020-07-26 14:02:00.0 +0200
+++ nfs-utils-1.3.4/debian/nfs-kernel-server.default	2020-09-27 21:20:25.375657576 +0200
@@ -1,6 +1,10 @@
 # Number of servers to start up
 RPCNFSDCOUNT=8
 
+# Options for rpc.nfsd
+# To enable RDMA on the server, specify '--rdma' here
+RPCNFSDOPTS=""
+
 # Runtime priority of server (see nice(1))
 RPCNFSDPRIORITY=0
 

-- 
AR Mario Lang   Phone: +43 316 873 6897
Graz University of Technology  Mobile: +43 664 60 873 6897
IT-Services for research and teaching   Email: ml...@tugraz.at
Steyrergasse 30/1, 8010 Graz, Austria   Please https://useplaintext.email/

Bug#970698: Please remove amd64 from NO_PMIX_ARCH

[Mario Lang]

Package: openmpi
Version: 4.0.5-4
Severity: important

Right now, debian/rules has

NO_PMIX_ARCH:= armel mipsel amd64

This looks like an oversight.  I get an error about undefined
symbol when launching an MPI job via SLURM.  Removing amd64 from
NO_PMIX_ARCH fixes this.

-- 
AR Mario Lang   Phone: +43 316 873 6897
Graz University of Technology  Mobile: +43 664 60 873 6897
IT-Services for research and teaching   Email: ml...@tugraz.at
Steyrergasse 30/1, 8010 Graz, Austria   Please https://useplaintext.email/

Bug#948336: selinux-policy-default: systemd-journal cannot access processes with 'signull' (RedHat Bug 1676923).

[Mario Koppensteiner]

Hello,

Today I installed a Debian Box with selinux enabled. I found that I'm 
affected by this bug. Is there any activity to solve this bug?


The referenced Redhat Bug 1676923 is closed.


Links:
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1676923


sincerely yours

Mario Koppensteiner

Bug#970054: fwupd: Missing Depends (or Recommends) on udisks2 for UEFI update

[Limonciello, Mario]

Thanks for the report, and submitting the fix upstream!

I agree, it should probably be a recommends and we should pull that patch in
for safety.  I'll include it in a 1.4.6-2 upload once we merge it upstream.

Thanks!

> -Original Message-
> From: Jochen Sprickerhof 
> Sent: Thursday, September 10, 2020 17:08
> To: Debian Bug Tracking System
> Subject: Bug#970054: fwupd: Missing Depends (or Recommends) on udisks2 for
> UEFI update
> 
> 
> [EXTERNAL EMAIL]
> 
> Package: fwupd
> Version: 1.4.6-1
> Severity: normal
> 
> Hi,
> 
> starting with 1.4.6 (or 25ba4157) fwupdmgr connects to
> /org/freedesktop/UDisks2/Manager to get the ESP. You can see this by
> running
> 
> dbus-monitor --system
> 
> while doing a
> 
> fwupdtool esp-list
> 
> with out udisks2 installed I get a segfault and fwupdmgr does not opt to
> update the UEFI. I proposed a fix to the segfault here:
> 
> https://github.com/fwupd/fwupd/pull/2384
> 
> Still there should be a dependency on udisks2 (or a way to work without
> it).
> 
> Cheers Jochen
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.8.0-1-amd64 (SMP w/8 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 /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages fwupd depends on:
> ii  libc6  2.31-3
> ii  libefiboot137-5
> ii  libefivar1 37-5
> ii  libelf10.180-1+b1
> ii  libflashrom1   1.2-5
> ii  libfwupd2  1.4.6-1
> ii  libfwupdplugin11.4.6-1
> ii  libglib2.0-0   2.64.4-1
> ii  libgudev-1.0-0 233-1
> ii  libgusb2   0.3.4-0.2
> ii  libjcat1   0.1.3-2
> ii  libjson-glib-1.0-0 1.4.4-2
> ii  libpolkit-gobject-1-0  0.105-29
> ii  libsmbios-c2   2.4.3-1
> ii  libsoup2.4-1   2.70.0-1
> ii  libsqlite3-0   3.33.0-1
> ii  libtss2-esys0  3.0.0-1
> ii  libxmlb1   0.1.15-2
> ii  shared-mime-info   1.15-1
> 
> Versions of packages fwupd recommends:
> pn  bolt  
> pn  fwupd-signed  
> ii  python3   3.8.2-3
> 
> fwupd suggests no packages.
> 
> -- no debconf information

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

I would suggest a new issue linking to that one instead so it's not lost.

> -Original Message-
> From: Michel Le Bihan 
> Sent: Monday, July 27, 2020 1:01 PM
> To: Limonciello, Mario; 963...@bugs.debian.org
> Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> I added a comment under the existing closed issue:
> https://github.com/rhboot/efibootmgr/issues/133#issuecomment-664549236
> 
> Le lundi 27 juillet 2020 à 17:54 +, Limonciello, Mario a écrit :
> > In that case, would you mind reporting a bug to upstream efibootmgr?
> > It seems
> > to me that your Boot entry can't be properly parsed.  You may
> > need to also
> > attach it to your bug report.
> >
> > > -Original Message-
> > > From: Michel Le Bihan 
> > > Sent: Monday, July 27, 2020 12:16 PM
> > > To: Limonciello, Mario; 963...@bugs.debian.org
> > > Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > "Could not
> > > parse device path: Invalid argument"
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > It was efibootmgr and efivar master.
> > >
> > > Le lundi 27 juillet 2020 à 16:46 +, Limonciello, Mario a écrit
> > > :
> > > > Was that just efibootmgr master?
> > > > If possible, can you move up to *both* efivar master and
> > > > efibootmgr
> > > > master and try again?
> > > >
> > > > > -Original Message-
> > > > > From: Michel Le Bihan 
> > > > > Sent: Monday, July 27, 2020 11:25 AM
> > > > > To: Limonciello, Mario; 963...@bugs.debian.org
> > > > > Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > > > "Could not
> > > > > parse device path: Invalid argument"
> > > > >
> > > > >
> > > > > [EXTERNAL EMAIL]
> > > > >
> > > > > Hello,
> > > > >
> > > > > I applied the fix and built the package. It didn't help. I also
> > > > > built
> > > > > latest master and I still have this issue.
> > > > >
> > > > > BTW, the computer is an OptiPlex 7040. Full hwinfo --bios:
> > > > > https://lebihan.pl/files/hwinfo-bios.txt
> > > > >
> > > > > Error trace:
> > > > > ```
> > > > > root@s217-lab00:~# /dev/shm/efibootmgr/src/efibootmgr -v
> > > > > BootCurrent: 0003
> > > > > Timeout: 2 seconds
> > > > > BootOrder: 0003,0004,0001,0005,000A,0007,0008,0009,0002
> > > > > Boot* Windows Boot ManagerCould not parse device path:
> > > > > Invalid
> > > > > argument
> > > > > error trace:
> > > > >  /build/efivar-yvRv8P/efivar-37/src/include/efivar/efivar-
> > > > > dp.h:1208
> > > > > efidp_is_valid(): invalid device path node type: Invalid
> > > > > argument
> > > > > ```
> > > > >
> > > > > Michel Le Bihan
> > > > >
> > > > > Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a
> > > > > écrit
> > > > > :
> > > > > > > -Original Message-
> > > > > > > From: Michel Le Bihan 
> > > > > > > Sent: Sunday, July 26, 2020 2:58 PM
> > > > > > > To: 963...@bugs.debian.org
> > > > > > > Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > > > > > "Could
> > > > > > > not
> > > > > > > parse device path: Invalid argument"
> > > > > > >
> > > > > > >
> > > > > > > [EXTERNAL EMAIL]
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > What's preventing the upstream fix from being applied to
> > > > > > > this
> > > > > > > package?
> > > > > > >
> > > > > > > Michel Le Bihan
> > > > > >
> > > > > > I personally can't reproduce the failure on my system's
> > > > > > firmware.
> > > > > > Can you apply the fix locally and confirm it actually helps?

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

In that case, would you mind reporting a bug to upstream efibootmgr? It seems
to me that your Boot entry can't be properly parsed.  You may need to also
attach it to your bug report.

> -Original Message-
> From: Michel Le Bihan 
> Sent: Monday, July 27, 2020 12:16 PM
> To: Limonciello, Mario; 963...@bugs.debian.org
> Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> It was efibootmgr and efivar master.
> 
> Le lundi 27 juillet 2020 à 16:46 +, Limonciello, Mario a écrit :
> > Was that just efibootmgr master?
> > If possible, can you move up to *both* efivar master and efibootmgr
> > master and try again?
> >
> > > -Original Message-
> > > From: Michel Le Bihan 
> > > Sent: Monday, July 27, 2020 11:25 AM
> > > To: Limonciello, Mario; 963...@bugs.debian.org
> > > Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > "Could not
> > > parse device path: Invalid argument"
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hello,
> > >
> > > I applied the fix and built the package. It didn't help. I also
> > > built
> > > latest master and I still have this issue.
> > >
> > > BTW, the computer is an OptiPlex 7040. Full hwinfo --bios:
> > > https://lebihan.pl/files/hwinfo-bios.txt
> > >
> > > Error trace:
> > > ```
> > > root@s217-lab00:~# /dev/shm/efibootmgr/src/efibootmgr -v
> > > BootCurrent: 0003
> > > Timeout: 2 seconds
> > > BootOrder: 0003,0004,0001,0005,000A,0007,0008,0009,0002
> > > Boot* Windows Boot ManagerCould not parse device path: Invalid
> > > argument
> > > error trace:
> > >  /build/efivar-yvRv8P/efivar-37/src/include/efivar/efivar-dp.h:1208
> > > efidp_is_valid(): invalid device path node type: Invalid argument
> > > ```
> > >
> > > Michel Le Bihan
> > >
> > > Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a écrit
> > > :
> > > > > -Original Message-
> > > > > From: Michel Le Bihan 
> > > > > Sent: Sunday, July 26, 2020 2:58 PM
> > > > > To: 963...@bugs.debian.org
> > > > > Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with
> > > > > "Could
> > > > > not
> > > > > parse device path: Invalid argument"
> > > > >
> > > > >
> > > > > [EXTERNAL EMAIL]
> > > > >
> > > > > Hello,
> > > > >
> > > > > What's preventing the upstream fix from being applied to this
> > > > > package?
> > > > >
> > > > > Michel Le Bihan
> > > >
> > > > I personally can't reproduce the failure on my system's firmware.
> > > > Can you apply the fix locally and confirm it actually helps?

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

> -Original Message-
> From: Michel Le Bihan 
> Sent: Sunday, July 26, 2020 2:58 PM
> To: 963...@bugs.debian.org
> Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello,
> 
> What's preventing the upstream fix from being applied to this package?
> 
> Michel Le Bihan

I personally can't reproduce the failure on my system's firmware.
Can you apply the fix locally and confirm it actually helps?

Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not parse device path: Invalid argument"

[Limonciello, Mario]

Was that just efibootmgr master?
If possible, can you move up to *both* efivar master and efibootmgr master and 
try again?

> -Original Message-
> From: Michel Le Bihan 
> Sent: Monday, July 27, 2020 11:25 AM
> To: Limonciello, Mario; 963...@bugs.debian.org
> Subject: Re: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could not
> parse device path: Invalid argument"
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello,
> 
> I applied the fix and built the package. It didn't help. I also built
> latest master and I still have this issue.
> 
> BTW, the computer is an OptiPlex 7040. Full hwinfo --bios:
> https://lebihan.pl/files/hwinfo-bios.txt
> 
> Error trace:
> ```
> root@s217-lab00:~# /dev/shm/efibootmgr/src/efibootmgr -v
> BootCurrent: 0003
> Timeout: 2 seconds
> BootOrder: 0003,0004,0001,0005,000A,0007,0008,0009,0002
> Boot* Windows Boot ManagerCould not parse device path: Invalid
> argument
> error trace:
>  /build/efivar-yvRv8P/efivar-37/src/include/efivar/efivar-dp.h:1208
> efidp_is_valid(): invalid device path node type: Invalid argument
> ```
> 
> Michel Le Bihan
> 
> Le lundi 27 juillet 2020 à 15:28 +, Limonciello, Mario a écrit :
> > > -Original Message-
> > > From: Michel Le Bihan 
> > > Sent: Sunday, July 26, 2020 2:58 PM
> > > To: 963...@bugs.debian.org
> > > Subject: Bug#963475: libefivar1: "efibootmgr -v" fails with "Could
> > > not
> > > parse device path: Invalid argument"
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > Hello,
> > >
> > > What's preventing the upstream fix from being applied to this
> > > package?
> > >
> > > Michel Le Bihan
> >
> > I personally can't reproduce the failure on my system's firmware.
> > Can you apply the fix locally and confirm it actually helps?

Bug#956013: Fails to install

[Mario Blättermann]

Hi David,

David Prévot  schrieb am Mo., 6. Apr. 2020, 18:51:

> Le 06/04/2020 à 02:39, Dr. Tobias Quathamer a écrit :
>
> > I think that this bug is now fixed in git. If you have the time, I'd
> > value your input if I've thought of everything before I start another
> > upload cycle.
>
> I very much doubt it is manpages-l10n task to take over
> manpages-fr-extra (especially via a transnational dummy package).
>

It *is* the task of manpages-l10n because the source tarball contains
translations which were previously maintained within manpages-fr-extra.

Well, alternatively we could disable the man pages which come from there
and keep publishing the old manpages-fr-extra package again and again, with
all the outdated stuff it contains. Doesn't make sense at all. Instead,
let's go a step ahead and switch to up-to-date man pages.

Best Regards,
Mario


Anyway, adding a manpages-fr-extra package with a version lower the one
> currently in unstable will not supersede it.
>
> Regards
>
> David
>
>

Bug#953565: ITP: libjcat -- JSON Catalog library

[Mario Limonciello]

Package: wnpp
Severity: wishlist
Owner: Mario Limonciello 

* Package name: libjcat
  Version : 0.1.0
  Upstream Author : Richard Hughes 
* URL : https://github.com/hughsie/libjcat
* License : LGPL 2.1+
  Programming Lang: C
  Description : JSON Catalog library

The libjcat library assembles checksum and metadata into a JSON based catalog.
This is used by other software to validate metadata.

This will be a dependency for fwupd in the future (1.4.0 release or newer).
It will be maintained by the debian-efi team which also maintains the rest of
the firmware updating stack for UEFI machines.

The packaging has already been started at https://salsa.debian.org/efi-
team/libjcat.  It will be uploaded when libjcat has it's first release.

Bug#951589: flashrom: Update to version 1.2

[Mario Limonciello]

Package: flashrom
Severity: wishlist
Tags: upstream

Dear Maintainer,

Can you please upgrade to the recently released version 1.2?

This package now supports a library for other applications to compile against
it.  As part of upgrading to 1.2, can you please introduce new binary packages
for that library and pkgconfig/headers too?

I would like to compile fwupd against it to introduce flashrom support for
fwupd in Debian.



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

Kernel: Linux 5.4.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flashrom depends on:
ii  libc6 2.30-0ubuntu3
ii  libftdi1-21.4-2build1
ii  libpci3   1:3.6.4-1
ii  libusb-0.1-4  2:0.1.12-32
ii  libusb-1.0-0  2:1.0.23-2build1

flashrom recommends no packages.

flashrom suggests no packages.

Bug#950389: libc6 s390x preinstall script fails

[Mario Limonciello]

Package: libc6
Version: 2.30-0ubuntu3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I currently use multi arch with s390x on Debian testing in an amd64 container
for continuous integration purposes for an upstream project, fwupd.

In the last day or so the container setup is failing with the following:

Selecting previously unselected package libc6:s390x.
Preparing to unpack .../2-libc6_2.29-9_s390x.deb ...
/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open
shared object file: No such file or directory
dpkg: error processing archive /tmp/apt-dpkg-install-
Fec8mr/2-libc6_2.29-9_s390x.deb (--unpack):
 new libc6:s390x package pre-installation script subprocess returned error exit
status 127
Unpacking gcc-9-base:s390x (9.2.1-25) ...
Errors were encountered while processing:
 /tmp/apt-dpkg-install-Fec8mr/2-libc6_2.29-9_s390x.deb
E: Could not configure 'libc6:s390x'.
E: Could not perform immediate configuration on 'libgcc1:s390x'. Please see man
5 apt.conf under APT::Immediate-Configure for details. (2)

The full log is available here: https://travis-
ci.org/fwupd/fwupd/jobs/644533041#L1250



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

Kernel: Linux 5.3.0-19-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc1  1:9.2.1-25ubuntu1

Versions of packages libc6 recommends:
ii  libidn2-0  2.2.0-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.73
pn  glibc-doc  
ii  locales2.30-0ubuntu3

-- debconf information excluded

Bug#891410:

[Mario Limonciello]

I think that upstream would be happy to switch to a "public" interface in
the future.  Would you mind suggesting something upstream with the relevant
changes that make sense?

On Mon, Jan 20, 2020 at 7:52 AM Guilhem Moulin  wrote:

> On Mon, 20 Jan 2020 at 07:12:37 -0600, Mario Limonciello wrote:
> > FYI, the newly released version 12 has initramfs support.
>
> Hmm.  I guess I'm part of the problem since I haven't found time to help
> with this unfortunately, but on a quick look it appears that my comments
> from msg#27 and msg#32 still hold.
>
> cryptsetup's initramfs integration isn't part of cryptsetup upstream,
> but is development and maintained by the Debian packaging team, which
> I'm part of.  AFAICT clevis upstream seem to have taken shell scripts
> from src:cryptsetup and adapted them to their needs.  Might work right
> now, but these file use *internal* / *undocumented* interfaces which are
> subject to change without notice.  I fear clevis initramfs users have a
> real risk of ending up with an unbootable system when we do update these
> interfaces.
>
> --
> Guilhem.
>


-- 
Mario Limonciello
supe...@gmail.com

Bug#891410:

[Mario Limonciello]

FYI, the newly released version 12 has initramfs support.

Bug#949069: "apt autoremove" doesn't remove an automatic package with 0 dependents

[Mario E. Weisz]

package: apt
version: 1.8.2

I'm refiling this report since it was wrongly marked as resolved.

to reproduce the problem, run these commands on a fresh Ubuntu or Debian 
installation:
$ apt install postgresql-11
$ apt purge postgresql-11
$ apt autoremove

a dependency named "postgresql-client-11" doesn't get autoremoved despite 
having 0 dependents:
$ apt rdepends "postgresql-client-11 --installed

returns nothing.

*these commands were executed literally after installing the distro (Ubuntu and 
Debian)
*the dependency can be removed manually
*this doesn't happen with aptitude