Bug#1072438: notcurses: FTBFS with ffmpeg 7.0: ffmpeg.c:523:46: error: ‘struct AVFrame’ has no member named ‘pkt_duration’; did you mean ‘duration’?

[nick black]

confirmed. this is a known issue with a fix present on the
notcurses main. i need to cut a new release ASAP including that
fix. until then, i can patch the debian package. there's
actually a fedora patch for the same problem:

 
https://src.fedoraproject.org/rpms/notcurses/c/70d807ff48579d92e580c7eb8c7e9cad4c26d79b?branch=rawhide

i'll try to get a debian patch up today or tomorrow. thanks for
the report!

Bug#1006889: frr / bgp failing to insert routes on boot (usually ipv6, sometimes ipv4)

[Nick]

Hi David,

No problem at all!  To be honest, I’d completely forgotten about this.

I was only setting up a test network for learning, and if what you say about 
interfaces bouncing is true then you are right not to mess with the systemd 
scripts.  If I try this again in future, I’ll go for loopback interfaces as you 
suggest.

Keep up the good work!

Kind regards,

Nick

> On 6 May 2024, at 15:16, David Lamparter  wrote:
> 
> Hi Nick,
> 
> 
> (first of all, sorry, I kinda blanked out this bug report for some time,
> see below for why)
> 
> On Mon, Mar 07, 2022 at 06:16:03PM +, Nick wrote:
> [...]
>>   Because of the above, I checked out 
>>   /etc/systemd/system/multi-user.target.wants/frr.service and found
>>   that it is set to start with 'After=network-pre.target'.  I replaced
>>   Wants= and After= with 'network-online.target' and removed Before=
>>   entirely.
>> 
>>   * What was the outcome of this action?
>> 
>>   Having modified the systemd start script, routes are always inserted
>>   on boot!
> [...]
> 
> The problem with this is that while this fixes your specific scenario,
> it also breaks other users' setups since network-online.target itself is
> on occasion made to depend on frr.service, which would now create a
> loop.
> 
> Further, the issue you're seeing is specific to your configuration with
> these two route-maps:
> 
> [...]
>> route-map RM_SET_SRC permit 10
>> set src 25.0.1.1
>> !
>> route-map RM_SET_SRC6 permit 10
>> set src :f0a1::1
> [...]
> 
> You're correct to observe that these require the interface that owns
> these IP addresses to be up and configured before they can take effect,
> and the kernel will reject them otherwise.  zebra's behavior on this
> is... call it "suboptimal" in not retrying the install;  however the
> behavior of FRR is designed against a limitation of "normal" policy
> setups.  route-maps, especially in zebra, are essentially code, and
> there are *lots* of possibilities to create edge cases or non-working
> setups.
> 
> In your specific setup, the "FRR recommended practice" would be: add
> both of these IP addresses (25.0.1.1 and XYZ:f0a1::1) as /32 / /128 to
> your loopback interface.  This will ensure they are always available.
> (This is generally recommended for a router's primary addresses.)
> 
> Alternatively, your fix in editing the dependency is also viable,
> assuming you don't need to deal with cases where the interface or
> addresses go away and come back.  I can't incorporate it into the
> package though because it is specific to your situation.
> 
> 
> Sorry, I'm not sure there is anything else I can do here,
> 
> 
> equi (David)

Bug#1068710: tiktoken: pybuild-autopkgtest fails with ModuleNotFoundError(s)

[Nick Rosbrook]

> Are you sure this patch worked in Ubuntu?  As far as I can tell, the
> autopkgtest script still fail on Debian.
>

Yes, here is the autopkgtest result page for Ubuntu:
https://autopkgtest.ubuntu.com/packages/tiktoken. Looking at the
Debian autopkgtest logs, the failure looks different:
https://ci.debian.net/packages/t/tiktoken/unstable/amd64/45200281/.

-Nick

Bug#1065761: m4api: FTBFS on arm{el,hf}: /<>/m4api.c:413:10: error: implicit declaration of function ‘m4SetBinary’ [-Werror=implicit-function-declaration]

[Nick Rosbrook]

Package: m4api
Followup-For: Bug #1065761
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix the implicit
declarations.

  * debian/patches: fix several implicit declarations (LP: #2060847)


Thanks for considering the patch.

-Nick
diff -Nru 
m4api-0.3~0.9646fd/debian/patches/fix-several-implicit-declarations.patch 
m4api-0.3~0.9646fd/debian/patches/fix-several-implicit-declarations.patch
--- m4api-0.3~0.9646fd/debian/patches/fix-several-implicit-declarations.patch   
1969-12-31 19:00:00.0 -0500
+++ m4api-0.3~0.9646fd/debian/patches/fix-several-implicit-declarations.patch   
2024-04-10 13:41:11.0 -0400
@@ -0,0 +1,27 @@
+Description: Fix several implicit declarations
+Author: Nick Rosbrook 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/2060847
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066290
+Last-Update: 2024-04-10
+--- a/m4api.c
 b/m4api.c
+@@ -391,6 +391,8 @@
+   return 0;
+ }
+ 
++int m4SetBinary(m4Handle *dev, struct m4ConfigField *field, char const *val);
++
+ int m4SetFloat(m4Handle *dev, enum m4FieldID fid, float val) {
+   char binary[2];
+   int ival;
+--- a/m4ctl.c
 b/m4ctl.c
+@@ -17,6 +17,8 @@
+  */
+ 
+ #include 
++#include 
++#include 
+ #include 
+ 
+ #include "m4api.h"
diff -Nru m4api-0.3~0.9646fd/debian/patches/series 
m4api-0.3~0.9646fd/debian/patches/series
--- m4api-0.3~0.9646fd/debian/patches/series1969-12-31 19:00:00.0 
-0500
+++ m4api-0.3~0.9646fd/debian/patches/series2024-04-10 13:40:41.0 
-0400
@@ -0,0 +1 @@
+fix-several-implicit-declarations.patch

Bug#1066379: loqui: FTBFS: loqui-core-gtk.gob:256:25: error: implicit declaration of function ‘account_list_dialog_open_for_connect’ [-Werror=implicit-function-declaration]

[Nick Rosbrook]

Package: loqui
Followup-For: Bug #1066379
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

This FTBFS is due to a missing include of account_list_dialog.h. In
Ubuntu we applied this patch to fix it.

  * debian/patches: fix implicit declaration of
account_list_dialog_open_for_connect


Thanks for considering the patch.

-Nick
diff -Nru 
loqui-0.7.0/debian/patches/0002-add-missing-include-account_list_dialog.h.patch 
loqui-0.7.0/debian/patches/0002-add-missing-include-account_list_dialog.h.patch
--- 
loqui-0.7.0/debian/patches/0002-add-missing-include-account_list_dialog.h.patch 
1969-12-31 19:00:00.0 -0500
+++ 
loqui-0.7.0/debian/patches/0002-add-missing-include-account_list_dialog.h.patch 
2024-04-10 11:51:39.0 -0400
@@ -0,0 +1,16 @@
+Description: Fix implicit declaration of account_list_dialog_open_for_connect
+ The account_list_dialog.h header needs to be included for this.
+Author: Nick Rosbrook 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/loqui/+bug/2060834
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066379
+Last-Update: 2024-04-10
+--- a/src/loqui-core-gtk.gob
 b/src/loqui-core-gtk.gob
+@@ -63,6 +63,7 @@
+ #include "loqui_stock.h"
+ #include "prefs_general_upgrader.h"
+ #include "loqui-notifier-gtk.h"
++#include "account_list_dialog.h"
+ 
+ %}
+ 
diff -Nru loqui-0.7.0/debian/patches/series loqui-0.7.0/debian/patches/series
--- loqui-0.7.0/debian/patches/series   2021-08-14 23:24:56.0 -0400
+++ loqui-0.7.0/debian/patches/series   2024-04-10 11:47:31.0 -0400
@@ -1 +1,2 @@
 0001-Add-missing-Makefile.in.patch
+0002-add-missing-include-account_list_dialog.h.patch

Bug#1068710: tiktoken: pybuild-autopkgtest fails with ModuleNotFoundError(s)

[Nick Rosbrook]

Package: tiktoken
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch

Dear Maintainer,

In Ubuntu, I noticed that the autopkgtests were failing for tiktoken[1].
The failure is due to missing 'pytest' and 'hypothesis' python modules.
Looking at [2], I see the same failures in Debian. I applied this
patch in Ubuntu to fix the autopkgtest:

  * debian/control: Build-Depends: python3-{pytest,hypothesis}

Thanks for considering the patch.

-Nick

[1] https://bugs.launchpad.net/bugs/2060690
[2] https://ci.debian.net/packages/t/tiktoken/
diff -Nru tiktoken-0.6.0/debian/control tiktoken-0.6.0/debian/control
--- tiktoken-0.6.0/debian/control   2024-04-01 04:25:31.0 -0400
+++ tiktoken-0.6.0/debian/control   2024-04-09 10:23:56.0 -0400
@@ -11,6 +10,8 @@
  , python3-all
  , python3-setuptools-rust
  , python3-regex
+ , python3-hypothesis
+ , python3-pytest
  , librust-bstr-dev (>= 0.0.1~)
  , librust-fancy-regex-dev
  , librust-pyo3-dev

Bug#1066072: ITP: swappy -- Wayland native snapshot and editor tool

[Nick Hastings]

Package: wnpp
Severity: wishlist
Owner: Nick Hastings 
X-Debbugs-Cc: debian-de...@lists.debian.org, nicholaschasti...@gmail.com

* Package name: swappy
  Version : 1.5.1
  Upstream Contact: Jeremy Attali 
* URL : https://github.com/jtheoof/swappy
* License : MIT
  Programming Lang: C
  Description : Wayland native snapshot and editor tool

A Wayland native snapshot and editor tool, inspired by Snappy on
macOS. Works great with grim, slurp and sway. But can easily work
with other screen copy tools that can output a final image to stdout.

This tool provides a nice balance between feature set and ease of used
for quickly annotating screenshots or other images.

A sponsor will be needed.

Bug#1065105: plasma-desktop: Laptop intermittently won't resume from sleep

[Nick]

Package: plasma-desktop
Version: 4:5.27.5-2
Severity: important

Dear Maintainer,

I'm not sure this is necessarily an issue with Plasma Desktop specifically
rather than the display manager or something wider, but I'm using Plasma so
thought this the best place to report initially.

I'm experiencing an issue waking from sleep on Debian, on a laptop, running
KDE. Some of the time when I try and wake it nothing happens - screen remains
off and unresponsive. I'm forced to hard restart the laptop.
Power button shows as on throughout, implying that the issue occurs during the
suspend i.e. it never properly goes into sleep but crashes at this point.

I have tried switching from X to Wayland and the problem is reproduced on both.
But it's intermittent, it doesn't happen every time.
I wonder if it happens more when an external monitor is connect via HDMI but
this is not conclusive.
I've tried different options for sleep to see if this makes a difference - e.g.
from the ctrl-alt-delete suspend button, closing laptop lid, etc. But problem
seems to occur with all options (possibly less frequently with the ctrl-alt-
delete logout screen and then pressing suspend).

I'm running Debian Stable - Bookworm - KDE Plasma 5.27.5 but the problem has
been going on for a month or two now.
Laptop is Lenovo YOGA 520-14IKB
Graphics processor: Mesa Intel® HD Graphics 610

Expected behaviour: laptop wakes from sleep as normal.

Happy to try and help supply log files etc if you can talk me through these.


Many thanks in advance for your help with this issue and all your great work
developing KDE / Debian.


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

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

Versions of packages plasma-desktop depends on:
ii  accountsservice  22.08.8-6
ii  breeze   4:5.27.5-2
ii  kactivitymanagerd5.27.5-2
ii  kde-cli-tools4:5.27.5.1-2
ii  kded55.103.0-1
ii  kio  5.103.0-1
ii  kpackagetool55.103.0-1
ii  layer-shell-qt   5.27.5-2
ii  libaccounts-qt5-11.16-2
ii  libc62.36-9+deb12u4
ii  libglib2.0-0 2.74.6-2
ii  libibus-1.0-51.5.27-5
ii  libkaccounts24:22.12.3-1
ii  libkf5activities55.103.0-1
ii  libkf5activitiesstats1   5.103.0-1
ii  libkf5authcore5  5.103.0-1
ii  libkf5baloo5 5.103.0-2
ii  libkf5bookmarks5 5.103.0-1
ii  libkf5codecs55.103.0-1
ii  libkf5completion55.103.0-1
ii  libkf5configcore55.103.0-2
ii  libkf5configgui5 5.103.0-2
ii  libkf5configwidgets5 5.103.0-1
ii  libkf5coreaddons55.103.0-1
ii  libkf5crash5 5.103.0-1
ii  libkf5dbusaddons55.103.0-1
ii  libkf5globalaccel-bin5.103.0-1
ii  libkf5globalaccel5   5.103.0-1
ii  libkf5guiaddons5 5.103.0-1
ii  libkf5i18n5  5.103.0-1
ii  libkf5iconthemes55.103.0-1
ii  libkf5itemviews5 5.103.0-1
ii  libkf5jobwidgets55.103.0-1
ii  libkf5kcmutils5  5.103.0-3
ii  libkf5kcmutilscore5  5.103.0-3
ii  libkf5kdelibs4support5   5.103.0-1
ii  libkf5kiocore5   5.103.0-1
ii  libkf5kiofilewidgets55.103.0-1
ii  libkf5kiogui55.103.0-1
ii  libkf5kiowidgets55.103.0-1
ii  libkf5newstuffcore5  5.103.0-1
ii  libkf5notifications5 5.103.0-1
ii  libkf5notifyconfig5  5.103.0-1
ii  libkf5package5   5.103.0-1
ii  libkf5plasma55.103.0-1+deb12u1
ii  libkf5plasmaquick5   5.103.0-1+deb12u1
ii  libkf5quickaddons5   5.103.0-1
ii  libkf5runner55.103.0-1
ii  libkf5service-bin5.103.0-1
ii  libkf5service5   5.103.0-1
ii  libkf5solid5 5.103.0-1
ii  libkf5sonnetcore55.103.0-1

Bug#1062072: marked as done (clamav: NMU diff for 64-bit time_t transition)

[Nick Mortel]

Please advise. Not sure what this means for me as a sole independant 
personal user for home use.


Nick Mortel

On 04/02/2024 12:03, Debian Bug Tracking System wrote:

Your message dated Sun, 04 Feb 2024 12:00:11 +
with message-id 
and subject line Bug#1062072: fixed in clamav 1.2.1+dfsg-3
has caused the Debian Bug report #1062072,
regarding clamav: NMU diff for 64-bit time_t transition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)

Bug#1055494: marked as done (clamav-doc: missing Breaks+Replaces: clamav (<< 1.2))

[Nick Mortel]

same again.not sure !

On 04/02/2024 12:03, Debian Bug Tracking System wrote:

Your message dated Sun, 04 Feb 2024 12:00:11 +
with message-id 
and subject line Bug#1055494: fixed in clamav 1.2.1+dfsg-3
has caused the Debian Bug report #1055494,
regarding clamav-doc: missing Breaks+Replaces: clamav (<< 1.2)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)

Bug#1062953: python3-pyocd: Module is unusable (missing runtime dependencies)

[Nick Morrott (nickm)]

Package: python3-pyocd
Version: 0.36.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

The upload of python3-pyocd 0.36.0-1 appears to be completely unusable:

$ python3
Python 3.11.7 (main, Dec  8 2023, 14:22:46) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pyOCD
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pyOCD/__init__.py", line 21, in 
from . import gdbserver
  File "/usr/lib/python3/dist-packages/pyOCD/gdbserver/__init__.py", line 17, 
in 

from .gdbserver import GDBServer
  File "/usr/lib/python3/dist-packages/pyOCD/gdbserver/gdbserver.py", line 42, 
in 

from ..rtos import RTOS
  File "/usr/lib/python3/dist-packages/pyOCD/rtos/__init__.py", line 29, in 


load_plugin_classes_of_type('pyocd.rtos', RTOS, ThreadProvider)
  File "/usr/lib/python3/dist-packages/pyOCD/core/plugin.py", line 97, in 
load_plugin_classes_of_type

plugin = entry_point.load()()
 ^^
  File "/usr/lib/python3/dist-packages/importlib_metadata/__init__.py", line 
203, in load

module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "/usr/lib/python3/dist-packages/pyocd/__init__.py", line 21, in 
from . import gdbserver
  File "/usr/lib/python3/dist-packages/pyocd/gdbserver/__init__.py", line 17, 
in 

from .gdbserver import GDBServer
  File "/usr/lib/python3/dist-packages/pyocd/gdbserver/gdbserver.py", line 50, 
in 

return _bootstrap._gcd_import(name[level:], package, level)
   
  File "/usr/lib/python3/dist-packages/pyocd/probe/jlink_probe.py", line 22, in 


import pylink
ModuleNotFoundError: No module named 'pylink'


The build log reports several missing dependencies:

I: dh_python3 pydist:302: Cannot find package that provides cmsis_pack_manager.
I: dh_python3 pydist:302: Cannot find package that provides libusb_package.
I: dh_python3 pydist:302: Cannot find package that provides pylink_square.


Although present in the distribution, no tests are configured to run at build 
time.



