Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Lucas Nussbaum]

Hi,

On 10/03/23 at 23:25 +, Samuel Henrique wrote:
> Hello Daniel
> 
> > > I couldn't find anything in the release notes which look like a
> > > breaking change[0]
> >
> > Lots of people and CI systems run all the tests flawlessly all the time, so
> > there is reason to suspect that there is something slightly unusual in your
> > test setup that causes these problems. Meaning that I suspect this is not a
> > curl problem, this is a curl test problem.
> >
> > Are these problems different or the same as the ones already filed at
> > https://github.com/curl/curl/issues/10682 ?
> 
> I think it's a different issue, we have good evidence that those
> failures are triggered by an IPv6-only host and I acknowledge your
> solution to document that tests require IPv4 support for now.
> 
> Salvatore can double check but the build logs indicate that the host
> used to build lnav had an IPv4 address.
> 
> I also don't think lnav is running any of the curl's tests, but rather
> making use of the curl library to run their tests, which leads me to
> believe that whatever issue it is, it has to be something very
> specific and uncommon (and not related to curl's tests), otherwise
> there would be more reports.
> 
> By the way I should have replied on that issue just in case: but feel
> free to close it if you'd like to track IPv6-only support somewhere
> else, or to rename it if you'd like to use it to track support for
> that. Me and sergiodj are thinking about giving it a try at solving
> that but we're not sure when (in the packaging, for now, we are
> ignoring those test results).
> 
> Me and sergiodj are also currently investigating a test issue related
> to ppc64el, we have got some good insights already, but would like to
> fully understand what's going on and have a patch ready before
> reporting. Also that issue only affects curl's own tests so it can't
> be related to this.
> 
> Cheers,

Regarding the issue I reported in this bug:

This triggers on a host with both IPv4 and IPv6.

With curl 7.88.1-6, both tests test_sql_fs_func.sh and test_sql_fs_func.sh fail

With curl 7.87.0-2, test_sql_fs_func.sh fails and test_sql_str_func.sh passes



The failure for test_sql_str_func.sh with version 7.88.1-6 is:

Command: test: env TEST_COMMENT=invalid_url ./drive_sql
BEGIN test_sql_str_func.sh_3855d2cc0ab29171cae8e722f130adec25eae36e.out
END   test_sql_str_func.sh_3855d2cc0ab29171cae8e722f130adec25eae36e.out
BEGIN test_sql_str_func.sh_3855d2cc0ab29171cae8e722f130adec25eae36e.err
error: sqlite3_exec failed -- 
lnav-error:{"level":"error","message":{"str":"invalid URL: 
“https://bad@[fe::”","attrs":[]},"reason":{"str":"Bad IPv6 
address","attrs":[]},"snippets":[],"help":{"str":"","attrs":[]}}
END   test_sql_str_func.sh_3855d2cc0ab29171cae8e722f130adec25eae36e.err
ERR: test: env TEST_COMMENT=invalid_url ./drive_sql
--- 
/root/lnav-0.11.1/test/expected/test_sql_str_func.sh_3855d2cc0ab29171cae8e722f130adec25eae36e.err
   2022-10-11 03:12:58.0 +
+++ test_sql_str_func.sh_3855d2cc0ab29171cae8e722f130adec25eae36e.err   
2023-03-11 07:27:53.862049124 +
@@ -1 +1 @@
-error: sqlite3_exec failed -- 
lnav-error:{"level":"error","message":{"str":"invalid URL: 
“https://bad@[fe::”","attrs":[]},"reason":{"str":"Port number was not a decimal 
number between 0 and 
65535","attrs":[]},"snippets":[],"help":{"str":"","attrs":[]}}
+error: sqlite3_exec failed -- 
lnav-error:{"level":"error","message":{"str":"invalid URL: 
“https://bad@[fe::”","attrs":[]},"reason":{"str":"Bad IPv6 
address","attrs":[]},"snippets":[],"help":{"str":"","attrs":[]}}
FAIL! EXPECTED ERR DIFF

The failure for test_sql_fs_func.sh is:

Command: test: ./drive_sql select joinpath('foo', 'bar', 'baz', '/root')
BEGIN test_sql_fs_func.sh_73df81c6889d1f06fb3f3b6bf30c6046b3f52c8b.out
Row 0:
  Column joinpath('foo', 'bar', 'baz', '{top_srcdir_parent}'): 
{top_srcdir_parent}
END   test_sql_fs_func.sh_73df81c6889d1f06fb3f3b6bf30c6046b3f52c8b.out
OUT: test: ./drive_sql select joinpath('foo', 'bar', 'baz', '/root')
--- 
/root/lnav-0.11.1/test/expected/test_sql_fs_func.sh_73df81c6889d1f06fb3f3b6bf30c6046b3f52c8b.out
2022-10-11 03:12:58.0 +
+++ test_sql_fs_func.sh_73df81c6889d1f06fb3f3b6bf30c6046b3f52c8b.out
2023-03-11 07:26:52.144915467 +
@@ -1,2 +1,2 @@
 Row 0:
-  Column joinpath('foo', 'bar', 'baz', '/root'): /root
+  Column joinpath('foo', 'bar', 'baz', '{top_srcdir_parent}'): 
{top_srcdir_parent}
FAIL! EXPECTED OUT DIFF
BEGIN test_sql_fs_func.sh_73df81c6889d1f06fb3f3b6bf30c6046b3f52c8b.err
END   test_sql_fs_func.sh_73df81c6889d1f06fb3f3b6bf30c6046b3f52c8b.err
FAIL test_sql_fs_func.sh (exit status: 1)

Lucas

Bug#990016: Debian installer images missing ASpeed video driver

[Salvatore Bonaccorso]

Hi Héctor,

On Sat, Mar 11, 2023 at 01:15:31AM +0100, Héctor Orón Martínez wrote:
> Hello,
> 
>   I have opened an MR in salsa:
>   https://salsa.debian.org/kernel-team/linux/-/merge_requests/676

I assume you were able to test it accordingly it works as expected?

Looks fine IMHO, but wanted to double-check with you.

Regards,
Salvatore

Bug#1032693: RM: puppet-beaker -- ROM; RC buggy, no rdeps, umaintained and blocks transitions

[Utkarsh Gupta]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: s...@debian.org

Hello,

The package was already orphaned (#1001000) back in December 2021
and it has been unmaintained since then. The package is not in
testing either because of 2 RC bugs - #1025979 and #1026491.

Since this is not being looked after and often blocks Ruby transitions
in one way or the other, I'd like to request its removal from the
archive.

$ reverse-depends src:puppet-beaker
No reverse dependencies found

$ reverse-depends -b src:puppet-beaker
No reverse dependencies found

puppet-beaker suggests and recommends no packages either.

Should you have any questions or concerns, please let me know. TIA.

Bug#1032692: ITP: gitleaks -- protect and discover secrets using Gitleaks

[Anthony Fok]

Package: wnpp
Severity: wishlist
Owner: Anthony Fok 

* Package name: gitleaks
  Version : 8.16.0-1
  Upstream Author : Zachary Rice
* URL : https://github.com/gitleaks/gitleaks
* License : Expat
  Programming Lang: Go
  Description : protect and discover secrets using Gitleaks 

 Gitleaks is a SAST tool for **detecting** and **preventing** hardcoded
 secrets like passwords, api keys, and tokens in git repos.  Gitleaks is
 an **easy-to-use, all-in-one solution** for detecting secrets, past or
 present, in your code.

Bug#1011549: openrocket needs newer jogl

[tony mancill]

Hello Pierre,

On Fri, Mar 10, 2023 at 10:23:53PM +0100, Pierre Gruet wrote:
> Hi tony,
> 
> On Sun, 12 Feb 2023 10:15:35 -0800 tony mancill  wrote:
> >
> > Okay, first the good news. There are upstream tags for 2.4.0. I have
> > started working on adapting the sequence of debian/patches against the
> > new release.
> >
> > But in addition to not yet being done with that, it didn't seem prudent
> > to try to push this into bookwork at the last minute, and that wouldn't
> > have given the reverse dependencies any time to react anyway. So I am
> > going to work towards an upload to experimental soon, and then we can
> > aim for getting this into unstable/testing after the freeze.
> 
> I fully understand your position. However I recently looked at scilab, a
> rdep of jogl, and saw it is severely broken -- although a key package, so it
> will be shipped in Bookworm anyway. Scilab cannot be run in GUI mode, only
> in command-line mode with plots not working (after some tweaking I am
> working on).
> 
> Locally I tried to update jogl to version 2.4.0 (I had not seen you were
> working on it, sorry), and to do so I also had to update its dependency
> gluegen2 to version 2.4.0 (possibly you have already seen it), and then the
> command-line mode would allow one to make plots.

Yes, I saw the upload of gluegen2.  Thank you for doing that and need to
apologize!

> Given the Hard freeze begins in two days, I will only touch scilab and not
> jogl nor gluegen2 right now.
> 
> It you want, I can upload my changes to gluegen2 and jogl2 to experimental
> in the upcoming days. But if you prefer doing it yourself, please tell me
> and do so when you are ready :)

Please feel free to go ahead with your uploads.  Working code, made
available to all, is what's important.  And there are plenty of other
packages for me to work on.  :)

Best regards,
tony


signature.asc
Description: PGP signature

Bug#1032691: rinse: fedora-37 is not installable

[Dima Kogan]

Package: rinse
Version: 4.1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. 

This might not be a RINSE bug, but an issue with the fedora servers.
Nevertheless...

Today I can use rinse to reliably create a fedora-36 install. Just tried
it twice; worked both times.

The same command reliably fails with fedora-37. The exact failure mode
varies. Sometimes it does this:

  $ sudo rinse --distribution fedora-37 --directory root_fedora2 --arch amd64

  Failed to fetch : 
http://download.fedoraproject.org/pub/fedora/linux/releases/37/Everything/x86_64/os/Packages//z/
404 Not Found

Which is odd because navigating there with a browser works.

Sometimes it does this instead:

  $ sudo rinse --distribution fedora-37 --directory root_fedora2 --arch amd64

  [Harmless] Failed to find download link for acl
  [Harmless] Failed to find download link for alternatives
  [Harmless] Failed to find download link for audit-libs
  [Harmless] Failed to find download link for basesystem
  
  [Harmless] Failed to find download link for xz-libs
  [Harmless] Failed to find download link for zchunk-libs
  [Harmless] Failed to find download link for zlib


  Running post-install script /usr/lib/rinse/common/10-resolv.conf.sh:
  Running post-install script /usr/lib/rinse/common/15-mount-proc.sh:
  Running post-install script /usr/lib/rinse/common/20-dev-zero.sh:
  Running post-install script /usr/lib/rinse/fedora-37/post-install.sh:
Setting up DNF cache
  mv: cannot stat 'root_fedora2/*.rpm': No such file or directory
  cp: cannot stat '/var/cache/rinse//fedora-37.amd64/*': No such file or 
directory
  mv: cannot stat 'root_fedora2/etc/yum.repos.d': No such file or directory
Bootstrapping DNF
  chroot: failed to run command '/usr/bin/dnf': No such file or directory
  mv: cannot stat 'root_fedora2/etc/yum.repos.d.orig': No such file or directory
  chroot: failed to run command 'update-ca-trust': No such file or directory
Updating packages
  chroot: failed to run command '/usr/bin/dnf': No such file or directory
  chroot: failed to run command '/usr/bin/dnf': No such file or directory
  Installation complete.


It claims to have succeeded successfully, but it did not at all. This is
a bug too (it should know that it failed).

Thanks


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

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

Versions of packages rinse depends on:
ii  cpio   2.13+dfsg-7
ii  libterm-size-perl  0.211-1+b2
ii  libwww-perl6.67-1
ii  perl   5.36.0-4
ii  rpm4.17.0+dfsg1-4+b1
ii  rpm2cpio   4.17.0+dfsg1-4+b1
ii  wget   1.21.3-1+b2

rinse recommends no packages.

rinse suggests no packages.

-- no debconf information

Bug#979090: Legally problematic GPL-3+ readline dependency

[Milan Kupcevic]

On 1/27/23 12:04, Bastian Germann wrote:

Control: severity -1 serious
Control: retitle -1 avrdude: inaccurate copyright file

There are more problems:
The doc's GFDL license is not mentioned and seems to be the variant 
without NIV.

This is considered a non-free license by Debian. Please ask upstream for a
license change or drop the files from the source package.



Hi Bastian,

I was not able to identify any invariant sections in documentation. As 
far as I can see this document [0] is free and is eligible for Debian 
main in accordance with General Resolution 2006/001 [1]


Milan

[0] 
https://sources.debian.org/src/avrdude/6.3-20171130%252Bsvn1429-2/doc/avrdude.texi

[1] https://www.debian.org/vote/2006/vote_001

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

[Pete Batard]

Thanks for looking into this.

Just going to add, in case you wonder why it shouldn't be up to the 
software that is mounting the ISO to sort out symbolic links and just 
duplicate content, that neither Windows File Explorer nor 7-zip (both of 
which can mount/extract ISO content) will list anything under the 
'/firmware/' directory besides the 'dep11/' subdirectory and the 
'Contents-firmware' file.


In short, a Windows user trying to use the most common ways of 
extracting ISO content will be missing all the '*.deb' firmware files in 
'/firmware/'. So this means that, unfortunately, the issue can't exactly 
be dismissed as something that should be fixed at the ISO mounting level 
rather than at the Debian ISO mastering level, at least for Windows users.


I guess one approach could be to have the Debian firmware detection and 
loading software handle something like plain text files containing a 
relative path when they use a specific extension (e.g. .deblink), in 
order to perform the link resolution manually instead of relying on the 
underlying file system...


Regards,

/Pete

Bug#1032690: alsa-ucm-conf: No sound on GPD Pocket 1

[Marc]

Package: alsa-ucm-conf
Version: 1.2.8-1
Severity: important
X-Debbugs-Cc: dkm+report...@kataplop.net

Dear Maintainer,

After a fresh installation of Debian on my GPD Pocket 1, there is no sound.
I've updated my system to sid, hoping the issue would be fixed there, but it's 
not.
The sound was working correctly with the previous ubuntu (initially modified 
with things like 
https://github.com/stockmind/gpd-pocket-ubuntu-respin/blob/master/audio/HiFi.conf
 ).

Currently, pavucontrol shows an audio output device called "Pro Audio" and 
playing sound seemsto work (the player is stuck, I can see the vumeter moving 
in pavucontrol)...
but I don't hear anything from speaker or headphones.

syslog has also these messages repeated over and over:

[174899.046296]  Audio Port: ASoC: no backend DAIs enabled for Audio Port
[174899.046317]  Audio Port: ASoC: error at dpcm_fe_dai_prepare on Audio Port: 
-22
[174899.047672]  Deep-Buffer Audio Port: ASoC: no backend DAIs enabled for 
Deep-Buffer Audio Port
[174899.047690]  Deep-Buffer Audio Port: ASoC: error at dpcm_fe_dai_prepare on 
Deep-Buffer Audio Port: -22
[174899.167717]  Audio Port: ASoC: no backend DAIs enabled for Audio Port
[174899.167738]  Audio Port: ASoC: error at dpcm_fe_dai_prepare on Audio Port: 
-22
[174899.170218]  Deep-Buffer Audio Port: ASoC: no backend DAIs enabled for 
Deep-Buffer Audio Port

Grepping ucm files, I see references to the chip (chtrt5645) my laptop has. 
There's even mentions of gpd-pocket in a cof file.

Filling a bug in alsa-ucm-conf as people with similar error usually fix it by 
installing correct ucm files. But these are also found in old forums messages 
that points to obsolete github package for UCM files... 
Feel free to tell me if this is not an UCM issue and I should report this issue 
somewhere else

thanks,
Marc 

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

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

Versions of packages alsa-ucm-conf depends on:
ii  libasound2  1.2.8-1+b1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

Bug#1032689: rinse: Manpage is incorrect

[Dima Kogan]

Package: rinse
Version: 4.1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. The manpage says

  Basic usage is as simple as:

   rinse --distribution fedora-core-6 --directory /tmp/test

  This will download the required RPM files and unpack them into
  a minimal installation of Fedora Core 6.

This is incorrect. This just happened:

  $ sudo rinse --distribution fedora-37 --directory root_fedora

  The name of the architecture is mandatory.
  Please specify i386, amd64 or arm64.

So the architecture is a required argument, and the manpage should
include that in its example.

Thanks!



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

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

Versions of packages rinse depends on:
ii  cpio   2.13+dfsg-7
ii  libterm-size-perl  0.211-1+b2
ii  libwww-perl6.67-1
ii  perl   5.36.0-4
ii  rpm4.17.0+dfsg1-4+b1
ii  rpm2cpio   4.17.0+dfsg1-4+b1
ii  wget   1.21.3-1+b2

rinse recommends no packages.

rinse suggests no packages.

-- no debconf information

Bug#1032688: ugene: unused build-dependency on removed libprocps-dev

[Steve Langasek]

Package: ugene
Version: 40.1+dfsg-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear maintainers,

The ugene package has unsatisfiable build-dependencies in testing and
unstable, because it build-depends on libprocps-dev which has been removed.

This build-dependency didn't block the removal of libprocps8, because
despite the build-dependency, ugene has no runtime dependency on libprocps.

I haven't verified that the package builds with this change, because it
appears that the package ftbfs with or without this change in Ubuntu.  But I
can say that the string '-lprocps' doesn't appear anywhere in the last
successful build log.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ugene-40.1+dfsg/debian/control ugene-40.1+dfsg/debian/control
--- ugene-40.1+dfsg/debian/control  2022-04-26 05:25:30.0 -0700
+++ ugene-40.1+dfsg/debian/control  2023-03-10 17:55:56.0 -0800
@@ -20,7 +20,6 @@
debhelper-compat (= 13),
libxtst-dev,
libsqlite3-dev,
-   libprocps-dev
 Build-Conflicts: libqt4-dev,
  qt4-qmake
 Standards-Version: 4.6.0

Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin

[dkm]

> 1) First remove the symlink you created above.
> 2) Get the .deb for version 20230117-2 and install that
> 3) Reboot and verify that your wifi works as it should

it works as expected...

> 4) If so, upgrade to the 20230210-1 version and reboot
> 5) verify that wifi is now broken

