Bug#1022022: New btusb hardware IDs (MT7922, MT7921, others)

[Bjørn Mork]

Chris Hofstaedtler  writes:
> * Diederik de Haas  [221019 00:07]:
>> On dinsdag 18 oktober 2022 23:44:17 CEST Chris Hofstaedtler wrote:
>> > it appears quite some new btusb hardware was released recently.
>> > linux-next has a lot of simple "Add xyz ID" patches for btusb.c:
>> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/driv
>> > ers/bluetooth/btusb.c
>> > 
>> > Please consider applying 57117d7234dadfba2a83615b2a9369f6f2f9914f
>> > and/or the other patches adding new hwids to btusb.c for the
>> > bookworm kernel.
>> 
>> It's already part of Linux 6.1-rc1 and it is expected that 6.1 will be the
>> next LTS release and I'd guess thus also the Bookworm kernel.
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/bluetooth?h=v6.1-rc1
>
> Right, that'd be good. I've manually applied
> 57117d7234dadfba2a83615b2a9369f6f2f9914f against 5.9.11-1, and that
> works for me; but only after making available
> BT_RAM_CODE_MT7922_1_1_hdr.bin from linux-firmware.git.

If this is a simple device ID addition without any other dependencies,
then it qualifies for Linux stable.  And you'll get it in Debian stable
for free.

New device ID patches are regularily backported to the maintained stable
kernels, and usually picked up automatically by the stable maintainers.
You can request a backport of a specific commit in mainline by sending
an email to sta...@vger.kernel.org

See https://docs.kernel.org/process/stable-kernel-rules.html


Bjørn

Bug#1022027: crypt symbols are missing from musl breaking its ABI

[Szabolcs Nagy]

Package: musl
Version: 1.2.3-1
X-Debbugs-CC: Helmut Grohne 

The crypt symbols are part of the musl libc ABI which enables binaries
to be portable between systems where musl is installed, but debian
removed these symbols (not just the headers).

nm -D /lib/ld-musl-x86_64.so.1 |grep crypt

should print crypt, crypt_r and decrypt symbols, but on debian the
result is empty.

attached a patch that should fix the issue.
diff --minimal -Nru musl-1.2.3/debian/changelog musl-1.2.3/debian/changelog
--- musl-1.2.3/debian/changelog 2022-04-07 22:48:37.0 +0200
+++ musl-1.2.3/debian/changelog 2022-10-17 17:49:14.0 +0200
@@ -1,3 +1,10 @@
+musl (1.2.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Restore crypt functionality in libc.{a,so} for ABI compatibility.
+
+ -- Helmut Grohne   Mon, 17 Oct 2022 17:49:14 +0200
+
 musl (1.2.3-1) unstable; urgency=medium
 
   * New upstream release.
diff --minimal -Nru musl-1.2.3/debian/clean musl-1.2.3/debian/clean
--- musl-1.2.3/debian/clean 2021-08-21 12:05:49.0 +0200
+++ musl-1.2.3/debian/clean 2022-10-17 17:49:14.0 +0200
@@ -1,7 +1,5 @@
 debian/musl-dev.postinst
 debian/musl-dev.postrm
 debian/scripts/*.path
-include/crypt.h
-src/crypt/
 include/fts.h
 src/fts/
diff --minimal -Nru musl-1.2.3/debian/rules musl-1.2.3/debian/rules
--- musl-1.2.3/debian/rules 2021-08-21 12:05:23.0 +0200
+++ musl-1.2.3/debian/rules 2022-10-17 17:49:14.0 +0200
@@ -73,7 +73,7 @@
dh_auto_configure -- --libdir=/usr/lib/$(MUSL_TRIPLE) 
--includedir=/usr/include/$(MUSL_TRIPLE) --host=$(DEB_HOST_GNU_TYPE) 
--enable-gcc-wrapper=$(GCC_WRAPPER) --enable-debug
 
 execute_after_dh_auto_install:
-   rm debian/tmp/usr/lib/$(MUSL_TRIPLE)/libcrypt.a
+   rm debian/tmp/usr/include/$(MUSL_TRIPLE)/crypt.h 
debian/tmp/usr/lib/$(MUSL_TRIPLE)/libcrypt.a
 
 execute_after_dh_install:
 ifeq ($(GCC_WRAPPER),yes)

Bug#1022028: jhead: CVE-2022-41751

[Salvatore Bonaccorso]

Source: jhead
Version: 1:3.06.0.1-2
Severity: grave
Tags: security upstream
Forwarded: https://github.com/Matthias-Wandel/jhead/pull/57
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jhead.

CVE-2022-41751[0]:
| Jhead 3.06.0.1 allows attackers to execute arbitrary OS commands by
| placing them in a JPEG filename and then using the regeneration -rgt50
| option.

>From context I'm not yet really conviced we need a DSA for it, as a
user needs to be tricked into processing a specially crafted filename.
keeping RC severity though to make sure the fix land in bookworm.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-41751
https://www.cve.org/CVERecord?id=CVE-2022-41751
[1] https://github.com/Matthias-Wandel/jhead/pull/57

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1022029: rust-chrono: please update to 0.4.20

[Jonas Smedegaard]

Source: rust-chrono
Version: 0.4.19-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to upstream release 0.4.20 (or newer), needed by projects
I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNPsb0ACgkQLHwxRsGg
ASHNtA/+JluVJsL/rPVBhme5NS64UIiUHjyo6gkXpYj8vIFJ5uuw0nG9j5kg9+fV
V7ZikGK9zr1AA+C7m2QkPPJUuELlHqKwjAGCUKzblR4dOGbMccogIGIUCLGj7iYr
MGmQ0E/WetnJeGUO0uYb+LeSUxib6P0DIbWHHKd5ksLu33C2AzMgR7MChSFhM8dX
U6yvNWp+JIXuDdwSSiOYg/avxukNX0CHXKohloU61EONzVZZYyzLb2sxvobYf3P2
+eh7/OBfFlkuo3oYHaLub1dNbVP7Vb1D6KONM/oTccsdf11xXttH3tDFC/gW2mIK
KzYNptAsNKq5w5XjkIURP4WUD1h3ymI7qndoHb6m3BHJIZrLup2DEmMRTdi7xB5w
inX7BbS9m1n9AGxvA7IglyXOC9xy6I+IpC+YUfCYJFssdfWT5qwe+SRbqsECV9qY
/d5tVyc0eZV8+j14cdg5oNFRh/x1GK3YGS3EPCf5Plvb0EQPWudZgZh4sfgtWYu7
MNEYJ1onh62mXKwf7N97+NiavUXPpv0S9dAPDrQFi2hJld3y7dE6RM6kxXgogRKX
wh0n+X7L9rtmi5TlyPx3SCpIGoCb9L5hqpPN/UsMLeh/OicvJXNIcDkTkNhzzfX6
IXQht1Gs3/fZw0shpy/0rIeNG69TZksCPLOb9BEbTyAMFaQjvmk=
=wPFx
-END PGP SIGNATURE-

Bug#1022030: toolz: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Source: toolz
Version: 0.11.2-1
Severity: important
Tags: ftbfs fixed-upstream
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

toolz will FTBFS once Python 3.11 is added as a supported version.
I've copied what I hope is the relevant part of the log below.  This
appears to be fixed in the upstream 0.12.0 release.

You can verify this by installing python3.11 from testing or unstable
and adding the following line to debian/rules:
export DEBPYTHON3_SUPPORTED=3.10,3.11

Although for toolz, you'll need python-py fixed (#1021871), but that
does not block fixing this bug.

Regards
Graham


___ test_tlz ___

def test_tlz():
import tlz
tlz.curry
tlz.functoolz.curry
assert tlz.__package__ == 'tlz'
assert tlz.__name__ == 'tlz'
>   import tlz.curried

toolz/tests/test_tlz.py:10:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
:1178: in _find_and_load
???
:1149: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
tlz/_build_tlz.py:85: in exec_module
submodule = import_module(module_name)
/usr/lib/python3.11/importlib/__init__.py:126: in import_module
return _bootstrap._gcd_import(name[level:], package, level)
:1206: in _gcd_import
???
:1178: in _find_and_load
???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

name = 'tlz.curried.operator'
import_ = 

>   ???
E   AttributeError: 'TlzSpec' object has no attribute
'_uninitialized_submodules'

:1147: AttributeError

Bug#1010807: isc-dhcp: ftbfs on riscv64 arch

[Santiago Ruano Rincón]

El 19/10/22 a las 11:29, Paul Wise escribió:
> On Tue, 2022-10-18 at 10:17 +0800, Bo YU wrote:
> 
> > Certainly. I have updated the patch with help of Paul Wise.
> > But I am not sure I understand it correctly. Yeah, The bind.tar.gz keeps
> > itself config.{guess/sub}, so I simply copy these files from system in
> > Makefile.
> 
> While that is a minimal workaround for the riscv64 FTBFS, I think a
> better option would be to unpack bind/bind.tar.gz manually before
> dh_update_autotools_config runs and also ensure that dh_autoreconf
> rebuilds things in the unpacked bind dir too, something like this:
> 
> debian/rules
> 
>    # Ensure that the bind config.guess/config.sub are unpacked first,
>    # otherwise they won't be updated and isc-dhcp will FTBFS on new arches
>    execute_before_dh_update_autotools_config:
> cd bind && tar xf bind.tar.gz
>    
>    # Ensure that the bind build system gets rebuilt too
>    override_dh_autoreconf:
> dh_autoreconf debian/autogen.sh
> 
> debian/autogen.sh
> 
>    #!/bin/sh
>    set -x
>    autoreconf -f -i
>    cd bind/bind-*/
>    autoreconf -f -i

Bo Yu, could you please check the attached patch instead? It comes from
Ubuntu, where isc-dhcp seems to build OK.

> 
> That is still only a workaround; the correct solution to this issue
> is that isc-dhcp should link against the bind9 libraries instead of
> adding a copy of bind9 to isc-dhcp. This would be more complicated
> though and would have to be done upstream not in Debian.

I am afraid that is no longer a possible solution. Please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942502

Cheers,

 -- Santiago
Description: run autoreconf in the bind directory
 Using an embedded version of old bind libraries instead of having to ship
 those as a separate source package in the archive is fine, but then we
 shouldn't use 9-year-old config.{guess,sub} that don't know about current
 architectures and cause build failures.
Author: Steve Langasek 
Last-Update: 2022-08-14
Forwarded: no

Index: isc-dhcp-4.4.3/bind/Makefile.in
===
--- isc-dhcp-4.4.3.orig/bind/Makefile.in
+++ isc-dhcp-4.4.3/bind/Makefile.in
@@ -56,6 +56,7 @@
 		echo Configuring BIND libraries for DHCP. ; \
 		rm -rf ${cleandirs} ${cleanfiles} ; \
 		(cd ${bindsrcdir} &&\
+		 autoreconf -i -f &&	\
  ./configure ${bindconfig} > ${binddir}/configure.log); \
 	fi
 


signature.asc
Description: PGP signature

Bug#1021603: libpmix2

[Alastair McKinstry]

It appears that openmpi needs to be rebuilt with the latest pmix.

This works locally for me, but an  attempt to do so (on the autobuilds) 
was blocked by a separate bug in pmix.


Will retry


Alastair



On 16/10/2022 23:23, Ron Lovell wrote:

Should have said Arch Linux Issue 75727.

On Sun, Oct 16, 2022 at 5:20 PM Ron Lovell  wrote:

Same issue as Arch issue 279267?

-- 
James Ronald Lovell 

Huntsville, AL, USA



--
James Ronald Lovell 
Huntsville, AL, USA


--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e:alast...@sceal.ie, im: @sceal.ie:mckinstry

Bug#1022028: jhead: CVE-2022-41751

[Jakub Wilk]

* Salvatore Bonaccorso , 2022-10-19 09:53:

[1] https://github.com/Matthias-Wandel/jhead/pull/57


This fix is incomplete:
https://github.com/Matthias-Wandel/jhead/issues/60

--
Jakub Wilk

Bug#1019403: gitlab: failed to fetch comments in issue (500 Internal Server Error)

[Jakob Haufe]

> An alternative fix is to replace:
> #{"style=\"background-color: #{h bg_color}\"" if bg_color}
> with:
> #{"style=\"background-color: #{html_escape bg_color}\"" if bg_color}
> 
> I think "h" is supposed to be a method alias for "html_escape", but
> is not loaded due to something missing in our setup.

This fails for me the same way as plain "h". After digging deeper, I
found "h" is ERB::Util.h, so changing the line to:

#{"style=\"background-color: #{ERB::Util.h bg_color}\"" if bg_color}

works for me.

-- 
ceterum censeo microsoftem esse delendam.


pgpqJhiU1pFDU.pgp
Description: OpenPGP digital signature

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Bastian Germann]

Am 19.10.22 um 00:52 schrieb Soren Stoutner:
I very carefully looked though all the files in the source and the output of licensecheck to create the copyright file.  
If you compare it to the copyright file from 4.0.9-1 you will see that it is much improved and fixes many inaccuracies 
that existed in the 4.0.9-1 Debian package.  I am fairly sure that the current copyright file is comprehensively 
correct, but feel free to point out anything I have missed.


Missing copyright:

2011, ParaType Ltd.
2014, The Monero Project

Missing license:

CC0 via electrum/www/jquery-ui-themes-1.12.1/LICENSE.txt

Bug#1022031: perl: FTBFS on sparc64: test failures in t/re

[Niko Tyni]

Source: perl
Version: 5.36.0-4
Tags: ftbfs
X-Debbugs-Cc: debian-sp...@lists.debian.org

The perl package currently fails to build on sparc64 due
to two failing tests:

  t/re/reg_fold  ok
  t/re/reg_mesg  FAILED--no 
leader found
  t/re/reg_namedcapture  ok
  t/re/reg_nc_tie .. ok
  t/re/reg_nocapture ... ok
  t/re/reg_pmod  ok
  t/re/reg_posixcc . ok
  t/re/regex_sets .. FAILED--no 
leader found

[...]

  Failed 2 tests out of 2622, 99.92% okay.
re/reg_mesg.t
re/regex_sets.t

