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

[Soren Stoutner]

I opened up another MR.  It has a detailed explanation of the changes, 
including an updated patch.

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

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

Bug#1022207: ITP: pysocks -- Lets you send traffic through SOCKS proxy servers

[Carsten Schoenert]

Hi,

Am 22.10.22 um 01:44 schrieb Josenilson Ferreira da Silva:

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

  It is a modern fork of SocksiPy with bug fixes and extra
  features. Acts as a drop-in replacement to the socket module.
  Seamlessly configure SOCKS proxies for any socket object by
  calling socket_object.set_proxy().
  .
  Features:
   - SOCKS proxy client for Python 2.7 and 3.4+
   - TCP supported, UDP mostly supported (issues may occur in
 some edge cases).
   - HTTP proxy client included but not supported or recommended
 (you should use requests', or your HTTP client's, own HTTP
 proxy interface).
* Package name: pysocks
   Version : 1.7.0
   Upstream Author :  Anorov 
* URL : https://github.com/Anorov/PySocks
* License : BSD-3-clause
   Programming Lang: Python
   Description : Lets you send traffic through SOCKS proxy servers

  Note:
  package is a required dependency for packaging from
  https://github.com/sherlock-project/sherlock


a quick check on the CLI shows me that this seems to be already packaged.
Did you have checked this before writing the ITP?


$ apt show python3-socks
Package: python3-socks
Version: 1.7.1+dfsg-1
Priority: optional
Section: python
Source: python-socksipy
Maintainer: Debian Python Team 
Installed-Size: 78,8 kB
Depends: python3:any
Breaks: python3-pysocks, python3-socksipy
Replaces: python3-pysocks, python3-socksipy
Homepage: https://github.com/Anorov/PySocks
Download-Size: 23,3 kB
APT-Sources: http://ftp.de.debian.org/debian testing/main amd64 Packages
Description: Python 3 SOCKS client module
 This module was designed to allow developers of Python
 software that uses the Internet or another TCP/IP-based
 network to add support for connection through a SOCKS proxy
 server with as much ease as possible.
 .
 The module is also knowns as SocksiPy or PySocks.
 .
 This is the Python 3 version.



--
Regards
Carsten

Bug#1022212: ITP: pulsar -- Emacs package to pulse the current line after running select functions.

[Aymeric Agon-Rambosson]

Package: wnpp
Owner: Aymeric Agon-Rambosson 
Severity: wishlist

* Package name: pulsar
 Version : 0.50
 Upstream Author : Protesilaos Stavrou
* URL or Web page : https://git.sr.ht/~protesilaos/pulsar
* License : GPL-3+
 Description : Emacs package to pulse the current line after 
 running select functions.


This is a small package that temporarily highlights the current 
line after a given function is invoked.


Best,

Aymeric

Bug#1022211: xml2rfc: Test failures with Weasyprint 57.0

[Scott Kitterman]

Package: xml2rfc
Version: 3.13.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source

Using FTBFS as it's the closest thing we have to an autopkgtest
regression severity.  xml2rfc autopkgtest fails in Unstable with
Weasyprint 57.0:

==
ERROR: setUpClass (__main__.PdfWriterTests)
--
Traceback (most recent call last):
  File "/tmp/autopkgtest-lxc.48kx6p_4/downtmp/build.obL/src/xxx/test.py", line 
495, in setUpClass
cls.elements_pdfxml = xmldoc(None, bytes=elements_pdfdoc)
  File "/usr/lib/python3/dist-packages/xml2rfc/walkpdf.py", line 96, in xmldoc
return lxml.etree.fromstring(text)
  File "src/lxml/etree.pyx", line 3254, in lxml.etree.fromstring
  File "src/lxml/parser.pxi", line 1913, in lxml.etree._parseMemoryDocument
  File "src/lxml/parser.pxi", line 1793, in lxml.etree._parseDoc
  File "src/lxml/parser.pxi", line 1082, in 
lxml.etree._BaseParser._parseUnicodeDoc
  File "src/lxml/parser.pxi", line 615, in 
lxml.etree._ParserContext._handleParseResultDoc
  File "src/lxml/parser.pxi", line 725, in lxml.etree._handleParseResult
  File "src/lxml/parser.pxi", line 654, in lxml.etree._raiseParseError
  File "", line 14199
lxml.etree.XMLSyntaxError: PCDATA invalid Char value 23, line 14199, column 11

--
Ran 42 tests in 21.851s

FAILED (errors=1)

https://ci.debian.net/data/autopkgtest/testing/amd64/x/xml2rfc/27394437/log.gz

Upstream is apparently aware since (I discovered after uploading
Weasyprint) they have recently pinned the Weasyprint dependency to
<57.0.

I did file an issue upstream:

https://github.com/ietf-tools/xml2rfc/issues/921

Scott K

Bug#1022198: rust-rustyline: please upgrade to v9

[Peter Green]

> Please upgrade to newer upstream release v9, needed by projects I am 
preparing for Debian.

I have prepared an upload of rustyline 9.1.2. However there is one wrinkle
before I upload.

01234567890123456789012345678901234567890123456789012345678901234567890123456789
The new version of rustyline depends on version 3 of fd-lock and debian has
version 2. I could possibly patch the dependency but I'd rather not do that if I
can avoid it. So I looked at updading rust-fd-lock in debian.

rust-fd-lock has no reverse dependencies, but it's first (and only) upload was
only 7 months ago. So I would like to give dkg a heads-up in case a major
version bump interferes with his plans.

I also notice that jgorzen has been working on fd-lock 3 packaging in
debcargo-conf, however he has packaged 3.0.6 which depends on rustix which is
not yet in Debian (currently waiting in new).

So my plan would be

upload fd-lock 3.0.2 and rustyline 9.1.2 now

upload fd-lock 3.0.6 if/when rustix passes NEW

jgorzen, dkg do you have any objections to this plan?

Bug#1018754: telegram-cli: Outdated app that is no longer supported

[Ying-Chun Liu (PaulLiu)]

Hi Axel,

Neither szqdong nor kenorb-contrib is working.
I've tried both.

1. Purge libtgl*, telegram-cli, libtl-parser*, tl-parser.
2. git clone --recursive 
3. ./configure; make
4. ./bin/telegram-cli

And both of them are not working. So I think we might need to really 
look into what causes the failure.


Yours,
Paul

On 2022/10/21 17:05, Axel Beckert wrote:

Hi,

aexlfow...@web.de wrote:

when I start the program it asks for my phone number. When I give it it
says following:
  *** 1661844939.688455 Notification API_64BIT_LOGIN_APP_OUTDATED_39:
You are using an outdated app that is no longer supported. To access
your messages, please update your app to the latest version.

[…]

I don't think it will be fixed,


The original developer clearly seems to have stalled working on it:

https://github.com/vysheng/tg says last commit was on Mar 23, 2016.

But there seem at least two very active forks:

* https://github.com/szqdong/tg
* https://github.com/kenorb-contrib/tg

Last commit in both is from 2022 Jul 26. (It's the same commit of
kenorb — not kenorb-contrib — in both cases.)

I'm though not sure which of these would be better to base the package
on in the future.

Bastian Germann wrote:

Setting appropriate severity. The application is not usable.


Thanks!

Regards, Axel


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1021918: debian-installer: Kernel module blacklisting inconsistent

[Olaf Meeuwissen]

Pascal Hambourg  writes:

> On 17/10/2022 at 13:13, Olaf Meeuwissen wrote:
>> I recently tried this version with hardware that triggers loading of the
>> mt7921e kernel module.  Loading the module fails due to a firmware file
>> load error but the installer starts okay.  However, the installer later
>> crashes when probing for network hardware (when it tries to rmmod the
>> kernel module).
>
> How does the installer crash exactly ? Kernel panic ? Freeze ? Error ?

Freeze.  Even after ten minutes the network hardware probe does not
complete.  FWIW, I have seen an error log as well but that may have
been with Devuan's preview installer for daedalus.

You can still switch VTs but trying to `poweroff` or `reboot` after
starting a shell on VT2 or VT3 will also freeze.  The last bit of the
error can be seen on VT4.

I've attached the installer's syslog.  /dev/sdc is the installer ISO.
The other disks, /dev/sda, /dev/sdb and /dev/nmve0n1 are the machine's
internal disks.  I just ran the installer after the machine was already
installed with the workaround I mentioned in the original bug report.

The error starts at

  Oct 19 23:06:13 check-missing-firmware: removing and loading kernel module 
mt7921e

and looks like what I've seen on VT4.

>> The first issue I ran into was that the documented[1] way to blacklist
>> kernel modules is no longer correct
>>   [1]:
>> https://www.debian.org/releases/testing/amd64/ch05s03.en.html#module-blacklist
>> Instead of
>>mt7921e.blacklist=yes
>> I had to use
>>modprobe.blacklist=mt7921e
>
> /lib/debian-installer-startup.d/S02module-params has the following comment:
>
> # Before udev is started, parse kernel command word for module params of
> # the form module.param=value and register them so they will be used when
> # modules are loaded. Also check for modules to be blacklisted.
>
> But udev is actually started earlier, so the first method does not
> work with modules included in initrd.gz (e.g. storage drivers).

In that case, shouldn't that be mentioned in the installation manual?
Actually, a single method that works for *all* modules, whether in the
initrd.gz or installed later is much preferred.

> However it should work with network driver modules which are installed
> much later.

You may want to double check how the kernel command parse results are
used then.

Or maybe the mt7921e module is in the initrd.gz?
Just checked, it is not.

>> However, upon booting I saw a pile of ATA bus and I/O errors that made
>> me suspicious.  The disk is brand new and a smartmontools extended test
>> reports no errors.
>> I found a /etc/modprobe.d/blacklist.local.conf file with
>>blacklist modprobe
>
> This is a minor bug in
> /lib/debian-installer-startup.d/S02module-params which can be easily
> fixed. However, it should not have any actual impact as "modprobe"
> does not match any kernel module name or alias.

Strange, because removing it made those ATA bus and I/O errors go away,
reproducibly at that.

>> For completeness' sake, the /etc/default/grub file included
>>GRUB_CMDLINE_LINUX="modprobe.blacklist=mt7921e"
>
> As expected.

I have since removed that blacklist statement and installed
firmware-misc-nonfree.  That makes the firmware load without any
trouble.

>> Seeing that the kernel boot argument is added correctly to the GRUB
>> configuration, there is no need to create a file in /etc/modprobe.d/.
>> In addition, the installation manual needs to be updated to use the
>> correct syntax.
>
> If I understand correctly, this is how things work:
>
> The kernel runs /init.
> /init runs /lib/debian-installer/start-udev which starts udevd.
> udevd gets hotplug events and calls modprobe to load matching modules
> included in initrd.gz.
> Then /init exec's /bin/busybox init.

Since there is no mt7921e module in the initrd.gz, in fact no modules
matching mt7, it should not have been loaded at this point according to
your understanding.

> busybox init reads /etc/inittab and runs /sbin/debian-installer-startup.
> debian-installer-startup runs
> /lib/debian-installer-startup.d/S02module-params.
> /lib/debian-installer-startup.d/S02module-params calls
> /bin/register-module for each module parameter or blacklist in the
> kernel command line.

That appears to work but blacklisting syntax is *not* as documented in
the installation manual.

> register-module writes module blacklists in
> /etc/modprobe.d/blacklist.local.conf and module parameters in
> /etc/modprobe.d/local.conf.

The blacklist.local.conf file is created as documented but using the
alternative syntax I had to use leads to the oxymoronic

  blacklist modprobe

entry, trying to tell modprobe to blacklist itself :-)

You mentioned above that's a minor bug and easily fixed.  If so, then
please fix it.

> Later, network driver modules are installed and loaded.

Seeing that the module is not in initrd.gz, this is where it would be
loaded according to your understanding.  Does this step happen *before*
the installer 

Bug#1022210: diffoscope: highlight whitespace-only differences in text data

[Paul Wise]

Package: diffoscope
Version: 224
Severity: wishlist

It would be nice if diffoscope could help highlight that text data
differ only in the whitespace or if they differ in the text too.

The proposal would be that by default diffoscope would use wdiff (or
similar) to compare all line based text buffers (including those
converted from other formats) in order to check for whitespace-only
differences. When there are non-whitespace differences then display the
wdiff (or similar) output, with a comment saying these are differences
in the text after ignoring whitespace. In situations where the text
buffer differs only by whitespace, diffoscope would do a line diff of
the text buffer itself, with a comment saying the text of the two text
buffers was not different and only whitespace changes were present.

Since this check probably won't be useful for all diffs of line based
text buffers, probably there will need to be various heuristics for
when to apply it and when not to apply it, perhaps starting with
applying it to everything and then adding exceptions over time.

This would be useful in some situations like when comparing old
versions of a document with newer versions of a document or similar.
In particular it would have been useful when preparing this mail:

https://lists.debian.org/msgid-search/197a4671e7694c24424b91b4d7288867c0c85d9b.ca...@debian.org

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages diffoscope depends on:
ii  diffoscope-minimal  224

Versions of packages diffoscope recommends:
ii  abootimg 0.6-1+b2
ii  acl  2.3.1-1
ii  androguard   3.4.0~a1-5
ii  apksigner    31.0.2-1
ii  apktool  2.6.1+dfsg.1-2
ii  binutils-multiarch   2.39-8
ii  bzip2    1.0.8-5+b1
ii  caca-utils   0.99.beta20-3
ii  colord   1.4.6-1
ii  coreboot-utils   4.15~dfsg-2
ii  db-util  5.3.1+nmu1
ii  default-jdk [java-sdk]   2:1.11-72
ii  default-jdk-headless 2:1.11-72
pn  device-tree-compiler 
pn  docx2txt 
ii  e2fsprogs    1.46.6~rc1-1+b1
ii  enjarify 1:1.0.3-5
ii  ffmpeg   7:5.1.2-1
ii  fontforge-extras 1:20220308~dfsg-1
pn  fp-utils 
ii  genisoimage  9:1.1.11-3.4
ii  gettext  0.21-9
ii  ghc  9.0.2-4
ii  ghostscript  9.56.1~dfsg-1
ii  giflib-tools 5.2.1-2.5
ii  gnumeric 1.12.52-1
ii  gnupg    2.2.39-1
ii  gnupg-utils  2.2.39-1+b1
pn  hdf5-tools   
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b3
ii  jsbeautifier 1.14.4-1
ii  libarchive-tools 3.6.0-1
pn  libxmlb-dev  
ii  llvm 1:14.0-55.2+b1
ii  lz4 [liblz4-tool]    1.9.4-1
pn  mono-utils   
ii  ocaml-nox    4.13.1-3
pn  odt2txt  
pn  oggvideotools    
ii  openjdk-11-jdk [java-sdk]    11.0.17+8-2
ii  openssh-client   1:9.0p1-1+b2
ii  openssl  3.0.5-4
ii  pgpdump  0.34-1
ii  poppler-utils    22.08.0-2.1
pn  procyon-decompiler   
ii  python3-argcomplete  2.0.0-1
ii  python3-binwalk  2.3.3+dfsg1-2
ii  python3-debian   0.1.48
ii  python3-defusedxml   0.7.1-2
ii  python3-guestfs  1:1.48.4-2+b1
hi  python3-jsondiff 1.1.1-4
ii  python3-pdfminer 20220319+dfsg-1
ii  python3-progressbar  2.5-3
ii  python3-pypdf2   2.11.0-1
ii  python3-pyxattr  0.7.2-2+b1
ii  python3-rpm  4.17.1.1+dfsg-1
ii  python3-tlsh 3.4.4+20151206-1.4+b2
pn  r-base-core  
pn  radare2  
ii  rpm2cpio 4.17.1.1+dfsg-1
ii  sng 

Bug#1022209: diffoscope: highlight text-only differences in HTML files

[Paul Wise]

Package: diffoscope
Version: 224
Severity: wishlist

It would be nice if diffoscope could help highlight that HTML files
differ in the text output or if they differ only in the non-text HTML
bytes like the page title, the stylesheet etc.

The proposal would be that by default diffoscope would convert HTML
files to text, diff that and if there were text differences then
display them, with a comment saying these are differences in the text.
In situations where the text does not differ, diffoscope would do a
line diff of the HTML file itself, with a comment saying the text of
the two files was not different.

This is useful in some situations like when comparing old versions of a
document with newer versions of a document or similar. In particular it
would have been useful when preparing this mail to debian-mentors:

https://lists.debian.org/msgid-search/197a4671e7694c24424b91b4d7288867c0c85d9b.ca...@debian.org