... and this breaks the wifi with module not finding the fw, as expected (same 
error message)

> Let me/us know how that test goes.

:)

Marc

Bug#1032687: pylint: conffiles not removed: /etc/emacs/site-start.d/50pylint.el

[Paul Wise]

Package: pylint
Version: 2.16.2-2
Severity: normal
User: debian...@lists.debian.org
Usertags: obsolete-conffile adequate

The recent upgrade did not deal with obsolete conffiles properly.
Please use the dpkg-maintscript-helper support provided by
dh_installdeb to remove these obsolete conffiles on upgrade.

https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
https://manpages.debian.org/man/1/dh_installdeb

This bug report brought to you by adequate:

https://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/

$ p=pylint ; adequate $p ; dpkg-query -W -f='${Conffiles}\n' $p | grep obsolete
pylint: obsolete-conffile /etc/emacs/site-start.d/50pylint.el
 /etc/emacs/site-start.d/50pylint.el 048138b0fe7fceccd86f814eb36223e1 obsolete

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing-security
  APT policy: (950, 'testing-security'), (900, 'testing-debug'), (900, 
'testing'), (850, 'buildd-testing-proposed-updates'), (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.1.0-6-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 pylint depends on:
ii  python3    3.11.2-1
ii  python3-astroid    2.14.2-1
ii  python3-dill   0.3.6-1
ii  python3-isort  5.6.4-1
ii  python3-logilab-common 1.9.8-1
ii  python3-mccabe 0.7.0-1
ii  python3-platformdirs   2.6.0-1
ii  python3-setuptools 66.1.1-1
ii  python3-tomli  2.0.1-2
ii  python3-tomlkit    0.11.6-1
ii  python3-typing-extensions  4.4.0-1

Versions of packages pylint recommends:
ii  python3-tk  3.11.2-2

Versions of packages pylint suggests:
pn  pylint-doc  

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#940444: ITA: golang-gopkg-h2non-filetype.v1

[Anthony Fok]

Control: retitle -1 ITA: golang-gopkg-h2non-filetype.v1
Control: owner -1 !

Hello,

I intend to adopt this package because a newer version of
golang-gopkg-h2non-filetype.v1 (now known as github.com/h2non-filetype
v1.1.3) is needed by gitleaks.

Thank you Alexandre for your great work in creating and maintaining
this package!

Cheers,
Anthony

Bug#986724: Already fixed

[Andreas Teiß]

Hello,

is this bug already fixed in libc6 2.28-10+deb10u2?

Regards,
Andreas

Bug#928300: secure boot via removable media path unavailable

[Steve McIntyre]

Hey guys,

Apologies for not getting back to you in better time...

I've just uploaded new shim-signed binaries for all of buster,
bullseye and unstable based on the latest upstream version (15.7). I
can't *promise* that this will fix your issue, but it would be very
helpful if you could try them and let me know please.

The buster upload should be already available via security.debian.org;
the bullseye version is in bullseye-proposed updates if you need to
look.

You'll need to grab the appropriate shim-signed and shim-signed-common
packages together, then install by hand.

If that still doesn't help, the next thing to try is turning on shim
debug using:

$ sudo mokutil --set-verbosity true

This will produce a *lot* of output; if you can capture it via video
or on a serial port, that may help diagnose what's happening.

Thanks!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"C++ ate my sanity" -- Jon Rabone

Bug#1032686: [INTL:ro] Romanian debconf templates translation of man2html

[Remus-Gabriel Chelu]

Package: man2html
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the man2html file.

Thanks,
Remus-Gabriel

man2html_debconf_ro.po
Description: Binary data

Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin

[Diederik de Haas]

On Friday, 10 March 2023 17:16:48 CET Diederik de Haas wrote:
> On Friday, 10 March 2023 13:07:22 CET d...@kataplop.net wrote:
> > March 10, 2023 10:57 AM, "Diederik de Haas"  wrote:
> > > I'm 99% sure this would be a *workaround*, but let's verify anyway:
> > > In the /lib/firmware directory, create a symlink from
> > > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin
> > 
> > As expected, it works with the symlink :)
> 
> Thanks, then it's a kernel issue so I'm reassigning accordingly.

New development: I now think it *is* an issue in firmware-brcm80211.
I think it would still be good if the kernel would also check the `cypress` 
directory, but this seems to be a packaging issue.

Via https://snapshot.debian.org/binary/firmware-brcm80211/ you can find
various old versions of the package, and I want you to do the following test:

1) First remove the symlink you created above.
2) Get the .deb for version 20230117-2 and install that
3) Reboot and verify that your wifi works as it should
4) If so, upgrade to the 20230210-1 version and reboot
5) verify that wifi is now broken

Let me/us know how that test goes.

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

Bug#1032685: [INTL:ro] Romanian debconf templates translation of man-db

[Remus-Gabriel Chelu]

Package: man-db
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the man-db file.

Thanks,
Remus-Gabriel

man-db_debconf_ro.po
Description: Binary data

Bug#1032684: [INTL:ro] Romanian debconf templates translation of mailman3

[Remus-Gabriel Chelu]

Package: mailman3
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the mailman3 file.

Thanks,
Remus-Gabriel

mailman3_debconf_ro.po
Description: Binary data

Bug#1032683: [INTL:ro] Romanian debconf templates translation of mailman-hyperkitty

[Remus-Gabriel Chelu]

Package: mailman-hyperkitty
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the mailman-hyperkitty file.

Thanks,
Remus-Gabriel

mailman-hyperkitty_debconf_ro.po
Description: Binary data

Bug#1032682: [INTL:ro] Romanian debconf templates translation of mailagent

[Remus-Gabriel Chelu]

Package: mailagent
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the mailagent file.

Thanks,
Remus-Gabriel

mailagent_debconf_ro.po
Description: Binary data

Bug#1032681: [INTL:ro] Romanian debconf templates translation of macchanger

[Remus-Gabriel Chelu]

Package: macchanger
Severity: wishlist
Tags: l10n, patch

Dear Maintainer,

Please find attached the Romanian translation of the macchanger file.

Thanks,
Remus-Gabriel

macchanger_debconf_ro.po
Description: Binary data

Bug#990016: Debian installer images missing ASpeed video driver

[Héctor Orón Martínez]

Hello,

  I have opened an MR in salsa:
  https://salsa.debian.org/kernel-team/linux/-/merge_requests/676

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#1032680: kdiff3: Crashes when comparing 2 directories (signal: Aborted)

[Diederik de Haas]

Package: kdiff3
Version: 1.10.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I tried to compare 2 directories with kdiff3 and it crashed the moment
it was supposed to show the diff.
This happened initially when selecting the dirs in Dolphin.
Then via the crash handler I restarted kdiff3 and was presented with a
dialog to select files/folders to compare. Selected the same 2
directories again and it crashed immediately.

The KDE Crash Handler said the trace was useful, so copied below:

Application: KDiff3 (kdiff3), signal: Aborted

[KCrash Handler]
#4  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#5  0x7f51868a9d2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#6  0x7f518685aef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#7  0x7f5186845472 in __GI_abort () at ./stdlib/abort.c:79
#8  0x7f5186845395 in __assert_fail_base (fmt=0x7f5180148894 "%s%s%s:%u: 
%s%sControletest '%s' faalt.\n%n", assertion=assertion@entry=0x561be34287a8 
"!m_modificationTime.isNull()", file=file@entry=0x561be3428728 
"./src/fileaccess.cpp", line=line@entry=762, 
function=function@entry=0x561be3428a38 "QDateTime FileAccess::lastModified() 
const") at ./assert/assert.c:92
#9  0x7f5186853df2 in __GI___assert_fail (assertion=0x561be34287a8 
"!m_modificationTime.isNull()", file=0x561be3428728 "./src/fileaccess.cpp", 
line=762, function=0x561be3428a38 "QDateTime FileAccess::lastModified() const") 
at ./assert/assert.c:101
#10 0x561be33b21c0 in FileAccess::lastModified (this=) at 
./src/fileaccess.cpp:762
#11 0x561be33ee182 in MergeFileInfos::compareFilesAndCalcAges 
(this=this@entry=0x561be3ff9c70, errors=..., pOptions=..., pDMW=0x561be3e28490) 
at ./src/MergeFileInfos.cpp:192
#12 0x561be334c4d0 in 
DirectoryMergeWindow::DirectoryMergeWindowPrivate::prepareListView 
(this=this@entry=0x561be395d740, pp=...) at ./src/directorymergewindow.cpp:1331
#13 0x561be334ffbb in 
DirectoryMergeWindow::DirectoryMergeWindowPrivate::init (this=0x561be395d740, 
bDirectoryMerge=, bReload=) at 
./src/directorymergewindow.cpp:951
#14 0x561be3350ee0 in DirectoryMergeWindow::init (this=, 
bDirectoryMerge=, bReload=) at 
./src/directorymergewindow.cpp:736
#15 0x561be3366d59 in KDiff3App::doDirectoryCompare 
(this=this@entry=0x561be39f6c00, 
bCreateNewInstance=bCreateNewInstance@entry=false) at ./src/pdiff.cpp:1627
#16 0x561be333ba3f in KDiff3App::completeInit (this=0x561be39f6c00, 
fn1=..., fn2=..., fn3=...) at ./src/kdiff3.cpp:432
#17 0x561be332dda8 in KDiff3Shell::KDiff3Shell (this=0x561be36e5b50, 
bCompleteInit=, __in_chrg=, __vtt_parm=) at ./src/kdiff3_shell.cpp:60
#18 0x561be33227bb in main (argc=, argv=) at 
./src/main.cpp:197
[Inferior 1 (process 6106) detached]


Cheers,
  Diederik

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

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

Versions of packages kdiff3 depends on:
ii  kio   5.103.0-1
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libkf5configcore5 5.103.0-1
ii  libkf5configwidgets5  5.103.0-1
ii  libkf5coreaddons5 5.103.0-1
ii  libkf5crash5  5.103.0-1
ii  libkf5i18n5   5.103.0-1
ii  libkf5kiocore55.103.0-1
ii  libkf5kiowidgets5 5.103.0-1
ii  libkf5parts5  5.103.0-1
ii  libkf5widgetsaddons5  5.103.0-1
ii  libkf5xmlgui5 5.103.0-1
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5printsupport5   5.15.8+dfsg-3
ii  libqt5widgets55.15.8+dfsg-3
ii  libstdc++612.2.0-14

Versions of packages kdiff3 recommends:
ii  kdiff3-doc  1.10.0-1

kdiff3 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCZAvHYAAKCRDXblvOeH7b
bmgpAQDtCOVCPSztfaBEC0HOyC0WReV2g18Is8j9NCdb6nW3JAEAg7WS9tVso3gB
3fSlNEGJR6o3XcwqpT9Y3jRVc83iigQ=
=213e
-END PGP SIGNATURE-

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Alejandro Colomar]

Hi Bálint,

On 3/10/23 21:34, Bálint Réczey wrote:
[...]

>> I didn't have the time to look into that, but we should really
>> check if we need to add some error checking.  With strlcpy(3),
>> at least we can do it, contrary to strncpy(3), which doesn't
>> really help detecting truncation (except that you can check
>> the last byte _before_ overwriting it with the '\0', which is
>> really cumbersome).
> 
> I did not find setting the last '\0' that cumbersome,