The 5.36 transition is already ongoing
 (see https://lists.debian.org/debian-devel-announce/2022/10/msg5.html )
so you might want to upload a nocheck build or something to catch
the train.

Apologies for the late notice,
-- 
Niko Tyni   nt...@debian.org

Bug#1021871: python-py: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Control: block 1021984 by -1
Control: affects -1 + src:lru-dict src:cbor2 src:python-moderngl-glcontext
Control: affects -1 + src:pycurl src:python-cffi src:python-unicodedata2
Control: affects -1 + src:poetry-core src:pycairo src:extension-helpers

This can be verified by installing python3.11 from testing or unstable
and adding the following line to debian/rules:
export DEBPYTHON3_SUPPORTED=3.10,3.11

Ideally, this should be fixed before the Python 3.11 transition
(#1021984) starts, as several packages in the lower dependency levels
of the transition tracker are affected.

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Bastian Germann]

Am 19.10.22 um 00:43 schrieb Soren Stoutner:
Because this Lintian error existed in the previous packages and because it does not relate the RC bug that this upload 
is attempting to fix I was planning to wait for a future release to fix it.  Do you think it would be best to deal with 
it now without input from Tristan Seligmann?




Yes. I am a team member and can make this kind of change.
I have to care about packages that I upload are conforming to the Debian Policy
and not having the source available for the JS files is violating it.

The replacing of the embedded copies can wait however, but I would be happy to
sponsor another version with them as well.

Bug#1022031: perl: FTBFS on sparc64: test failures in t/re

[John Paul Adrian Glaubitz]

Hi!

On 10/19/22 11:06, Niko Tyni wrote:

The perl package currently fails to build on sparc64 due
to two failing tests:

   t/re/reg_fold  ok
   t/re/reg_mesg  
FAILED--no leader found
   t/re/reg_namedcapture  ok
   t/re/reg_nc_tie .. ok
   t/re/reg_nocapture ... ok
   t/re/reg_pmod  ok
   t/re/reg_posixcc . ok
   t/re/regex_sets .. 
FAILED--no leader found

[...]

   Failed 2 tests out of 2622, 99.92% okay.
re/reg_mesg.t
re/regex_sets.t

The 5.36 transition is already ongoing
  (see https://lists.debian.org/debian-devel-announce/2022/10/msg5.html )
so you might want to upload a nocheck build or something to catch
the train.


Already working on it. Are you going to file a bug report upstream or shall I?


Apologies for the late notice,


No worries.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#1022032: open-adventure: Uses deprecated yaml.load in tests

[Gordon Ball]

Source: open-adventure
Version: 1.9-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


Found in tests/coverage_dungeon.py


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

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

Bug#1022033: owslib: Uses deprecated yaml.load

[Gordon Ball]

Source: owslib
Version: 0.27.2-1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


Found in
https://sources.debian.org/src/owslib/0.27.2-1/owslib/ogcapi/__init__.py/?hl=102#L102
(but only when loading openapi in yaml format - not sure if this
codepath is much used).


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

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

Bug#1022034: policyd-rate-limit: Uses deprecated yaml.load

[Gordon Ball]

Source: policyd-rate-limit
Version: 1.0.1.1-2.1
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


Found in
https://sources.debian.org/src/policyd-rate-limit/1.0.1.1-2.1/policyd_rate_limit/utils.py/?hl=88#L88
for loading yaml-format config files (and in tests)


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

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

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Soren Stoutner]

On Wednesday, October 19, 2022 2:00:23 AM MST Bastian Germann wrote:
> Am 19.10.22 um 00:52 schrieb Soren Stoutner:
> > I very carefully looked though all the files in the source and the output
> > of licensecheck to create the copyright file. If you compare it to the
> > copyright file from 4.0.9-1 you will see that it is much improved and
> > fixes many inaccuracies that existed in the 4.0.9-1 Debian package.  I am
> > fairly sure that the current copyright file is comprehensively correct,
> > but feel free to point out anything I have missed.
> 
> Missing copyright:
> 
> 2011, ParaType Ltd.
> 2014, The Monero Project

Good catch.  I have added these to the copyright file and will submit a MR 
shortly.

> Missing license:
> 
> CC0 via electrum/www/jquery-ui-themes-1.12.1/LICENSE.txt

The jQuery UI themes license is covered by the following existing section in 
the copyright file:

Files: electrum/www/jquery-ui-themes-1.12.1/*
Copyright: jQuery Foundation and other contributors, https://jquery.org/
License: Expat
Comment:
 Various authors are described in the
 electrum/www/jquery-ui-themes-1.12.1/ AUTHORS file.

The CC0 license mentioned in the second half of electrum/www/jquery-ui-
themes-1.12.1/LICENSE.txt specifically says, "Copyright and related rights for 
sample code are waived via CC0. Sample code is defined as all source code 
contained within the demos directory.”  The demos directory is not shipped in 
the upstream tarball, so this license was left out of the copyright file as it 
does not apply to any files.

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

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

Bug#1022035: python-aptly: Uses deprecated yaml.load

[Gordon Ball]

Source: python-aptly
Version: 0.12.10-3
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


Found in publisher/__{init,main}__.py for loading config.


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

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

Bug#1020436: giac FTBFS with PARI 2.15.0

[Tobias Hansen]

I tried rebuilding with this patch from sagemath:

|diff --git a/src/pari.cc b/src/pari.cc index 76ce8e1..50d08ab 100644 --- 
a/src/pari.cc +++ b/src/pari.cc @@ -40,6 +40,13 @@ using namespace std; #ifdef 
HAVE_LIBPARI +// Anyarg disappeared from PARI 2.15.0 +#ifdef __cplusplus +# 
define ANYARG ... +#else +# define ANYARG +#endif + #ifdef HAVE_PTHREAD_H 
#include  #endif|


But I get one test failure:

FAIL: chk_fhan4
===

// Using locale /usr/share/locale/
// C.UTF-8
// /usr/share/locale/
// giac
// UTF-8
// Maximum number of parallel threads 8
// Unable to find keyword file doc/en/keywords
Added 0 synonyms
// Warning: a, declared as global variable(s). If symbolic variables are 
required, declare them as local and run purge
// Success
// Success
// Success
// Success
// Success
// Success
// Success
// Success
// End defining T
== restarted ===
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
// Time 0.02
// Time 0
// Time 0
// Time 0
// Time 0
0
0
0
0
0
0
0
0
0
// Time 0.03
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
0
0
0
0
// Time 0.04
// Time 0
// Time 0
// Time 0
// Time 0
0
// Time 0.06
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0.01
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0
// Time 0.01
  ***   the thread stack overflows !
  current stack size: 1024000 (0.977 Mbytes)
  [hint] set 'threadsizemax' to a nonzero value in your GPRC
  *** matdet: Warning: increasing stack size to 2048000.
  ***   at top-level: matdet([-10,-7,6,-7,1,4,-1,-2,-2,-5,1,7,-6,7,-
  *** ^--
  *** matdet: the thread stack overflows !
  current stack size: 1024000 (0.977 Mbytes)
  [hint] set 'threadsizemax' to a nonzero value in your GPRC
Error in PARI subsystem
Segmentation fault
49c49,108
<
---
> "Done",
> "Done",
> "Done",
> 0,
> 0,
> 50,
> "Done",
> "Done",
> "Done",
> "Done",
> 0,
> 0,
> 30,
> "Done",
> "Done",
> "Done",
> "Done",
> "Done",
> "Done",
> 0,
> 0,
> 0,
> 40,
> "Done",
> "Done",
> 0,
> 50,
> "Done",
> "Done",
> 0,
> [[0,-2,1,3],[0,0,0,1],[1,1,0,0],[-3,4,1,0]],
> "Done",
> "Done",
> "Done",
> "Done",
> "Done",
> [[0,1,0,0],[1,0,0,0],[0,0,1,0],[0,0,0,1]],
> [[0,0,0,1],[0,-2,1,3],[1,1,0,0],[-3,4,1,0]],
> proc(i,j,a)
>   local TT;
>   TT:=identity(4);  
>   TT[i,j]:=a;  
>   TT;  
>  
> end;,
> [[0,0,0,1],[0,-2,1,3],[1,1,0,1/2],[-3,4,1,0]],
> [[0,0,0,1],[0,-2,1,3],[1,1,0,1/2],[-3,4,1,3/2]],
> "Done",
> "Done",
> "Done",
> "Done",
> "Done",
> [[1,0,0,0],[0,0,0,1],[0,0,1,0],[0,1,0,0]],
> [[0,0,0,1],[-3,4,1,3/2],[1,1,0,1/2],[0,-2,1,3]],
> [[0,0,1,0],[1,0,0,0],[0,0,0,1],[0,1,0,0]],
> [[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]],
> [[0,0,0,1],[-3,4,1,3/2],[1,1,0,1/2],[-2,-4,1,2]],
> [[1,0,0,0],[-3/2,1,0,0],[-1/2,0,1,0],[0,0,2,1]],
> [[0,0,0,1],[1,0,0,0],[0,0,1,0],[0,1,0,0]],
> [[0,0,0,0],[0,0,0,0],[0,0,0,0],[0,0,0,0]]
FAIL chk_fhan4 (exit status: 1)


Testsuite summary for giac 1.9.0

# TOTAL: 30
# PASS:  29
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0




On 10/1/22 20:46, Bill Allombert wrote:
> On Wed, Sep 21, 2022 at 09:01:51PM +0300, Adrian Bunk wrote:
>> Source: giac
>> Version: 1.9.0.19+dfsg2-1
>> Severity: serious
>> Tags: ftbfs
>>
>> https://buildd.debian.org/status/logs.php?pkg=giac&ver=1.9.0.19%2Bdfsg2-1%2Bb1
>>
>> ...
>> pari.cc: At global scope:
>> pari.cc:752:17: error: typedef ‘giac::PFGEN’ is initialized (use ‘decltype’ 
>> instead)
>>   752 |   typedef GEN (*PFGEN)(ANYARG);
>>   | ^
>> pari.cc:752:24: error: ‘ANYARG’ was not declared in this scope
> This is my comment on this bug:
>
> PARI used to define ANYARG as
> #ifdef __cplusplus
> #  define ANYARG ...
> #else
> #  define ANYARG
> #endif
>
> This definition was removed because newer gcc/clang do not like to call
> function without prototype and it was not particularly
> useful.
>
> So you can replace this by
>
> typedef GEN (*PFGEN)();
>
> if you like, but recent gcc 12 will issue warning.
> In PARI we changed EVAL_f to cast the pointer to the right prototype
> before calling it.
>
> Sorry for the trouble.
>
> Cheers,

Bug#1022036: python-canmatrix: Uses deprecated yaml.load

[Gordon Ball]

Source: python-canmatrix
Version: 0.9.5~github-2
Severity: normal
X-Debbugs-Cc: gor...@chronitis.net

We hope to upgrade python3-yaml (aka pyyaml) to version 6 before the
freeze, per #1008262

Your package appears to use `yaml.load()` without specifying a `Loader=`
argument, which will become an error in pyyaml version 6. This should
have emitted a warning message since version 5.1 (from 2019).

In most cases this can be fixed by replacing `yaml.load` with
`yaml.safe_load`, unless the ability for yaml to create arbitrary python
objects is desirable.


load() in
https://sources.debian.org/src/python-canmatrix/0.9.5~github-2/src/canmatrix/formats/yaml.py/?hl=77#L77
appears to use unqualified yaml.load - and it looks like in this case
the desired behaviour is probably not to use safe_load since
_init_yaml() declares several tag types, but I think loading (if it is
ever used) still needs an explicit Loader= argument.


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

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

Bug#1022037: thunderbird: Incorrect icon in KDE/Wayland with Wayland enabled

[Frédéric Parrenin]

Package: thunderbird
Version: 1:102.3.3-1
Severity: normal
X-Debbugs-Cc: frederic.parre...@univ-grenoble-alpes.fr

Steps to reproduce:
- enter a KDE/Wayland session
- launch thunderbird with MOZ_ENABLE_WAYLAND=1
=> the thunderbird icon, in the top-left corner of the window or in the window
switcher is a generic Wayland icon, instead of being the thunderbid icon.
This is because the app_id is thunderbird-default, and it does not match with
the .desktop filename which is thunberbird.


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

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

Versions of packages thunderbird depends on:
ii  debianutils  5.7-0.3
ii  fontconfig   2.13.1-4.5
ii  kdialog  4:21.12.3-1
ii  libasound2   1.2.7.2-1
ii  libatk1.0-0  2.46.0-3
ii  libc62.35-3
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.4-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.0-3
ii  libgtk-3-0   3.24.34-3
ii  libicu71 71.1-3
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.83-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  librnp0  0.16.2-1
ii  libstdc++6   12.2.0-3
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.1-2
ii  libx11-xcb1  2:1.8.1-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxext6 2:1.3.4-1+b1
ii  libxrandr2   2:1.5.2-2+b1
ii  psmisc   23.5-3
ii  x11-utils7.7+5
ii  zenity   3.43.0-1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2
ii  hunspell-fr-classical [hunspell-dictionary]  1:7.0-1

Versions of packages thunderbird suggests:
ii  apparmor  3.0.7-1+b1
ii  fonts-lyx 2.3.6.1-1
ii  libgssapi-krb5-2  1.20-1+b1

-- no debconf information

Bug#1019424: me too

[Roderich Schupp]

On Fri, 9 Sep 2022 14:21:50 +0200 Roderich Schupp
 wrote:
> Same here (complete system info below), TL;DR:
>
> kernel 5.19.0-1-686
> system is using md raid:
>
> $ cat proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] [linear] [multipath]
> [raid0] [raid10]
> md1 : active raid5 sda3[3] sdc3[2] sdb3[1]
>   2926059520 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3]
> [UUU]
>
> md0 : active raid1 sdc2[2] sdb2[1] sda2[3]
>   101544 blocks super 1.2 [3/3] [UUU]

The problem has gone away in linux 6.0.2-1, apparently fixed by
4c66a326b5ab784cddd72de07ac5b6210e9e1b06 Revert "block: freeze the
queue earlier in del_gendisk"
so for my case you may close this bug.

Cheers, Roderich

Bug#1022030: toolz: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Control: affects -1 + src:skimage

This affects at least skimage in dependency level 6 of the Python 3.11
transition (#1021984).

Bug#1022038: firefox-esr: Incorrect icon on KDE/Wayland with Wayland enabled

[Frédéric Parrenin]

Package: firefox-esr
Version: 102.3.0esr-1
Severity: normal
X-Debbugs-Cc: frederic.parre...@univ-grenoble-alpes.fr

Steps to reproduce:
- enter a KDE/Wayland session
- launch firefox-esr with MOZ_ENABLE_WAYLAND=1
=> the firefox icon, in the top-left corner of the window or in the window
switcher is a generic Wayland icon, instead of being the firefox icon.
This is because the app_id is Firefox-esr, and it does not match with
the .desktop filename which is firefox-esr (note the capital "F" difference).


-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils  5.7-0.3
ii  fontconfig   2.13.1-4.5
ii  libasound2   1.2.7.2-1
ii  libatk1.0-0  2.46.0-3
ii  libc62.35-3
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libdbus-1-3  1.14.4-1
ii  libdbus-glib-1-2 0.112-2
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.2-4
ii  libfontconfig1   2.13.1-4.5
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.2.0-3
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.0-3
ii  libgtk-3-0   3.24.34-3
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.83-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libstdc++6   12.2.0-3
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.1-2
ii  libx11-xcb1  2:1.8.1-2
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
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:3.3.17-7+b1
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec59  7:5.1.2-1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20-1+b1
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

Bug#1022033: owslib: Uses deprecated yaml.load

[Sebastiaan Couwenberg]

Control: tags -1 upstream pending
Control: forwarded -1 https://github.com/geopython/OWSLib/pull/838

Thanks for reporting this issue, it fixed in git and forwarded upstream.

Kind Regards,

Bas

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

Bug#1022039: gh: new upstream release (v2.18.0)

[Jakub Wilk]

Package: gh
Version: 2.17.0+dfsg1-1
Severity: wishlist

gh v2.18.0 was released on 2022-10-18:
https://github.com/cli/cli/releases/tag/v2.18.0

Could you upload it to Debian?


-- System Information:
Architecture: i386

Versions of packages gh depends on:
ii  libc6  2.35-3

--
Jakub Wilk

Bug#1021550: FTBFS: JarCacheTest.cacheMiss Expected exception: java.io.IOException

[Andrius Merkys]

Control: tags -1 + unreproducible
Control: severity -1 important

Hi Pierre,

I have successfully built the package even with disabled network. Thus I 
cannot reproduce the FTBFS in any setup I can think of. As a result I am 
lowering issue's severity. Feel free to bump it back, but please supply 
some additional environment details to help me reproduce it.


It may as well be that the failure is nondeterministic (signal race).

Thanks,
Andrius

Bug#1021959: RFS: electrum/4.3.2-0.1 [NMU] [RC] -- Easy to use Bitcoin client

[Soren Stoutner]

On Wednesday, October 19, 2022 2:05:21 AM MST Bastian Germann wrote:
> Am 19.10.22 um 00:43 schrieb Soren Stoutner:
> > Because this Lintian error existed in the previous packages and because it
> > does not relate the RC bug that this upload is attempting to fix I was
> > planning to wait for a future release to fix it.  Do you think it would
> > be best to deal with it now without input from Tristan Seligmann?
> 
> Yes. I am a team member and can make this kind of change.
> I have to care about packages that I upload are conforming to the Debian
> Policy and not having the source available for the JS files is violating
> it.
> 
> The replacing of the embedded copies can wait however, but I would be happy
> to sponsor another version with them as well.

I have submitted a request to upstream to help me understand the best way to 
remove 
these JavaScript files and depend on system copies.  You can follow that 
conversation at the 
following link if you like.  Once I have a working build without these files I 
will create a MR.

https://github.com/spesmilo/electrum/issues/8023[1]

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


[1] https://github.com/spesmilo/electrum/issues/8023


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

Bug#1021845: s050000l.afm lost in transition from gsfonts to fonts-urw-base35

[fabian]

Hi,

Am 16.10.2022 21:22, schrieb Fabian Greffrath:

I will provide a README.Debian file with the next revision, explicitly
listing the font files with their previous and new file names and paths
to make migrations easier.


I have done so in the form of a debian/NEWS entry here, which is part of 
the -5 revision that I just uploaded:


https://salsa.debian.org/fonts-team/fonts-urw-base35/-/commit/6b87143e259bdf89bf6cb24624e1dd4ab4249827

Given that the s05l.afm file is *not* lost, but merely renamed and 
moved, and that this move is now properly documented, do you think we 
could close this issue again?


Thanks!

 - Fabian

Bug#1021846: grub-install is broken since 2.06-3: error: unknown filesystem

[Steve McIntyre]

On Wed, Oct 19, 2022 at 11:07:36AM +0300, программист некто wrote:
>I rebuilt grub2 v.2.06-4  without 3  f2fs patches.
>Results of   # /usr/sbin/grub-install -v /dev/sda
>in file attachment. No error!

Excellent, and thanks for testing!

OK, so the patches from upstream have broken f2fs support for
you. Looking at the patches, I'm not seeing anything *obvious* there
that might be an issue. They're all trying to add checks to avoid
crashes with an invalid/corrupt f2fs filesystem.

Silly question: does your filesystem have errors? Does fsck.f2fs
report anything?

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
< sladen> I actually stayed in a hotel and arrived to find a post-it
  note stuck to the mini-bar saying "Paul: This fridge and
  fittings are the correct way around and do not need altering"

Bug#1022040: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-language-haskell-extract
Version: 0.2.4-10
Severity: serious

I intend to remove this package:

  * The current version FTBFS and is incompatible with the latest GHC
  * Seems unmaintained; Last upload almost 10 years ago
  * It's not part of the latest Stackage LTS

If you believe we should keep this package in Debian, please close this
bug report.

-- 
Ilias

Bug#1019424: linux-image-5.19.0-1-amd64: endless loop at poweroff/reboot with "block device autoloading is deprecated and will be removed"

[Diederik de Haas]

On woensdag 19 oktober 2022 11:48:22 CEST Roderich Schupp wrote:
> The problem has gone away in linux 6.0.2-1, apparently fixed by
> 4c66a326b5ab784cddd72de07ac5b6210e9e1b06 Revert "block: freeze the
> queue earlier in del_gendisk"
> so for my case you may close this bug.

Francesco, is the bug fixed for you too with 6.0.2-1?

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

Bug#1022003: transition: gssdp/gupnp 1.2->1.6 (+ rygel 0.42.0)

[Andreas Henriksson]

Control: tags -1 - moreinfo

On Tue, Oct 18, 2022 at 09:32:10PM +0200, Sebastian Ramacher wrote:
> Control: tags -1 moreinfo
[...]
> Please remove the moreinfo tag once they cleared NEW.
[...]

All of them (gssdp, gupnp and rygel) has made it through NEW,
thus removing moreinfo tag.


I'll start working on local updates and build-testing reverse
dependencies next to verify the transition really is as easy as
anticipated.


Regards,
Andreas Henriksson

Bug#1022041: python3-msal: New upstream release 1.20.0

[Michael Sprengel]

Package: python3-msal
Version: 1.18.0b1-1
Severity: important

Dear Maintainer,

a new version of microsoft-authentication-library-for-python has been 
released, which is required by the newest version of azure-cli 
(2.41.0-1) in Debian testing and unstable.


By using the current version of python3-msal, you get the following 
error message during a login with the azure-cli:



Error: : The command failed with an unexpected error. Here is the traceback:

Error: : ClientApplication.__init__() got an unexpected keyword argument 
'allow_broker'



When you have a chance, it would be good if you could update this 
package to 1.20.0


Here, you can see the new release:
https://github.com/AzureAD/microsoft-authentication-library-for-python/releases/tag/1.20.0

Thanks in advance

Kind regards,
Michael

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

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

Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics

[Dan Coleman]

Package: linux-image-amd64
Version: 5.10.149-1
Severity: important
X-Debbugs-Cc: autop...@protonmail.com

Dear Maintainer,

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

   * What led up to the situation?

I upgraded to the latest security kernel on Stable (5.10.0-19). After 
upgrading, I rebooted.

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

Only thing that works to get 5.10.0-19 booting is to not have integrated AMD 
graphics. My other nvidia machine upgraded just fine. Disabling modesetting did 
not resolve the issue.

   * What was the outcome of this action?

Computer gets past GRUB, attempts to boot, and then hangs on a black screen. 
After about 30 seconds, some error messages are spat out regarding DRM and 
"flip_done timed out"

   * What outcome did you expect instead?

I expected the machine to boot normally.

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


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

Kernel: Linux 5.10.0-18-amd64 (SMP w/16 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)
LSM: AppArmor: enabled

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-19-amd64  5.10.149-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#975490: u-boot-sunxi: A64-Olinuxino-eMMC boot stuck at "Starting kernel ..."

[Diederik de Haas]

On Mon, 10 Oct 2022 00:08:29 +0200 Philip Rinn  wrote:
> I followed 
> https://wiki.debian.org/InstallingDebianOn/Allwinner#Installing_from_an_SD_card_image
>  
> using the daily build of the unstable netboot installer from 
> https://d-i.debian.org/daily-images/arm64/20221009-02:38/netboot/SD-card-images/
>  
> and I was able to install successfully but the system does not boot - it 
> tries 
> to boot from eMMC actually:
> 
> U-Boot SPL 2020.04+olimex-2-20210111.165338 (Jan 30 2020 - 11:10:18 +)

That is a 'peculiar' (and old) version ... (which does not work)

On Tue, 11 Oct 2022 19:22:34 +0200 Philip Rinn  wrote:
> OK, I used a custom bootstrap script now and that works:
> 
> U-Boot SPL 2022.10+dfsg-1 (Oct 04 2022 - 00:06:38 +)

While Debian's 2022.10+dfsg-1 does work :-)

Felt like worth noting.
As well as last msg from OP is from 2020-11-28 ...

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

Bug#1022043: apt-cacher-ng: sometimes fails to download some index files - maybe a race condition

[Václav Ovsík]

Package: apt-cacher-ng
Version: 3.7.4-1~bpo11+1
Severity: normal

Dear Maintainer,
I have errors while updating apt database with several concurrent
requests. I usually run apt update using Fabric framework on many
servers in the same moment and apt-cacher-ng has a trouble with this.
Apt shows that some Release file has invalid signature or some other
problem with index files. I found this errors in error log:


  ns1:/srv/cache/apt-cacher-ng/debrep/dists/bullseye# tail 
/var/log/apt-cacher-ng/apt-cacher.err
  Wed Oct 19 13:47:18 2022|Error creating file item for 
debrep/dists/bullseye-updates/InRelease -- check file permissions!
  Wed Oct 19 13:47:18 2022|Failure to move file 
/srv/cache/apt-cacher-ng/debrep/dists/bullseye-backports/InRelease out of the 
way or cannot create 
/srv/cache/apt-cacher-ng/debrep/dists/bullseye-backports/InRelease.1666180038 - 
errno: File exists
  Wed Oct 19 13:47:18 2022|Error creating file item for 
debrep/dists/bullseye-backports/InRelease -- check file permissions!
  Wed Oct 19 13:47:18 2022|Failure to move file 
/srv/cache/apt-cacher-ng/debsecrep/dists/bullseye-security/InRelease out of the 
way or cannot create 
/srv/cache/apt-cacher-ng/debsecrep/dists/bullseye-security/InRelease.1666180038 
- errno: File exists
  Wed Oct 19 13:47:18 2022|Error creating file item for 
debsecrep/dists/bullseye-security/InRelease -- check file permissions!
  Wed Oct 19 13:47:18 
2022|/srv/cache/apt-cacher-ng/adoptopenjdk/dists/bullseye/InRelease.1666180038 
storage error [Checked size beyond EOF], check file AND directory permissions, 
last errno: File exists
  Wed Oct 19 13:47:18 2022|Failure to move file 
/srv/cache/apt-cacher-ng/debsecrep/dists/bullseye-security/InRelease out of the 
way or cannot create 
/srv/cache/apt-cacher-ng/debsecrep/dists/bullseye-security/InRelease.1666180038 
- errno: File exists
  Wed Oct 19 13:47:18 2022|Error creating file item for 
debsecrep/dists/bullseye-security/InRelease -- check file permissions!
  Wed Oct 19 13:47:18 2022|Failure to move file 
/srv/cache/apt-cacher-ng/debrep/dists/bullseye/InRelease out of the way or 
cannot create 
/srv/cache/apt-cacher-ng/debrep/dists/bullseye/InRelease.1666180038 - errno: 
File exists
  Wed Oct 19 13:47:18 2022|Error creating file item for 
debrep/dists/bullseye/InRelease -- check file permissions!


  ns1:/srv/cache/apt-cacher-ng/debrep/dists/bullseye# ls -la
  total 3684
  drwxr-xr-x  5 apt-cacher-ng apt-cacher-ng   4096 Oct 19 13:47 .
  drwxr-xr-x 15 apt-cacher-ng apt-cacher-ng   4096 Oct 13 18:35 ..
  drwxr-xr-x  5 apt-cacher-ng apt-cacher-ng   4096 Oct 14 06:25 contrib
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 19 13:47 InRelease
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Sep 27 16:49 
InRelease.1664901121
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  4 22:03 
InRelease.1664963050
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  5 11:44 
InRelease.1664967465
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng  32768 Oct 14 06:25 
InRelease.1664967466
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  5 13:07 
InRelease.1664968046
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng  16384 Oct 14 06:25 
InRelease.1664968047
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  5 14:27 
InRelease.1664976362
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  5 15:26 
InRelease.1664987237
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  5 18:27 
InRelease.1665135746
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  7 11:42 
InRelease.1665143341
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  7 14:27 
InRelease.1665146115
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct  7 14:35 
InRelease.1665423845
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng  16384 Oct 14 06:25 
InRelease.1665423846
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 10 19:44 
InRelease.1665917759
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 12:55 
InRelease.1665917760
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 12:56 
InRelease.1665922621
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng  16384 Oct 16 14:17 
InRelease.1665922622
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 14:17 
InRelease.1665937102
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 18:18 
InRelease.1665937103
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 18:18 
InRelease.1665943973
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 20:12 
InRelease.1665943974
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 16 20:12 
InRelease.1666009621
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 17 14:35 
InRelease.1666037442
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 17 22:10 
InRelease.1666037443
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 17 22:55 
InRelease.1666075608
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng 115947 Oct 18 08:46 
InRelease.1666075609
  -rw-r--r--  1 apt-cacher-ng apt-cacher-ng  32768 Oct 18 08:46 
InRelease.16

Bug#1022042: (No Subject)

[Dan Coleman]

Here is a reddit link with information from another user that is experiencing 
the same issue. They've reprinted the errors I referred to in the original bug 
report.

https://www.reddit.com/r/debian/comments/y7t4bv/cant_boot_on_stable_bullseye_after_kernel_update/

Bug#1022042: linux-image-amd64: linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics

[Arndt Kaiser]

Dear Maintainer,

i can confirm the problem.

All of our notebooks with integrated AMD graphics (CPU: AMD Ryzen 7 PRO 
4750U with Radeon Graphics) are affected and don't boot anymore.


During boot the following error-messages appear:

[drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* 
[CRTC:62:crtc-0] flip_done timed out.


[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* 
[CRTC:62:crtc-0] flip_done timed out.


[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* 
[PLANE:52:plane-3] flip_done timed out.



5.10.0-18 boots without problems.


Best Regards,

Arndt Kaiser

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Wed, Oct 19, 2022 at 06:22:05AM +, Doublychargedhiggs wrote:
> Same problem here.  Kernel version 5.10.149-1 (linux-image-5.10.0-19-amd64) 
> hangs on initialisation of amdgpu
> driver, while version 5.10.140-1 (linux-image-5.10.0-18-amd64) boots without 
> any problem.
> 
> According to the changelogs on kernel.org there were several changes to 
> amdgpu in versions 
> 5.10.141, 5.10.143, 5.10.144 5.10.146 and 5.10.148. 
> 
> Some extract from my /var/log/messages just in case it is of any help:
> 
> Oct 19 07:05:24 omikron kernel: [0.00] Linux version 5.10.0-19-amd64 
> (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, 
> GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.149-1 (2022-10-17)
> Oct 19 07:05:24 omikron kernel: [0.00] Command line: 
> BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-amd64 
> root=UUID=28af0276-7bd6-468f-b9c9-c743233a9468 ro quiet mem_encrypt=off 
> snd_hda_intel.power_save=0
> ...
> Oct 19 07:05:24 omikron kernel: [2.325914] [drm] amdgpu kernel 
> modesetting enabled.
> Oct 19 07:05:24 omikron kernel: [2.327288] amdgpu: Topology: Add APU node 
> [0x0:0x0]
> Oct 19 07:05:24 omikron kernel: [2.327398] fb0: switching to amdgpudrmfb 
> from EFI VGA
> Oct 19 07:05:24 omikron kernel: [2.328120] Console: switching to colour 
> dummy device 80x25
> Oct 19 07:05:24 omikron kernel: [2.328366] amdgpu :05:00.0: vgaarb: 
> deactivate vga console
> Oct 19 07:05:24 omikron kernel: [2.328431] amdgpu :05:00.0: enabling 
> device (0006 -> 0007)
> Oct 19 07:05:24 omikron kernel: [2.328516] [drm] initializing kernel 
> modesetting (RAVEN 0x1002:0x15DD 0x1002:0x15DD 0x83).
> Oct 19 07:05:24 omikron kernel: [2.328519] amdgpu :05:00.0: amdgpu: 
> Trusted Memory Zone (TMZ) feature disabled as experimental (default)
> Oct 19 07:05:24 omikron kernel: [2.328536] [drm] register mmio base: 
> 0xFE60
> Oct 19 07:05:24 omikron kernel: [2.328537] [drm] register mmio size: 
> 524288
> Oct 19 07:05:24 omikron kernel: [2.328559] [drm] add ip block number 0 
> 
> Oct 19 07:05:24 omikron kernel: [2.328561] [drm] add ip block number 1 
> 
> Oct 19 07:05:24 omikron kernel: [2.328562] [drm] add ip block number 2 
> 
> Oct 19 07:05:24 omikron kernel: [2.328564] [drm] add ip block number 3 
> 
> Oct 19 07:05:24 omikron kernel: [2.328565] [drm] add ip block number 4 
> 
> Oct 19 07:05:24 omikron kernel: [2.328567] [drm] add ip block number 5 
> 
> Oct 19 07:05:24 omikron kernel: [2.328568] [drm] add ip block number 6 
> 
> Oct 19 07:05:24 omikron kernel: [2.328570] [drm] add ip block number 7 
> 
> Oct 19 07:05:24 omikron kernel: [2.328571] [drm] add ip block number 8 
> 
> Oct 19 07:05:24 omikron kernel: [2.333054] input: HD-Audio Generic 
> HDMI/DP,pcm=3 as 
> /devices/pci:00/:00:08.1/:05:00.1/sound/card0/input6
> Oct 19 07:05:24 omikron kernel: [2.334135] amdgpu :05:00.0: firmware: 
> direct-loading firmware amdgpu/raven_gpu_info.bin
> Oct 19 07:05:24 omikron kernel: [2.334155] amdgpu :05:00.0: amdgpu: 
> Fetched VBIOS from VFCT
> Oct 19 07:05:24 omikron kernel: [2.334157] amdgpu: ATOM BIOS: 
> 113-RAVEN-113
> Oct 19 07:05:24 omikron kernel: [2.334462] amdgpu :05:00.0: firmware: 
> direct-loading firmware amdgpu/raven_sdma.bin
> Oct 19 07:05:24 omikron kernel: [2.334469] [drm] VCN decode is enabled in 
> VM mode
> Oct 19 07:05:24 omikron kernel: [2.334470] [drm] VCN encode is enabled in 
> VM mode
> Oct 19 07:05:24 omikron kernel: [2.334471] [drm] JPEG decode is enabled 
> in VM mode
> Oct 19 07:05:24 omikron kernel: [2.334527] [drm] vm size is 262144 GB, 4 
> levels, block size is 9-bit, fragment size is 9-bit
> Oct 19 07:05:24 omikron kernel: [2.334539] amdgpu :05:00.0: amdgpu: 
> VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used)
> Oct 19 07:05:24 omikron kernel: [2.334541] amdgpu :05:00.0: amdgpu: 
> GART: 1024M 0x - 0x3FFF
> Oct 19 07:05:24 omikron kernel: [2.334543] amdgpu :05:00.0: amdgpu: 
> AGP: 267419648M 0x00F8 - 0x
> Oct 19 07:05:24 omikron kernel: [2.334551] [drm] Detected VRAM RAM=2048M, 
> BAR=2048M
> Oct 19 07:05:24 omikron kernel: [2.334552] [drm] RAM width 128bits DDR4
> Oct 19 07:05:24 omikron kernel: [2.334618] [TTM] Zone  kernel: Available 
> graphics memory: 15381802 KiB
> Oct 19 07:05:24 omikron kernel: [2.334620] [TTM] Zone   dma32: Available 
> graphics memory: 2097152 KiB
> Oct 19 07:05:24 omikron kernel: [2.334621] [TTM] Initializing pool 
> allocator
> Oct 19 07:05:24 omikron kernel: [2.334626] [TTM] Initializing DMA pool 
> allocator
> Oct 19 07:05:24 omikron kernel: [2.334738] [drm] amdgpu: 2048M of VRAM 
> memory ready
> Oct 19 07:05:24 omikron kernel: [2.334741] [drm] amdgpu: 3072M of GTT 
> memory ready.
> Oct 19 07:05:24 omikron ke

Bug#1022044: ITP: pytest-httpserver -- HTTP server for pytest to test HTTP clients

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: pytest-httpserver -- HTTP server for pytest to test HTTP clients
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: pytest-httpserver
  Version : 1.0.6
  Upstream Author : Zsolt Cserna
* URL : https://github.com/csernazs/pytest-httpserver
* License : Expat
  Programming Lang: Python
  Description : HTTP server for pytest to test HTTP clients
 This library is designed to help to test HTTP clients without contacting the
 real HTTP server. In other words, it is a fake HTTP server which is accessible
 via localhost can be started with the pre-defined expected HTTP requests and
 their responses.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/pytest-httpserver

Bug#1022045: fio: New upstream version 3.32 available

[Michael Prokop]

Package: fio
Version: 3.30-1+b1
Severity: wishlist

Hi,

fio v3.32 is available since 2022-08-30, and while the Github
releases for 3.31 + 3.32 mention only "fio Windows installer",
looking at the actual git history, there are some further
changes/fixes.

Would be great to have most current version available for
Debian/bookworm. :)

Thanks for maintaining fio!

regards
-mika-

Bug#1022046: git: CVE-2022-39253 CVE-2022-39260

[Salvatore Bonaccorso]

Source: git
Version: 1:2.30.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:2.37.2-1

Hi,

The following vulnerabilities were published for git.

CVE-2022-39253[0] and CVE-2022-39260[1].

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-39253
https://www.cve.org/CVERecord?id=CVE-2022-39253
[1] https://security-tracker.debian.org/tracker/CVE-2022-39260
https://www.cve.org/CVERecord?id=CVE-2022-39260
[2] https://www.openwall.com/lists/oss-security/2022/10/18/5

Regards,
Salvatore

Bug#1022028: jhead: CVE-2022-41751

[Salvatore Bonaccorso]

Hi Jakub,

On Wed, Oct 19, 2022 at 10:45:22AM +0200, Jakub Wilk wrote:
> * Salvatore Bonaccorso , 2022-10-19 09:53:
> > [1] https://github.com/Matthias-Wandel/jhead/pull/57
> 
> This fix is incomplete:
> https://github.com/Matthias-Wandel/jhead/issues/60

Thanks for having reported  this upstream.

Salvatore

Bug#1022047: /usr/bin/fwupdmgr: Failed to update metadata for lvfs: checksum failure

[Eric Van Buggenhaut]

Package: fwupd
Version: 1.8.6-2+b1
Severity: normal
File: /usr/bin/fwupdmgr
X-Debbugs-Cc: ericv...@gmail.com

# fwupdmgr --force refresh
Updating lvfs
Downloading… [***]
Downloading… [***]
Failed to update metadata for lvfs: checksum failure: failed to verify data, 
expected 20771e784f77cca205b14a2d3aea54658bd1700b

Despite upgrading libjcat1 as mentioned in some forums I still repeatedly get 
this checksum error.

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

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

Versions of packages fwupd depends on:
ii  adduser3.118
ii  libarchive13   3.4.3-2+deb11u1
ii  libc6  2.35-3
ii  libcbor0.8 0.8.0-2+b1
ii  libcurl3-gnutls7.74.0-1.3+deb11u3
ii  libefiboot137-6
ii  libflashrom1   1.2-5
ii  libfwupd2  1.8.6-2+b1
ii  libgcab-1.0-0  1.5-1
ii  libglib2.0-0   2.74.0-3
ii  libgnutls303.7.8-2
ii  libgudev-1.0-0 234-1
ii  libgusb2   0.3.10-1
ii  libjcat1   0.1.9-1
ii  libjson-glib-1.0-0 1.6.2-1
ii  liblzma5   5.2.5-2.1~deb11u1
ii  libmbim-glib4  1.26.4-1
ii  libmbim-proxy  1.26.4-1
ii  libmm-glib01.14.12-0.2
ii  libpolkit-gobject-1-0  0.105-31+deb11u1
ii  libprotobuf-c1 1.3.3-1+b2
ii  libqmi-glib5   1.26.10-0.1
ii  libqmi-proxy   1.26.10-0.1
ii  libsmbios-c2   2.4.3-1
ii  libsqlite3-0   3.34.1-3
ii  libsystemd0247.3-7+deb11u1
ii  libtss2-esys-3.0.2-0   3.0.3-2
ii  libxmlb2   0.3.8-1
ii  shared-mime-info   2.0-1

Versions of packages fwupd recommends:
ii  bolt   0.9.1-1
ii  dbus   1.12.24-0+deb11u1
ii  fwupd-amd64-signed [fwupd-signed]  1:1.2+3
ii  jq 1.6-2.1
ii  python33.9.2-3
pn  secureboot-db  
ii  udisks22.9.2-2+deb11u1

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- no debconf information

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Dan Coleman]

Hi,

I would love to, but I'm afraid I don't know how. If you or anyone on the chain 
is willing to show me what commands to enter (I tried following this 
https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html 
but got as far as 4.2.2 and couldn't find a debian directory in the source that 
I unpacked by following the prior instructions), I would be grateful.

That said, I understand time and resources are limited, so no worries if that's 
not possible!

Best,

Dan

On 10/19/22 07:35 AM, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
>
> Hi,
>
> On Wed, Oct 19, 2022 at 06:22:05AM +, Doublychargedhiggs wrote:
>> Same problem here.  Kernel version 5.10.149-1 (linux-image-5.10.0-19-amd64) 
>> hangs on initialisation of amdgpu
>> driver, while version 5.10.140-1 (linux-image-5.10.0-18-amd64) boots without 
>> any problem.
>>
>> According to the changelogs on kernel.org there were several changes to 
>> amdgpu in versions
>> 5.10.141, 5.10.143, 5.10.144 5.10.146 and 5.10.148.
>>
>> Some extract from my /var/log/messages just in case it is of any help:
>>
>> Oct 19 07:05:24 omikron kernel: [0.00] Linux version 5.10.0-19-amd64 
>> (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, 
>> GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.149-1 
>> (2022-10-17)
>> Oct 19 07:05:24 omikron kernel: [0.00] Command line: 
>> BOOT_IMAGE=/boot/vmlinuz-5.10.0-19-amd64 
>> root=UUID=28af0276-7bd6-468f-b9c9-c743233a9468 ro quiet mem_encrypt=off 
>> snd_hda_intel.power_save=0
>> ...
>> Oct 19 07:05:24 omikron kernel: [2.325914] [drm] amdgpu kernel 
>> modesetting enabled.
>> Oct 19 07:05:24 omikron kernel: [2.327288] amdgpu: Topology: Add APU 
>> node [0x0:0x0]
>> Oct 19 07:05:24 omikron kernel: [2.327398] fb0: switching to amdgpudrmfb 
>> from EFI VGA
>> Oct 19 07:05:24 omikron kernel: [2.328120] Console: switching to colour 
>> dummy device 80x25
>> Oct 19 07:05:24 omikron kernel: [2.328366] amdgpu :05:00.0: vgaarb: 
>> deactivate vga console
>> Oct 19 07:05:24 omikron kernel: [2.328431] amdgpu :05:00.0: enabling 
>> device (0006 -> 0007)
>> Oct 19 07:05:24 omikron kernel: [2.328516] [drm] initializing kernel 
>> modesetting (RAVEN 0x1002:0x15DD 0x1002:0x15DD 0x83).
>> Oct 19 07:05:24 omikron kernel: [2.328519] amdgpu :05:00.0: amdgpu: 
>> Trusted Memory Zone (TMZ) feature disabled as experimental (default)
>> Oct 19 07:05:24 omikron kernel: [2.328536] [drm] register mmio base: 
>> 0xFE60
>> Oct 19 07:05:24 omikron kernel: [2.328537] [drm] register mmio size: 
>> 524288
>> Oct 19 07:05:24 omikron kernel: [2.328559] [drm] add ip block number 0 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328561] [drm] add ip block number 1 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328562] [drm] add ip block number 2 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328564] [drm] add ip block number 3 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328565] [drm] add ip block number 4 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328567] [drm] add ip block number 5 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328568] [drm] add ip block number 6 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328570] [drm] add ip block number 7 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.328571] [drm] add ip block number 8 
>> 
>> Oct 19 07:05:24 omikron kernel: [2.333054] input: HD-Audio Generic 
>> HDMI/DP,pcm=3 as 
>> /devices/pci:00/:00:08.1/:05:00.1/sound/card0/input6
>> Oct 19 07:05:24 omikron kernel: [2.334135] amdgpu :05:00.0: 
>> firmware: direct-loading firmware amdgpu/raven_gpu_info.bin
>> Oct 19 07:05:24 omikron kernel: [2.334155] amdgpu :05:00.0: amdgpu: 
>> Fetched VBIOS from VFCT
>> Oct 19 07:05:24 omikron kernel: [2.334157] amdgpu: ATOM BIOS: 
>> 113-RAVEN-113
>> Oct 19 07:05:24 omikron kernel: [2.334462] amdgpu :05:00.0: 
>> firmware: direct-loading firmware amdgpu/raven_sdma.bin
>> Oct 19 07:05:24 omikron kernel: [2.334469] [drm] VCN decode is enabled 
>> in VM mode
>> Oct 19 07:05:24 omikron kernel: [2.334470] [drm] VCN encode is enabled 
>> in VM mode
>> Oct 19 07:05:24 omikron kernel: [2.334471] [drm] JPEG decode is enabled 
>> in VM mode
>> Oct 19 07:05:24 omikron kernel: [2.334527] [drm] vm size is 262144 GB, 4 
>> levels, block size is 9-bit, fragment size is 9-bit
>> Oct 19 07:05:24 omikron kernel: [2.334539] amdgpu :05:00.0: amdgpu: 
>> VRAM: 2048M 0x00F4 - 0x00F47FFF (2048M used)
>> Oct 19 07:05:24 omikron kernel: [2.334541] amdgpu :05:00.0: amdgpu: 
>> GART: 1024M 0x - 0x3FFF
>> Oct 19 07:05:24 omikron kernel: [2.334543] amdgpu :05:00.0: amdgpu: 
>> AGP: 267419648M 0x00F8 - 0x
>> Oct 19 07:05:24 omikron kernel: [2.334551] [drm] Detected VRAM 
>> RAM=2048M, BAR=2048M
>> Oct 19 07:05:24 omikron kernel: [2.334552] [drm

Bug#1010807: isc-dhcp: ftbfs on riscv64 arch

[Bo YU]

Hi,
On Wed, Oct 19, 2022 at 10:31:38AM +0200, Santiago Ruano Rinc�n wrote:

El 19/10/22 a las 11:29, Paul Wise escribi?:

On Tue, 2022-10-18 at 10:17 +0800, Bo YU wrote:

> Certainly. I have updated the patch with help of Paul Wise.
> But I am not sure I understand it correctly. Yeah, The bind.tar.gz keeps
> itself config.{guess/sub}, so I simply copy these files from system in
> Makefile.

While that is a minimal workaround for the riscv64 FTBFS, I think a
better option would be to unpack bind/bind.tar.gz manually before
dh_update_autotools_config runs and also ensure that dh_autoreconf
rebuilds things in the unpacked bind dir too, something like this:

debian/rules

?? # Ensure that the bind config.guess/config.sub are unpacked first,
?? # otherwise they won't be updated and isc-dhcp will FTBFS on new arches
?? execute_before_dh_update_autotools_config:
cd bind && tar xf bind.tar.gz
??
?? # Ensure that the bind build system gets rebuilt too
?? override_dh_autoreconf:
dh_autoreconf debian/autogen.sh

debian/autogen.sh

?? #!/bin/sh
?? set -x
?? autoreconf -f -i
?? cd bind/bind-*/
?? autoreconf -f -i


Bo Yu, could you please check the attached patch instead? It comes from
Ubuntu, where isc-dhcp seems to build OK.


I can confirm the patch from Ubuntu that fix the issue.





That is still only a workaround; the correct solution to this issue
is that isc-dhcp should link against the bind9 libraries instead of
adding a copy of bind9 to isc-dhcp. This would be more complicated
though and would have to be done upstream not in Debian.


I am afraid that is no longer a possible solution. Please see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942502


OK, maybe we can use the patch from Ubuntu here.

Thanks for all again~



--
Regards,
--
  Bo YU



signature.asc
Description: PGP signature

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Salvatore Bonaccorso]