Since there are many different tools for conversion of HTML to text and
each of them have different bugs and features, probably this feature
should allow the user to choose the tool they want to use for this.

   $ head -vn-0 *.html
   ==> bar.html <==
   
   
   bar
   
   
   
   
   
   
   bar
   
   
   
   
   ==> foo.html <==
   
   
   foo
   
   
   
   
   
   
   foo
   
   
   
   
   $ diffoscope foo.html bar.html 
   --- foo.html
   +++ bar.html
   @@ -1,17 +1,17 @@


   -foo
   +bar






   -foo
   +bar



   
   $ diff -u <(w3m -dump foo.html) <(w3m -dump bar.html)
   --- /dev/fd/63   2022-10-22 08:52:33.581676470 +0800
   +++ /dev/fd/62   2022-10-22 08:52:33.585676477 +0800
   @@ -1,2 +1,2 @@
   -foo
   +bar
   
   $ diff -u <(html2text foo.html) <(html2text bar.html)
   --- /dev/fd/63   2022-10-22 08:54:43.793859066 +0800
   +++ /dev/fd/62   2022-10-22 08:54:43.781859049 +0800
   @@ -1 +1 @@
   -foo
   +bar

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages diffoscope depends on:
ii  diffoscope-minimal  224

Versions of packages diffoscope recommends:
ii  abootimg 0.6-1+b2
ii  acl  2.3.1-1
ii  androguard   3.4.0~a1-5
ii  apksigner    31.0.2-1
ii  apktool  2.6.1+dfsg.1-2
ii  binutils-multiarch   2.39-8
ii  bzip2    1.0.8-5+b1
ii  caca-utils   0.99.beta20-3
ii  colord   1.4.6-1
ii  coreboot-utils   4.15~dfsg-2
ii  db-util  5.3.1+nmu1
ii  default-jdk [java-sdk]   2:1.11-72
ii  default-jdk-headless 2:1.11-72
pn  device-tree-compiler 
pn  docx2txt 
ii  e2fsprogs    1.46.6~rc1-1+b1
ii  enjarify 1:1.0.3-5
ii  ffmpeg   7:5.1.2-1
ii  fontforge-extras 1:20220308~dfsg-1
pn  fp-utils 
ii  genisoimage  9:1.1.11-3.4
ii  gettext  0.21-9
ii  ghc  9.0.2-4
ii  ghostscript  9.56.1~dfsg-1
ii  giflib-tools 5.2.1-2.5
ii  gnumeric 1.12.52-1
ii  gnupg    2.2.39-1
ii  gnupg-utils  2.2.39-1+b1
pn  hdf5-tools   
ii  imagemagick  8:6.9.11.60+dfsg-1.3+b3
ii  imagemagick-6.q16 [imagemagick]  8:6.9.11.60+dfsg-1.3+b3
ii  jsbeautifier 1.14.4-1
ii  libarchive-tools 3.6.0-1
pn  libxmlb-dev  
ii  llvm 1:14.0-55.2+b1
ii  lz4 [liblz4-tool]    1.9.4-1
pn  mono-utils   
ii  ocaml-nox    4.13.1-3
pn  odt2txt  
pn  oggvideotools    
ii  openjdk-11-jdk [java-sdk]    11.0.17+8-2
ii  openssh-client   1:9.0p1-1+b2
ii  openssl  3.0.5-4
ii  pgpdump  0.34-1
ii  poppler-utils    

Bug#1022208: direnv: Missing manpage direnv.toml(1)

[Aaron Schrab]

Package: direnv
Version: 2.32.1-1+b1
Severity: normal
X-Debbugs-Cc: aa...@schrab.com

Dear Maintainer,

The main manpage refers to the direnv.toml(1) manpage for information 
about configuration, but this isn't included in the package. Looking at 
the source I see it there, but it doesn't get included in the binary 
package.

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

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

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

direnv recommends no packages.

direnv suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

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

[Paul Wise]

On Fri, 2022-10-21 at 16:55 +0200, Santiago Ruano Rincón wrote:

> This should be solved from the upstream side. I'll file a bug soon.

Excellent, thanks for that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#860275: msp430mcu: invalid paths returned from /usr/bin/msp430mcu-config

[Vagrant Cascadian]

On 2022-10-20, Vagrant Cascadian wrote:
Control: tags 860274 -pending
Control: tags 860275 pending

Er... That's what I meant.