It's not just setting '\0', but also checking truncation.  As I
said, strncpy(3) is not suited for that, but memcpy(3) could be
used.  However, using memcpy(3) for copying strings with truncation
and detecting truncation is:

memcpy(dst, src, sizeof(dst) - 1)
if (strlen(src) >= sizeof(dst))
goto trunc;
dst[sizeof(dst) - 1] = '\0';

There are a few things I don't like:

-  setting '\0' is in a separate line.  Just a minor thing.
-  Two '-1', which are likely to produce off-by-one errors
   at some point (I've already fixed a few of them, IIRC).  At
   least they didn't seem bad, since we had then on the good
   side (we were just wasting one byte).

But the behavior is indeed what we want.  Here's the definition of
stpecpy(), which basically does that (I call strnlen(3) for optimizing):

$ grepc -tfd stpecpy
./lib/stpecpy.h:67:
inline char *
stpecpy(char *dst, char *end, const char *restrict src)
{
booltrunc;
char*p;
size_t  dsize, dlen, slen;

if (dst == end)
return end;
if (dst == NULL)
return NULL;

dsize = end - dst;
slen = strnlen(src, dsize);
trunc = (slen == dsize);
dlen = slen - trunc;

p = mempcpy(dst, src, dlen);
*p = '\0';

return p + trunc;
}


> but I'd be OK
> with any implementation that's correct and uses only glibc symbols
> including strcpy() and memcpy().

Okay, stpecpy() would be enough.

>> But we can't trivially replace readpassphrase(3bsd).  We could try
>> to reimplement it ourselves, but I don't see avoiding libbsd-dev
>> as a strong-enough reason.
> 
> Indeed, readpassphrase() is the most problematic, but looking at its
> implementation in libbsd it could be just copied to shadow. I'm not a
> fan of such copies, but it seems this function has been copied
> extensively already:
> https://codesearch.debian.net/search?q=readpassphrase%28const+char=1

I'm not a fan either; rather the opposite.  I'd vote against doing so.

> 
> readpassphrase.c's ISC license allows that, too, and I think copying
> would not be a ton of work.

Copying it, probably not.  Maintaining it, maybe yes.  I mean, just look
at it:

$ grepc -tfd readpassphrase | wc -l
142


142 lines of a function definition are not something I'd consider easy to
maintain.  Is it a big deal to add another dependency?  I'd say it's a
bigger deal to copy verbatim so many lines of code, and sync them from
time to time from libbsd (or OpenBSD) just to bring in any bugfixes they
apply.  That's exactly the purpose of libbsd, so I think relying on them
should be fine.

Cheers,

Alex
-- 

GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032679: O: stomper -- Python client implementation of the STOMP protocol

[Boyuan Yang]

Package: wnpp
Severity: normal
Control: affects -1 src:stomper

I am orphaning this package ( https://tracker.debian.org/pkg/stomper ) to
reduce the maintenance footprint on packages that I am not familiar of.

The package stomper itself hasn't seen upstream development for several
years. Given its stable codebase and build system, the future maintenance
should be relatively easy. Git packaging repo is located under Debian Python
Team: https://salsa.debian.org/python-team/packages/stomper .

Package description:

The client is attempting to be transport layer neutral. This module provides
functions to create and parse STOMP messages in a programmatic fashion. The
messages can be easily generated and parsed, however its up to the user to
do the sending and receiving.
 .
 The Streaming Text Oriented Messaging Protocol is a text-based protocol
 vaguely similar to HTTP, intended for message oriented middleware. Its
 protocol specification can be found at
 http://stomp.github.io/


Best Regards,
Boyuan Yang


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

Bug#1032678: O: libwebcam -- Webcam Library

[Boyuan Yang]

Package: wnpp
Severity: normal
Control: affects -1 src:libwebcam

I am orphaning this package ( https://tracker.debian.org/pkg/libwebcam ) to
reduce the maintenance footprint on packages that I am not familiar of.

The package libwebcam itself hasn't seen upstream development for nearly a
decade. Given its stable codebase and build system, the future maintenance
should be relatively easy. Git packaging repo is located under regular
salsa.debian.org/debian/libwebcam namespace.

Package description:

 The Webcam Library libwebcam is designed to simplify
 the development of webcam applications, primarily on Linux but
 with an option to be ported to other platforms, in particular
 Solaris. It realizes part of what the unwritten Video4Linux user
 space library was always supposed to be: an easy to use library
 that shields its users from many of the difficulties and problems
 of using the V4L2 API directly.

Best Regards,
Boyuan Yang


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

Bug#1031696: Use of symbolic links in non-free ISO images breaks file system transposition support

[James Addison]

Package: cdimage.debian.org
Followup-For: Bug #1031696
X-Debbugs-Cc: p...@akeo.ie

My best guess at the moment is that the relevant section of the CD image
preparation scripts is:

https://salsa.debian.org/images-team/debian-cd/-/blob/5aebb6794a3b8b2393663fb643e35eb8e510c9a4/tools/make_disc_trees.pl#L1242-1245

Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Samuel Henrique]

Hello Daniel

> > I couldn't find anything in the release notes which look like a
> > breaking change[0]
>
> Lots of people and CI systems run all the tests flawlessly all the time, so
> there is reason to suspect that there is something slightly unusual in your
> test setup that causes these problems. Meaning that I suspect this is not a
> curl problem, this is a curl test problem.
>
> Are these problems different or the same as the ones already filed at
> https://github.com/curl/curl/issues/10682 ?

I think it's a different issue, we have good evidence that those
failures are triggered by an IPv6-only host and I acknowledge your
solution to document that tests require IPv4 support for now.

Salvatore can double check but the build logs indicate that the host
used to build lnav had an IPv4 address.

I also don't think lnav is running any of the curl's tests, but rather
making use of the curl library to run their tests, which leads me to
believe that whatever issue it is, it has to be something very
specific and uncommon (and not related to curl's tests), otherwise
there would be more reports.

By the way I should have replied on that issue just in case: but feel
free to close it if you'd like to track IPv6-only support somewhere
else, or to rename it if you'd like to use it to track support for
that. Me and sergiodj are thinking about giving it a try at solving
that but we're not sure when (in the packaging, for now, we are
ignoring those test results).

Me and sergiodj are also currently investigating a test issue related
to ppc64el, we have got some good insights already, but would like to
fully understand what's going on and have a patch ready before
reporting. Also that issue only affects curl's own tests so it can't
be related to this.

Cheers,

-- 
Samuel Henrique 

Bug#1018023: Update on this bug?

[Jose Antonio Jimenez Madrid]

Dear Matthew,

I have just uploaded to mentors a new version of the package fixing this
bug.
I will made other improvements after Bookworm is released as we are very
close to the full freeze.
The new package can be found here:

https://mentors.debian.net/package/eterm/

Thank you for your interest in Eterm,

Jose

Matthew Vernon wrote:
> Hi,
>
> On 14/02/2023 18:36, Jose Antonio Jimenez Madrid wrote:
>
>> I will test this patch and let you to know whether the bug is fixed.
>
> Any joy? We're approaching the time that eterm is going to be
> autoremoved from bookworm...
>
> Thanks,
>
> Matthew

Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Daniel Stenberg]

On Fri, 10 Mar 2023, Samuel Henrique wrote:


I couldn't find anything in the release notes which look like a
breaking change[0]


Lots of people and CI systems run all the tests flawlessly all the time, so 
there is reason to suspect that there is something slightly unusual in your 
test setup that causes these problems. Meaning that I suspect this is not a 
curl problem, this is a curl test problem.


Are these problems different or the same as the ones already filed at 
https://github.com/curl/curl/issues/10682 ?


It would help if you could just get into the system and run the problematic 
tests maybe one by one with verbose mode enabled and I'm sure we could work it 
out.


The next curl release is just ten days out and it would be cool to get this 
sorted before then.


--

 / daniel.haxx.se

Bug#1032677: libamdhip64-5: Missing dependency on libamd-comgr2

[Christian Kastner]

Package: libamdhip64-5
Version: 5.2.3-5
Severity: serious

When working on rocrand, I noticed that the rocrand libraries did not
work without libamd-comgr2 installed.

Cordell Bloor pointed out that libamd-comgr2 is essential to any library
that contains GPU kernels, and the calls are likely to be made through
libhipamd64-5.

libamd-comgr2 is dynamically loaded, which is why dh_shlibdeps did not
discover it.

Bug#1032676: zfs-dkms: Installation fails on a Raspberry Pi 3 Model B+ (Raspberry Pi OS, 64-bit kernel activated)

[Wolfgang Liessmann]

Package: zfs-dkms
Version: 2.1.5-1~bpo11~rpt1
Severity: important
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?

Trying to install ZFS with "sudo apt -y install zfsutils-linux".


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

I also tried the following commands:

# https://wiki.debian.org/ZFS#Installation (March 10, 2023)

codename=$(lsb_release -cs);echo "deb http://deb.debian.org/debian 
$codename-backports main contrib non-free"|sudo tee -a /etc/apt/sources.list && 
sudo apt update

# Get keys for http://deb.debian.org/debian bullseye-backports InRelease 
(otherwise an error will occur)

gpg --keyserver hkps://keyserver.ubuntu.com --recv-key 648ACFD622F3D138
gpg --export --armor 648ACFD622F3D138 | sudo apt-key add -

gpg --keyserver hkps://keyserver.ubuntu.com --recv-key 0E98404D386FA1D9
gpg --export --armor 0E98404D386FA1D9 | sudo apt-key add -

sudo apt update
#sudo apt install linux-headers-amd64
sudo apt install -t bullseye-backports zfsutils-linux


   * What was the outcome of this action?

An error message claiming that loadable module support is not included, 
although the kernel supports it:

zfs-dkms (2.1.9-1~bpo11+1) wird eingerichtet ...
Loading new zfs-2.1.9 DKMS files...
It is likely that 6.1.14-v8+ belongs to a chroot's host
Building for 5.15.84+, 5.15.84-v7+, 5.15.84-v7l+, 5.15.84-v8+, 
5.15.92-v8-MY_CUSTOM_KERNEL+, 6.1.14+, 6.1.14-v7+, 6.1.14-v7l+ and 6.1.14-v8+
Building initial module for 5.15.84+
configure: error: 
*** This kernel does not include the required loadable module
*** support!
***
*** To build OpenZFS as a loadable Linux kernel module
*** enable loadable module support by setting
*** `CONFIG_MODULES=y` in the kernel configuration and run
*** `make modules_prepare` in the Linux source tree.
***
*** If you don't intend to enable loadable kernel module
*** support, please compile OpenZFS as a Linux kernel built-in.
***
*** Prepare the Linux source tree by running `make prepare`,
*** use the OpenZFS `--enable-linux-builtin` configure option,
*** copy the OpenZFS sources into the Linux source tree using
*** `./copy-builtin `,
*** set `CONFIG_ZFS=y` in the kernel configuration and compile
*** kernel as usual.

Error! Bad return status for module build on kernel: 5.15.84+ (aarch64)


   * What outcome did you expect instead?

Successful installation of the package in order to use the ZFS filesystem.


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


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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.77
pn  dkms   
ii  file   1:5.39-3
ii  libc6-dev [libc-dev]   2.31-13+rpt2+rpi1+deb11u5
ii  libpython3-stdlib  3.9.2-3
ii  lsb-release11.1.0+rpi1
ii  perl   5.32.1-4+deb11u2
ii  python3-distutils  3.9.2-1

Versions of packages zfs-dkms recommends:
ii  linux-libc-dev  1:1.20230306-1
pn  zfs-zed 
pn  zfsutils-linux  

Versions of packages zfs-dkms suggests:
pn  debhelper  

Bug#1032539: lnav: FTBFS in testing: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2

[Samuel Henrique]

Hello Salvatore,

> -Setting up libcurl3-gnutls:amd64 (7.87.0-2) ...
> -Setting up libcurl4-gnutls-dev:amd64 (7.87.0-2) ...
> +Setting up libcurl3-gnutls:amd64 (7.88.1-1) ...
> +Setting up libcurl4-gnutls-dev:amd64 (7.88.1-1) ...
>
> In fact if I downgrade the packages to 7.87.0-2 the test suite
> succeeds again, would you be able to confirm? 7.88.1-6 as well still
> triggers the test failures.
>
> curl maintainers, is there potential for a regression betweeen 7.87.0
> and 7.88.1 or a incompatible change between the two which can explain
> that?

I couldn't find anything in the release notes which look like a
breaking change[0], I've also looked at the release notes for the next
release[1] and the problem is that there are a lot of bugfixes (as
usual) but it's hard to understand if any of those are for regressions
that could be affecting lnav without a better error message.

If you manage to get more details about the error (ideally some error
being thrown by curl or which call is returning an unexpected output),
we might be able to scope this down.

[0] https://curl.se/changes.html
[1] 
https://github.com/curl/curl/blob/c4a89cb153b782bf7be7739e3ca0bafe5a9a14c3/RELEASE-NOTES

Regards,


-- 
Samuel Henrique 

Bug#1032423: lldb-15: Bug "No module named lldb.embedded_interpreter" reappeared again in lldb-15

[Askar Safin]

I just tested this bug using packages from https://apt.llvm.org/ . I see
that the bug reproduces with lldb-15, but doesn't reproduce with
lldb-16. So let's just wait when lldb 16 enters debian, and the bug
will be hopefully fixed

-- 
Askar Safin

Bug#1032614: ddcutil: pre-approval request ddcutil-1.4.2-1 fixes bug #1031259

[Paul Gevers]

tags 1032614 moreinfo
user release.debian.org
usertag 1032614 unblock
affects 1032614 src:ddcutil
thanks

Hi Sanford,

On Fri, 10 Mar 2023 01:04:18 -0500 Sanford Rockowitz 
 wrote:

Bug report #1031259 vs ddcutil 1.4.1-1 suggests installing files in
/usr/lib/modules-load.d to ensure that driver i2c-dev is loaded at system
startup, avoiding the possible need for user configuration after package
installation.  The change was made in the upstream source, and ddcutil 1.4.2-1
was uploaded to mentors on 2023-02-22.

The package sponsor, Andrey Rakhmatullin, has suggested that a pre-approval
request be submitted at this point before uploading from mentors to sid.

The change consists of 2 new files installed into /usr/lib/modules-load.d, an
updated Changelog.md file, along with modified DEBIAN/changelog,
DEBIAN/ddcutil.install, DEBIAN/libddcutil4.install, and updates to relevant
Autotools files.


If you would have used reportbug against the release.debian.org package, 
these suggestions would have been in the template below (and the user 
tag would have been set correctly). Can you please fill in the parts you 
haven't covered yet?


I'm not sure I like the proposed change in behavior at this stage of the 
release, particularly because there's no other package shipping files in 
/usr/lib/modules-load.d (according to a quick search). Can you comment 
on that?


Paul

(Please provide enough (but not too much) information to help
the release team to judge the request efficiently. E.g. by
filling in the sections below.)

[ Reason ]
(Explain what the reason for the unblock request is.)

[ Impact ]
(What is the impact for the user if the unblock isn't granted?)

[ Tests ]
(What automated or manual tests cover the affected code?)

[ Risks ]
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)

[ Checklist ]
  [ ] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  [ ] attach debdiff against the package in testing

[ Other info ]
(Anything else the release team should know.)


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032674: /usr/bin/plasmashell: when killing a window via the grouped task bar, the task bar disappears

[Aurélien COUDERC]

control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=464186



Le 10 mars 2023 21:45:57 GMT+01:00, Paul Gevers  a écrit :
>Package: plasma-workspace
>Version: 4:5.27.0-1
>Severity: normal
>File: /usr/bin/plasmashell
>
>Dear maintainers,

Dear Paul,

>Thank you for maintaining KDE in Debian, it must be a hell of a job.

Thank you for coordinating Debian releases, it must be a hell of a job. 

> I
>want to share the following annoyance which is probably due to a crash
>and auto restart (so an annoyance, but probably it really should be
>fixed). When I have multiple windows of the same program (qgit in my
>case) I have their entries grouped in the task bar. If I hover over
>their entry in the task bar, multiple minified windows appear with a
>close button. When I press the close button of the minified window I
>want to close, the task bar dissapears for several seconds. When the
>bar returns I can see that `plasmashell` got started in the same
>minute as the disappearance.

This is tracked upstream as bug 464186 (now linked).

The fix is in KDE Frameworks 5.104 which is expected to be released tomorrow 
(March 11.).

I've not seen the release note yet but KDE Frameworks is a tightly coupled set 
of 83 source packages, and I'd prefer avoiding having to backport individual 
fixes as much as possible.

If I could trick the Release Team into accepting 5.104 into bookworm as a 
whole, it would fix this issue and probably several others in a safe way. 
Frameworks 5.x is now in maintenance mode and upstream is supposed to include 
only bugfixes there.

This particular fix is a oneliner so not an issue to backport in itself, but it 
would mean I'm going down the long hard path of patching on top of the 83 
frameworks packages version 5.103, hoping not to (cross-)break more things. So 
patching is definitely not my preferred option.

Let's see what the complete Frameworks 5.104 release note brings us and I'll 
file a proper unblock pre-approval bug to discuss this.


Happy hacking,
--
Aurélien

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

[Brendan O'Dea]

tags 1032651 unreproducible
thanks

On Fri, Mar 10, 2023 at 12:24:26PM +0100, Helmut Grohne wrote:
>Source: vile
>Version: 9.8y-2
>
>vile fails to cross build from source, because the cross-compilation
>specific test contains a syntax error. This will become obvious once
>looking at the attached patch. Thus it fails to define GETPRGP_VOID and
>that produces a compilation error later.

This was fixed in 9.8y-2 (closing #1029956).

I can't reproduce with the source packages:

  % apt-get source vile
  [...]
  Get:1 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (dsc) 
[2,034 B]
  Get:2 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (tar) 
[1,735 kB]
  Get:3 http://mirror.aarnet.edu.au/debian unstable/main vile 9.8y-2 (diff) 
[10.3 kB]
  [...]
  % cd vile-9.8y 
  % fgrep -c \$ac_includes_default aclocal.m4 
  15
  % fgrep -c \#ac_includes_default aclocal.m4 
  0  

See also:

  
https://salsa.debian.org/debian/vile/-/commit/f57788a3b30cfb3d860bd31a01ce57fc43b9c0e6

Did you pull the package from git?  I just noticed that I'd neglected to
push that version, and have just done so now.

--bod

Bug#1011549: openrocket needs newer jogl

[Pierre Gruet]

Hi tony,

On Sun, 12 Feb 2023 10:15:35 -0800 tony mancill  wrote:
>
> Okay, first the good news. There are upstream tags for 2.4.0. I have
> started working on adapting the sequence of debian/patches against the
> new release.
>
> But in addition to not yet being done with that, it didn't seem prudent
> to try to push this into bookwork at the last minute, and that wouldn't
> have given the reverse dependencies any time to react anyway. So I am
> going to work towards an upload to experimental soon, and then we can
> aim for getting this into unstable/testing after the freeze.

I fully understand your position. However I recently looked at scilab, a 
rdep of jogl, and saw it is severely broken -- although a key package, 
so it will be shipped in Bookworm anyway. Scilab cannot be run in GUI 
mode, only in command-line mode with plots not working (after some 
tweaking I am working on).


Locally I tried to update jogl to version 2.4.0 (I had not seen you were 
working on it, sorry), and to do so I also had to update its dependency 
gluegen2 to version 2.4.0 (possibly you have already seen it), and then 
the command-line mode would allow one to make plots.


Given the Hard freeze begins in two days, I will only touch scilab and 
not jogl nor gluegen2 right now.


It you want, I can upload my changes to gluegen2 and jogl2 to 
experimental in the upcoming days. But if you prefer doing it yourself, 
please tell me and do so when you are ready :)


Warm regards,

--
Pierre


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032675: python3-numpy: conflict with python-numpy of /usr/bin/f2py

[Nicola]

Package: python3-numpy
Version: 1:1.23.5-2
Severity: important

Dear Maintainer,

on update:

Estrazione di python3-numpy (1:1.24.2-1) su (1:1.23.5-2)...
dpkg: errore nell'elaborare l'archivio
/var/cache/apt/archives/python3-numpy_1%3a1.24.2-1_amd64.deb (--unpack):
 tentata sovrascrittura di "/usr/bin/f2py" presente anche nel pacchetto python-
numpy 1:1.16.5-5
dpkg-deb: errore: il sottoprocesso paste è stato terminato dal segnale (Pipe
interrotta)
Si sono verificati degli errori nell'elaborazione:
 /var/cache/apt/archives/python3-numpy_1%3a1.24.2-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (950, 'testing'), (500, 'testing-security'), (400, 'unstable'), 
(300, 'experimental'), (10, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 python3-numpy depends on:
ii  libatlas3-base [liblapack.so.3]  3.10.3-13
ii  libblas3 [libblas.so.3]  3.11.0-2
ii  libc62.36-8
ii  liblapack3 [liblapack.so.3]  3.11.0-2
ii  python3  3.11.2-1
ii  python3-pkg-resources66.1.1-1
ii  python3.10   3.10.10-2
ii  python3.11   3.11.2-4

python3-numpy recommends no packages.

Versions of packages python3-numpy suggests:
ii  gcc   4:12.2.0-3
pn  gfortran  
pn  python-numpy-doc  
pn  python3-dev   
ii  python3-pytest7.2.1-2

-- no debconf information

Bug#1032674: /usr/bin/plasmashell: when killing a window via the grouped task bar, the task bar disappears

[Paul Gevers]

Package: plasma-workspace
Version: 4:5.27.0-1
Severity: normal
File: /usr/bin/plasmashell

Dear maintainers,

Thank you for maintaining KDE in Debian, it must be a hell of a job. I
want to share the following annoyance which is probably due to a crash
and auto restart (so an annoyance, but probably it really should be
fixed). When I have multiple windows of the same program (qgit in my
case) I have their entries grouped in the task bar. If I hover over
their entry in the task bar, multiple minified windows appear with a
close button. When I press the close button of the minified window I
want to close, the task bar dissapears for several seconds. When the
bar returns I can see that `plasmashell` got started in the same
minute as the disappearance.

I traced it a bit with the one-liner below. `plasmashell` actually
seems to stay running until the task bar reappears, at which moment
the start time and ID get bumped. So maybe the problem lies elsewhere,
please tell me if you need more from me trace back the culprit.

Paul

paul@mulciber ~ $ while true ; do ps aux | grep /usr/bin/plasmashell | grep -v 
grep ; echo . ; sleep 1 ; done
paul  220257  1.4  8.3 3211068 309192 ?  Rsl  20:47   0:10 
/usr/bin/plasmashell --no-respawn
.
paul  220257  1.4  8.6 3211068 319060 ?  Ssl  20:47   0:10 
/usr/bin/plasmashell --no-respawn
.
paul  220257  1.4  8.2 3211068 305960 ?  Ssl  20:47   0:10 
/usr/bin/plasmashell --no-respawn
.
paul  220257  1.4  7.5 3211068 279624 ?  Ssl  20:47   0:10 
/usr/bin/plasmashell --no-respawn
.
paul  220257  1.4  7.4 3211068 275072 ?  Ssl  20:47   0:10 
/usr/bin/plasmashell --no-respawn
.
paul  220858 54.0  1.7 378372 64852 ?Rsl  20:59   0:00 
/usr/bin/plasmashell --no-respawn
.
paul  220858 42.2  3.5 1234588 130732 ?  Dsl  20:59   0:00 
/usr/bin/plasmashell --no-respawn
.
paul  220858 43.6  4.6 1505996 173336 ?  Rsl  20:59   0:01 
/usr/bin/plasmashell --no-respawn
.
paul  220858 48.8  5.3 2043572 198924 ?  Rsl  20:59   0:01 
/usr/bin/plasmashell --no-respawn
.
paul  220858 43.4  5.7 2060256 214048 ?  Ssl  20:59   0:01 
/usr/bin/plasmashell --no-respawn


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

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]1.14.6-1
ii  dbus-x11 [dbus-session-bus] 1.14.6-1
ii  drkonqi 5.26.90-1
ii  frameworkintegration5.103.0-1
ii  gdb-minimal [gdb]   13.1-2
ii  init-system-helpers 1.65.2
ii  iso-codes   4.13.0-1
ii  kactivitymanagerd   5.26.90-1
ii  kded5   5.103.0-1
ii  kinit   5.103.0-1
ii  kio 5.103.0-1
ii  kpackagetool5   5.103.0-1
ii  kwin-common 4:5.26.90-1
ii  libappstreamqt2 0.16.1-1
ii  libc6   2.36-8
ii  libcolorcorrect54:5.27.0-1
ii  libcrypt1   1:4.4.33-2
ii  libfontconfig1  2.14.1-4
ii  libfreetype62.12.1+dfsg-4
ii  libgcc-s1   12.2.0-14
ii  libgps283.22-4.1+b1
ii  libice6 2:1.0.10-1
ii  libicu7272.1-3
ii  libkf5activities5   5.103.0-1
ii  libkf5activitiesstats1  5.103.0-1
ii  libkf5archive5  5.103.0-1
ii  libkf5authcore5 5.103.0-1
ii  libkf5baloo55.103.0-2
ii  libkf5bookmarks55.103.0-1
ii  libkf5calendarevents5   5.103.0-1
ii  libkf5completion5   5.103.0-1
ii  libkf5config-bin5.103.0-1
ii  libkf5configcore5   5.103.0-1
ii  libkf5configgui55.103.0-1
ii  libkf5configwidgets55.103.0-1
ii  libkf5coreaddons5   5.103.0-1
ii  

Bug#1032673: lintian: inconsistent-appstream-metadata-license does not correctly match GFDL licenses

[Soren Stoutner]

Package: lintian
Version: 2.116.3
Severity: wishlist

Lintian currently produces warnings like the following:

inconsistent-appstream-metadata-license appdata.xml (gfdl-1.3 != gfdl-niv-1.3+) 
[debian/copyright]


AppStream metadata defines a specific short list of acceptable licenses as 
described at:

https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-metadata_license

One of the available licenses uses the following syntax:

GFDL-1.3

AppStream's documentation says that "The license codes correspond to the 
identifiers found at the SPDX OpenSource License Registry."

However, SPDX does not use the simplified GFDL-1.3 syntax:

https://spdx.org/licenses/

Rather, they describe the licence using the following syntax, which describe 
six subcategories of GFDL usage:

GFDL-1.3-invariants-only
GFDL-1.3-invariants-or-later
GFDL-1.3-no-invariants-only
GFDL-1.3-no-invariants-or-later
GFDL-1.3-only
GFDL-1.3-or-later


Debian similarly uses specific syntax to describe subcategories of the GFDL:

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

"For licenses that have multiple versions in use, the short name is formed from 
the general short name of the license family,
followed by a dash and the version number. If the version number is omitted, 
the lowest version number is implied.
When the license grant permits using the terms of any later version of that 
license, add a plus sign to the end of the short name.
For example, the short name GPL refers to the GPL version 1 and is equivalent 
to GPL-1, although the latter is clearer and therefore preferred.
If the package may be distributed under the GPL version 1 or any later version, 
use a short name of GPL-1+."

"GFDL   GNU Free Documentation License 1.0, 1.1, 1.2, or 1.3. Use GFDL-NIV 
instead if there are no Front-Cover or Back-Cover Texts or Invariant Sections."
"GFDL-NIV   GNU Free Documentation License, with no Front-Cover or Back-Cover 
Texts or Invariant Sections. Use the same version numbers as GFDL."


Because the AppStream specification does not allow syntax that is any more 
precise than GFDL-1.3,
Lintian should consider this to match against any of the following lincenses in 
debain/copyright:

GFDL-1.3
GFDL-1.3+
GFDL-NIV-1.3
GFDL-NIV-1.3+

Similar matching should be applied for the AppStream's GFDL-1.1 and GDFL-1.2 
licenses.

Bug#1032393: [Pkg-shadow-devel] Bug#1032393: [PATCH v2 2/2] debian/control: Add libbsd-dev and pkg-config

[Bálint Réczey]

Hi Alejandro,

Alejandro Colomar  ezt írta (időpont: 2023.
márc. 8., Sze, 13:55):
>
> Hi Bálint,
>
> [I reordered some quotes for my reply]
> [CC Paul, since he's been mentioned, and I'm curious to know
> if he has any comments]
>
> On 3/8/23 11:59, Bálint Réczey wrote:
> > Hi Alejandro,
> >
> > Alejandro Colomar  ezt írta (időpont: 2023.
> > márc. 5., V, 20:44):
> >>
> >> Package: passwd
> >> Source: shadow
> >> Tags: patch
> >> X-Debbugs-CC: Bálint Réczey 
> >> X-Debbugs-CC: Iker Pedrosa 
> >> X-Debbugs-CC: Serge Hallyn 
> >>
> >> These dependencies were added upstream recently.
> >>
> >> Signed-off-by: Alejandro Colomar 
> >> Cc: Iker Pedrosa 
> >> Cc: Serge Hallyn 
> >> ---
> >>  debian/control | 2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/debian/control b/debian/control
> >> index 3cc66f8d..75015c35 100644
> >> --- a/debian/control
> >> +++ b/debian/control
> >> @@ -11,11 +11,13 @@ Build-Depends: bison,
> >> gettext,
> >> itstool,
> >> libaudit-dev [linux-any],
> >> +   libbsd-dev,
> >
> > I checked out recent changes in shadow's master and I'm very happy
> > about many of the fixes for memory allocation problems,
>
> Thanks! :-)
>
> > but wearing my maintainer hat I believe linking to a new library for a
> > few functions which are not very different from their glibc
> > counterpart is not worth it.
>
> We added it with strlcpy(3) in mind, but I agree with you that
> it's not a critical reason, and we could live without it; in fact
> I introduced a similar (and IMO superior) function, stpecpy(),
> which could replace strlcpy(3) in all 6 calls.
>
> But we didn't really add it for it; we already had the libbsd-dev
> dependency before adding strlcpy(3).  libbsd-dev was added for
> readpassphrase(3bsd), which has nothing similar in glibc, and I don't
> want to be rewriting it in terms of glibc stuff, since it's not
> trivial.
>
> It was added in this patch set:
>
> * 2a5b8810 - Mon, 21 Nov 2022 14:00:13 +0100 (4 months ago)
> |   agetpass: Hook into build-system - Guillem Jover
> * ab91ec10 - Wed, 28 Sep 2022 23:09:19 +0200 (5 months ago)
> |   Hide [[gnu::malloc(deallocator)]] in a macro - Alejandro Colomar
> * 554f86ba - Tue, 27 Sep 2022 21:21:35 +0200 (5 months ago)
> |   Replace the deprecated getpass(3) by our agetpass() - Alejandro 
> Colomar
> * 155c9421 - Mon, 26 Sep 2022 22:22:24 +0200 (5 months ago)
> |   libmisc: agetpass(), erase_pass(): Add functions for getting 
> passwords safely - Alex Colomar
> * 8cce4557 - Wed, 28 Sep 2022 00:03:46 +0200 (5 months ago)
> |   Don't 'else' after a 'noreturn' call - Alex Colomar
> * 99ce21a3 - Tue, 22 Nov 2022 14:35:06 +0100 (4 months ago)
> |   CI: add libbsd and pkg-config dependencies - Iker Pedrosa
>
> >
> > Freezero() also provides little extra benefit over memset() and free()
> > and is used only 4 times in the code.
>
> Use of freezero(3bsd) was added later to erase_pass() for one reason:
> that API pair --agetpass(), erase_pass()-- already strongly depends on a
> libbsd-dev function --readpassphrase(3bsd)--, so depending on two of them
> doesn't add any issues.  Anyway, freezero(3) is easy to implement if we
> had a need.
>
>
>
> > There are reasons for strlcpy() not being provided by glibc [1]:
> >
> > "Reactions among core glibc contributors on the topic of including
> > strlcpy() and strlcat() have been varied over the years. Christoph
> > Hellwig's early patch was rejected in the then-primary maintainer's
> > inimitable style (1 and 2). But reactions from other glibc developers
> > have been more nuanced, indicating, for example, some willingness to
> > accept the functions. Perhaps most insightfully, Paul Eggert notes
> > that even when these functions are provided (as an add-on packaged
> > with the application), projects such as OpenSSH, where security is of
> > paramount concern, still manage to either misuse the functions
> > (silently truncating data) or use them unnecessarily (i.e., the
> > traditional strcpy() and strcat() could equally have been used without
> > harm); such a state of affairs does not constitute a strong argument
> > for including the functions in glibc. "
> >
> > I agree with their position and the 6 cases where strlcpy() is used in
> > shadow's current master could be implemented with strncpy() as safely
> > as with strlcpy().
>
> I would strongly advise against that.  strncpy(3) doesn't produce
> strings.
>
> See the following manual pages:
>
> 
> 
>
> My main concerns with strncpy(3) are:
>
> -  It zeroes the rest of the buffer, which isn't bad per se, but
>then when reading code it's hard to tell if that was necessary
>or if it was just some inessential side effect of calling
>

Bug#1032672: ntcard: disabling "32-bit" disabled too many archs

[Steve Langasek]

Package: ntcard
Version: 1.2.2+dfsg-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch

Dear maintainers,

The latest upload of ntcard disabled 32-bit support by dropping a
compatibility patch.  In the process, you also marked the package as only
building for a specific list of architectures instead of for Architecture:
any.

If the package simply fails to build on those architectures, there's no need
to change the architecture list.  But in any case, your list of 64-bit
architectures is incomplete, both for Debian (s390x) and for Ubuntu (s390x +
riscv64).

I've applied the attached patch in Ubuntu to re-enable builds on these
architectures.  Please consider including in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru ntcard-1.2.2+dfsg/debian/control ntcard-1.2.2+dfsg/debian/control
--- ntcard-1.2.2+dfsg/debian/control2022-12-19 00:17:21.0 -0800
+++ ntcard-1.2.2+dfsg/debian/control2023-03-10 12:22:43.0 -0800
@@ -12,7 +12,7 @@
 Rules-Requires-Root: no
 
 Package: ntcard
-Architecture: amd64 arm64 mips64el ppc64el ppc64
+Architecture: amd64 arm64 mips64el ppc64el ppc64 riscv64 s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Streaming algorithm to estimate cardinality in genomics datasets
  As input it takes file(s) in fasta, fastq, sam, or bam formats

Bug#1032240: akonadi server fails to start since it cannot connect to mysql database

[Patrick Franz]

Hi,

the issue is connected to MariaDB when upgrading after the shutdown was 
not clean, see https://bugs.debian.org/cgi-bin/bugreport.cgi?
bug=1032047#40

We are trying to find a solution for this.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1016694: packages.debian.org uses favicon with white shadow

[Akbarkhon Variskhanov]

Control: tags -1 confirmed
Control: owner -1 !

Hello, Alexander. Nice catch.

It looks whacky indeed. We already have a good icon available at
another resource, so it's just a matter of replacing the bad one.

Thanks for the report.

Bug#1032631: please drop transitional package apt-transport-https from src:apt

[David Kalnischkies]

On Fri, Mar 10, 2023 at 01:33:23PM +, Holger Levsen wrote:
> On Fri, Mar 10, 2023 at 02:25:59PM +0100, Julian Andres Klode wrote:
> > We have no plans to drop this package for the foreseeable future. Doing
> > so breaks various bootstrapping tools and causes severe headaches we
> > don't have the capacity to deal with.
> 
> even if apt provides apt-transports-https?

apt already does, longer than (trying to) dropping a-t-h even.

The whole reason the package was reintroduced quickly after Julian
dropped it was that tools like debootstrap were exploding, and even
if he was expressing hope for the better in the commit message I have
my serious doubts that has changed and as he said we aren't exactly able
to fix the world… hands (more than) full with what we have now already.

If you can come with prove that debootstrap (and probably other tools)
can deal with virtual packages nowadays, we will be happy to oblige –
and I think I know a couple other people who would be happy, too.

Adding Provides: 
https://salsa.debian.org/apt-team/apt/-/commit/c6a428e4d17b408c2701def5daa46ca950948980
Drop a-t-h: 
https://salsa.debian.org/apt-team/apt/-/commit/5e770a07c8fd649340e83725f6d07b94c361e87c
Reintroduce: 
https://salsa.debian.org/apt-team/apt/-/commit/afe3cd6ef1b157a07d05bbf70283e4f175813438


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1024868: rust-kvm-bindings: diff for NMU version 0.5.0-1.1

[Peter Green]

I've prepared an NMU for rust-kvm-bindings (versioned as 0.5.0-1.1) and 
uploaded it to DELAYED/7. Please feel free to tell me if I should cancel it.


It's not my place to tell you to cancel it, but I can tell you that it
it will not clear the path for testing migration.

The new version of rust-kvm-bindings adds a dependency on rust-vmm-sys-util.
rust-vmm-sys-util has a few issues

* It is not in testing and has missed the freeze deadline.
* It FTBFS on armel and mipsel due to the unavailbility of atomicu64
* It fails it's autopkgtests on 32-bit architectures, this looks like
  broken tests to me.
* It fails it's autopkgtests on s390x, some rngs produce different
  results, presumablly due to endian issues. I don't know what
  the contracts for said rngs are and hence whether this is a bug
  in the rngs or in the tests.

Since no applications in Debian depend on this package, I do not
intend to dig deeper into these issues myself.

It would be possible to patch rust-kvm-bindings to disable the
dependency on rust-vmm-sys-util and the optional feture that
depends on it. If there were applications in Debian that used
rust-kvm-bindings and did not use the feature in question I
would do so, but as there are no such applications I don't
intend to bother.

Bug#1032569: src:pywebdav: fails to migrate to testing for too long: autopkgtest regression

[Paul Gevers]

Hi Mathias,

Good that you ask.

On 10-03-2023 11:51, Mathias Behrle wrote:

pywebdav currently suffers from missing adaption to Python 3.11. As you know it
is not appropriate to force the decision of our quite late move to Python 3.11
on upstreams or package maintainers. So what I expect to happen is that
pywebdav won't be part of bookworm (i.e. removed from testing), but stay in
unstable (waiting for upstream maintainers to catch up with migration to Python
3.11). I would have assumed that this is already the case with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029283


No, because that bug only affects the package in unstable. Check: 
https://bugs.debian.org/cgi-bin/version.cgi?found=pywebdav%2F0.10.0-1;package=src%3Apywebdav;absolute=0;collapse=1;info=1



so basically I don't get what this immediately closed bug is meant for.


Well, without me filing this bug, pywebdav would not be (auto)removed 
from bookworm, because there is no RC bug affecting the version in 
bookworm. Because the version in testing passes its autopkgtest (with 
Python 3.11), so neither bunk (I assume) nor me were seeing this as a 
Python 3.11 problem. I file most of my "fails to migrate to testing for 
too long" bugs closing the bug with the version in unstable, because I 
don't want the bug to *block* migration once the underlying problem is 
solved. The underlying problem regularly either has it's own bug report 
already, or may be solvable without changes to the bug I file. To avoid 
busywork for maintainers, I close the bug when I file it. Because 
autoremoval knows to only care about bugs affecting testing.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1026062: kded crashes after turning off screen

[Aurélien COUDERC]

Hi,

Le 10 mars 2023 12:16:46 GMT+01:00, Jordi Bosveld  a écrit :
>Yesterday I upgraded both my workstation and my HTPC to bookworm, and now I 
>see kded crashes too. The aforementioned patch did not fix them, but 
>considering how I manage to trigger this crash, that is expected. Reproducing 
>is super easy for me. All I have to do is turn off the screen (or tv). The 
>same line is reported (repeatedly) as with the PackageKit bug that was 
>hopefully fixed:
>
>Mar 10 11:22:57 relativity kded5[63899]: QDBusAbstractAdaptor: Cannot relay 
>signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: 
>KDEDModule*
>
>Needless to say, this did not happen on bullseye. One system is NVIDIA using 
>DisplayPort, the other is AMD (RADV) through HDMI, both X11. A third system 
>running Wayland does not seem affected.

This bug report was about an apper/packagekit-qt crash.

Your issue is unrelated, please open a second bug report.


Thanks !
--
Aurélien

Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start

[Paride Legovini]

Benedikt Spranger wrote on 10/03/2023:
> On Fri, 10 Mar 2023 15:04:44 +0100
> Paride Legovini  wrote:
> 
>> I am not running sysv systems; The case looks simple enough for me to
>> tempt a fix, but I need validation from an actual sysv user. Even better
>> if you can submit a salsa MR, which will also speed up the process of
>> landing a fix: 
>> https://salsa.debian.org/debian/isc-kea/
> 
> Can do that next week. ATM I am busy to prepare stuff for a trade fair
> starting next week...

Sound good, thanks! Keep in mind that Debian will be in hard freeze.
Given that isc-kea is a non-key package with autopkgtests we'll still be
able to upload a "small, targeted fix" [1] for this issue, but the
sooner the better.

Cheers,

Paride

[1] https://release.debian.org/testing/freeze_policy.html#full

Bug#1032671: linux: Enable USB_XHCI_PCI_RENESAS on arm64

[Cyril Brulebois]

Source: linux
Severity: normal
Tags: patch

Hi,

The µPD720201 and µPD720202 controllers from Renesas are USB 3.0 Host
Controllers making it possible to get several USB 3 lines from a single
PCIe slot.

I'm suggesting enabling the relevant module on arm64 as having that
module enabled is quite useful on devices like Raspberry Pi CM4, but
that might be useful on other architectures. Seeing how arm64 has the
most USB_HCI_* modules enabled, that's why I'm sticking to this
particular architecture in my initial patch.

Please note that these controllers require a firmware to operate; it can
be stored on an EEPROM next to the controller, or loaded directly from
/lib/firmware/renesas_usb_fw.mem

More information about the firmware:
  https://github.com/markusj/upd72020x-load

Repository containing the firmware (UPDATE.mem):
  https://github.com/denisandroid/uPD72020x-Firmware


Thanks for considering!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant

Bug#1031334: intel-microcode: CVE-2022-21216 CVE-2022-33972 CVE-2022-33196 CVE-2022-38090

[Tobias Frost]

Hi,

just a heads-up: I'm planning to fix those CVEs for LTS and ELTS, and fix them
in the order unstable -> bookworm -> bullseye -> buster -> stretch -> jessie.

For unstable, I plan to do an NMU.

Staging area will be my fork on salsa: 
https://salsa.debian.org/tobi/intel-microcode

Please shout if you'd like me to handle it differently.

Cheers,
-- 
tobi

On Wed, 15 Feb 2023 08:52:06 +0100 Salvatore Bonaccorso  
wrote:
> Source: intel-microcode
> Version: 3.20221108.1
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: found -1 3.20220510.1~deb11u1
> Control: found -1 3.20220510.1~deb10u1
> 
> Hi,
> 
> The following vulnerabilities were published for intel-microcode.
> 
> CVE-2022-21216[0]:
> - INTEL-SA-00700
> 
> CVE-2022-33972[1]:
> - INTEL-SA-00730
> 
> CVE-2022-33196[2]:
> - INTEL-SA-00738
> 
> CVE-2022-38090[3]:
> - INTEL-SA-00767
> 
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2022-21216
> https://www.cve.org/CVERecord?id=CVE-2022-21216
> 
>https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00700.html
> [1] https://security-tracker.debian.org/tracker/CVE-2022-33972
> https://www.cve.org/CVERecord?id=CVE-2022-33972
> 
>https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00730.html
> [2] https://security-tracker.debian.org/tracker/CVE-2022-33196
> https://www.cve.org/CVERecord?id=CVE-2022-33196
> 
>https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00738.html
> [3] https://security-tracker.debian.org/tracker/CVE-2022-38090
> https://www.cve.org/CVERecord?id=CVE-2022-38090
> 
>https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00767.html
> [4] 
> https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20230214
> 
> Regards,
> Salvatore
> 
> 

Bug#1032670: allegro4.4: CVE-2021-36489

[Moritz Mühlenhoff]

Source: allegro4.4
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for allegro4.4.

CVE-2021-36489[0]:
| Buffer Overflow vulnerability in Allegro through 5.2.6 allows
| attackers to cause a denial of service via crafted PCX/TGA/BMP files
| to allegro_image addon.

https://github.com/liballeg/allegro5/issues/1251
https://github.com/liballeg/allegro5/pull/1253

These fixes landed in Allegro 5.2.8.0:
https://github.com/liballeg/allegro5/commit/3f2dbd494241774d33aaf83910fd05b2a590604a
 (5.2.8.0)
https://github.com/liballeg/allegro5/commit/cca179bc16827f358153060cd10ac73d394e758c
 (5.2.8.0)
https://github.com/liballeg/allegro5/commit/a2c93939f6997a96ecac1865dbb4fa3f66b5e1b7
 (5.2.8.0)
https://github.com/liballeg/allegro5/commit/0294e28e6135292eab4b2916a7d2223b1bb6843e
 (5.2.8.0)

In allegro 4.4, code is in src/[pcx|tga].c instead


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-36489
https://www.cve.org/CVERecord?id=CVE-2021-36489

Please adjust the affected versions in the BTS as needed.

Bug#1032669: wabt: CVE-2023-27115 CVE-2023-27116 CVE-2023-27117 CVE-2023-27119

[Moritz Mühlenhoff]

Source: wabt
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for wabt.

CVE-2023-27115[0]:
| WebAssembly v1.0.29 was discovered to contain a segmentation fault via
| the component wabt::cat_compute_size.

https://github.com/WebAssembly/wabt/issues/1938
https://github.com/WebAssembly/wabt/issues/1992

CVE-2023-27116[1]:
| WebAssembly v1.0.29 discovered to contain an abort in
| CWriter::MangleType.

https://github.com/WebAssembly/wabt/issues/1984
https://github.com/WebAssembly/wabt/pull/2119
https://github.com/WebAssembly/wabt/commit/8a7b7497bdf78f9099f8d5a3a2c9bde87ddd52da

CVE-2023-27117[2]:
| WebAssembly v1.0.29 was discovered to contain a heap overflow via the
| component component wabt::Node::operator.

https://github.com/WebAssembly/wabt/issues/1989

CVE-2023-27119[3]:
| WebAssembly v1.0.29 was discovered to contain a segmentation fault via
| the component wabt::Decompiler::WrapChild.

https://github.com/WebAssembly/wabt/issues/1990

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-27115
https://www.cve.org/CVERecord?id=CVE-2023-27115
[1] https://security-tracker.debian.org/tracker/CVE-2023-27116
https://www.cve.org/CVERecord?id=CVE-2023-27116
[2] https://security-tracker.debian.org/tracker/CVE-2023-27117
https://www.cve.org/CVERecord?id=CVE-2023-27117
[3] https://security-tracker.debian.org/tracker/CVE-2023-27119
https://www.cve.org/CVERecord?id=CVE-2023-27119

Please adjust the affected versions in the BTS as needed.

Bug#1032668: nvidia-cuda-toolkit: CVE-2023-0193 CVE-2023-0196

[Moritz Mühlenhoff]

Source: nvidia-cuda-toolkit
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerabilities were published for nvidia-cuda-toolkit.

CVE-2023-0193[0]:
No description was found (try on a search engine)

CVE-2023-0196[1]:
| NVIDIA CUDA Toolkit SDK contains a bug in cuobjdump, where a local
| user running the tool against an ill-formed binary may cause a null-
| pointer dereference, which may result in a limited denial of service.

https://nvidia.custhelp.com/app/answers/detail/a_id/5446


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-0193
https://www.cve.org/CVERecord?id=CVE-2023-0193
[1] https://security-tracker.debian.org/tracker/CVE-2023-0196
https://www.cve.org/CVERecord?id=CVE-2023-0196

Please adjust the affected versions in the BTS as needed.

Bug#1032667: radare2: CVE-2023-27114

[Moritz Mühlenhoff]

Source: radare2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for radare2.

CVE-2023-27114[0]:
| radare2 v5.8.3 was discovered to contain a segmentation fault via the
| component wasm_dis at p/wasm/wasm.c.

https://github.com/radareorg/radare2/issues/21363
https://github.com/radareorg/radare2/commit/13308c9aad79f9c7a3507ce549fe270103e8ceea


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-27114
https://www.cve.org/CVERecord?id=CVE-2023-27114

Please adjust the affected versions in the BTS as needed.

Bug#1032666: freeimage: CVE-2021-33367

[Moritz Mühlenhoff]

Source: freeimage
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for freeimage.

CVE-2021-33367[0]:
| Buffer Overflow vulnerability in Freeimage v3.18.0 allows attacker to
| cause a denial of service via a crafted JXR file.

https://sourceforge.net/p/freeimage/discussion/36109/thread/1a4db03d58/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33367
https://www.cve.org/CVERecord?id=CVE-2021-33367

Please adjust the affected versions in the BTS as needed.

Bug#1032665: tidy-html5: CVE-2021-33391

[Moritz Mühlenhoff]

Source: tidy-html5
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for tidy-html5.

CVE-2021-33391[0]:
| An issue in HTACG HTML Tidy v5.7.28 allows attacker to execute
| arbitrary code via the -g option of the CleanNode() function in
| gdoc.c.

https://github.com/htacg/tidy-html5/issues/946
https://github.com/htacg/tidy-html5/commit/efa61528aa500a1efbd2768121820742d3bb709b


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-33391
https://www.cve.org/CVERecord?id=CVE-2021-33391

Please adjust the affected versions in the BTS as needed.

Bug#1032664: mootools: CVE-2021-32821

[Moritz Mühlenhoff]

Source: mootools
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for mootools.

CVE-2021-32821[0]:
| MooTools is a collection of JavaScript utilities for JavaScript
| developers. All known versions include a CSS selector parser that is
| vulnerable to Regular Expression Denial of Service (ReDoS). An attack
| requires that an attacker can inject a string into a CSS selector at
| runtime, which is quite common with e.g. jQuery CSS selectors. No
| patches are available for this issue.

https://securitylab.github.com/advisories/GHSL-2020-345-redos-mootools/

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-32821
https://www.cve.org/CVERecord?id=CVE-2021-32821

Please adjust the affected versions in the BTS as needed.

Bug#970021: Provisional packaging for Aoache Arrow available

[Nilesh Patra]

On 20 December 2021 9:17:40 pm IST, Sascha Steinbiss  wrote:
>TLDR: I have prepared a package to cover as much of Arrow as is possible
>with what we have in Debian, dependency-wise. There is still a review of
>d/copyright missing, and some bundled code might need some extra love or
>removal.
>
>If someone wants to work on this and wants to maintain it for longer,
>feel free to let me know and I might help get it finished. :)
>I just feel I won't be able to keep this updated in time on my own given
>how busy upstream seems to be.