Hi Dan,

On Wed, Oct 19, 2022 at 12:55:16PM +, Dan Coleman wrote:
> Hi,
> 
> I would love to, but I'm afraid I don't know how. If you or anyone on the 
> chain is willing to show me what commands to enter (I tried following this 
> https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html
>  but got as far as 4.2.2 and couldn't find a debian directory in the source 
> that I unpacked by following the prior instructions), I would be grateful.
> 
> That said, I understand time and resources are limited, so no worries if 
> that's not possible!

When you do fetch the source package the output will look like:

# apt-get source linux
Reading package lists... Done
NOTICE: 'linux' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/kernel-team/linux.git
Please use:
git clone https://salsa.debian.org/kernel-team/linux.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 124 MB of source archives.
Get:1 http://security.debian.org/debian-security bullseye-security/main linux 
5.10.149-1 (dsc) [197 kB]
Get:2 http://security.debian.org/debian-security bullseye-security/main linux 
5.10.149-1 (tar) [122 MB]
Get:3 http://security.debian.org/debian-security bullseye-security/main linux 
5.10.149-1 (diff) [1549 kB]
Fetched 124 MB in 1s (95.7 MB/s)
dpkg-source: info: extracting linux in linux-5.10.149
dpkg-source: info: unpacking linux_5.10.149.orig.tar.xz
dpkg-source: info: unpacking linux_5.10.149-1.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying debian/gitignore.patch
dpkg-source: info: applying 
debian/dfsg/arch-powerpc-platforms-8xx-ucode-disable.patch
[...]
dpkg-source: info: applying 
bugfix/all/tools-perf-pmu-events-fix-reproducibility.patch
dpkg-source: info: applying 
bugfix/all/bpftool-fix-version-string-in-recursive-builds.patch
dpkg-source: info: applying debian/overlayfs-permit-mounts-in-userns.patch