> I've submitted an NMU to DELAYED/10 fixing this issue:
>
> diff -Nru msp430mcu-20120406/debian/changelog 
> msp430mcu-20120406/debian/changelog
> --- msp430mcu-20120406/debian/changelog   2022-04-22 10:18:57.0 
> -0700
> +++ msp430mcu-20120406/debian/changelog   2022-10-20 10:57:45.0 
> -0700
> @@ -1,3 +1,12 @@
> +msp430mcu (20120406-2.3) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +
> +  [ Chris Lamb ]
> +  * Fix invalid paths in /usr/bin/msp430mcu-config. (Closes: #860275)
> +
> + -- Vagrant Cascadian   Thu, 20 Oct 2022 
> 10:57:45 -0700
> +
>  msp430mcu (20120406-2.2) unstable; urgency=medium
>  
>* Non-maintainer upload.
> diff -Nru msp430mcu-20120406/debian/rules msp430mcu-20120406/debian/rules
> --- msp430mcu-20120406/debian/rules   2012-05-10 08:16:44.0 -0700
> +++ msp430mcu-20120406/debian/rules   2022-10-20 10:57:45.0 -0700
> @@ -2,7 +2,8 @@
>  
>  # Package name, source dir and target installation dir.
>  PACKAGE=msp430mcu
> -DESTDIR=$(CURDIR)/debian/$(PACKAGE)/usr
> +TARGET=$(CURDIR)/debian/$(PACKAGE)
> +DESTDIR=$(TARGET)/usr
>  
>  # Uncomment this to turn on verbose mode.
>  #export DH_VERBOSE=1
> @@ -28,6 +29,7 @@
>   dh_installdirs
>  
>   MSP430MCU_ROOT=$(CURDIR) scripts/install.sh $(DESTDIR)
> + sed -i -e 's!$(TARGET)!!g' $(DESTDIR)/bin/msp430mcu-config # Strip 
> build path
>  
>  binary-arch: binary-indep
>  
>
> live well,
>   vagrant


signature.asc
Description: PGP signature

Bug#312552: unrar-free: request for RAR 3.0 format support

[Bastian Germann]

The autopkgtest test cases 0002 to 0004 need an update for the 0.1.x versions.
In 0002, I have corrected the CRC for the rar-contained file.
In 0003 and 0004, I have reworked the expected valgrind exitcode for the "list" 
operation.#!/bin/sh
#
# Test CVE-2017-14120

setUp() {
uudecode >archive.rar <#!/bin/sh
#
# Test CVE-2017-14122

setUp() {
uudecode > unrar-gpl-stack-overread.rar <#!/bin/sh
#
# Test CVE-2017-14121

setUp() {
uudecode > unrar-gpl-nullptr.rar < 
"$AUTOPKGTEST_TMP"/0004-CVE-2017-14121.log 2>&1
grep -q '*** Segmentation fault' 
"$AUTOPKGTEST_TMP"/0004-CVE-2017-14121.log
assertNotEquals "catchsegv value" 0 $?

valgrind --error-exitcode=121 --track-origins=yes unrar-free --extract 
unrar-gpl-nullptr.rar
assertNotEquals "Valgrind status code" 121 $?
}

. /usr/bin/shunit2

Bug#901468: madlib FTCBFS: abuses AC_CHECK_FILE

[Vagrant Cascadian]

On 2018-06-13, Helmut Grohne wrote:
> madlib fails to cross build from source, because it abuses AC_CHECK_FILE
> to search for headers. The macro is meant for searching files on the
> host system. Certainly madlib won't need any headers at runtime, so you
> actually want to check headers on the build system. A simple "test -e"
> is suitable for that. Please consider applying the attached patch.

Tried this patch before my recent QA upload of 1.3.0-3, but was unable
to successfully cross-build on amd64 for an arm64 host; the configure
script got tripped up...

I did switch from cdbs to dh and had to disable autoreconf, so that
might need more changes to get it to cross-build...

live well,
  vagrant

> --- madlib-1.3.0.orig/configure.ac
> +++ madlib-1.3.0/configure.ac
> @@ -281,7 +281,7 @@
>  
>  dnl Check for gmm++ linear solver
>  if test "x$enable_gmm" != "xno"; then
> -  AC_CHECK_FILE(${srcdir}/Contrib/gmm/gmm.h,GMM="yes")
> +  AS_IF([test -e "${srcdir}/Contrib/gmm/gmm.h"],[GMM="yes"])
>if test "x${GMM}" = "xyes"; then
>  MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_GMM_"
>  MAdLib_INCLUDES="${MAdLib_INCLUDES} -I\$(top_srcdir)/Contrib/gmm "
> @@ -301,7 +301,7 @@
>if test "x${GMSH_PREFIX}" != "x"; then
>  LDFLAGS="-L${GMSH_PREFIX}/lib ${LDFLAGS}"
>fi
> -  AC_CHECK_FILE("${GMSH_PREFIX}/include/gmsh/Gmsh.h",GMSH="yes") 
> +  AS_IF([test -e "${GMSH_PREFIX}/include/gmsh/Gmsh.h"],[GMSH="yes"])
>  dnl  AC_CHECK_LIB(Gmsh,main,GMSH="yes",[],-lGmsh)
>if test "x${GMSH}" = "xyes"; then
>  MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_GMSH_"
> @@ -329,7 +329,7 @@
>if test "x${OCC_PREFIX}" != "x"; then
>  LDFLAGS="-L${OCC_PREFIX}/lib ${LDFLAGS}"
>fi
> -dnl  AC_CHECK_FILE("${OCC_PREFIX}/inc/Geom_Curve.hxx",OCC="yes") 
> +dnl  AS_IF([test -e "${OCC_PREFIX}/inc/Geom_Curve.hxx"],[OCC="yes"])
>AC_CHECK_LIB(TKernel,main,OCC="yes",[],-lTKernel)
>if test "x${OCC}" = "xyes"; then
>  MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_OCC_"
> @@ -353,7 +353,7 @@
>  
>  dnl Check for ANN, the Approximate Nearest Neighbor library
>  if test "x$enable_ann" != "xno"; then
> -  AC_CHECK_FILE(${srcdir}/Contrib/ANN/include/ANN/ANN.h,ANN="yes") 
> +  AS_IF([test -e "${srcdir}/Contrib/ANN/include/ANN/ANN.h"],[ANN="yes"])
>if test "x${ANN}" = "xyes"; then
>  MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_ANN_"
>  AC_DEFINE(_HAVE_ANN_)
> @@ -372,7 +372,7 @@
>  
>  dnl Check for Mathex
>  if test "x$enable_mathex" != "xno"; then
> -  AC_CHECK_FILE(${srcdir}/Contrib/mathex/mathex.h,MATHEX="yes")
> +  AS_IF([test -e "${srcdir}/Contrib/mathex/mathex.h"],[MATHEX="yes"])
>if test "x${MATHEX}" = "xyes"; then
>  MAdLib_DEFS="${MAdLib_DEFS} -D_HAVE_MATHEX_"
>  MAdLib_INCLUDES="${MAdLib_INCLUDES} -I\$(top_srcdir)/Contrib/mathex "


signature.asc
Description: PGP signature

Bug#1022207: ITP: pysocks -- Lets you send traffic through SOCKS proxy servers

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

 It is a modern fork of SocksiPy with bug fixes and extra
 features. Acts as a drop-in replacement to the socket module.
 Seamlessly configure SOCKS proxies for any socket object by
 calling socket_object.set_proxy().
 .
 Features:
  - SOCKS proxy client for Python 2.7 and 3.4+
  - TCP supported, UDP mostly supported (issues may occur in
some edge cases).
  - HTTP proxy client included but not supported or recommended
(you should use requests', or your HTTP client's, own HTTP
proxy interface).
* Package name: pysocks
  Version : 1.7.0
  Upstream Author :  Anorov 
* URL : https://github.com/Anorov/PySocks
* License : BSD-3-clause
  Programming Lang: Python
  Description : Lets you send traffic through SOCKS proxy servers

 Note:
 package is a required dependency for packaging from
 https://github.com/sherlock-project/sherlock

Bug#724014: pavucontrol: Output settings are forgotten and must be set again

[Gerard ROBIN]

Same issue with bookworm but not with bullseye.
kernel: linux-image-5.19.0-2-amd64  5.19.11-1  Linux 5.19 for 64-bit PCs 
(signed)

-- 
Gerard
___
***
Created with Mutt  2.2.7
under Debian Linux BOOKWORM
***

Bug#1022205: node-undici: Fails on riscv64

[Jérémy Lal]

Package: node-undici
Version: 5.11.0+dfsg1+~cs20.10.9-1
Severity: important

Hi,

https://ci.debian.net/data/autopkgtest/unstable/riscv64/n/node-undici/27369429/log.gz

there is something going on with wasm on riscv64, probably.

Note that some nodejs tests fail on riscv64 because of that.

This is somewhat "important", at least it will be important, eventually.

Jérémy



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

Kernel: Linux 6.0.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 node-undici depends on:
ii  node-busboy  1.6.0+~cs2.6.0-2

node-undici recommends no packages.

node-undici suggests no packages.

-- no debconf information

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

[Miguel A. Vallejo]

Hello!

A new upgrade gave me libfaad2 2.10.1-1 and now all videos sound nice.

Thank you.

Bug#1022178: safe: Import new version

[matthias . geiger1024]

done.

thanks :)


21. Okt. 2022, 06:10 von b...@debian.org:

> Source: safe
> Version: 1.0.1-1
>
> Please import a new version so that I can make a source-only upload.
> Either a new revision or a new upstream version.
>

Bug#991266: postinst: Can't exec systemctl: No such file or directory

[Hilmar Preuße]

Am 19.07.2021 um 10:23 teilte Lorenzo Puliti mit:

Hi Francesco,

I had a weird issue when removing proftp recently. I could completely 
remove the package (not purge), i.e. all binaries are gone. I noticed 
that the propftp server process was not stopped and kept running. I'm 
pretty sure this is not intended.


I propose the rewrite our postinst script & debian/rules. I pushed my 
proposal into branch master_start_using_dhinstallsystemd on salsa, 
please be so kind to have a look.


Thanks,
  Hilmar


[...]
Setting up proftpd-core (1.3.7b+dfsg-1) ...
usermod: no changes
Can't exec "systemctl": No such file or directory at 
/usr/bin/deb-systemd-invoke line 110.
sh: 1: systemctl: not found
Can't exec "systemctl": No such file or directory at 
/usr/bin/deb-systemd-invoke line 94.
proftpd.service is a disabled or a static unit not running, not starting it.
insserv: warning: current start runlevel(s) (empty) of script `proftpd' 
overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `proftpd' 
overrides LSB defaults (0 1 6).
insserv: Script `lvm2' has overlapping Default-Start and Default-Stop runlevels 
(S) and (S). This should be fixed.
Stopping ftp server: proftpd.
Starting ftp server: proftpd.
[...]




--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#872816: radicale wsgi example not usable

[Borden]

> I tried following these instructions and grafting this file at 
> https://gist.github.com/return42/47ac8aabd19eaad0f10979761d0611a1 into my 
> config. I have authentication set to pwauth, not a static file. Apache spawns 
> a login window when I use the uWSGI configuration, but it throws a 500 error 
> (due to PermissionError: [Errno 13] Permission denied: 
> '/var/lib/radicale/collections') when I use only mod_wsgi.

So I know I'm making a nuisance out of myself. But I hope that, once I 
understand what's going on and how to fix it, I can improve the code and/or 
documentation to make Radicale more useful for future generations.

My DAV folders are permissioned to uid=radicale & gid=radicale & perm=rwxrwx--- 
(770). It should be documented whether this is too restrictive or permissive, 
since this _is_ an  Internet-facing service.

The above config  works with the 'recommended' uWSGI implementation. However, I 
can't figure out which mod_wsgi apache.conf settings will get Radicale to run 
with radicale:radicale permissions, so Linux quite appropriately refuses to let 
it access the DAV folders.

One suggestion is to change the DAV folder permissions to www-data:www-data 
(https://wiki.debian.org/Radicale#Deliver_Radicale_through_Apache) which 
strikes me as unsafe (fixing wiki documentation is also on my to-do list).

I also discovered the undocumented (!) /etc/default/radicale file, which sets 
the "--daemon" option. Does this have to be disabled for mod_wsgi?

Bug#794821: libwxbase3.0-0: segmentation fault (SIGSEGV) with gnuplot5

[Vincent Lefevre]

Control: reassign -1 libwxbase3.2-0 3.2.1+dfsg-1

On 2022-10-21 09:00:13 -0400, Scott Talbert wrote:
> As of yesterday, gnuplot has been rebuilt using wxWidgets 3.2.  Can you
> please try again with gnuplot 5.4.4+dfsg1-2 and see if the crash still
> exists?

Yes, the crash still occurs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1022204: FTBFS because nimgrep needs libpcre3

[Sergio Durigan Junior]

On Friday, October 21 2022, I wrote:

> I will soon attach a patch to fix the problem.

Here it is.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index f8dd0ad79..8654f42cb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+nim (1.6.8-2) UNRELEASED; urgency=medium
+
+  * d/control: Add libpcre3 to B-D and to nim's Dependency list.
+(Closes: #1022204)
+
+ -- Sergio Durigan Junior   Fri, 21 Oct 2022 16:58:30 
-0400
+
 nim (1.6.8-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/control b/debian/control
index cf9ea3932..16d606696 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,8 @@ Maintainer: Federico Ceratto 
 Build-Depends: debhelper-compat (= 13),
  help2man (>= 1.46.4),
  libssl-dev,
- libssl1.1
+ libssl1.1,
+ libpcre3,
 Standards-Version: 4.6.1
 Homepage: https://nim-lang.org/
 Vcs-Git: https://salsa.debian.org/debian/nim.git
@@ -16,7 +17,8 @@ Package: nim
 Architecture: alpha amd64 arm64 armel armhf hppa hurd-i386 i386 ia64 m68k mips 
mips64el mipsel powerpc powerpcspe ppc64 ppc64el riscv64 sh4 sparc64 x32
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- libssl1.1
+ libssl1.1,
+ libpcre3,
 Suggests: nim-doc
 Recommends: build-essential,
  gcc,


signature.asc
Description: PGP signature

Bug#1000922: upgrading llvmlite to llvm-13

[Diane Trout]

Hi,

I found a pull request that starts the process of upgrading llvmlite to
llvm-12 or -13.
https://github.com/numba/llvmlite/pull/802

I modified it to work with our llvmlite 0.39.1 package and was able to
build llvmlite and have it's tests pass on x86 64.

The llvmlite upstream developers are concerned about releasing it
because in their experience they have various compile errors on unusual
architectures.

Though I'm having those with the llvm-11 version too, so who knows.

I was thinking that releasing it to Debian's buildd would help upstream
see which architectures are having problems with the migration to llvm-
13

I've been trying to build and run numba's tests, it's been a bit
difficult to tell what's failures are new because of building against
llvm-13 and which are because there's some failures due to the
autopkgtest environment being different from what upstream expects.

I think there's only a couple of test failures out of the about 20 I'm
trying to fix that are due to the llvm-13 update.

Since there's already some numba test failures with ppc64el and amdel
even with the llvm-11 version of llvmlite, I feel like releasing the -
13 version of llvmlite isn't going to make things any worse for numba.

So should we uploading a version of llvmlite with the -13 compatibility
patch?

They both fell out of testing, and it'd be really bad for the
scientific python ecosystem if we don't get numba shipped in bullseye.

Diane
From 1d928ebcd59b23b5050234a2bf71f9be7f5f6bd1 Mon Sep 17 00:00:00 2001
From: Richard Barnes 
Date: Wed, 1 Dec 2021 10:29:08 -0700
Subject: [PATCH] Enable LLVM-12 and LLVM-13

---
 ffi/build.py   |  5 ++---
 ffi/targets.cpp|  2 ++
 llvmlite/tests/test_binding.py | 19 ---
 3 files changed, 20 insertions(+), 6 deletions(-)

--- a/ffi/build.py
+++ b/ffi/build.py
@@ -163,9 +163,8 @@
 print(msg)
 print(warning + '\n')
 else:
-
-if not out.startswith('11'):
-msg = ("Building llvmlite requires LLVM 11.x.x, got "
+if not (out.startswith('11') or out.startswith('12') or out.startswith('13')):
+msg = ("Building llvmlite requires LLVM 11-13.x.x, got "
"{!r}. Be sure to set LLVM_CONFIG to the right executable "
"path.\nRead the documentation at "
"http://llvmlite.pydata.org/ for more information about "
--- a/ffi/targets.cpp
+++ b/ffi/targets.cpp
@@ -204,7 +204,9 @@
 rm = Reloc::DynamicNoPIC;
 
 TargetOptions opt;
+#if LLVM_VERSION_MAJOR < 12
 opt.PrintMachineCode = PrintMC;
+#endif
 opt.MCOptions.ABIName = ABIName;
 
 bool jit = JIT;
--- a/llvmlite/tests/test_binding.py
+++ b/llvmlite/tests/test_binding.py
@@ -18,6 +18,16 @@
 from llvmlite.tests import TestCase
 
 
+def clean_string_whitespace(x: str) -> str:
+# Remove trailing whitespace from the end of each line
+x = re.sub(r"\s+$", "", x, flags=re.MULTILINE)
+# Remove intermediate blank lines
+x = re.sub(r"\n\s*\n", r"\n", x, flags=re.MULTILINE)
+# Remove extraneous whitespace from the beginning and end of the string
+x = x.strip()
+return x
+
+
 # arvm7l needs extra ABI symbols to link successfully
 if platform.machine() == 'armv7l':
 llvm.load_library_permanently('libgcc_s.so.1')
@@ -555,7 +565,10 @@
 bd = ir.IRBuilder(fn.append_basic_block(name="<>!*''#"))
 bd.ret(ir.Constant(ir.IntType(32), 12345))
 asm = str(mod)
-self.assertEqual(asm, asm_nonalphanum_blocklabel)
+self.assertEqual(
+clean_string_whitespace(asm),
+clean_string_whitespace(asm_nonalphanum_blocklabel)
+)
 
 def test_global_context(self):
 gcontext1 = llvm.context.get_global_context()
@@ -640,7 +653,7 @@
 def test_version(self):
 major, minor, patch = llvm.llvm_version_info
 # one of these can be valid
-valid = [(11,)]
+valid = [(11,), (12,), (13,)]
 self.assertIn((major,), valid)
 self.assertIn(patch, range(10))
 
--- a/ffi/passmanagers.cpp
+++ b/ffi/passmanagers.cpp
@@ -17,9 +17,6 @@
 #include "llvm-c/Transforms/IPO.h"
 #include "llvm-c/Transforms/Scalar.h"
 #include "llvm/IR/LegacyPassManager.h"
-#if LLVM_VERSION_MAJOR > 11
-#include "llvm/IR/RemarkStreamer.h"
-#endif
 #include "llvm/IR/LLVMRemarkStreamer.h"
 #include "llvm/Remarks/RemarkStreamer.h"
 #include "llvm/Transforms/IPO.h"


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

Bug#1022204: FTBFS because nimgrep needs libpcre3

[Sergio Durigan Junior]

Source: nim
Version: 1.6.8-1
Severity: serious

Hi,

One of the reasons nim is currently FTBFSing is because the nimgrep
program attempts to load libpcre.so.3 but fails.  The package needs to
explicitly depend on libpcre3.

I will soon attach a patch to fix the problem.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1022203: openpgp-applet: since upstream move from Alioth to Salsa, uscan fails

[Clément Hermann]

Source: openpgp-applet
Version: 1.1-3
Severity: normal

Hi,

Since some time, the debian/watch for opengpgp-applet can't get
signatures.
The signatures are in the /upload/ subdirectory, which is unpredicatable:

Looking at 
https://salsa.debian.org/openpgp-applet-team/openpgp-applet/-/archive/OpenPGP_Applet-1.1/openpgp-applet-OpenPGP_Applet-1.1.tar.gz,
 we can get the download link for tarballs, but to get the signature for this 
file, one has to follow the link to the release desc:
https://salsa.debian.org/openpgp-applet-team/openpgp-applet/-/tags/OpenPGP_Applet-1.1

in which the signature can be downloaded: 
https://salsa.debian.org/openpgp-applet-team/openpgp-applet/uploads/77ee3004f99643f3a2275317354bf950/OpenPGP_Applet-1.1.tar.gz.asc

This is fine for humans who will figure it out, but bad for automation.

Maybe there is a way to parse a specific page with the version name with
uscan? Didn't find an obvious way, but would welcome pointers.

Cheers

-- 
nodens

Bug#1022202: linux: rebuild upgrades of running kernel breaks module loading

[Salvatore Bonaccorso]

Control: forcemerge 1003210 -1 

Hi Christian,

On Fri, Oct 21, 2022 at 10:40:22PM +0200, Christian Göttsche wrote:
> source: linux
> version: 6.0.2-1+b1
> severity: important
> 
> Upgrading the package of the currently running kernel, e.g. for
> rebuilds like 6.0.2-1+b1, breaks module loading until the next reboot.
> Trying to load modules by applications, e.g. qemu, will fail:
> 
> Oct 21 22:23:23 debianHome kernel: BPF:  type_id=1457 bits_offset=0
> Oct 21 22:23:23 debianHome kernel: BPF:
> Oct 21 22:23:23 debianHome kernel: BPF: Invalid name
> Oct 21 22:23:23 debianHome kernel: BPF:
> Oct 21 22:23:23 debianHome kernel: failed to validate module [tun] BTF: -22
> 
> Maybe this is hard to fix, due to signature changes, so maybe the
> postinst should print a strong reboot recommendation?

I'm going to merge this with the related #1003210 .

Regards,
Salvatore

Bug#1022200: cpan: cannot check signatures

[Vincent Lefevre]

On 2022-10-21 22:28:14 +0200, Vincent Lefevre wrote:
> It is no longer possible to install modules from CPAN because
> signatures can no longer be checked. There was no such issue
> with 5.34. This is a major regression; in particular, the
> locally installed modules need to be reinstalled after the
> upgrade.

As a workaround, one can run "gpg --recv-keys E247329948EA8380",
then all the modules can be installed. But I suppose that the key
should be loaded by default as before.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1022202: linux: rebuild upgrades of running kernel breaks module loading

[Christian Göttsche]

source: linux
version: 6.0.2-1+b1
severity: important

Upgrading the package of the currently running kernel, e.g. for
rebuilds like 6.0.2-1+b1, breaks module loading until the next reboot.
Trying to load modules by applications, e.g. qemu, will fail:

Oct 21 22:23:23 debianHome kernel: BPF:  type_id=1457 bits_offset=0
Oct 21 22:23:23 debianHome kernel: BPF:
Oct 21 22:23:23 debianHome kernel: BPF: Invalid name
Oct 21 22:23:23 debianHome kernel: BPF:
Oct 21 22:23:23 debianHome kernel: failed to validate module [tun] BTF: -22

Maybe this is hard to fix, due to signature changes, so maybe the
postinst should print a strong reboot recommendation?

Bug#1022174: linux-image-6.0.0-1-amd64: nvidia 470 modul builds successfully, but does not get loaded on boot -> no X

[Salvatore Bonaccorso]

Hi Michael,

On Fri, Oct 21, 2022 at 02:41:33PM +0200, Michael Hatzold wrote:
> Package: src:linux
> Version: 6.0.2-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Installing linux-image 6.0.0.1 (may not be the *exact* nam, but you'll figure 
> it out
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>* What was the outcome of this action?
> The nvidia470 module seems to be build (?), no error message
> 
> On reeboot with the newwly installed kernel there are red *Failed* messages. 
> The first one stating:
> 
> *Failed*  start load Kernel modules (or the like)
> 
> The boot continues with some more *Failed* messages
> 
>* What outcome did you expect instead?
> 
> all neccessary modules, including a working nvidia 470 modul should be loaded
> 
> 
> *** End of the template - remove these template lines ***
> 
> 
> BTW:
> I am writing this report on a terminal (i.e. no X -> ctrl-Alt_F2)
> reportbug asks *repeatedly* for sudo PW (for the kernel log) (I don't want to 
> use 'sudo' which is not configured for that reason)
> I am sure most people will give up writing a bug report at this point.
> 
> Apart from this:
> I hope the internal reportbug-email works (which it didn't in recent times) 
> because I don't know - being here now outside of X - how to forward it to my 
> email client. 

Reassigning this bug to src:nvidia-graphics-drivers-tesla-470.

Andreas, there should as far I understand #1021974 already a patch to
restore compatibility with 6.0 kernel.

Regards,
Salvatore

Bug#1022174: Acknowledgement (linux-image-6.0.0-1-amd64: nvidia 470 modul builds successfully, but does not get loaded on boot -> no X)

[Diederik de Haas]

Control: reassign -1 nvidia-graphics-drivers-tesla-470 470.141.03-2
Control: severity -1 normal
Control: merge -1 1021974

On Friday, 21 October 2022 22:13:35 CEST mh wrote:
> 2> /var/lib/dkms/nvidia-tesla-470/470.141.03/build/nvidia/nv-acpi.c:270:43:
> 2> error: ‘struct acpi_device’ has no member named ‘children’
> 2> /var/lib/dkms/nvidia-tesla-470/470.141.03/build/nvidia/nv-acpi.c:273:50:
> 2> error: ‘struct acpi_device’ has no member named ‘node’; did you mean
> 2> ‘fwnode’?
> 2>
> /usr/src/linux-headers-6.0.0-1-common/include/linux/compiler_types.h:295:27
> : 2> error: expression in static assertion is not an integer

Sounds like https://bugs.debian.org/1021974 (doesn't work with kernel 6.0), 
thus reassigning and merging accordingly

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

Bug#1022200: cpan: cannot check signatures

[Vincent Lefevre]

Package: perl
Version: 5.36.0-4
Severity: grave
Justification: renders package unusable

It is no longer possible to install modules from CPAN because
signatures can no longer be checked. There was no such issue
with 5.34. This is a major regression; in particular, the
locally installed modules need to be reinstalled after the
upgrade.

Example:

Fetching with HTTP::Tiny:
https://cpan.org/modules/03modlist.data.gz
Reading '/home/vinc17/.cpan/sources/modules/03modlist.data.gz'
DONE
Writing /home/vinc17/.cpan/Metadata
Running install for module 'ReadDir'
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/S/SA/SAMV/ReadDir-0.03.tar.gz
CPAN: Digest::SHA loaded ok (v6.02)
Fetching with HTTP::Tiny:
https://cpan.org/authors/id/S/SA/SAMV/CHECKSUMS
CPAN: Module::Signature loaded ok (v0.88)
gpg: Signature made 2021-11-21T22:42:22 CET
gpg:using RSA key B6A1739063760CCA
gpg: Can't check signature: No public key

Signature for file /home/vinc17/.cpan/sources/authors/id/S/SA/SAMV/CHECKSUMS 
could not be verified for an unknown reason. Distribution id = 
S/SA/SAMV/ReadDir-0.03.tar.gz
CPAN_USERID  SAMV (Sam Vilain )
CALLED_FOR   ReadDir
CHECKSUM_STATUS 
CONTAINSMODS ReadDir
UPLOAD_DATE  2004-06-25
incommandcolor 1
localfile
/home/vinc17/.cpan/sources/authors/id/S/SA/SAMV/ReadDir-0.03.tar.gz
mandatory1
negative_prefs_cache 0
prefsHASH(0x55c2dfe1e9f8)
reqtype  c

Module::Signature verification returned value 0E0

The manual says for this case: Cannot verify the
OpenPGP signature, maybe due to the lack of a network connection to
the key server, or if neither gnupg nor Crypt::OpenPGP exists on the
system. You probably want to analyse the situation and if you cannot
fix it you will have to decide whether you want to stop this session
or you want to turn off signature verification. The latter would be
done with the command 'o conf init check_sigs'

Signature for S/SA/SAMV/CHECKSUMS could not be verified for an unknown reason. 
Distribution id = S/SA/SAMV/ReadDir-0.03.tar.gz

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
merged-usr: no
Architecture: amd64 (x86_64)

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

Versions of packages perl depends on:
ii  dpkg   1.21.9+b1
ii  libperl5.365.36.0-4
ii  perl-base  5.36.0-4
ii  perl-modules-5.36  5.36.0-4

Versions of packages perl recommends:
ii  netbase  6.4

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-perl-perl   1.0303-2.1
ii  make 4.3-4.1
ii  perl-doc 5.36.0-4

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1022201: libflac12 compiled without arm64 or i386 improvements

[Martijn van Beurden]

Package: libflac12
Version: 1.4.1-2

The 'packaging rules' list that only amd64 and ppc64 get asm
optimisations, all other platforms get the configuration option
--disable-asm-optimizations. Why is this? This badly hurts execution
speed on arm64 and i386.

Bug#1022174: Acknowledgement (linux-image-6.0.0-1-amd64: nvidia 470 modul builds successfully, but does not get loaded on boot -> no X)

[mh]

Addidional Info 
(Error while building modul after installen new kernel version
linux-image-6.0.0-1-amd64 amd64 6.0.2-1+b1 this evening)

Still no working Module:
on boot first error: Failed to start Load Kernel Modules


Building module:
Cleaning build area...
unset ARCH; env NV_VERBOSE=1 make -j2 modules
KERNEL_UNAME=6.0.0-1-amd64..(bad exit status: 2)
Error! Bad return status for module build on kernel: 6.0.0-1-amd64
(x86_64) Consult
/var/lib/dkms/nvidia-tesla-470/470.141.03/build/make.log for more
information.

*



$ cat /var/lib/dkms/nvidia-tesla-470/470.141.03/build/make.log | grep
error

NV_CONFTEST_CFLAGS=-O2 -D__KERNEL__ -DKBUILD_BASENAME="#conftest87977"
-DKBUILD_MODNAME="#conftest87977" -nostdinc -isystem
/usr/lib/gcc/x86_64-linux-gnu/12/include
-I/lib/modules/6.0.0-1-amd64/source/arch/x86/include/asm/mach-default
-I/lib/modules/6.0.0-1-amd64/source/include/asm-x86/mach-default
-I/lib/modules/6.0.0-1-amd64/build/include2
-I/lib/modules/6.0.0-1-amd64/build/include -include
/lib/modules/6.0.0-1-amd64/build/include/generated/autoconf.h
-I/lib/modules/6.0.0-1-amd64/source/arch/x86/include
-I/lib/modules/6.0.0-1-amd64/source/arch/x86/include/uapi
-I/lib/modules/6.0.0-1-amd64/build/arch/x86/include/generated
-I/lib/modules/6.0.0-1-amd64/build/arch/x86/include/generated/uapi
-I/lib/modules/6.0.0-1-amd64/source/include
-I/lib/modules/6.0.0-1-amd64/source/include/uapi
-I/lib/modules/6.0.0-1-amd64/source/include/xen
-I/lib/modules/6.0.0-1-amd64/build/include/generated/uapi -mfentry
-DCC_USING_FENTRY
-I/var/lib/dkms/nvidia-tesla-470/470.141.03/build/common/inc
-I/var/lib/dkms/nvidia-tesla-470/470.141.03/build -Wall -MD
-Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE
-DNVRM -DNV_VERSION_STRING=\"470.141.03\" -Wno-unused-function
-Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel
-DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0
-DNV_KERNEL_INTERFACE_LAYER -fno-pie -Wall -Wundef -Wno-trigraphs
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE
-Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1
-mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3
-mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel
-Wno-sign-compare -fno-asynchronous-unwind-tables
-mindirect-branch=thunk-extern -mindirect-branch-register
-mindirect-branch-cs-prefix -mfunction-return=thunk-extern
-fno-jump-tables -mharden-sls=all -fno-delete-null-pointer-checks
-Wno-frame-address -Wno-format-truncation -Wno-format-overflow
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races
-Wframe-larger-than=2048 -fstack-protector-strong -Wno-array-bounds
-Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable
-Wno-unused-const-variable -Wno-dangling-pointer
-ftrivial-auto-var-init=zero -fno-stack-clash-protection -pg
-mrecord-mcount -mfentry -DCC_USING_FENTRY
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign
-Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow
-Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than
-fno-strict-overflow -fno-stack-check -fconserve-stack
-Wno-packed-not-aligned -g KBUILD_CFLAGS=-Wall -Wundef
-Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -fshort-wchar -fno-PIE
-Werror=implicit-function-declaration -Werror=implicit-int
-Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx
-mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1
-falign-loops=1 -mno-80387 -mno-fp-ret-in-387
-mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic
-mno-red-zone -mcmodel=kernel -Wno-sign-compare
-fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern
-mindirect-branch-register -mindirect-branch-cs-prefix
-mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all
-fno-delete-null-pointer-checks -Wno-frame-address
-Wno-format-truncation -Wno-format-overflow
-Wno-address-of-packed-member -O2 -fno-allow-store-data-races
-Wframe-larger-than=2048 -fstack-protector-strong -Wno-array-bounds
-Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable
-Wno-unused-const-variable -Wno-dangling-pointer
-ftrivial-auto-var-init=zero  -fno-stack-clash-protection -pg
-mrecord-mcount -mfentry -DCC_USING_FENTRY
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign
-Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow
-Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than
-fno-strict-overflow -fno-stack-check -fconserve-stack
-Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned -g gcc-12
-Wp,-MMD,/var/lib/dkms/nvidia-tesla-470/470.141.03/build/nvidia/.nv.o.d
-nostdinc -I/usr/src/linux-headers-6.0.0-1-common/arch/x86/include
-I./arch/x86/include/generated
-I/usr/src/linux-headers-6.0.0-1-common/include -I./include

Bug#1022199: apt: certificate verification fails after adding custom root certificates through ca-certificates

[Marc Riudalbas Clemente]

Package: apt
Version: 2.5.3+b1
Severity: important
X-Debbugs-Cc: marc.riudalbas.cleme...@aiticon.com

Dear Maintainer,

*** What led up to the situation?

We need to install CA certificates to our servers so we can access to
services which are running with certificates singed by our CA. If we
dont, we can not use them. Example:

$ docker login dockerregistry.aiticon.net
Username: ait-docker
Password:
Error response from daemon: Get 
"https://dockerregistry.aiticon.net/v2/": x509: certificate signed by 
unknown authority


After installing custom root certificates through ca-certificates, apt
complains about other certificates (when pulling packages through https
sources.lists):

This is what we have done so far:

* We installed our CA and its intermediate in a fresh Vanilla-Bullseye
this way:

* Create our own directory to store CA and intermediate:
$ sudo mkdir -p /usr/share/ca-certificates/aiticon.net

* saved the certificates files under the created folder:
$ cat <<_EOF_ |sudo tee 
/usr/share/ca-certificates/aiticon.net/Aiticon_Trust_PKI_intermediate_east.crt

-BEGIN CERTIFICATE-
X
-END CERTIFICATE-

* Did the same for the following files
/usr/share/ca-certificates/aiticon.net/Aiticon_Trust_PKI_root.crt
/usr/share/ca-certificates/aiticon.net/Aiticon_Trust_PKI_intermediate_west.crt
/usr/share/ca-certificates/aiticon.net/Aiticon_Trust_PKI_intermediate_east.crt

* The certificates are there:
$ ls -lh
total 12K
-rw-r--r-- 1 root root 2,1K 18. Okt 13:46 
Aiticon_Trust_PKI_intermediate_east.crt
-rw-r--r-- 1 root root 2,1K 18. Okt 13:45 
Aiticon_Trust_PKI_intermediate_west.crt

-rw-r--r-- 1 root root 2,1K 18. Okt 13:45 Aiticon_Trust_PKI_root.crt

* Added the following lines in /etc/ca-certificates.conf
$ cat <<_EOF_ |sudo tee --append /etc/ca-certificates.conf
aiticon.net/Aiticon_Trust_PKI_root.crt
aiticon.net/Aiticon_Trust_PKI_intermediate_west.crt
aiticon.net/Aiticon_Trust_PKI_intermediate_east.crt
_EOF_

* Updated the CA Certificates:
$ sudo update-ca-certificates
Updating certificates in /etc/ssl/certs...
3 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

* After doing this, we can successfully use our services with the
installed signed certificates:

* Restart the docker service so it notices the are new CAs in the system
$ sudo systemctl restart docker

* Try docker login again
$ docker login dockerregistry.aiticon.net
Username: ait-docker
Password:
WARNING! Your password will be stored unencrypted in 
/home/aiticon/.docker/config.json.

Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

* And now, when executing a simple apt-get update, the certificate
verification for other https lists fail. THIS HAPPENS WITH ALL sources.list,
not only with docker (this is only an example):
$ sudo apt update
Err:3 https://download.docker.com/linux/debian bullseye InRelease
  Certificate verification failed: The certificate is NOT trusted. The 
certificate issuer is unknown.  Could not handshake: Error in the 
certificate verification. [IP: 13.225.78.127 443]



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

* Deleting again the CAs from /etc/ca-certificates.conf and running
update-ca-certificates again leads to the situation from the
beggining:

- apt works propperly, even with https source lists
- we cant use our services, because the CA is not known in the system

*** What outcome did you expect instead?

* We expected to be able to use all our services running with our CA, 
because we installed the CA in our system.
* We expected that the command apt update updates the package lists 
correctly.


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: 

Bug#1022042: linux-image-5.10.0-19-amd64: amd computers with integrated graphics (ryzen 5 3400G) don't boot with this kernel version

[George Ramos]

Package: src:linux
Version: 5.10.149-1
Followup-For: Bug #1022042
X-Debbugs-Cc: m...@duck.com

Dear Maintainer,

I just updated to the new kernel linux-image-5.10.0-19-amd64 (ver 5.10.149-1)
And when the system was trying to boot(but never did), I just got this
messages:

[14.020140] [drm:drm_atomic_helper_wait_for_flip_done [drm_dkms_helper]]
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[24.260069] [drm:drm_atomic_helper_wait_for_flip_done [drm_dkms_helper]]
*ERROR* [CRTC:65:crtc-1] flip_done timed out
[34.500079] [drm:drm_atomic_helper_wait_for_dependencies [drm_dkms_helper]]
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[44.740026] [drm:drm_atomic_helper_wait_for_dependencies [drm_dkms_helper]]
*ERROR* [CRTC:62:crtc-1] flip_done timed out
[54.980073] [drm:drm_atomic_helper_wait_for_dependencies [drm_dkms_helper]]
*ERROR* [PLANE:48:plane-2] flip_done timed out
[65.220054] [drm:drm_atomic_helper_wait_for_dependencies [drm_dkms_helper]]
*ERROR* [PLANE:52:plane-3] flip_done timed out
[75.460064] [drm:drm_atomic_helper_wait_for_flip_done [drm_dkms_helper]]
*ERROR* [CRTC:62:crtc-0] flip_done timed out
[85.700050] [drm:drm_atomic_helper_wait_for_flip_done [drm_dkms_helper]]
*ERROR* [CRTC:65:crtc-1] flip_done timed out
/dev/nvme0n1p2: clean, 354739/1831424 files, 4384360/7324160 blocks

I restarted the system twice later but got nothing more than a black screen.

I backed off to the previous kernel linux-image-5.10.0-17-amd64 (5.10.136-1)

The system boots again with no issues, I'll keep using this kernel version
(linux-image-5.10.0-17-amd64) until a new one
gets released and try it.

Thanks for your great work.




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

** Model information
sys_vendor: BIOSTAR Group
product_name: A32M2
product_version: 
chassis_vendor: BIOSTAR Group
chassis_version: 
bios_vendor: American Megatrends Inc.
bios_version: 5.14
board_vendor: BIOSTAR Group
board_name: A32M2
board_version: 

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex [1022:15d0]
Subsystem: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root Complex 
[1022:15d0]
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] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
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] Raven/Raven2 PCIe 
GPP Bridge [6:0] [1022:15d3] (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] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
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] Raven/Raven2 
Internal PCIe GPP Bridge 0 to Bus B [1022:15dc] (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 61)
Subsystem: Biostar Microtech Int'l Corp FCH SMBus Controller [1565:370b]
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: xhci_hcd
Kernel modules: xhci_pci

01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] Device 

Bug#1022173: Arbitrary and frequent 100% CPU load symptom with Libreoffice Writer 1:7.0.4

[Rene Engelhard]

Hi,

Am 21.10.22 um 21:23 schrieb Thorsten Glaser:

On Fri, 21 Oct 2022, Rene Engelhard wrote:


Maybe time to get hardware from this or last century even?

Excuse me! That’s so totally not acceptable.

Debian runs on such machines, and I personally also have an EeePC,
and, to reduce electronic waste, reusing of older machines is
perfectly fine.

True. But then they know or should know that stuff might become slow.

Some people might not have the budget for newer
machines or their, generally increased, power consumption.


I'd actually argue that current processors are more power-efficient than 
a Pentium M



Your statement on the other hand was dismissive and insulting on top.


And this report has a too high severity. And was on a non-supported 
distro anymore. And for backports which doesn't belong here.



Regards,


Rene

Bug#1022197: fix correction

[tsteven4]

The original report dropped the final double quote in the fix.  Here is the 
corrected fix.

   $ diff /usr/bin/fop fop
   46c46
   < . $HOME/.foprc
   ---
   > . "$HOME/.foprc"

Bug#1019624: UPSONIC IRT-3K 2U broken by length checking in blazer_usb/nutdrv_qx

[Laurent Bigonville]

On Tue, 13 Sep 2022 10:19:24 +1000 "Trent W. Buck"  
wrote:

Hello,
>
> Short version:
>
> 1. UPSONIC IRT-3K 2U speaks a variant of Q1 which omits final \r.
> 2. nut 2.4 doesn't check for final \r, so it Just Works.
> 3. nut 2.7 checks for final \r, cannot talk to my UPS.
> 4. I fixed #3 but it's not very good.

Do you think you could check whether nut 2.8.0 (currently in unstable) 
works with your UPS?


Otherwise if the bug is still happening, could you please open a bug 
upstream if it's not already done?


Kind regards,

Laurent Bigonville

Bug#1022198: rust-rustyline: please upgrade to v9

[Jonas Smedegaard]

Source: rust-rustyline
Version: 6.3.0-5
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream release v9, needed by projects I am
preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNS81gACgkQLHwxRsGg
ASHVhQ//elkE5vVU9/MEVi8qQDZqUcFEyrpIvtA0J77BFL5ZjaO4yjsM/kRQsEjN
kAhz9Ai02S/+MBkPhipqFUcF+5XlA3JCrniIQBAxSV2D3tDHBsNd2+B2j8gDpljb
5AdiI3+aaYFaPpHc1X12rUfYN/en4kfYTVjiSa6MFzme0ctBk/DDyZvH4TDsCPw+
hcNeD5DAjZPTV+U0vuWjarkFDZY50RG3yd0vCJkenPmLLjEeUdDIO3PPVim8kpMW
y+KT/CDPbBmZaZ2ONrAy4B0j3j9LEIpTF3SxHHUorbZ87WZiokzHpxsnrH/1ptjS
MaZYL4W3+fNURkW+c5L9tYUlPbHx1ICq/r4A800YXK8fiUdfOmcapee48keIvjCI
uPgaI0/7cIEFxFBNZGZMj9rMJEl8haeXbGKSTdjrJS9sZ17PuUa4139AbOItLxS7
FMGfxTdEj610jSe4x6gnqK1e+d1TOaIGIC4bzMvDk+oXk+osUs9lGn64ogh6z6YV
lzmyR1YTBOR/YVY2alziwpuCregGDUwR8sU+avxv68HB09u+rJz9e7SOoMHH7ese
GOYa9rRw4lsgGIKiSSK66Ic2qCCaeuR2n2k4iPOO/3egvMoFG/sCsEdUviB8Bwd+
CFZ8w7v+yySC7+kaJhyWJFIZ201TCeT3SSfD61yfl3pTQ0+A7bo=
=STr3
-END PGP SIGNATURE-

Bug#1022173: Arbitrary and frequent 100% CPU load symptom with Libreoffice Writer 1:7.0.4

[Thorsten Glaser]

On Fri, 21 Oct 2022, Rene Engelhard wrote:

> Maybe time to get hardware from this or last century even?

Excuse me! That’s so totally not acceptable.

Debian runs on such machines, and I personally also have an EeePC,
and, to reduce electronic waste, reusing of older machines is
perfectly fine. Some people might not have the budget for newer
machines or their, generally increased, power consumption.

Your statement on the other hand was dismissive and insulting on top.

bye,
//mirabilos

Bug#1022197: fop fails if environmental variable HOME includes a space

[Steven Trabert]

Package: fop
Version: 1:2.6-2
Severity: normal
Tags: newcomer
X-Debbugs-Cc: tstev...@gmail.com

Dear Maintainer,


   * What led up to the situation?
   HOME environmental variable has a space in it.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   The fix is to double quote line 46 of /usr/bin/fop.
   $ diff /usr/bin/fop fop
   46c46
   < . $HOME/.foprc
   ---
   > . "$HOME/.foprc

   * What was the outcome of this action?
   fop works as expected with the patch.  Without the patch fop fails:
   HOME="/home/tsteven4/work/doc link" fop -q -fo gpsbabel.fo -pdf gpsbabel.pdf
   /usr/bin/fop: 46: .: cannot open /home/tsteven4/work/doc: No such file
   * What outcome did you expect instead?
   I expect fop to work normally even when HOME has an embedded space
   character.


  see https://bugs.launchpad.net/ubuntu/+source/fop/+bug/1993853
  LP: #1993853

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

Kernel: Linux 5.15.68.1-microsoft-standard-WSL2 (SMP w/20 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fop depends on:
ii  default-jre-headless [java2-runtime-headless] 2:1.11-72build2
ii  libfop-java   1:2.6-2
ii  openjdk-11-jre-headless [java2-runtime-headless]  11.0.16+8-0ubuntu1~22.04

Versions of packages fop recommends:
ii  libsaxon-java  1:6.5.5-12

Versions of packages fop suggests:
pn  fop-doc  

-- no debconf information

Bug#958036: nut-snmp: SNMPv3 with privacy method "AES" fails to communicate with UPS

[Laurent Bigonville]

On Fri, 17 Apr 2020 12:32:15 -0400 Wilfried Teiken  
wrote:

>

> Dear Maintainer,

Hello Wilfried,

>
> when configuring SNMP as v3 with privacy enabled and "privProtocol = 
AES" in
> /etc/nut/ups.conf for the UPS then the communication with the UPS 
will fail.

>
> The sympton is that on startup the driver will report:
> - "Unknown mibs value: apcc" (with "mibs = apcc")
> - "No supported device detected" (with "mibs = auto"
>
> Communication with "privProtocol = DES" works if the SNMP endpoint is 
configured

> accordingly, so this only affects the "AES" setting.
>
> The underlying root cause is a length issue for the 'usmAESPrivProtocol'
> oid value, causing the wrong privacy string being passed into the 
net-snmp

> library caused by a #define that is leading to a sizeof() with a pointer
> instead of the oid array.
>
> See attached patch for a fix.

Could you please tell me if you are still experiencing this issue with 
the version 2.8.0 that is currently in debian unstable?


I can see that the code to detect 
usmAESPrivProtocol/usmAES128PrivProtocol availability has changed.


Also, in the build logs of version 2.7.14, I can see the compiler 
complain about the size of these types, while this warning is not 
present in version 2.8.0


I think that this is now fixed.

Could you please confirm?

Kind regards,

Laurent Bigonville

Bug#1022196: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-relational-schemas
Version: 0.1.8.0-1
Severity: serious

I intend to remove this package, since it depends on the broken
haskell-product-isomorphic package (see https://bugs.debian.org/1022189).

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

-- 
Ilias

Bug#1022195: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-relational-record
Version: 0.2.2.0-5
Severity: serious

I intend to remove this package, since it depends on the broken
haskell-product-isomorphic package (see https://bugs.debian.org/1022189).

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

-- 
Ilias

Bug#1022194: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-relational-query-hdbc
Version: 0.7.2.0-2
Severity: serious

I intend to remove this package, since it depends on the broken
haskell-product-isomorphic package (see https://bugs.debian.org/1022189).

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

-- 
Ilias

Bug#1022193: rust-generator: please upgrade to v0.7.0

[Jonas Smedegaard]

Source: rust-generator
Version: 0.6.20-3
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream release v0.7.0 (or newer), needed by
projects I am preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNS4xAACgkQLHwxRsGg
ASGg6RAAn4pdYoFhL2pMEPx7vY/WekCoFjmaIsSaP+yxAR9CxEa6JoNKLbRBQVtt
BiNo+5i9djibfw3gzKaN+UnUnMQYHs/IJO/0+Hs5v1OczvsUdXOuX/RVrlrFh/uB
igkxwrP5cYibB3ly4cvj8HKtFaaHMmw1td9qu2t+KlMEw2JAaJbL7JmpkHSq/+PH
kXADDb8Za+B0okln+lBVe3a6fI2F2O/vvaGQc5BwGpAsy+nOh4EOC9FGUC7y5WLI
d4Nj5Ar+4ioH1aA43OkqSYrjCVsFOOklTx10WuR6uqnY+fZUgs+r5odCTNxDCpHv
HH2aK1hCJxRASxGq8H/b4f+8AaUOk/FJV5c/mXfMxrYpVfB5iC2Ot7Q9cGNPjmrt
rkYrxM7XLRRCHtIkTKZRpVLbehzOSTln/cblKtfC+V8WVm8NQemcE0hm4nv8kSpz
QhzJWkF6ggb7kcqvORP8z786iDKhAakTAmhit1sDyXiTZkPU15VAdLGcZXtbGnzK
jt04xv/3bG2EPLiR5avTnnVQT/8QNiUP61AtsATyveYbYVa6edqPevrHitjn+5sM
bRN4oii88ZYq+34fTwOwrCKEDCd38jyndHwfp3PBoK2AKkiORq29qeDUD4YSVi0M
kt4Wrcj2/MdbhXASCqu+6NwtWKIDbjaAV19Dyf62eE6IvUayISY=
=3fNO
-END PGP SIGNATURE-

Bug#1022192: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-relational-query
Version: 0.12.3.0-1
Severity: serious

I intend to remove this package, since it depends on the broken
haskell-product-isomorphic package (see https://bugs.debian.org/1022189).

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

-- 
Ilias

Bug#1022191: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-persistable-types-hdbc-pg
Version: 0.0.3.5-2
Severity: serious

I intend to remove this package, since it depends on the broken
haskell-product-isomorphic package (see https://bugs.debian.org/1022189).

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

-- 
Ilias

Bug#1013276: personal insights to this configuration mess

[Lukas Wiest]

Hey, I'm not quite sure if everyone reading only here, recognized all
needed steps for a correct behavior.

In message #17 it was said to remove the conflicting pulseaudio configs
from the Alsa folder. But that's only half of the solution.

Ubuntu 22.10 now comes with pipewire audio by default, without any
/etc/alsa folder present. This works fine in a virtual machine, but not
on my actual hardware with multiple sinks. For this it still needed the
pipewire configurations being in place and pipewire-alsa installed.
The configurations were provided by installing the
pipewire-audio-client-libraries package in Ubuntu's case, however the
package itself isn't required to stay installed.

The requirement on my actual hardware for Java (Alsa) applications to
work properly, are the pipewire-alsa package AND the two configurations
in /etc/alsa/conf.d

For the now freshly released Ubuntu 22.10 this means on a clean install
the user is might not be able to use Alsa applications properly, without
manually fixing this. What the state on the Debian side is, I have no
idea without doing a test install.

Greetings, Lukas
-- 
answer me encrypted using OpenPGP 
OpenPGP Fingerprint: E3DC 58EA D28D 18B6 82D0 C48F 45D5 1A16 591C 7F51
https://keys.openpgp.org/vks/v1/by-fingerprint/E3DC58EAD28D18B682D0C48F45D51A16591C7F51


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022190: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-persistable-record
Version: 0.6.0.5-1
Severity: serious

I intend to remove this package, since it depends on the broken
haskell-product-isomorphic package (see https://bugs.debian.org/1022189).

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

-- 
Ilias

Bug#1022189: Removal notice: obsolete

[Ilias Tsitsimpis]

Source: haskell-product-isomorphic
Version: 0.0.3.3-2
Severity: serious

I intend to remove this package:

  * The current version is incompatible with GHC 9.0 and FTBFS
  * Seems unmaintained; Last upload more than 3 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#1022188: debugpy: FTBFS due to either "Timed out..." or "Address already in use"

[Sergio Durigan Junior]

Source: debugpy
Version: 1.6.3+ds-1
Severity: serious

Hi,

debugpy is currently FTBFSing:

--8<---cut here---start->8---
=== short test summary info 
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-python-custompy,-O-None-launch(console=internalConsole)]
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-pythonPath-custompy,-O-None-launch(console=internalConsole)]
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-python-custompy,-O--B-launch(console=integratedTerminal)]
FAILED 
tests/debugpy/test_run.py::test_custom_python_args[program-pythonPath-custompy,-O-None-launch(console=externalTerminal)]
--8<---cut here---end--->8---

The long summary is too big to post here, but you can see the full log
at:

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

I think the gist of what's going on is the following excerpt:

--8<---cut here---start->8---
E+00015.109: /handling #2 request "attach" from Client[1]/
 Traceback (most recent call last):
   File 
"/<>/.pybuild/cpython3_3.10_debugpy/build/debugpy/adapter/../../debugpy/common/messaging.py",
 line 1015, in __init__
 raise self
 debugpy.common.messaging.MessageHandlingError: Timed out waiting 
for debug server to connect.
--8<---cut here---end--->8---

Interestingly, when I sbuild the package locally I get a somewhat
different error:

--8<---cut here---start->8---
E+0.008: Error listening for incoming Client connections on 127.0.0.1:5684:
 
 Traceback (most recent call last):
   File 
"/<>/.pybuild/cpython3_3.10_debugpy/build/debugpy/../debugpy/adapter/../../debugpy/common/sockets.py",
 line 93, in serve
 listener = create_server(host, port, backlog, timeout)
   File 
"/<>/.pybuild/cpython3_3.10_debugpy/build/debugpy/../debugpy/adapter/../../debugpy/common/sockets.py",
 line 24, in create_server
 server.bind((host, port))
 OSError: [Errno 98] Address already in use
--8<---cut here---end--->8---

I found a few upstream bugs that contain either the "Timed out waiting
for debug server to connect" or the "Address already in use" messages,
but I haven't investigated further TBH.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#1022087: jellyfish: FTBFS with pkgconf

[Andrej Shadura]

Hi,

On Fri, 21 Oct 2022, at 19:34, Nilesh Patra wrote:
> D'you plan to rebuild this, and other few currently failing packages w/ 
> the new pkgconf release?

Yes, I also will rebuild all packages that failed because of missing 
dependencies (Perl transition) or aborted during the build (possibly OOM or 
disk space).

-- 
Cheers,
  Andrej

Bug#1022087: jellyfish: FTBFS with pkgconf

[Nilesh Patra]

On Fri, Oct 21, 2022 at 07:24:59PM +0200, Andrej Shadura wrote:
> On Fri, 21 Oct 2022, at 19:01, Andreas Metzler wrote:
> > On 2022-10-21 Andreas Metzler  wrote:
> >> Looks like this could be https://github.com/pkgconf/pkgconf/issues/267
> >> which was fixed in June
> >> https://github.com/pkgconf/pkgconf/commit/a61193c7236f5b240585c4f8eef6f452f1d9a7ee
> >> but has not hit a release yet.
> >
> > Indeed applying the upstream patch fixes the testcase Nilesh provided.
> >
> > I have not tried rebuilding jellyfish with patched pkgconf.
> 
> Thanks for confirming, I was looking at the same upstream commit, and 
> actually I have just uploaded it to experimental.

D'you plan to rebuild this, and other few currently failing packages w/ the new 
pkgconf release?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1022103: gdisk: sgdisk produces only errors

[Håvard F . Aasen]

I believe this is related to #1020446, and hopefully should be fixed with the 
latest NMU, version 1.0.9-2.1.
Which was needed when "popt" plugged   a memory leak.

It would be nice if someone could try the latest upload, and verify this issue 
is fixed.


Regards,
Håvard

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

[Mario Luppi]

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


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

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

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

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

Contents of /etc/apt/sources.list:


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

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

- Did any packages fail to upgrade?

- Were there any problems with the system after upgrading?


Further Comments/Problems:


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

Bug#1022087: jellyfish: FTBFS with pkgconf

[Andrej Shadura]

Hi,

On Fri, 21 Oct 2022, at 19:01, Andreas Metzler wrote:
> On 2022-10-21 Andreas Metzler  wrote:
>> Looks like this could be https://github.com/pkgconf/pkgconf/issues/267
>> which was fixed in June
>> https://github.com/pkgconf/pkgconf/commit/a61193c7236f5b240585c4f8eef6f452f1d9a7ee
>> but has not hit a release yet.
>
> Indeed applying the upstream patch fixes the testcase Nilesh provided.
>
> I have not tried rebuilding jellyfish with patched pkgconf.

Thanks for confirming, I was looking at the same upstream commit, and actually 
I have just uploaded it to experimental.

-- 
Cheers,
  Andrej

Bug#1022103: gdisk: sgdisk produces only errors

[Holger Schröder]

Fixed in 1.0.9-2.1.  currently still in incoming


see

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

...

Bug#1022087: jellyfish: FTBFS with pkgconf

[Andreas Metzler]

On 2022-10-21 Andreas Metzler  wrote:
> On 2022-10-20 Nilesh Patra  wrote:
>> On Wed, 19 Oct 2022 21:11:12 +0100 Andrej Shadura  
>> wrote:
>> > Source: jellyfish
> []

>> I took a look at this one, and this seems to FTBFS with pkgconf
>> because pkgconf does not seem to honor atleast PKG_CONFIG_SYSROOT_DIR
>> which is set in d/rules for this package[1]
> [...]
>> with old pkg-config:

>> $ PKG_CONFIG_PATH=. PKG_CONFIG_SYSROOT_DIR=debian/tmp/ pkg-config --cflags 
>> jellyfish-2.0
>> -Idebian/tmp//usr/include/jellyfish-2.3.0

>> with pkgconf:

>> $ PKG_CONFIG_PATH=. PKG_CONFIG_SYSROOT_DIR=debian/tmp/ pkg-config --cflags 
>> jellyfish-2.0
>> -I/usr/include/jellyfish-2.3.0
> [...]

> Hello,

> Looks like this could be https://github.com/pkgconf/pkgconf/issues/267
> which was fixed in June
> https://github.com/pkgconf/pkgconf/commit/a61193c7236f5b240585c4f8eef6f452f1d9a7ee
> but has not hit a release yet.

Indeed applying the upstream patch fixes the testcase Nilesh provided.

I have not tried rebuilding jellyfish with patched pkgconf.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#1021974: adding dkms log

[Ivan Sergio Borgonovo]

Just adding dkms make log.


--
Ivan Sergio Borgonovo
https://www.webthatworks.it https://www.borgonovo.net
DKMS make.log for nvidia-tesla-470-470.141.03 for kernel 6.0.0-1-amd64 (x86_64)
Fri Oct 21 06:07:39 PM CEST 2022
make KBUILD_OUTPUT=/lib/modules/6.0.0-1-amd64/build V=1 -C /lib/modules/6.0.0-1-amd64/source M=/var/lib/dkms/nvidia-tesla-470/470.141.03/build ARCH=x86_64 NV_KERNEL_SOURCES=/lib/modules/6.0.0-1-amd64/source NV_KERNEL_OUTPUT=/lib/modules/6.0.0-1-amd64/build NV_KERNEL_MODULES="nvidia nvidia-uvm nvidia-modeset nvidia-drm nvidia-peermem" INSTALL_MOD_DIR=kernel/drivers/video NV_SPECTRE_V2=0 modules
make[1]: Entering directory '/usr/src/linux-headers-6.0.0-1-common'
make -C /usr/src/linux-headers-6.0.0-1-amd64 -f /usr/src/linux-headers-6.0.0-1-common/Makefile modules
make[2]: Entering directory '/usr/src/linux-headers-6.0.0-1-amd64'
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;			\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;			\
/bin/false)
make -f /usr/src/linux-headers-6.0.0-1-common/scripts/Makefile.build obj=/var/lib/dkms/nvidia-tesla-470/470.141.03/build \
single-build= \
need-builtin=1 need-modorder=1
NV_CONFTEST_CMD=/bin/sh /var/lib/dkms/nvidia-tesla-470/470.141.03/build/conftest.sh " gcc-12" x86_64 /lib/modules/6.0.0-1-amd64/source /lib/modules/6.0.0-1-amd64/build
NV_CONFTEST_CFLAGS=-O2 -D__KERNEL__ -DKBUILD_BASENAME="#conftest43911" -DKBUILD_MODNAME="#conftest43911" -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/12/include -I/lib/modules/6.0.0-1-amd64/source/arch/x86/include/asm/mach-default -I/lib/modules/6.0.0-1-amd64/source/include/asm-x86/mach-default -I/lib/modules/6.0.0-1-amd64/build/include2 -I/lib/modules/6.0.0-1-amd64/build/include -include /lib/modules/6.0.0-1-amd64/build/include/generated/autoconf.h -I/lib/modules/6.0.0-1-amd64/source/arch/x86/include -I/lib/modules/6.0.0-1-amd64/source/arch/x86/include/uapi -I/lib/modules/6.0.0-1-amd64/build/arch/x86/include/generated -I/lib/modules/6.0.0-1-amd64/build/arch/x86/include/generated/uapi -I/lib/modules/6.0.0-1-amd64/source/include -I/lib/modules/6.0.0-1-amd64/source/include/uapi -I/lib/modules/6.0.0-1-amd64/source/include/xen -I/lib/modules/6.0.0-1-amd64/build/include/generated/uapi -mfentry -DCC_USING_FENTRY -I/var/lib/dkms/nvidia-tesla-470/470.141.03/build/common/inc -I/var/lib/dkms/nvidia-tesla-470/470.141.03/build -Wall -MD   -Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"470.141.03\" -Wno-unused-function -Wuninitialized -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0 -DNV_KERNEL_INTERFACE_LAYER -fno-pie -Wall -Wundef -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong -Wno-array-bounds -Wimplicit-fallthrough=5 -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -pg -mrecord-mcount -mfentry -DCC_USING_FENTRY -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -fno-strict-overflow -fno-stack-check -fconserve-stack -Wno-packed-not-aligned -g
KBUILD_CFLAGS=-Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -fcf-protection=none -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -Wno-sign-compare -fno-asynchronous-unwind-tables -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -fno-jump-tables -mharden-sls=all -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=2048 

Bug#1022087: jellyfish: FTBFS with pkgconf

[Andreas Metzler]

On 2022-10-20 Nilesh Patra  wrote:
> On Wed, 19 Oct 2022 21:11:12 +0100 Andrej Shadura  wrote:
> > Source: jellyfish
[]

> I took a look at this one, and this seems to FTBFS with pkgconf
> because pkgconf does not seem to honor atleast PKG_CONFIG_SYSROOT_DIR
> which is set in d/rules for this package[1]
[...]
> with old pkg-config:

> $ PKG_CONFIG_PATH=. PKG_CONFIG_SYSROOT_DIR=debian/tmp/ pkg-config --cflags 
> jellyfish-2.0
> -Idebian/tmp//usr/include/jellyfish-2.3.0

> with pkgconf:

> $ PKG_CONFIG_PATH=. PKG_CONFIG_SYSROOT_DIR=debian/tmp/ pkg-config --cflags 
> jellyfish-2.0
> -I/usr/include/jellyfish-2.3.0
[...]

Hello,

Looks like this could be https://github.com/pkgconf/pkgconf/issues/267
which was fixed in June
https://github.com/pkgconf/pkgconf/commit/a61193c7236f5b240585c4f8eef6f452f1d9a7ee
but has not hit a release yet.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#937234: trying to remove python2.7 from bookworm

[Mike Gabriel]

Hi Nilesh,

On  Fr 21 Okt 2022 16:13:37 CEST, Nilesh Patra wrote:


On Fri, 16 Sep 2022 22:50:29 +0200 Paul Gevers  wrote:

Hi Mike,

On Mon, 15 Aug 2022 13:54:27 + Mike Gabriel
 wrote:
> in another project context I have a freelancer working on pam-python
> Py3 transition. Will pick up the threads this week (I returned freshly
> from VAC yesterday).

One month went by, is there any progress to report?


. and it is two months now, w/ nothing happening on this bug reoport.
Mike, do you intend to get working on it?


yes, I do. I'll have it +/- next on my list.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpo9_bjX1xzH.pgp
Description: Digitale PGP-Signatur

Bug#1022134: Moving forward to 0.67

[Christoph Biedl]

Christoph Biedl wrote...

> as briefly discussed in IRC, I tried to import upstream version 0.67 -
> turns out this is no big deal:

Someone™ asked for a debdiff, see attachment. May contain easter eggs.

Christoph
diff --git a/debian/changelog b/debian/changelog
index f91eaf7..4964eb8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+quilt (0.67-1) UNRELEASED; urgency=low
+
+  * Import upstream version 0.67
+
+ -- Christoph Biedl   Sun, 16 Oct 2022 
17:06:38 +0200
+
 quilt (0.66-2.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index 8e3bcac..4589c1c 100644
--- a/debian/control
+++ b/debian/control
@@ -1,10 +1,11 @@
 Source: quilt
 Maintainer: Martin Quinson 
-Uploaders: Dr. Tobias Quathamer 
+Uploaders: Dr. Tobias Quathamer ,
+   Christoph Biedl 
 Section: vcs
 Priority: optional
 Build-Depends: bash-completion, debhelper-compat (= 12)
-Build-Depends-Indep: diffstat, ed, gettext, hevea, html2text, perl, procmail
+Build-Depends-Indep: diffstat, ed, gawk, gettext, hevea, html2text, perl, 
procmail
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/debian/quilt
 Vcs-Git: https://salsa.debian.org/debian/quilt.git
diff --git a/debian/patches/manpage-typo.patch 
b/debian/patches/manpage-typo.patch
index 7856be5..2680d4d 100644
--- a/debian/patches/manpage-typo.patch
+++ b/debian/patches/manpage-typo.patch
@@ -1,7 +1,7 @@
 Description: Manpage typo
 --- a/quilt/header.in
 +++ b/quilt/header.in
-@@ -29,7 +29,7 @@
+@@ -18,7 +18,7 @@
  Print or change the header of the topmost or specified patch.
  
  -a, -r, -e
@@ -12,16 +12,7 @@ Description: Manpage typo
  
 --- a/doc/quilt.1.in
 +++ b/doc/quilt.1.in
-@@ -161,7 +161,7 @@
- well as the order in which it should be applied.
- 
- The .pc/ directory contains some metadata about the current state of
--your patch serie. Changing its content is not advised. This directory
-+your patch series. Changing its content is not advised. This directory
- can usually be regenerated from the initial files and the
- content of the patches/ directory (provided that all patches were
- regenerated before the removal).
-@@ -208,7 +208,7 @@
+@@ -214,7 +214,7 @@
  You may also want to add the "-E" option if you have issues with quilt
  not deleting empty files when you think it should. The documentation of
  GNU patch says that "normally this option is unnecessary", but when patch
diff --git a/debian/patches/series b/debian/patches/series
index bb80934..f490718 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -2,7 +2,6 @@ cherry-pick.v0.67-29-gf73f8d7.avoid-warnings-with-grep-3-8.patch
 quilt-init
 dep3mail### Sent 2014-01-18
 check_SERIES_exists ### Sent 2014-01-18
-setup-dont-read-pc  ### Sent 2014-01-18
 
 restrict-patch-names
 fail_on_missing
diff --git a/debian/patches/setup-dont-read-pc 
b/debian/patches/setup-dont-read-pc
deleted file mode 100644
index 11d65b8..000
--- a/debian/patches/setup-dont-read-pc
+++ /dev/null
@@ -1,34 +0,0 @@
-Description: setup don't obey the settings of any englobing .pc 
- .
- This is mainly intended to get the setup.test working even if the
- debian package contains a .pc directory. Without this patch, the
- debian packaging stuff will get the testsuite using debian/patches
- instead of patches (because it's the way it goes in our .pc). The
- test breaks with that setting.
- .
- The patch changes the setup command to not take the settings of any
- .pc directory found, and reset QUILT_PC QUILT_PATCHES and QUILT_SERIES
- to their default values.
-Bug-Debian: https://bugs.debian.org/573689
-Forwarded: 2014-01-18
-

- quilt/setup.in |5 +
- 1 file changed, 5 insertions(+)
-
 a/quilt/setup.in
-+++ b/quilt/setup.in
-@@ -20,8 +20,13 @@
-   . $QUILT_DIR/scripts/patchfns
-   if [ -n "$SUBDIR" ]
-   then
-+  # Damn, found an enclosing quilt directory; don't follow its 
settings
-   cd $SUBDIR
-   unset SUBDIR
-+  unset QUILT_PC QUILT_PATCHES QUILT_SERIES
-+  : ${QUILT_PC:=.pc}
-+  : ${QUILT_PATCHES:=patches}
-+  : ${QUILT_SERIES:=series}
-   fi
- fi
- 
diff --git a/debian/patches/use-sensible-editor 
b/debian/patches/use-sensible-editor
index 1bc11d9..2bb145b 100644
--- a/debian/patches/use-sensible-editor
+++ b/debian/patches/use-sensible-editor
@@ -20,13 +20,13 @@ Author: Ryan Niebur 
 -: ${EDITOR:=vi}
 +: ${EDITOR:=sensible-editor}
  
- # Read in library functions
- if [ "$(type -t patch_file_name)" != function ]
+ usage()
+ {
 --- a/quilt/header.in
 +++ b/quilt/header.in
-@@ -17,7 +17,7 @@
-   . $QUILT_DIR/scripts/patchfns
- fi
+@@ -6,7 +6,7 @@
+ #
+ #  See the COPYING and AUTHORS files for more details.
  
 -: ${EDITOR:=vi}
 +: ${EDITOR:=sensible-editor}
@@ -42,8 +42,8 @@ Author: Ryan Niebur 
 -: ${EDITOR:=vi}
 +: ${EDITOR:=sensible-editor}
  
- # Read in library functions
- if [ "$(type -t patch_file_name)" != 

Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal

[Vincent Lefevre]

Control: found -1 390.154-2

I've just done an upgrade and rebooted. Still reproducible...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1021978: spamassassin: non-standard version numbers break spamassassin's AIDE script

[Noah Meyerhans]

Control: reassign -1 aide
Control: retitle -1 aide's spamassassin script does not correctly handle 
spamassassin prerelease version strings

On Fri, Oct 21, 2022 at 01:05:21PM +0200, Thomas Dorner wrote:
> > > The problem is that the current version number 4.0.0~rc3-3.1 does
> > > not match the expected schema of N.N.N-N.  As only the first 3
> > > numbers are used anyway, I've created a patch (attached) making the
> > > regular expression less rigid by ignoring everything after those 3
> > > numbers. This works for me.  
> 
> Ooops, you're right, the file
> /usr/share/aide/config/aide/aide.conf.d/21_aide_spamassassin
> belongs to aide-common.  Could you forward this or should I create a
> new report?

Reassinged to aide.

noah

Bug#1022185: nfs-utils: blkmapd crash

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/linux-nfs/CANYNYEG=utJ2pe+FtMWh8O+dz63R2wbzOC7ZVrvoqD=u04w...@mail.gmail.com/
Control: tag -1 upstream

On vrijdag 21 oktober 2022 16:57:04 CEST Andreas Hasenack wrote:
> I sent a ping to upstream again[1], and in Ubuntu for now I'll just
> remove the faulty free(serial->data) in the 3 places in that function.
> 
> 1. https://lore.kernel.org/linux-nfs/CANYNYEG=utJ2pe+FtMWh8O+dz63R2wbzOC7ZVrvo
> qD=u04w...@mail.gmail.com/T/#u

Updating metadata accordingly

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

Bug#1022173: Arbitrary and frequent 100% CPU load symptom with Libreoffice Writer 1:7.0.4

[Robin]

Am Fri, 21 Oct 2022 15:21:11 +0200
schrieb Rene Engelhard :

Hello Rene,

sorry for having sent this report to the wrong listing. I followed the 
instructions found here:
https://www.debian.org/Bugs/Reporting
there was nothing mentioned about different treatment for backports at all, and 
I'm not that experienced in bug reporting.

>Let's merge them since the description sounds familiar enough.
Please feel free to assign, move or merge with whatever you consider to be 
appropriate.

>Wow.
I have no other system running besides this old but fast 32bit notebook, which 
is still absolutely fit and fine for everyday work (I'm not compiling or 
programming, being translator, not programmer). It is even fit for gimp image 
manipulation of large images, or dual head multimedia display up to 3000kbps 
and surfing the web fast and fluently, you'd not guess its age.

> Buster is out of life. 
I know, but I'm running LTS until June 2024 on this notebook, since some of its 
hardware components are not supported properly in bullseye anymore by the 
drivers. Somebody decided to remove the needed code.
 
> Does it still happen with bullseye? (Assume so since the buster-backports 
> version is built from bullseye)
> Does it happen with the version in bullseye-backports?
I'll check this both as soon as possible. Will have to setup a parallel 
bullseye install here first for testing. Then I can definitely state whether it 
happens with the non backported bullseye version of Libreoffice also. Maybe I 
can even run a test on bookworm, but I'm not sure by now whether and when I can 
free up some time for all this testing in OS versions I have not running or 
even installed here.

> (Btw, you want to upgrade to deb11u4 backport whenever it is approved 
> immediately to fix a security bug)
Many thanks for this security warning, I'll watch out, as always, for the 
update.

Regards
Robin

Bug#1020436: giac failed tests with new pari

[Ileana Dumitrescu]

Hi Tobias,

> are you aware of the bug
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020436

> Bill posted a suggestion how to fix this test there yesterday.

Yes I saw the bug and initial comments by Bill but thanks for letting me know 
about Bill's latest comments.

I applied the patch from sagemath (define-anyarg.patch) and built giac 
1.9.0.21+dfsg2 in my pbuilder environment and was able to reproduce the 
chk_fhan4 seg fault from above. I added an additional patch 
(increase-pari-size.patch) to export PARI_SIZE=2048000 in chk_fhan4 as in 
Gonzalo Tornaria's comment here: https://trac.sagemath.org/ticket/34583. This 
allowed the build to complete without error on my pbuilder environment and I 
committed the changes to salsa. Please feel free to test and upload if the 
updates look good.

IleanaFrom 2238c88dbb3ea8eacd7b3d8f071cd8a977c47e98 Mon Sep 17 00:00:00 2001
From: Ileana Dumitrescu 
Date: Fri, 21 Oct 2022 16:41:42 +0300
Subject: [PATCH] define anyarg

---
 src/pari.cc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/src/pari.cc b/src/pari.cc
index 76ce8e1..8d5b22b 100644
--- a/src/pari.cc
+++ b/src/pari.cc
@@ -39,6 +39,12 @@ using namespace std;
 #endif
 
 #ifdef HAVE_LIBPARI
+// ANYARG disappeared from PARI 2.15.0
+#ifdef __cplusplus
+# define ANYARG ...
+#else
+# define ANYARG
+#endif
 
 #ifdef HAVE_PTHREAD_H
 #include 
-- 
2.37.2

From f32439947309f276d963234c827c1e8918bb808c Mon Sep 17 00:00:00 2001
From: Ileana Dumitrescu 
Date: Fri, 21 Oct 2022 17:10:36 +0300
Subject: [PATCH] increase pari size

---
 check/chk_fhan4 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/check/chk_fhan4 b/check/chk_fhan4
index 5d1e1e8..29429d3 100755
--- a/check/chk_fhan4
+++ b/check/chk_fhan4
@@ -1,4 +1,5 @@
 #! /bin/sh
 unset LANG
+export PARI_SIZE=2048000
 ../src/icas TP04-sol.cas > TP04.tst
 diff TP04.tst TP04-sol.cas.out1
-- 
2.37.2

Bug#1022124: libdbd-oracle-perl needs binaries uploaded for the perl 5.36 transitions

[Adrian Bunk]

On Fri, Oct 21, 2022 at 02:38:56PM +0200, Alex Muntada wrote:
> Hi Adrian,
> 
> > libdbd-oracle-perl cannot be built on the buildds,
> > and it needs binaries uploaded for the perl 5.36 transition.
> 
> Please, don't hesitate to remove libdbd-oracle-perl from testing
> for the perl 5.36 transition to proceed. I'll try to have those
> binaries by next week, but I don't want to stall the transition.

I am not a member of the release team, but your statement on
status/schedule is appreciated.

> Cheers!
> Alex

cu
Adrian

Bug#912335: gnome-terminal: minor redraw issue when moving a window over the terminal

[Vincent Lefevre]

Control: found -1 390.154-1

On 2022-10-20 12:06:19 +0200, Tobias Frost wrote:
> > I have another machine with nvidia-driver 418.56-2, but I couldn't
> > try yet.
> 
> do you recall or know if 418.56-2 (or newer driver version) still
> show the same issue?

Actually I think I had never had any machine with 418.x (or this
was reverted later due to compatibility issues). The latest branch
supporting the chipset is 390.* provided by nvidia-legacy-390xx-driver
on my both machines. And the issue still occurs. See attached
screenshot.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#1008707: RFS: calamares-extensions/1.2.1-1 [ITP] -- Mobile module for Calamares installer framework

[Bastian Germann]

Am 21.10.22 um 17:17 schrieb Arnaud Ferraris:

Bastian, in case you aren't interested (anymore?) in sponsoring this package I 
can take it from here.


Thanks, please do so.

Bug#1022186: sonivox -- does not honor the nocheck profile while building

[Nilesh Patra]

Source: sonivox
Version: 3.6.11-1
Severity: important
Tags: patch
X-Debbugs-Cc: s...@y0o.de


Hi Dennis,

The CMakeLists.txt has BUILD_TESTING set to ON by default and
the tests are then forcefully run even when a nocheck opt is
being passed.
This also breaks cross builds, and this should be taken care
of in d/rules.

I have attached a patch, please consider merging.

Thanks!


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

Kernel: Linux 5.18.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
>From ee2eedcca81e36db113d2711328342ada166b18a Mon Sep 17 00:00:00 2001
From: Nilesh Patra 
Date: Fri, 21 Oct 2022 20:54:30 +0530
Subject: [PATCH] Respect nocheck profile when passed in buildsystem

---
 debian/control | 2 +-
 debian/rules   | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 2596f20..999f5dc 100644
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Uploaders: Dennis Braun 
 Build-Depends:
  debhelper-compat (= 13),
  cmake,
- libgtest-dev
+ libgtest-dev 
 Homepage: https://github.com/pedrolcl/sonivox
 Vcs-Browser: https://salsa.debian.org/multimedia-team/sonivox
 Vcs-Git: https://salsa.debian.org/multimedia-team/sonivox.git
diff --git a/debian/rules b/debian/rules
index d8309f6..8de3a79 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,3 +4,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
dh $@
+
+override_dh_auto_configure:
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+   dh_auto_configure
+else
+   dh_auto_configure -- -DBUILD_TESTING=OFF
+endif
-- 
2.35.1

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

[Diederik de Haas]

On woensdag 19 oktober 2022 18:47:06 CEST Ansgar wrote:
> After upgrading to linux 6.0.2-1 I see the following message during boot:
> 
> ...
>
> | [3.858820] BUG: kernel NULL pointer dereference, address:
> | 0020 [3.858838] #PF: supervisor read access in kernel
> | mode
> 
> I only use the integrated Intel graphics, the Nvidia card is unused.
> 
> There was no null pointer dereference with the previous kernel
> (5.19.11-1 (2022-09-24)).

Can you verify if the issue is also present on 6.0~rc7-1~exp1?
I expect it does, but it's better to know then to assume.

There have been quite some commit under 'drivers/gpu/drm/nouveau' in kernel 
6.0 and in 6.0.3 there have been several NPE fixes, although they didn't appear 
directly related to your issue.
It could be, but it could also be that there are more.

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

Bug#1020989: trafficserver: failed to load plugin

[Jean Baptiste Favre]

Hello,
Thanks for your report.
After a quick look, I couldn't find any easy solution to this issue.
Will have a deeper as soon as possible.

Best,
Jean Baptiste


On 9/30/22 09:05, YunQiang Su wrote:

Package: trafficserver
Version: 9.1.3+ds-2
Severity: grave

Since ATS 9, it tries to load plugins to /run/trafficserver, and then load them,
and it asks for the plugins to have execution permission.

While the /run filesystem on Debian is mounted with noexec option.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022185: nfs-utils: blkmapd crash

[Andreas Hasenack]

Package: nfs-utils
Version: 1:2.6.2-1+b1
Severity: normal

Dear Maintainer,

Under certain conditions, blkmapd can crash due to calling free() on a
pointer that wasn't malloc()ed. The reproducer I list below using a
debian sid VM went as far as isolating it to having LVM Logical
Volumes on SCSI disks, but this does not exclude other scenarios.

The struct bl_serial *serial structure is allocated via
bl_create_scsi_string() which does a malloc for it, but the code later
on was doing a free() on the data element of this structure and only
then on the structure itself. That first free() is incorrect, as the
data element was never malloc()ed separatedly.

This was first brought up by lixiaokeng via
https://www.spinics.net/lists/linux-nfs/msg87598.html, but not
acknowledged back then.

Here is a reproducer using a VM. It assumes you can add a SCSI disk to
it, which in my steps below is /dev/sdb.

# apt install nfs-kernel-server lvm2
# systemctl stop nfs-blkmapd.service
# pvcreate /dev/sdb
# vgcreate vg0 /dev/sdb
# lvcreate -ntest -L100M vg0
# blkmapd -f
blkmapd: open pipe file /run/rpc_pipefs/nfs/blocklayout failed: No
such file or directory
double free or corruption (out)
Aborted

Note the message about blocklayout is not relevant for this bug.

In gdb:
(gdb) bt
#0  __pthread_kill_implementation (threadid=,
signo=signo@entry=6, no_tid=no_tid@entry=0) at
./nptl/pthread_kill.c:44
#1  0x77c895df in __pthread_kill_internal (signo=6,
threadid=) at ./nptl/pthread_kill.c:78
#2  0x77c3da02 in __GI_raise (sig=sig@entry=6) at
../sysdeps/posix/raise.c:26
#3  0x77c28469 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77c7d888 in __libc_message
(action=action@entry=do_abort, fmt=fmt@entry=0x77db66fb "%s\n") at
../sysdeps/posix/libc_fatal.c:155
#5  0x77c9322a in malloc_printerr
(str=str@entry=0x77db9340 "double free or corruption (out)") at
./malloc/malloc.c:5659
#6  0x77c95198 in _int_free (av=0x77df4c60 ,
p=0x55567ad0, have_lock=, have_lock@entry=0) at
./malloc/malloc.c:4583
#7  0x77c978df in __GI___libc_free (mem=) at
./malloc/malloc.c:3386
#8  0x745e in bl_add_disk (filepath=0x7fffd2b0
"/dev/dm-0") at ./utils/blkmapd/device-discovery.c:245
#9  bl_discover_devices () at ./utils/blkmapd/device-discovery.c:276
#10 0x67cd in main (argc=, argv=) at ./utils/blkmapd/device-discovery.c:558

The crash is caused by this erroneous free on a pointer that is not
malloc()ed:  
https://salsa.debian.org/kernel-team/nfs-utils/-/blob/master/utils/blkmapd/device-discovery.c#L245

I sent a ping to upstream again[1], and in Ubuntu for now I'll just
remove the faulty free(serial->data) in the 3 places in that function.


1. 
https://lore.kernel.org/linux-nfs/CANYNYEG=utJ2pe+FtMWh8O+dz63R2wbzOC7ZVrvoqD=u04w...@mail.gmail.com/T/#u

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

[Santiago Ruano Rincón]

El 20/10/22 a las 15:18, Paul Wise escribió:
> On Wed, 2022-10-19 at 10:31 +0200, Santiago Ruano Rincón wrote:
> 
> > Bo Yu, could you please check the attached patch instead?
> 
> Personally I prefer my approach for correctness, but including the
> Ubuntu patch would be good to reduce the Ubuntu delta.

OK, you are right, for both things.

> 
> > I am afraid that is no longer a possible solution. Please see
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942502
> 
> Hmm, maybe they could at least switch to embedding them as source
> instead of a tarball then? And also autoreconf before release.

And you are right again :-) This should be solved from the upstream
side. I'll file a bug soon.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#1022025: two reverts required, submitted to stable review list

[Dan Coleman]

On Fri, 21 Oct 2022 13:51:48 + Dan Coleman  wrote:
 > Thanks for sending them! No need for the binary packages, I mostly just want 
 > to see if I can successfully apply patches and get a working kernel.

The patches work! I booted into the new kernel just fine.

Bug#1022139: RFS: dh-runit/2.15.0 -- debhelper add-on to handle runit runscripts

[Lorenzo]

On Fri, 21 Oct 2022 01:17:51 +0200
Adam Borowski  wrote:

> 
> >  dh-runit (2.15.0) unstable; urgency=medium
> >  .
> >* metafiles: write packagename inside a pkg file
> >* Add a bin option, useful for triggered upgrade
> >* update dh-runit manpage
> >* Revert "Temporary disable ghc testsuite"
> >* Update testsuite
> 
> Hi!
> I guess the inclusion of a file named "e -i HEAD~2" was not
> intentional, right?
> 
Correct, re-uploaded on mentors without the "e -i HEAD~2" file.

Links:

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

  https://mentors.debian.net/package/dh-runit/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.15.0.dsc

Git repo:

  https://salsa.debian.org/debian/dh-runit/-/tree/next


> Meow!
Thank You Adam

Bug#937234: trying to remove python2.7 from bookworm

[Nilesh Patra]

On Fri, 16 Sep 2022 22:50:29 +0200 Paul Gevers  wrote:
> Hi Mike,
> 
> On Mon, 15 Aug 2022 13:54:27 + Mike Gabriel 
>  wrote:
> > in another project context I have a freelancer working on pam-python  
> > Py3 transition. Will pick up the threads this week (I returned freshly  
> > from VAC yesterday).
> 
> One month went by, is there any progress to report?

. and it is two months now, w/ nothing happening on this bug reoport.
Mike, do you intend to get working on it?

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1022184: grub2: Update compiler version (currently: gcc-10)

[Bastian Germann]

Source: grub2
Version: 2.06-4

This package build-depends on gcc-11; on amd64, this package can
be built with gcc-11.  If the package cannot be built on any
architecture with gcc-11 because of a compiler bug, please file a
report for gcc-12. Else, please update the compiler version.

You might even be able to update to the current standard gcc-12.
However, this requires changing the package; a test build failed
with dangling-pointer errors.

Bug#1022025: two reverts required, submitted to stable review list

[Dan Coleman]

Thanks for sending them! No need for the binary packages, I mostly just want to 
see if I can successfully apply patches and get a working kernel.

On 10/21/22 08:42 AM, Salvatore Bonaccorso wrote:
> Hi,
>
> On Fri, Oct 21, 2022 at 12:55:09PM +, Dan Coleman wrote:
>> Hey,
>>
>>   > On Thursday, 20 October 2022 22:10:27 CEST Salvatore Bonaccorso wrote:
>>
>>   > > So there are two patches who need to be reverted:
>>   > >
>>   > > 
>> https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/
>>   > > 
>> https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/
>>
>>
>> How do I apply these patches to see if they work for me? Thus far in
>> this bug, I've just seen .patch files.
> Here are those as patches.
>
> If you trust unsigned binary packages build I would put somehwere I
> can provide you those with those two applied. But again, after testing
> make sure you reinstall the meta package and go back to the -18
> version.
>
> Regards,
> Salvatore

Bug#1022183: libcmark-gfm-dev: Please install all .h files

[Yadd]

Package: libcmark-gfm-dev
Version: 0.29.0.gfm.3-3+b1
Severity: important

Hi,

when trying to use libcmark-gfm-dev and libcmark-gfm-extensions-dev to
build node-cmark-gfm, it looks like some files are missing in your *-dev
packages. At least: parser.h, registry.h and syntax_extension.h. Could
you install all .h files (maybe in /usr/include/cmark-gfm) ?

Cheers,
Yadd

Bug#1022182: prads: FTBFS on riscv64 (undefined reference to `_res_opcodes')

[Eric Long]

Source: prads
Version: 0.3.3-7
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: i...@hack3r.moe

Dear maintainer,

prads failed to build on riscv64 due to undefined reference to `_res_opcodes',
which somehow not existent on riscv64 but on other platforms:

```
cc -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong 
-Wformat -Werror=format-security -O3 -DCONFDIR='"/etc/prads/"' -D__USE_GNU -o 
shm-client shm-client.o -Wl,-z,relro -lpcap -lpcre -lresolv
/usr/bin/ld: dump_dns.o: in function `dump_dns':
./src/dump_dns.c:135: undefined reference to `_res_opcodes'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:88: prads] Error 1
```

Full buildd log: 
https://buildd.debian.org/status/fetch.php?pkg=prads=riscv64=0.3.3-7=1634546939=0

After some searching I found this related to libresolv. Using existing shim code
for FreeBSD I am able to fix FTBFS, which is included in the attached
patch.

If more help is needed, please let me know.

Cheers,
Eric
--- prads-0.3.3.orig/src/dump_dns.c
+++ prads-0.3.3/src/dump_dns.c
@@ -98,7 +98,7 @@ void printchars(char buf[NS_MAXDNAME], u
(cp) += INT32SZ; \
 } while (0)

-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__riscv)
 const char *_res_opcodes[] = {
 "QUERY",
 "IQUERY",

Bug#1022025: two reverts required, submitted to stable review list

[Salvatore Bonaccorso]

Hi,

On Fri, Oct 21, 2022 at 12:55:09PM +, Dan Coleman wrote:
> Hey,
> 
>  > On Thursday, 20 October 2022 22:10:27 CEST Salvatore Bonaccorso wrote:
> 
>  > > So there are two patches who need to be reverted:
>  > >
>  > > 
> https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/
>  > > 
> https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/
> 
> 
> How do I apply these patches to see if they work for me? Thus far in
> this bug, I've just seen .patch files.

Here are those as patches.

If you trust unsigned binary packages build I would put somehwere I
can provide you those with those two applied. But again, after testing
make sure you reinstall the meta package and go back to the -18
version.

Regards,
Salvatore
From: Alex Deucher 
Date: Thu, 20 Oct 2022 11:38:56 -0400
Subject: Revert "drm/amdgpu: move nbio sdma_doorbell_range() into sdma code
 for vega"
Origin: https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/
Bug-Debian: https://bugs.debian.org/1022025

This reverts commit 9f55f36f749a7608eeef57d7d72991a9bd557341.

This patch was backported incorrectly when Sasha backported it and
the patch that caused the regression that this patch set fixed
was reverted in commit 412b844143e3 ("Revert "PCI/portdrv: Don't disable AER reporting in get_port_device_capability()"").
This isn't necessary and causes a regression so drop it.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2216
Cc: Shuah Khan 
Cc: Sasha Levin 
Signed-off-by: Alex Deucher 
Cc: # 5.10
Tested-By: Diederik de Haas 
---
 drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c |  5 -
 drivers/gpu/drm/amd/amdgpu/soc15.c | 25 +
 2 files changed, 25 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
index a1a8e026b9fa..1f2e2460e121 100644
--- a/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/sdma_v4_0.c
@@ -1475,11 +1475,6 @@ static int sdma_v4_0_start(struct amdgpu_device *adev)
 		WREG32_SDMA(i, mmSDMA0_CNTL, temp);
 
 		if (!amdgpu_sriov_vf(adev)) {
-			ring = >sdma.instance[i].ring;
-			adev->nbio.funcs->sdma_doorbell_range(adev, i,
-ring->use_doorbell, ring->doorbell_index,
-adev->doorbell_index.sdma_doorbell_range);
-
 			/* unhalt engine */
 			temp = RREG32_SDMA(i, mmSDMA0_F32_CNTL);
 			temp = REG_SET_FIELD(temp, SDMA0_F32_CNTL, HALT, 0);
diff --git a/drivers/gpu/drm/amd/amdgpu/soc15.c b/drivers/gpu/drm/amd/amdgpu/soc15.c
index abd649285a22..7212b9900e0a 100644
--- a/drivers/gpu/drm/amd/amdgpu/soc15.c
+++ b/drivers/gpu/drm/amd/amdgpu/soc15.c
@@ -1332,6 +1332,25 @@ static int soc15_common_sw_fini(void *handle)
 	return 0;
 }
 
+static void soc15_doorbell_range_init(struct amdgpu_device *adev)
+{
+	int i;
+	struct amdgpu_ring *ring;
+
+	/* sdma/ih doorbell range are programed by hypervisor */
+	if (!amdgpu_sriov_vf(adev)) {
+		for (i = 0; i < adev->sdma.num_instances; i++) {
+			ring = >sdma.instance[i].ring;
+			adev->nbio.funcs->sdma_doorbell_range(adev, i,
+ring->use_doorbell, ring->doorbell_index,
+adev->doorbell_index.sdma_doorbell_range);
+		}
+
+		adev->nbio.funcs->ih_doorbell_range(adev, adev->irq.ih.use_doorbell,
+		adev->irq.ih.doorbell_index);
+	}
+}
+
 static int soc15_common_hw_init(void *handle)
 {
 	struct amdgpu_device *adev = (struct amdgpu_device *)handle;
@@ -1351,6 +1370,12 @@ static int soc15_common_hw_init(void *handle)
 
 	/* enable the doorbell aperture */
 	soc15_enable_doorbell_aperture(adev, true);
+	/* HW doorbell routing policy: doorbell writing not
+	 * in SDMA/IH/MM/ACV range will be routed to CP. So
+	 * we need to init SDMA/IH/MM/ACV doorbell range prior
+	 * to CP ip block init and ring test.
+	 */
+	soc15_doorbell_range_init(adev);
 
 	return 0;
 }
-- 
2.37.2

From: Alex Deucher 
Date: Thu, 20 Oct 2022 11:38:57 -0400
Subject: Revert "drm/amdgpu: make sure to init common IP before gmc"
Origin: https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/
Bug-Debian: https://bugs.debian.org/1022025

This reverts commit 7b0db849ea030a70b8fb9c9afec67c81f955482e.

The patches that this patch depends on were not backported properly
and the patch that caused the regression that this patch set fixed
was reverted in commit 412b844143e3 ("Revert "PCI/portdrv: Don't disable AER reporting in get_port_device_capability()"").
This isn't necessary and causes a regression so drop it.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2216
Cc: Shuah Khan 
Cc: Sasha Levin 
Signed-off-by: Alex Deucher 
Cc: # 5.10
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 881045e600af..bde0496d2f15 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ 

Bug#1020043: pillow: FTBFS: ModuleNotFoundError: No module named 'PIL'

[Nilesh Patra]

I have NMU'd and put the pakcage to the DELAY queue with 7-day delay.
Let me know if I should cancel it or reduce the delay.

On Thu, 13 Oct 2022 17:58:54 +0530 Nilesh Patra  wrote:
> diff --git a/debian/rules b/debian/rules
> index 68e9a8c..96cc5ca 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -23,7 +23,7 @@ build-indep: build build-doc-stamp
>  build: build-stamp
>  
>  build-doc-stamp: build
> -   -PYTHONPATH=$(CURDIR)/$(wildcard build/lib.*-$(PY3VER)) $(MAKE) -C 
> docs html
> +   -PYTHONPATH=$(CURDIR)/$(wildcard build/lib.*) $(MAKE) -C docs html
> touch $@
>  
>  build-stamp: $(PY3VERS:%=build-stamp-python%) 
> $(PY3VERS:%=check-stamp-python%)

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Bug#1022181: pygccjit: non-standard gcc used for build (gcc-10)

[Bastian Germann]

Source: pygccjit
Severity: important
Version: 0.4-12

This package depends on a non-standard compiler version; on amd64,
this package can be built with libgccjit-12-dev, gcc-12.  If the
package cannot be built on any architecture with gcc-12 because
of a compiler bug, please file a report for gcc-12. Else, please
switch to gcc-12.

Bug#1022173: Arbitrary and frequent 100% CPU load symptom with Libreoffice Writer 1:7.0.4

[Rene Engelhard]

severity 1022173 minor
forcemerge 964549 1022173
thanks

Hi,

Am 21. Oktober 2022 14:39:13 MESZ schrieb Robin :
>Looks possibly like a regression of a bug reported in 2020 already for an 
>older Libreoffice release:
>#964549

Well, that one never was handled at all, actually. It's open still.

Let's merge them since the description sounds familiar enough.

Regards

Rene
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#1022180: shim: non-standard gcc used for build (gcc-10)

[Bastian Germann]

Package: shim
Severity: important

(Follow-up on #978521):
This package depends on a non standard compiler version; on amd64,
this package can be built with the default version of gcc.  If the
package cannot be built on any architecture with GCC 12 because
of a compiler bug, please file a report for gcc-12. Else, please
switch to the default gcc.

Bug#1022179: groff-base: Support for .Ss that breaks a line may be improved to match .Sh

[наб]

Package: groff-base
Version: 1.22.4-6
Severity: wishlist

Dear Maintainer,

I realise this is a "god help you if your abstract goes over one page,
try writing less" situation, but: subsections that span multiple lines
(because they're moderately long), end up with their first line
dedented, but all subsequent ones indented at text level;
for example, in grotty output:
-- >8 --
   X/Open CAE Specification, System Interface Definitions Issue 4, Version 2;
 X/Open CAE Specification, System Interfaces and Headers Issue 4, Version
 2; X/Open CAE Specification, Commands and Utilities Issue 4, Version 2
 Also sometimes known as the Single UNIX Specification (“SUS”) partially
 extract "IEEE Draft Standard P1003.2/D12" and "IEEE Std 1003.1-1990" —
-- >8 --
of course, this is 80 columns and borderline-pathological input,
but it's not that much better (break after the second CAE) at A4.

I've patched my doc-common .de Ss as such:
-- >8 --
1039 .if !\n[cR] \
1040 .ne 3
1041 .\"ti -.25i
1042 .in -.25i
1043 .nr doc-reg-Ss \n[.ss]
1044 .nr doc-reg-Ss1 \n[.sss]
1045 .ss (\n[.ss] * 5 / 4) (\n[.sss] * 5 / 4)
1046 .nr doc-arg-ptr +1
1047 .nr doc-curr-font \n[.f]
1048 .nr doc-curr-size \n[.ps]
1049 .nop \*[doc-Sh-font]\c
1050 .doc-print-recursive
1051 .ss \n[doc-reg-Ss] \n[doc-reg-Ss1]
1052 .ta T .5i
1053 .in
1054 .if !\n[cR] \
1055 .ne 2
-- >8 --
i.e. by replacing the .ti on line 1041 with an .in (1042),
and reverting the indent for text on line 1053,
and can confirm it renders as-expected in grotty (and grops):
-- >8 --
   X/Open CAE Specification, System Interface Definitions Issue 4, Version 2;
   X/Open CAE Specification, System Interfaces and Headers Issue 4, Version 2;
   X/Open CAE Specification, Commands and Utilities Issue 4, Version 2
 Also sometimes known as the Single UNIX Specification (“SUS”) partially
 extract "IEEE Draft Standard P1003.2/D12" and "IEEE Std 1003.1-1990" —
-- >8 --

This appears to be already done by .de Sh, with lines 986 and 1008 in
the following (in both grotty and grops outputs):
-- >8 --
 986 .in 0
 987 .nr doc-have-author 0
 988 .\}
 989 .doc-setup-page-layout
 990 .sp
 991 .ns
1004 .nop \*[doc-Sh-font]\c
1005 .doc-print-recursive
1006 .if t \
1007 .ss \n[doc-reg-Sh] \n[doc-reg-Sh1]
1008 .in +\n[doc-subheader-indent]u
1009 .ns
1010 .doc-check-depth
-- >8 --

So this would be a nice feature-match :)

Best,
наб

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

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

Versions of packages groff-base depends on:
ii  libc6 2.31-13+deb11u4
ii  libgcc-s1 10.2.1-6
ii  libstdc++610.2.1-6
ii  libuchardet0  0.0.7-1

groff-base recommends no packages.

Versions of packages groff-base suggests:
ii  groff  1.22.4-6

-- no debconf information


signature.asc
Description: PGP signature

Bug#1022173: Arbitrary and frequent 100% CPU load symptom with Libreoffice Writer 1:7.0.4

[Rene Engelhard]

notfound 1022173 1:7.0.4-4+deb11u3_bpo10+1
found 1022173 1:7.0.4-4+deb11u3
tag 1022173 + moreinfo
thanks

Am 21. Oktober 2022 14:39:13 MESZ schrieb Robin :
>Package: libreoffice-writer
>Version: 1:7.0.4-4+deb11u3_bpo10+1

No. You even say the correct version below:

1:7.0.4-4+deb11u3~bpo10+1

The _ is just because the UI displays the ~ wrongly.

In a related note, read the docs. https://backports.debian.org/Instructions/ 
clearly says:

"Report Bugs

Please report bugs in backported packages to the backports mailing list and NOT 
to the Debian BTS!
"


>CPU threads: 1; 
(...)
> $ lscpu
> Architecture: i686
> CPU op-mode(s): 32-bit
> Byte Order: Little Endian
> Address sizes: 32 bits physical, 32 bits virtual
> CPU(s): 1
> On-line CPU(s) list: 0
> Thread(s) per core: 1
> Core(s) per socket: 1
> Socket(s): 1
> NUMA node(s): 1
> Vendor ID: GenuineIntel
> CPU family: 6
> Model: 13
> Model name: Intel(R) Pentium(R) M processor 1.73GHz

Wow.
Maybe time to get hardware from this or last century even?

>$ lsb_release -a
>No LSB modules are available.
>Distributor ID:Debian
>Description:   Debian GNU/Linux 10 (buster)
>Release:   10
>Codename:  buster

Buster is out of life. 

Does it still happen with bullseye? (Assume so since the buster-backports 
version is built from bullseye)
Does it happen with the version in bullseye-backports?

(Btw, you want to upgrade to deb11u4 backport whenever it is approved 
immediately to fix a security bug)
Regards

Rene
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#1022173: Correction

[Robin]

Originally I've written:
“—When Libreoffice is ideling in its document selection launch (where you can 
select previously used documents from a screen) without a document being opened 
in one of its components, this issue doesn't happen at all.”

This is not true as I found out meanwhile. True is instead:
—When Libreoffice is ideling in its document selection launch (where you can 
select previously used documents from a screen) without a document being opened 
in one of its components, it happens also. But then it is enough to give the 
Libreoffice window focus by either activating, restoring or maximising it. When 
minimising it, or put it in background, immediately after it has got focus for 
a short time (a second is fine already), without any further action, the CPU 
load from soffice.bin will stay normal for some time again, without need of 
saving something (which wouldn't be possible from this window anyway).

Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs

[Marco d'Itri]

On Oct 21, Andras Korn  wrote:

> I thought --ignore-install was completely broken, but no, because without it, 
> the output contains *more* "install" lines:
What you are actually seeing is that --ignore-install is applied only to 
the nfs module (the one which you have requested to load) but not to its 
own dependencies:

diff -U 0 <(modprobe --all --set-version="6.0.0-1-amd64" --ignore-install 
--quiet --show-depends nfs) <(modprobe --all --set-version="6.0.0-1-amd64" 
--quiet --show-depends nfs)

I am not sure if this is a bug or a feature, so this should be discussed 
with the upstream maintainer.

So the possible solutions are:
- the semantics of --ignore-install are changed upstream (this may take 
  some time)
- initramfs-tools learns to parse the install directives
- nfs-kernel-server uses a different design

No matter what happens to --ignore-install I suggest that 
nfs-kernel-server will replace the modprobe configuration with some udev 
rules like this one (untested):

ACTION=="add", SUBSYSTEM=="module", KERNEL=="sunrpc", \
  RUN+="/sbin/sysctl -q --pattern sunrpc --system"

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1022178: safe: Import new version

[Bastian Germann]

Source: safe
Version: 1.0.1-1

Please import a new version so that I can make a source-only upload.
Either a new revision or a new upstream version.

Bug#1022165: nvidia-driver: Regression with PowerManagement Support (resume after suspend)

[Tobias Frost]

Control: tags -1 fixed-upstream

Hi Andreas,

On Fri, Oct 21, 2022 at 02:52:13PM +0200, Andreas Beckmann wrote:
> On 21/10/2022 14.11, Tobias Frost wrote:
> > (I've removed the complete line
> > options nvidia NVreg_PreserveVideoMemoryAllocations=1 
> > NVreg_TemporaryFilePath=/var/cache/nvidia
> > in my /etc/modprobe.d/nvidia-options.conf)
> 
> If this affects more people we could issue a warning in postinst if this
> parameter is found in nvidia-options.conf

That won't be needed :)
I've did a quick and dirty packaing of upstream'S 515.76 driver [1],
and this driver does not show the garbling, evenwith 
NVreg_PreserveVideoMemoryAllocations
turned on. This is consistent with a comment on the nvidia forum (see forwarded
link, response 16) saying that they have adressed the issue.

> We don't have that in there by default, not even commented.

Yes, I know... When I first had the issue with Gnome being ugly to unuseable in
Jan 2022, it took me quite some time to figure this out eventually find the
solution… So I wonder if it would be actually be better, if enabled by default?
The bug in Ubuntu - 
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1876632
shows that this affects quite some people…

-- 
tobi

[1] Went surpisingly smooth. Kudos for your packaging work!
A patch, module/debian/conftest-verbose.patch was not applying, and it seems
that there is no longer a library for lib${nvidia}-nvvm4 and I had to add one 
entry
to nv-readme.ids, and basically then it built :)

Bug#794821: libwxbase3.0-0: segmentation fault (SIGSEGV) with gnuplot5

[Scott Talbert]

On Fri, 21 Oct 2022, Vincent Lefevre wrote:


Control: reassign -1 libwxbase3.0-0v5 3.0.5.1+dfsg-5

as the bug still occurs.

On 2019-10-10 08:21:22 +1300, Olly Betts wrote:

Hmm, I don't seem to get a core file (and sadly am struggling to work
out how to enable them on current Debian).

But repeating that after installing these packages (assuming unstable)
would be more enlightening:

libwxbase3.0-0v5-dbgsym libwxgtk3.0-gtk3-0v5-dbgsym


Here's the backtrace:


As of yesterday, gnuplot has been rebuilt using wxWidgets 3.2.  Can you 
please try again with gnuplot 5.4.4+dfsg1-2 and see if the crash still 
exists?


Thanks,
Scott

Bug#1021926: clang-14 fails to run with "Illegal Instruction" at i386 (pre SSE2), is linking to libz3 really needed.

[Bernhard Übelacker]

Dear Maintainer,
in the meantime there got a merge request [1] accepted to libz3-4,
which might solve this issue by avoiding sse2 instructions,
and is still awaiting an upload to unstable.

[1] https://salsa.debian.org/pkg-llvm-team/z3/-/merge_requests/9

Kind regards,
Bernhard

Bug#1022177: mod-wsgi: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Source: mod-wsgi
Version: 4.9.0-1.1
Severity: important
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

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

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

Regards
Graham


make[2]: Entering directory '/<>/build-3.11'
/usr/bin/apxs2 -c -Wdate-time -D_FORTIFY_SOURCE=2
-I/usr/include/python3.11 -DNDEBUG  -Wc,-g -Wc,-O2
-Wc,-ffile-prefix-map=/home/gi>/usr/share/apr-1.0/build/libtool
--mode=compile --tag=disable-static x86_64-linux-gnu-gcc -prefer-pic
-pipe -g -O2 -fstack-protect>libtool: compile:  x86_64-linux-gnu-gcc
-pipe -g -O2 -fstack-protector-strong -Wformat -Werror=format-security
-Wdate-time -D_FORTI>src/server/mod_wsgi.c: In function
‘wsgi_log_stack_traces’:
src/server/mod_wsgi.c:9524:32: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9524 | if (current->f_trace) {
  |^~
src/server/mod_wsgi.c:9525:41: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9525 | lineno = current->f_lineno;
  | ^~
src/server/mod_wsgi.c:9528:58: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9528 | lineno = PyCode_Addr2Line(current->f_code,
  |  ^~
src/server/mod_wsgi.c:9529:58: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9529 |   current->f_lasti);
  |  ^~
src/server/mod_wsgi.c:9533:56: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9533 | filename =
PyUnicode_AsUTF8(current->f_code->co_filename);
  |^~
src/server/mod_wsgi.c:9534:52: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9534 | name = PyUnicode_AsUTF8(current->f_code->co_name);
  |^~
src/server/mod_wsgi.c:9547:36: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9547 | if (current->f_back) {
  |^~
src/server/mod_wsgi.c:9561:38: error: invalid use of incomplete
typedef ‘PyFrameObject’ {aka ‘struct _frame’}
 9561 | current = current->f_back;
  |  ^~
apxs:Error: Command failed with rc=65536
.
make[2]: *** [Makefile:31: src/server/mod_wsgi.la] Error 1

Bug#1022042: Similar problem with Radeon R7 360

[Andreas Wirooks]

I am running Debian 11 with linux-image-5.10.0-19-amd64 and can confirm a similar problem with an AMD Radeon R7 360 on an Intel X58 board with Intel Xeon W3530 CPU and classic BIOS.

 


Kernel parameters are radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1 amdgpu.gpu_recovery=1

 

Nothing is logged and screen is black. No error messages at all. Works flawless with linux-image-5.10.0-18-amd64.

 

Kind regards,

Andreas

Bug#1022025: two reverts required, submitted to stable review list

[Dan Coleman]

Hey,

 > On Thursday, 20 October 2022 22:10:27 CEST Salvatore Bonaccorso wrote:

 > > So there are two patches who need to be reverted:
 > >
 > > https://lore.kernel.org/stable/20221020153857.565160-1-alexander.deuc...@amd.com/
 > > https://lore.kernel.org/stable/20221020153857.565160-2-alexander.deuc...@amd.com/


How do I apply these patches to see if they work for me? Thus far in this bug, 
I've just seen .patch files.