It's quite an old mail but
I can give you a hand with it, however I can't maintain this alone.

I'm seeing this as a dependency in increasing number of packages and it'd be 
good to have this in the archive.

Let me know if we can move fwd with this.


>[1] https://salsa.debian.org/science-team/arrow
>[2] https://lists.debian.org/debian-med/2021/08/msg00066.html
>

--
Best,
Nilesh

Bug#1032663: ITP: eludris -- A simple CLI to help you with setting up and managing your Eludris instance

[Oliver Wilkes]

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

* Package name : eludris
Version : 0.3.2
Upstream Author : Oliver Wilkes 
* URL : https://github.com/eludris/eludris/tree/main/cli/
* License : MIT
Programming Lang: Rust
Description : A simple CLI to help you with setting up and managing your 
Eludris instance


Located at https://github.com/eludris/eludris/tree/main/cli, this is a 
package for creating an Eludris instance with ease. It is officially 
supported and maintained by Eludris and reduces the barrier to entry for 
new instance owners.


### Why is this package useful/relevant?

This CLI provides an easy way for users to create their own Eludris 
instance from scratch. There are currently no alternatives as Eludris is 
relatively new and this is an 'official' CLI.


### How do you plan to maintain it?

I am not all too sure how this works as this is my first time packaging 
for Debian. I plan to maintain it solo for now, unless if anyone has any 
better suggestions as to what team to maintain it under.