Now you have in the current working directory the linux-5.10.149 directory.

Did you process went that far? If so change into that directory where the 
debian/
directory which will include the debian/bin/test-patches to test-apply the 
patches
we would like to test.

If that will not help I will try to respin a build so anyone affected can test

Hope this helps already,

Regards,
Salvatore

Bug#1022048: patsy: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Source: patsy
Version: 0.5.2-2
Severity: important
Tags: ftbfs fixed-upstream
User: debian-pyt...@lists.debian.org
Usertags: python3.11
Control: affects -1 src:statsmodels

Hi Maintainer

patsy will FTBFS once Python 3.11 is added as a supported version.
I've copied what I hope is the relevant part of the log below.  This
appears to be fixed in the upstream 0.5.3 release.

You can verify this by installing python3.11 from testing or unstable
and adding the following line to debian/rules:
export DEBPYTHON3_SUPPORTED=3.10,3.11

This affects at least statsmodels in dependency level 6 of the Python
3.11 transition (#1021984).

Regards
Graham


 ERRORS 
___ ERROR collecting .pybuild/cpython3_3.11/build/patsy/__init__.py 
patsy/__init__.py:77: in 
import patsy.highlevel
:1178: in _find_and_load
???
:1149: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:168: in exec_module
exec(co, module.__dict__)
patsy/highlevel.py:19: in 
from patsy.design_info import DesignMatrix, DesignInfo
:1178: in _find_and_load
???
:1149: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:168: in exec_module
exec(co, module.__dict__)
patsy/design_info.py:38: in 
from patsy.desc import ModelDesc, Term
:1178: in _find_and_load
???
:1149: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:168: in exec_module
exec(co, module.__dict__)
patsy/desc.py:14: in 
from patsy.eval import EvalEnvironment, EvalFactor
:1178: in _find_and_load
???
:1149: in _find_and_load_unlocked
???
:690: in _load_unlocked
???
/usr/lib/python3/dist-packages/_pytest/assertion/rewrite.py:168: in exec_module
exec(co, module.__dict__)
patsy/eval.py:36: in 
_ALL_FUTURE_FLAGS = _all_future_flags()
patsy/eval.py:32: in _all_future_flags
if feature.getMandatoryRelease() > sys.version_info:
E   TypeError: '>' not supported between instances of 'NoneType' and
'sys.version_info'

Bug#1022049: libnettle8: Illegal instruction on IBM POWER7

[WHR]

Package: libnettle8
Version: 3.8.1-2
Severity: normal
X-Debbugs-Cc: msl023...@gmail.com

Hello.
I think the Debian architecture I'm using (ppc64) should still supporting
POWER7, but apparently this library was built to use instructions unavailable
on POWER7.

gdb(1) output:

Program received signal SIGILL, Illegal instruction.
0x3fffb72bedec in ._nettle_chacha_2core () from 
/usr/lib/powerpc64-linux-gnu/libnettle.so.8
(gdb) disassemble 
Dump of assembler code for function ._nettle_chacha_2core:
   0x3fffb72beda0 <+0>: li  r8,48
   0x3fffb72beda4 <+4>: vspltisw v1,1
   0x3fffb72beda8 <+8>: vspltisw v0,0
   0x3fffb72bedac <+12>:vsldoi  v1,v1,v0,12
   0x3fffb72bedb0 <+16>:lxvw4x  vs35,r8,r4
   0x3fffb72bedb4 <+20>:vaddcuw v7,v3,v1
   0x3fffb72bedb8 <+24>:vsldoi  v7,v7,v7,12
   0x3fffb72bedbc <+28>:vor v7,v7,v1
   0x3fffb72bedc0 <+32>:vadduwm v7,v7,v3
   0x3fffb72bedc4 <+36>:li  r6,16
   0x3fffb72bedc8 <+40>:li  r7,32
   0x3fffb72bedcc <+44>:lxvw4x  vs32,0,r4
   0x3fffb72bedd0 <+48>:lxvw4x  vs33,r6,r4
   0x3fffb72bedd4 <+52>:lxvw4x  vs34,r7,r4
   0x3fffb72bedd8 <+56>:vmr v12,v0
   0x3fffb72beddc <+60>:vmr v13,v1
   0x3fffb72bede0 <+64>:vmr v14,v2
   0x3fffb72bede4 <+68>:vmr v15,v3
   0x3fffb72bede8 <+72>:vmr v16,v7
=> 0x3fffb72bedec <+76>:vmrgow  v4,v0,v0
   0x3fffb72bedf0 <+80>:vmrgew  v0,v0,v0
   0x3fffb72bedf4 <+84>:vmrgow  v5,v1,v1
   0x3fffb72bedf8 <+88>:vmrgew  v1,v1,v1
   0x3fffb72bedfc <+92>:vmrgow  v6,v2,v2
   0x3fffb72bee00 <+96>:vmrgew  v2,v2,v2
   0x3fffb72bee04 <+100>:   vmrgow  v7,v3,v16
   0x3fffb72bee08 <+104>:   vmrgew  v3,v3,v16
   0x3fffb72bee0c <+108>:   vspltisw v8,-16
   0x3fffb72bee10 <+112>:   vspltisw v9,12
   0x3fffb72bee14 <+116>:   vspltisw v10,8
   0x3fffb72bee18 <+120>:   vspltisw v11,7
   0x3fffb72bee1c <+124>:   rldicl  r5,r5,63,1
   0x3fffb72bee20 <+128>:   mtctr   r5
   0x3fffb72bee24 <+132>:   vadduwm v0,v0,v1
--Type  for more, q to quit, c to continue without paging--


lscpu(1) output:

Architecture:ppc64
  CPU op-mode(s):32-bit, 64-bit
  Byte Order:Big Endian
CPU(s):  4
  On-line CPU(s) list:   0-3
Model name:  POWER7 (architected), altivec supported
  Model: 2.3 (pvr 003f 0203)
  Thread(s) per core:4
  Core(s) per socket:1
  Socket(s): 1
Virtualization features: 
  Hypervisor vendor: pHyp
  Virtualization type:   para
Caches (sum of all): 
  L1d:   32 KiB (1 instance)
  L1i:   32 KiB (1 instance)
  L2:256 KiB (1 instance)
  L3:4 MiB (1 instance)
NUMA:
  NUMA node(s):  2
  NUMA node0 CPU(s): 
  NUMA node1 CPU(s): 0-3


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

Kernel: Linux 4.1.42-rivoreo-powerpc64-largepage (SMP w/4 CPU threads)
Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW:zh_CN:zh:en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libnettle8 depends on:
ii  libc6  2.35-3

libnettle8 recommends no packages.

libnettle8 suggests no packages.

-- no debconf information

Bug#1022042: #1022042 linux-image-5.10.0-19-amd64 fails to boot on machines with AMD integrated graphics

[Lloyd Jacobs]

Same problem here, after update my laptop failed to boot after grub. 
Reverted to 5.10.0-18 which works.


Laptop System: ASUSTeK product: VivoBook_ASUSLaptop X415DAP_M415DA v: 1.0

serial:

Mobo: ASUSTeK model: X415DAP v: 1.0 serial: UEFI: American Megatrends

v: X415DAP.308 date: 04/15/2022

AMD Ryzen 3 3250U with Radeon Graphics

Bug#1022050: ukui-control-center: FTBFS on hppa - stub table overflow

[John David Anglin]

Source: ukui-control-center
Version: 3.0.5.1-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

The build fails linking libkeyboard.so:
rm -f libkeyboard.so
g++ -Wl,-O1 -Wl,-rpath-link,/usr/lib/hppa-linux-gnu -shared -o libkeyboard.so 
switchbutton.o hoverwidget.o closebutton.o imageutil.o fixlabel.o iconlabel.o 
titlelabel.o keyboardcontrol.o kbdlayoutmanager.o debug.o geometry_components.o 
geometry_parser.o kbpreviewframe.o keyaliases.o keyboard_config.o 
keyboardlayout.o keyboardpainter.o keysym2ucs.o keysymhelper.o symbol_parser.o 
x11_helper.o xkb_rules.o moc_switchbutton.o moc_hoverwidget.o moc_closebutton.o 
moc_fixlabel.o moc_iconlabel.o moc_titlelabel.o moc_keyboardcontrol.o 
moc_kbdlayoutmanager.o moc_kbpreviewframe.o moc_keyboardpainter.o 
moc_x11_helper.o  -L/usr/lib/hppa-linux-gnu -lX11 -lxkbfile -lmatekbd 
-Wl,--export-dynamic -lgmodule-2.0 -pthread -lgdk-3 -lpangocairo-1.0 
-lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgio-2.0 
-lgobject-2.0 -lglib-2.0 -lxklavier -lgsettings-qt 
/usr/lib/hppa-linux-gnu/libQt5Svg.so /usr/lib/hppa-linux-gnu/libQt5Widgets.so 
/usr/lib/hppa-linux-gnu/libQt5X11Extras.so 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5WindowSystem.so
 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5GuiAddons.so
 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5ConfigGui.so
 /usr/lib/hppa-linux-gnu/libQt5Gui.so /usr/lib/hppa-linux-gnu/libQt5Xml.so 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5CoreAddons.so
 /usr/lib/hppa-linux-gnu/libQt5Concurrent.so 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5ConfigCore.so
 
/usr/lib/hppa-linux-gnu/qt5/mkspecs/modules/../../../../../lib/hppa-linux-gnu/libKF5I18n.so
 /usr/lib/hppa-linux-gnu/libQt5Core.so -lGL -lpthread
g++ -c -pipe -Wno-error -Wdate-time -D_FORTIFY_SOURCE=2 -pthread -Wall -Wextra 
-D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_XML_LIB -DQT_DBUS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I. 
-I../../../../ukui-control-center-3.0.5.1 -I../../../commonComponent 
-I/usr/include/hppa-linux-gnu/qt5/QGSettings -I/usr/include/libmount 
-I/usr/include/blkid -I/usr/include/glib-2.0 
-I/usr/lib/hppa-linux-gnu/glib-2.0/include -I/usr/include/hppa-linux-gnu/qt5 
-I/usr/include/hppa-linux-gnu/qt5/QtWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtGui -I/usr/include/hppa-linux-gnu/qt5/QtXml 
-I/usr/include/hppa-linux-gnu/qt5/QtDBus 
-I/usr/include/hppa-linux-gnu/qt5/QtConcurrent 
-I/usr/include/hppa-linux-gnu/qt5/QtCore -I. -I. 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o moc_fixlabel.o 
moc_fixlabel.cpp
g++ -c -pipe -Wno-error -Wdate-time -D_FORTIFY_SOURCE=2 -std=gnu++11 -Wall 
-Wextra -D_REENTRANT -fPIC -DQT_NO_DEBUG -DQT_PLUGIN -DQT_WIDGETS_LIB 
-DQT_X11EXTRAS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_DBUS_LIB -DQT_CORE_LIB 
-I. -I../../../commonComponent -I../../../../ukui-control-center-3.0.5.1 
-I/usr/include/hppa-linux-gnu/qt5/QGSettings -I/usr/include/hppa-linux-gnu/qt5 
-I/usr/include/hppa-linux-gnu/qt5/QtWidgets 
-I/usr/include/hppa-linux-gnu/qt5/QtX11Extras 
-I/usr/include/hppa-linux-gnu/qt5/QtGui -I/usr/include/KF5/KConfig 
-I/usr/include/KF5/KConfigCore -I/usr/include/KF5/KI18n 
-I/usr/include/hppa-linux-gnu/qt5/QtConcurrent 
-I/usr/include/hppa-linux-gnu/qt5/QtDBus 
-I/usr/include/hppa-linux-gnu/qt5/QtCore -I. -I. 
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o moc_iconlabel.o 
moc_iconlabel.cpp
/usr/bin/ld: 
geometry_parser.o(.text._ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC2ERKSD_RKSI_[_ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC5ERKSD_RKSI_]+0x48):
 cannot reach 
2bb4__ZN5boost6spirit2qi13sequential_orINS_6fusion4consINS1_14literal_stringIRA5_KcLb1EEENS4_IS9_NS3_4nil_EEC1ERKSD_+0,
 recompile with -ffunction-sections
/usr/bin/ld: 
geometry_parser.o(.text._ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC2ERKSD_RKSI_[_ZN5boost6fusion4consINS_6spirit2qi13sequential_orINS1_INS3_14literal_stringIRA5_KcLb1EEENS1_IS9_NS0_4nil_EEENS1_INS3_12literal_charINS2_13char_encoding8standardELb1ELb0EEESA_EEEC5ERKSD_RKSI_]+0x48):
 cannot handle R_PARISC_PCREL17F for 
_ZN5boost6spirit2qi13sequential_orINS_6fusion4consINS1_14literal_stringIRA5_KcLb1EEENS4_IS9_NS3_4nil_EEC1ERKSD_
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status

The failure to handle the R_PARISC_PCREL17F relocation indicates that the
stub table for long call stubs has overflowed.  S

Bug#1022000: ITP: clipper -- Cross-platform clipboard access in Go

[Andrius Merkys]

Hi,

On Wed, 19 Oct 2022 00:12:23 +0530 rajudev  wrote:

* Package name    : clipper


This source package name clashes with already existing clipper package 
in Debian Science.


Andrius

Bug#981285: Please move fdk-aac to main

[fabian]

Hi Jeremy et al.,

On Fri, 3 Jun 2022 16:35:34 -0400 Jeremy Bicha wrote:

Fedora's fdk-aac copy does not include newer AAC features which might
be patent-encumbered.
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/F64JBJI2IZFT2A5QDXGHNMPALCQIVJAX/


honestly, I do not read this from the linked discussion.

With "No other AAC implementations (regardless of copyright license) are 
permitted in Fedora at this time." I am sure they refer to the faac and 
vo-aacenc packages, respectively (the latter of which is in Debian main 
already, BTW).


 - Fabian

Bug#994260: RFS: blop-lv2/1.0.2-1 [ITP] -- Bandlimited LADSPA Oscillator Plugins ported to LV2

[Bastian Germann]

Control: tags -1 - moreinfo

Hi Dennis,

Am 19.10.22 um 15:32 schrieb snd:

Hi Bastian,

sorry for the very late reply. I uploaded a newer version of blop-lv2.
https://mentors.debian.net/package/blop-lv2/

version: 1.0.4-1

Yes, the libs are only available as statically linked .so files.

There are no more 'Jérôme Carretero' copyright notices.
I guess he is an author of waf, and waf has been removed from the new release.


It is almost a year. I do not have the bandwidth currently to look at the 
package again.
But I have reopened the RFS for you.

Thanks,
Bastian

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Dan Coleman]

Hi,

I've built the test kernel successfully, how do I install it? I have the 
following four files.

linux-headers-5.10.0-19-amd64_5.10.149-1a~test_amd64.deb

linux-image-5.10.0-19-amd64-dbg_5.10.149-1a~test_amd64.deb

linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb

linux-image-amd64-dbg_5.10.149-1a~test_amd64.deb

On 10/19/22 08:18 AM, Salvatore Bonaccorso wrote:
> Hi Dan,
>
> On Wed, Oct 19, 2022 at 12:55:16PM +, Dan Coleman wrote:
>> Hi,
>>
>> I would love to, but I'm afraid I don't know how. If you or anyone on the 
>> chain is willing to show me what commands to enter (I tried following 
>> thishttps://www.debian.org/doc/manuals/debian-kernel-handbook/ch-common-tasks.html
>>   but got as far as 4.2.2 and couldn't find a debian directory in the source 
>> that I unpacked by following the prior instructions), I would be grateful.
>>
>> That said, I understand time and resources are limited, so no worries if 
>> that's not possible!
> When you do fetch the source package the output will look like:
>
> # apt-get source linux
> Reading package lists... Done
> NOTICE: 'linux' packaging is maintained in the 'Git' version control system 
> at:
> https://salsa.debian.org/kernel-team/linux.git
> Please use:
> git clonehttps://salsa.debian.org/kernel-team/linux.git
> to retrieve the latest (possibly unreleased) updates to the package.
> Need to get 124 MB of source archives.
> Get:1http://security.debian.org/debian-security  bullseye-security/main linux 
> 5.10.149-1 (dsc) [197 kB]
> Get:2http://security.debian.org/debian-security  bullseye-security/main linux 
> 5.10.149-1 (tar) [122 MB]
> Get:3http://security.debian.org/debian-security  bullseye-security/main linux 
> 5.10.149-1 (diff) [1549 kB]
> Fetched 124 MB in 1s (95.7 MB/s)
> dpkg-source: info: extracting linux in linux-5.10.149
> dpkg-source: info: unpacking linux_5.10.149.orig.tar.xz
> dpkg-source: info: unpacking linux_5.10.149-1.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying debian/gitignore.patch
> dpkg-source: info: applying 
> debian/dfsg/arch-powerpc-platforms-8xx-ucode-disable.patch
> [...]
> dpkg-source: info: applying 
> bugfix/all/tools-perf-pmu-events-fix-reproducibility.patch
> dpkg-source: info: applying 
> bugfix/all/bpftool-fix-version-string-in-recursive-builds.patch
> dpkg-source: info: applying debian/overlayfs-permit-mounts-in-userns.patch
>
> Now you have in the current working directory the linux-5.10.149 directory.
>
> Did you process went that far? If so change into that directory where the 
> debian/
> directory which will include the debian/bin/test-patches to test-apply the 
> patches
> we would like to test.
>
> If that will not help I will try to respin a build so anyone affected can test
>
> Hope this helps already,
>
> Regards,
> Salvatore