-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (400, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE

Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pyocd depends on:
ii  python3  3.11.6-1
ii  python3-capstone 4.0.2-5+b1
ii  python3-colorama 0.4.6-4
ii  python3-importlib-metadata   4.12.0-1
ii  python3-importlib-resources  6.0.1-1
ii  python3-intelhex 2.3.0-2
ii  python3-intervaltree 3.0.2-1.1
ii  python3-lark 1.1.9-1
ii  python3-natsort  8.0.2-2
ii  python3-pkg-resources68.1.2-2
ii  python3-prettytable  3.6.0-1
ii  python3-pyelftools   0.30-1
ii  python3-six  1.16.0-4
ii  python3-typing-extensions4.7.1-2
ii  python3-usb  1.2.1-2
ii  python3-yaml 6.0.1-1+b1

python3-pyocd recommends no packages.

python3-pyocd suggests no packages.

-- no debconf information

Bug#1061785: automake-1.16 fails its autopkg tests with Python 3.12

[Nick Rosbrook]

Package: automake-1.16
Followup-For: Bug #1061785
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu noble ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The reason for the autopkgtest failure is that the imp module was
removed from python 3.12. The t/ax/am-test-lib.sh script currently
calls imp.get_tag(), and the recommended[1] way to replace this
functionality is to use sys.implementation.cache_tag.

Thanks for considering the patch.

[1] https://docs.python.org/3.10/library/imp.html#imp.get_tag
diff -Nru 
automake-1.16-1.16.5/debian/patches/python3.12-do-not-import-imp.patch 
automake-1.16-1.16.5/debian/patches/python3.12-do-not-import-imp.patch
--- automake-1.16-1.16.5/debian/patches/python3.12-do-not-import-imp.patch  
1969-12-31 19:00:00.0 -0500
+++ automake-1.16-1.16.5/debian/patches/python3.12-do-not-import-imp.patch  
2024-02-01 13:42:56.0 -0500
@@ -0,0 +1,19 @@
+Description: Do not try to import imp module
+ The imp module has been deprecated for a while, and was removed in python3.12.
+ Following the recommendation from python documentation, replace imp.get_tag()
+ usage with sys.implementation.cache_tag.
+Author: Nick Rosbrook 
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1061785
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/automake-1.16/+bug/2051972
+Last-Update: 2024-02-01
+--- a/t/ax/am-test-lib.sh
 b/t/ax/am-test-lib.sh
+@@ -631,7 +631,7 @@
+ python_has_pep3147 ()
+ {
+   if test -z "$am_pep3147_tag"; then
+-am_pep3147_tag=$($PYTHON -c 'import imp; print(imp.get_tag())') \
++am_pep3147_tag=$($PYTHON -c 'import sys; 
print(sys.implementation.cache_tag)') \
+   || am_pep3147_tag=none
+   fi
+   test $am_pep3147_tag != none
diff -Nru automake-1.16-1.16.5/debian/patches/series 
automake-1.16-1.16.5/debian/patches/series
--- automake-1.16-1.16.5/debian/patches/series  2022-03-15 19:03:50.0 
-0400
+++ automake-1.16-1.16.5/debian/patches/series  2024-02-01 13:36:58.0 
-0500
@@ -3,3 +3,4 @@
 0003-t-python-prefix.sh-Respect-PYTHON-environment-variable.patch
 python3.10.patch
 python3.10-sysconfig.patch
+python3.12-do-not-import-imp.patch

Bug#1061716: clang-16: unable to find standard headers like

[Nick Lewycky]

stem" 
"/usr/include" "-fdeprecated-macro" 
"-fdebug-compilation-dir=/home/nicholas" "-ferror-limit" "19" 
"-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" 
"-fcolor-diagnostics" "-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" 
"/tmp/cassert-0fb9fc.o" "-x" "c++" "cassert.cc"
 "/usr/bin/ld" "-pie" "--hash-style=gnu" "--build-id" "--eh-frame-hdr" 
"-m" "elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" 
"a.out" "/lib/x86_64-linux-gnu/Scrt1.o" "/lib/x86_64-linux-gnu/crti.o" 
"/usr/bin/../lib/gcc/x86_64-linux-gnu/14/crtbeginS.o" 
"-L/usr/bin/../lib/gcc/x86_64-linux-gnu/14" 
"-L/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../lib64" 
"-L/lib/x86_64-linux-gnu" "-L/lib/../lib64" 
"-L/usr/lib/x86_64-linux-gnu" "-L/usr/lib/../lib64" 
"-L/usr/lib/llvm-16/bin/../lib" "-L/lib" "-L/usr/lib" 
"/tmp/cassert-0fb9fc.o" "-lstdc++" "-lm" "-lgcc_s" "-lgcc" "-lc" 
"-lgcc_s" "-lgcc" "/usr/bin/../lib/gcc/x86_64-linux-gnu/14/crtendS.o" 
"/lib/x86_64-linux-gnu/crtn.o"

```

Simplifying the paths, I see:
  -internal-isystem /usr/include/c++
  -internal-isystem /usr/include/c++/x86_64-linux-gnu
  -internal-isystem /usr/include/c++/backward
  -internal-isystem /usr/lib/llvm-16/lib/clang/16/include
  -internal-isystem /usr/local/include
  -internal-isystem /usr/x86_64-linux-gnu/include
  -internal-externc-isystem /usr/include/x86_64-linux-gnu
  -internal-externc-isystem /include
  -internal-externc-isystem /usr/include

```
$ dpkg -S cassert | grep /cassert$
libstdc++-5-dev:amd64: /usr/include/c++/5/cassert
libcu++-dev: /usr/include/cuda/std/detail/libcxx/include/cassert
libcu++-dev: /usr/include/cuda/std/cassert
libstdc++-11-dev:amd64: /usr/include/c++/11/cassert
libstdc++-12-dev:amd64: /usr/include/c++/12/cassert
libstdc++-8-dev:amd64: /usr/include/c++/8/cassert
libboost1.83-dev:amd64: 
/usr/include/boost/compatibility/cpp_c_headers/cassert

libstdc++6-4.4-dev: /usr/include/c++/4.4/cassert
libstdc++-6-dev:amd64: /usr/include/c++/6/cassert
libc++-16-dev:amd64: /usr/lib/llvm-16/include/c++/v1/cassert
libstdc++6-4.6-dev: /usr/include/c++/4.6/cassert
libstdc++-4.9-dev:amd64: /usr/include/c++/4.9/cassert
libstdc++-9-dev:amd64: /usr/include/c++/9/cassert
libstdc++-4.8-dev:amd64: /usr/include/c++/4.8/cassert
g++-mingw-w64-i686-posix: 
/usr/lib/gcc/i686-w64-mingw32/13-posix/include/c++/cassert

libstdc++6-4.5-dev: /usr/include/c++/4.5/cassert
g++-mingw-w64-i686-win32: 
/usr/lib/gcc/i686-w64-mingw32/13-win32/include/c++/cassert

libstdc++-13-dev:amd64: /usr/include/c++/13/cassert
libstdc++-9-dev-arm64-cross: /usr/aarch64-linux-gnu/include/c++/9/cassert
libstdc++-10-dev:amd64: /usr/include/c++/10/cassert
libstdc++6-4.7-dev:amd64: /usr/include/c++/4.7/cassert
```

Nick

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable'), (1, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.13-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default

Versions of packages clang-16 depends on:
ii  binutils    2.41.90.20240122-1
ii  libc6   2.37-14
ii  libc6-dev   2.37-14
ii  libclang-common-16-dev  1:16.0.6-19
ii  libclang-cpp16  1:16.0.6-19
ii  libclang1-16    1:16.0.6-19
ii  libgcc-13-dev   13.2.0-12
ii  libgcc-s1   14-20240127-1
ii  libllvm16   1:16.0.6-19
ii  libobjc-13-dev  13.2.0-12
ii  libstdc++-13-dev    13.2.0-12
ii  libstdc++6  14-20240127-1
ii  llvm-16-linker-tools    1:16.0.6-19

Versions of packages clang-16 recommends:
ii  llvm-16-dev  1:16.0.6-19
ii  python3  3.11.6-1

Versions of packages clang-16 suggests:
pn  clang-16-doc  
pn  wasi-libc 

-- debconf-show failed

Bug#1061697: ITP: libcgi-tiny-perl -- module providing a modern interface to write CGI scripts

[Nick Morrott]

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

* Package name: libcgi-tiny-perl
  Version : 1.002
  Upstream Author : Dan Book 
* URL : https://metacpan.org/release/CGI-Tiny
* License : Artistic-2.0
  Programming Lang: Perl
  Description : module providing a modern interface to write CGI scripts

CGI::Tiny provides a modern interface to write CGI scripts to dynamically
respond to HTTP requests as defined in RFC 3875. It is intended to be:

 * Minimal
 CGI::Tiny contains a small amount of code and (on modern Perls) no non-core
 requirements. No framework needed.

 * Simple
 CGI::Tiny is straightforward to use, avoids anything magical or surprising,
 and provides easy access to the most commonly needed features.

 * Robust
 CGI::Tiny's interface is designed to help the developer follow best
 practices and avoid common pitfalls and vulnerabilities by default.

 * Lazy
 CGI::Tiny only loads code or processes information once it is needed,
 so simple requests can be handled without unnecessary overhead.

 * Restrained
 CGI::Tiny is designed for the CGI protocol which executes the program again
 for every request. It is not suitable for persistent protocols like FastCGI
 or PSGI.

 * Flexible
 CGI::Tiny can be used with other modules to handle tasks like routing and
 templating, and doesn't impose unnecessary constraints to reading input or
 rendering output.

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

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

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Nick Hastings]

Hi,

* Maytham Alsudany  [240117 11:37]:
>
> Are you still working on the zig package?
> I'd be happy to help you fix any problems that remain.

I updated the package to Zig 0.10.1. The RFS bug still still open.

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

I'll likely not even try packaging 0.11 or newer until it can once again
bootstrap. However I don't expect that to happen anytime soon.

Nick.

Bug#1059856: firefox-esr: touchscreen support

[Nick Manini]

Package: firefox-esr
Version: 115.6.0esr-1
Severity: normal
Tags: patch

Hello,
   touchscreen is common in modern laptops. Currently the default
behavior of firefox-esr is "point and select text".
The expected 1-finger scroll and 2-fingers zoom-in gestures of the mobile
app are not activated in the desktop version of firefox.

This is easily corrected by setting the global variable MOZ_USE_XINPUT2 to 1.
In my opinion the expected touch gestures should be the default behavior of
firefox-esr in laptops, and this can be obtained by adding a file
/etc/environment.d/50firefox-esr.conf
(or some other filename that Maintainer finds more suitable)
containing this single line:
MOZ_USE_XINPUT2=1

I don't expect that this addition can do any harm to non-touchscreen
installations, but please make a quick test before deployment.

For reference, see
https://superuser.com/questions/1151161/enable-touch-scrolling-in-firefox

Thanks in advance!
All the best,
    Nick



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.14
ii  fontconfig   2.14.2-6
ii  libasound2   1.2.10-3
ii  libatk1.0-0  2.50.0-1
ii  libc62.37-12
ii  libcairo-gobject21.18.0-1
ii  libcairo21.18.0-1
ii  libdbus-1-3  1.14.10-3
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-8
ii  libffi8  3.4.4-2
ii  libfontconfig1   2.14.2-6
ii  libfreetype6 2.13.2+dfsg-1
ii  libgcc-s113.2.0-7
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-3
ii  libglib2.0-0 2.78.3-1
ii  libgtk-3-0   3.24.39-1
ii  libnspr4 2:4.35-1.1
ii  libnss3  2:3.96.1-1
ii  libpango-1.0-0   1.51.0+ds-3
ii  libstdc++6   13.2.0-7
ii  libvpx8  1.13.1-2
ii  libx11-6 2:1.8.7-1
ii  libx11-xcb1  2:1.8.7-1
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.4-2
ii  zlib1g   1:1.3.dfsg-3

Versions of packages firefox-esr recommends:
ii  libavcodec60  7:6.1-5

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-11
ii  libgssapi-krb5-2   1.20.1-5
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

Bug#1056183: texlive-luatex: lualatex exits immediately due to new zlib

[Nick Black (Public gmail account)]

Package: texlive-luatex
Version: 2023.20231007-1
Severity: important
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I recently updated zlib1g:amd64 (1:1.2.13.dfsg-3, 1:1.3.dfsg-2) in unstable.

lualatex immediately stopped working, with the error:

[schwarzgerat](0) $ lualatex
PANIC: unprotected error in call to Lua API (zlib library version does not
match - header: 1.2.13, library: 1.3)
Aborted (core dumped)
[schwarzgerat](134) $

Should just need a rebuild, but perhaps this (unnecessary?) check ought be
removed? Isn't this what SOVERSIONs are for?


-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2496 2023-11-10 04:56 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 2022-10-12 17:25 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 2023-10-08 16:00 /usr/share/texlive/texmf-dist/ls-R 
-> /var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 2023-10-08 16:00 /usr/share/texlive/texmf-dist/ls-R 
-> /var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 2023-08-28 14:30 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 2023-10-08 16:00 /usr/share/texmf/web2c/fmtutil.cnf 
-> /var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 2023-10-08 16:00 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 5289 2023-11-10 04:54 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 2016-02-22 09:54 mktex.cnf
-rw-r--r-- 1 root root 475 2023-08-28 14:30 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

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

Kernel: Linux 6.5.9nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-luatex depends on:
ii  libjs-jquery  3.6.1+dfsg+~3.5.14-1
ii  lmodern   2.005-1
ii  tex-common6.18
ii  texlive-base  2023.20231007-1
ii  texlive-binaries  2023.20230311.66589-7

texlive-luatex recommends no packages.

texlive-luatex suggests no packages.

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.8

Versions of packages texlive-luatex is related to:
ii  tex-common6.18
ii  texlive-binaries  2023.20230311.66589-7

-- no debconf information

Bug#1052528: grub-efi-amd64: Loading initial ramdisk... Error: out of memory

[Nick]

Package: grub-efi-amd64
Version: 2.06-13
Severity: important

After upgrading from Debian 11 to Debian 12 I have been getting the
error when booting my system about 2/3 of the times:

Loading initial ramdisk...
error: out of memory

The other 1/3 of the times I boot, it works fine.

The error happens with the 6.1.0-12 kernel as well as 6.1.0-11. I
still have 5.10.0-23 installed and it doesn't seem to happen with
that kernel.

/boot/initrd.img-6.1.0-12-amd64 (which often failed) was 87 MB.
/boot/initrd.img-5.10.0-23-amd64 (which always worked) was 77 MB.

I found this Ubuntu bug report which shares a lot of similarities:

https://bugs.launchpad.net/oem-priority/+bug/1842320

Similar to others in that bug report, my system is a Dell XPS 9550
with 32 GB of RAM. It has a 4k screen and the nvidia drivers.

Following the advice on that bug report, I checked my
/etc/initramfs-tools/initramfs.conf and found that I was
using "COMPRESS=zstd"

I changed this to "COMPRESS=xz" and "COMPRESSLEVEL=9" and ran
update-initramfs -c to rebuild this kernel's initrd.img.

After doing so, /boot/initrd.img-6.1.0-12-amd64 was compressed
down to 64 MB.

I rebooted the system about 8 times after that and it booted
successfully each time, so I believe this workaround worked.

So it seems like there is a problem booting with initrd.img files
that are bigger than somewhere around 77-87 MB. I'm not sure why
it would sometimes work, though.

-- Package-specific info:


*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod zfs
search --no-floppy --fs-uuid --set=root 0499156567a2c9a6
font="/BOOT/debian@/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=1280x1024x32
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
insmod part_gpt
insmod zfs
search --no-floppy --fs-uuid --set=root 0499156567a2c9a6
insmod png
if background_image /BOOT/debian@/grub/.background_cache.png; then
  set color_normal=white/black
  set color_highlight=black/white
else
  set menu_color_normal=cyan/blue
  set menu_color_highlight=white/blue
fi
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 'gnulinux-simple-/dev/nvme0n1p7' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod zfs
search --no-floppy --fs-uuid --set=root 0499156567a2c9a6
echo'Loading Linux 6.1.0-12-amd64 ...'
linux   /BOOT/debian@/vmlinuz-6.1.0-12-amd64 root=ZFS=/ROOT/debian ro 
root=ZFS=rpool/ROOT/debian root=ZFS=rpool/ROOT/debian 
echo'Loading initial ramdisk ...'
initrd  /BOOT/debian@/initrd.img-6.1.0-12-amd64
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-/dev/nvme0n1p7' {
menuentry 'Debian GNU/Linux, with Linux 6.1.0-12-amd64' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-6.1.0-12-amd64-advanced-/dev/nvme0n1p7' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod zfs
search --no-floppy --fs-uuid --set=root 

Bug#1051290: Acknowledgement (fonts-sil-gentiumplus: gentium plus v6.200 has been released)

[Nick Black (Public gmail account)]

i've uploaded 6.200, and it has entered unstable. this bug can be closed.

Bug#1051290: fonts-sil-gentiumplus: gentium plus v6.200 has been released

[Nick Black (Public gmail account)]

Package: fonts-sil-gentiumplus
Version: 6.101-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Gentium Plus v6.200 was released 2023-02-01.

I'd really like to be able to use U+2227/U+2228 from this great font, among
other recent changes.

Please package the new version when you find time. Thank you!


-- Package-specific info:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version   Architecture Description
+++-==-=--=
ii  fontconfig 2.14.2-5  amd64generic font configuration 
library - support binaries
ii  libfreetype6:amd64 2.13.2+dfsg-1 amd64FreeType 2 font engine, 
shared library files
ii  libxft2:amd64  2.3.6-1   amd64FreeType-based font drawing 
library for X

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

Kernel: Linux 6.4.9nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

Bug#999977: qxw: depends on obsolete pcre3 library

[Nick Morrott]

On Mon, 4 Sept 2023 at 07:32, Stephen Kitt  wrote:
>
> It took me longer to get round to this than I hoped, but here is a patch for
> qxw. I’ve already forwarded it upstream.

Dear Stephen and Bastian,

Thank you both for the pcre2 patch and the upload of qxw.

I got back from vacation yesterday and receiving the commit and upload
notifications this morning was a very unexpected gift!

Many thanks,
Nick

Bug#1024693:

[Nick Eu]

Yeah bug is still present. I installed the official binary and that seems
to work fine.

Bug#1050152: rxvt-unicode: prompt starts in the middle of the screen

[Nick K.]

Package: rxvt-unicode
Version: 9.31-1
Severity: normal
Tags: upstream

Dear Maintainer,

When opening terminal, prompt appears in the middle of the screen. I
disabled .profile, .bashrc and .xresources to no effect, so I assume,
it's not configuration issue.

Putting "clear" in .bashrc "solves" the issue. Issue disappears on
downgrading to 9.30-2+b4 from "stable" branch.

Also there is a discussion of this bug: 
https://bugs.archlinux.org/task/77062 


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

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

Versions of packages rxvt-unicode depends on:
ii  base-passwd   3.6.1
ii  libc6 2.37-7
ii  libfontconfig12.14.2-3
ii  libgcc-s1 13.2.0-2
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libglib2.0-0  2.77.2-1
ii  libperl5.36   5.36.0-7
ii  libptytty02.0-1+b1
ii  libstartup-notification0  0.12-6+b1
ii  libx11-6  2:1.8.6-1
ii  libxext6  2:1.3.4-1+b1
ii  libxft2   2.3.6-1
ii  libxmu6   2:1.1.3-3
ii  libxrender1   1:0.9.10-1.1
ii  ncurses-base  6.4+20230625-2
ii  ncurses-term  6.4+20230625-2

Versions of packages rxvt-unicode recommends:
ii  fonts-dejavu2.37-8
pn  fonts-vlgothic | fonts-japanese-gothic  

Versions of packages rxvt-unicode suggests:
ii  sensible-utils  0.0.20

-- no debconf information

Bug#1044924: moc: Setting volume above 100% kills mocp.

[Nick]

Package: moc
Version: 1:2.6.0~svn-r3005-3
Severity: normal

Whether this belongs with moc I don't know but it's where the problem
is most immediately apparent.  To reproduce the bug (whether moc's or
not):

1. Start mocp

   $ mocp

2. Set volume of the default sink (mine has id of 1) to 100%

   $ pactl set-sink-volume 1 100%

3. Nothing changes in mocp, except the volume. Now increase the volume,

   $ pactl set-sink-volume 1 +1%

mocp promptly exits (return code 2):

   FATAL_ERROR: Can't receive value from the server!

4. Try to restart mocp:

   $ mocp
   Running the server...
   Trying JACK...
   Trying ALSA...
   mocp: alsa.c:319: alsa_read_mixer_raw: Assertion `RANGE(0, vol, 100)' failed.

   FATAL_ERROR: Server exited!

The return code is 2 again.

Reducing the volume to 100% or less allows mocp to run again.  Whether
pactl should be able to set the volume over 100% I'll leave for
someone else to decide :)

Please let me know if I can provide more information.
Thanks

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

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

Versions of packages moc depends on:
ii  libasound21.2.8-1+b1
ii  libc6 2.36-9+deb12u1
ii  libcurl3-gnutls   7.88.1-10+deb12u1
ii  libdb5.3  5.3.28+dfsg2-1
ii  libfaad2  2.10.1-1
ii  libflac12 1.4.2+ds-2
ii  libgcc-s1 12.2.0-14
ii  libid3tag00.15.1b-14
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-3
ii  libltdl7  2.4.7-5
ii  libmad0   0.15.1b-10.1+b1
ii  libmagic1 1:5.44-3
ii  libmodplug1   1:0.8.9.0-3
ii  libmpcdec62:0.1~r495-2
ii  libncursesw6  6.4-4
ii  libogg0   1.3.5-3
ii  libopusfile0  0.12-4
ii  libpopt0  1.19+dfsg-1
ii  librcc0   0.2.13+ds-2
ii  libresid-builder0c2a  2.1.1-15+b1
ii  libsamplerate00.2.2-3
ii  libsidplay2   2.1.1-15+b1
ii  libsidutils0  2.1.1-15+b1
ii  libsndfile1   1.2.0-1
ii  libspeex1 1.2.1-2
ii  libstdc++612.2.0-14
ii  libtagc0  1.13-2
ii  libtinfo6 6.4-4
ii  libvorbisfile31.3.7-1
ii  libwavpack1   5.6.0-1

moc recommends no packages.

Versions of packages moc suggests:
pn  moc-ffmpeg-plugin  

-- no debconf information

Bug#1043258: texlive-latex-extra-doc: moderncv.tex fails to build

[Nick Hastings]

Hi,

sorry the bug subject line is wrong/bad. Better would be something
like: "template.tex for moderncv.cls fails to build".

Regards,

Nick.

Bug#1043258: texlive-latex-extra-doc: moderncv.tex fails to build

[Nick Hastings]

Package: texlive-latex-extra-doc
Version: 2022.20230122-4
Severity: normal
X-Debbugs-Cc: nicholaschasti...@gmail.com

Dear Maintainer,

I have been unable to build a document using moderncv.cls. It seems
that either the documentation of the immplementaion of moderncv.cls
has a problem. The /usr/share/doc/texlive-doc/latex/moderncv/README.md
indicates that the example should be compiled with: `latexmk -pdf 
./template.tex`
Following this documentation:

mkdir ~/tmp
cd tmp
zcat /usr/share/doc/texlive-doc/latex/moderncv/template.tex.gz > template.tex
cp /usr/share/doc/texlive-doc/latex/moderncv/picture.jpg .
latexmk -pdf template.tex 2>&1 | tee build.log

This results in the build hanging and the error:

.
.
.
*geometry* driver: auto-detecting
*geometry* detected driver: pdftex
(/usr/share/texmf/tex/latex/lm/ot1lmr.fd)
(/usr/share/texlive/texmf-dist/tex/latex/microtype/mt-cmr.cfg)
(/usr/share/texmf/tex/latex/lm/omllmm.fd)
(/usr/share/texmf/tex/latex/lm/omslmsy.fd)
(/usr/share/texmf/tex/latex/lm/omxlmex.fd)
Underfull \hbox (badness 1) in paragraph at lines 93--93

! Missing number, treated as zero.
 
   }
l.95 \section{Education}

The build.log and template.log are attached.

Regards,

Nick.

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

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

Versions of packages texlive-latex-extra-doc depends on:
ii  tex-common6.18
ii  texlive-base  2022.20230122-3

texlive-latex-extra-doc recommends no packages.

texlive-latex-extra-doc suggests no packages.

Versions of packages tex-common depends on:
ii  ucf  3.0043+nmu1

Versions of packages tex-common suggests:
ii  debhelper  13.11.4

Versions of packages texlive-latex-extra-doc is related to:
ii  tex-common6.18
ii  texlive-binaries  2022.20220321.62855-5.1+deb12u1

-- no debconf information


build.log.gz
Description: application/gzip


template.log.gz
Description: application/gzip

Bug#1043073: xmobar: Battery monitor ignores "on" status string

[Nick]

Package: xmobar
Version: 0.46-1
Severity: normal

After upgrading to Debian 12, xmobar ignores the value for the -O
option in the battery monitor.  From my config,

  Run BatteryN ["BAT0"]
  ["-t", "",
   "-L", "30", "-H", "74",
   "-l", "red", "-n", "orange", "-h", "yellow",
   "-S", "on",
   "--", "-O", "▲", "-i", "=",
   "-o", "▼"]
  30 "bat0",

This worked for several years, in that "▲" would appear while the
battery is charging but now it's blank.  The strings for the other
states ("=" and "▼" in my case) do still appear as expected.

Please let me know if I can provide more information.
Thanks

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

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

Versions of packages xmobar depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9+deb12u1
ii  libcairo21.16.0-7
ii  libffi8  3.4.4-1
ii  libglib2.0-0 2.74.6-2
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libiw30  30~pre9-14
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxinerama1 2:1.1.4-3
ii  libxpm4  1:3.5.12-1.1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  libxss1  1:1.2.3-1
ii  zlib1g   1:1.2.13.dfsg-1

xmobar recommends no packages.

Versions of packages xmobar suggests:
ii  xmonad  0.17.1-1

-- no debconf information

Bug#1043072: xmobar: Missing documentation

[Nick]

Package: xmobar
Version: 0.46-1
Severity: normal

After upgrading to Debian 12, xmobar's documentation, or most if it,
disappeared.  readme.org.gz refers to "file:doc/quick-start.org"
but there's no such file.

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

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

Versions of packages xmobar depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9+deb12u1
ii  libcairo21.16.0-7
ii  libffi8  3.4.4-1
ii  libglib2.0-0 2.74.6-2
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libiw30  30~pre9-14
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libx11-6 2:1.8.4-2+deb12u1
ii  libxext6 2:1.3.4-1+b1
ii  libxft2  2.3.6-1
ii  libxinerama1 2:1.1.4-3
ii  libxpm4  1:3.5.12-1.1
ii  libxrandr2   2:1.5.2-2+b1
ii  libxrender1  1:0.9.10-1.1
ii  libxss1  1:1.2.3-1
ii  zlib1g   1:1.2.13.dfsg-1

xmobar recommends no packages.

Versions of packages xmobar suggests:
ii  xmonad  0.17.1-1

-- no debconf information

Bug#1042713: wireplumber: High cpu usage

[Nick]

El 2023-08-01 11:22 PYT, Dylan Aïssi escribió:
> Do you have pipewire-libcamera installed? If yes, can you remove it?

"pipewire-libcamera" doesn't appear anywhere under /var/log/apt so I
think it's never been installed.

> Can you provide log from pipewire and wireplumber as explained here [1]?

I'm attaching the result of

   $ journalctl --user-unit=pipewire --user-unit=wireplumber \
   --user-unit=pipewire-pulse  --since="2023-07-29" \
   --until="2023-07-30" > log1.txt

which I think includes the result of my first boot into debian 12, soon
followed by my killing wireplumber.  Hope that helps.

> Best regards,
> Dylan

Thanks for replying, I'll try to supply more if needed.
-- 
Nick
Asunción 12:03 PYT ►  30.7°C  ◆  cielo claro  ◆  22Km/h NNE  ◆  40% HR
Jul 29 10:45:59 argon systemd[1380]: Stopping Multimedia Service...
Jul 29 10:45:59 argon pipewire-media-session[1419]: error id:0 seq:164 res:-32 
(Broken pipe): connection error
Jul 29 10:45:59 argon systemd[1380]: pipewire.service: Succeeded.
Jul 29 10:45:59 argon systemd[1380]: Stopped Multimedia Service.
Jul 29 10:45:59 argon systemd[1380]: pipewire.service: Consumed 40.688s CPU 
time.
-- Boot 1fda9ee2cfc54a14bbab068213dac2d7 --
Jul 29 10:46:53 argon systemd[1422]: Started pipewire.service - PipeWire 
Multimedia Service.
Jul 29 10:46:53 argon systemd[1422]: Started wireplumber.service - Multimedia 
Service Session Manager.
Jul 29 10:46:53 argon systemd[1422]: Started pipewire-pulse.service - PipeWire 
PulseAudio.
Jul 29 10:46:53 argon pipewire[1438]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jul 29 10:46:53 argon pipewire-pulse[1440]: mod.rt: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jul 29 10:46:53 argon pipewire-pulse[1440]: mod.rt: found session bus but no 
portal
Jul 29 10:46:53 argon pipewire[1438]: mod.rt: found session bus but no portal
Jul 29 10:46:53 argon wireplumber[1439]: Can't find 
org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
Jul 29 10:46:53 argon wireplumber[1439]: found session bus but no portal
Jul 29 10:46:54 argon wireplumber[1439]: Failed to set scheduler settings: 
Operation not permitted
Jul 29 10:46:54 argon wireplumber[1439]: SPA handle 
'api.libcamera.enum.manager' could not be loaded; is it installed?
Jul 29 10:46:54 argon wireplumber[1439]: PipeWire's libcamera SPA missing or 
broken. libcamera not supported.
Jul 29 10:46:54 argon wireplumber[1439]: SPA handle 'api.bluez5.enum.dbus' 
could not be loaded; is it installed?
Jul 29 10:46:54 argon wireplumber[1439]: PipeWire's BlueZ SPA missing or 
broken. Bluetooth not supported.
Jul 29 10:46:54 argon wireplumber[1439]:  
Object activation aborted: proxy destroyed
Jul 29 10:46:54 argon wireplumber[1439]:  
failed to activate item: Object activation aborted: proxy destroyed
Jul 29 10:53:05 argon wireplumber[1439]: stopped by signal: Terminated
Jul 29 10:53:05 argon wireplumber[1439]: disconnected from pipewire
Jul 29 10:53:05 argon systemd[1422]: wireplumber.service: Consumed 5min 6.906s 
CPU time.

Bug#1042713: Workaround

[Nick]

In case it helps anyone else, this has so far fixed the problem
introduced by wireplumber:

# apt-get purge wireplumber
# apt-get autoremove --purge

Then I killed and restarted pulseaudio.
-- 
Nick<http://acrasis.net>
Asunción 11:55 PYT ►  29.7°C  ◆  cielo claro  ◆  9Km/h N  ◆  48% HR

Bug#999977: qxw: depends on obsolete pcre3 library

[Nick Morrott]

On 2023/07/22 at 08:43, Stephen Kitt wrote:
>aOn Sat, 22 Jul 2023 16:14:06 +0200, Bastian Germann  wrote:
> > I suggest to remove the package. I do not think upstream will deal with 
> > this.
> 
> qxw’s usage of pcre seems simple enough, I’ll try to come up with a patch.
> 
> Regards,
> 
> Stephen

Bastian/Stephen,

In my last contact with upstream I discussed the use of the obsolete pcre3
library. The development team told me that a new GTK3/Qt GUI is under
development which will resolve the pcre3 issue in addition to the
proposed UI improvements.

In the meantime, I will look to spend some time understanding the
pcre3->pcre2 migration and patching qxw in the short term, if Stephen does
not have time to do so.

I'd like to keep qxw in the archive, given the time spent getting it
reintroduced in time for bookworm following the RFP.

Thanks,
Nick

Bug#1042713: wireplumber: High cpu usage

[Nick]

Package: wireplumber
Version: 0.4.13-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Upgrading to debian 12.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Followed the instructions in the release notes.

   * What was the outcome of this action?

On rebooting, a process called wireplumber consumes most of the cpu.
Sound does work.  If I kill the process, cpu usage falls, my fan stops
spinning and I no longer have sound.  I have to kill wireplumber on
each reboot (or let it try to fry my cpu).

Please let me know if I can provide more information.

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

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

Versions of packages wireplumber depends on:
ii  init-system-helpers   1.65.2
ii  libc6 2.36-9+deb12u1
ii  libglib2.0-0  2.74.6-2
ii  libpipewire-0.3-0 0.3.65-3
ii  libwireplumber-0.4-0  0.4.13-1
ii  pipewire  0.3.65-3

Versions of packages wireplumber recommends:
ii  pipewire-pulse  0.3.65-3

Versions of packages wireplumber suggests:
pn  libspa-0.2-bluetooth  
pn  wireplumber-doc   

-- no debconf information

Bug#1040783: libvirt-daemon: libvirt firewalld zone is missing

[Nick Hastings]

Hi,

On Tue, 11 Jul 2023 04:41:07 +0200 =?UTF-8?Q?Niccol=C3=B2_Belli?= 
 wrote:
> I've found the root of the problem: I was connecting to libvirt via ssh 
> using an unprivileged user part of the libvirt group. That works for 
> most of the tasks but not for creating the firewalld libvirt zone. Using 
> root, while being less than ideal, works fine.

I'm facing the same problem. I'm running virt-manager on the localhost as
a user who is a member of the libvirt group. What did you actually run as
root to have the libvirt zone created?

Thanks,

Nick.

Bug#955733: cloud-init does not set locale specified in user data

[Nick Holloway]

On Wed, Jun 28, 2023 at 08:51:46PM -0700, Noah Meyerhans wrote:
> I think that each of the components is working correct if viewed in
> isolation, but the end result is not what you expect.  If we document
> that you must first populate /etc/locale.gen with the desired list of
> available locales, that may be sufficient.  For example, the following
> sets the desired locale:
> 
> admin@ip-10-0-3-7:~$ sudo cat /var/lib/cloud/instance/user-data.txt
> #cloud-config
> write_files:
> - path: /etc/locale.gen
>   content: ZW5fR0IuVVRGLTggVVRGLTgK
>   encoding: base64
> locale: en_GB.UTF-8
> admin@ip-10-0-3-7:~$ echo "ZW5fR0IuVVRGLTggVVRGLTgK" | openssl base64 -d
> en_GB.UTF-8 UTF-8

This feels like a workaround for the failure of cloud-init setting the locale
on a Debian install.

The locale configuration in cloud-init is expecting locale-gen to configure the
generated locales with the specified locale.


https://git.launchpad.net/ubuntu/+source/cloud-init/tree/cloudinit/distros/debian.py#n401

Debian just ignores the locale passed as a parameter.

> Do Ubuntu systems list all known locales in /etc/locale.gen?  That would
> make the locale module work without additional configuration, but seems
> unnecessarily expensive.

Ubuntu does not list all locales in /etc/locale.gen, but their version of
locale-gen will update /etc/locale.gen to add/uncomment the specified locale
before generating locales.


https://git.launchpad.net/ubuntu/+source/glibc/tree/debian/local/usr_sbin/locale-gen?h=ubuntu/jammy#n115

It seems cloud-init has expectation on what locale-gen will do (i.e. _update_
and generate), and that is not the case.

I don't know if cloud-init should take on the responsibility for updating
/etc/locale.gen, or if locale-gen should update /etc/locale.gen if passed a
parameter.

Bug#1028633:

[Nick Rosbrook]

Hi,

I have opened a pull request[1] to fix this FTBFS. We experienced the
same problem in Ubuntu[2], and these changes resolved the problem for
us.

Thanks,
Nick

[1] https://salsa.debian.org/science-team/mlpack/-/merge_requests/2
[2] https://bugs.launchpad.net/ubuntu/+source/mlpack/+bug/2025291

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

[Nick Hastings]

Hi,

* Limonciello, Mario  [230701 06:40]:
> 
> > > 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/

Thanks.

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

Cheers,

Nick.

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

[Nick Hastings]

Hi,

* Thorsten Leemhuis  [230630 22:02]:
> On 27.06.23 00:34, Nick Hastings wrote:
> > * Linux regression tracking (Thorsten Leemhuis)  
> > [230626 21:09]:
> >> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> >> for once, to make this easily accessible to everyone.
> >>
> >> Nick, what's the status/was there any progress? Did you do what Mario
> >> suggested and file a nouveau bug?
> > 
> > It was not apparent that the suggestion to open "a Nouveau drm bug" was
> > addressed to me.
> 
> I wish things were earlier for reporters, but from what I can see this
> is the only way forward if you or some silent bystander cares.

In principle I can open another bug report, but I don't know how or
where to report "a Nouveau drm bug". Please keep in mind that I'm just
an end user. I learnt to use git bisect specifically because of this
bug. Prior to that, I hadn't compiled a kernel in about 15 years.

> >> I ask, as I still have this on my list of regressions and it seems there
> >> was no progress in three+ weeks now.
> > 
> > I have not pursued this further since as far as I could tell I already
> > provided all requested information and I don't actually use nouveau, so
> > I blacklisted it.
> 
> I doubt any developer cares enough to take a closer look[1] without a
> proper nouveau bug and some help & prodding from someone affected. And
> looks to me like reverting the culprit now might create even bigger
> problems for users.

If someone can point me to some docs about for reporting nouveau bugs I
can look into it.

> Hence I guess then this won't be fixed in the end. In a ideal world this
> would not happen, but we don't live in one and all have just 24 hours in
> a day. :-/

This is a very common Dell XPS 15 7590 so I expect many people could
experience this issue. Or maybe like me they only use the intel GPU.

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

Cheers,

Nick.

> [1] some points on the following page kinda explain this
> https://linux-regtracking.leemhuis.info/post/frequent-reasons-why-linux-kernel-bug-reports-are-ignored/
> 
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> #regzbot inconclusive: reporting deadlock (see thread for details)
 > 
> 
> 
> >> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> >> --
> >> Everything you wanna know about Linux kernel regression tracking:
> >> https://linux-regtracking.leemhuis.info/about/#tldr
> >> If I did something stupid, please tell me, as explained on that page.
> >>
> >> #regzbot backburner: slow progress, likely just affects one machine
> >> #regzbot poke
> >>
> >>
> >> On 02.06.23 02:57, Limonciello, Mario wrote:
> >>> [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..

Bug#1039867: release.debian.org: Site uses old favicon.ico

[Nick Hastings]

Package: release.debian.org
Severity: minor
X-Debbugs-Cc: nicholaschasti...@gmail.com

Hi,

the site https://release.debian.org uses an old version
of the debian favicon.ico that renders poorly on dark
backgrounds. Please use the same favicon.ico as https://www.debian.org

Note that this is also a problem on https://backports.debian.org and
https://search.debian.org. I have already attempted to alert the relevant
people for those sites.

Regards,

Nick.

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

[Nick Hastings]

Hi Thorsten,

* Linux regression tracking (Thorsten Leemhuis)  
[230626 21:09]:
> Hi, Thorsten here, the Linux kernel's regression tracker. Top-posting
> for once, to make this easily accessible to everyone.
> 
> Nick, what's the status/was there any progress? Did you do what Mario
> suggested and file a nouveau bug?

It was not apparent that the suggestion to open "a Nouveau drm bug" was
addressed to me.

> I ask, as I still have this on my list of regressions and it seems there
> was no progress in three+ weeks now.

I have not pursued this further since as far as I could tell I already
provided all requested information and I don't actually use nouveau, so
I blacklisted it.

Regards,

Nick.

> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
> 
> #regzbot backburner: slow progress, likely just affects one machine
> #regzbot poke
> 
> 
> On 02.06.23 02:57, Limonciello, Mario wrote:
> > [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:

Bug#995670: What's the status of this ITP?

[Nick Hastings]

Hi,

* Abraham Raji  [230620 17:37]:
> 
> On 20/06/23 13:54, Nick Hastings wrote:
> 
> > As far as I know the d/copyright file covers everything.
> > 
> > > Or is there a licensing issue here?
> > 
> > I don't think there is a licensing issue.
> > 
> > It is the specifics of the d/copyright file I produced. Please see the
> > RFS bug for details.
> 
> Will take a look. Thanks.
> 
> 
> > > I have created a zig-team namespace on salsa and I've invited you there.
> > > We can move the packaging work there as it will make it easier for
> > > potential contributors to find it.
> > 
> > I joined it.
> 
> Great let's get the zig package there.

Done.

> > > Also is there any particular reason you are only committing the debian
> > > directory?
> > 
> > That is all that exists in the repo. Builds are done by downloading the
> > source with uscan with the info from the d/watch file. I did try to look
> > into keeping upstream in the same repo but I didn't find a clear path
> > forward. So I just stuck with what I am currently doing since it works
> > and from the documentation I have read is not "incorrect". If you could
> > recommend specific documentation for this I can have a look.
> 
> I do find the ruby team's approach to be very nice here. Adding link
> to a sample ruby package for reference[0].  The approach is to keep
> the upstream files and tar ball deltas in separate branches (upstream
> and pristine-tar). The tooling makes maintaining this pretty seamless.

I see. I'll  try to have a look.

> Please take a look at these page for more information: -
> https://wiki.debian.org/SimplePackagingTutorial -
> https://wiki.abrahamraji.in/simple-packaging-tutorial.html

I'm familiar with this level of packaging.

IIRC when I tried to look at a "proper" packaging work flow using git
there did not appear to be a "correct" way to do it. Multiple different
approaches only quite briefly documented. Perhaps without much
information about why particular things were done, and seemingly to
expecting knowledge of the other approaches.

Cheers,

Nick.

> [0]: https://salsa.debian.org/ruby-team/atig

Bug#995670: What's the status of this ITP?

[Nick Hastings]

Hi,

* Abraham Raji  [230620 16:53]:
> 
> On 20/06/23 04:48, Nick Hastings wrote:
> > There was some progress and some interest from a potential sponsor but
> > it seems that the copyright file has become a road block.
> 
> What exactly is the roadblock? Is it just a matter of going through each
> of the files and adding the entries?

As far as I know the d/copyright file covers everything.

> Or is there a licensing issue here?

I don't think there is a licensing issue.

It is the specifics of the d/copyright file I produced. Please see the
RFS bug for details.

> Asking because for the first we can always try and get more people to
> help out.

That would be nice.

> > My package is on salsa: https://github.com/NickHastings/zig-debian

Adding the correction here too: https://salsa.debian.org/nickh/zig

> I have created a zig-team namespace on salsa and I've invited you there.
> We can move the packaging work there as it will make it easier for
> potential contributors to find it.

I joined it.

> Also is there any particular reason you are only committing the debian
> directory?

That is all that exists in the repo. Builds are done by downloading the
source with uscan with the info from the d/watch file. I did try to look
into keeping upstream in the same repo but I didn't find a clear path
forward. So I just stuck with what I am currently doing since it works
and from the documentation I have read is not "incorrect". If you could
recommend specific documentation for this I can have a look.

Cheers,

Nick.

Bug#995670: What's the status of this ITP?

[Nick Hastings]

* Nick Hastings  [230620 08:18]:
> 
> My package is on salsa: https://github.com/NickHastings/zig-debian

While that statement is true, the link is clearly not the intended one.
https://salsa.debian.org/nickh/zig

Nick.

Bug#995670: What's the status of this ITP?

[Nick Hastings]

Hi,

* Abraham Raji  [230620 06:38]:
> 
> What's the status of this ITP? It seems like Nick is pulling a
> considerable amount of work himself.

I filed an RFS bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012286
There was some progress and some interest from a potential sponsor but
it seems that the copyright file has become a road block.

> I would personally love to see Zig in the Debian archives so I am
> ready to volunteer some of my time towards the effort.

My zig package is up to date with the current version of zig 0.10.1 and
this version of zig can bootstrap. However, it seems that the next
planned release of zig will not be able to bootstrap (in the usual
sense). See for example https://ziglang.org/news/goodbye-cpp/

> I feel we can move the work for this package to salsa if no one has any
> issues.

My package is on salsa: https://github.com/NickHastings/zig-debian

Cheers,

Nick.

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

[Nick Hastings]

Hi,

* 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]
   +-02.0  Intel Corporation CoffeeLake-H GT2 [UHD Graphics 630] 
[8086:3e9b]
   +-04.0  Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor Thermal Subsystem [8086:1903]
   +-08.0  Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 
6th/7th/8th Gen Core Processor Gaussian Mixture Model [8086:1911]
   +-12.0  Intel Corporation Cannon Lake PCH Thermal Controller 
[8086:a379]
   +-14.0  Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host 
Controller [8086:a36d]
   +-14.2  Intel Corporation Cannon Lake PCH Shared SRAM [8086:a36f]
   +-15.0  Intel Corporation Cannon Lake PCH Serial IO I2C Controller 
#0 [8086:a368]
   +-15.1  Intel Corporation Cannon Lake PCH Serial IO I2C Controller 
#1 [8086:a369]
   +-16.0  Intel Corporation Cannon Lake PCH HECI Controller [8086:a360]
   +-17.0  Intel Corporation Cannon Lake Mobile PCH SATA AHCI 
Controller [8086:a353]
   +-1b.0-[02-3a]00.0-[03-3a]--+-00.0-[04]00.0  Intel 
Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] 
[8086:15d9]
   |   +-01.0-[05-39]--
   |   \-02.0-[3a]00.0  Intel 
Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 
2016] [8086:15db]
   +-1c.0-[3b]00.0  Intel Corporation Wi-Fi 6 AX200 [8086:2723]
   +-1c.4-[3c]00.0  Realtek Semiconductor Co., Ltd. RTS525A PCI 