Bug#1032367: brcm/brcmfmac4356-pcie.bin failed with error -2

[Diederik de Haas]

On Thursday, 9 March 2023 19:17:10 CET Diederik de Haas wrote:
> In https://bugs.debian.org/1032367 we have a user who reported that the
> brcm/brcmfmac4356-pcie.bin firmware file failed to load with a new firmware-
> brcm80211 package, while it succeeded with an old one.
> 
> In
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
> / I found 2 commits that seem relevant:
> - 04f71fe564552c22dc7ece0d2b8afc11b33de392 where various cypress firmware
> and clm_blob files (including 4356) were added to the *cypress* directory.
> - 0f0aefd733f70beae4c0246edbd2c158d5ce974c which removed old brcm firmware
> files that have a newer cypress variant ...  from the *brcm* directory.
> 
> So in essence a bunch of firmware files were moved from 'brcm' dir to
> 'cypress'.
> 
> I don't know how the firmware file loading mechanism works, but could it be
> that it (also) needs to look in the new (cypress) location for those files?

I am now reasonably certain that that is indeed the issue.

I asked the reporter of the issue to create symlinks and that 'fixed' it:

On Friday, 10 March 2023 13:07:22 CET d...@kataplop.net wrote:
> March 10, 2023 10:57 AM, "Diederik de Haas"  wrote:
> > I'm 99% sure this would be a *workaround*, but let's verify anyway:
> > In the /lib/firmware directory, create a symlink from
> > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin
> 
> As expected, it works with the symlink :)