Bug#1021874: python-greenlet: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Control: affects -1 + src:sqlalchemy

This can be verified by installing python3.11 from testing or unstable
and adding the following line to debian/rules:
export DEBPYTHON3_SUPPORTED=3.10,3.11

This affects at least sqlalchemy in dependency level 3 of the Python
3.11 transition (#1021984).

Bug#1022051: linux-image-5.10.0-19-amd64: no boot possible

[Michael]

Package: src:linux
Version: 5.10.149-1
Severity: critical
Justification: breaks the whole system

5.10.0-18 works without problems

the problem starts with the error:
[drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* 
[CRTC:62:crtc-0] flip_done timed out

this part of the journal might help:

Okt 19 16:00:16 hiltrup kernel: [ cut here ]
Okt 19 16:00:16 hiltrup kernel: WARNING: CPU: 0 PID: 206 at 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7391 
amdgpu_dm_atomic_commit_tail+0x23af/0x2440 [amdgpu]
Okt 19 16:00:16 hiltrup kernel: Modules linked in: amdgpu(+) gpu_sched 
i2c_algo_bit xhci_pci ttm xhci_hcd nvme ahci drm_kms_helper libahci nvme_core 
usbcore libata r8169 t10_pi crc_t10dif cec realtek crct10dif_generic 
hid_generic mdio_devres drm crct10dif_pclmul crc32_pclmul crc32c_intel scsi_mod 
libphy i2c_piix4 usb_common crct10dif_common i2c_hid wmi battery video hid 
button
Okt 19 16:00:16 hiltrup kernel: CPU: 0 PID: 206 Comm: systemd-udevd Not tainted 
5.10.0-19-amd64 #1 Debian 5.10.149-1
Okt 19 16:00:16 hiltrup kernel: Hardware name: TUXEDO TUXEDO Pulse 14 
Gen1/PULSE1401, BIOS N.1.07.A03 05/11/2021
Okt 19 16:00:16 hiltrup kernel: RIP: 
0010:amdgpu_dm_atomic_commit_tail+0x23af/0x2440 [amdgpu]
Okt 19 16:00:16 hiltrup kernel: Code: a8 fd ff ff 01 c7 85 a4 fd ff ff 37 00 00 
00 c7 85 ac fd ff ff 20 00 00 00 e8 9d 39 13 00 e9 f4 fa ff ff 0f 0b e9 5f f9 
ff ff <0f> 0b e9 af f9 ff ff 0f 0b 0f 0b e9 c6 f9 ff ff 49 8b 06 41 0f b6
Okt 19 16:00:16 hiltrup kernel: RSP: 0018:b2538077b3e0 EFLAGS: 00010002
Okt 19 16:00:16 hiltrup kernel: RAX: 0002 RBX: 0997 
RCX: 99ba40b62918
Okt 19 16:00:16 hiltrup kernel: RDX: 0001 RSI: 0297 
RDI: 99bac8a20188
Okt 19 16:00:16 hiltrup kernel: RBP: b2538077b6d8 R08: 0005 
R09: 
Okt 19 16:00:16 hiltrup kernel: R10: b2538077b340 R11: b2538077b344 
R12: 0297
Okt 19 16:00:16 hiltrup kernel: R13: 99ba40b62800 R14: 99c7f625c000 
R15: 99bac8cd1780
Okt 19 16:00:16 hiltrup kernel: FS:  7fea294bb8c0() 
GS:99c90f60() knlGS:
Okt 19 16:00:16 hiltrup kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Okt 19 16:00:16 hiltrup kernel: CR2: 7fea29a4e8cc CR3: 00010bf22000 
CR4: 00350ef0
Okt 19 16:00:16 hiltrup kernel: Call Trace:
Okt 19 16:00:16 hiltrup kernel:  ? __switch_to+0x114/0x460
Okt 19 16:00:16 hiltrup kernel:  commit_tail+0x94/0x130 [drm_kms_helper]
Okt 19 16:00:16 hiltrup kernel:  drm_atomic_helper_commit+0x11b/0x140 
[drm_kms_helper]
Okt 19 16:00:16 hiltrup kernel:  drm_client_modeset_commit_atomic+0x1e8/0x230 
[drm]
Okt 19 16:00:16 hiltrup kernel:  drm_client_modeset_commit_locked+0x56/0x160 
[drm]
Okt 19 16:00:16 hiltrup kernel:  drm_fb_helper_pan_display+0xdc/0x210 
[drm_kms_helper]
Okt 19 16:00:16 hiltrup kernel:  fb_pan_display+0x87/0x110
Okt 19 16:00:16 hiltrup kernel:  bit_update_start+0x1a/0x40
Okt 19 16:00:16 hiltrup kernel:  fbcon_switch+0x31c/0x490
Okt 19 16:00:16 hiltrup kernel:  redraw_screen+0xe5/0x250
Okt 19 16:00:16 hiltrup kernel:  do_bind_con_driver.isra.0.cold+0xad/0x103
Okt 19 16:00:16 hiltrup kernel:  do_take_over_console+0x116/0x190
Okt 19 16:00:16 hiltrup kernel:  do_fbcon_takeover+0x5c/0xc0
Okt 19 16:00:16 hiltrup kernel:  register_framebuffer+0x1e4/0x300
Okt 19 16:00:16 hiltrup kernel:  
__drm_fb_helper_initial_config_and_unlock+0x321/0x4a0 [drm_kms_helper]
Okt 19 16:00:16 hiltrup kernel:  amdgpu_fbdev_init+0xbd/0x100 [amdgpu]
Okt 19 16:00:16 hiltrup kernel:  amdgpu_device_init.cold+0x1740/0x1a8e [amdgpu]
Okt 19 16:00:16 hiltrup kernel:  ? pci_conf1_read+0xa4/0x100
Okt 19 16:00:16 hiltrup kernel:  ? pci_bus_read_config_word+0x49/0x70
Okt 19 16:00:16 hiltrup kernel:  amdgpu_driver_load_kms+0x2b/0x1f0 [amdgpu]
Okt 19 16:00:16 hiltrup kernel:  amdgpu_pci_probe+0x187/0x210 [amdgpu]
Okt 19 16:00:16 hiltrup kernel:  local_pci_probe+0x42/0x80
Okt 19 16:00:16 hiltrup kernel:  ? _cond_resched+0x16/0x50
Okt 19 16:00:16 hiltrup kernel:  pci_device_probe+0x101/0x1b0
Okt 19 16:00:16 hiltrup kernel:  really_probe+0x222/0x480
Okt 19 16:00:16 hiltrup kernel:  driver_probe_device+0xe5/0x150
Okt 19 16:00:16 hiltrup kernel:  device_driver_attach+0xa9/0xb0
Okt 19 16:00:16 hiltrup kernel:  __driver_attach+0xb5/0x170
Okt 19 16:00:16 hiltrup kernel:  ? device_driver_attach+0xb0/0xb0
Okt 19 16:00:16 hiltrup kernel:  ? device_driver_attach+0xb0/0xb0
Okt 19 16:00:16 hiltrup kernel:  bus_for_each_dev+0x78/0xc0
Okt 19 16:00:16 hiltrup kernel:  bus_add_driver+0x13a/0x200
Okt 19 16:00:16 hiltrup kernel:  driver_register+0x8b/0xe0
Okt 19 16:00:16 hiltrup kernel:  ? 0xc0cf9000
Okt 19 16:00:16 hiltrup kernel:  do_one_initcall+0x44/0x1d0
Okt 19 16:00:16 hiltrup kernel:  ? do_init_module+0x23/0x250
Okt 19 16:00:16 hiltrup kernel:  ? kmem_cache_alloc_trace+0xf5/0x200
Okt 19 16:00:16 hiltrup kernel:  do_init_module+0x4c/0x250
Okt 19 16:00:16 hiltrup kernel: 

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Diederik de Haas]

On Wednesday, 19 October 2022 16:12:22 CEST Dan Coleman wrote:
> I've built the test kernel successfully, how do I install it? I have the
> following four files.
> 
> linux-headers-5.10.0-19-amd64_5.10.149-1a~test_amd64.deb
> linux-image-5.10.0-19-amd64-dbg_5.10.149-1a~test_amd64.deb
> linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb
> linux-image-amd64-dbg_5.10.149-1a~test_amd64.deb

# = do as root or with 'sudo'

# dpkg -i linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb

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

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Dan Coleman]

$ sudo dpkg -i ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb
dpkg: considering removing linux-image-5.10.0-19-amd64 in favour of 
linux-image-5.10.0-19-amd64-unsigned ...
dpkg: no, cannot proceed with removal of linux-image-5.10.0-19-amd64 
(--auto-deconfigure will help):
  linux-image-amd64 depends on linux-image-5.10.0-19-amd64 (= 5.10.149-1)
   linux-image-5.10.0-19-amd64 is to be removed.

dpkg: regarding 
.../linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb containing 
linux-image-5.10.0-19-amd64-unsigned:
  linux-image-5.10.0-19-amd64-unsigned conflicts with 
linux-image-5.10.0-19-amd64
   linux-image-5.10.0-19-amd64 (version 5.10.149-1) is present and installed.

dpkg: error processing archive 
./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb (--install):
  conflicting packages - not installing linux-image-5.10.0-19-amd64-unsigned
Errors were encountered while processing:
  ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb

On 10/19/22 09:32 AM, Diederik de Haas wrote:
> On Wednesday, 19 October 2022 16:12:22 CEST Dan Coleman wrote:
>> I've built the test kernel successfully, how do I install it? I have the
>> following four files.
>>
>> linux-headers-5.10.0-19-amd64_5.10.149-1a~test_amd64.deb
>> linux-image-5.10.0-19-amd64-dbg_5.10.149-1a~test_amd64.deb
>> linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb
>> linux-image-amd64-dbg_5.10.149-1a~test_amd64.deb
> # = do as root or with 'sudo'
>
> # dpkg -i linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb

Bug#994260: RFS: blop-lv2/1.0.2-1 [ITP] -- Bandlimited LADSPA Oscillator Plugins ported to LV2

[snd]

Hi Bastian,

sorry for the very late reply. I uploaded a newer version of blop-lv2.
https://mentors.debian.net/package/blop-lv2/

version: 1.0.4-1

Yes, the libs are only available as statically linked .so files.

There are no more 'Jérôme Carretero' copyright notices.
I guess he is an author of waf, and waf has been removed from the new 
release.


Best,
Dennis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022052: whiptail 0.52.21-6: fails with output: "free(): invalid pointer"

[Steven Shiau]

Package: whiptail
Version: 0.52.21-6
Severity: normal

Dear Maintainer,

   * What led up to the situation?
 After doing a system update in my Sid box today, the whiptail 
fails with output: "free(): invalid pointer"


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Run the following in the command line as a normal user:
 whiptail --backtitle 'backtitle' --title 'testing' --menu 
'Choose:' 0 0 0 A 'A' B 'B' C 'C'

 Choose either A, B, or C then press Enter.

   * What was the outcome of this action?
 free(): invalid pointer
 Aborted

   * What outcome did you expect instead?
 Either A, B, or C is shown in the command line.

 This issue is almost the same with this bug report, just the 
whiptail is newer, and libpopt0 is newer (version 1.19+dfsg-1):

 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942557
 Not sure if culprit is still libpopt0?

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

Kernel: Linux 6.0.0-1-amd64 (SMP w/6 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 not set

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

Versions of packages whiptail depends on:
ii  libc6    2.35-3
ii  libnewt0.52  0.52.21-6
ii  libpopt0 1.19+dfsg-1
ii  libslang2    2.3.3-2

whiptail recommends no packages.

whiptail suggests no packages.

-- no debconf information

--
Steven Shiau 
Public Key Server PGP Key ID: 4096R/163E3FB0
Fingerprint: EB1D D5BF 6F88 820B BCF5  356C 8E94 C9CD 163E 3FB0

Bug#1022053: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-djinn-ghc
Version: 0.0.2.3-10
Severity: serious

I intend to remove this package:

  * It has no rev dependencies
  * The current version FTBFS
  * Seems unmaintained; Last upload more than 5 years ago
  * It's not part of the latest Stackage LTS

If you believe we should keep this package in Debian, please close this
bug report.

-- 
Ilias

Bug#1022054: Add multiarch metadata to dh-cmake

[Graemer Tobias LCPF-CH]

Package: dh-cmake
Version: 0.6.1

Dear Maintainer,

We are working on getting multiarch metadata correct throught the archive. This
package needs to be marked 'Multi-Arch: foreign' for dependencies and build-
depencies to work correctly in all cases.

Any package 'X' build-depending on dh-cmake cannot be cross-built because apt-
get build-dep -a cannot satisfy X's build-dependencies until

Multi-Arch: foreign

is added to dh-cmake's control file, to indicate that dh-cmake from any
available arch will satisfy the dependency.

See http://wiki.debian.org/Multiarch/CrossDependencies and
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
in the Multiarch Spec for further explanation.

Bug#1022051: linux-image-5.10.0-19-amd64: no boot possible

[Hanno Hecker]

Package: src:linux
Version: 5.10.149-1
Followup-For: Bug #1022051

Same issue here, similar system

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: BESSTAR TECH LIMITED
product_name: HM80
product_version: Default string
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 5.16
board_vendor: BESSTAR TECH LIMITED
board_name: HM80
board_version: Default string

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir Root 
Complex [1022:1630]
Subsystem: Advanced Micro Devices, Inc. [AMD] Renoir Root Complex 
[1022:1630]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:01.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP 
Bridge [1022:1634] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP 
Bridge [1022:1634] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.3 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe GPP 
Bridge [1022:1634] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Renoir PCIe 
Dummy Host Bridge [1022:1632]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Renoir Internal 
PCIe GPP Bridge to Bus [1022:1635] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 51)
Subsystem: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: nvme
Kernel modules: nvme

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. 
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
DeviceName: Onboard LAN Brodcom
Subsystem: Realtek Semiconductor Co., Ltd. RTL

Bug#1017076: Please send complete log.

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 moreinfo unreproducible

Hi! I'm pretty sure this is working, so please send a **complete** log
on how you are trying to install the package. basically all the output
of (as root):

apt update
apt install qt6-base-dev

Thanks!

-- 
Lisandro Damián Nicanor Pérez Meyer
https://perezmeyer.com.ar/

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Diederik de Haas]

On Wednesday, 19 October 2022 16:34:49 CEST Dan Coleman wrote:
> $ sudo dpkg -i
> ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb dpkg:
> considering removing linux-image-5.10.0-19-amd64 in favour of
> linux-image-5.10.0-19-amd64-unsigned ... dpkg: no, cannot proceed with
> removal of linux-image-5.10.0-19-amd64 (--auto-deconfigure will help):
> linux-image-amd64 depends on linux-image-5.10.0-19-amd64 (= 5.10.149-1)
> linux-image-5.10.0-19-amd64 is to be removed.

AFAICT, the last line indicates the problem.
I do know how I would resolve it on my system and if my initial attempt fails 
how to fix that, but I don't feel comfortable suggesting that to you.

So, I'll let Salvatore take over as he's (WAY) more experienced then I am.

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

Bug#1022055: ITP: prometheus-ui-classic -- classic web user interface for Prometheus

[Daniel Swarbrick]

Package: wnpp
Severity: wishlist
Owner: Daniel Swarbrick 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: prometheus-ui-classic
  Version : 2.33.5+ds-1
  Upstream Author : The Prometheus Authors
* URL : https://prometheus.io/
* License : Apache-2.0, Expat
  Programming Lang: JavaScript
  Description : classic web user interface for Prometheus

This package contains the classic web UI for Prometheus, which shipped
with versions up until 2.33.5, after which it was removed upstream.
Splitting out the classic UI from the last Prometheus version to include
it was necessary due to the new React UI being prohibitively complex to
package (without violating Debian policy).

This package will effectively be frozen in time at version 2.33.5, until
such time that the React UI can be included in the prometheus package.
It is unlikely that the prometheus-ui-classic package will need any
updating, so long as Prometheus provides the v1 API.

Bug#1022056: gdb: Cannot return a specified value from a shared library function using the 'return' command

[WHR]

Package: gdb
Version: 12.1-4
Severity: minor
X-Debbugs-Cc: msl023...@gmail.com


Hello.
The issue happens when I specific a return value to the 'return' command in
gdb(1), in order to return from a shared library function with my specified
return value.

The following example uses function geteuid(2) from libc.so.6:

root@debian:~/src# cat rval-test.c
#include 
#include 

int main() {
while(1) {
printf("geteuid returned %u\n", (unsigned 
int)geteuid());
sleep(1);
}
}
root@debian:~/src# gcc -Wall -g rval-test.c -o rval-test   
root@debian:~/src# gdb rval-test 
GNU gdb (Debian 12.1-4) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64le-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from rval-test...
(gdb) b geteuid
Breakpoint 1 at 0x960
(gdb) r
Starting program: /root/src/rval-test 
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x77e12ea0 in __GI_geteuid () at 
../sysdeps/unix/syscall-template.S:91
91  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) c
Continuing.
geteuid returned 0

Breakpoint 1, 0x77e12ea0 in __GI_geteuid () at 
../sysdeps/unix/syscall-template.S:91
91  in ../sysdeps/unix/syscall-template.S
(gdb) return 11
Make __GI_geteuid return now? (y or n) y
#0  0x000108dc in main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) c
Continuing.
geteuid returned 0

Breakpoint 1, 0x77e12ea0 in __GI_geteuid () at 
../sysdeps/unix/syscall-template.S:91
91  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) return (uint32_t)11
Make __GI_geteuid return now? (y or n) y
#0  0x000108dc in main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) c
Continuing.
geteuid returned 0


As shown in this example, I'm trying to make this function to return 11
instead, but this didn't work.

Manually changing the register for return value (r3) worked:

Breakpoint 1, 0x77e12ea0 in __GI_geteuid () at 
../sysdeps/unix/syscall-template.S:91
91  ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) p $r3
$1 = 0
(gdb) p $r3 = (uint32_t)11
$2 = 11
(gdb) return
Make __GI_geteuid return now? (y or n) y
#0  0x000108dc in main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) c
Continuing.
geteuid returned 11
...


So this method could be used as a workaround.


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