Express Card Reader [10ec:525a]
   +-1d.0-[3d]00.0  Samsung Electronics Co Ltd NVMe SSD Controller 
SM981/PM981/PM983 [144d:a808]
   +-1f.0  Intel Corporation Cannon Lake LPC Controller [8086:a30e]
   +-1f.3  Intel Corporation Cannon Lake PCH cAVS [8086:a348]
   +-1f.4  Intel Corporation Cannon Lake PCH SMBus Controller 
[8086:a323]
   \-1f.5  Intel Corporation Cannon Lake PCH SPI Controller
   [8086:a324]


Regards,

Nick.

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

[Nick Hastings]

Hi,

* Limonciello, Mario  [230602 01:18]:
> +Lyude, Lukas, Karol
> 
> On 5/31/2023 6:40 PM, Nick Hastings wrote:
> > 
> > * 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?

I reported this twice already. I guess it was lost since for some
reason emails in this thread are not being trimmed. I'll repeat here:

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.

Regards,

Nick.

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

[Nick Hastings]

Hi,

* Nick Hastings  [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.

Bug#1036960: plocate: coredump on any search

[Nick Black (Public gmail account)]

Package: plocate
Version: 1.1.18-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

   * What led up to the situation?

I've been using plocate for many months on all my machines without problems.
Recently, I get a coredump on any search, on all the machines on which I've
tested. I've got a stack trace that points at do_search_file():

Thread 1 (Thread 0x7f426c687740 (LWP 914015) "locate"):
#0  __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f426c2a9d2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f426c25aef2 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3  0x7f426c245472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f426c29e2d0 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f426c3b8459 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#5  0x7f426c2b364a in malloc_printerr (str=str@entry=0x7f426c3b60b1
"free(): invalid pointer") at ./malloc/malloc.c:5660
#6  0x7f426c2b53d4 in _int_free (av=, p=,
have_lock=have_lock@entry=0) at ./malloc/malloc.c:4435
#7  0x7f426c2b7d2f in __GI___libc_free (mem=) at
./malloc/malloc.c:3385
#8  0x5617abf86e1a in do_search_file (needles=std::vector of length 1,
capacity 1 = {...}, filename="plocate.db") at ../plocate.cpp:491
#9  0x5617abf804b8 in main (argc=, argv=) at
../plocate.cpp:995