AFAICT in drivers/net/wireless/broadcom/brcm80211/brcmfmac/ there is pcie.c 
and firmware.[c|h] and it uses BRCMF_FW_DEFAULT_PATH (="brcm/") to construct 
the location of the firmware files.

Now that several firmware files are stored in a different directory ('cypress') 
and also have a different file 'prefix' ('cyfmac') the firmware files that are 
stored in/moved to the cypress directory are no longer found.

Cheers,
  Diederik

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

Bug#1032619: the package

[Bálint Réczey]

Control: tags + confirmed upstream
Control: forwarded https://github.com/firebuild/firebuild/issues/312

Hi Russell,

Russell Coker  ezt írta (időpont: 2023. márc.
10., P, 11:02):
>
> The package I was trying to build was "refpolicy", it would be interesting to
> see if you have the same problem when building it.

Yes, I figured that out from the built files, thanks. :-)

The refpolicy package builds fine for me with firebuild in Ubuntu
22.04 and Ubuntu devel LXC containers where seccomp is not enabled.

Firebuild's interception overhead is relatively high building this
package with -j18 due to the many quick commands:

Total time with firebuild (%) in lunar-v0.2.11-16-g0ce0aa8 :
 first run second run
real  134.2151   30.64922
user  133.8906   11.90031
sys   142.2342   37.57094
user+sys  134.7790   14.63378

There is test framework that measures firebuild's performance on
Ubuntu packages or upstream git repositories if you are interested:
https://github.com/firebuild/firebuild-infra

The crash you faced seems to be due to man-recode's seccomp() usage.
Firebuild intercepts commands by interposing libc and syscalls, and
reporting them to the firebuild supervisor process over an Unix domain
socket.
The interception thus makes the intercepted processes call functions
they are absolutely not expected to call and that can cause crashes in
enforced sandboxes.

One workaround is listing "man-recode" like "man" on the
"dont_shortcut" in /etc/firebuild.conf.

Another option is disabling man's seccomp sandbox, like:
 firebuild env MAN_DISABLE_SECCOMP=1 dpkg-buildpackage -j18

Cheers,
Balint

Bug#1032367: firmware-brcm80211: Missing brcmfmac4356-pcie.bin

[Diederik de Haas]

Control: reassign -1 src:linux 6.1.15-1
Control: tag -1 -moreinfo +upstream
Control: forwarded -1 
https://lore.kernel.org/linux-wireless/2716728.5R3jveeIG6@prancing-pony/

On Friday, 10 March 2023 13:07:22 CET d...@kataplop.net wrote:
> March 10, 2023 10:57 AM, "Diederik de Haas"  wrote:
> > I'm 99% sure this would be a *workaround*, but let's verify anyway:
> > In the /lib/firmware directory, create a symlink from
> > brcm/brcmfmac4356-pcie.bin to cypress/cyfmac4356-pcie.bin
> 
> As expected, it works with the symlink :)

Thanks, then it's a kernel issue so I'm reassigning accordingly.

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

Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services

[Daniel Baumann]

On 3/10/23 16:33, Benjamin Drung wrote:
> My preference is that I will do the initial packaging
> and you become the maintainer and I only an uploader for it.

sounds like win-win, thanks :)

> Where should I put the packaging git repository? To
> https://salsa.debian.org/debian/nvme-stas?

sounds good, can always be changed anytime later if needed.

Regards,
Daniel

Bug#1022126: New mainline kernel is out fixes for example 1022126 bug

[Salvatore Bonaccorso]

Hello Marc-Robin,

On Thu, Mar 09, 2023 at 09:33:19PM +0100, Marc-Robin Wendt wrote:
> Hello Salvatore,
> 
> I followed instructions and it made me a linux-image-5.10.0-21-amd64-
> unsigned_5.10.162-1a~test_amd64.deb, which, after installed, boots
> nicely and seems to work without errors at mpt3sas anymore.
> All XEN-functionality seems to work in our environment.

Thanks a lot, that was helpful. Good news, Greg has now picked the
series:

https://lore.kernel.org/stable/zasovkmt7n9fd...@kroah.com/

> Anyhow I had some errors:
> 
> qla2xxx :61:00.1: swiotlb buffer is full (sz: 65536 bytes), total
> 32768 (slots), used 28799 (slots)
> 
> But I'm not sure, if this is releated and it doesn't affect functions.
> 
> Do you need further informations about the testing process?

I assume this has to be tackled separately. You can confim it was not
seen before in earlier kernels?

Thanks,

Regards,
Salvatore

Bug#1032662: elpa-debian-el: deb-view fails on zstd compressed debs

[Sven Joachim]

Package: elpa-debian-el
Version: 37.10
Severity: normal

Visiting zstd compressed .deb files in deb-view mode-fails with a tar
error, here is a backtrace after toggling debug-on-error.