Kernel: Linux 5.4.0-113-generic (SMP w/128 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_TW:zh_CN:en_GB:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages gdb depends on:
ii  libbabeltrace1  1.5.8-2+b2
ii  libc6   2.35-3
ii  libdebuginfod1  0.187-1
ii  libexpat1   2.4.8-1
ii  libgcc-s1   12.1.0-7
ii  libgmp102:6.2.1+dfsg1-1
ii  liblzma55.2.5-2.1
ii  libmpfr64.1.0-3
ii  libncursesw66.3+20220423-2
ii  libpython3.10   3.10.5-1
ii  libreadline88.1.2-1.2
ii  libsource-highlight4v5  3.1.9-4.1+b1
ii  libstdc++6  12.1.0-7
ii  libtinfo6   6.3+20220423-2
ii  libxxhash0  0.8.1-1
ii  zlib1g  1:1.2.11.dfsg-4

Versions of packages gdb recommends:
ii  libc6-dbg

Bug#1022057: ITP: seqan-raptor -- pre-filter for querying very large collections of nucleotide sequences

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: cru...@debian.org

Subject: ITP: seqan-raptor -- pre-filter for querying very large collections of 
nucleotide sequences
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: seqan-raptor
  Version : 2.0.0.0.git.fecfbca+ds
  Upstream Author : Enrico Seiler
* URL : https://github.com/seqan/raptor
* License : BSD-3-clause
  Programming Lang: C
  Description : pre-filter for querying very large collections of 
nucleotide sequences
 Raptor is a system for approximately searching many queries such as
 next-generation sequencing reads or transcripts in large collections of
 nucleotide sequences. Raptor uses winnowing minimizers to define a set of
 representative k-mers, an extension of the interleaved Bloom filters (IBFs) as
 a set membership data structure and probabilistic thresholding for minimizers.
 Our approach allows compression and partitioning of the IBF to enable the
 effective use of secondary memory. We test and show the performance and
 limitations of the new features using simulated and real datasets. Our data
 structure can be used to accelerate various core bioinformatics applications.

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

Bug#1022051: linux-image-5.10.0-19-amd64: no boot possible

[Diederik de Haas]

Control: severity -1 important
Control: merge -1 1022025

On Wednesday, 19 October 2022 16:28:10 CEST Michael wrote:
> Package: src:linux
> Version: 5.10.149-1
> Severity: critical

This is the same issue as https://bugs.debian.org/1022025, thus merging

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

Bug#1022059: netctl: ifplugd integration does not work

[Helmut Grohne]

Package: netctl
Version: 1.24-1.1
Tags: patch

Hi,

the netctl-ifplugd@.service does not work at all. The first issue is
that it refers to /usr/bin/ifplugd, but it's installed as
/usr/sbin/ifplugd on Debian. Next, the target action
/etc/ifplugd/netctl.action does not exist as it was moved by
debian/rules. Likely, it should be updated to
/etc/ifplugd/ifplugd.action. I'm attaching a patch for your convenience.

Helmut
diff -Nru netctl-1.24/debian/changelog netctl-1.24/debian/changelog
--- netctl-1.24/debian/changelog2022-10-15 12:26:07.0 +0200
+++ netctl-1.24/debian/changelog2022-10-19 17:03:16.0 +0200
@@ -1,3 +1,12 @@
+netctl (1.24-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ifplugd integration: (Closes: #-1)
++ Debian's ifplugd is installed to /usr/sbin.
++ After moving netctl.action, adapt path passed to ifplugd.
+
+ -- Helmut Grohne   Wed, 19 Oct 2022 17:03:16 +0200
+
 netctl (1.24-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru netctl-1.24/debian/rules netctl-1.24/debian/rules
--- netctl-1.24/debian/rules2021-01-04 17:09:51.0 +0100
+++ netctl-1.24/debian/rules2022-10-19 17:03:16.0 +0200
@@ -14,5 +14,9 @@
mv debian/netctl/etc/netctl/examples debian/netctl/usr/share/netctl/
mkdir debian/netctl/etc/ifplugd/action.d/
mv debian/netctl/etc/ifplugd/netctl.action 
debian/netctl/etc/ifplugd/action.d/netctl
+   sed -i \
+   -e 's,/etc/ifplugd/netctl\.action,/etc/ifplugd/ifplugd.action,' 
\
+   -e 's,/usr/bin/ifplugd,/usr/sbin/ifplugd,' \
+   debian/netctl/lib/systemd/system/netctl-ifplugd@.service
mv debian/netctl/usr/lib/netctl/connections/README 
debian/netctl/usr/share/netctl/README.connections
mv debian/netctl/usr/lib/netctl/dhcp/README 
debian/netctl/usr/share/netctl/README.dhcp

Bug#1022058: spirv-headers: Please upgrade to spirv-headers >=1.3.224

[Christopher Obbard]

Package: spirv-headers
Version: 1.6.1+1.3.216.0-1
Severity: normal

Dear Maintainer,

mesa 22.3 in debian-experimental FTBFS with the following tests
failing:

Failed Tests (4):
LLVM_SPIRV :: transcoding/AtomicFMaxEXT.ll
LLVM_SPIRV :: transcoding/AtomicFMaxEXTForOCL.ll
LLVM_SPIRV :: transcoding/AtomicFMinEXT.ll
LLVM_SPIRV :: transcoding/AtomicFMinEXTForOCL.ll

Turns out we need to bump spirv-headers to >= 1.3.224 and make
sure llvm-spirv-translator gets built against that.

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Salvatore Bonaccorso]

Hi Dan, hi Diederik

On Wed, Oct 19, 2022 at 05:09:01PM +0200, Diederik de Haas wrote:
> On Wednesday, 19 October 2022 16:34:49 CEST Dan Coleman wrote:
> > $ sudo dpkg -i
> > ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb dpkg:
> > considering removing linux-image-5.10.0-19-amd64 in favour of
> > linux-image-5.10.0-19-amd64-unsigned ... dpkg: no, cannot proceed with
> > removal of linux-image-5.10.0-19-amd64 (--auto-deconfigure will help):
> > linux-image-amd64 depends on linux-image-5.10.0-19-amd64 (= 5.10.149-1)
> > linux-image-5.10.0-19-amd64 is to be removed.
> 
> AFAICT, the last line indicates the problem.
> I do know how I would resolve it on my system and if my initial attempt fails 
> how to fix that, but I don't feel comfortable suggesting that to you.
> 
> So, I'll let Salvatore take over as he's (WAY) more experienced then I am.

You need to have (temporarily at least) removed the signed package
indeed, as they are conflicting. If you do it with apt-get install
./path/to/local/package.deb all the surronding work should be done as
well.

(And you have the 18 ABI kernel still installed to which you can go
back if th test package does no work).

After testing, make sure to reinstall the linux-image-amd64 package
again.

Regards,
Salvatore

Bug#1021938: kalarm: .local/share/kalarm/expired.ics is not a valid iCalendar file

[Igor A. Shmakov]

Package: kalarm
Version: 4:22.08.0-2
Severity: normal

I can confirm bugs №1021938 exist in testing system.
I deleted all the files with the .ics extension, and then recreated them 
again.

After restarting the program, I received an error message.

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 kalarm depends on:
ii  akonadi-server 4:22.08.0-2
ii  kdepim-runtime 4:22.08.0-2
ii  kio 5.98.0-1
ii  libc6 2.35-3
ii  libgcc-s1 12.2.0-3
ii  libkf5akonadicontact5 [libkf5akonadicontact5-22.08] 4:22.08.0-2
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-22.08] 4:22.08.0-2
ii  libkf5akonadimime5 [libkf5akonadimime5-22.08] 4:22.08.0-2
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-22.08] 4:22.08.0-2
ii  libkf5authcore5 5.98.0-1
ii  libkf5calendarcore5abi2 5:5.98.0-1
ii  libkf5calendarutils5 [libkf5calendarutils5-22.08] 4:22.08.0-2
ii  libkf5codecs5 5.98.0-1
ii  libkf5completion5 5.98.0-1
ii  libkf5configcore5 5.98.0-1
ii  libkf5configgui5 5.98.0-1
ii  libkf5configwidgets5 5.98.0-1
ii  libkf5contacts5 5:5.98.0-1
ii  libkf5coreaddons5 5.98.0-1
ii  libkf5crash5 5.98.0-1
ii  libkf5dbusaddons5 5.98.0-1
ii  libkf5globalaccel-bin 5.98.0-1
ii  libkf5globalaccel5 5.98.0-1
ii  libkf5guiaddons5 5.98.0-2
ii  libkf5holidays5 1:5.98.0-1
ii  libkf5i18n5 5.98.0-1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-22.08] 22.08.0-2
ii  libkf5identitymanagementwidgets5 [libkf5identitymanagementwi 22.08.0-2
ii  libkf5idletime5 5.98.0-1
ii  libkf5itemmodels5 5.98.0-1
ii  libkf5jobwidgets5 5.98.0-1
ii  libkf5kiocore5 5.98.0-1
ii  libkf5kiofilewidgets5 5.98.0-1
ii  libkf5kiowidgets5 5.98.0-1
ii  libkf5mailtransport5 [libkf5mailtransport5-22.08] 22.08.0-2
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-22. 22.08.0-2
ii  libkf5mime5abi1 [libkf5mime5-22.08] 22.08.0-2
ii  libkf5notifications5 5.98.0-1
ii  libkf5notifyconfig5 5.98.0-1
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-22.08] 22.08.0-2
ii  libkf5textwidgets5 5.98.0-1
ii  libkf5widgetsaddons5 5.98.0-1
ii  libkf5windowsystem5 5.98.0-1
ii  libkf5xmlgui5 5.98.0-1
ii  libphonon4qt5-4 4:4.11.1-4
ii  libqt5core5a 5.15.4+dfsg-5
ii  libqt5dbus5 5.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5network5 5.15.4+dfsg-5
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libqt5x11extras5 5.15.4-2
ii  libstdc++6 12.2.0-3
ii  phonon4qt5 4:4.11.1-4

kalarm recommends no packages.

kalarm suggests no packages.

-- no debconf information

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Dan Coleman]

Ok, I think I succeeded in getting the test kernel to install, but it did not 
solve the issue. The fans ramped up a bit, and I didn't get any errors about 
DRM on the console, but it still hung on the black screen.

Of course, I may have royally screwed up installing the kernel (thank goodness 
for Timeshift), so I welcome another, more experienced tester to verify my own 
findings.

On 10/19/22 10:26 AM, Salvatore Bonaccorso wrote:
> Hi Dan, hi Diederik
>
> On Wed, Oct 19, 2022 at 05:09:01PM +0200, Diederik de Haas wrote:
>> On Wednesday, 19 October 2022 16:34:49 CEST Dan Coleman wrote:
>>> $ sudo dpkg -i
>>> ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb dpkg:
>>> considering removing linux-image-5.10.0-19-amd64 in favour of
>>> linux-image-5.10.0-19-amd64-unsigned ... dpkg: no, cannot proceed with
>>> removal of linux-image-5.10.0-19-amd64 (--auto-deconfigure will help):
>>> linux-image-amd64 depends on linux-image-5.10.0-19-amd64 (= 5.10.149-1)
>>> linux-image-5.10.0-19-amd64 is to be removed.
>> AFAICT, the last line indicates the problem.
>> I do know how I would resolve it on my system and if my initial attempt fails
>> how to fix that, but I don't feel comfortable suggesting that to you.
>>
>> So, I'll let Salvatore take over as he's (WAY) more experienced then I am.
> You need to have (temporarily at least) removed the signed package
> indeed, as they are conflicting. If you do it with apt-get install
> ./path/to/local/package.deb all the surronding work should be done as
> well.
>
> (And you have the 18 ABI kernel still installed to which you can go
> back if th test package does no work).
>
> After testing, make sure to reinstall the linux-image-amd64 package
> again.
>
> Regards,
> Salvatore

Bug#1022060: gnome-shell: Prolonged use lets one core have >90% CPU usage for a few minutes

[Krassy Boykinov]

Package: gnome-shell
Version: 43.0-2
Severity: important

After updating my gnome-shell to 43 i have noticed
repeated "freezes" in wich gnome-shell takes one CPU core up to
100% CPU usage for some minutes. Closing gnome-terminal and reopening
it fixes the problem temporarily (for one to two hours or so). The bug
was also present before the upgrade to the latest kernel.

From /var/log/dpkg.log:
2022-10-02 22:04:32 upgrade gnome-shell:amd64 42.4-2 43.0-2

From /var/log/syslog: (only gnome-shell related, from freeze onwards)
Oct 19 15:10:37 computer systemd[2186]: Started Application launched by 
gnome-shell.
Oct 19 15:10:37 computer gnome-shell[2364]: 
meta_window_set_stack_position_no_sync: assertion 
'window->stack_position >= 0' failed
Oct 19 15:11:18 computer dbus-daemon[2215]: [session uid=1000 pid=2215] 
Activating service name='org.gnome.Settings.SearchProvider' requested by 
':1.36' (uid=1000 pid=2364 comm="/usr/bin/gnome-shell")
Oct 19 15:11:18 computer dbus-daemon[2215]: [session uid=1000 pid=2215] 
Activating service name='org.gnome.Contacts.SearchProvider' requested by 
':1.36' (uid=1000 pid=2364 comm="/usr/bin/gnome-shell")
Oct 19 15:11:18 computer dbus-daemon[2215]: [session uid=1000 pid=2215] 
Activating service name='org.gnome.seahorse.Application' requested by 
':1.36' (uid=1000 pid=2364 comm="/usr/bin/gnome-shell")
Oct 19 15:11:18 computer dbus-daemon[2215]: [session uid=1000 pid=2215] 
Activating service name='org.gnome.Calculator.SearchProvider' requested 
by ':1.36' (uid=1000 pid=2364 comm="/usr/bin/gnome-shell")
Oct 19 15:11:18 computer dbus-daemon[2215]: [session uid=1000 pid=2215] 
Activating service name='org.gnome.clocks' requested by ':1.36' 
(uid=1000 pid=2364 comm="/usr/bin/gnome-shell")
Oct 19 15:11:18 computer dbus-daemon[2215]: [session uid=1000 pid=2215] 
Activating service name='org.gnome.Characters' requested by ':1.36' 
(uid=1000 pid=2364 comm="/usr/bin/gnome-shell")
Oct 19 15:11:18 computer gnome-shell[2364]: Received error from D-Bus 
search provider org.gnome.Terminal.desktop: Gio.DBusError: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Das Objekt 
existiert nicht am Pfad »/org/gnome/Terminal/SearchProvider«
Oct 19 15:11:18 computer gnome-shell[2364]: Received error from D-Bus 
search provider org.gnome.Terminal.desktop: Gio.DBusError: 
GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Das Objekt 
existiert nicht am Pfad »/org/gnome/Terminal/SearchProvider«
Oct 19 15:16:54 computer gnome-shell[2364]: Window manager warning: 
last_focus_time (10217970) is greater than comparison timestamp 
(10217967).  This most likely represents a buggy client sending 
inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to 
work around...
Oct 19 15:20:35 computer gnome-shell[2364]: Window manager warning: 
last_user_time (10438967) is greater than comparison timestamp 
(10438959).  This most likely represents a buggy client sending 
inaccurate timestamps in messages such as _NET_ACTIVE_WINDOW.  Trying to 
work around...
Oct 19 15:20:35 computer gnome-shell[2364]: Window manager warning: W111 
appears to be one of the offending windows with a timestamp of 10438967. 
 Working around...



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

Kernel: Linux 6.0.0-1-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-accountsservice-1.0   22.08.8-1+b1
ii  gir1.2-adw-1 1.2.0-1
ii  gir1.2-atk-1.0   2.46.0-3
ii  gir1.2-atspi-2.0 2.46.0-3
ii  gir1.2-freedesktop   1.74.0-2
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.9+dfsg-1
ii  gir1.2-gdm-1.0   43.0-1
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-2
ii  gir1.2-gnomebluetooth-3.042.4-1
ii  gir1.2-gnomedesktop-3.0  43-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.3-1
ii  gir1.2-gtk-3.0   3.24.34-3
ii  gir1.2-gtk-4.0   4.8.1+ds-1
ii  gir1.2-gweather-4.0  4.2.0-1
ii  gir1.2-ibus-1.0  1.5.27-2+b1
ii  gir1.2-mutter-11 43.0-3
ii  gir1.2-nm-1.01.40.2-1
ii  gir1.2-nma-1.0   1.10.2

Bug#1022061: debian-kernel-handbook: improve kernel build steps for newbies

[Diederik de Haas]

Package: debian-kernel-handbook
Version: 1.0.20
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

In https://bugs.debian.org/1022025#37 I saw another example of someone
who hadn't built a kernel before, found the proper instructions but
didn't succeed in building a (patched) kernel.

All it took to succeed was some light guidance. And I know that when I
was at that stage, I had similar problems.

This bug is intended to collect the experiences/problems/etc that
newbies run into, which in turn allows us/me to improve the
documentation for everyone.

I do intend to submit a MR to improve it, but first we need to collect
the issues newbies run into, which will be done in this bug.


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

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

debian-kernel-handbook depends on no packages.

Versions of packages debian-kernel-handbook recommends:
ii  firefox [www-browser]  106.0-1
ii  firefox-esr [www-browser]  102.4.0esr-1
ii  konqueror [www-browser]4:21.12.3-1
ii  qutebrowser [www-browser]  2.5.2-1
ii  w3m [www-browser]  0.5.3+git20220429-1+b1

debian-kernel-handbook suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCY1AavAAKCRDXblvOeH7b
bvUZAQCULw272Gb13pivISHTmnfbKEQ9JnSHSgXI+rHwSAVJ7gD/Qucrg6F0eUAO
z81Be4N3hfK+A8eCDWcezzvOZudQvQo=
=MIDA
-END PGP SIGNATURE-

Bug#1022062: linux-image-5.10.0-19-rt-amd64: drm_kms_helper "flip_done timed out" messages during boot. amdgpu. Only "nomodeset" works.

[J.H. Leib]

Package: linux-image-5.10.0-19-rt-amd64
Severity: important
X-Debbugs-Cc: jhlei...@gmail.com

Dear Maintainer,

linux-image-5.10.0-19-rt-amd64

drm_kms_helper "flip_done timed out" messages during boot. amdgpu. Only 
"nomodeset" works.
This started upgrading from vunerable linux-image-5.10.0-18-rt-amd64 to 
linux-image-5.10.0-19-rt-amd64 (Debian security).

I see a constant stream of these messages which repeat:
[   16.405686] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] 
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[   26.645844] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[   36.885904] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [PLANE:52:plane-3] flip_done timed out

I see a Linux Mint user has the same problem with 5.10.0.19-amd64 that I have ( 
https://forums.linuxmint.com/viewtopic.php?t=383942&p=2247003 ).

I have an amdgpu.
Hardware name: ASUS System Product Name/PRIME B550M-K, BIOS 2803 04/28/2022
(This motherboard has the AMD B550 chipset. I already installed the most recent 
BIOS version for this motherboard.)
CPU model name: AMD Ryzen 7 5700G with Radeon Graphics
microcode   : 0xa5d
cpu MHz : 1516.675


The system is not completely dead. I can ssh into it from another computer. My 
daemons like apache,squid and apt-cacher-ng are responsive.
The problem is I do not have **any** VTs and lightdm never appears on VT7.

Thinking that the "rt" version was fussy about hardware, I tried 
linux-image-5.10.0-19-amd64 but had the same poor results.

I tried some suggestions I found on the internet:
I changed from
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet video=SVIDEO-1:d"

I changed
GRUB_CMDLINE_LINUX="zswap.enabled=1 blacklist=watchdog,sp5100_tco"
to
GRUB_CMDLINE_LINUX="amd_iommu=on iommu=pt amdgpu.noretry=0 
amdgpu.lockup_timeout=1000 amdgpu.gpu_recovery=1 amdgpu.audio=0 efi=runtime 
zswap.enabled=1 blacklist=watchdog,sp5100_tco"

These parameter changes did not help.

The only way I successfully boot is to either use the vunerable 
linux-image-5.10.0-18-rt-amd64 or use GRUB_CMDLINE_LINUX="nomodeset 
zswap.enabled=1 blacklist=watchdog,sp5100_tco"
The GUI resolution with "nomodeset" is poor.

Please let me know if you need more information.

dmesg gives much more context:
[   16.405686] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] 
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[   16.407440] amdgpu :0a:00.0: [drm] fb0: amdgpudrmfb frame buffer device
[   16.437782] amdgpu :0a:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0
[   16.437786] amdgpu :0a:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 
on hub 0
[   16.437787] amdgpu :0a:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 
on hub 0
[   16.437788] amdgpu :0a:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 
on hub 0
[   16.437789] amdgpu :0a:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 
on hub 0
[   16.437789] amdgpu :0a:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 
on hub 0
[   16.437790] amdgpu :0a:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 
on hub 0
[   16.437791] amdgpu :0a:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 
on hub 0
[   16.437791] amdgpu :0a:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 
on hub 0
[   16.437792] amdgpu :0a:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 
on hub 0
[   16.437793] amdgpu :0a:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 
1
[   16.437794] amdgpu :0a:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on 
hub 1
[   16.437795] amdgpu :0a:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on 
hub 1
[   16.437796] amdgpu :0a:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on 
hub 1
[   16.437797] amdgpu :0a:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on 
hub 1
[   16.443571] [drm] Initialized amdgpu 3.40.0 20150101 for :0a:00.0 on 
minor 0

[   26.645844] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[   36.885904] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] 
*ERROR* [PLANE:52:plane-3] flip_done timed out
[   36.885943] [ cut here ]
[   36.885944] WARNING: CPU: 8 PID: 188 at 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.
c:7391 amdgpu_dm_atomic_commit_tail+0x2361/0x23f0 [amdgpu]
[   36.886067] Modules linked in: raid10 raid456 async_raid6_recov async_memcpy 
async_pq async_xor as
ync_tx xor raid6_pq libcrc32c raid0 multipath linear dm_mod raid1 md_mod 
hid_generic amdgpu usbhid hi
d sd_mod t10_pi sr_mod crc_t10dif crct10dif_generic cdrom gpu_sched 
i2c_algo_bit ttm crct10dif_pclmul
 crct10dif_common crc32_pclmul ahci crc32c_intel libahci xhci_pci 