this also happens with an empty database.


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

Kernel: Linux 6.3.4nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages plocate depends on:
ii  adduser 3.134
ii  libc6   2.36-9
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  liburing2   2.3-3
ii  libzstd11.5.4+dfsg2-5

plocate recommends no packages.

Versions of packages plocate suggests:
ii  nocache 1.1-1+b1
ii  powermgmt-base  1.37
ii  systemd-sysv252.6-1

-- Configuration Files:
/etc/updatedb.conf changed:
PRUNE_BIND_MOUNTS="yes"
PRUNEPATHS="/tmp /var/spool /media/usb /media/dank /media/mtp /media/killermike 
/var/lib/os-prober /var/lib/ceph /home/.ecryptfs /var/lib/schroot"
PRUNEFS="NFS afs autofs binfmt_misc ceph cgroup cgroup2 cifs coda configfs 
curlftpfs debugfs devfs devpts devtmpfs ecryptfs ftpfs fuse.ceph fuse.cryfs 
fuse.encfs fuse.glusterfs fuse.gocryptfs fuse.gvfsd-fuse fuse.mfs fuse.rclone 
fuse.rozofs fuse.sshfs fusectl fusesmb hugetlbfs iso9660 lustre lustre_lite mfs 
mqueue ncpfs nfs nfs4 ocfs ocfs2 proc pstore rpc_pipefs securityfs shfs smbfs 
sysfs tmpfs tracefs udev udf usbfs"


-- no debconf information

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

[Nick Hastings]

Hi,

* Mario Limonciello  [230530 13:00]:
> 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) (20220

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

[Nick Hastings]

Hi,

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

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

[Nick Hastings]

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

I let this run for 3 hours without issue.

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

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

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

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

Yes nouveau is blacklisted.

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

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

Regards,

Ncik.

Bug#1036530: linux-signed-amd64: Hard lock up of system

[Nick Hastings]

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.

Regards,

Nick.

* Salvatore Bonaccorso  [230526 20:30]:
> Control: tags -1 + moreinfo
> 
> Hi Nick,
> 
> On Fri, May 26, 2023 at 09:25:23AM +0900, Nick Hastings wrote:
> > Hi Salvatore,
> > 
> > thanks for your help. However, I'm now not sure if I really have
> > identified the commit that causes my problems. I fear I may have made
> > one or more mistakes when setting "git bisect good". I had been under
> > the impression that the lock up would happen no more than a few tens of
> > minutes after booting, however it seems that sometimes it can take a few
> > hours to occur.
> > 
> > So, I'm running the git bisect again and will be more careful before
> > marking "git bisect good". It could take a few days.
> > 
> > Should this particular bug be closed?
> 
> Thanks a lot for reporting back, you time put in into bisect is very
> appreciated and valued! No, no need to close this one, as the bug
> still persist. Just followup please once you have identified the
> culprit with the fresh bisect.
> 
> Please do remove by then as well the moreinfo tag again (you can write
> a control message with tag -1 - moreinfo, so won't appear as bug
> needing information from reporter).
> 
> Thank you!
> 
> Regards,
> Salvatore

Bug#1036530: linux-signed-amd64: Hard lock up of system

[Nick Hastings]

Hi Salvatore,

thanks for your help. However, I'm now not sure if I really have
identified the commit that causes my problems. I fear I may have made
one or more mistakes when setting "git bisect good". I had been under
the impression that the lock up would happen no more than a few tens of
minutes after booting, however it seems that sometimes it can take a few
hours to occur.

So, I'm running the git bisect again and will be more careful before
marking "git bisect good". It could take a few days.

Should this particular bug be closed?

Thanks,

Nick.


* Salvatore Bonaccorso  [230526 00:19]:
> Hi Nick,
> 
> On Thu, May 25, 2023 at 08:23:15AM +0900, Nick Hastings wrote:
> > Hi,
> > 
> > * Salvatore Bonaccorso  [230524 19:26]:
> > >
> > > Given you were able to bisect it so far, can you try to isolate the
> > > commit from the merge commit causing it?
> > 
> > I guess I can try. The commit message states:
> > 
> > Merge: c77f54a9bcec a1cf1fd62ae7 562163595a91 018d6711c26e 6cc401be1648
> > 
> > Is there a way extract out each of those?
> 
> Th way i usuually get all commits from a merge request is
> 
> git log --oneline $mergecommit^$mergecommit^2
> 
> though here we have three merge commits, merged with one merge commit
> on top, so you would go down the merges of the acpi-properties,
> acpi-tables, acpi-x86 and acpi-soc branches. Those are those:
> 
> * acpi-properties:
>   ACPI: property: Silence missing-declarations warning in apple.c
> 
> * acpi-tables:
>   ACPI: HMAT: Drop unused dev_fmt() and redundant 'HMAT' prefix
>   ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys 
> address
> 
> * acpi-x86:
>   ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable
> 
> * acpi-soc:
>   ACPI: LPSS: Deduplicate skipping device in acpi_lpss_create_device()
>   ACPI: LPSS: Replace loop with first entry retrieval
> 
> > > One remotely related might be "ACPI: x86: Add a quirk for Dell
> > > Inspiron 14 2-in-1 for StorageD3Enable".
> > 
> > Manually looking at the diff with
> > git diff e996c7e01892ac18ec0db447294d4f591c325efe~  
> > e996c7e01892ac18ec0db447294d4f591c325efe 
> > I guess that means the following:
> > 
> > --- a/drivers/acpi/x86/utils.c
> > +++ b/drivers/acpi/x86/utils.c
> > @@ -207,9 +207,26 @@ static const struct x86_cpu_id storage_d3_cpu_ids[] = {
> > {}
> >  };
> >  
> > +static const struct dmi_system_id force_storage_d3_dmi[] = {
> > +   {
> > +   /*
> > +* _ADR is ambiguous between GPP1.DEV0 and GPP1.NVME
> > +* but .NVME is needed to get StorageD3Enable node
> > +* https://bugzilla.kernel.org/show_bug.cgi?id=216440
> > +*/
> > +   .matches = {
> > +   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14 7425 
> > 2-in-1"),
> > +   }
> > +   },
> > +   {}
> > +};
> > +
> >  bool force_storage_d3(void)
> >  {
> > -   return x86_match_cpu(storage_d3_cpu_ids);
> > +   const struct dmi_system_id *dmi_id = 
> > dmi_first_match(force_storage_d3_dmi);
> > +
> > +   return dmi_id || x86_match_cpu(storage_d3_cpu_ids);
> >  }
> 
> That probably won't work actually as the code has been refactored
> substantiantly after the commit. 
> 
> In the ideal case we could confirm the quirk change is the responsable
> commit, so we can make upstream aware.
> 
> Regards,
> Salvatore

Bug#1036530: linux-signed-amd64: Hard lock up of system

[Nick Hastings]

Hi,

* Salvatore Bonaccorso  [230524 19:26]:
>
> Given you were able to bisect it so far, can you try to isolate the
> commit from the merge commit causing it?

I guess I can try. The commit message states:

Merge: c77f54a9bcec a1cf1fd62ae7 562163595a91 018d6711c26e 6cc401be1648

Is there a way extract out each of those?

> One remotely related might be "ACPI: x86: Add a quirk for Dell
> Inspiron 14 2-in-1 for StorageD3Enable".

Manually looking at the diff with
git diff e996c7e01892ac18ec0db447294d4f591c325efe~  
e996c7e01892ac18ec0db447294d4f591c325efe 
I guess that means the following:

--- a/drivers/acpi/x86/utils.c
+++ b/drivers/acpi/x86/utils.c
@@ -207,9 +207,26 @@ static const struct x86_cpu_id storage_d3_cpu_ids[] = {
{}
 };
 
+static const struct dmi_system_id force_storage_d3_dmi[] = {
+   {
+   /*
+* _ADR is ambiguous between GPP1.DEV0 and GPP1.NVME
+* but .NVME is needed to get StorageD3Enable node
+* https://bugzilla.kernel.org/show_bug.cgi?id=216440
+*/
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+   DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14 7425 2-in-1"),
+   }
+   },
+   {}
+};
+
 bool force_storage_d3(void)
 {
-   return x86_match_cpu(storage_d3_cpu_ids);
+   const struct dmi_system_id *dmi_id = 
dmi_first_match(force_storage_d3_dmi);
+
+   return dmi_id || x86_match_cpu(storage_d3_cpu_ids);
 }
 

Thanks,

Nick.

Bug#1036530: linux-signed-amd64: Hard lock up of system

[Nick Hastings]

Source: linux-signed-amd64
Severity: important
Tags: upstream
X-Debbugs-Cc: nicholaschasti...@gmail.com

Dear Maintainer,

after upgrading from a 6.0.0 kernel to a 6.1.0 kernel I experienced
hard lockups on my Dell XPS 15 7590 a few minutes after each boot.  On
more than one occasion I was on the console and was able to see the
error message. It was the same error on each occasion, and I reproduce
it here:

[   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

N.B. the message on the console was recorded with at photograph and
then manually typed in, so it is possible that it may contain one or
more errors.

I ran git bisect as descirbed at
https://wiki.debian.org/DebianKernel/GitBisect which seems to have
found the bad commit. It is a merge commit that deals with acpi code.
However I don't see what may actually be causing this issue.
The commit is e996c7e01892ac18ec0db447294d4f591c325efe

Please find the report from git bisect below.

Regards,

Nick.

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

Kernel: Linux 6.0.0-rc6-1-g018d6711c26e (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


% git bisect good
e996c7e01892ac18ec0db447294d4f591c325efe is the first bad commit
commit e996c7e01892ac18ec0db447294d4f591c325efe
Merge: c77f54a9bcec a1cf1fd62ae7 562163595a91 018d6711c26e 6cc401be1648
Author: Rafael J. Wysocki 
Date:   Fri Sep 30 20:52:39 2022 +0200

Merge branches 'acpi-properties', 'acpi-tables', 'acpi-x86' and 'acpi-soc'

Merge changes related to ACPI data-only tables handling and ACPI device
properties management, x86-specific ACPI code changes and ACPI SoC driver
changes for 6.1-rc1:

 - Clean up the ACPI LPSS (Intel SoC) driver (Andy Shevchenko).

 - Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable (Mario
   Limonciello).

 - Drop unused dev_fmt() and redundant 'HMAT' prefix from the HMAT
  parsing code (Liu Shixin).

 - Make ACPI FPDT parsing code avoid calling acpi_os_map_memory() on
   invalid physical addresses (Hans de Goede).

 - Silence missing-declarations warning related to Apple device
   properties management (Lukas Wunner).

* acpi-properties:
  ACPI: property: Silence missing-declarations warning in apple.c

* acpi-tables:
  ACPI: HMAT: Drop unused dev_fmt() and redundant 'HMAT' prefix
  ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys 
address

* acpi-x86:
  ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable

* acpi-soc:
  ACPI: LPSS: Deduplicate skipping device in acpi_lpss_create_device()
  ACPI: LPSS: Replace loop with first entry retrieval

 drivers/acpi/acpi_fpdt.c | 22 ++
 drivers/acpi/acpi_lpss.c | 45 +
 drivers/acpi/numa/hmat.c | 25 -
 drivers/acpi/x86/apple.c |  1 +
 drivers/acpi/x86/utils.c | 19 ++-
 5 files changed, 74 insertions(+), 38 deletions(-)
 [0 running job(s)] {history#6810} 2023-05-20 20:54:16

Bug#1035848: imake on riscv64

[Nick Fousac]

Dear Maintainer,

   * What led up to the situation?

I tried to compile (wery old) xview/openlook project which is
"controlled" by Imakefile.

The **imake** did it's job then some **Makefile**s was generated.

When running **make** I got following error message:

```

gcc: warning: LinuxMachineDefines: linker input file unused because
linking not done
gcc: error: LinuxMachineDefines: linker input file not found: No such
file or directory
make[2]: *** [Makefile:1214: ol_button.o] Error 1
make[2]: Leaving directory '/home/david/RaD/source/xview/lib/libolgx'
make[1]: *** [Makefile:1166: all] Error 2
make[1]: Leaving directory '/home/david/RaD/source/xview/lib'
make: *** [Makefile:1190: all] Error 2

```

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I checked files for presence of string LinuxMachineDefines and I found
them in linux.cf. I realized that structure of defines in linux.cf and
Imake.cf is not obvious for me.

   * What was the outcome of this action?

N/A

   * What outcome did you expect instead?
Generated Makefiles, with no artifacts like this.


With Regards David D.

Bug#1032620: doctest: new 2.4.10 out, fixes pernicious bugs

[Nick Black (Public gmail account)]

Source: doctest
Version: 2.4.9~ds-1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Hello! My package notcurses depends on doctest. doctest 2.4.9 was released with
some issues that led to FTBFS without patchery. Thankfully, 2.4.10 has these
fixed. Hopefully it's possible to get an upgrade in before hard freeze. Thanks!


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

Kernel: Linux 6.2.2nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1032402: calcurse: New upstream since 2022-04-16

[Nick Hastings]

Package: calcurse
Version: 4.6.0-2
Severity: normal
X-Debbugs-Cc: nicholaschasti...@gmail.com

Dear Maintainer,

unstable contains calcurse 4.7.1-1, howver a new version, 4.8.0 of
calcurse was released 11 months ago. Could the calcurse version in
Debian please be updated?

Thanks,

Nick.

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (100, 
'bullseye-fasttrack'), (100, 'bullseye-backports-staging')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages calcurse depends on:
ii  libc6 2.31-13+deb11u5
ii  libncursesw6  6.2+20201114-2
ii  libtinfo6 6.2+20201114-2
ii  python3   3.9.2-3

calcurse recommends no packages.

calcurse suggests no packages.

-- no debconf information

Bug#1026725: python-structlog: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.11 3.10" returned exit code 13

[Nick Rosbrook]

Package: python-structlog
Followup-For: Bug #1026725
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

I found that an upstream commit[1] already contained the fix for this.
This patch just takes the relevant portion of that commit.

Thanks,
Nick

[1] 
https://github.com/hynek/structlog/commit/1012f5606b356d4fe1a9027513602c758bf51ab8
diff -Nru 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
--- 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
  1969-12-31 19:00:00.0 -0500
+++ 
python-structlog-20.1.0/debian/patches/fix-assertion-in-test_delattr_missing.patch
  2023-02-08 15:50:24.0 -0500
@@ -0,0 +1,20 @@
+Description: Fix test_delattr_missing for python 3.11
+Origin: upstream, 
https://github.com/hynek/structlog/commit/1012f5606b356d4fe1a9027513602c758bf51ab8
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026725
+Bug-Ubuntu: 
https://bugs.launchpad.net/ubuntu/+source/python-structlog/+bug/2006634
+Last-Update: 2023-02-08
+---
+--- a/tests/test_threadlocal.py
 b/tests/test_threadlocal.py
+@@ -251,7 +251,10 @@
+ with pytest.raises(AttributeError) as e:
+ d._tl.__delattr__("does_not_exist")
+ 
+-assert "does_not_exist" == e.value.args[0]
++assert e.value.args[0] in (
++"does_not_exist",
++"'_thread._local' object has no attribute 'does_not_exist'",
++)
+ 
+ def test_del(self, D):
+ """
diff -Nru python-structlog-20.1.0/debian/patches/series 
python-structlog-20.1.0/debian/patches/series
--- python-structlog-20.1.0/debian/patches/series   1969-12-31 
19:00:00.0 -0500
+++ python-structlog-20.1.0/debian/patches/series   2023-02-08 
15:46:13.0 -0500
@@ -0,0 +1 @@
+fix-assertion-in-test_delattr_missing.patch

Bug#1030867: aseba: Missing builds on s390x and ppc64el

[Nick Rosbrook]

Package: aseba
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear Maintainer,

In Ubuntu, aseba previously built on s390x and ppc64el. I see build
architectures were restricted[1] in a recent version. I have tested
s390x and ppc64el builds in Ubuntu, and would like to re-enable those
arches.

Thanks for considering the patch.

-Nick

[1] 
https://salsa.debian.org/science-team/aseba/-/commit/d5ad0ce97c814ccac777cf5ee86eeaaf4b5a9bac
[2] 
https://launchpad.net/~enr0n/+archive/ubuntu/proposed-migration/+packages?field.name_filter=aseba_filter=published_filter=lunar
diff -Nru aseba-1.6.99+dfsg/debian/control aseba-1.6.99+dfsg/debian/control
--- aseba-1.6.99+dfsg/debian/control2022-07-15 12:25:36.0 -0400
+++ aseba-1.6.99+dfsg/debian/control2023-02-07 09:58:53.0 -0500
@@ -18,7 +18,7 @@
 Homepage: https://github.com/aseba-community/aseba
 
 Package: aseba
-Architecture: any-amd64 any-i386 arm64 mips64el mipsel riscv64
+Architecture: any-amd64 any-i386 arm64 mips64el mipsel riscv64 s390x ppc64el
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Suggests: aseba-plugin-blockly
 Description: Event-based framework for distributed mobile robots control

Bug#1030829: mmc-utils: FTBFS on ppc64el with error: ‘cnt’ may be used uninitialized

[Nick Rosbrook]

Package: mmc-utils
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear Maintainer,

In Ubuntu, mcc-utils FTBFS[1] on ppc64el with the following:

 In file included from /usr/include/endian.h:35,
  from /usr/include/powerpc64le-linux-gnu/sys/types.h:176,
  from /usr/include/stdlib.h:395,
  from mmc_cmds.c:21:
 In function ‘__bswap_32’,
 inlined from ‘do_rpmb_write_block’ at mmc_cmds.c:2462:27:
 /usr/include/powerpc64le-linux-gnu/bits/byteswap.h:52:10: error: ‘cnt’ may be 
used uninitialized [-Werror=maybe-uninitialized]
52 |   return __builtin_bswap32 (__bsx);
   |  ^
 mmc_cmds.c: In function ‘do_rpmb_write_block’:
 mmc_cmds.c:2439:22: note: ‘cnt’ was declared here
  2439 | unsigned int cnt;
   |  ^~~
 cc1: all warnings being treated as errors
 make[1]: *** [Makefile:36: mmc_cmds.o] Error 1
 make[1]: Leaving directory '/<>'
 dh_auto_build: error: make -j4 "INSTALL=install --strip-program=true" returned 
exit code 2
 make: *** [debian/rules:8: binary-arch] Error 25
 dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2
 


This was already fixed upstream[2]. We applied the patch in Ubuntu to fix
the build on ppc64el.

Thanks,
Nick

[1] 
https://launchpadlibrarian.net/648312622/buildlog_ubuntu-lunar-ppc64el.mmc-utils_0+git20220624.d7b343fd-1_BUILDING.txt.gz
[2] 
https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git/commit/?id=5086e7c0de4d0094f8674368a88d931b27589d53
diff -Nru 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
--- 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
 1969-12-31 19:00:00.0 -0500
+++ 
mmc-utils-0+git20220624.d7b343fd/debian/patches/0003-fix-warning-on-uninitialized-cnt.patch
 2023-02-07 15:14:11.0 -0500
@@ -0,0 +1,54 @@
+Description: mmc-utils: fix warning on uninitialized 'cnt'
+Origin: 
https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git/commit/?id=5086e7c0de4d0094f8674368a88d931b27589d53
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/mmc-utils/+bug/2006505
+Last-Update: 2023-02-07
+---
+From 5086e7c0de4d0094f8674368a88d931b27589d53 Mon Sep 17 00:00:00 2001
+From: Giulio Benetti 
+Date: Sun, 18 Sep 2022 18:17:51 +0200
+Subject: mmc-utils: fix warning on uninitialized 'cnt'
+
+When building following warning shows up:
+```
+In function '__bswap_32',
+inlined from 'do_rpmb_write_block' at mmc_cmds.c:2293:27:
+/home/autobuild/autobuild/instance-15/output-1/host/aarch64-buildroot-linux-gnu/sysroot/usr/include/bits/byteswap.h:52:10:
 error: 'cnt' may be used uninitialized [-Werror=maybe-uninitialized]
+   52 |   return __builtin_bswap32 (__bsx);
+  |  ^
+mmc_cmds.c: In function 'do_rpmb_write_block':
+mmc_cmds.c:2270:22: note: 'cnt' was declared here
+2270 | unsigned int cnt;
+  |  ^~~
+cc1: all warnings being treated as errors
+```
+This is due to function rpmb_read_counter() that doesn't set its
+argument 'unsigned int *cnt' in all return points. So let's set
+*cnt to 0 in the return point that misses to initialize it.
+
+Signed-off-by: Giulio Benetti 
+Reviewed-by: Avri Altman 
+Link: 
https://lore.kernel.org/r/20220918161751.1132590-1-giulio.bene...@benettiengineering.com
+Signed-off-by: Ulf Hansson 
+---
+ mmc_cmds.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/mmc_cmds.c b/mmc_cmds.c
+index ef1d8c6..29abd1d 100644
+--- a/mmc_cmds.c
 b/mmc_cmds.c
+@@ -2238,8 +2238,10 @@ int rpmb_read_counter(int dev_fd, unsigned int *cnt)
+   }
+ 
+   /* Check RPMB response */
+-  if (frame_out.result != 0)
++  if (frame_out.result != 0) {
++  *cnt = 0;
+   return be16toh(frame_out.result);
++  }
+ 
+   *cnt = be32toh(frame_out.write_counter);
+ 
+-- 
+cgit 
+
diff -Nru mmc-utils-0+git20220624.d7b343fd/debian/patches/series 
mmc-utils-0+git20220624.d7b343fd/debian/patches/series
--- mmc-utils-0+git20220624.d7b343fd/debian/patches/series  2022-08-04 
02:07:11.0 -0400
+++ mmc-utils-0+git20220624.d7b343fd/debian/patches/series  2023-02-07 
15:09:50.0 -0500
@@ -1,2 +1,3 @@
 0001-Fix-typo.patch
 0002-man-mmc.1-Fix-warning-macro-not-defined.patch
+0003-fix-warning-on-uninitialized-cnt.patch

Bug#1026600: firmware-microbit-micropython: diff for NMU version 1.0.1-3.1

[Nick Morrott]

On Tue, 7 Feb 2023 at 09:01, Adrian Bunk  wrote:
>
> On Tue, Feb 07, 2023 at 01:23:28AM +, Nick Morrott wrote:
> >...
> > I'm happy for the NMU to stay in DELAYED/1 and will have a look at
> > getting the new upstream packaged over the next days.
>
> that sounds good, but please wait until my NMU is in testing before
> making further uploads - if the package misses the deadline on the 12th
> it will not be in bookworm.

Absolutely.

Thank you again,
Nick

Bug#1026600: firmware-microbit-micropython: diff for NMU version 1.0.1-3.1

[Nick Morrott]

On Mon, 6 Feb 2023 at 23:33, Adrian Bunk  wrote:
>
> Control: tags 1026600 + patch
> Control: tags 1026600 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for firmware-microbit-micropython (versioned as 
> 1.0.1-3.1)
> and uploaded it to DELAYED/1. Please feel free to tell me if I should cancel 
> it.

Dear Adrian,

Thank you so much for preparing a patch and NMU to fix this issue. I
hadn't yet realised the fix would be quite so straightforward.

I'm happy for the NMU to stay in DELAYED/1 and will have a look at
getting the new upstream packaged over the next days.

Thanks,
Nick

Bug#1018106: sshd: pam_env(sshd:session): deprecated reading of user environment enabled

[nick black]

the cause of this output is the following line in /etc/pam.d/sshd:

  # In Debian 4.0 (etch), locale-related environment variables were moved to
  # /etc/default/locale, so read that as well.
  sessionrequired pam_env.so user_readenv=1 envfile=/etc/default/locale

i'm guessing from the comment that user_readenv=1 is in place
primarily to allow overrides of the default locale? etch was
quite some time ago, possibly preceding support for SendEnv?
that seems sufficient workaround if user_readenv is deprecated,
but this is all speculative.

Bug#1028662: lvm2-udeb: /sbin/fsadm missing from Debian installer; breaks -r with lvreduce/lvextend

[Nick Morrott]

Package: lvm2
Version: 2.03.16-2
Severity: normal
Tags: d-i patch

Dear Maintainer,

Whilst attempting to resize some LVM on LUKS partitions using
lvreduce/lvextend from the current Debian 11 installer in rescue mode,
I received the following error when using the `-r` option to resize the
underlying filesystem:

# lvreduce -L -10G -r -v /dev/foo/home
Finding volume group foo
Executing: fsadm check /dev/foo/home (null)
  fsadm: execlp failed: No such file or directory

The same error was received when running lvextend to grow LVs into the
freed space.

lvresize, lvreduce, and lvextend all support the `-r` option to resize
the underlying filesystem when resizing the logical volume. With fsadm
missing from the Debian installer, this will fail.

Merge request here: https://salsa.debian.org/lvm-team/lvm2/-/merge_requests/5

Thanks!

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

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE

Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lvm2 depends on:
ii  dmeventd   2:1.02.185-2
ii  dmsetup2:1.02.185-2
ii  libaio10.3.113-3
ii  libblkid1  2.38.1-4
ii  libc6  2.36-8
ii  libdevmapper-event1.02.1   2:1.02.185-2
ii  libedit2   3.1-20221030-2
ii  libselinux13.4-1+b4
ii  libsystemd0252.4-1
ii  libudev1   252.4-1
ii  lsb-base   11.5
ii  sysvinit-utils [lsb-base]  3.06-2

Versions of packages lvm2 recommends:
pn  thin-provisioning-tools  

lvm2 suggests no packages.

-- no debconf information

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

* Bastian Germann  [230113 18:05]:
> Am 13.01.23 um 03:40 schrieb Nick Hastings:
> > This debian/copyright file was originally produced by decopy and I
> > adjusted it wherever I found problems. I hesitate to change things that
> > I do not know to be wrong, at the risk of introducing errors simply to
> > reduce the number of lines in the file.
> 
> If you want this to be sponsored by me, please do so.

I spent a couple of hours grinding through the LGPL-2.1 section of
lib/libc/include and was able reduce the copyright file by about 760
lines. I was also able to save a few lines from the APSL-2 an GPL-2
sections.

> I will not review a non-reviewable copyright file.

I'm not clear on what constitutes a reviewable vs non-reviewable
copyright file. If there are other specific parts of the copyright file
that you think need more work please let me know.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

* Bastian Germann  [230104 02:20]:
> Control: tags -1 moreinfo
> 
> Am 15.12.22 um 06:40 schrieb Nick Hastings:
> > > d/copyright
> > > ===
> > > Please use more wildcards so you do not have to list so many files.
> > This is where it gets tricky for me. As I understand it the last match
> > in d/copyright file is the one that applies. So for example, the block
> > starting at line 253 specifies a LGPL-2.1+ license for a bunch of files
> > under lib/libc/include/. Lines 253-270 explicitly list header files
> > under lib/libc/include/aarch64-linux-gnu/bits/. So first thought is to
> > just list them all as a glob lib/libc/include/aarch64-linux-gnu/bits/*
> > However on closer inspection I see that there is a file in that
> > directory that is not listed. Specifically
> > lib/libc/include/aarch64-linux-gnu/bits/fcntl/endianness.h
> > Inspecting this file and the others in the directory I see that
> > explicitly listed files contain the LGPL-2.1+ text, but that
> > endianness.h contains no license text. Thus endianness.h is actually
> > Expat license and is covered in the block starting on line 10 "Files:
> > lib/*".
> > 
> > So if I change the explicit list of files under
> > lib/libc/include/aarch64-linux-gnu/bits/ to a glob, I'll need to and
> > anther block later to explicitly list endianness.h as Expat.
> 
> Yes, you would use a glob for the LGPL files and add another block 
> specifically
> for the Expat-licensed file after the LGPL block.

Understood. However I do not feel confident that I can correctly make
these changes by hand. The above is just one example where I found that
using a glob would require an additional section/exception. There are
likely many more.

This debian/copyright file was originally produced by decopy and I
adjusted it wherever I found problems. I hesitate to change things that
I do not know to be wrong, at the risk of introducing errors simply to
reduce the number of lines in the file.

Bug#1027976: ITP: libcpucycles -- Microlibrary for counting CPU cycles

[Nick Black (Public gmail account)]

Package: wnpp
Severity: wishlist
Owner: nick black  
X-Debbugs-Cc: debian-de...@lists.debian.org, dankamong...@gmail.com

* Package name: libcpucycles
  Version : 20230105
  Upstream Contact: Daniel J. Bernstein 
* URL : https://cpucycles.cr.yp.to/download.html
* License : Public domain
  Programming Lang: C
  Description : Microlibrary for counting CPU cycles

libcpucycles understands machine-level cycle counters for amd64 (both PMC and
TSC), arm32, arm64 (both PMC and VCT), mips64, ppc32, ppc64, riscv32, riscv64,
sparc64, and x86. libcpucycles also understands four OS-level mechanisms, which
give varying levels of accuracy: mach_absolute_time, perf_event,
CLOCK_MONOTONIC, and, as a fallback, microsecond-resolution gettimeofday.

When the program first calls cpucycles(), libcpucycles automatically benchmarks
the available mechanisms and selects the mechanism that does the best job.
Subsequent cpucycles() calls are thread-safe and very fast. An accompanying
cpucycles-info program prints a summary of cycle-counter accuracy.

Bug#1027820: nctetris man page: bad description in NAME section

[nick black]

https://github.com/dankamongmen/notcurses/issues/2693

thanks! i'll fix this upstream and report here.

Bug#1027035: libcpuset1: cpuset.3 references nonexistent bootcpuset.8, bootcpuset.conf.5

[Nick Black (Public gmail account)]

Package: libcpuset1
Version: 1.0-6+b1
Severity: minor
Tags: upstream
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

The cpuset.3 man page references bootcpuset.8 and bootcpuset.conf.5. Neither of
these man pages appear to exist in any package.


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

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

Versions of packages libcpuset1 depends on:
ii  libbitmask1  2.0-5
ii  libc62.36-7

libcpuset1 recommends no packages.

libcpuset1 suggests no packages.

-- no debconf information

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

Hi Bastian,

* Bastian Germann  [221219 06:22]:
> A quick note before I forget it: llvm-toolchain-13 is on its way out of 
> Debian.
> Can we make this package use the unversioned (default, currently v14)
> llvm packages or v15?

The cmake setup is quite specific about needing v13 so changing it to
greater than v13 would be significant work. Instead I changed it from
v13 to v14. I was able to get it to configure, but the build failed.

make[3]: Leaving directory '/build/zig-0.9.1/obj-x86_64-linux-gnu'
[ 82%] Built target embedded_softfloat
/build/zig-0.9.1/src/zig_llvm-ar.cpp:139:1: error: 'LLVM_ATTRIBUTE_NORETURN' 
does not name a type; did you mean 'LLVM_ATTRIBUTE_NODEBUG'?
  139 | LLVM_ATTRIBUTE_NORETURN static void badUsage(Twine Error) {
  | ^~~
  | LLVM_ATTRIBUTE_NODEBUG
/build/zig-0.9.1/src/zig_llvm-ar.cpp:146:1: error: 'LLVM_ATTRIBUTE_NORETURN' 
does not name a type; did you mean 'LLVM_ATTRIBUTE_NODEBUG'?
  146 | LLVM_ATTRIBUTE_NORETURN static void fail(Twine Error) {
  | ^~~
  | LLVM_ATTRIBUTE_NODEBUG

I changed these LLVM_ATTRIBUTE_NORETURN to "[[ noreturn ]]" and then the
build failed soon after at:

make[3]: Leaving directory '/build/zig-0.9.1/obj-x86_64-linux-gnu'
[ 82%] Built target embedded_softfloat
/build/zig-0.9.1/src/zig_clang.cpp: In function 'void 
ZigClang_detect_enum_TypeClass(clang::Type::TypeClass)':
/build/zig-0.9.1/src/zig_clang.cpp:297:27: error: 'DependentExtInt' is not a 
member of 'clang::Type'
  297 | case clang::Type::DependentExtInt:
  |   ^~~
/build/zig-0.9.1/src/zig_clang.cpp:318:27: error: 'ExtInt' is not a member of 
'clang::Type'
  318 | case clang::Type::ExtInt:
  |   ^~


So I think the short answer is: no, we can't use LLVM 14 or 15. I guess
it may be possible by patching the source but if that level of effort is
to be spent I think would be better spending it on getting Zig 0.10.0
(which depends on LLVM 15) to build. See
https://github.com/ziglang/zig/issues/13915

Cheers,

Nick.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

Hi,

thought it may be a little while until I could dig into this but
actually found the time today. So here's another quick update.

* Nick Hastings  [221216 13:15]:
> Hi,
>
> quick update.
>
> * Nick Hastings  [221215 14:40]:
>
> > * Bastian Germann  [221215 08:57]:
> >
> > > Your package fails to build from scratch on amd64 with a test fail 
> > > (maybecaused by wrong pwd?):

Yes, turns out to be wrong pwd.



> > I don't know why that is. It works for me on amd64 on unstable
> > (bullseye with backports). I do recall that someone on #mentors had
> > issues building it using sbuild at some point. But at least 3 or 4
> > others did not: success was reported with both pbuilder and sbuild.
>
> I updated my unstable chroot and now build the fails in this way for me
> too. I will investigate.

I don't actually understand why this ever worked. As I now understand it
dh_auto_test is run before dh_auto_install so I had no reason to expect
that the binary would already be in debian/zig/usr/bin/zig. Updating
this to the build time path fixed this (thanks to pabs and mjt in
#debian-mentors).  Now all but one of the test suites completes without
error. An updated d/rules skips that test suite for now.

I was able to build the package on x86_64 unstable with pbuilder.

New package uploaded to both mentors and salsa.

Cheers,

Nick.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

Hi,

quick update.

* Nick Hastings  [221215 14:40]:

> * Bastian Germann  [221215 08:57]:
>
> > Your package fails to build from scratch on amd64 with a test fail 
> > (maybecaused by wrong pwd?):
> >
> > [100%] Built target zig
> > make[2]: Leaving directory '/home/bage/zig-0.9.1/obj-x86_64-linux-gnu'
> > /usr/bin/cmake -E cmake_progress_start 
> > /home/bage/zig-0.9.1/obj-x86_64-linux-gnu/CMakeFiles 0
> > make[1]: Leaving directory '/home/bage/zig-0.9.1/obj-x86_64-linux-gnu'
> >debian/rules override_dh_auto_test
> > make[1]: Entering directory '/home/bage/zig-0.9.1'
> > ./debian/zig/usr/bin/zig build test-fmt || exit 1; ./debian/zig/usr/bin/zig
> > build test-behavior || exit 1; ./debian/zig/usr/bin/zig build
> > test-compiler-rt || exit 1; ./debian/zig/usr/bin/zig build test-minilibc ||
> > exit 1; ./debian/zig/usr/bin/zig build test-compare-output || exit 1;
> > ./debian/zig/usr/bin/zig build test-standalone || exit 1;
> > ./debian/zig/usr/bin/zig build test-stack-traces || exit 1;
> > ./debian/zig/usr/bin/zig build test-cli || exit 1; ./debian/zig/usr/bin/zig
> > build test-asm-link || exit 1; ./debian/zig/usr/bin/zig build
> > test-runtime-safety || exit 1; ./debian/zig/usr/bin/zig build
> > test-translate-c || exit 1; ./debian/zig/usr/bin/zig build
> > test-run-translated-c || exit 1; ./debian/zig/usr/bin/zig build test-std ||
> > exit 1;
> > /bin/sh: 1: ./debian/zig/usr/bin/zig: not found
> > make[1]: *** [debian/rules:16: override_dh_auto_test] Error 1
> > make[1]: Leaving directory '/home/bage/zig-0.9.1'
> > make: *** [debian/rules:8: binary] Error 2
> 
> I don't know why that is. It works for me on amd64 on unstable
> (bullseye with backports). I do recall that someone on #mentors had
> issues building it using sbuild at some point. But at least 3 or 4
> others did not: success was reported with both pbuilder and sbuild.

I updated my unstable chroot and now build the fails in this way for me
too. I will investigate.

Cheers,

Nick.

Bug#1012286: RFS: zig/0.9.1-1 [ITP] -- Programming language

[Nick Hastings]

ndianness.h?

This is the sort of thing that I've been battling with the whole time
with that d/copyright.

> Your comment:
> "COPYRIGHT file has a lont list of "Authors/contributors include". Should 
> these be added here in some way?"
> You should first think if the whole musl dir can be replaced with the
> musl-dev package. If so, you can repack the tarball,

I comment on this further down.

> else you stick to the Copyright line, as required by the Expat license.
> The long list of authors does not claim they are copyright holders but
> "Authors/contributors".

Ok thanks, that clarifies that for me. I removed that comment.

> The repackaging comment does not only go for musl but also the other
> 3rd party components.

Striping out the bundled source would change Zig drastically and would
make both producing and maintaining this package much harder. I think
that the bundled source is part of what makes Zig Zig.

If you have not seen it already (and for the sake of others) please see
what Andrew Kelly of wrote in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995670

> BSD-4-clause is not correctly represented. You replaced the 3rd clause's
> acknowlegement with "This product includes software developed by this
> project." However, this mentions the University of California in the
> referencing files.
> For BSD-4-clause by UC California specifically you can just remove the whole
> 3rd clause because the Regents allowed to do so once upon a time. If there
> is a file with different acknowlegement please keep it as-is.

Checking my copyright file it seems that all files that are licensed
BSD-4-clause have "The Regents of the University of California" as one
of the copyright holders. Checking the files themselves I see that for
most files third clause does indeed specify University of California,
Berkeley and its contributors. However there are a handful of others
that specify different people in the clause 3 and have correspondingly
modified clause 4. So I guess I need to grind through and separate them
all?

> CC0 is in Debian's common-licenses. Please replace the whole text with
> a reference like in the GPL variants.

Ok. I haven't been able find a definitive short version of the CC0
license. There seem to be some variations checking
/usr/share/doc/*/copyright on my system. Can you suggest what I should
use for this?

> BSD-2-clause-NetBSD is not the right license. You copied the ISC from
> lib/libc/mingw/misc/getopt.c, not the BSD-2-clause-NetBSD.

Thanks. Fixed.

> There is more to come; I have only reviewed the overall appearance of
> the file.

Understood.

> What is the debian.decopy file about?

That is the output produced by decopy. It should not have been included
in the package.

> d/patches
> ==
> Please do not include if you do not have at least one patch.

Think that's an artefact of earlier iterations when the package did have
patches. Removed.

I committed and pushed the updates to
https://github.com/NickHastings/zig-debian
Will move it to salsa when/if my account application is approved.

Should I also reupload to mentors?

Thanks for your time and efforts reviewing this package. You've found
problems that I had overlooked and explained things that I didn't
previously understand.

Cheers,

Nick.

Bug#1026094: prometheus-ipmi-exporter: autopkgtest/build fails due to API change in prometheus exporter-toolkit

[Nick Rosbrook]

Package: prometheus-ipmi-exporter
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear Maintainer,

Recent API changes in the github.com/prometheus/exporter-toolkit/web
package, which are included in golang-github-prometheus-exporter-toolkit
0.8.2-1, cause the autopkgtest (and re-build) to fail.

This can be fixed by an upstream commit that adapts to the new API.

Thanks,
Nick
diff -Nru 
prometheus-ipmi-exporter-1.6.1/debian/patches/02-fix-build-with-new-exporter-toolkit.patch
 
prometheus-ipmi-exporter-1.6.1/debian/patches/02-fix-build-with-new-exporter-toolkit.patch
--- 
prometheus-ipmi-exporter-1.6.1/debian/patches/02-fix-build-with-new-exporter-toolkit.patch
  1969-12-31 19:00:00.0 -0500
+++ 
prometheus-ipmi-exporter-1.6.1/debian/patches/02-fix-build-with-new-exporter-toolkit.patch
  2022-12-13 15:51:36.0 -0500
@@ -0,0 +1,33 @@
+Description: Fix build with golang-github-prometheus-exporter-toolkit 0.8.2
+Origin: upstream, 
https://github.com/prometheus-community/ipmi_exporter/commit/e8989cfdf79bebb2e3d84e43f65a7fc027ee7bba.patch
+Bug-Ubuntu: https://launchpad.net/bugs/1999574
+Last-Update: 2022-12-13
+---
+--- a/main.go
 b/main.go
+@@ -41,11 +41,7 @@
+   "freeipmi.path",
+   "Path to FreeIPMI executables.",
+   ).Default("/usr/sbin").String()
+-  listenAddress = kingpin.Flag(
+-  "web.listen-address",
+-  "Address to listen on for web interface and telemetry.",
+-  ).Default(":9290").String()
+-  webConfig = webflag.AddFlags(kingpin.CommandLine)
++  webConfig = webflag.AddFlags(kingpin.CommandLine, ":9290")
+ 
+   sc = {
+   C: {},
+@@ -169,10 +165,8 @@
+ `))
+   })
+ 
+-  level.Info(logger).Log("msg", "Listening on", "address", *listenAddress)
+-
+-  srv := {Addr: *listenAddress}
+-  if err := web.ListenAndServe(srv, *webConfig, logger); err != nil {
++  srv := {}
++  if err := web.ListenAndServe(srv, webConfig, logger); err != nil {
+   level.Error(logger).Log("msg", "HTTP listener stopped", 
"error", err)
+   os.Exit(1)
+   }
diff -Nru prometheus-ipmi-exporter-1.6.1/debian/patches/series 
prometheus-ipmi-exporter-1.6.1/debian/patches/series
--- prometheus-ipmi-exporter-1.6.1/debian/patches/series2022-06-22 
07:19:56.0 -0400
+++ prometheus-ipmi-exporter-1.6.1/debian/patches/series2022-12-13 
15:23:10.0 -0500
@@ -1 +1,2 @@
 01-debian-defaults.patch
+02-fix-build-with-new-exporter-toolkit.patch

Bug#887035: cron: Logging to STDOUT when in foreground mode

[Nick Reilingh]

On Thu, 28 Jan 2021 17:38:00 + prog+debian-bug-887...@posteo.org wrote:
> For the use case of containerized environments BusyBox already provides
> a cron applet with custom logging capabilities:
> 
> busybox crond -f -L /dev/stdout

I am working in a debian-based container and the busybox available via apt-get 
appears not to have crond available.

Dockerfile:
FROM debian

RUN apt-get update && apt-get install -y busybox

CMD ["bash"]

$ docker build -t test .
$ docker run --rm -it test
# busybox crond -f
crond: applet not found

Can you clarify how one can use busybox’s crond in a containerized environment?

Thank you,
Nick R.

Bug#995670: Updated Zig package uploaded to mentors.d.n

[Nick Hastings]

Hi,

I did some more work on the copyright file, I think it may be ready to
be reviewed. The package is now again at
https://mentors.debian.net/package/zig/

I looked at updating to Zig 0.10.0 (released Oct 31). However, there are
significant changes to the build between 0.9.1 and 0.10.0.  Release
notes are at https://ziglang.org/download/0.10.0/release-notes.html

Zig 0.9.1 simply built a Zig compiler using the system provided compiler
and libraries. This new release attempts to do a self hosted build.
Details are at
https://ziglang.org/download/0.10.0/release-notes.html#Self-Hosted-Compiler

There are three stages to the 0.10.0 build. As I understand them, they
are:

1. Build a zig compiler using system compilers and libraries (similar to
   0.9.1).

2. Use the zig compiler from stage 1 to build a zig compiler from zig
   bundled libraries.

3. Repeat stage 2 using the zig compiler in produced in stage 2.

Attempting this on Debian unstable (and also on bullseye with backported
llvm-15) resulted in a failure at stage 2. It seems the build was not
able to find a particular header file. There may be other problems too,
but I did not investigate further.

The release notes actually suggest waiting until Zig 0.10.1 or Zig
0.11.0 before upgrading from 0.9.1. It seems there will be even larger
changes to the build system for Zig 0.11.0 so I'm not sure how much
effort upstream will be put into fixing build related issues in 0.10.0.

So, at this point I think it may be best to wait for the next release
before attempting to update this package.

Regards,

Nick.

Bug#995670: Zig package status

[Nick Hastings]

Hi Bastian,

* Bastian Germann  [221204 09:02]:
> 
> With the copyright in place I will sponsor it. Please notify me when you
> think you have represented the applicable licenses completely and I will
> review it.

Many thanks for stepping forward for this.

I started looking at the copyright again and have some questions. I'm
not sure if the discussion should continue here in this bug report or if
it is better to take it "offline" to be just with you as the potential
sponsor.

Thanks,

Nick.

Bug#995670: Zig package status

[Nick Hastings]

Hi Bastian,

* Bastian Germann  [221203 02:45]:
> The package got removed from mentors.

Yes, no one sponsored it.

> Nick, do you still have time to work on it? If not please make this a
> RFP.

I think I have time. Zig 0.10.0 was just released and I'm updating the
package for it. Hope to upload to mentors soon.

I think the biggest problem is still the copyright file. I tried using
scancode but it seems that d/copyright output option is still a work in
progress.

Without a sponsor the package can't enter Debian so I don't want to
spend the many tedious hours required to manually produce a correct
copyright file if it will not be used. If/when there is indication that
someone may sponsor this package I can look to put more time/effort into
the d/copyright.

Regards,

Nick.

Bug#1024863: RFP: amdgpu-opencl -- Open-source OpenCL support for AMD GPUs

[Nick Jacobs]

Package: wnpp
X-Debbugs-Cc: halbtaxabo-...@yahoo.com
Severity: wishlist

* Package name    : amdgpu-open
  Version :
  Upstream Author : 
* URL : https://gpuopen.com
* License : MIT
  Programming Lang:
  Description : Open-source OpenCL support for AMD GPUs

There is a packaged graphics device driver for AMD Radeon graphics
cards, but there doesn't seem to be OpenCL support.
A typical use case would be using
the graphics card to speed up neural-network computation.
There is open-source software developed by AMD but it isn't
packaged.

Bug#1024623: tried Fedora 37 live

[Nick Sh]

I have booted with Fedora 37 usb live stick (it has kernel 6.0), suspended
with sudo systemctl suspend (i wasn't able to easily find how to suspend
from gnome ui...), then pressed a key after a few seconds - the system has
woken up, but display was still off. so the issue is even more grave on
fedora

Bug#1024624: linux-image-6.0.0-4-amd64: Lenovo E14 Gen 2 Intel freezes after waking up from suspend

[Nick Shaforostov]

Package: src:linux
Version: 6.0.8-1
Severity: important
Tags: upstream


It unfreezes after 8 seconds if spent 10 seconds in sleep state (I am sending 
this report immediately after trying this - i.e. without a powercycle)
It didn't unfreeze during 2 minutes after spending 1 minute in sleep state

Sleep type in BIOS is "windows and linux", (other alternative is Linux S3)

Works fine with 5.19; 6.1rc5 also has this regression; 6.0 works fine on my 
older lenovo e330;


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.0.0-4-amd64 
root=UUID=f119ee93-fcef-4430-b4d1-12bab74e7242 ro rootflags=subvol=@rootfs 
quiet zswap.enabled=1 zswap.max_pool_percent=25 zswap.zpool=z3fold 
mitigations=off

** Not tainted

** Kernel log:
[8.473109] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[8.473110] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[8.473111] snd_hda_codec_realtek ehdaudio0D0:mono: mono_out=0x0
[8.473112] snd_hda_codec_realtek ehdaudio0D0:inputs:
[8.473113] snd_hda_codec_realtek ehdaudio0D0:  Mic=0x19
[8.517955] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX 
overwritten
[8.517961] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX 
overwritten
[8.518056] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 
overwritten
[8.518059] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 
overwritten
[8.518062] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 
overwritten
[8.518065] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Codec Output Pin1 overwritten
[8.518067] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Codec 
Input Pin1 overwritten
[8.518071] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Analog Codec Playback overwritten
[8.518074] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Digital Codec Playback overwritten
[8.518078] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt 
Analog Codec Playback overwritten
[8.518082] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Analog Codec Capture overwritten
[8.518086] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Digital Codec Capture overwritten
[8.518089] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt 
Analog Codec Capture overwritten
[8.518096] skl_hda_dsp_generic skl_hda_dsp_generic: 
hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
[8.534436] input: sof-hda-dsp Mic as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input12
[8.534462] input: sof-hda-dsp Headphone as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input13
[8.534481] input: sof-hda-dsp HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input14
[8.534501] input: sof-hda-dsp HDMI/DP,pcm=4 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input15
[8.534520] input: sof-hda-dsp HDMI/DP,pcm=5 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input16
[8.541598] EXT4-fs (zram1): mounting ext2 file system using the ext4 
subsystem
[8.541743] EXT4-fs (zram1): mounted filesystem without journal. Quota mode: 
none.
[8.584273] audit: type=1400 audit(1669117980.412:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=648 
comm="apparmor_parser"
[8.584278] audit: type=1400 audit(1669117980.412:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=648 
comm="apparmor_parser"
[8.584280] audit: type=1400 audit(1669117980.412:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=648 
comm="apparmor_parser"
[8.584283] audit: type=1400 audit(1669117980.412:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=646 
comm="apparmor_parser"
[8.584284] audit: type=1400 audit(1669117980.412:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=650 comm="apparmor_parser"
[8.584643] audit: type=1400 audit(1669117980.412:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=652 comm="apparmor_parser"
[8.585046] audit: type=1400 audit(1669117980.412:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=647 
comm="apparmor_parser"
[8.585050] audit: type=1400 audit(1669117980.412:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=647 comm="apparmor_parser"
[

Bug#1024623: linux-image-6.0.0-4-amd64: Lenovo E14 Gen 2 Intel freezes after waking up from suspend

[Nick Shaforostov]

Package: src:linux
Version: 6.0.8-1
Severity: important
Tags: upstream


It unfreezes after 8 seconds if spent 10 seconds in sleep state (I am sending 
this report immediately after trying this - i.e. without a powercycle)
It didn't unfreeze during 2 minutes after spending 1 minute in sleep state

Sleep type in BIOS is "windows and linux", (other alternative is Linux S3)

Works fine with 5.19; 6.1rc5 also has this regression; 6.0 works fine on my 
older lenovo e330;


-- Package-specific info:
** Version:
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

** Command line:
BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.0.0-4-amd64 
root=UUID=f119ee93-fcef-4430-b4d1-12bab74e7242 ro rootflags=subvol=@rootfs 
quiet zswap.enabled=1 zswap.max_pool_percent=25 zswap.zpool=z3fold 
mitigations=off

** Not tainted

** Kernel log:
[8.473109] snd_hda_codec_realtek ehdaudio0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[8.473110] snd_hda_codec_realtek ehdaudio0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[8.473111] snd_hda_codec_realtek ehdaudio0D0:mono: mono_out=0x0
[8.473112] snd_hda_codec_realtek ehdaudio0D0:inputs:
[8.473113] snd_hda_codec_realtek ehdaudio0D0:  Mic=0x19
[8.517955] snd_hda_codec_realtek ehdaudio0D0: ASoC: sink widget AIF1TX 
overwritten
[8.517961] snd_hda_codec_realtek ehdaudio0D0: ASoC: source widget AIF1RX 
overwritten
[8.518056] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi3 
overwritten
[8.518059] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi2 
overwritten
[8.518062] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget hifi1 
overwritten
[8.518065] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Codec Output Pin1 overwritten
[8.518067] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Codec 
Input Pin1 overwritten
[8.518071] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Analog Codec Playback overwritten
[8.518074] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget 
Digital Codec Playback overwritten
[8.518078] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: sink widget Alt 
Analog Codec Playback overwritten
[8.518082] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Analog Codec Capture overwritten
[8.518086] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget 
Digital Codec Capture overwritten
[8.518089] skl_hda_dsp_generic skl_hda_dsp_generic: ASoC: source widget Alt 
Analog Codec Capture overwritten
[8.518096] skl_hda_dsp_generic skl_hda_dsp_generic: 
hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
[8.534436] input: sof-hda-dsp Mic as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input12
[8.534462] input: sof-hda-dsp Headphone as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input13
[8.534481] input: sof-hda-dsp HDMI/DP,pcm=3 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input14
[8.534501] input: sof-hda-dsp HDMI/DP,pcm=4 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input15
[8.534520] input: sof-hda-dsp HDMI/DP,pcm=5 as 
/devices/pci:00/:00:1f.3/skl_hda_dsp_generic/sound/card0/input16
[8.541598] EXT4-fs (zram1): mounting ext2 file system using the ext4 
subsystem
[8.541743] EXT4-fs (zram1): mounted filesystem without journal. Quota mode: 
none.
[8.584273] audit: type=1400 audit(1669117980.412:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=648 
comm="apparmor_parser"
[8.584278] audit: type=1400 audit(1669117980.412:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=648 
comm="apparmor_parser"
[8.584280] audit: type=1400 audit(1669117980.412:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=648 
comm="apparmor_parser"
[8.584283] audit: type=1400 audit(1669117980.412:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=646 
comm="apparmor_parser"
[8.584284] audit: type=1400 audit(1669117980.412:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=650 comm="apparmor_parser"
[8.584643] audit: type=1400 audit(1669117980.412:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" 
pid=652 comm="apparmor_parser"
[8.585046] audit: type=1400 audit(1669117980.412:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=647 
comm="apparmor_parser"
[8.585050] audit: type=1400 audit(1669117980.412:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=647 comm="apparmor_parser"
[

Bug#1024089: ITP: accel-config -- Utility for configuring the DSA subsystem for Linux

[nick black]

Colin Ian King left as an exercise for the reader:
> Package: wnpp
> Severity: wishlist
> Owner: Colin Ian King 
> X-Debbugs-Cc: debian-de...@lists.debian.org

Hey Colin! I'm hoping to work with the Intel folks on this, and
it seems you started the endeavor and guided it thus far. Can I
assist you in any way at the moment?

-- 
nick black -=- https://www.nick-black.com
to make an apple pie from scratch,
you need first invent a universe.


signature.asc
Description: PGP signature

Bug#1023667: xen-tools: xt-guess-suite-and-mirror cannot handle deb http://ports.ubuntu.com/ubuntu-ports

[Nick Rosbrook]

Source: xen-tools
Version: 4.9.1-1
Severity: normal

Dear Maintainer,

The xt-guess-suite-and-mirror tools is not able to handle sources.list
entries like this:

  deb http://ports.ubuntu.com/ubuntu-ports kinetic main restricted

This comes from a default installation of Ubuntu Kinetic on arm64
(raspberry pi). Specifically, the tool is not able to handle the
ubuntu-ports portion of the entry.

This is what the tool reports:

  pi@ubuntu:~$ xt-guess-suite-and-mirror --mirror
  Couldn't find a useful entry in the sources.list files of the Dom0. Tried:
/etc/apt/sources.list
  pi@ubuntu:~$ xt-guess-suite-and-mirror --suite
  Couldn't find a useful entry in the sources.list files of the Dom0. Tried:
/etc/apt/sources.list

I would expect it to correctly report 'http://ports.ubuntu.com/ubuntu-ports'
and 'kinetic' instead. 

Thanks,
Nick

Bug#1021750: general: the nodelalloc mount option should be used by default for ext4 in /etc/fstab

[nick black]

i'm pretty sure that the corruption issues leading to the
nodelalloc option were considered largely remedied by the
"auto_da_alloc" capability introduced (and enabled by default)
in 2.6.30? how would nodelalloc equal the performance of
delalloc? nodelalloc was all about reliability for programs that
weren't conforming to certain POSIX semantics, as i recall.

Bug#1021639: wayfire: symbol lookup error: wayfire: undefined symbol: wlr_backend_get_renderer

[Nick Black (Public gmail account)]

Version: 0.7.4-2
close 1021639


i'm stupid. /usr/local strikes again. sorry!


signature.asc
Description: PGP signature

Bug#1021639: wayfire: symbol lookup error: wayfire: undefined symbol: wlr_backend_get_renderer

[Nick Black (Public gmail account)]

Package: wayfire
Version: 0.7.4-2
Severity: important
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I installed wayfire 0.7.4-2, and attempted to run wayfire. It refused to start,
due to an undefined symbol. Prior to this, it printed several diagnostics, so
I'm guessing this symbol is used by some plugin or dynlib.

[schwarzgerat](0) $ wayfire
II 11-10-22 21:58:23.668 - [src/main.cpp:288] Starting wayfire version
0.8.0-bbe63a72 (Dec  1 2021, branch 'master')
II 11-10-22 21:58:23.669 - [backend/x11/backend.c:397] Creating X11 backend
II 11-10-22 21:58:23.669 - [backend/x11/backend.c:480] X11 does not support
shared pixmaps
EE 11-10-22 21:58:23.669 - [backend/x11/backend.c:609] Failed to query DRI3 DRM
FD
wayfire: symbol lookup error: wayfire: undefined symbol:
wlr_backend_get_renderer

Also, is the version number correct? The diagnostic indicates 0.8.0, but the
package is 0.7.4.


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

Kernel: Linux 5.19.14nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wayfire depends on:
ii  libc62.35-3
ii  libcairo21.16.0-6
ii  libgcc-s112.2.0-5
ii  libgles2 1.5.0-1
ii  libglib2.0-0 2.74.0-2
ii  libinput10   1.21.0-1
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpixman-1-00.40.0-1
ii  libpng16-16  1.6.38-2
ii  libstdc++6   12.2.0-5
ii  libwayland-server0   1.21.0-1
ii  libwf-config10.7.1-2
ii  libwf-utils0 0.7.4-2
ii  libwlroots10 0.15.1-3
ii  libxcb1  1.15-1
ii  libxkbcommon01.4.1-1

wayfire recommends no packages.

wayfire suggests no packages.

-- no debconf information

Bug#1021049: fritzing: new version 0.9.10 is available

[Nick Black (Public gmail account)]

Package: fritzing
Version: 0.9.6+dfsg-2+b1
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

Version 0.9.10 of fritzing was released 2022-05-22. It includes a beta
simulator, a powerful new addition to fritzing. It would be great to have it in
Debian. If you need assistance updating, I'm happy to help out; if you were
unaware of the new version, just making you aware =].

Thanks for your efforts.


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

Kernel: Linux 5.19.11nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fritzing depends on:
ii  fritzing-data0.9.6+dfsg-2
ii  fritzing-parts   0.9.6~unreleased-1
ii  libc62.35-1
ii  libgcc-s112.2.0-3
ii  libgit2-1.3  1.3.0+dfsg.1-3
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5gui5   5.15.4+dfsg-5
ii  libqt5network5   5.15.4+dfsg-5
ii  libqt5printsupport5  5.15.4+dfsg-5
ii  libqt5serialport55.15.4-2
ii  libqt5sql5   5.15.4+dfsg-5
ii  libqt5sql5-sqlite5.15.4+dfsg-5
ii  libqt5svg5   5.15.4-2
ii  libqt5widgets5   5.15.4+dfsg-5
ii  libqt5xml5   5.15.4+dfsg-5
ii  libstdc++6   12.2.0-3
ii  zlib1g   1:1.2.11.dfsg-4.1

fritzing recommends no packages.

fritzing suggests no packages.

-- no debconf information

Bug#1020871: firefox-esr: Opening a URL in firefox running under sudo

[Nick]

Package: firefox-esr
Version: 102.3.0esr-1~deb11u1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Upgrading to 102.3.0esr-1~deb11u1

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Attempted to open a link by clicking on it in a terminal emulator.

   * What was the outcome of this action?

A dialog appeared saying "Firefox is already running, but is not
responding. To use Firefox, you must first close the existing Firefox
process, restart your device, or use a different profile."

   * What outcome did you expect instead?

That firefox would open the link, as it would do until recently.
There's no problem if I run firefox in my own account.  The trouble
appears to be that firefox no longer responds to such requests while
running as another user under sudo, which I've been doing for the last
decade or so for extra safety,
.

Is there a way to make it work again, please, pretty please?

-- Package-specific info:

-- Extensions information
Name: Add-ons Search Detection
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Amazon.co.uk
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: eBay
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Alpenglow theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Picture-In-Picture
Location: /usr/lib/firefox-esr/browser/features/pictureinpict...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: System theme — auto theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Web Compatibility Interventions
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled


-- Addons package information
ii  firefox-esr102.3.0esr-1~deb11u1 amd64Mozilla Firefox web 
browser - Extended Support Release (ESR)

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

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

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

Bug#1020676: prometheus-mqtt-exporter: new version available (0.1.6)

[Nick Black (Public gmail account)]

Package: prometheus-mqtt-exporter
Version: 0.1.4-2+b9
Severity: normal
X-Debbugs-Cc: dankamong...@gmail.com

Dear Maintainer,

I was attempting to determine why promtheus-mqtt-exporter as packaged in Debian
wasn't honoring the MQTT2PROM_MQTT_USER and _PASSWORD variables defined in a
systemd override file. It appears that the version being shipped is 0.1.4.
Version 0.1.6 has been available from upstream for some time now (since
January), and adds support for these variables. It would be good to upgrade, I
think.

I'm also wondering whether this fixes a problem I was seeing where metrics were
being dropped. I'm going to grab 0.1.6, built it myself, and see what happens.


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

Kernel: Linux 5.19.10nlb2 (SMP w/64 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages prometheus-mqtt-exporter depends on:
ii  init-system-helpers  1.65.2
ii  libc62.35-1
ii  systemd-sysv 251.4-3

prometheus-mqtt-exporter recommends no packages.

prometheus-mqtt-exporter suggests no packages.

-- Configuration Files:
/etc/prometheus/mqtt-exporter.yaml changed:
mqtt:
  # The MQTT broker to connect to
  server: tcp://localhost:1883
  # user and password are specified in systemd dropin
  topic_path: mora3
  # Optional: Regular expression to extract the device ID from the topic path. 
The default regular expression, assumes
  # that the last "element" of the topic_path is the device id.
  # The regular expression must contain a named capture group with the name 
deviceid
  # For example the expression for tasamota based sensors is 
"tele/(?P.*)/.*"
  # device_id_regex: "(.*/)?(?P.*)"
  # The MQTT QoS level
  qos: 0
cache:
  # Timeout. Each received metric will be presented for this time if no update 
is send via MQTT.
  # Set the timeout to -1 to disable the deletion of metrics from the cache. 
The exporter presents the ingest timestamp
  # to prometheus.
  timeout: 60m
metrics:
  -
prom_name: mora3coolant
mqtt_name: therm
help: Coolant temperature as measured at MO-RA3
type: gauge
const_labels:
  sensor_type: k10
  -
prom_name: mora3rpm
mqtt_name: rpm
help: RPM measurements from MO-RA3 fans
type: gauge
const_labels:
  sensor_type: arcticp14


-- no debconf information

Bug#1020528: dh-python: attempting to diff static library files raises UnicodeDecodeError

[Nick Rosbrook]

Package: dh-python
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

In verbose mode, if files differ in share_files(), dhpython will try to
show a diff of the files. When these files are static libraries, this
raises a UnicodeDecodeError. For example, from a recent numpy build on
Ubuntu kinetic[1].

In Ubuntu, the attached patch was applied to avoid diffing .a files,
just as is currently done for .so files:

  * dhpython/fs.py: do not try to diff static libraries in verbose mode (LP: 
#1990562)

Thanks,
Nick

[1] 
https://launchpadlibrarian.net/624822201/buildlog_ubuntu-kinetic-arm64.numpy_1%3A1.21.5-1build2_BUILDING.txt.gz
diff -Nru dh-python-5.20220819/dhpython/fs.py 
dh-python-5.20220819ubuntu1/dhpython/fs.py
--- dh-python-5.20220819/dhpython/fs.py 2022-08-19 16:34:55.0 -0400
+++ dh-python-5.20220819ubuntu1/dhpython/fs.py  2022-09-22 10:38:23.0 
-0400
@@ -144,7 +144,7 @@
 else:
 # The files differed so we cannot collapse them.
 log.warn('Paths differ: %s and %s', fpath1, fpath2)
-if options.verbose and not i.endswith('.so'):
+if options.verbose and not i.endswith(('.so','.a')):
 with open(fpath1) as fp1:
 fromlines = fp1.readlines()
 with open(fpath2) as fp2:

Bug#1019570: librust-cbindgen-dev has been removed from Bullseye

[Nick Brown]

Package: rust-cbindgen
Version:  0.23.0-1~deb11u1
Severity: important

 The NMU of 0.23.0-1~deb11u1 replaced 0.20.0-1~deb11u1 in Debian Bullseye
and in doing so removed librust-cbindgen-dev and librust-cbindgen+clap-dev

https://tracker.debian.org/news/1345484/accepted-rust-cbindgen-0230-1deb11u1-source-into-proposed-updates-stable-new-proposed-updates/

https://sources.debian.org/src/rust-cbindgen/0.23.0-1~deb11u1/debian/control/#L35

This means that any debian packages (or 3rd party debian packaged) that were 
built using librust-cbindgen-dev will no longer do so.

I had 3rd party debian packages that were being built against 
ibrust-cbindgen-dev that no longer builds, and only work around is now vendor 
ibrust-cbindgen-dev.

Why was ibrust-cbindgen-dev removed? Can it be restored?

Bug#1019250: lttng-modules-dkms: Build of lttng-probe-compaction.ko failed for: 5.18.0-4-arm64 (aarch64)

[Nick Gasson]

Package: lttng-modules-dkms
Version: 2.13.4-1
Severity: important

Dear Maintainer,

I get the following error when install lttng-modules-dkms:

Setting up lttng-modules-dkms (2.13.4-1) ...
Loading new lttng-modules-2.13.4 DKMS files...
Building for 5.18.0-4-arm64
Building initial module for 5.18.0-4-arm64
Error!  Build of lttng-probe-compaction.ko failed for: 5.18.0-4-arm64 (aarch64)
Make sure the name of the generated module is correct and at the root of the
build directory, or consult make.log in the build directory
/var/lib/dkms/lttng-modules/2.13.4/build for more information.
dpkg: error processing package lttng-modules-dkms (--configure):
 installed lttng-modules-dkms package post-installation script subprocess 
returned error exit status 7
Setting up libgcc-11-dev:arm64 (11.3.0-5) ...
Setting up gcc-11 (11.3.0-5) ...
Setting up linux-headers-5.18.0-4-arm64 (5.18.16-1) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 5.18.0-4-arm64:
Building module:
cleaning build area...
make -j64 KERNELRELEASE=5.18.0-4-arm64 -C /lib/modules/5.18.0-4-arm64/build 
M=/var/lib/dkms/lttng-modules/2.13.4/build modules CONFIG_LTTNG=m 
CONFIG_LTTNG_CLOCK_PLUGIN_TEST=m
Error!  Build of lttng-probe-compaction.ko failed for: 5.18.0-4-arm64 (aarch64)
Make sure the name of the generated module is correct and at the root of the
build directory, or consult make.log in the build directory
/var/lib/dkms/lttng-modules/2.13.4/build for more information.


The relevant part of make.log:

/var/lib/dkms/lttng-modules/2.13.4/build/src/probes/Kbuild:184: Files 
/usr/src/linux-headers-5.18.0-4-common/mm/internal.h not found. Probe 
"compaction" is disabled. Use full kernel source tree to enable it.


It seems that, starting from kernel 5.18, the compaction module depends
on a header file that is only available with the full kernel sources.
>From src/probes/Kbuild:

# A dependency on internal header 'mm/internal.h' was introduced in v5.18
compaction_dep = $(srctree)/mm/internal.h
compaction_dep_wildcard = $(wildcard $(compaction_dep))
compaction_dep_check = $(shell \
if [ \( $(VERSION) -ge 6 \
   -o \( $(VERSION) -eq 5 -a $(PATCHLEVEL) -ge 18 \) \) -a \
   -z "$(compaction_dep_wildcard)" ] ; then \
  echo "warn" ; \
else \
  echo "ok" ; \
fi ;)
ifeq ($(compaction_dep_check),ok)
  obj-$(CONFIG_LTTNG) += lttng-probe-compaction.o
else
  $(warning Files $(compaction_dep) not found. Probe "compaction" is disabled. 
Use full kernel source tree to enable it.)
endif # $(wildcard $(compaction_dep))


The "random" module also won't build with 5.18:

# Introduced in v3.6, remove in v5.18
random_dep = $(srctree)/include/trace/events/random.h
ifneq ($(wildcard $(random_dep)),)
  obj-$(CONFIG_LTTNG) += lttng-probe-random.o
endif


If I comment both these modules out of the DKMS config file it can
install OK.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (400, 'unstable')
Architecture: arm64 (aarch64)

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

Versions of packages lttng-modules-dkms depends on:
ii  dkms  3.0.3-4

Versions of packages lttng-modules-dkms recommends:
ii  lttng-tools  2.13.7-1+b1

lttng-modules-dkms suggests no packages.

-- no debconf information

Bug#1016330: generate-ninja: FTBFS: dwz: debian/generate-ninja/usr/bin/gn: Unknown debugging section .debug_addr

[Nick Rosbrook]

Package: generate-ninja
Followup-For: Bug #1016330
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, we fixed the FTBFS by forcing gn to build as DWARFv4 to
remain compatible with dh_dwz:

  * debian/rules: Set -gdwarf-4 in CXXFLAGS to remain compatible with dh_dwz
and fix FTBFS (LP: #1984224).

Thanks,
Nick
diff -Nru generate-ninja-0.0~git20220314.bd99dbf/debian/rules 
generate-ninja-0.0~git20220314.bd99dbf/debian/rules
--- generate-ninja-0.0~git20220314.bd99dbf/debian/rules 2022-03-21 
02:51:44.0 -0400
+++ generate-ninja-0.0~git20220314.bd99dbf/debian/rules 2022-08-10 
11:14:05.0 -0400
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 include /usr/share/dpkg/buildflags.mk
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
-CXXFLAGS += $(CPPFLAGS) -fPIE
+CXXFLAGS += $(CPPFLAGS) -fPIE -gdwarf-4
 LDFLAGS += -pie
 
 include /usr/share/dpkg/architecture.mk

Bug#1015381: deepin-album: ftbfs with LTO (link time optimization) enabled

[Nick Rosbrook]

Package: deepin-album
Followup-For: Bug #1015381
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Hi,

In Ubuntu, we disabled LTO to fix the build:

  * debian/rules: disable LTO to fix the build (LP: #1984124).

Thanks,
Nick
diff -Nru deepin-album-5.9.1+dfsg/debian/rules 
deepin-album-5.9.1+dfsg/debian/rules
--- deepin-album-5.9.1+dfsg/debian/rules2022-03-31 14:17:10.0 
-0400
+++ deepin-album-5.9.1+dfsg/debian/rules2022-08-09 12:24:42.0 
-0400
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 include /usr/share/dpkg/default.mk
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all,optimize=-lto
 export DEB_CXXFLAGS_MAINT_APPEND = -Wl,-z,now
 
 export QT_SELECT := 5

Bug#1017469: libxsmm: FTBFS with undefined reference to pthread_yield

[Nick Rosbrook]

Package: libxsmm
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

With glibc >= 2.34, libxsmm FTBFS with an undefined reference to
pthread_yield. Fixes have been committed upstream, but not yet included
in a release.

In Ubuntu, we cherry-picked the upstream commits to fix the build:

  * debian/patches: Cherry-pick upstream patches to fix undefined reference to
pthread_yield (LP: #1984111).

Thanks,
Nick
diff -Nru 
libxsmm-1.17/debian/patches/0003-Issue-551-rely-on-sched_yield-rather-than-pthread_yi.patch
 
libxsmm-1.17/debian/patches/0003-Issue-551-rely-on-sched_yield-rather-than-pthread_yi.patch
--- 
libxsmm-1.17/debian/patches/0003-Issue-551-rely-on-sched_yield-rather-than-pthread_yi.patch
 1969-12-31 19:00:00.0 -0500
+++ 
libxsmm-1.17/debian/patches/0003-Issue-551-rely-on-sched_yield-rather-than-pthread_yi.patch
 2022-08-09 10:18:54.0 -0400
@@ -0,0 +1,25 @@
+Description: rely on sched_yield rather than pthread_yield (GLIBC 2.34 and 
later).
+Author: Hans Pabst 
+Origin: upstream, 
https://github.com/libxsmm/libxsmm/commit/161ee78f1ccbbe6ce2c0439d6889221cca77ce13
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libxsmm/+bug/1984111
+Last-Update: 2022-08-09
+---
+
+--- a/include/libxsmm_sync.h
 b/include/libxsmm_sync.h
+@@ -462,6 +462,10 @@
+ #   define LIBXSMM_TLS_GETVALUE(KEY) pthread_getspecific(KEY)
+ #   if defined(__APPLE__) && defined(__MACH__)
+ # define LIBXSMM_SYNC_YIELD pthread_yield_np()
++#   elif defined(__GLIBC__) && defined(__GLIBC_MINOR__) \
++  && LIBXSMM_VERSION2(2, 34) <= LIBXSMM_VERSION2(__GLIBC__, 
__GLIBC_MINOR__)
++  LIBXSMM_EXTERN int sched_yield(void); /* sched.h */
++# define LIBXSMM_SYNC_YIELD sched_yield()
+ #   else
+ # if defined(__USE_GNU) || !defined(__BSD_VISIBLE)
+   LIBXSMM_EXTERN int pthread_yield(void) LIBXSMM_THROW;
+@@ -813,4 +817,3 @@
+ LIBXSMM_API unsigned int libxsmm_get_tid(void);
+ 
+ #endif /*LIBXSMM_SYNC_H*/
+-
diff -Nru 
libxsmm-1.17/debian/patches/0004-Fixed-potential-issue-about-undefined-pthread_yield.patch
 
libxsmm-1.17/debian/patches/0004-Fixed-potential-issue-about-undefined-pthread_yield.patch
--- 
libxsmm-1.17/debian/patches/0004-Fixed-potential-issue-about-undefined-pthread_yield.patch
  1969-12-31 19:00:00.0 -0500
+++ 
libxsmm-1.17/debian/patches/0004-Fixed-potential-issue-about-undefined-pthread_yield.patch
  2022-08-09 10:18:54.0 -0400
@@ -0,0 +1,33 @@
+Description: Fixed potential issue about undefined pthread_yield (linkage).
+Author: Hans Pabst 
+Origin: upstream, 
https://github.com/libxsmm/libxsmm/commit/304de784a56c3d7763c92b1801e059c3d39e14dc
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/libxsmm/+bug/1984111
+Last-Update: 2022-08-09
+---
+diff --git a/include/libxsmm_macros.h b/include/libxsmm_macros.h
+index 1795ce763..e4d31c9d3 100644
+--- a/include/libxsmm_macros.h
 b/include/libxsmm_macros.h
+@@ -844,6 +844,7 @@ LIBXSMM_API_INLINE int libxsmm_nonconst_int(int i) { 
return i; }
+ #   include 
+ # else
+ #   include 
++#   include 
+ # endif
+ #endif
+ #if !defined(LIBXSMM_ASSERT)
+diff --git a/include/libxsmm_sync.h b/include/libxsmm_sync.h
+index b64a55f09..d92dad2c8 100644
+--- a/include/libxsmm_sync.h
 b/include/libxsmm_sync.h
+@@ -466,8 +466,8 @@ typedef enum libxsmm_atomic_kind {
+ #   define LIBXSMM_TLS_GETVALUE(KEY) pthread_getspecific(KEY)
+ #   if defined(__APPLE__) && defined(__MACH__)
+ # define LIBXSMM_SYNC_YIELD pthread_yield_np()
+-#   elif defined(__GLIBC__) && defined(__GLIBC_MINOR__) \
+-  && LIBXSMM_VERSION2(2, 34) <= LIBXSMM_VERSION2(__GLIBC__, 
__GLIBC_MINOR__)
++#   elif defined(_POSIX_PRIORITY_SCHEDULING) || (defined(__GLIBC__) && 
defined(__GLIBC_MINOR__) \
++  && LIBXSMM_VERSION2(2, 34) <= LIBXSMM_VERSION2(__GLIBC__, 
__GLIBC_MINOR__))
+   LIBXSMM_EXTERN int sched_yield(void); /* sched.h */
+ # define LIBXSMM_SYNC_YIELD sched_yield()
+ #   else
diff -Nru libxsmm-1.17/debian/patches/series libxsmm-1.17/debian/patches/series
--- libxsmm-1.17/debian/patches/series  2022-03-19 19:49:47.0 -0400
+++ libxsmm-1.17/debian/patches/series  2022-08-09 10:18:54.0 -0400
@@ -1,2 +1,4 @@
 0001-Makefile-rebuild-fix.patch
 0002-Makefile-fix-pkgconfigdir.patch
+0003-Issue-551-rely-on-sched_yield-rather-than-pthread_yi.patch
+0004-Fixed-potential-issue-about-undefined-pthread_yield.patch

Bug#1016411: ghdl FTBFS with LLVM 14 as default

[Nick Rosbrook]

Package: ghdl
Followup-For: Bug #1016411
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

In Ubuntu, this patch was applied to fix the build with LLVM 14.0.
Additionally, we opted to skip the build tests on armhf until upstream
provides a solution[1].

  * debian/patches/llvm14.0.patch: Allow building with LLVM 14.0
(LP: #1983908).
  * debian/rules: Skip testsuite on armhf (LP: #1984138).

Thanks,
Nick

[1] https://github.com/ghdl/ghdl/issues/2170
diff -Nru ghdl-1.0.0+dfsg/debian/patches/llvm14.0.patch 
ghdl-1.0.0+dfsg/debian/patches/llvm14.0.patch
--- ghdl-1.0.0+dfsg/debian/patches/llvm14.0.patch   1969-12-31 
19:00:00.0 -0500
+++ ghdl-1.0.0+dfsg/debian/patches/llvm14.0.patch   2022-08-09 
11:40:42.0 -0400
@@ -0,0 +1,33 @@
+Description: Enable building with LLVM 14.0
+ Allow the configure script to handle LLVM 14.0, and use DWARFv4 format to 
remain
+ compatible with dwz.
+Author: Nick Rosbrook 
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/ghdl/+bug/1983908
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016411
+Forwarded: no, the DWARFv4 piece is packaging specific due to dh_dwz
+Last-Update: 2022-08-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/configure
 b/configure
+@@ -283,6 +283,7 @@
+check_version 11.1.0 $llvm_version ||
+check_version 12.0 $llvm_version ||
+check_version 13.0 $llvm_version ||
++   check_version 14.0 $llvm_version ||
+false; then
+ echo "Debugging is enabled with llvm $llvm_version"
+   else
+--- a/Makefile.in
 b/Makefile.in
+@@ -59,6 +59,10 @@
+ 
+ VHDL_LIB_DIR=$(prefix)/$(libdirsuffix)/vhdl
+ 
++ifeq "$(backend)" "llvm"
++ OPT_FLAGS+=-gdwarf-4
++endif
++
+ ifeq "$(enable_checks)" "true"
+  # Debug + checks
+  OPT_FLAGS+=-g
diff -Nru ghdl-1.0.0+dfsg/debian/patches/series 
ghdl-1.0.0+dfsg/debian/patches/series
--- ghdl-1.0.0+dfsg/debian/patches/series   2022-02-14 17:10:35.0 
-0500
+++ ghdl-1.0.0+dfsg/debian/patches/series   2022-08-09 11:40:42.0 
-0400
@@ -7,3 +7,4 @@
 llvm12.0.patch
 llvm11.1.0.patch
 llvm13.0.patch
+llvm14.0.patch
diff -Nru ghdl-1.0.0+dfsg/debian/rules ghdl-1.0.0+dfsg/debian/rules
--- ghdl-1.0.0+dfsg/debian/rules2022-02-14 17:10:35.0 -0500
+++ ghdl-1.0.0+dfsg/debian/rules2022-08-09 11:40:42.0 -0400
@@ -197,6 +197,9 @@
@echo 
@echo Run testsuite
@echo 
+ifeq ($(DEB_HOST_ARCH),armhf)
+   @echo Skipping testsuite on armhf
+else
# With some paths patched for the Debian packaging, the tests will not
# work right when run from the build directory. To keep it simple
# simply install into a temporary location and tell the testsuite to
@@ -219,6 +222,7 @@
ln -sf lib/ghdl/gcc/libexec $(TESTRUNDIR)/gcc/usr/libexec; \
debian/tests/ghdl-tests buildtest gcc; \
fi
+endif
 
 override_dh_gencontrol:
if [ -n "$(WITH_GCC)" ]; then \

Bug#1017468: openfst: FTBFS in dh_auto_test due to excessive memory usage

[Nick Rosbrook]

Package: openfst
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

The openfst build was failing both locally and on Ubuntu build
infrastructure[1] during dh_auto_test. In both situations, the build
process was getting killed due to excessive memory usage. In Ubuntu, the
attached patch was applied to reduce the memory usage during
dh_auto_test.

  * debian/rules: Set --max-parallel=2 in override_dh_auto_test to avoid
excessive memory usage resulting in FTBFS (LP: #1984137).

Thanks,
Nick

[1] 
https://launchpadlibrarian.net/617386196/buildlog_ubuntu-kinetic-amd64.openfst_1.7.9-4_BUILDING.txt.gz
diff -Nru openfst-1.7.9/debian/rules openfst-1.7.9/debian/rules
--- openfst-1.7.9/debian/rules  2022-04-05 08:03:00.0 -0400
+++ openfst-1.7.9/debian/rules  2022-08-09 16:50:53.0 -0400
@@ -37,6 +37,9 @@
 ifneq ($(findstring mips,$(DEB_BUILD_ARCH)),)
 override_dh_auto_test:
# Tests disabled on MIPS
+else
+override_dh_auto_test:
+   dh_auto_test --max-parallel=2
 endif
 
 override_dh_missing:

Bug#1014821: python3-hgapi: duplicates python-hglib functionality

[Nick Morrott]

On Tue, 12 Jul 2022 at 16:09, Julien Cristau  wrote:
>
> I'm curious why python-hgapi exists when from its description it sounds
> like it's a clone of python-hglib which predates it (at least in the
> debian archive) by a number of years?

Dear Julien,

I seem to remember checking this when I was packaging the micro:bit
toolchain and finding their different approaches:

- python-hgapi uses the Mercurial command line for its work
- python-hglib uses the internal Mercurial API for its work

python-hgapi was packaged solely as a dependency for yotta. Having
neither the experience with hg internally, nor the desire, I did not
got through the source to migrate from one to the other.

Please let me know if you're happy to close the report.

Cheers,
Nick

Bug#995670: Zig package status

[Nick Hastings]

Hi,

* Henrique Almeida  [220811 03:57]:
>  Hello, what's the current status of the Zig package for the Debian
> official repository ?

I've filed a request for a sponsor
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012286

Other than not have a sponsor, the two main issues I see are:

1. Some of the post build tests fail.
Checking on zig issues and IRC it seems not so unusual for some tests to
fail in certain situations. I'm not sure how worthwhile it is chasing
down these issues before zig reaches 1.0.0. 

2. The copyright file.
With so much bundled source code from different projects it's quite
challenging to write a correct copyright file. I've put considerable
time into this, but it is horribly tedious and boring work. Without a
sponsor to get zig into Debian I could just be completely wasting my
time.

Cheers,

Nick.