,
| Debugger entered--Lisp error: (error "Malformed Tar header")
|   signal(error ("Malformed Tar header"))
|   tar-mode()
|   debview-mode()
|   deb-view-process("/tmp/libtinfo6_6.3+20220423-2_amd64.deb")
|   deb-view-mode()
|   set-auto-mode-0(deb-view-mode nil)
`

Here /tmp/libtinfo6_6.3+20220423-2_amd64.deb is the package from Ubuntu
22.10, see https://packages.ubuntu.com/kinetic/amd64/libtinfo6/download.

While the control.tar.zst apparently can be inspected, there is no way
to get to the files in data.tar.zst.  I had to kill the buffer
libtinfo6_6.3+20220423-2_amd64.deb-DATA, confirming that I wanted to get
rid of that buffer despite it being modified.


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (101, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages elpa-debian-el depends on:
ii  bzip2   1.0.8-5+b1
ii  dh-elpa-helper  2.0.16
ii  dpkg1.21.21
ii  emacsen-common  3.0.5
ii  reportbug   11.6.0
ii  xz-utils5.4.1-0.2

Versions of packages elpa-debian-el recommends:
ii  emacs  1:28.2+1-12
ii  emacs-gtk [emacs]  1:28.2+1-12
ii  wget   1.21.3-1+b2

elpa-debian-el suggests no packages.

-- no debconf information

Bug#1032589: sq-wot: Please update

[Alexander Kjäll]

Hi

I have started to look at updating the group of sequoia packages as
part of packaging https://crates.io/crates/sequoia-chameleon-gnupg

But since we are in a freeze right now I haven't spent very much time
on it, am very happy to collaborate on the effort.

//Alex

Bug#1032661: ITP: golang-github-radovskyb-watcher -- a Go package for watching for files or directory changes without using filesystem events.

[Mark E. Fuller]

Package: wnpp
Severity: wishlist
Owner: Mark E. Fuller 

* Package name: golang-github-radovskyb-watcher
  Version : 1.0.7-1
  Upstream Author : Benjamin Radovsky
* URL : https://github.com/radovskyb/watcher
* License : BSD-3-clause
  Programming Lang: Go
  Description : watcher is a Go package for watching for files or
directory changes without using filesystem events.

 watcher is a Go package for watching for files or directory changes
 (recursively or non recursively) without using filesystem events, which
 allows it to work cross platform consistently.
 .
 watcher watches for changes and notifies over channels either anytime an
 event or an error has occurred.

 Reason for packaging: Needed by go-task

Bug#1032660: ITP: golang-github-sajari-fuzzy -- Spell checking and fuzzy search suggestion written in Go

[Mark E. Fuller]

Package: wnpp
Severity: wishlist
Owner: Mark E. Fuller 

* Package name: golang-github-sajari-fuzzy
  Version : 1.0.0-1
  Upstream Author : Search.io
* URL : https://github.com/sajari/fuzzy
* License : MIT
  Programming Lang: Go
  Description : Spell checking and fuzzy search suggestion written 
in Go


 Fuzzy is a very fast spell checker and query suggester written in
 Golang.

 Reason for packaging: Needed by go-task


OpenPGP_0xD599E76CFFCABF60.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032659: ITP: golang-github-go-task-slim-sprig -- Useful template functions for Go templates.

[Mark E. Fuller]

Package: wnpp
Severity: wishlist
Owner: Mark E. Fuller 

* Package name: golang-github-go-task-slim-sprig
  Version : 2.20.0-1
  Upstream Author : Andrey Nering
* URL : https://github.com/go-task/slim-sprig
* License : MIT
  Programming Lang: Go
  Description : Useful template functions for Go templates.

 Slim-Sprig: Template functions for Go templates GoDoc
 (https://godoc.org/github.com/go-task/slim-sprig) Go Report Card
 (https://goreportcard.com/report/github.com/go-task/slim-sprig)
 .
 Slim-Sprig is a fork of Sprig (https://github.com/Masterminds/sprig), but
 with all functions that depend on external (non standard library) or
 crypto packages removed. The reason for this is to make this library
 more lightweight. Most of these functions (specially crypto ones) are
 not needed on most apps, but costs a lot in terms of binary size and
 compilation time.

 Reason for packaging: Needed by go-task

Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services

[Benjamin Drung]

On Fri, 2023-03-10 at 15:43 +0100, Daniel Baumann wrote:
> Hi Benjamin
> 
> On 3/10/23 14:40, Benjamin Drung wrote:
> > I would love to team maintain that package.
> 
> I've had this on my todo list (but didn't fill a ITP for it), so I'm
> happy to (co)maintain it or take over if you just want do to the inital
> but not longterm work.

That sounds great. My preference is that I will do the initial packaging
and you become the maintainer and I only an uploader for it. I am not
sure how much time I will have for longterm work in the future.

Where should I put the packaging git repository? To
https://salsa.debian.org/debian/nvme-stas?

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1032658: ITP: go-task -- A task runner / simpler Make alternative written in Go

[Mark E. Fuller]

Package: wnpp
Severity: wishlist
Owner: Mark E. Fuller 

* Package name: go-task
  Version : 3.21.0-1
  Upstream Author : Task
* URL : https://github.com/go-task/task
* License : MIT
  Programming Lang: Go
  Description : A task runner / simpler Make alternative written in Go

Reason for packaging: Alternative to Make with utility for development 
and CI


OpenPGP_0xD599E76CFFCABF60.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032120: Upload of new upstream version before fix has migrated to testing

[Nilesh Patra]

Quoting Andreas Tille:

your recent upload of tiledb 2.15.0-1 into unstable is quite unfortunate
in freeze policy.  You should have waited at least until 2.14.1-2 fixing
this bug to migrate to testing.  You would need to ask release team for
migration of 2.15.0 which will probably be refused


The changes between 2.14 and 2.15 are non-trivial and are likely to be rejected 
by
release team at the moment, considering there are no autopkgtests either.


even if you would be
able to fix the regression in autopkgtest[1].


This is because the version of tiledb-py is not compatible with tiledb 2.15.0. 
Uploading
a new version of tiledb-py would fix this, but:

- It'd be useless unless tiledb 2.15.0 migrates.
- It seems to need pyarrow for tests, and other functionalities, which is 
un-packaged.

So current situation is:

* tiledb 2.14.1-1 in testing (and next stable) is marked for auto-removal.
* consequently, tiledb-py is also marked for autoremoval.
* tiledb 2.15.0-1 can't migrate because of freeze policy.

What a freaking mess!

Dirk, we could have avoided all of it if you had quite literally ** waited ** 
for a few hours
to let tiledb migrate on the 8th of March. I'm sad to see such mess-ups 
happening at this time as I
had put quite some efforts on tiledb-py myself too.

The solution right now is what Andreas said:


My recommendation would be to upload a version

   2.15.0-2+really_2.14.1


Dirk, please fix this so tiledb can make a (valid) stable release.


[1]: https://tracker.debian.org/pkg/tiledb


Thanks,
Nilesh

Bug#1032657: runit-services: connmand runscript

[Dimitris]

Package: runit-services
Version: 0.5.4
Severity: wishlist

Hey,

please add a connman runscript in runit-services package.
there's an example here : https://git.devuan.org/xinomilo/runscript-
collection/src/branch/master/connman that might help. just keep in mind 
i haven't tried that one in production.


was going to suggest network-manager runscript too, but will leave that 
one for now... some other time :)


thanks in advance,
d.


-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.15-xanmod1 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages runit-services depends on:
ii  runit 2.1.2-54
ii  runit-helper  2.15.2

Versions of packages runit-services recommends:
ii  runit-init  2.1.2-54

Versions of packages runit-services suggests:
pn  socklog  

-- no debconf information

Bug#1032656: bzflag: BZFlag Start Server menu errors because bzflag-server automatically runs bzfs

[Scott Wichser]

Package: bzflag
Version: 2.4.26-1
Severity: normal
X-Debbugs-Cc: blast...@users.sourceforge.net

Dear Maintainer,

The bzflag-server package installs and enables a systemd service that will run
an instance of bzfs with a minimal configuration. The bzflag-client package
suggests the bzflag-server package (and both the -client and -server packages
are installed by the bzflag metapackage). The BZFlag client has a Start Server
menu that allows a user to quickly configure and start a basic bzfs instance
for LAN play. However, because the bzflag-server package runs bzfs
automatically, the client fails to launch an instance of bzfs. My expection
would be that the systemd service would be disabled by default when installed.
As an aside, it might also be more useful if a configuration file in /etc was
referenced via the -conf option so that editing the service wasn't needed to
make configuration changes.


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

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

Versions of packages bzflag depends on:
ii  bzflag-client  2.4.26-1
ii  bzflag-server  2.4.26-1

bzflag recommends no packages.

bzflag suggests no packages.

-- no debconf information

Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start

[Benedikt Spranger]

On Fri, 10 Mar 2023 15:04:44 +0100
Paride Legovini  wrote:

[...] 
> Thanks for the patch. However I have a couple of questions:
> 
> Are you actually using Bookworm with sysv, having removed systemd, or
> are you using the init.d scripts for some other reason (integration
> with other software, habit, ...)?
I am using bookworm/sid with sysv, having systemd not installed/purged.
systemd simply does not fit *my* needs, while sysv does. Therefore sysv.

> If your init system is systemd, then I strongly advise using systemctl
> to start/stop/... the daemons.
See above: no systemd

> I don't think the init scripts are actively maintained at the moment,
> as you noticed (FIXME kea team, Cc:). Plus QA on the package
> (e.g. DEP8 tests) is done assuming systemd.
I am aware of that. And I fully understand the rationale behind that
decision.

> If you are a sysv init user, are you willing to test packages with a
> candidate fix, before an upload is done?
If you need help here, do not hesitate to ask. I can test the package.

> I am not running sysv systems; The case looks simple enough for me to
> tempt a fix, but I ned validation from an actual sysv user. Even better
> if you can submit a salsa MR, which will also speed up the process of
> landing a fix: 
> https://salsa.debian.org/debian/isc-kea/

Can do that next week. ATM I am busy to prepare stuff for a trade fair
starting next week...

Regards
Bene

Bug#1032394: libqt5positioning5-plugins: Serial NMEA plugin is missing

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 patch

Hi!

I have just created 
https://salsa.debian.org/qt-kde-team/qt/qtlocation/-/merge_requests/3

I created a MR because I am not strictly sure we can push this now due to 
freeze.

Apart from that Salsa shows no diff for that MR, which is odd... so I guess one 
will have to compare the branches by hand :-/

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

Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services

[Daniel Baumann]

Hi Benjamin

On 3/10/23 14:40, Benjamin Drung wrote:
> I would love to team maintain that package.

I've had this on my todo list (but didn't fill a ITP for it), so I'm
happy to (co)maintain it or take over if you just want do to the inital
but not longterm work.

Regards,
Daniel

Bug#1032655: psi-plus segfaults

[Lee Garrett]

Package: psi-plus
Version: 1.4.554-5+b2
Severity: grave
X-Debbugs-Cc: deb...@rocketjump.eu

Hi,

psi-plus currently simply segfaults on a stock bookworm installation:

$ psi-plus 
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
[20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile 
(unknown:0, unknown)
Segmentation fault

Regards,
Lee

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

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

Versions of packages psi-plus depends on:
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libhunspell-1.7-0 1.7.1-1
ii  libidn12  1.41-1
ii  libminizip1   1.1-8+b1
ii  libqca-qt5-2  2.3.5-2
ii  libqca-qt5-2-plugins  2.3.5-2
ii  libqt5concurrent5 5.15.8+dfsg-3
ii  libqt5core5a  5.15.8+dfsg-3
ii  libqt5dbus5   5.15.8+dfsg-3
ii  libqt5gui55.15.8+dfsg-3
ii  libqt5keychain1   0.13.2-5
ii  libqt5network55.15.8+dfsg-3
ii  libqt5sql55.15.8+dfsg-3
ii  libqt5sql5-sqlite 5.15.8+dfsg-3
ii  libqt5svg55.15.8-2
ii  libqt5widgets55.15.8+dfsg-3
ii  libqt5x11extras5  5.15.8-2
ii  libqt5xml55.15.8+dfsg-3
ii  libstdc++612.2.0-14
ii  libx11-6  2:1.8.4-2
ii  psi-plus-common   1.4.554-5
ii  zlib1g1:1.2.13.dfsg-1

Versions of packages psi-plus recommends:
ii  psi-plus-l10n 1.4.554-1
ii  psi-plus-plugins  1.4.554-5+b2
ii  psi-plus-sounds   1.4.554-5
ii  sox   14.4.2+git20190427-3.4

Versions of packages psi-plus suggests:
pn  libgnome-keyring0  
ii  xdg-utils  1.1.3-4.1

-- no debconf information

Bug#1032605: apt: should change "non-free" to "non-free non-free-firmware" in /etc/apt/sources.list

[Vincent Lefevre]

On 2023-03-10 14:27:50 +0100, Julian Andres Klode wrote:
> We have added a notice thingy for bookworm specifically to help
> people, but unstable and testing users are expected to sort that
> out on their own months ago so adding more code to deal with them
> and break other downstream users isn't very helpful.

OK, the discussion in the debian-user-french was not very clear,
and this has now been clarified.

In any case, the change should be announced somewhere, and now,
I think that the issue is in aptitude, as with aptitude, I have
never got the information, while testing/unstable apt users got
it. I could also check that on my side by using "apt update"
(instead of doing the update with aptitude), and I get the usful
message:

N: Repository 'Debian bookworm' changed its 'non-free component' value from 
'non-free' to 'non-free non-free-firmware'
N: More information about this can be found online in the Release notes at: 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.html#non-free-split

So, aptitude should have output the same thing. I've reported a bug
against aptitude:

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

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

Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware

[Vincent Lefevre]

Package: aptitude
Version: 0.8.13-5
Severity: important

I'm using testing+unstable, and Debian changed the non-free component
to "non-free non-free-firmware" some time ago, and nothing has been
announced. I've recently learnt that with apt 2.6, a message is output
about that with "apt update", but I got nothing with updates from the
aptitude UI.

I have just tried "apt update" and got:

15 packages can be upgraded. Run 'apt list --upgradable' to see them.
N: Repository 'Debian bookworm' changed its 'non-free component' value from 
'non-free' to 'non-free non-free-firmware'
N: More information about this can be found online in the Release notes at: 
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.html#non-free-split

This message should have been displayed by aptitude. Without it, the
user who uses aptitude only may never be aware of this change and will
miss future updates of the concerned packages (which are important for
security reasons).

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 12.1.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.3
  libsigc++ version: 2.10.8
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.4.20221231
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffdc6f9e000)
libgtk3-nocsd.so.0 => /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 
(0x7f381c337000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f381bc05000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f381c2fd000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f381c2cb000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f381c2c2000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f381bb13000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f381b9b4000)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7f381c2a8000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f381b60)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f381c2a3000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f381b20)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f381b8d5000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f381c281000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f381b41f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f381c27c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f381c25d000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f381c24a000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f381c219000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7f381b8af000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7f381b144000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7f381b882000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f381b075000)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f381af2e000)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f381b86b000)
/lib64/ld-linux-x86-64.so.2 (0x7f381c364000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7f381b861000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f381b855000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f381af06000)

-- System Information:
Debian Release: 12.0
  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)
Foreign Architectures: i386

Kernel: Linux 6.1.0-6-amd64 (SMP w/12 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 aptitude depends on:
ii  aptitude-common   0.8.13-5
ii  libapt-pkg6.0 2.6.0
ii  libboost-iostreams1.74.0  1.74.0+ds1-20
ii  libc6 2.36-8
ii  libcwidget4   0.5.18-6
ii  libgcc-s1 12.2.0-14
ii  libncursesw6  6.4-2
ii  libsigc++-2.0-0v5 2.12.0-1
ii  libsqlite3-0  3.40.1-1
ii  libstdc++612.2.0-14
ii  libtinfo6 6.4-2
ii  libxapian30   

Bug#1032413: kodi-inputstream-adaptive FTCBFS: assumes a toolchain file

[Helmut Grohne]

On Thu, Mar 09, 2023 at 08:18:24PM +0100, Timo Röhling wrote:
> Given that meson and cmake are also part of the toolchain
> build-essential set (just like debhelper), would it not be better to
> have a separate cross-toolchain-helper package that provides such
> generators for all supported build systems?

Indeed none of meson, cmake and debhelper are build-essential. I think
we've vaguely tried that with cross-config, which happens to still be
pulled by sbuild, but not by pbuilder. I recommend not repeating this.

For another thing, keep in mind that Debian is not the only user of such
functionality. My original approach to this was adding debcrossgen to
meson, but Jussi Pakkanen argued in favour of including it in meson
proper and now it is "meson env2mfile" - a core meson functionality.
Users (or CI) building stuff on Debian systems but without a Debian
package is thus enabled to use Debian's cross build infrastructure in an
easy way: meson env2mfile knows how Debian works and will produce a
suitable crossfile.

> I'd say that is a matter of personal preference. It is certainly
> more convenient for developers who need to invoke cmake manually,
> but in effect, it is not much different from the current "inline"
> approach.

While I appreciate "there is more than one way to do it", there also is
value in "There should be one-- and preferably only one --obvious way to
do it." An ind this case, my impression is that the world is converging
towards the other way (from Debian point of view). The question kinda is
how accurate that impression is.

Hence, I think that if we're going to change the way we pass cross flags
to cmake, we should do it like meson does by providing a tool inside the
cmake package.

Helmut

Bug#1032653: intel2gas FTCBFS: does not pass --host to configure

[Helmut Grohne]

Source: intel2gas
Version: 1.3.3-17
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

intel2gas cross builds a broken package, because it builds for the build
architecture. It needs to pass --host to configure. I'm attaching a
patch for your convenience.

Helmut
diff -u intel2gas-1.3.3/debian/changelog intel2gas-1.3.3/debian/changelog
--- intel2gas-1.3.3/debian/changelog
+++ intel2gas-1.3.3/debian/changelog
@@ -1,3 +1,10 @@
+intel2gas (1.3.3-17.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass --build and --host to configure. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 10 Mar 2023 13:03:19 +0100
+
 intel2gas (1.3.3-17) unstable; urgency=low
 
   * lifted standards version
diff -u intel2gas-1.3.3/debian/rules intel2gas-1.3.3/debian/rules
--- intel2gas-1.3.3/debian/rules
+++ intel2gas-1.3.3/debian/rules
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 DOCDIR=debian/tmp/usr/share/doc/intel2gas
 
+include /usr/share/dpkg/architecture.mk
+
 CPPFLAGS:=$(shell dpkg-buildflags --get CPPFLAGS)
 CFLAGS:=$(shell dpkg-buildflags --get CFLAGS)
 CXXFLAGS:=$(shell dpkg-buildflags --get CXXFLAGS) $(shell dpkg-buildflags 
--get CPPFLAGS)
@@ -25,7 +27,7 @@
 
 build:
if [ ! -f debian/rules ]; then echo "wrong dir!"; exit 1; fi
-   ./configure --prefix=/usr 
+   ./configure --prefix=/usr --build=$(DEB_BUILD_GNU_TYPE) 
--host=$(DEB_HOST_GNU_TYPE)
$(MAKE) CXXFLAGS="$(CXXFLAGS)" LDFLAGS="$(LDFLAGS)" 
INSTALL_OPTS="$(INSTALL_OPTS)"
touch build
 

Bug#1032652: monero FTBFS with nocheck profile: python3 not found

[Helmut Grohne]

Source: monero
Version: 0.18.0.0+~0+20200826-1
Severity: serious
Tags: ftbfs trixie sid
Justification: nocheck ftfbs is serious since trixie

monero fails to build from source when enabling the nocheck build
profile. Evidently, cmake expects python3, which is tagged  in
debian/control. Please either drop the  annotations or ensure
that the build passes.

Note that this is not an RC bug for bookworm and earlier. There is no
expectation to fix this before the bookworm release though it may still
be included there if the fix is not invasive (e.g. dropping
annotations).  It only becomes RC after bookworm as been released due to
a change in release policy.

Helmut

Bug#1032651: vile FTCBFS: broken cross-compilation specific autoconf test

[Helmut Grohne]

Source: vile
Version: 9.8y-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

vile fails to cross build from source, because the cross-compilation
specific test contains a syntax error. This will become obvious once
looking at the attached patch. Thus it fails to define GETPRGP_VOID and
that produces a compilation error later.

Helmut
--- vile-9.8y.orig/aclocal.m4
+++ vile-9.8y/aclocal.m4
@@ -2951,7 +2951,7 @@ fi
 if test "$cross_compiling" = yes ; then
 	AC_CHECK_FUNC(getpgrp,[
 	AC_TRY_COMPILE([
-#ac_includes_default
+$ac_includes_default
 
 #include 
 ],[

Bug#1032495: kea-dhcp4-server: apparmor profile prohibit start

[Paride Legovini]

Control: severity -1 normal

bene wrote on 08/03/2023:
> On Wednesday, March 08, 2023 20:15 CET, Andreas Hasenack 
>  wrote: 
>   
>> I see you are not using the systemd unit, so I suspect you are running kea
>> as root directly, instead of as the unprivileged `_kea` user, and you are
>> probably tripping over the "owner" flag of the apparmor rules.
> 
> Thanks for the hint... (\me buys some big brown paperbag...)
> 
> It is working now with the following patch to /etc/init.d/kea-dhcp4-server.

> --- /etc/init.d/kea-dhcp4-server.orig   2023-03-08 22:00:35.249600025 
> +0100
> +++ /etc/init.d/kea-dhcp4-server2023-03-08 22:12:11.80397 +0100

[...]

Thanks for the patch. However I have a couple of questions:

Are you actually using Bookworm with sysv, having removed systemd, or
are you using the init.d scripts for some other reason (integration with
other software, habit, ...)?

If your init system is systemd, then I strongly advise using systemctl
to start/stop/... the daemons. I don't think the init scripts are
actively maintained at the moment, as you noticed (FIXME kea team, Cc:).
Plus QA on the package (e.g. DEP8 tests) is done assuming systemd.

If you are a sysv init user, are you willing to test packages with a
candidate fix, before an upload is done? I am not running sysv systems;
The case looks simple enough for me to attempt a fix, but I need
validation from an actual sysv user. Even better if you can submit a
salsa MR, which will also speed up the process of landing a fix:

https://salsa.debian.org/debian/isc-kea/

Cheers,

Paride

Bug#1032650: ITP: nvme-stas -- NVMe STorage Appliance Services

[Benjamin Drung]

Package: wnpp
Severity: wishlist
Owner: Benjamin Drung 
X-Debbugs-Cc: debian-de...@lists.debian.org, bdr...@debian.org

* Package name: nvme-stas
  Version : 2.3.1
  Upstream Author : Martin Belanger 
* URL : https://github.com/linux-nvme/nvme-stas
* License : Apache 2.0
  Programming Lang: Python
  Description : NVMe STorage Appliance Services

 This package provides two daemons, stafd and stacd. The STorage Appliance
 Finder Daemon (stafd) automatically discovers NVMe-oF Discovery Controllers
 (DC) and retrieves the list of NVMe Storage Appliances. The STorage Appliance
 Connector Daemon (stacd) establishes I/O connections to the NVMe Storage
 Appliances discovered by stafd.

I am working on packaging nvme-stas as part of my day job at Canonical.
I would love to team maintain that package. Since it is a Python project
it could be maintained by the Python team. Or it could form a team with
the nvme package libnvme and nvme-cli.

-- 
Benjamin Drung
Debian & Ubuntu Developer

Bug#1026062: kded5: kded crashes with signal 11

[James Addison]

Followup-For: Bug #1026062
Control: reassign -1 libpackagekitqt5-1 1.1.0-1
Control: retitle -1 packagekit-qt: use-after-free in PackageKit::Transaction
Control: affects -1 kded5
Control: forwarded -1 https://github.com/PackageKit/PackageKit-Qt/issues/42
Control: tags -1 fixed-upstream

Bug#1032648: depthcharge-tools-installer: repeatedly logs about non-ChromeOS board

[Cyril Brulebois]

Ciao Emanuele,

Emanuele Rocca  (2023-03-10):
> while looking at d-i logs for one of my systems I've noticed the
> following message repeated many times:
> 
>  depthcharge-tools-installer: Not installing to non-ChromeOS board.
> 
> Please consider removing the logging statement from isinstallable.

That looks like a good idea, yes. Noticed it too but was chasing other
issues at the time, then forgot about it.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#980974:

[Ivan Golović]

Same problem here on Debian 11, will try the workaround and hope for the
best. Huge time waste and disappointment though.. :/

Bug#1032649: linux-headers-6.1.0-5-amd64: Impossible to build modules via dpkg-reconfigure command

[Joao Eriberto Mota Filho]

Package: linux-headers-6.1.0-5-amd64
Version: 6.1.12-1
Severity: normal

Dear maintainers,

When trying to build modules using the commands:

  # dpkg-reconfigure nvidia-tesla-470-kernel-dkms
  # dpkg-reconfigure lime-forensics-dkms

I got:

  Module build for kernel 6.1.0-5-amd64 was skipped since the
  kernel headers for this kernel do not seem to be installed.

I have the headers installed on my machine:

  root@canopus:~# dpkg -l | grep linux-headers
  ii linux-headers-6.1.0-3-amd64   6.1.8-1   amd64  Header files for Linux 
6.1.0-3-amd64
  ii linux-headers-6.1.0-3-common  6.1.8-1   allCommon header files for 
Linux 6.1.0-3
  ii linux-headers-6.1.0-5-amd64   6.1.12-1  amd64  Header files for Linux 
6.1.0-5-amd64
  ii linux-headers-6.1.0-5-common  6.1.12-1  allCommon header files for 
Linux 6.1.0-5
  ii linux-headers-amd64   6.1.12-1  amd64  Header files for Linux 
amd64 configuration (meta-package)

Note this issue is specifically for linux-headers-6.1.0-5-amd64. The
linux-headers-6.1.0-3-amd64 is working fine.

Regards,

Eriberto

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

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

Versions of packages linux-headers-6.1.0-5-amd64 depends on:
ii  linux-compiler-gcc-12-x86 6.1.12-1
ii  linux-headers-6.1.0-5-common  6.1.12-1
ii  linux-kbuild-6.1  6.1.12-1

linux-headers-6.1.0-5-amd64 recommends no packages.

linux-headers-6.1.0-5-amd64 suggests no packages.

-- no debconf information

Bug#1032631: please drop transitional package apt-transport-https from src:apt

[Holger Levsen]

On Fri, Mar 10, 2023 at 02:25:59PM +0100, Julian Andres Klode wrote:
> Control: tag -1 wontfix

fair enough.
 
> We have no plans to drop this package for the foreseeable future. Doing
> so breaks various bootstrapping tools and causes severe headaches we
> don't have the capacity to deal with.

even if apt provides apt-transports-https?


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Where will you go when you become a climate refugee?


signature.asc
Description: PGP signature

Bug#1032648: depthcharge-tools-installer: repeatedly logs about non-ChromeOS board

[Emanuele Rocca]

Package: depthcharge-tools-installer

Hi,

while looking at d-i logs for one of my systems I've noticed the following
message repeated many times:

 depthcharge-tools-installer: Not installing to non-ChromeOS board.

Please consider removing the logging statement from isinstallable.

Thanks,
  ema

Bug#1032646: please drop transitional package python3-buildbot-doc from src:buildbot

[Holger Levsen]

Package: python3-buildbot-doc
Version: 3.7.0-2
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package python3-buildbot-doc (from the source 
package buildbot) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: transitional package for buildbot-doc
Package: python3-buildbot-doc
Version: 2.0.1-2
Version: 2.10.1-1
Version: 3.7.0-2

Thanks for maintaining buildbot!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

I miss the old days were billionaires’ vanity projects were to build 1000 public
libraries or giant music venues.


signature.asc
Description: PGP signature

Bug#1032645: please drop transitional package compiz-plugins-default from src:compiz

[Holger Levsen]

Package: compiz-plugins-default
Version: 2:0.8.18-5
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package compiz-plugins-default (from the source 
package compiz) after the release of bookworm, it has been released with buster 
and bullseye already...


Description: transitional dummy package
Package: compiz-plugins-default
Version: 2:0.8.16.1-10
Version: 2:0.8.18-2
Version: 2:0.8.18-5

Thanks for maintaining compiz!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Make earth cool again.


signature.asc
Description: PGP signature

Bug#1032644: please drop transitional package gtk3-engines-breeze from src:breeze-gtk

[Holger Levsen]

Package: gtk3-engines-breeze
Version: 5.27.2-1
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package gtk3-engines-breeze (from the source 
package breeze-gtk) after the release of bookworm, it has been released with 
buster and bullseye already...


Description: Transitional package for KDE's Breeze
Package: gtk3-engines-breeze
Version: 5.14.5-1
Version: 5.20.5-1
Version: 5.27.2-1

Thanks for maintaining breeze-gtk!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

If it feels like we’re breaking climate records every year, it’s because we are.


signature.asc
Description: PGP signature

Bug#1032643: please drop transitional package migemo-el from src:cmigemo

[Holger Levsen]

Package: migemo-el
Version: 1:1.2+gh0.20150404-8
Severity: normal
user: qa.debian@packages.debian.org
usertags: transitional

Please drop the transitional package migemo-el (from the source package 
cmigemo) after the release of bookworm, it has been released with buster and 
bullseye already...


Description: transitional dummy package: elpa-migemo
Package: migemo-el
Version: 1:1.2+gh0.20150404-7
Version: 1:1.2+gh0.20150404-7.1
Version: 1:1.2+gh0.20150404-8

Thanks for maintaining cmigemo!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

In a world where you can be anything, be kind.


signature.asc
Description: PGP signature