ghash_clmulni_intel drm_kms_helper
xhci_hcd r8169 libata cec realtek mdio_devres aesni_intel libphy libaes usbcore 
drm crypto_simd scsi_
mod cryptd usb_common glue_helper i2c_piix4 wmi gpio_amdpt gpio_gene

Bug#1022063: gdb crashes target program if any breakpoint was set at a shared library function before it was first used

[WHR]

Package: gdb
Version: 12.1-4
Severity: important
X-Debbugs-Cc: msl023...@gmail.com


Hello.
When trying to test whether bug 1022056 affects architecture ppc64
(big endian), I discovered a more serious issue; when I set a breakpoint for
a shared library function which have not yet being referenced by the target
program, for example when setting breakpoint before running the program, the
target program would crash as soon as it calls the shared library function.

For example:

whr@debian:~/src$ gdb rval-test 
GNU gdb (Debian 12.1-4) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from rval-test...
(gdb) b geteuid
Breakpoint 1 at 0xaa4
(gdb) r
Starting program: /home/whr/src/rval-test 
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/powerpc64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x7fe8b7e1a3a8 in ?? ()
(gdb) bt
#0  0x7fe8b7e1a3a8 in ?? ()
#1  0x2a0c in main () at rval-test.c:6
(gdb) c
Continuing.

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.


The workaround is to control the target program to call the shared library
function by itself first, before trying to set breakpoint for that function;
unfortunately this helps only in some situations.

With this workaround, I can confirm that the bug 1022056 is indeed affecting
ppc64 too:

whr@debian:~/src$ gdb rval-test 
GNU gdb (Debian 12.1-4) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from rval-test...
(gdb) b main
Breakpoint 1 at 0xa08: file rval-test.c, line 6.
(gdb) r
Starting program: /home/whr/src/rval-test 
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/powerpc64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) n
geteuid returned 1000
7   sleep(1);
(gdb) b geteuid
Breakpoint 2 at 0x3fffb7e1a3a8: geteuid. (2 locations)
(gdb) c
Continuing.

Breakpoint 1, main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) 
Continuing.

Breakpoint 2, .LY__geteuid () at ../sysdeps/unix/syscall-template.S:91
91  ../sysdeps/unix/syscall-template.S: 沒有此一檔案或目錄.
(gdb) return 11
Make .LY__geteuid return now? (y or n) y
#0  0x2a0c in main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) c
Continuing.
geteuid returned 0

Breakpoint 1, main () at rval-test.c:6
6   printf("geteuid returned %u\n", (unsigned 
int)geteuid());
(gdb) delete 1
(gdb) c
Continuing.

Breakpoint 2, .LY__geteuid () at ../sysdeps/unix/syscall-template.S:91
91  ../sysdeps/unix/syscall-template.S: 沒有此一檔案或目錄.
(gdb) return (uint32_t)11
Make .LY__geteuid return now? (y or n) y
#0  0

Bug#1022049: libnettle8: Illegal instruction on IBM POWER7

[Niels Möller]

WHR  writes:

> I think the Debian architecture I'm using (ppc64) should still supporting
> POWER7, but apparently this library was built to use instructions unavailable
> on POWER7.

Nettle attempts to figure out at runtime which processor features are
available.

> => 0x3fffb72bedec <+76>:vmrgow  v4,v0,v0

The ppc specification says "vmrgow is treated as a Vector
instruction in terms of resource availability.", it's not entirely clear
to me what that means, and if checking for altivec support should be enough.

The fat setup for ppc is intended to enable the crashing code path only
if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are
both set in the status word returned from

  hwcap = getauxval(AT_HWCAP);

This logic is in
https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-ppc.c#L151
and used to selct chacha code here:
https://git.lysator.liu.se/nettle/nettle/-/blob/master/fat-ppc.c#L232

> lscpu(1) output:
>
> Architecture:ppc64
>   CPU op-mode(s):32-bit, 64-bit
>   Byte Order:Big Endian
> CPU(s):  4
>   On-line CPU(s) list:   0-3
> Model name:  POWER7 (architected), altivec supported

Would you expect to have the "vsx" feature mentioned there or not?

You can get some diagnostics from the initialization process by setting
the NETTLE_FAT_VERBOSE environment variable, and override the automatic
detection with the NETTLE_FAT_OVERRIDE environment variable.

Can you check what getauxval(AT_HWCAP) returns on your system?

I'm not so familiar with powerpc variants. Cc:ing Maamoun who's more
familiar with this arch.

>   Model: 2.3 (pvr 003f 0203)
>   Thread(s) per core:4
>   Core(s) per socket:1
>   Socket(s): 1
> Virtualization features: 
>   Hypervisor vendor: pHyp
>   Virtualization type:   para

Is the program that crashes running under a vm, or is the kernel running
on the bare metal? Each layer of vm tends to be ian opportunity to introduce
errors in the list of available processor features.

> Caches (sum of all): 
>   L1d:   32 KiB (1 instance)
>   L1i:   32 KiB (1 instance)
>   L2:256 KiB (1 instance)
>   L3:4 MiB (1 instance)
> NUMA:
>   NUMA node(s):  2
>   NUMA node0 CPU(s): 
>   NUMA node1 CPU(s): 0-3
>
>
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> merged-usr: no
> Architecture: ppc64
> Foreign Architectures: powerpc
>
> Kernel: Linux 4.1.42-rivoreo-powerpc64-largepage (SMP w/4 CPU threads)
> Locale: LANG=zh_TW.UTF-8, LC_CTYPE=zh_TW.UTF-8 (charmap=UTF-8), 
> LANGUAGE=zh_TW:zh_CN:zh:en_GB:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages libnettle8 depends on:
> ii  libc6  2.35-3
>
> libnettle8 recommends no packages.
>
> libnettle8 suggests no packages.
>
> -- no debconf information
>

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

Bug#1022025: fails to boot on machines with AMD integrated graphics

[Dan Coleman]

I'm recompiling to start from scratch and make sure I did this correctly, but 
I'll be away from my computer for several hours. If anyone else wants to jump 
in and report their own findings, feel free! Hopefully there's some new info 
when I get back.

Thanks very much to Salvatore and Diederik for their help.

On 10/19/22 10:38 AM, Dan Coleman wrote:
> Ok, I think I succeeded in getting the test kernel to install, but it did not 
> solve the issue. The fans ramped up a bit, and I didn't get any errors about 
> DRM on the console, but it still hung on the black screen.
>
> Of course, I may have royally screwed up installing the kernel (thank 
> goodness for Timeshift), so I welcome another, more experienced tester to 
> verify my own findings.
>
> On 10/19/22 10:26 AM, Salvatore Bonaccorso wrote:
>> Hi Dan, hi Diederik
>>
>> On Wed, Oct 19, 2022 at 05:09:01PM +0200, Diederik de Haas wrote:
>>> On Wednesday, 19 October 2022 16:34:49 CEST Dan Coleman wrote:
 $ sudo dpkg -i
 ./linux-image-5.10.0-19-amd64-unsigned_5.10.149-1a~test_amd64.deb dpkg:
 considering removing linux-image-5.10.0-19-amd64 in favour of
 linux-image-5.10.0-19-amd64-unsigned ... dpkg: no, cannot proceed with
 removal of linux-image-5.10.0-19-amd64 (--auto-deconfigure will help):
 linux-image-amd64 depends on linux-image-5.10.0-19-amd64 (= 5.10.149-1)
 linux-image-5.10.0-19-amd64 is to be removed.
>>> AFAICT, the last line indicates the problem.
>>> I do know how I would resolve it on my system and if my initial attempt 
>>> fails
>>> how to fix that, but I don't feel comfortable suggesting that to you.
>>>
>>> So, I'll let Salvatore take over as he's (WAY) more experienced then I am.
>> You need to have (temporarily at least) removed the signed package
>> indeed, as they are conflicting. If you do it with apt-get install
>> ./path/to/local/package.deb all the surronding work should be done as
>> well.
>>
>> (And you have the 18 ABI kernel still installed to which you can go
>> back if th test package does no work).
>>
>> After testing, make sure to reinstall the linux-image-amd64 package
>> again.
>>
>> Regards,
>> Salvatore

Bug#1021938: kalarm: .local/share/kalarm/expired.ics is not a valid iCalendar file

[David Jarvie]

This is due to a regression in libical version 3.0.15. It is fixed in libical 
3.0.16 (which is in unstable). See https://bugs.kde.org/show_bug.cgi?
id=460442.

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#1022064: transition: libavif

[Boyuan Yang]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: by...@debian.org
Severity: normal

I plan to start yet another libavif transition as shown in the following
transition tracker:

https://release.debian.org/transitions/html/auto-libavif.html

The new version of libavif library has bumped SONAME and needs a transition.
The only reverse build-dependencies are kimageformats and jpeg-xl, and I have
verified that the build would still pass with the new libavif currently in
experimental.

Example Ben file (the one currently on auto-libavif page should be ok):

title = "libavif";
is_affected = .depends ~ "libavif14" | .depends ~ "libavif15";
is_good = .depends ~ "libavif15";
is_bad = .depends ~ "libavif14";

This would be a really tiny transition, and I expect that we can finish it
very soon once there are no transition entanglements (gcc-12, perl-5.26).

Thanks,
Boyuan Yang


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

Bug#1022065: mujoco: FTBFS on riscv64

[Eric Long]

Source: mujoco
Version: 2.2.2-2
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: i...@hack3r.moe, debian-ri...@lists.debian.org

Dear maintainer,

mujoco failed to build on riscv64 due to missing symbols for sub-word atomic
functions:

```
[66/71] : && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--gc-sections 
simulate/CMakeFiles/simulate.dir/main.cc.o 
simulate/CMakeFiles/simulate.dir/glfw_dispatch.cc.o 
simulate/CMakeFiles/simulate.dir/simulate.cc.o 
simulate/CMakeFiles/simulate.dir/uitools.cc.o -o bin/simulate  
-Wl,-rpath,"\$ORIGIN/../lib/riscv64-linux-gnu"  
lib/riscv64-linux-gnu/liblibsimulate.a  
lib/riscv64-linux-gnu/libmujoco.so.2.2.2  
/usr/lib/riscv64-linux-gnu/libglfw.so.3.3  
/usr/lib/riscv64-linux-gnu/liblodepng.so && :
FAILED: bin/simulate 
: && /usr/bin/c++ -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,--gc-sections 
simulate/CMakeFiles/simulate.dir/main.cc.o 
simulate/CMakeFiles/simulate.dir/glfw_dispatch.cc.o 
simulate/CMakeFiles/simulate.dir/simulate.cc.o 
simulate/CMakeFiles/simulate.dir/uitools.cc.o -o bin/simulate  
-Wl,-rpath,"\$ORIGIN/../lib/riscv64-linux-gnu"  
lib/riscv64-linux-gnu/liblibsimulate.a  
lib/riscv64-linux-gnu/libmujoco.so.2.2.2  
/usr/lib/riscv64-linux-gnu/libglfw.so.3.3  
/usr/lib/riscv64-linux-gnu/liblodepng.so && :
/usr/bin/ld: simulate/CMakeFiles/simulate.dir/simulate.cc.o: in function 
`std::__atomic_base::exchange(bool, std::memory_order)':
./obj-riscv64-linux-gnu/./simulate/simulate.cc:513: undefined reference to 
`__atomic_exchange_1'
collect2: error: ld returned 1 exit status
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=mujoco&arch=riscv64&ver=2.2.2-1&stamp=1664815613&raw=0

Attached is a patch that links libatomic to bin/simulate on riscv64 platform
and fix FTBFS. If more help is needed, please let me know.

Cheers,
Eric
--- a/simulate/CMakeLists.txt
+++ b/simulate/CMakeLists.txt
@@ -245,3 +245,7 @@
 endif()
   endif()
 endif()
+
+if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "riscv64")
+  target_link_libraries(simulate atomic)
+endif()

Bug#836873: kalarm: The Akonadi personal information management service is not operational

[David Jarvie]

Note that from version 20.08 onwards (i.e. Bullseye or later), kalarm no 
longer uses Akonadi for calendar access, so this problem no longer exists. 
Akonadi is now only used for functions such as migration of resources from 
previous versions, birthday import and email functions. Failure of Akonadi 
will only affect those particular functions.

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#1022066: olive-editor: New versions of olive are not packaged for Debian

[david]

Package: olive-editor
Version: 20220815+ds-3
Severity: wishlist

Dear Maintainer,

I have visited olive editor web and seen that new versions are delivered on
a monthly basis, more or less. Version in Debian is very obsolete and I'd like
to have them available.

Thank you very much.

-- 
David

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

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

Versions of packages olive-editor depends on:
ii  ffmpeg 7:5.1.2-1
ii  frei0r-plugins 1.8.0-1+b1
ii  libavcodec59   7:5.1.2-1
ii  libavfilter8   7:5.1.2-1
ii  libavformat59  7:5.1.2-1
ii  libavutil577:5.1.2-1
ii  libc6  2.35-3
ii  libgcc-s1  12.2.0-3
ii  libopencolorio2.1  2.1.2+dfsg1-4
ii  libopenexr-3-1-30  3.1.5-4
ii  libopenimageio2.3  2.3.18.0+dfsg-5
ii  libportaudio2  19.6.0-1.2
ii  libqt5core5a   5.15.4+dfsg-5
ii  libqt5dbus55.15.4+dfsg-5
ii  libqt5gui5 5.15.4+dfsg-5
ii  libqt5multimedia5-plugins  5.15.4-2
ii  libqt5widgets5 5.15.4+dfsg-5
ii  libstdc++6 12.2.0-3
ii  libswresample4 7:5.1.2-1
ii  libswscale67:5.1.2-1

olive-editor recommends no packages.

olive-editor suggests no packages.

-- no debconf information

Bug#932347: kalarm: Multiple akonadi_kalarm_resource processes are spawned on kalarm start and consume lot of CPU

[David Jarvie]

Note that from version 20.08 onwards (i.e. Bullseye or later), kalarm no 
longer uses Akonadi for calendar access, so this problem can no longer occur. 

-- 
David Jarvie.
KDE developer, KAlarm author.

Bug#931295: u-boot-sunxi: cannot stop autoboot with usb keyboard on cubietruck

[Diederik de Haas]

On 18 Jan 2020 11:50:35 -0800 Vagrant Cascadian  wrote:
> Version: 2019.04+dfsg-1
> 
> This commit is present in 2019.04+dfsg-1, so marking as done.
> 
> It still could standd to get fixed in buster, but the fixing commit
> depended on several others, so I'm not sure if it's a trivial backport
> or not.

This bug is not marked as 'done' as it was not send to 931295-done@b.d.o.
I could (ofc) do that, but given the above backport comment, I didn't do it.

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

Bug#955310: u-boot-tools: update list of architectures in mkimage

[Diederik de Haas]

On 29 Mar 2020 12:33:40 -0700 Vagrant Cascadian  wrote:
> On 2020-03-29, Chris Dumont wrote:
> >* What led up to the situation?
> > read the manpage for mkimage and then used 'mkimage -T -h'
> ...
> >* What was the outcome of this action?
> > The output (ellipsized)
> >
> > $ mkimage -T -h
> >
> > Invalid image type, supported are:
> > Unknown image type  Unknown image type
> > aisimage Davinci AIS image
> > atmelimage   ATMEL ROM-Boot Image
> > filesystem   Filesystem Image
> > ...
> 
> It appears the recommendation from mkimage help output is to use
> "mkimage -T list" now.
> 
> It seems like this should be changed to "-T list" in the manpage.
> 
> There are several other options -A, -O and -C that also should probably
> be updated, but those options need an updated to the code as well, as
> they output the usage information in addition to listing the available
> Architecture/Os/Compression types ...
> 
> Using "mkimage -T list" just displays the list of image types, from what
> I can tell, which seems more-or-less fine.
> 
> I haven't tested anything newer than 2020.04~rc2, so there may be newer
> fixes upstream...

I checked it with version 2022.10+dfsg-1 and AFAICT both command help and the 
manpage have the mentioned options documented.

Chris, do you consider this bug fixed?

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

Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7

[王昊然]

-- Forwarded message --
From: 王昊然 
Date: Thu, 20 Oct 2022 00:18:35 +0800
Subject: Re: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
To: Niels Möller 

> The ppc specification says "vmrgow is treated as a Vector
> instruction in terms of resource availability.", it's not entirely clear
> to me what that means, and if checking for altivec support should be enough.
>
> The fat setup for ppc is intended to enable the crashing code path only
> if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are
> both set in the status word returned from
> ...

Thanks for the hint, I guess this issue is likely caused by my kernel which
wasn't have CONFIG_VSX enabled. But in my understanding, this feature is an
extension to AltiVec, not the AltiVec itself, so nettle shouldn't assume VSX
to be available if they seen AltiVec available.


> You can get some diagnostics from the initialization process by setting
> the NETTLE_FAT_VERBOSE environment variable, and override the automatic
> detection with the NETTLE_FAT_OVERRIDE environment variable.

$ NETTLE_FAT_VERBOSE=1 test-program
libnettle: cpu features:
libnettle: enabling altivec code.
Illegal instruction


> Can you check what getauxval(AT_HWCAP) returns on your system?

whr@debian:~/src$ cat cpu-feature-test.c
#include 
#include 

int main() {
unsigned long int hwcap = getauxval(AT_HWCAP);
printf("hwcap = 0x%lx\n", hwcap);
return 0;
}
whr@debian:~/src$ gcc -Wall cpu-feature-test.c
whr@debian:~/src$ ./a.out
hwcap = 0xdc0065c2


> Is the program that crashes running under a vm, or is the kernel running
> on the bare metal? Each layer of vm tends to be ian opportunity to introduce
> errors in the list of available processor features.

Operating systems on this machine are always running on the Power Hypervisor,
which is a part of the server firmware.

Bug#1022049: Fwd: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7

[王昊然]

-- Forwarded message --
From: 王昊然 
Date: Thu, 20 Oct 2022 00:33:18 +0800
Subject: Re: Bug#1022049: libnettle8: Illegal instruction on IBM POWER7
To: Niels Möller 

2022-10-20 0:18 GMT+08:00, 王昊然 :
>> The ppc specification says "vmrgow is treated as a Vector
>> instruction in terms of resource availability.", it's not entirely clear
>> to me what that means, and if checking for altivec support should be
>> enough.
>>
>> The fat setup for ppc is intended to enable the crashing code path only
>> if the feature bits PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX are
>> both set in the status word returned from
>> ...
>
> Thanks for the hint, I guess this issue is likely caused by my kernel which
> wasn't have CONFIG_VSX enabled. But in my understanding, this feature is an
> extension to AltiVec, not the AltiVec itself, so nettle shouldn't assume
> VSX
> to be available if they seen AltiVec available.
>
>
>> You can get some diagnostics from the initialization process by setting
>> the NETTLE_FAT_VERBOSE environment variable, and override the automatic
>> detection with the NETTLE_FAT_OVERRIDE environment variable.
>
> $ NETTLE_FAT_VERBOSE=1 test-program
> libnettle: cpu features:
> libnettle: enabling altivec code.
> Illegal instruction
>
>
>> Can you check what getauxval(AT_HWCAP) returns on your system?
>
> whr@debian:~/src$ cat cpu-feature-test.c
> #include 
> #include 
>
> int main() {
> unsigned long int hwcap = getauxval(AT_HWCAP);
> printf("hwcap = 0x%lx\n", hwcap);
> return 0;
> }
> whr@debian:~/src$ gcc -Wall cpu-feature-test.c
> whr@debian:~/src$ ./a.out
> hwcap = 0xdc0065c2
>
>
>> Is the program that crashes running under a vm, or is the kernel running
>> on the bare metal? Each layer of vm tends to be ian opportunity to
>> introduce
>> errors in the list of available processor features.
>
> Operating systems on this machine are always running on the Power
> Hypervisor,
> which is a part of the server firmware.
>

I just checked the nettle source code, it is indeed correctly checked both
PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX; and with my HWCAP has
PPC_FEATURE_HAS_VSX set, I think it hits a limitation of this processor
feature checking logic: hardware supporting it, but the kernel didn't.

I will try to build a new kernel with CONFIG_VSX enabled by tomorrow.

Bug#1022064: transition: libavif

[Sebastian Ramacher]

Control: tags -1 confirmed

On 2022-10-19 12:06:24 -0400, Boyuan Yang wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-CC: by...@debian.org
> Severity: normal
> 
> I plan to start yet another libavif transition as shown in the following
> transition tracker:
> 
> https://release.debian.org/transitions/html/auto-libavif.html
> 
> The new version of libavif library has bumped SONAME and needs a transition.
> The only reverse build-dependencies are kimageformats and jpeg-xl, and I have
> verified that the build would still pass with the new libavif currently in
> experimental.
> 
> Example Ben file (the one currently on auto-libavif page should be ok):
> 
> title = "libavif";
> is_affected = .depends ~ "libavif14" | .depends ~ "libavif15";
> is_good = .depends ~ "libavif15";
> is_bad = .depends ~ "libavif14";
> 
> This would be a really tiny transition, and I expect that we can finish it
> very soon once there are no transition entanglements (gcc-12, perl-5.26).

While binNMUs might take a bit longer to be done, neither of those two
should be entangled. So please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1022067: zynaddsubfx: FTBFS on riscv64

[Eric Long]

Source: zynaddsubfx
Version: 3.0.6-3
Severity: important
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: i...@hack3r.moe, debian-ri...@lists.debian.org

Dear maintainers,

zynaddsubfx failed to build on riscv64 due to gcc missing sub-word atomics:

```
[ 78%] Building CXX object 
src/Plugin/Distortion/CMakeFiles/ZynDistortion_vst.dir/__/__/__/DPF/distrho/DistrhoPluginMain.cpp.o
cd /<>/obj-riscv64-linux-gnu/src/Plugin/Distortion && /usr/bin/c++ 
-DALSA=1 -DDISTRHO_PLUGIN_TARGET_VST2 -DFLTK_GUI -DHAVE_ASYNC=1 
-DHAVE_CPP_STD_COMPLEX=1 -DHAVE_SCHEDULER=1 -DJACK=1 -DOSS=1 -DUSE_NSM=1 
-DVERSION=\"\" -DZynDistortion_vst_EXPORTS -I/<>/rtosc/include 
-I/<>/obj-riscv64-linux-gnu/src -I/usr/lib/fltk 
-I/<>/src/UI -I/<>/obj-riscv64-linux-gnu/src/UI 
-I/<>/src 
-I/<>/obj-riscv64-linux-gnu/src/Plugin/Distortion 
-I/<>/DPF/distrho -I/<>/src/Plugin/Distortion/. -g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 
-Wno-unused-parameter -O3 -ffast-math -fomit-frame-pointer  -fPIC   -Wall 
-Wextra -fPIC -Wno-parentheses -MD -MT 
src/Plugin/Distortion/CMakeFiles/ZynDistortion_vst.dir/__/__/__/DPF/distrho/DistrhoPluginMain.cpp.o
 -MF 
CMakeFiles/ZynDistortion_vst.dir/__/__/__/DPF/distrho/DistrhoPluginMain.cpp.o.d 
-o 
CMakeFiles/ZynDistortion_vst.dir/__/__/__/DPF/distrho/DistrhoPluginMain.cpp.o 
-c /<>/DPF/distrho/DistrhoPluginMain.cpp
/usr/bin/ld: libzynaddsubfx_core.a(Master.cpp.o): in function `.L0 ':
/usr/include/riscv64-linux-gnu/bits/string_fortified.h:59: undefined reference 
to `__atomic_exchange_1'
collect2: error: ld returned 1 exit status
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=zynaddsubfx&arch=riscv64&ver=3.0.6-3&stamp=1665440667&raw=0

Attached is a patch that links libatomic manually on riscv64. If more help is
needed, please let me know.

Cheers,
Eric
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -583,6 +583,10 @@
 ${PTHREAD_LIBRARY}
 rtosc rtosc-cpp)
 
+if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "riscv64")
+target_link_libraries(zynaddsubfx_core atomic)
+endif()
+
 if(IwyuErr)
 message (STATUS "Include what you use: ${IwyuErr}")
 else()

Bug#1022068: linux: kernel NULL pointer dereference in nouveau driver on Thinkpad W541

[Ansgar]

Source: linux
Version: 6.0.2-1
Severity: important

After upgrading to linux 6.0.2-1 I see the following message during boot:

+---
| [3.723631] i915 :00:02.0: [drm] fb0: i915drmfb frame buffer device
| [...]
| [3.855523] vga_switcheroo: enabled
| [3.855536] nouveau :01:00.0: DRM: VRAM: 2048 MiB
| [3.855537] nouveau :01:00.0: DRM: GART: 1048576 MiB
| [3.855539] nouveau :01:00.0: DRM: TMDS table version 2.0
| [3.855541] nouveau :01:00.0: DRM: DCB version 4.0
| [3.855542] nouveau :01:00.0: DRM: DCB outp 00: 08800fc6 0f420010
| [3.855544] nouveau :01:00.0: DRM: DCB outp 01: 08000f82 00020010
| [3.855545] nouveau :01:00.0: DRM: DCB conn 00: 0146
| [3.857230] nouveau :01:00.0: DRM: MM: using COPY for buffer copies
| [3.858820] BUG: kernel NULL pointer dereference, address: 0020
| [3.858838] #PF: supervisor read access in kernel mode
| [3.858847] #PF: error_code(0x) - not-present page
| [3.858856] PGD 0 P4D 0 
| [3.858864] Oops:  [#1] PREEMPT SMP PTI
| [3.858872] CPU: 1 PID: 427 Comm: systemd-udevd Not tainted 6.0.0-1-amd64 
#1  Debian 6.0.2-1
| [3.858886] Hardware name: LENOVO 20EGS1FD00/20EGS1FD00, BIOS GNET88WW 
(2.36 ) 05/30/2018
| [3.858898] RIP: 0010:nvif_object_mthd+0xba/0x200 [nouveau]
| [3.858982] Code: 72 ce 41 8d 56 20 49 8b 44 24 08 83 fa 17 0f 86 35 01 00 
00 4c 39 e0 0f 84 ea 00 00 00 4c 89 63 10 31 c9 48 89 de c6 43 06 ff <48> 8b 78 
20 48 8b 40 38 48 8b 40 28 e8 d5 e3 95 ce 48 8b 3c 24 4c
| [3.859008] RSP: 0018:a8e7409bb718 EFLAGS: 00010246
| [3.859018] RAX:  RBX: a8e7409bb720 RCX: 

| [3.859030] RDX: 0028 RSI: a8e7409bb720 RDI: 
a8e7409bb748
| [3.859042] RBP:  R08: a8e7409bb968 R09: 
0008
| [3.859053] R10: 95661041f9c0 R11: a8e740e3 R12: 
9565ca2114f8
| [3.859065] R13: a8e7409bb720 R14: 0008 R15: 
a8e7409bb740
| [3.859076] FS:  7fc0a2a6e8c0() GS:956d1e24() 
knlGS:
| [3.859090] CS:  0010 DS:  ES:  CR0: 80050033
| [3.859100] CR2: 0020 CR3: 000100f74001 CR4: 
001706e0
| [3.859112] Call Trace:
| [3.859120]  
| [3.859128]  nvif_conn_hpd_status+0x35/0xe0 [nouveau]
| [3.859209]  nouveau_dp_detect+0x2d0/0x410 [nouveau]
| [3.859302]  nouveau_connector_detect+0x9b/0x550 [nouveau]
| [3.859395]  drm_helper_probe_detect+0x84/0xb0 [drm_kms_helper]
| [3.859421]  drm_helper_probe_single_connector_modes+0x361/0x510 
[drm_kms_helper]
| [3.859444]  drm_client_modeset_probe+0x224/0x1490 [drm]
| [3.859487]  ? nouveau_cli_init+0x3ea/0x490 [nouveau]
| [3.859582]  ? __pm_runtime_suspend+0x6a/0x100
| [3.859593]  __drm_fb_helper_initial_config_and_unlock+0x44/0x510 
[drm_kms_helper]
| [3.859618]  ? drm_client_init+0x133/0x160 [drm]
| [3.859653]  nouveau_fbcon_init+0x14a/0x1c0 [nouveau]
| [3.859736]  nouveau_drm_device_init+0x1ec/0x7a0 [nouveau]
| [3.859819]  ? pci_update_current_state+0x6e/0xa0
| [3.859831]  nouveau_drm_probe+0x128/0x1f0 [nouveau]
| [3.859913]  ? _raw_spin_unlock_irqrestore+0x23/0x40
| [3.859925]  local_pci_probe+0x41/0x80
| [3.859935]  pci_device_probe+0xc3/0x230
| [3.859946]  really_probe+0xde/0x380
| [3.859955]  ? pm_runtime_barrier+0x50/0x90
| [3.859963]  __driver_probe_device+0x78/0x170
| [3.859972]  driver_probe_device+0x1f/0x90
| [3.859981]  __driver_attach+0xd1/0x1d0
| [3.859990]  ? __device_attach_driver+0x110/0x110
| [3.86]  bus_for_each_dev+0x87/0xd0
| [3.860011]  bus_add_driver+0x1ae/0x200
| [3.860019]  driver_register+0x89/0xe0
| [3.860028]  ? 0xc0731000
| [3.860035]  do_one_initcall+0x59/0x220
| [3.860047]  do_init_module+0x4a/0x200
| [3.860057]  __do_sys_finit_module+0xac/0x120
| [3.860067]  do_syscall_64+0x3a/0xc0
| [3.860077]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
| [3.860088] RIP: 0033:0x7fc0a3177859
| [3.860096] Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 87 05 0f 00 f7 d8 64 89 01 48
| [3.860121] RSP: 002b:7ffdb9440778 EFLAGS: 0246 ORIG_RAX: 
0139
| [3.860133] RAX: ffda RBX: 55f6ea1a8cf0 RCX: 
7fc0a3177859
| [3.860144] RDX:  RSI: 7fc0a3327efd RDI: 
0015
| [3.860155] RBP: 7fc0a3327efd R08:  R09: 
55f6ea1af1a0
| [3.860167] R10: 0015 R11: 0246 R12: 
0002
| [3.860178] R13:  R14: 55f6ea1df350 R15: 
55f6e964fcc1
| [3.860190]  
| [3.860196] Modules linked in: raid1 md_mod i915 nouveau(+) sd_mod t10_pi 
sr_mod crc64_rocksoft_generic cdrom crc64_rocksoft crc_

Bug#1022069: dh-cmake: Uses DEB_HOST_GNU_TYPE instead of DEB_HOST_MULTIARCH in tests

[Niels Thykier]

Package: dh-cmake
Tags: ftbfs
Severity: important

Spotted via Reproducible Builds 
(https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/dh-cmake.html)



The bug is in KWTestCaseBase (dhcmake/tests/__init__.py)

@classmethod
def replace_arch_in_paths(cls, paths):
return (p.format(arch=dhcmake.arch
 .dpkg_architecture()["DEB_HOST_GNU_TYPE"])
for p in paths)


Based on how it is used, that "DEB_HOST_GNU_TYPE" should almost 
certainly have been a "DEB_HOST_MULTIARCH".


Thanks,
~Niels

Bug#1021845: s050000l.afm lost in transition from gsfonts to fonts-urw-base35

[Christoph Biedl]

fab...@greffrath.com wrote...

> Hi,
> 
> Am 16.10.2022 21:22, schrieb Fabian Greffrath:
> > I will provide a README.Debian file with the next revision, explicitly
> > listing the font files with their previous and new file names and paths
> > to make migrations easier.
> 
> I have done so in the form of a debian/NEWS entry here, which is part of the
> -5 revision that I just uploaded:

Awesome!

> Given that the s05l.afm file is *not* lost, but merely renamed and
> moved, and that this move is now properly documented, do you think we could
> close this issue again?

Certainly. Now there is something to point users to. As mentioned, this
change might still be something for the bookworm release notes,
depending on how important this is for end users or third-party packages
Debian cannot control. I'm not into font handling, so I cannot judge the
necessity for that.

Kind regards,

Christoph


signature.asc
Description: PGP signature

Bug#1022070: Booting semi-hangs with 'drm_atomic_helper_wait_for_flip_done' errors and alike

[Kees Meijs]

Package: linux-image-5.10.0-19-amd64
Version: 5.10.149-1

Dear maintainer,

This morning I upgraded my Lenovo Yoga 7 Series laptop with 
linux-image-5.10.0-19-amd64, and rebooted.


Briefly after the initial RAM-disk was loaded, the screen was filling 
with errors, in a very (very) slow manner.


The errors were like this:

[drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* 
[CRTC:62:crtc-0] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* 
[CRTC:62:crtc-0] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* 
[PLANE:52:plane-3] flip_done timed out


In /var/log/kern.log there seemed more to be found:

Oct 19 15:49:55 yoga0 kernel: [  976.653955] CPU: 10 PID: 336 Comm: 
plymouthd Tainted: G    W 5.10.0-19-amd64 #1 Debian 5.10.149-1
Oct 19 15:49:55 yoga0 kernel: [  976.653957] Hardware name: LENOVO 
82CY/LNVNB161216, BIOS GHCN20WW 03/18/2021
Oct 19 15:49:55 yoga0 kernel: [  976.654086] RIP: 
0010:amdgpu_dm_atomic_commit_tail+0x23af/0x2440 [amdgpu]
Oct 19 15:49:55 yoga0 kernel: [  976.654090] Code: a8 fd ff ff 01 c7 85 
a4 fd ff ff 37 00 00 00 c7 85 ac fd ff ff 20 00 00 00 e8 9d 39 13 00 e9 
f4 fa ff ff 0f 0b e9 5f f9 ff ff <0f> 0b e9 af f9 ff ff 0f 0b 0f 0b e9 
c6 f9 ff ff 49 8b 06 41 0f b6
Oct 19 15:49:55 yoga0 kernel: [  976.654092] RSP: 0018:ac03c0caf978 
EFLAGS: 00010002
Oct 19 15:49:55 yoga0 kernel: [  976.654094] RAX: 0002 RBX: 
e610 RCX: 89b240b48118
Oct 19 15:49:55 yoga0 kernel: [  976.654096] RDX: 0001 RSI: 
0297 RDI: 89b253960188
Oct 19 15:49:55 yoga0 kernel: [  976.654097] RBP: ac03c0cafc70 R08: 
0005 R09: 
Oct 19 15:49:55 yoga0 kernel: [  976.654098] R10: ac03c0caf8d8 R11: 
ac03c0caf8dc R12: 0297
Oct 19 15:49:55 yoga0 kernel: [  976.654099] R13: 89b240b48000 R14: 
89b442aac800 R15: 89b24bf8d280
Oct 19 15:49:55 yoga0 kernel: [  976.654101] FS: 7fbdf4fce740() 
GS:89b53e68() knlGS:
Oct 19 15:49:55 yoga0 kernel: [  976.654103] CS:  0010 DS:  ES:  
CR0: 80050033
Oct 19 15:49:55 yoga0 kernel: [  976.654104] CR2: 5623fe743058 CR3: 
0001203ac000 CR4: 00750ee0

Oct 19 15:49:55 yoga0 kernel: [  976.654105] PKRU: 5554
Oct 19 15:49:55 yoga0 kernel: [  976.654106] Call Trace:
Oct 19 15:49:55 yoga0 kernel: [  976.654123]  ? vprintk_emit+0x171/0x260
Oct 19 15:49:55 yoga0 kernel: [  976.654130]  ? printk+0x58/0x73
Oct 19 15:49:55 yoga0 kernel: [  976.654143]  ? 
drm_atomic_helper_wait_for_dependencies+0x1e4/0x200 [drm_kms_helper]

Oct 19 15:49:55 yoga0 kernel: [  976.654167]  ? __drm_err+0x72/0x90 [drm]
Oct 19 15:49:55 yoga0 kernel: [  976.654179]  commit_tail+0x94/0x130 
[drm_kms_helper]
Oct 19 15:49:55 yoga0 kernel: [  976.654191] 
drm_atomic_helper_commit+0x11b/0x140 [drm_kms_helper]
Oct 19 15:49:55 yoga0 kernel: [  976.654202] 
drm_atomic_helper_dirtyfb+0x188/0x260 [drm_kms_helper]
Oct 19 15:49:55 yoga0 kernel: [  976.654224] 
drm_mode_dirtyfb_ioctl+0xfc/0x1d0 [drm]
Oct 19 15:49:55 yoga0 kernel: [  976.654244]  ? 
drm_mode_getfb2_ioctl+0x2d0/0x2d0 [drm]
Oct 19 15:49:55 yoga0 kernel: [  976.654260] drm_ioctl_kernel+0xae/0x100 
[drm]

Oct 19 15:49:55 yoga0 kernel: [  976.654276]  drm_ioctl+0x224/0x3c0 [drm]
Oct 19 15:49:55 yoga0 kernel: [  976.654292]  ? 
drm_mode_getfb2_ioctl+0x2d0/0x2d0 [drm]
Oct 19 15:49:55 yoga0 kernel: [  976.654348] amdgpu_drm_ioctl+0x49/0x80 
[amdgpu]

Oct 19 15:49:55 yoga0 kernel: [  976.654353] __x64_sys_ioctl+0x8b/0xc0
Oct 19 15:49:55 yoga0 kernel: [  976.654357] do_syscall_64+0x33/0x80
Oct 19 15:49:55 yoga0 kernel: [  976.654360] 
entry_SYSCALL_64_after_hwframe+0x61/0xc6

Oct 19 15:49:55 yoga0 kernel: [  976.654361] RIP: 0033:0x7fbdf52596b7
Oct 19 15:49:55 yoga0 kernel: [  976.654364] Code: 00 00 00 48 8b 05 d9 
c7 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 
00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 
a9 c7 0d 00 f7 d8 64 89 01 48
Oct 19 15:49:55 yoga0 kernel: [  976.654364] RSP: 002b:7ffecf9c6538 
EFLAGS: 0246 ORIG_RAX: 0010
Oct 19 15:49:55 yoga0 kernel: [  976.654365] RAX: ffda RBX: 
7ffecf9c6570 RCX: 7fbdf52596b7
Oct 19 15:49:55 yoga0 kernel: [  976.654366] RDX: 7ffecf9c6570 RSI: 
c01864b1 RDI: 0009
Oct 19 15:49:55 yoga0 kernel: [  976.654366] RBP: c01864b1 R08: 
7ffecf9c65d0 R09: 7fbdf5336be0
Oct 19 15:49:55 yoga0 kernel: [  976.654366] R10: ff80 R11: 
0246 R12: 2800
Oct 19 15:49:55 yoga0 kernel: [  976.654367] R13: 0009 R14: 
5623fe6a5580 R15: 7fbdf4b4a390
Oct 19 15:49:55 yoga0 kernel: [  976.654368] ---[ end trace 
25852d8f208943ff ]---
Oct 19 15:49:55 yoga0 kernel: [  976.654373] [ cut here 
]


After a minute or two, I was able to enter my LUKS password. When 
pre

Bug#1020436: giac FTBFS with PARI 2.15.0

[Bill Allombert]

On Wed, Oct 19, 2022 at 09:27:23AM +, Tobias Hansen wrote:
> I tried rebuilding with this patch from sagemath:

Thanks!

> |diff --git a/src/pari.cc b/src/pari.cc index 76ce8e1..50d08ab 100644 --- 
> a/src/pari.cc +++ b/src/pari.cc @@ -40,6 +40,13 @@ using namespace std; 
> #ifdef HAVE_LIBPARI +// Anyarg disappeared from PARI 2.15.0 +#ifdef 
> __cplusplus +# define ANYARG ... +#else +# define ANYARG +#endif + #ifdef 
> HAVE_PTHREAD_H #include  #endif|
> 
> 
>   ***   the thread stack overflows !
>   current stack size: 1024000 (0.977 Mbytes)
>   [hint] set 'threadsizemax' to a nonzero value in your GPRC
>   *** matdet: Warning: increasing stack size to 2048000.
>   ***   at top-level: matdet([-10,-7,6,-7,1,4,-1,-2,-2,-5,1,7,-6,7,-
>   *** ^--
>   *** matdet: the thread stack overflows !
>   current stack size: 1024000 (0.977 Mbytes)
>   [hint] set 'threadsizemax' to a nonzero value in your GPRC

Probably you just need to increase threadsize or parisize, 1024000 is very 
small.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.