Bug#1022865: notepadqq: unnecessary test dependency on autopkgtest?

[Paul Gevers]

Source: notepadqq
Version: 2.0.0~beta1-3
Severity: minor

Dear maintainer(s),

I happen to be one of the maintainers of autopkgtest and I just
happened to notice that your autopkgtest depends on
autopkgtest. However, I can't find where in the test you actually use
that dependency. Is it really needed?

Obviously you need autopkgtest to run your test within the autopkgtest
framework, but in that case autopkgtest already needs to be installed
beforehand on the host that creates the testbed, so you wouldn't need
to declare it.

Paul

Bug#1022864: gscan2pdf: unnecessary test dependency on autopkgtest?

[Paul Gevers]

Source: gscan2pdf
Version: 2.13.0-1
Severity: minor

Dear Jeffrey,

I happen to be one of the maintainers of autopkgtest and I just
happened to notice that your autopkgtest depends on
autopkgtest. However, I can't find where in the gscan2pdf test you
actually use that dependency. Is it really needed?

Obviously you need autopkgtest to run your test within the autopkgtest
framework, but in that case autopkgtest already needs to be installed
beforehand on the host that creates the testbed, so you wouldn't need
to declare it.

Paul

Bug#1022863: rpmlint: does the autopkgtest still needs to depend on autopkgtest?

[Paul Gevers]

Source: rpmlint
Version: 2.4.0+ds1-0.1
Severity: minor

Dear maintainer,

I happen to be one of the maintainers of autopkgtest and I happened to
notice that your autopkgtest depends on autopkgtest. If I read the
history log comments of d/t/control correctly, I think that's because
the first version worked that way, but I wonder if it's still
needed. If not, I suggest to drop the test dependency.

Thanks

Paul

Bug#1022860: bullseye-pu: package powerline-gitstatus/1.3.2-1+deb11u1

[Salvatore Bonaccorso]

On Wed, Oct 26, 2022 at 11:05:05PM -0400, Jérôme Charaoui wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> [ Reason ]
> I would like to upload powerline-gitstatus to stable to fix CVE-2022-42906.
> I have consulted with the security team and they suggested we make the fix
> available via the next point release.
> 
> [ Impact ]
> powerline-gitstatus/1.3.1 and earlier versions are susceptible to code
> execution via malicious repository. Note that the malicious repository must
> be obtained other than by "git clone".
> 
> [ Tests ]
> The package has no autopkgtests. It has been tested manually.
> 
> [ Risks ]
> The changeset between 1.3.1 and 1.3.2 is small. The risk is low that
> a new bug or security issue is introduced.
> 
> [ Checklist ]
>   [x] *all* changes are documented in the d/changelog
>   [x] I reviewed all changes and I approve them
>   [x] attach debdiff against the package in (old)stable
>   [x] the issue is verified as fixed in unstable
> 
> [ Changes ]
> The fix for CVE-2022-42906 is straightforward: it simply appends the
> argument "-C core.fsmonitor=" to the git command. Aside from that, a simple
> program option was added (untracked_not_dirty) and the README is updated.
> 
> [Other info]
> As I expect a positive response, I will be uploading the package shortly.
> 
> 
> -- Jerome

> diff -Nru powerline-gitstatus-1.3.1/debian/changelog 
> powerline-gitstatus-1.3.2/debian/changelog
> --- powerline-gitstatus-1.3.1/debian/changelog2020-07-08 
> 16:17:05.0 -0400
> +++ powerline-gitstatus-1.3.2/debian/changelog2022-10-26 
> 22:54:03.0 -0400
> @@ -1,3 +1,10 @@
> +powerline-gitstatus (1.3.2-1+deb11u1) bullseye; urgency=medium
> +
> +  * New upstream version 1.3.2
> +- Fix command injection via malicious repository config (CVE-2022-42906)
> +
> + -- Jérôme Charaoui   Wed, 26 Oct 2022 22:54:03 -0400
> +
>  powerline-gitstatus (1.3.1-2) unstable; urgency=medium

The former proposed update was to just cherry-pick the needed change,
so the version number 1.3.1-2+deb11u1. But if you propose to import
1.3.2 instread, then you need to pick 1.3.2-1~deb11u1 or
1.3.2-0+deb11u1 here, to have it sorting before the version which hit
the archive as 1.3.2-1.

In fact, if you just import a new upstream version on top of the
current packaging then I would go for 1.3.2-0+deb11u1. If it is OTOH
merely a rebuild of the upper-suite version then 1.3.2-1~deb11u1.

In your case I think both of the ones is perfectly reasonable.

Hope that helps,

Regards,
Salvatore

Bug#1022862: ITP: libsphinx -- SPHINX password storage library

[Joost van Baal-Ilić]

Package: wnpp
Owner: Joost van Baal-Ilić 
Severity: wishlist

* Package name: libsphinx
  Upstream Author : Stefan Marsiske
* URL : https://github.com/stef/libsphinx
* License : LGPL-3+
  Programming Lang: C
  Description : SPHINX password storage library

 SPHINX -- password Store that Perfectly Hides from Itself (No Xaggeration) --
 is an information-theoretically secure cryptographic password storage
 protocol with strong security guarantees, as described in the 2015 paper
 "Device-Enhanced Password Protocols with Optimal Online-Offline Protection" by
 Jarecki, Krawczyk, Shirvanian, and Saxena (https://ia.cr/2015/1099).

 libsphinx is a low-level library implementing SPHINX.

I plan to package "pwdsphinx" too ( https://salsa.debian.org/debian/pwdsphinx ,
https://github.com/stef/pwdsphinx , ITP will follow); pwdsphinx will depend
upon libequihash (ITP #1021433, https://salsa.debian.org/debian/libequihash)
and libsphinx.

I'm using https://salsa.debian.org/debian/libsphinx for the packaging work.

See https://www.ctrlc.hu/~stef/blog/posts/sphinx.html and
https://nlnet.nl/project/OpaqueSphinxServer/ for more background information.

The SPHINX project was funded through the NGI0 PET Fund, a fund established by
NLnet with financial support from the European Commission's Next Generation
Internet programme, under the aegis of DG Communications Networks, Content and
Technology under grant agreement No 825310.

Bye,

Joost

Bug#1022861: evince: Evince in Unstable Seems Need Outdated libgs9 Binary

[Zhian Chen]

Package: evince
Version: 43.0-1
Severity: important
X-Debbugs-Cc: moonexi...@gmail.com

Dear Maintainer,

I am using evince on Debian unstable system, everything goes well until I
notice that ghostscript package is currently under transition, and one
of its binaries that evince requires, **libgs9**, updates and is renamed to
**libgs10**. upgrading ghostscript will remove libgs9 and pull in
libgs10, hence evince will be removed by autoremove, too.

I can't find useful informations about libgs9 problem in
Debian Package Tracker's evince page. What should I do now? 
For now I choose to wait and not to upgrade my system.

'aptitude why libgs9' shows:
i   evince   Depends libevdocument3-4 (= 43.0-1)
i A libevdocument3-4 Depends libspectre1 (>= 0.2.3) 
i A libspectre1  Depends libgs9 (>= 9.53.0~dfsg)

With Sincere Appreciation,
Zhian Chen


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

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

Versions of packages evince depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  evince-common43.0-1
ii  gsettings-desktop-schemas43.0-1
ii  libatk1.0-0  2.46.0-3
ii  libc62.35-4
ii  libcairo-gobject21.16.0-6
ii  libcairo21.16.0-6
ii  libevdocument3-4 43.0-1
ii  libevview3-3 43.0-1
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.1-1
ii  libgnome-desktop-3-2043-2
ii  libgtk-3-0   3.24.34-3
ii  libhandy-1-0 1.8.0-1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libsecret-1-00.20.5-3
ii  shared-mime-info 2.2-1

Versions of packages evince recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.4-1

Versions of packages evince suggests:
ii  gvfs 1.50.2-2
pn  nautilus-sendto  
ii  poppler-data 0.4.11-1
pn  unrar

-- no debconf information

Bug#1022860: bullseye-pu: package powerline-gitstatus/1.3.2-1+deb11u1

[Jérôme Charaoui]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
I would like to upload powerline-gitstatus to stable to fix 
CVE-2022-42906. I have consulted with the security team and they 
suggested we make the fix available via the next point release.


[ Impact ]
powerline-gitstatus/1.3.1 and earlier versions are susceptible to code 
execution via malicious repository. Note that the malicious repository 
must be obtained other than by "git clone".


[ Tests ]
The package has no autopkgtests. It has been tested manually.

[ Risks ]
The changeset between 1.3.1 and 1.3.2 is small. The risk is low that
a new bug or security issue is introduced.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The fix for CVE-2022-42906 is straightforward: it simply appends the 
argument "-C core.fsmonitor=" to the git command. Aside from that, a 
simple program option was added (untracked_not_dirty) and the README is 
updated.


[Other info]
As I expect a positive response, I will be uploading the package shortly.


-- Jerome
diff -Nru powerline-gitstatus-1.3.1/debian/changelog 
powerline-gitstatus-1.3.2/debian/changelog
--- powerline-gitstatus-1.3.1/debian/changelog  2020-07-08 16:17:05.0 
-0400
+++ powerline-gitstatus-1.3.2/debian/changelog  2022-10-26 22:54:03.0 
-0400
@@ -1,3 +1,10 @@
+powerline-gitstatus (1.3.2-1+deb11u1) bullseye; urgency=medium
+
+  * New upstream version 1.3.2
+- Fix command injection via malicious repository config (CVE-2022-42906)
+
+ -- Jérôme Charaoui   Wed, 26 Oct 2022 22:54:03 -0400
+
 powerline-gitstatus (1.3.1-2) unstable; urgency=medium
 
   [ Jann Haber ]
diff -Nru powerline-gitstatus-1.3.1/powerline_gitstatus/segments.py 
powerline-gitstatus-1.3.2/powerline_gitstatus/segments.py
--- powerline-gitstatus-1.3.1/powerline_gitstatus/segments.py   2019-01-11 
08:50:57.0 -0500
+++ powerline-gitstatus-1.3.2/powerline_gitstatus/segments.py   2022-10-09 
08:58:20.0 -0400
@@ -11,9 +11,9 @@
 
 def execute(self, pl, command):
 pl.debug('Executing command: %s' % ' '.join(command))
-   
+
 git_env = os.environ.copy()
-git_env['LC_ALL'] = 'C' 
+git_env['LC_ALL'] = 'C'
 
 proc = Popen(command, stdout=PIPE, stderr=PIPE, env=git_env)
 out, err = [item.decode('utf-8') for item in proc.communicate()]
@@ -27,13 +27,13 @@
 
 def get_base_command(self, cwd, use_dash_c):
 if use_dash_c:
-return ['git', '-C', cwd]
+return ['git', '-c', 'core.fsmonitor=', '-C', cwd]
 
 while cwd and cwd != os.sep:
 gitdir = os.path.join(cwd, '.git')
 
 if os.path.isdir(gitdir):
-return ['git', '--git-dir=%s' % gitdir, '--work-tree=%s' % cwd]
+return ['git', '-c', 'core.fsmonitor=', '--git-dir=%s' % 
gitdir, '--work-tree=%s' % cwd]
 
 cwd = os.path.dirname(cwd)
 
@@ -80,10 +80,10 @@
 
 return (staged, unmerged, changed, untracked)
 
-def build_segments(self, formats, branch, detached, tag, behind, ahead, 
staged, unmerged, changed, untracked, stashed):
+def build_segments(self, formats, branch, detached, tag, behind, ahead, 
staged, unmerged, changed, untracked, stashed, untracked_not_dirty):
 if detached:
 branch_group = 'gitstatus_branch_detached'
-elif staged or unmerged or changed or untracked:
+elif staged or unmerged or changed or (untracked and not 
untracked_not_dirty):
 branch_group = 'gitstatus_branch_dirty'
 else:
 branch_group = 'gitstatus_branch_clean'
@@ -111,7 +111,7 @@
 
 return segments
 
-def __call__(self, pl, segment_info, use_dash_c=True, show_tag=False, 
formats={}, detached_head_style='revision'):
+def __call__(self, pl, segment_info, use_dash_c=True, show_tag=False, 
formats={}, detached_head_style='revision', untracked_not_dirty=False):
 pl.debug('Running gitstatus %s -C' % ('with' if use_dash_c else 
'without'))
 
 cwd = segment_info['getcwd']()
@@ -160,7 +160,7 @@
 else:
 tag = tag[0]
 
-return self.build_segments(formats, branch, detached, tag, behind, 
ahead, staged, unmerged, changed, untracked, stashed)
+return self.build_segments(formats, branch, detached, tag, behind, 
ahead, staged, unmerged, changed, untracked, stashed, untracked_not_dirty)
 
 
 gitstatus = with_docstring(GitStatusSegment(),
@@ -189,6 +189,10 @@
 Display style when in detached HEAD state. Valid values are ``revision``, 
which shows the current revision id, and ``ref``, which shows the closest 
reachable ref object.
 The default is ``revision``.
 
+:param untracked_not_dirty:
+Untracked files alone will not mark the git 

Bug#1022859: RM: govendor -- RoQA; superseded by Go modules; upstream discontinued

[Shengjing Zhu]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org, f...@debian.org


Hi,

govendor upstream repository https://github.com/kardianos/govendor is archived.
And this tool is superseded by Go modules.

Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Arnaud Rebillout]

On 26/10/2022 23:20, Michael Tokarev wrote:

Control: forward -1 https://bugzilla.samba.org/show_bug.cgi?id=15205
Control: tag -1 + upstream patch

Ok, there's a bugreport in samba (see above), and the fixes went to 
4.17.1,

but not to 4.16.6 (they're in 4.16-test, though.

I can probably make another 4.16 upload - was thinking about making 4.17
the default finally but decided to wait for yet another minor release due
to another symlink attack issue found in the new 4.17 code.

Oh well. I hate useless work, - it is useless to push the already pending
patches. But the next 4.16.7 is scheduled for Jan 05 2023, which is quite
some time from now.

Hwell..


Thanks Michael!

Arnaud

Bug#964953: Workaround

[Philip Mott]

One workaround is to set this in /etc/ssh/ssh_config:

StrictHostKeyChecking accept-new

Bug#1022858: perl-base: lots of duplicate files between perl-modules-5.32 and perl-base

[Marc Lehmann]

Package: perl-base
Version: 5.32.1-4+deb11u2
Severity: minor
X-Debbugs-Cc: report...@plan9.de

Dear Maintainer,

I recently installed a fresh bullseye and ran jdupes to deduplicate files.

To my surprise, this reduced the installed size (on a zstd-compressed btrfs 
filesystem)
from 2GB to 1.3GB.

This was rather unexpected and I investigated.

One of the larger reasons for this size reduction is a large number of 
relatively large files
that are identical in perl-modules-5.32 and perl-base, random example:

-rw-r--r-- 1 root root 1466 Sep 24  2021 
/usr/lib/x86_64-linux-gnu/perl-base/unicore/lib/Lb/CL.pl
-rw-r--r-- 1 root root 1466 Sep 24  2021 
/usr/share/perl/5.32.1/unicore/lib/Lb/CL.pl

I wonder if thid duplication is intended, and if yes, maybe hardlinks should be 
used to save space.

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

Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 perl-base depends on:
ii  dpkg   1.20.12
ii  libc6  2.31-13+deb11u5
ii  libcrypt1  1:4.4.18-4

perl-base recommends no packages.

Versions of packages perl-base suggests:
ii  perl5.32.1-4+deb11u2
ii  sensible-utils  0.0.14

-- no debconf information

Bug#1022275: Acknowledgement (nala: missing option "download only")

[Blake Lee]

Hello,

Thank you for using Nala and reporting bugs. I checked it out and `-d` indeed 
no longer exists. I'm not sure where this regression stems from but I can add 
it back in for the next release. It may be some time as I've been very busy 
lately.

As for the severity of the bug, I am unsure how to change that. I wouldn't 
worry about it though, I'll handle it all the same. This one is pretty simple 
to fix.

Thanks,
Blake

On Wed, Oct 26, 2022, at 5:30 PM, mh wrote:
> Am Sun, 23 Oct 2022 12:27:04 +
> schrieb "Debian Bug Tracking System" :
> 
> Hi, I need to change the "severity", it is not a wishbug but a bug.
> 
> There is a "-d" option, but it does not work (I am not the only to have
> experieced it) whereas the long version "--download-only" works.
> 
> So This wishbug should be changed to whatever is appropriate.
> 
> Sorry for the confusion
> 
> MH
> 
> 
> > Thank you for filing a new Bug report with Debian.
> >
> > You can follow progress on this Bug here: 1022275:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022275.
> >
> > This is an automatically generated reply to let you know your message
> > has been received.
> >
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> >
> > Your message has been sent to the package maintainer(s):
> >  Volian Developers 
> >
> > If you wish to submit further information on this problem, please
> > send it to 1022...@bugs.debian.org.
> >
> > Please do not send mail to ow...@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> >
> 

Bug#964953: Update request

[Philip Mott]

Hi there,

It’s been over two years since this bug was reported in Bullseye - is there any 
update on a fix?

Thanks

Bug#1022856: atril: Patch to transition to webkit2gtk-4.1

[Judit Foglszinger]

Package: atril
Version: 1.26.0-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: ur...@debian.org, unit...@debian.org

Hi,

have attached a patch by Unit193
for transitioning atril to webkit2gtk-4.1
>From 8578ecbe3ede1b0766710b9c9e75d01dc78636c8 Mon Sep 17 00:00:00 2001
From: Unit 193 
Date: Wed, 26 Oct 2022 08:40:51 -0400
Subject: [PATCH] d/control, d/p/1001-webkit4.1.patch: Transition to
 webkit2gtk-4.1.

---
 debian/control  |  2 +-
 debian/patches/1001-webkit2gtk4.1.patch | 15 +++
 debian/patches/series   |  1 +
 3 files changed, 17 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/1001-webkit2gtk4.1.patch
 create mode 100644 debian/patches/series

diff --git a/debian/control b/debian/control
index b8a44ce..4bd2e91 100644
--- a/debian/control
+++ b/debian/control
@@ -25,7 +25,7 @@ Build-Depends: debhelper-compat (= 13),
libspectre-dev,
libsynctex-dev,
libtiff-dev,
-   libwebkit2gtk-4.0-dev,
+   libwebkit2gtk-4.1-dev,
libx11-dev,
libxml2-dev,
libxml2-utils,
diff --git a/debian/patches/1001-webkit2gtk4.1.patch 
b/debian/patches/1001-webkit2gtk4.1.patch
new file mode 100644
index 000..149071a
--- /dev/null
+++ b/debian/patches/1001-webkit2gtk4.1.patch
@@ -0,0 +1,15 @@
+Description: Search for webkit2gtk-4.1.
+Author: Unit 193 
+Forwarded: no
+
+--- atril-1.26.0.orig/configure.ac
 atril-1.26.0/configure.ac
+@@ -622,7 +622,7 @@ AC_ARG_ENABLE(epub,
+ 
+ have_webkit="no"
+ if test "x$enable_epub" = "xyes"; then
+-PKG_CHECK_MODULES(EPUB, webkit2gtk-4.0 >= $WEBKIT_REQUIRED \
++PKG_CHECK_MODULES(EPUB, webkit2gtk-4.1 >= $WEBKIT_REQUIRED \
+libxml-2.0 >= $LIBXML_REQUIRED zlib,have_webkit=yes,have_webkit=no)
+ 
+ if test "x$have_webkit" = "xyes"; then
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..108af4f
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+1001-webkit2gtk4.1.patch
-- 
2.35.1

Bug#1012547: linux: disable user namespaces per default

[Philippe Cerfon]

Here we go, another one, it seems:

CVE-2022-2588 (https://seclists.org/oss-sec/2022/q3/115)


Seems I'm not the only one who's quite concerned about the ongoing
security impact of user namspaces, as the recent/current discussion
about some LSM patches for 6.1 shows:
https://lwn.net/ml/linux-kernel/CAHk-=wicqicqrnqpehbdf7eckhk_ceyzzk5dyq7y5nztzhp...@mail.gmail.com/#t

Quoting Linus:

> And I think you are in denial about how many problems the
> user-namespace stuff has caused.
>
> Distros are literally turning it off entirely because the whole "let
> users create their own namespace" has *NOT* been a great success.
>
> I personally think it was a mistake. We're stuck with it, but we most
> definitely need knobs to manage it that isn't just "enable/disable
> USER_NS" in the kernel config.
>
> So this whole "don't do this" approach you have is not acceptable.
>
> 99% of all code does NOT WANT the user namespace thing, and it's been
> a big new attack surface for the kernel getting things subtly wrong.


It's still a shame to see that Debian intentionally sacrifices the
security of *all* users just for the needs of very few.

Regards,
Philippe.

Bug#1022855: cron script floods system mail box with "which: this version of which is deprecated, use command -v instead"

[M. Zhou]

Package: zfs-auto-snapshot
Version: 1.2.4-2
Severity: important
Tags: +patch

Dear maintainer,

After the deprecation of which, that command now creates lots of noise
and floods the system mail box. A simple fix is to replace the command.

Bug#1022830: apt ignores versioned provides if non-matching version is installed via another dep

[David Kalnischkies]

reassign -1 libruby3.1,ruby-csv
retitle -1 libruby3.1 and ruby-csv are providing different things under the 
same name

On Thu, Oct 27, 2022 at 12:32:16AM +0900, Marc Dequènes wrote:
> I had a weird FTBFS in #1022340 and it looks like the resolver is just
> skipping the versioned dep because another dep provides the same virtual
> package. Unfortunately it does not resolve the required version and should
> install the non-virtual package providing the right version (they are
> co-installable). More info in the referenced BR.
[…]
> Could you have a look please?

$ apt-cache showpkg ruby-csv
[…]
Reverse Provides:
libruby3.1 3.1.2-3 (= 3.2.2)
libruby3.0 3.0.4-8 (= 3.1.9)
libruby2.7 2.7.4-1+deb11u1 (= 3.1.2)


You are right that libruby3.0 which provides 3.1.9 is not enough to
satisfy the build-dependency of redmine, but libruby3.1 is installed,
too, and that certainly does satisfy ruby-csv (>= 3.2.0). It is
therefore correct for apt to not install the real ruby-csv package
as that dependency is already satisfied.

You might or might not be able to workaround this with Build-Conflicts,
but in the end libruby3.1 and ruby-csv should really agree on what they
are providing at what version or not… hence reassigning to both.


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

[Tianon Gravi]

On Wed, 26 Oct 2022 at 16:03, Tianon Gravi  wrote:
> On Wed, 26 Oct 2022 at 14:54, Luca Boccassi  wrote:
> > It seems debuerreotype has an autopkgtest that rebuilds Stretch with a
> > new toolchain, compares it to a fixed version and fails if it doesn't
> > match. But I don't see how this can be supported - if the toolchain
> > changes, then the result is also not expected to be the same?
> > This is why for reproducible builds the toolchain is recorded in the 
> > buildenv?
> >
> > This is going to block debootstrap's migration to testing, so I will
> > bump the severity soon if we can't find a workaround.
> >
> > Example: 
> > https://ci.debian.net/data/autopkgtest/testing/amd64/d/debuerreotype/27484986/log.gz
>
> Yeah, this is the same issue as what I noted in
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/70#note_343328
> -- I don't think the break in reproducibility of the output of
> debootstrap was _intentional_, but rather accidental (especially from
> xnox's comments there where it seems he does want to support *some*
> amount of reproducibility).
>
> I'm happy to adjust the debuerreotype test based on the updated
> debootstrap if the break was intentional, but IMO it's worth at least
> a _little_ root cause analysis first, right?  (especially if there's
> any chance it might change back again)

Also, just to be extra explicit, I have no problem with you adjusting
tags however necessary to get debootstrap to migrate in spite of
debuerreotype -- I don't want to hold anything up unnecessarily. ❤

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1022814: /etc/runit/1 could be more readable

[Lorenzo]

Hi,

On Wed, 26 Oct 2022 14:05:48 +0200
Andras Korn  wrote:

> Package: runit
> Version: 2.1.2-50
> Severity: minor
> Tags: patch
> 
> Hi,
> 
> I'm not satisfied with this bit from /etc/runit/1:
> 
> --- 8< ---
> if [ -f /etc/runit/native.boot.run ] || [ -n "$bootrun" ]; then
>   bootrun=1
> fi
> 
> if [ -d /etc/runit/boot-run ] && [ ! -z $bootrun ]; then
>   for f in /etc/runit/boot-run/*.sh; do
>   [ -r "$f" ] && . "$f"
>   done
> else
>   /lib/runit/run_sysv_scripts '/etc/rcS.d'
> fi
> 
> --- >8 ---
> 
> On the one hand, '-z $bootrun' looks like an accident waiting to
> happen due to the missing quotes around "$bootrun". On the other, '[
> ! -z "$bootrun" ]' and '[ -n "$bootrun ]' mean the same thing, so why
> do it two different ways within five lines?

I guess late night experimenting has drawbacks, and I'm taking too
seriously the advice to not use test -a or -o from the test man page...

> 
> Furthermore, the two ifs seem redundant; I think the code would be
> more succinct and more readable the following way:
> 
> --- 8< ---
> 
> if [ -f /etc/runit/native.boot.run -o -n "$bootrun" ] && [ -d
> /etc/runit/boot-run ]; then bootrun=1 # set this because
> sourced scripts might use it, I guess (although they wouldn't get run
> if bootrun weren't set, so setting bootrun=1 looks completely
> superfluous) for f in /etc/runit/boot-run/*.sh; do [ -r "$f" ] && .
> "$f" done else
>   /lib/runit/run_sysv_scripts '/etc/rcS.d'
> fi
> 
> --- >8 ---
> 
> I think this is equivalent with the exception that it only sets
> bootrun=1 if the /etc/runit/boot-run directory exists; but since
> nothing in the original script uses $bootrun, this doesn't seem to
> matter (and, as noted above, setting bootrun=1 seems completely
> redundant).

The only thing that I want to achieve here is:

1) have a way to boot with an alternative set of boot scripts by
setting 'bootrun' with GRUB, so that if something goes wrong it's
possible to reboot with initscripts

2) a permanent way (the flag file) to use an alternative set of
bootscripts, when one is satisfied with 1)

Your patch looks fine to me, I'm applying in the next upload.
Thank you

Lorenzo

> 
> András
> 

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

[Tianon Gravi]

On Wed, 26 Oct 2022 at 14:54, Luca Boccassi  wrote:
> It seems debuerreotype has an autopkgtest that rebuilds Stretch with a
> new toolchain, compares it to a fixed version and fails if it doesn't
> match. But I don't see how this can be supported - if the toolchain
> changes, then the result is also not expected to be the same?
> This is why for reproducible builds the toolchain is recorded in the buildenv?
>
> This is going to block debootstrap's migration to testing, so I will
> bump the severity soon if we can't find a workaround.
>
> Example: 
> https://ci.debian.net/data/autopkgtest/testing/amd64/d/debuerreotype/27484986/log.gz

Yeah, this is the same issue as what I noted in
https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/70#note_343328
-- I don't think the break in reproducibility of the output of
debootstrap was _intentional_, but rather accidental (especially from
xnox's comments there where it seems he does want to support *some*
amount of reproducibility).

I'm happy to adjust the debuerreotype test based on the updated
debootstrap if the break was intentional, but IMO it's worth at least
a _little_ root cause analysis first, right?  (especially if there's
any chance it might change back again)

I'd have had the same break if I'd updated this autopkgtest to use
bullseye or even bookworm (which I didn't do specifically to avoid the
extra space of storing the originals on people.debian.org
unnecessarily).  Updating this over time is going to be a fact of the
way debuerreotype works (necessarily), but it is the first time I can
remember in  the last five years of maintaining this tool that I've
had such an instance that wasn't an intentional break (like
merged-usr, for example, which is pretty easily manageable to maintain
backwards compatibility with, unlike this break where I can't control
debootstrap's behavior).

Generally when I use this tool for generating the Docker images, I do
now record the debootstrap version
(https://github.com/debuerreotype/debuerreotype/pull/139) so that
anyone looking to reproduce my results can match my environment if
necessary (although I'm realizing that version number isn't included
on https://docker.debian.net/ so I'll be updating that soon).

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#1017845: New upload should resolve native compilation fork bomb problem

[Axel Beckert]

Control: found -1 1:28.2+1-2

Hi Sean,

Axel Beckert wrote:
> Sean Whitton wrote:
> > Could you see if the upload I just made, 28.2+1-2, still shows the
> > problem, please?  It includes a backported upstream fix.  Thanks.
> 
> Would like to, but can't as "emacs-common (= 1:28.2+1-2)" is
> unavailable due to a FTBFS:
> https://buildd.debian.org/status/package.php?p=emacs

Ok, someone gave back emacs:all and it built now.

Unfortunately the issue still shows up for me:

iU  emacs  1:28.2+1-2   all  GNU Emacs editor (metapackage)
ii  emacs-common   1:28.2+1-2   all  GNU Emacs editor's shared, 
architecture independent infrast>
iF  emacs-gtk  1:28.2+1-2   amd64GNU Emacs editor (with GTK+ GUI 
support)

20564 root20   0  2724   960   864 S   0.0  0.0  0:00.00 │  │└─ 
/bin/sh /var/lib/dpkg/info/emacs-gtk.postinst configure 1:27.1+1-3.1+b1
20568 root20   0 20524 14612  5016 S   0.0  0.0  0:00.29 │  │   
└─ /usr/bin/perl -w /usr/lib/emacsen-common/emacs-install emacs
21149 root20   0 0 0 0 Z   0.0  0.0  0:00.00 │  │   
   ├─ emacs-install
21237 root20   0  2724   952   856 S   0.0  0.0  0:00.00 │  │   
   └─ /bin/sh 
/usr/lib/emacsen-common/packages/install/elpa-fill-column-indicator emacs
21238 root20   0  2724   960   864 S   0.0  0.0  0:00.00 │  │   
  └─ /bin/sh /usr/lib/dh-elpa/helper/install emacs fill-column-indicator 
1.90
21241 root20   0  2724   116 0 S   0.0  0.0  0:00.00 │  │   
 └─ /bin/sh /usr/lib/dh-elpa/helper/install emacs fill-column-indicator 
1.90
21242 root20   0  168M 57984 36120 S   0.0  0.1  0:00.54 │  │   
└─ emacs --quick --batch -l package --eval (setq package-user-dir 
"/nonexistent") --eval (add-to-list 'package-directory-list 
"/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -f 
batch-byte-compile fill-column-indica
21249 root20   0  170M 60956 36524 S   0.0  0.1  0:02.28 │  │   
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-63616c6c2d696e7465726163746976656c79_call_interactively_0-OOHs6g.el
21280 root20   0  170M 60820 36376 S   0.0  0.1  0:02.05 │  │   
  └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-vBdYEq.el
21301 root20   0  170M 61184 36740 S   0.0  0.1  0:02.30 │  │   
 └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-uu1KqI.el
21371 root20   0  170M 61172 36728 S   0.0  0.1  0:02.06 │  │   
└─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-uV1CLq.el
21385 root20   0  170M 61064 36612 S   0.0  0.1  0:02.00 │  │   
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-HpMbkC.el
21397 root20   0  170M 61184 36736 S   0.0  0.1  0:02.00 │  │   
  └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-uaC8oA.el
21423 root20   0  170M 60860 36416 S   0.0  0.1  0:02.10 │  │   
 └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-OMU2wK.el
21455 root20   0  170M 61064 36624 S   0.0  0.1  0:02.01 │  │   
└─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-MySZWN.el
21478 root20   0  170M 61012 36560 S   0.0  0.1  0:02.00 │  │   
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-EUmSvx.el
21491 root20   0  170M 61232 36788 S   0.0  0.1  0:01.99 │  │   
  └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-b5u3WS.el
21520 root20   0  170M 61264 36820 S   0.0  0.1  0:02.06 │  │   
 └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-qdrmTo.el
21538 root20   0  170M 61188 36748 S   0.0  0.1  0:02.05 │  │   
└─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-MyJVpq.el
21562 root20   0  170M 61260 36812 S   0.0  0.1  0:02.04 │  │   
   └─ /usr/bin/emacs --batch -l 
/tmp/emacs-int-comp-subr--trampoline-64656c6574652d6672616d65_delete_frame_0-Fd8uCc.el
21583 

Bug#1022268: Processed: Re: Bug#1022268: linux-image-5.10.0-19-amd64: Boot failure under xen as dom0

[Diederik de Haas]

Control: forwarded -1 
https://lore.kernel.org/linux-scsi/y1jkuktjvyrow...@eldamar.lan/T/#u

On donderdag 27 oktober 2022 00:21:32 CEST you wrote:
> Control: forwarded -1 1022...@bugs.debian.org

Pfft *facepalm*

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

Bug#1022268: Processed: Re: Bug#1022268: linux-image-5.10.0-19-amd64: Boot failure under xen as dom0

[Diederik de Haas]

Control: forwarded -1 1022...@bugs.debian.org
Control: tag -1 -moreinfo

On woensdag 26 oktober 2022 23:57:05 CEST Debian Bug Tracking System wrote:
> Unset Bug forwarded-to-address

Oeps


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

Bug#1017370: cinnamon: window decoration themes broken

[Christoph Anton Mitterer]

Hey Fabio.

I just gave the current versions another try... and still, the enforced
CSD is outright ugly ^^
OTH, I probably cannot run on the old versions forever... so:


On Mon, 2022-08-15 at 20:07 +0200, Fabio Fantoni wrote:
> About the themes I already asked suggestions in mailing list, joshua
> had 
> suggested to put the cinnamon theme by default and i think it would
> be 
> good, if there are problems in that too they should be reported on 
> cinnamon github and i suppose they would be solved as i have seen
> others 
> recently too

You think so? The only (Cinnamon) upstream tickets I had looked at were
force-locked when people complained too loud about the lost features
and the new theming.


Right now I'd see a ton of minor nuisances and some real "showstoppers"
(with respect to usability of a desktop environment).



Nuisances:

- The taller window title bar because of the CSDs.
  Sure it's only a few pixels, but that adds up and uselessly wastes
  space.
  And for e.g. gnome-terminal, with some typical screen resolution and
  32px panel, when the terminal was maximised, the terminal lines just
  perfectly divided the remaining space. Now there's some extra bit
  wasted.
- The CSD window title bar sizes don't even match amongst each other.
  E.g. the one from Evolution is a bit taller, the one from gnome-
  terminal a bit smaller.
- Shade/unshade doesn't seem to work anymore.
  From the window title bar context menu, it's no longer changeable at
  all.
  And the keyboard shortcut ("Toggle shaded state") no longer works
  properly. For me it does shade a window, but unshade simply doesn't
  happen anymore.
- Previously, when moving the mouse pointer to the top right corner 
  (assuming there was no top panel), then one was sure that a click at
  that position, would hit the close button of any maximised window.
  This was really quite nice, cause in practise one often works with
  maximised windows, and a fast move in the top right corner needs no
  exact positioning but enables one to quickly close a window.
  Now, the close button is much farther inwards and so one needs to
  exactly position the pointer on it, which takes noticeably longer.


Showstoppers, these seem small, but in day2day work they're really a
pain in the a***:
- There's barely any difference in colour between the window title bar
  of those which have the focus and those which have not. The one is
  some gray, the other some slightly brighter gray.
  Having e.g. multiple terminals open, makes it really hard to see
  which one has the focus, and I really don't want to pull out my
  colour spectrograph for that ;-)
- Windows no longer seem to have a borderline at all.
  This is especially annoying when one has e.g. multiple overlapping
  windows, and one has a hard time following lines in order find out to
  which window some part of them actually belongs.
  Just place a number of terminal windows in overlapping positions -
  without the border, it's much more difficult to see straight, which
  characters belong to which terminal.


Also, but possibly non-issues:
- the font seems to be different... not 100% sure about that one, maybe
  it's just misconception, but it seems somewhat slimmer



Previously existing issues:
- Similar to the colour of focused/unfocused window title bars, there's
  barely no difference in colour of the same for the panel's window
  list.
  The focused window is just slightly brighter and that even with a
  gradient.
- This used to work long ago, but stopped already previously:
  When I have e.g. a terminal window maximised, and move the mouse,
  pointer to the far left, click and select (i.e. I want to select
  whole lines), than this doesn't work.
  It seems like the left/rightmost pixel of the maximised window are
  not counted as part of that... and one has to move the pointer a tiny
  bit inwards in order to be able to select.


Not sure how especially the "showstoppers" could be fixed... I'd be
really surprised if others don't have problems with those changes... or
maybe after years of GNOMEing, they simply resigned.

I mean ten years ago, one could easily change themes, set custom
shortcuts in programs, etc. pp. ... and now one has less
customisability with every generation.

I found:
https://www.dedoimedo.com/computers/gnome-40-edit-theme.html

But haven't really tried yet... especially it seems hard to find out
*which* settings one has to actually change to get reasonable window
title bar colours... or window borders back - without breaking
everything else.


> 
> I think it would be great be able to bring many add/changes to
> upstream 
> of the forked software (as long as they accept them) and possibly
> also 
> optional feature (even if they were only or almost used by cinnamon, 
> mate or other forks) but I fear that this will be difficult :(
> 
> I also think would be great have on many softwares 2 "type of
> graphic" 
> (one default for gnome and one "traditional" for cinnamon mate and 

Bug#1008602: Thic client (X2Go) workaround

[Juri Grabowski]

Hello,

On Wed, Oct 26, 2022 at 09:14:53PM +, Mike Gabriel wrote:
> This is a known issue and should be amended on a system wide level and not
> per user (as you already recommended).
> See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008602
Here is possible workaroud for it:
https://bugzilla.redhat.com/show_bug.cgi?id=1954754#c2

To turn off globally (can be overridden by user), I created:
/etc/xdg/xfce4/xfconf/xfce-perchannel-xml/xfwm4.xml  with this added:




  

  


Best Regards,
Juri Grabowski

Bug#1022268: linux-image-5.10.0-19-amd64: Boot failure under xen as dom0

[Diederik de Haas]

Control: forcemerge -1 1022126

On woensdag 26 oktober 2022 18:18:28 CEST Daniel Smolik wrote:
> Hi, I  have normal boot with 5.10-18 see attached dmesg. And 2
> screenshots with boot failure under 5.10.-19.

I was pretty certain I had heard of such an issue before, but couldn't find it.
Until just now and it's the same issue as in 1022126, so merging the bugs.

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

Bug#1022854: debuerreotype: autopkgtest rebuilds with different toolchain and expects the same result

[Luca Boccassi]

Package: debuerreotype
Version: 0.15-1
Severity: important

It seems debuerreotype has an autopkgtest that rebuilds Stretch with a
new toolchain, compares it to a fixed version and fails if it doesn't
match. But I don't see how this can be supported - if the toolchain
changes, then the result is also not expected to be the same?
This is why for reproducible builds the toolchain is recorded in the buildenv?

This is going to block debootstrap's migration to testing, so I will
bump the severity soon if we can't find a workaround.

Example: 
https://ci.debian.net/data/autopkgtest/testing/amd64/d/debuerreotype/27484986/log.gz

Kind regards,
Luca Boccassi

Bug#1022853: ITP: golang-github-felixge-httpsnoop -- capture http related metrics from http.Handlers

[Thomas Goirand]

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

* Package name: golang-github-felixge-httpsnoop
  Version : 1.0.3
  Upstream Author : Felix Geisendörfer 
* URL : https://github.com/felixge/httpsnoop
* License : Expat
  Programming Lang: Golang
  Description : capture http related metrics from http.Handlers

 Httpsnoop provides an easy way to capture http related metrics (i.e. response
 time, bytes written, and http status code) from your application's
 http.Handlers.
 .
 Doing this requires non-trivial wrapping of the http.ResponseWriter interface,
 which is also exposed for users interested in a more low-level API.

Note: This is another indirect dependency of Etcd 3.5.5

Bug#1022275: Acknowledgement (nala: missing option "download only")

[mh]

Am Sun, 23 Oct 2022 12:27:04 +
schrieb "Debian Bug Tracking System" :

Hi, I need to change the "severity", it is not a wishbug but a bug.

There is a "-d" option, but it does not work (I am not the only to have
experieced it) whereas the long version "--download-only" works.

So This wishbug should be changed to whatever is appropriate.

Sorry for the confusion

MH


> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1022275:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022275.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Volian Developers 
>
> If you wish to submit further information on this problem, please
> send it to 1022...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>

Bug#1022147: Problem also with 149-2 and Kernel-Option amdgpu.dc=0

[debian]

We had have Problems with 5.10.0.19 (149-1) and all AMD-Computers with 
onboard graphics.


Update 149-2 had solved on most computers, but this computer has shows 
blankscreen a boot...


I have remove boot-option amdgpu.dc=1, since this change 149-2 works.

What has changed between 5.10.0.18 and 5.10.0.19-149-2 at usage of 
amdgpu.dc=0? Can anyone explain?


Here my lspci (stripped):

00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 
Root Complex

    Subsystem: ASUSTeK Computer Inc. PRIME B450M-A Motherboard
    Flags: fast devsel

00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
    Subsystem: ASUSTeK Computer Inc. PRIME B450M-A Motherboard
    Flags: bus master, fast devsel, latency 0, IRQ 25
    Capabilities: [40] Secure device 
    Capabilities: [64] MSI: Enable+ Count=1/4 Maskable- 64bit+
    Capabilities: [74] HyperTransport: MSI Mapping Enable+ Fixed+

00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
(rev 61)

    Subsystem: ASUSTeK Computer Inc. PRIME Motherboard
    Flags: 66MHz, medium devsel, IOMMU group 6
    Kernel driver in use: piix4_smbus
    Kernel modules: i2c_piix4, sp5100_tco

00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge 
(rev 51)

    Subsystem: ASUSTeK Computer Inc. PRIME B450M-A Motherboard
    Flags: bus master, 66MHz, medium devsel, latency 0, IOMMU group 6


01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. 
[AMD/ATI] Lexa PRO [Radeon 540/540X/550/550X / RX 540X/550/550X] (rev 
c7) (prog-if 00 [VGA controller])
    Subsystem: Hewlett-Packard Company Lexa PRO [Radeon 
540/540X/550/550X / RX 540X/550/550X]

    Flags: bus master, fast devsel, latency 0, IRQ 107, IOMMU group 8
    Memory at e000 (64-bit, prefetchable) [size=256M]
    Memory at f000 (64-bit, prefetchable) [size=2M]
    I/O ports at e000 [size=256]
    Memory at fcf0 (32-bit, non-prefetchable) [size=256K]
    Expansion ROM at fcf4 [disabled] [size=128K]
    Capabilities: [48] Vendor Specific Information: Len=08 
    Capabilities: [50] Power Management version 3
    Capabilities: [58] Express Legacy Endpoint, MSI 00
    Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
    Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 
Len=010 

    Capabilities: [150] Advanced Error Reporting
    Capabilities: [200] Physical Resizable BAR
    Capabilities: [270] Secondary PCI Express
    Capabilities: [2b0] Address Translation Service (ATS)
    Capabilities: [2c0] Page Request Interface (PRI)
    Capabilities: [2d0] Process Address Space ID (PASID)
    Capabilities: [320] Latency Tolerance Reporting
    Capabilities: [328] Alternative Routing-ID Interpretation (ARI)
    Capabilities: [370] L1 PM Substates
    Kernel driver in use: amdgpu
    Kernel modules: amdgpu

02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 300 Series 
Chipset USB 3.1 xHCI Controller (rev 02) (prog-if 30 [XHCI])
    Subsystem: ASMedia Technology Inc. 300 Series Chipset USB 3.1 xHCI 
Controller

    Flags: bus master, fast devsel, latency 0, IRQ 33, IOMMU group 9
    Memory at fcca (64-bit, non-prefetchable) [size=32K]
    Capabilities: [50] MSI: Enable- Count=1/8 Maskable- 64bit+
    Capabilities: [68] MSI-X: Enable+ Count=8 Masked-
    Capabilities: [78] Power Management version 3
    Capabilities: [80] Express Legacy Endpoint, MSI 00
    Capabilities: [100] Advanced Error Reporting
    Capabilities: [200] Secondary PCI Express
    Capabilities: [300] Latency Tolerance Reporting
    Capabilities: [400] L1 PM Substates
    Kernel driver in use: xhci_hcd
    Kernel modules: xhci_pci


CPU: AMD Ryzen 5 3400G with Radeon Vega Graphics
GPU: Radeon 540/540X/550/550X / RX 540X/550/550X


Thank you!

Bug#1022852: ITP: golang-github-aws-smithy-go -- Smithy code generators for Go

[Thomas Goirand]

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

* Package name: golang-github-aws-smithy-go
  Version : 1.13.3
  Upstream Author : 2020-2022, Amazon.com, Inc. or its affiliates.
* URL : https://github.com/aws/smithy-go
* License : Apache-2.0, BSD-3-clause
  Programming Lang: Golang
  Description : Smithy code generators for Go

 Smithy code generators for Go

Note: This is another new dependency for Etcd 3.5.5.

Bug#1022851: xorriso: -clone across sessions copies, not clones

[Ivan Shmakov]

Package: xorriso
Version: 1.5.4-4
Control: found -1 1.5.0-1
Control: found -1 1.5.2-1

When -clone is used on a file that belongs to the loaded
session, its contents get /copied/ to the new one (with the
location of the original one updated to match the copy);
while when used on a file /within/ the current session, the
resulting file (as expected) appears to share the extent
with the original one.

I believe that when it comes to rearranging data on ECMA 119
filesystems, it is as important for -clone /not/ to copy the
affected files’ contents as it is for, say, -move.

Consider, for instance, the following shell code.

#!/bin/sh

set -e
set -x
set -C -u

## NB: an arbitrary value, but must be larger than first session size
session_offset=256

f=$(mktemp -- /tmp/hello.X)
printf %s\\n "Hello, world!" >| "$f"

g=$(mktemp -- /tmp/iso.X)
xorriso -padding 0 -uid 0 -gid 0 \
-outdev stdio:/dev/fd/5 5>| "$g" \
-pathspecs on -add /hello/hello.world="$f" -- \
-clone /hello/hello.world /hello/hello.withn

h=$(mktemp -- /tmp/iso.X)
xorriso -padding 0 -uid 0 -gid 0 \
-indev  stdio:/dev/fd/4 4< "$g" \
-grow-blindly "$session_offset" \
-outdev stdio:/dev/fd/5 5>| "$h" \
-clone /hello/hello.world /hello/hello.clone
dd bs=2048 seek="$session_offset" conv=notrunc of="$g" < "$h"

isoinfo -l -i /dev/stdin < "$g"
isoinfo -l -T "$session_offset" -i /dev/stdin < "$g"

The resulting sessions are as follows.

+ isoinfo -l -i /dev/stdin

Directory listing of /
d-   0002048 Oct 26 2022 [ 18 02]  . 
d-   0002048 Oct 26 2022 [ 18 02]  .. 
d-   0002048 Oct 26 2022 [ 20 02]  HELLO 

Directory listing of /HELLO/
d-   0002048 Oct 26 2022 [ 20 02]  . 
d-   0002048 Oct 26 2022 [ 18 02]  .. 
--   000  14 Oct 26 2022 [ 33 00]  
HELLO.WITHN;1 
--   000  14 Oct 26 2022 [ 33 00]  
HELLO.WORLD;1 
+ isoinfo -l -T 256 -i /dev/stdin

Directory listing of /
d-   0002048 Oct 26 2022 [274 02]  . 
d-   0002048 Oct 26 2022 [274 02]  .. 
d-   0002048 Oct 26 2022 [276 02]  HELLO 

Directory listing of /HELLO/
d-   0002048 Oct 26 2022 [276 02]  . 
d-   0002048 Oct 26 2022 [274 02]  .. 
--   000  14 Oct 26 2022 [280 00]  
HELLO.CLONE;1 
--   000  14 Oct 26 2022 [280 00]  
HELLO.WITHN;1 
--   000  14 Oct 26 2022 [280 00]  
HELLO.WORLD;1 

Note that all three entries moved from LBA 33 to LBA 280.

Using two months old versions from Git (libburn 19545142,
libisoburn 3318fa47 and libisofs c6cb7dfa; the few changes
since these revisions made to the latter two don’t seem to
be relevant to the issue) gives the same result.

Omitting the -grow-blindly option (and using -dev stdio:"$h"
instead) doesn’t seem to change this behavior, either.

-- 
FSF associate member #7257  http://am-1.org/~ivan/

Bug#1019791: stimfit: Please transition to wxwidgets3.2

[Alois Schlögl]

In order to upgrade the dependency of stimfit to wxwidgets 3.2 the patch 
[1] should be sufficient.

However, I recommend to upgrade stimfit to tag v0.16.1debian [2].


Cheers,
   Alois


[1] 
https://github.com/neurodroid/stimfit/commit/a929d364c19195230e3b923726aef477479484a3

[2] https://github.com/neurodroid/stimfit/releases/tag/v0.16.1debian

Bug#1022847: atril requires libgs9 but ghostscript libgs10

[Mike Gabriel]

Control: close -1

Hi

On  Mi 26 Okt 2022 21:58:54 CEST, Сергей Фёдоров wrote:


Package: atril
Version: 1.26.0-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: serfyod...@yandex.ru

Dear Maintainer,

Problem: Installing the package "atril" 1.26.0-1 requires installing
the package libgs9, but installing the package "ghostscript" 10.0.0~dfsg-4
requires installing the package libgs10. Installing the libgs9 package
prohibits installing the libgs10 package.

Decision:
1, removed the package "atril" 1.26.0-1, removed the package libgs9.
2. installed the libgs10 package, installed the "ghostscript" package 10.0.0
3. downloaded from "github.com/mate-desktop/atril " the source code  
of "atril".

4. built and installed "atril"

Everything works: both "ghostscript" 10.0.0~dfsg-4 and "atril" 1.26.


Atril depend on libspectre1 and that library depends on libgs.

The ghostscript libraries are currently undergoing an auto-transition  
from libgs9 -> libgs10 in Debian unstable.

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

Please use Debian testing instead to avoid such errors on your system.  
As this is not a bug per se, but part of Debian's way to handle  
library transitions / SOVERSION changes, experiencing packages in  
broken dependency states is normal from time to time (for a couple of  
days, until all binNMUs have landed again or maintainers have fixed  
their packages).


Thus, closing this bug report. Please wait for the libgs transition to  
complete and then all should be good again.


Mike
--

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

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



pgpN82locg6Tj.pgp
Description: Digitale PGP-Signatur

Bug#1022850: ITP: node-openpgp-asmcrypto.js - Javascript cryptographic library with performance in mind

[Sandra Uwah]

Package: wnppX-Debbugs-Cc:debian-de...@lists.debian.org
Owner: Sandra Uwah 

X-Debbugs-Cc:sandrauwah...@gmail.com

Severity: wishlist

* Package name: node-openpgp-asmcrypto.js
  Version : 2.3.3~0
  Upstream Author : Adam Lippai
* URL :https://github.com/openpgpjs/asmcrypto.js
* License : MIT
  Programming Lang: Javascript
  Description : Javascript Cryptographic Library with performance in mind

Bug#1022730: [patch] opening chromium file chooser brings down xwayland+wayland compositor on etnaviv

[Johannes Schauer Marin Rodrigues]

Quoting Johannes Schauer Marin Rodrigues (2022-10-24 20:39:08)
> on the MNT Reform aarch64 laptop with etnaviv graphics, opening the
> chromium file chooser crashes Xwayland. I attached the gdb backtrace.
> The problem was fixed by Lucas Stach here:
> 
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19280
> 
> Please consider carrying that patch in the Debian mesa package.

the MR has now been merged into upstream main in this commit:

https://gitlab.freedesktop.org/mesa/mesa/-/commit/16e0702ec7103c06f2f33654b6e41498e2eabf8e

I filed a MR on salsa CI to carry that patch until the next mesa release
includes it:

https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/21

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Christoph Anton Mitterer]

Control: retitle -1 6.0.5 fixes critical btrfs bug in 6.0.3, affecting space 
cache v1 filesystems
Control: notfound -1 5.19.6-1
Control: found -1 6.0.3-1


No idea why reportbug picked 5.19.6, which I have not even installed
anymore... o.O

Bug#1022849: lightdm: Project migrated to new homepage

[Boyuan Yang]

Source: lightdm
Version: 1.26.0-8
Severity: normal
Tags: sid
X-Debbugs-CC: cor...@debian.org unit...@debian.org

Dear Debian lightdm package maintainers,

According to the old homepage https://launchpad.net/lightdm , "This project
now managed on GitHub: https://github.com/CanonicalLtd/lightdm ". Please
update the homepage information and uscan to the GitHub project.

Besides, I very much doubt the current decision of staying with
lightdm/1.26.0. I remember years ago when I requested upgrading lightdm in
Debian, someone told me that lightdm 1.26.x is a "stable release" so we
should stay with it. Unfortunately it is no longer the case today. As seen
in https://discourse.ubuntu.com/t/current-status-of-lightdm/29048/8 , the
lightdm upstream is no longer keeping so-called "stable branch". We really
should go with the latest release 1.32.0.

Best,
Boyuan Yang


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

Bug#1022848: linux: 6.0.5 fixes critical btrfs bug

[Christoph Anton Mitterer]

Source: linux
Version: 5.19.6-1
Severity: critical
Justification: breaks the whole system


Hi.

6.0.3 introduced a commit that causes (permanent) CPU soft lockups
for some people with btrfs filesystems, effectively breaking the
system, e.g. when booting.

See e.g.
https://lore.kernel.org/linux-btrfs/2291416ef48d98059f9fdc5d865b0ff040148237.ca...@scientia.org/T/#u
https://lore.kernel.org/linux-btrfs/1c531dd5de7477c8b6ec15d4aebb8e42ae460925.ca...@scientia.org/T/#t
https://lore.kernel.org/linux-btrfs/Y1krzbq3zdYOSQYG@bulldog/T/#u
https://lore.kernel.org/all/10522366-5c17-c18f-523c-b97c14969...@net4u.de/
https://bugs.archlinux.org/task/76266



6.0.5 is ought to fix that, could you please upgrade sid ASAP? :-)

See:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.0.5=217fd7557896d990c3dd8beea83a6feeb504f235


Thanks,
Chris.

Bug#1022787: libc6-dev: Lintian warns that all mips*el executables have executable stack

[Aurelien Jarno]

control: tag -1 + moreinfo

Hi,

On 2022-10-25 21:07, Simon McVittie wrote:
> Package: libc6-dev
> Version: 2.35-4
> Severity: normal
> X-Debbugs-Cc: debian-m...@lists.debian.org, lint...@packages.debian.org, 
> jrt...@debian.org
> User: debian-m...@lists.debian.org
> Usertags: mips mipsel
> 
> All mips*el executables and libraries appear to have an executable stack,
> resulting in very large numbers of Lintian warnings, particularly for
> packages with many small ELF objects like
> .
> 
> Jessica Clarke looked into this and found that this is intentionally done
> by glibc when targeting minimum kernel 4.8.0 or older with mips hardfloat:
> https://github.com/bminor/glibc/blob/595c22ecd8e87a27fd19270ed30fdbae9ad25426/sysdeps/unix/sysv/linux/mips/configure.ac#L138-L143
> 
> Debian 9 had a kernel newer than 4.8.0, so I think Debian 12 probably
> doesn't need to go that far into backwards compatibility? If the mips
> porters agree, then glibc on mips*el should stop forcing an executable
> stack, either by increasing the minimal kernel version or by patching
> this out. That will provide some security hardening on mips*el.

Note that the other official architecture still have a kernel
compatibility set to 3.2, so that will make a difference between
architectures. There are discussions to increase it upstream, but this
won't happened for bookworm. 

> Or, if the mips porters consider this backwards compatibility to be
> more important than the security hardening of a non-executable stack,
> then Lintian should stop issuing warnings about the executable stack on
> mips*el to improve its signal/noise ratio.

At this stage there is nothing that can be done on the glibc side, the
decision has to be taken by the mips porters.

Regards
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#1022146: diffoscope: detect ordering-only differences in XML files

[Chris Lamb]

tags 1022146 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/dbf5350fdacf5790ceab4f784ab8fc2f41cfa24c


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1022846: libunistring: update symbols for musl-any-any

[Helmut Grohne]

Source: libunistring
Version: 1.0-2
User: helm...@debian.org
Usertags: rebootstrap
Tags: patch

libunistring fails to build from source on musl-any-any, because symbols
differ from what is recorded. The check for rwlocks fails on musl and
thus libunistring ships its own replacement functions which add to
libunistring symbols. In that process,
libunistring_glthread_once_multithreaded disappears and makes the build
fail. I'm attaching a patch for your convenience.

Helmut
--- a/debian/libunistring2.symbols
+++ b/debian/libunistring2.symbols
@@ -162,10 +162,18 @@
  libunistring_gl_uninorm_decomp_chars_table@Base 0.9.7
  libunistring_gl_uninorm_decomp_index_table@Base 0.9.7
  libunistring_gl_uninorm_decompose_merge_sort_inplace@Base 0.9.7
- libunistring_glthread_once_multithreaded@Base 1.0
+ (arch=gnu-any-any)libunistring_glthread_once_multithreaded@Base 1.0
  libunistring_glthread_once_singlethreaded@Base 0.9.7
+ (arch=musl-any-any)libunistring_glthread_recursive_lock_destroy_multithreaded@Base 1.0-2
  libunistring_glthread_recursive_lock_init_multithreaded@Base 0.9.7
+ (arch=musl-any-any)libunistring_glthread_recursive_lock_lock_multithreaded@Base 1.0-2
+ (arch=musl-any-any)libunistring_glthread_recursive_lock_unlock_multithreaded@Base 1.0-2
+ (arch=musl-any-any)libunistring_glthread_rwlock_destroy_multithreaded@Base 1.0-2
  (arch=gnu-any-any)libunistring_glthread_rwlock_init_for_glibc@Base 0.9.8
+ (arch=musl-any-any)libunistring_glthread_rwlock_init_multithreaded@Base 1.0-2
+ (arch=musl-any-any)libunistring_glthread_rwlock_rdlock_multithreaded@Base 1.0-2
+ (arch=musl-any-any)libunistring_glthread_rwlock_unlock_multithreaded@Base 1.0-2
+ (arch=musl-any-any)libunistring_glthread_rwlock_wrlock_multithreaded@Base 1.0-2
  libunistring_hard_locale@Base 0.9.7
  libunistring_iconveh_close@Base 0.9.7
  libunistring_iconveh_open@Base 0.9.7

Bug#1022847: atril requires libgs9 but ghostscript libgs10

[Сергей Фёдоров]

Package: atril
Version: 1.26.0-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: serfyod...@yandex.ru

Dear Maintainer,

Problem: Installing the package "atril" 1.26.0-1 requires installing
the package libgs9, but installing the package "ghostscript" 10.0.0~dfsg-4
requires installing the package libgs10. Installing the libgs9 package
prohibits installing the libgs10 package.

Decision:
1, removed the package "atril" 1.26.0-1, removed the package libgs9.
2. installed the libgs10 package, installed the "ghostscript" package 10.0.0
3. downloaded from "github.com/mate-desktop/atril " the source code of "atril".
4. built and installed "atril"

Everything works: both "ghostscript" 10.0.0~dfsg-4 and "atril" 1.26.

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

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

Versions of packages atril depends on:
ii  atril-common 1.26.0-1
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libatk1.0-0  2.46.0-3
pn  libatrildocument3
pn  libatrilview3
ii  libc62.35-4
ii  libcaja-extension1   1.26.1-1
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libglib2.0-0 2.74.1-1
ii  libgtk-3-0   3.24.34-3
ii  libice6  2:1.0.10-1
ii  libsecret-1-00.20.5-3
ii  libsm6   2:1.2.3-1
ii  libxml2  2.9.14+dfsg-1+b1
ii  shared-mime-info 2.2-1

Versions of packages atril recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.14.4-1
ii  gvfs  1.50.2-2

Versions of packages atril suggests:
pn  caja  
ii  poppler-data  0.4.11-1
pn  unrar 

Bug#1022845: ITP: super-speedy-syslog-searcher -- Speedily search and merge log file entries by datetime

[James Thomas Moon]

Package: wnpp
Severity: wishlist
Owner: James Thomas Moon 

* Package name: super-speedy-syslog-searcher
  Version : 0.1.39
  Upstream Author : James Thomas Moon 

* URL : https://crates.io/crates/super-speedy-syslog-searcher
* License : MIT
  Programming Lang: Rust
  Description : Speedily search and merge log file entries by datetime

Super Speedy Syslog Searcher (s4) is a command-line tool to search and merge 
plain log files by datetime, including log compressed log files (.gz, .xz) and 
within archives (.tar). The first goal of s4 is speedy searching and printing.

Why is this package relevant? Simple and fast tool for reviewing large amounts 
of log files, in a datetime-oriented manner. A common activity for Power Users 
and Engineers.

Is this a dependency for another package? No

Do you use it? Yes, on all my local Linux and Windows machines.

Do other packages provide functionality? No.

How do you plan to maintain it? At minimum, ongoing watchful eye of Rust 
dependency changes. I setup a github dependabot alerts for needed fixes.
    I have created several Enhancement Issues at the project page. If this tool 
proves useful to anyone, then I may implement some Enhancements.
    However, I am new to packaging Debian packages. Not sure if I'll need an 
assist from an expert.

Are you looking for co-maintainer? No. I imagine once I get the hang of package 
maintanence, I'll be able to handle it on my own.

Bug#1022145: diffoscope: detect ordering-only differences in text files

[Chris Lamb]

tags 1022145 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/727b3c9ea54b89465d2308997aa8b4bd25bff07f


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#1022797: librocm-smi-dev: find_package(rocm_smi) fails due to missing liboam

[Cordell Bloor]

Hi Étienne,

On 2022-10-26 12:44, Étienne Mollier wrote:

I'm not too sure yet of the implementation to not export the oam
target; this looks to have been autogenerated by cmake.  About
the dependency, I'm thinking twice before making that a hard
one, since it is possible to make use of the headers without
pulling the oam, at least from my quick test.

What do you think about simply recommending the installation?


I think recommending the package makes sense, as upstream seems to 
install them together. That's a good start, but I think we can do more 
than that.


The oam target code is generated by CMake, but it appears to be exported 
by this line here: 
https://github.com/RadeonOpenCompute/rocm_smi_lib/blob/rocm-5.3.0/CMakeLists.txt#L183


(Incidentally, "rcom_smi_target.cmake" looks like a typo.)

I think we could probably create a patch that splits the rocm_smi and 
oam CMake config files. We'd remove oam from the rocm_smi exported 
targets and create an oam-config.cmake file, so it could be exported as 
its own thing. find_package(oam) would then be used to get the oam target.


To make Debian's behaviour compatible with upstream when both libraries 
are installed, we could modify the rocm_smi-config.cmake template 
(rocm_smi-config.cmake.in), so that find_package(rocm_smi) does a 
find_package(oam QUIET).


And maybe try to upstream the split?

Sincerely,
Cory Bloor

Bug#972078: sound-juicer: diff for NMU version 3.38.0-2.1

[Philip Rinn]

Hi Jeremy,

Thanks, done.

Not sure if it's helpfull, but I opend a MR on salsa with the NMU changes: 
https://salsa.debian.org/gnome-team/sound-juicer/-/merge_requests/2


Best,
Philip


Am 26.10.22 um 21:18 schrieb Jeremy Bicha:

Feel free to upload this without delay.

On behalf of the Debian GNOME team,
Jeremy Bicha

On Wed, Oct 26, 2022, 21:12 Philip Rinn > wrote:


Control: tags 972078 + pending


Dear maintainer,

I've prepared an NMU for sound-juicer (versioned as 3.38.0-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

(The change in Uploaders somehow happened automatically during the gbp
buildpackage run, not sure why.)

Best,
Philip


diff -Nru sound-juicer-3.38.0/debian/changelog
sound-juicer-3.38.0/debian/changelog
--- sound-juicer-3.38.0/debian/changelog        2022-02-18
22:16:14.0 +0100
+++ sound-juicer-3.38.0/debian/changelog        2022-10-26
20:58:46.0 +0200
@@ -1,3 +1,12 @@
+sound-juicer (3.38.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make build reproducible: Replace absolute path to source location of
+    data/rhythmbox.gep embedded in binary with relative path. It would 
never
+    resolve and is not necassary in an end-user installation (Closes: 
#972078)
+
+ -- Philip Rinn mailto:ri...@debian.org>>  Wed, 26 Oct
2022 20:58:46 +0200
+
  sound-juicer (3.38.0-2) unstable; urgency=medium

    * Drop unneeded -Wl,--as-needed and -Wno-unused-parameter
diff -Nru sound-juicer-3.38.0/debian/control 
sound-juicer-3.38.0/debian/control
--- sound-juicer-3.38.0/debian/control  2022-02-18 22:16:14.0 +0100
+++ sound-juicer-3.38.0/debian/control  2022-10-26 20:58:46.0 +0200
@@ -6,7 +6,7 @@
  Section: sound
  Priority: optional
  Maintainer: Debian GNOME Maintainers
mailto:pkg-gnome-maintain...@lists.alioth.debian.org>>
-Uploaders: Jeremy Bicha mailto:jbi...@debian.org>>,
Laurent Bigonville mailto:bi...@debian.org>>, Michael
Biebl mailto:bi...@debian.org>>
+Uploaders: Laurent Bigonville mailto:bi...@debian.org>>,
Michael Biebl mailto:bi...@debian.org>>
  Build-Depends: debhelper-compat (= 13),
                 appstream,
                 appstream-util ,
diff -Nru sound-juicer-3.38.0/debian/patches/reproducible-build.patch
sound-juicer-3.38.0/debian/patches/reproducible-build.patch
--- sound-juicer-3.38.0/debian/patches/reproducible-build.patch 1970-01-01
01:00:00.0 +0100
+++ sound-juicer-3.38.0/debian/patches/reproducible-build.patch 2022-10-26
18:01:17.0 +0200
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb mailto:la...@debian.org>>
+Last-Update: 2020-10-12
+
+--- sound-juicer-3.38.0.orig/libjuicer/rb-gst-media-types.c
 sound-juicer-3.38.0/libjuicer/rb-gst-media-types.c
+@@ -34,7 +34,7 @@
+
+ #include "rb-gst-media-types.h"
+
+-#define SOURCE_ENCODING_TARGET_FILE TOPSRCDIR"/data/rhythmbox.gep"
++#define SOURCE_ENCODING_TARGET_FILE "./data/rhythmbox.gep"
+ #define INSTALLED_ENCODING_TARGET_FILE 
DATADIR"/sound-juicer/rhythmbox.gep"
+ static GstEncodingTarget *default_target = NULL;
+
diff -Nru sound-juicer-3.38.0/debian/patches/series
sound-juicer-3.38.0/debian/patches/series
--- sound-juicer-3.38.0/debian/patches/series   2022-02-18
22:16:14.0 +0100
+++ sound-juicer-3.38.0/debian/patches/series   2022-10-26
18:01:37.0 +0200
@@ -2,3 +2,4 @@
  Fix-showing-icon-in-the-about-dialog.patch
  build-fix-doc-directory.patch
  meson-drop-unused-argument-for-i18n.merge_file.patch
+reproducible-build.patch





OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022804: azure-cli: terraform fails due to azure-cli error: unexpected keyword argument 'allow_broker'

[Luca Boccassi]

Control: reassign -1 python3-msal 1.18.0b1-1
Control: close -1 1.20.0-1

On Wed, 26 Oct 2022 12:22:52 +0200 Dominique Dumont 
wrote:
> Package: azure-cli
> Version: 2.41.0-1
> Severity: normal
> 
> Dear Maintainer,
> 
> With Debian's azure-cli, terraform authentication fails with the
> following error:
> 
> $ terraform apply 
> ╷
> │ Error: obtaining Authorization Token from the Azure CLI: parsing
json result from the Azure CLI: waiting for the Azure CLI: exit status
1: ERROR: The command failed with an unexpected error. Here is the
traceback:
> │ ERROR: ClientApplication.__init__() got an unexpected keyword
argument 'allow_broker'
> │ Traceback (most recent call last):
> │   File "/usr/lib/python3/dist-packages/knack/cli.py", line 233, in
invoke
> │ cmd_result = self.invocation.execute(args)
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 663, in execute
> │ raise ex
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 726, in
_run_jobs_serially
> │ results.append(self._run_job(expanded_arg, cmd_copy))
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 697, in _run_job
> │ result = cmd_copy(params)
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/__init__.py", line 333, in __call__
> │ return self.handler(*args, **kwargs)
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/commands/command_operation.py", line 121, in
handler
> │ return op(**command_args)
> │   File "/usr/lib/python3/dist-
packages/azure/cli/command_modules/profile/custom.py", line 66, in
get_access_token
> │ creds, subscription, tenant =
profile.get_raw_token(subscription=subscription, resource=resource,
scopes=scopes,
> │   File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py",
line 382, in get_raw_token
> │ credential = self._create_credential(account, tenant)
> │   File "/usr/lib/python3/dist-packages/azure/cli/core/_profile.py",
line 592, in _create_credential
> │ return identity.get_user_credential(username_or_sp_id)
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/auth/identity.py", line 224, in
get_user_credential
> │ return UserCredential(self.client_id, username,
**self._msal_app_kwargs)
> │   File "/usr/lib/python3/dist-
packages/azure/cli/core/auth/msal_authentication.py", line 39, in
__init__
> │ super().__init__(client_id, **kwargs)
> │   File "/usr/lib/python3/dist-packages/msal/application.py", line
1525, in __init__
> │ super(PublicClientApplication, self).__init__(
> │ TypeError: ClientApplication.__init__() got an unexpected keyword
argument 'allow_broker'
> │ To open an issue, please run: 'az feedback'

Check that you have the latest python3-msal (not yet migrated to
testing).

-- 
Kind regards,
Luca Boccassi


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

Bug#1022170: Excessive network latency with PREEMPT_RT

[Bernhard Übelacker]

Control: reassign -1 src:linux


On Fri, 21 Oct 2022 21:40:23 +1000 Rod Webster  wrote:

Package: PREEMPT_RT
Version: 5.10 to 6.0



I hope it is right to reassign to src:linux because it looks
like there is no package PREEMPT_RT.

Kind regards,
Bernhard

Bug#972078: sound-juicer: diff for NMU version 3.38.0-2.1

[Jeremy Bicha]

Feel free to upload this without delay.

On behalf of the Debian GNOME team,
Jeremy Bicha

On Wed, Oct 26, 2022, 21:12 Philip Rinn  wrote:

> Control: tags 972078 + pending
>
>
> Dear maintainer,
>
> I've prepared an NMU for sound-juicer (versioned as 3.38.0-2.1) and
> uploaded it to DELAYED/14. Please feel free to tell me if I
> should delay it longer.
>
> (The change in Uploaders somehow happened automatically during the gbp
> buildpackage run, not sure why.)
>
> Best,
> Philip
>
>
> diff -Nru sound-juicer-3.38.0/debian/changelog
> sound-juicer-3.38.0/debian/changelog
> --- sound-juicer-3.38.0/debian/changelog2022-02-18
> 22:16:14.0 +0100
> +++ sound-juicer-3.38.0/debian/changelog2022-10-26
> 20:58:46.0 +0200
> @@ -1,3 +1,12 @@
> +sound-juicer (3.38.0-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Make build reproducible: Replace absolute path to source location of
> +data/rhythmbox.gep embedded in binary with relative path. It would
> never
> +resolve and is not necassary in an end-user installation (Closes:
> #972078)
> +
> + -- Philip Rinn   Wed, 26 Oct 2022 20:58:46 +0200
> +
>  sound-juicer (3.38.0-2) unstable; urgency=medium
>
>* Drop unneeded -Wl,--as-needed and -Wno-unused-parameter
> diff -Nru sound-juicer-3.38.0/debian/control
> sound-juicer-3.38.0/debian/control
> --- sound-juicer-3.38.0/debian/control  2022-02-18 22:16:14.0 +0100
> +++ sound-juicer-3.38.0/debian/control  2022-10-26 20:58:46.0 +0200
> @@ -6,7 +6,7 @@
>  Section: sound
>  Priority: optional
>  Maintainer: Debian GNOME Maintainers <
> pkg-gnome-maintain...@lists.alioth.debian.org>
> -Uploaders: Jeremy Bicha , Laurent Bigonville <
> bi...@debian.org>, Michael Biebl 
> +Uploaders: Laurent Bigonville , Michael Biebl <
> bi...@debian.org>
>  Build-Depends: debhelper-compat (= 13),
> appstream,
> appstream-util ,
> diff -Nru sound-juicer-3.38.0/debian/patches/reproducible-build.patch
> sound-juicer-3.38.0/debian/patches/reproducible-build.patch
> --- sound-juicer-3.38.0/debian/patches/reproducible-build.patch 1970-01-01
> 01:00:00.0 +0100
> +++ sound-juicer-3.38.0/debian/patches/reproducible-build.patch 2022-10-26
> 18:01:17.0 +0200
> @@ -0,0 +1,15 @@
> +Description: Make the build reproducible
> +Author: Chris Lamb 
> +Last-Update: 2020-10-12
> +
> +--- sound-juicer-3.38.0.orig/libjuicer/rb-gst-media-types.c
>  sound-juicer-3.38.0/libjuicer/rb-gst-media-types.c
> +@@ -34,7 +34,7 @@
> +
> + #include "rb-gst-media-types.h"
> +
> +-#define SOURCE_ENCODING_TARGET_FILE TOPSRCDIR"/data/rhythmbox.gep"
> ++#define SOURCE_ENCODING_TARGET_FILE "./data/rhythmbox.gep"
> + #define INSTALLED_ENCODING_TARGET_FILE
> DATADIR"/sound-juicer/rhythmbox.gep"
> + static GstEncodingTarget *default_target = NULL;
> +
> diff -Nru sound-juicer-3.38.0/debian/patches/series
> sound-juicer-3.38.0/debian/patches/series
> --- sound-juicer-3.38.0/debian/patches/series   2022-02-18
> 22:16:14.0 +0100
> +++ sound-juicer-3.38.0/debian/patches/series   2022-10-26
> 18:01:37.0 +0200
> @@ -2,3 +2,4 @@
>  Fix-showing-icon-in-the-about-dialog.patch
>  build-fix-doc-directory.patch
>  meson-drop-unused-argument-for-i18n.merge_file.patch
> +reproducible-build.patch
>
>

Bug#972078: sound-juicer: diff for NMU version 3.38.0-2.1

[Philip Rinn]

Control: tags 972078 + pending


Dear maintainer,

I've prepared an NMU for sound-juicer (versioned as 3.38.0-2.1) and
uploaded it to DELAYED/14. Please feel free to tell me if I
should delay it longer.

(The change in Uploaders somehow happened automatically during the gbp 
buildpackage run, not sure why.)

Best,
Philip


diff -Nru sound-juicer-3.38.0/debian/changelog 
sound-juicer-3.38.0/debian/changelog
--- sound-juicer-3.38.0/debian/changelog2022-02-18 22:16:14.0 
+0100
+++ sound-juicer-3.38.0/debian/changelog2022-10-26 20:58:46.0 
+0200
@@ -1,3 +1,12 @@
+sound-juicer (3.38.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Make build reproducible: Replace absolute path to source location of
+data/rhythmbox.gep embedded in binary with relative path. It would never
+resolve and is not necassary in an end-user installation (Closes: #972078)
+
+ -- Philip Rinn   Wed, 26 Oct 2022 20:58:46 +0200
+
 sound-juicer (3.38.0-2) unstable; urgency=medium
 
   * Drop unneeded -Wl,--as-needed and -Wno-unused-parameter
diff -Nru sound-juicer-3.38.0/debian/control sound-juicer-3.38.0/debian/control
--- sound-juicer-3.38.0/debian/control  2022-02-18 22:16:14.0 +0100
+++ sound-juicer-3.38.0/debian/control  2022-10-26 20:58:46.0 +0200
@@ -6,7 +6,7 @@
 Section: sound
 Priority: optional
 Maintainer: Debian GNOME Maintainers 

-Uploaders: Jeremy Bicha , Laurent Bigonville 
, Michael Biebl 
+Uploaders: Laurent Bigonville , Michael Biebl 

 Build-Depends: debhelper-compat (= 13),
appstream,
appstream-util ,
diff -Nru sound-juicer-3.38.0/debian/patches/reproducible-build.patch 
sound-juicer-3.38.0/debian/patches/reproducible-build.patch
--- sound-juicer-3.38.0/debian/patches/reproducible-build.patch 1970-01-01 
01:00:00.0 +0100
+++ sound-juicer-3.38.0/debian/patches/reproducible-build.patch 2022-10-26 
18:01:17.0 +0200
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2020-10-12
+
+--- sound-juicer-3.38.0.orig/libjuicer/rb-gst-media-types.c
 sound-juicer-3.38.0/libjuicer/rb-gst-media-types.c
+@@ -34,7 +34,7 @@
+ 
+ #include "rb-gst-media-types.h"
+ 
+-#define SOURCE_ENCODING_TARGET_FILE TOPSRCDIR"/data/rhythmbox.gep"
++#define SOURCE_ENCODING_TARGET_FILE "./data/rhythmbox.gep"
+ #define INSTALLED_ENCODING_TARGET_FILE DATADIR"/sound-juicer/rhythmbox.gep"
+ static GstEncodingTarget *default_target = NULL;
+ 
diff -Nru sound-juicer-3.38.0/debian/patches/series 
sound-juicer-3.38.0/debian/patches/series
--- sound-juicer-3.38.0/debian/patches/series   2022-02-18 22:16:14.0 
+0100
+++ sound-juicer-3.38.0/debian/patches/series   2022-10-26 18:01:37.0 
+0200
@@ -2,3 +2,4 @@
 Fix-showing-icon-in-the-about-dialog.patch
 build-fix-doc-directory.patch
 meson-drop-unused-argument-for-i18n.merge_file.patch
+reproducible-build.patch

Bug#1022843: ifupdown: network down after systemctl restart

[Oleg A. Arkhangelsky]

Package: ifupdown
Version: 0.8.36
Severity: important
X-Debbugs-Cc: syso...@yandex.ru

Hello!

(Not sure why such rather important issue is not filled yet, but anyway. Sorry 
if I'm creating duplicate.)

My network is down after running `systemctl restart networking` on fresh 
installed Debian 11.5 (but the same issue is on Debian 10). There is no way to 
start it with `systemctl start networking`. Not sure if this relevant but I'm 
using static IPv4 config, no DHCP. The installation is very minimal without any 
systemd-networkd or NetworkManager stuff.

The reason for this is that systemd unit file networking.service using `ifdown 
-a` to stop network and then `ifup -a` to start it. According to the manual, 
the first command unconditionally deconfigure _all_ interfaces defined in 
/etc/network/interfaces, but the second one configure only interfaces which is 
defined as "auto" in the configuraton and not as "allow-hotplug".

During the installation all interfaces (fixed PCI NICs too, because udev events 
generated for PCI devices too [1]) in /etc/network/interfaces is created with 
"allow-hotplug", so restarting networking with systemd leads to non-functional 
network.

When using old-school `/etc/init.d/networking restart` (don't forget to set 
SYSTEMCTL_SKIP_REDIRECT=1) the issue is not present. This is because of special 
treatment for "allow-hotplug" interfaces in /etc/init.d/networking. See 
ifup_hotplug () function. The functionality is lacking in systemd unit file.

Forgot to mention that the network starting normally during the system startup. 
This is because of ifup@.service template unit which is started from udev rule 
via /lib/udev/ifupdown-hotplug script which runs unit for specific interface. 
This leads to running `ifup eth0`. When you run ifup this way, there is no need 
to define interface as "auto".

Yes, everything can be fixed using "auto" instead of "allow-hotplug", but 
"allow-hotplug" is set by Debian Installer [2]. This leads to the issue just 
"by default".

Should we sync systemd unit file behaviour with old SysV script by implementing 
something like ifup_hotplug() logic in unit file? Network must not be broken 
after silly systemctl restart.

[1] 
https://salsa.debian.org/installer-team/hw-detect/-/blob/master/net-hotplug.sh
[2] 
https://salsa.debian.org/installer-team/netcfg/-/blob/master/write_interface.c


-- Package-specific info:
--- /etc/network/interfaces:
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*

allow-hotplug eth0
iface eth0 inet static
address 172.17.0.3
netmask 255.255.0.0
gateway 172.17.0.1

--- /etc/network/interfaces.d/*:
cat: '/etc/network/interfaces.d/*': No such file or directory

--- up and down scripts installed:
/etc/network/if-down.d:
total 0

/etc/network/if-post-down.d:
total 0

/etc/network/if-pre-up.d:
total 0

/etc/network/if-up.d:
total 0


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

Kernel: Linux 5.12.2 (SMP w/1 CPU thread)
Kernel taint flags: TAINT_FORCED_MODULE, TAINT_WARN, 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 ifupdown depends on:
ii  adduser   3.118
ii  iproute2  5.10.0-4
ii  libc6 2.31-13+deb11u5
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.3+deb11u1

Versions of packages ifupdown suggests:
pn  ppp 
pn  rdnssd  

-- no debconf information

Bug#1022028: jhead: CVE-2022-41751

[Joachim Reichel]

found 1022028 1:3.00-8
thanks

The bugs exist probably since the features were added a long time ago. Let's use 
the current oldstable version for tracking purposes.

Bug#1022842: libghc-dice-doc: depends on non-existing haddock-interface-35

[Ralf Treinen]

Package: libghc-dice-doc
Version: 0.1.0.1-1
Severity: serious

Hi, libghc-dice-doc depends on haddock-interface-35 but that package
does not exist in the archive.

-Ralf.

Bug#1022797: librocm-smi-dev: find_package(rocm_smi) fails due to missing liboam

[Étienne Mollier]

Hi Cory,

Cordell Bloor, on 2022-10-26:
> As a workaround, I added liboam-dev directly to the rccl build-depends
> and installed the package manually. This resolved the problem. However,
> it seems to me that either rocm_smi should not be exporting the oam
> target or librocm-smi-dev should depend on liboam-dev. I'm not sure
> which option would be better.

I'm not too sure yet of the implementation to not export the oam
target; this looks to have been autogenerated by cmake.  About
the dependency, I'm thinking twice before making that a hard
one, since it is possible to make use of the headers without
pulling the oam, at least from my quick test.

What do you think about simply recommending the installation?

It would be installed by regular users, and the ones who know
what they are doing can always remove, or install with option
--no-recommends, if that suite their needs.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/4, please excuse my verbosity.
On air: Art Of Illusion - Devious Savior


signature.asc
Description: PGP signature

Bug#1022841: libghc-lambdabot-core-doc: unsatisfiable sdependency on haddock-interface-35

[Ralf Treinen]

Package: libghc-lambdabot-core-doc
Version: 5.3.0.1-1
Severity: serious

Hi, libghc-lambdabot-core-doc depends on haddock-interface-35 but that
package does not exist in the archive.

-Ralf

Bug#692995: reportbug: unblock requests: set affects src:$PACKAGE and Cc: $PACKAGE@packages.d.o

[Paul Gevers]

Hi,

On 26-10-2022 08:36, Paul Wise wrote:

In Debian bug #692995 it was proposed to set affects src:$PACKAGE
and XCC $PACKAGE@packages.d.o for release.d.o unblock bugs.

The reportbug team requested that the release team be contacted to find
out if they are OK with this change in reportbug behaviour.

In addition, I had prepared a patch doing this for all release.d.o
bugs, before I saw this existing unblock requests bug report and patch.

This would help maintainers and people reading the bugs web pages find
out about the unblock and other requests.

Would this be acceptable to you?


I think it's fine.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022779: dosbox: could dosbox-x be a future to dosbox?

[Patrice]

So nice!

Do you know this one https://github.com/dosbox-staging/dosbox-staging ?
I found some packagings on Salsa like:
https://salsa.debian.org/okias/dosbox-staging
but it remained at the version 0.76.0 and now the upstream is 0.79.1.
I haven't tried it yet.

Best,
Patrice

On Wed, 26 Oct 2022 11:59:29 +0200 Stephen Kitt  wrote:
> Hi Patrice,
> 
> Le 25/10/2022 19:55, Patrice Duroux a écrit :
> > The dosbox-x project (https://dosbox-x.com/) is currently version 
> > 0.84.3
> > (2022.09.0)
> > and seems to be SDL 2 compatible.
> > Have you tried it?
> 
> I have, and I’m actually working on packaging it. I’ve just filed an ITP 
> to trace that fact, https://bugs.debian.org/1022800
> 
> Regards,
> 
> Stephen
> 
> 

Bug#962956: reniced: diff for NMU version 1.21-1.2

[Christian Garbs]

On Sat, Oct 15, 2022 at 12:32:55PM +0300, Adrian Bunk wrote:

> I've prepared an NMU for reniced (versioned as 1.21-1.2) and uploaded
> it to DELAYED/2. Please feel free to tell me if I should cancel it.

Dear Adrian,

I really appreciate your NMU.

I neither had the time nor the endurance to look for a sponsor to
update the package, so I did not get further than fixing the upstream
repository.

Thanks a lot for the updated package!
Christian
-- 
Christian.Garbshttps://www.cgarbs.de

/"\
\ /  ASCII Ribbon Campaign - Say NO to HTML in email and news
 X Sag NEIN zu HTML in email und news
/ \

Bug#1022840: yubikey-agent: keys are not added to the agent

[Markus Grunwald]

Package: yubikey-agent
Version: 0.1.4-2+b3
Severity: important

Dear Maintainer,

When using a YubiKey 5C Nano, ssh keys are not added to the 
yubikey-agent. Instead, these errors occur:



From ssh - :
debug1: could not add identity to agent: 
/home/markus/.ssh/id_ed25519_sk (-27)



From systemctl --user status yubikey-agent:


Okt 26 19:44:46 bob systemd[2117]: Started Seamless ssh-agent for 
YubiKeys.
Okt 26 19:45:04 bob yubikey-agent[20944]: 2022/10/26 19:45:04 
Connecting to the YubiKey...
Okt 26 19:45:04 bob yubikey-agent[20944]: 2022/10/26 19:45:04 
agent 11: could not get public key: command failed: smart card 
error 6a82: data object or application not found
Okt 26 19:45:11 bob yubikey-agent[20944]: 2022/10/26 19:45:11 
agent 25: agent: not implemented: "sk-ssh-ed25...@openssh.com"


I would habe expected that the key is added to ssh agent and I 
don't have to enter the passphrase again.



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

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

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

Versions of packages yubikey-agent depends on:
ii  init-system-helpers  1.65.2
ii  libc62.35-3
ii  libpcsclite1 1.9.9-1

yubikey-agent recommends no packages.

yubikey-agent suggests no packages.

-- no debconf information

--
Markus Grunwald
https://www.the-grue.de/~markus/markus_grunwald.gpg

Bug#1022839: yubikey-agent: manpage contains wrong commands

[Markus Grunwald]

Package: yubikey-agent
Version: 0.1.4-2+b3
Severity: normal

Dear Maintainer,

The manpage for yubikey-agent mentions these two commands:

systemctl --user enable yubikey-service.user
systemctl --user start yubikey-service.user

Both are wrong and should read:

systemctl --user enable yubikey-agent.service
systemctl --user start yubikey-agent.service


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

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

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

Versions of packages yubikey-agent depends on:
ii  init-system-helpers  1.65.2
ii  libc62.35-3
ii  libpcsclite1 1.9.9-1

yubikey-agent recommends no packages.

yubikey-agent suggests no packages.

-- no debconf information

Bug#1021658: Processed: autopkgtest regressions are RC (and this one also blocks the perl transition)

[Hilmar Preuße]

Am 24.10.2022 um 19:48 teilte Paul Gevers mit:

Hi all,

I think Hilmar was afraid of what happens after latexml is removed from 
testing. Than TL migrates and breaks latexml for users of testing that 
don't immediately remove packages that are no longer in testing.




Yes, correct.

The idea to add a breaks into texlive-latex-base sounds reasonable to me 
and I'll introduce it.


Meanwhile latexml upstream has provided a patch for the issue. I did not 
test it, but they have their own test beds and it looks good so far. Not 
sure when I'll find time to upload new packages.


Hilmar
--
sigfault



OpenPGP_signature
Description: OpenPGP digital signature

Bug#969609: rust-zstd: unbuildable, uninstallable, depends on non-existent rust-zstd-safe

[Blair Noctis]

Hi,

rust-zstd-sys 2.0.1 has been ACCEPTED, rust-zstd-safe 5.0.2 is in NEW. rust-zstd
should follow.

-- 
Sdrager,
Blair Noctis


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1022825: libyaml-dev: Include yamlConfig.cmake

[Bastian Germann]

Am 26.10.22 um 18:30 schrieb Florian Ernst:

However, the yamlConfig.cmake.in appears simple enough as it is. Is
there an easy way to generate a fully compliant yamlConfig.cmake from it
without changing build systems?


I do not know. I had not checked the used build system on requesting this.
Please feel free to close the bug. But keep it in mind if there is a time that 
you switch to cmake.

Bug#1020691: debos should depend on systemd-resolved

[Christopher Obbard]

On Tue, 2022-10-25 at 07:47 +0700, Arnaud Rebillout wrote:
> On 24/10/2022 21:55, Christopher Obbard wrote:
> > I'm more leaning on just adding it as a direct Dependency to the
> > Debos
> > package and seeing if anyone moans...
> Works for me.

Seems installing systemd-resolved breaks the autopkgtest test runner,
at least in a local qemu instance :-).

For now I will leave it as a Recommends.

Bug#1022838: linux-image-5.10.0-19-amd64: kernel gets tainted when running a defective raid0 that is connected by USB3.0 with UASP

[bsegui]

Package: src:linux
Version: 5.10.149-2
Severity: important
Tags: upstream




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

[  166.804963] md0: detected capacity change from 0 to 12001828929536
[  272.116656] sd 3:0:0:0: [sdb] tag#29 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=6s
[  272.116900] sd 3:0:0:0: [sdb] tag#29 Sense Key : Hardware Error [current]
[  272.117070] sd 3:0:0:0: [sdb] tag#29 Add. Sense: Internal target failure
[  272.117189] sd 3:0:0:0: [sdb] tag#29 CDB: Read(16) 88 00 00 00 00 01 42 f4 
08 00 00 00 00 08 00 00
[  272.117346] blk_update_request: critical target error, dev sdb, sector 
5418256384 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.117665] sd 3:0:0:0: [sdb] tag#2 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=6s
[  272.117743] sd 3:0:0:0: [sdb] tag#2 Sense Key : Hardware Error [current]
[  272.117796] sd 3:0:0:0: [sdb] tag#2 Add. Sense: Internal target failure
[  272.117904] sd 3:0:0:0: [sdb] tag#2 CDB: Read(16) 88 00 00 00 00 01 43 54 08 
00 00 00 00 08 00 00
[  272.118052] blk_update_request: critical target error, dev sdb, sector 
5424547840 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.118246] sd 3:0:0:0: [sdb] tag#17 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=6s
[  272.118392] sd 3:0:0:0: [sdb] tag#17 Sense Key : Hardware Error [current]
[  272.118503] sd 3:0:0:0: [sdb] tag#17 Add. Sense: Internal target failure
[  272.118610] sd 3:0:0:0: [sdb] tag#17 CDB: Read(16) 88 00 00 00 00 01 43 64 
08 00 00 00 00 08 00 00
[  272.118757] blk_update_request: critical target error, dev sdb, sector 
5425596416 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.118952] sd 3:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=5s
[  272.119096] sd 3:0:0:0: [sdb] tag#0 Sense Key : Hardware Error [current]
[  272.119213] sd 3:0:0:0: [sdb] tag#0 Add. Sense: Internal target failure
[  272.119330] sd 3:0:0:0: [sdb] tag#0 CDB: Read(16) 88 00 00 00 00 01 43 d4 08 
00 00 00 00 08 00 00
[  272.119442] blk_update_request: critical target error, dev sdb, sector 
5432936448 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.119609] sd 3:0:0:0: [sdb] tag#8 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=5s
[  272.119743] sd 3:0:0:0: [sdb] tag#8 Sense Key : Hardware Error [current]
[  272.119837] sd 3:0:0:0: [sdb] tag#8 Add. Sense: Internal target failure
[  272.119928] sd 3:0:0:0: [sdb] tag#8 CDB: Read(16) 88 00 00 00 00 01 43 f4 08 
00 00 00 00 08 00 00
[  272.120044] blk_update_request: critical target error, dev sdb, sector 
5435033600 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.120251] sd 3:0:0:0: [sdb] tag#16 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=4s
[  272.120406] sd 3:0:0:0: [sdb] tag#16 Sense Key : Hardware Error [current]
[  272.120520] sd 3:0:0:0: [sdb] tag#16 Add. Sense: Internal target failure
[  272.120635] sd 3:0:0:0: [sdb] tag#16 CDB: Read(16) 88 00 00 00 00 01 44 24 
08 00 00 00 00 08 00 00
[  272.120790] blk_update_request: critical target error, dev sdb, sector 
5438179328 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.120989] sd 3:0:0:0: [sdb] tag#18 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=4s
[  272.121144] sd 3:0:0:0: [sdb] tag#18 Sense Key : Hardware Error [current]
[  272.121258] sd 3:0:0:0: [sdb] tag#18 Add. Sense: Internal target failure
[  272.121372] sd 3:0:0:0: [sdb] tag#18 CDB: Read(16) 88 00 00 00 00 01 44 44 
08 00 00 00 00 08 00 00
[  272.121519] blk_update_request: critical target error, dev sdb, sector 
5440276480 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.126222] sd 3:0:0:0: [sdb] tag#9 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=4s
[  272.130968] sd 3:0:0:0: [sdb] tag#9 Sense Key : Hardware Error [current]
[  272.135721] sd 3:0:0:0: [sdb] tag#9 Add. Sense: Internal target failure
[  272.140467] sd 3:0:0:0: [sdb] tag#9 CDB: Read(16) 88 00 00 00 00 01 44 64 08 
00 00 00 00 08 00 00
[  272.145285] blk_update_request: critical target error, dev sdb, sector 
5442373632 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.155087] sd 3:0:0:0: [sdb] tag#23 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=4s
[  272.160096] sd 3:0:0:0: [sdb] tag#23 Sense Key : Hardware Error [current]
[  272.164785] sd 3:0:0:0: [sdb] tag#23 Add. Sense: Internal target failure
[  272.169215] sd 3:0:0:0: [sdb] tag#23 CDB: Read(16) 88 00 00 00 00 01 44 84 
08 00 00 00 00 08 00 00
[  272.173275] blk_update_request: critical target error, dev sdb, sector 
570784 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[  272.181073] sd 3:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=4s
[  272.185070] sd 3:0:0:0: [sdb] tag#14 Sense Key : Hardware Error [current]
[  272.189069] sd 3:0:0:0: [sdb] tag#14 Add. Sense: Internal target failure
[  272.193046] sd 

Bug#994151: yt-dlp: little script

[Andres Salomon]

Hm, pabs thinks we should drop the wrapper stuff and just do a proper 
transition (and that we have time for that before the January freeze).


https://wiki.debian.org/Teams/ReleaseTeam/Transitions

I'm ambivalent. Youtube-dl has 3 reverse deps (mkchromecast, 
python3-moviepy, and youtubedl-gui), and another 23 reverse 
suggests/recommends.


On Sun, Oct 23 2022 at 10:57:29 PM -0400, Andres Salomon 
 wrote:
On Mon, 29 Aug 2022 19:09:45 -0400 (EDT) Unit 193 
 wrote:
> On Mon, 01 Aug 2022 20:10:42 +0200 michel  
wrote:
> > I fleshed out the proposal a bit more. The simplest possibillity 
is to make symlinks, of both
> > the executable and module, to pretend they are youtube-dl and the 
module youyube_dl. This way,

> > also python programs that load the module could work.
> >
> > A little bit better is this little wraper. you link the exec and 
module to it.

> >
> > --
> > #!/usr/bin/python3
> >
> > import sys
> > from yt_dlp import *
> >
> > if __name__ == "__main__":
> >
> > args=sys.argv.copy()
> > args.pop(0)
> > args=['--compat-options','youtube-dl']+args
> >
> > main(args)
> > 
> >
> >

Thanks for the script! We still haven't seen a youtube-dl release and 
it's pretty clear the way that things are headed, so I've gone ahead 
and prepared the package for becoming replaced by yt-dlp:


https://salsa.debian.org/debian/youtube-dl/-/commits/master

Andreas & others, any thoughts/comments on this before I upload?

Thanks,
Andres

Bug#1022828: grep: Remove patch than disables stray backslash warnings

[Santiago Ruano Rincón]

Control: block -1 by 1019725 1019326


signature.asc
Description: PGP signature

Bug#1004638: openjfx: diff for NMU version 11.0.11+0-1.1

[Emmanuel Bourg]

Le 26/10/2022 à 01:27, Sebastian Ramacher a écrit :


Dear maintainer,

I've prepared an NMU for openjfx (versioned as 11.0.11+0-1.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.


Hi Sebastian,

Thank you for the update, but could you send a PR on Salsa instead of 
uploading NMUs please?


Emmanuel Bourg

Bug#1022825: libyaml-dev: Include yamlConfig.cmake

[Florian Ernst]

Hello Bastian,

On Wed, Oct 26, 2022 at 04:10:33PM +0200, Bastian Germann wrote:
> Please include yamlConfig.cmake as part of the -dev package.

That yamlConfig.cmake file currently will only be generated when using
CMake to build libyaml. Upstream's standard build scheme does not build
it, though.

However, the yamlConfig.cmake.in appears simple enough as it is. Is
there an easy way to generate a fully compliant yamlConfig.cmake from it
without changing build systems?

Cheers,
Flo


signature.asc
Description: PGP signature

Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts

[Andras Korn]

Package: runit
Version: 2.1.2-50
Severity: normal

Hi,

/lib/runit/run_sysv_scripts has this:

for script in "$initdir/$rX"* ; do
[ ! -x "$script" ] && continue
path=$(realpath "$script")
name=${path##*/}
# Special case for wicd. Runscript is called "wicd-daemon",
# to match binary package name.
[ -d "/etc/sv/$name" ] && continue
[ -d "/etc/sv/$name-daemon" ] && continue
"$script" "$rcommand"
done

Checking for /etc/sv/$name and skipping initscripts if those directories exist 
is wrong for two reasons:

 1. /etc/sv/$name may not be symlinked into /etc/service (false positive);

 2. /etc/service may contain a symlink to a service directory for this service 
that is elsewhere in the filesystem, not in /etc/sv (false negative).

As a minimum, I suggest the following: instead of /etc/sv/$name, check for 
/etc/service/$name (and $name-daemon if necessary), and not with "-d" but "-L" 
(because when running rcS.d, the target of the symlink may only appear later, 
for example when a new filesystem is mounted).

This is still imperfect during boot because /etc/service may point to some 
directory that is not the one we'll switch to with runsvdir in stage 2. I don't 
know what the best way of handling this (likely rare) case is, but the 
following solutions come to mind:

 1. have a /etc/runit/override-init.d/ directory. If $name exists in it, don't 
invoke the initscript in /lib/runit/run_sysv_scripts. This places the entire 
administration/configuration burden on the admin but is very simple to do, and 
easy enough for the admin to automate (e.g. your own service scripts can just 
create these files when they're first run).

 2. pass the name of the /etc/runit/runsv directory that we expect to be used 
to /lib/runit/run_sysv_scripts somehow (for example, in an environment 
variable). This looks brittle (riddled with race conditions) and complicated to 
me, but it would require no effort from the admin.

 3. invoke runsvchdir earlier during boot. This is problematic on systems where 
/ is read-only before some initscripts are run.

 4. [other kludges]

András

-- 
 Reality is merely an illusion, albeit a very persistent one.

Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Michael Tokarev]

Control: forward -1 https://bugzilla.samba.org/show_bug.cgi?id=15205
Control: tag -1 + upstream patch

Ok, there's a bugreport in samba (see above), and the fixes went to 4.17.1,
but not to 4.16.6 (they're in 4.16-test, though.

I can probably make another 4.16 upload - was thinking about making 4.17
the default finally but decided to wait for yet another minor release due
to another symlink attack issue found in the new 4.17 code.

Oh well. I hate useless work, - it is useless to push the already pending
patches. But the next 4.16.7 is scheduled for Jan 05 2023, which is quite
some time from now.

Hwell..

/mjt

Bug#1022348: gpgme1.0: FTBFS: Could not find gpg-error-config. Please install the libgpg-error development package.

[Andreas Metzler]

On 2022-10-26 Andreas Metzler  wrote:
[...]
> Which has been promptly fixed. Find attached debdiffs for a proposed
> upload. - I can also massage this into a mergew-request or push
> directly to https://salsa.debian.org/debian/gpgme Just give me a
> heads-up.
[...]

https://salsa.debian.org/debian/gpgme/-/merge_requests/7

(Sending now since I will not have time tomorrow and on Friday.)
cu Andreas

Bug#1022836: RFP: python3-gensafeprime -- generate primes with openssl

[Jeffrey Cliff]

Package: wnpp
Severity: wishlist
* Package name:  python3-gensafeprime
  Upstream Author :   Erik Tews
* URL : https://git.freecumextremist.com/themusicgod1/gensafeprime
* License : MIT
  Programming Lang: python
  Description :  This module generates safe prime numbers using
the OpenSSL library

A number p is a safe prime number, if p is a prime number, and p =
2*q+1, and q is a prime number too. These numbers are sometimes used
in cryptography.

python3-gensafeprime is a dependency of py_ipv8 ( #1019898 )

Bug#1022835: ITP: node-openpgp-pako --high speed Zlib port to Javascript.

[Lydia Ojoawo]

Package: wnpp
X-Debbugs-Cc:debian-de...@lists.debian.org
Owner: Lydia Ojoawo
X-Debbugs-Cc: ojoawoly...@gmail.com
Severity: wishlist

* Package name : node-openpgp-pako
  Version : 1.0.11
  Upstream Author : Andrei Tuputcyn
* URL :https://github.com/openpgpjs/pako
* License : (MIT AND Zlib)
  Programming Lang: Javascript
  Description : high speed Zlib port to Javascript, works in browser 

Bug#1022834: ITP: golang-opentelemetry-contrib -- Collection of 3rd-party packages for OpenTelemetry-Go

[Thomas Goirand]

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

* Package name: golang-opentelemetry-contrib
  Version : 0.25.0
  Upstream Author : The OpenTelemetry Authors
* URL : https://github.com/open-telemetry/opentelemetry-go-contrib/
* License : Apache-2.0
  Programming Lang: Go
  Description : Collection of 3rd-party packages for OpenTelemetry-Go

 OpenTelemetry-Go Contrib is a collection of extensions for the
 opentelemetry project. It provides 3rd parth resource detectors,
 propagators, samplers, and instrumentation as submodules.
 .
 OpenTelemetry-Go Contrib contains common values used across all
 instrumentation, exporter, and detector contributions.

Note: this is yet another intdirect dependency of etcd 3.5.5

Bug#1022833: rust-send-wrapper: please upgrade to v0.4

[Jonas Smedegaard]

Source: rust-send-wrapper
Version: 0.6.0-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade to newer upstream branch v0.4, needed by projects I am
preparing for Debian.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNZWCEACgkQLHwxRsGg
ASERLBAAoKh7lcvuqguwtZefL3Bnu3Rdbf42QTV03d2IjAPygDyfjvTIvauYo8IF
7OTGo1nqx9czmuBHL6AmiM2AD/EZobFsZm4zGbjjJN50M1yYSDxoXuHaU0ybsq+2
uwMKHhu9BKaXBTWAdO+m2UkwgPyL09C9c2E+HQAAf3FYCtPyTel5ar+nOK/znMFK
E6kFUOnLXXQdBsflNO+4y6YKe9pNl1/9D3jia9BnkXvfgIA9whUcKz9NHVgQQZl9
jUMuVqDJG7iNRyhFP6GXZXYc+qybjaOdcXwRQo/V/k31uSPnJC6ajtUTK68Ocnku
HnxXrdXnIRQTIW0zLZz0NX5TqVauVm1A0h1vxrwWqqqUt9wc0hWYJBh0RUTPCwX6
YRCfG3VlG1QJDSh9FLfySLr2oEbHCCdaf56rbrVwnoXYF6yTY8Mo8qpuZ27SUGyu
osIiBc7ZHmwEJrXrkKpi78L6HuUGfDG/WUwHwIuZPwX1FhIdEmG2pWhkly8YHavu
1TZ1/5qWFOpn3ddiXHDqWmYDk3YT8IJlOdvn4wXSPATiP2BhZR89bl7sSLjJIrE6
17plQD7MIGxJQW72zKpD5X2JHJhEd1+8emaVdjNmrWrwq5TJmoMFa8+izCBc7Z34
G2IeNSw3GbI87kzLlex1eMGOZLczIi9I96VFGKFoSV3Jg702Wq8=
=4jjW
-END PGP SIGNATURE-

Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Michael Tokarev]

Control: found -1 2:4.16.6+dfsg-3
Control: tag -1 - moreinfo unreproducible
Control: tag -1 + confirmed


26.10.2022 18:34, Arnaud Rebillout wrote:
..

So this is version 2:4.16.6+dfsg-3. Right now I can fire a Debian sid container 
and reproduce the issue with:


Ok, that's excllent, thank you!


   # apt update && apt install -y smbclient
   # testparm /etc/samba/smb.conf --suppress-prompt
   Load smb config files from gW???U
   Error loading services.

NB: you MUST pass /etc/samba/smb.conf in argument to trigger the issue.


Aha. Got it.


The issue with libpopt seems to be documented at 
https://github.com/rpm-software-management/popt/issues/80.


Lemme see..


However I didn't notice that samba embeds its own libpopt, so now I'm confused. 
Are you 100% sure it's the embedded lib that is used?


I'm 100% sure it is *not* the embedded copy which is used, due to this:
https://salsa.debian.org/samba-team/samba/-/blob/debian/2%254.16.6+dfsg-3/debian/rules#L85

 --bundled-libraries=NONE,pytevent,ldb


   # ldd /usr/bin/testparm | grep popt
   libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x7f52a45d1000)

Or does the line above suggests that it uses the shared library? (real 
question, I'm not familiar with ldd)


It uses the system shared lib, exeactly as it should.

Samba had adoptations for the libpopt changes and changed internal popt
too, that's why I was confused as well.

Anyway, lemme look at this now when I know the version
and the environment, and was able to reproduce it.

Thanks,

/mjt

Bug#1022832: firmware-iwlwifi: Failed to load firmware for Intel Wireless AX211

[Zhengyi Fu]

Package: firmware-iwlwifi
Version: 20210818-1
Severity: important
X-Debbugs-Cc: zhengyi...@outlook.com

Dear Maintainer,

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

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

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

The firmwares wlwifi-so-a0-gf-a0-*.ucode and intel/ibt-0040-0041.sfi are
missing,
which causes ax211 unusable.
Please consider include these firmwares in firmware-iwlwifi.

Thanks,
Zhengyi Fu


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

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.142

-- debconf information excluded

Bug#1022831: ITP: rust-futures-timer -- timeouts for futures

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-futures-timer
  Version : 3.0.0
  Upstream Author : Alex Crichton 
* URL : https://github.com/async-rs/futures-timer
* License : Apache-2.0 or Expat
  Programming Lang: Rust
  Description : timeouts for futures

 A general purpose crate
 for working with timeouts and delays with futures.

This package is needed for rust-threadfin testsuite.
It will be maintained in the collaborative Debian section of Salsa, at
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNZVfwACgkQLHwxRsGg
ASHdIQ//U67SSlEOTwLM96nVyrGCWVul7P/BA/pSi6AnvKzMrhEcF2J+lC35O7Ib
twzAA1BUEHSa85Zxk93KqPQdPRUyaLFBEuNjQculBQKoGYEZ3jHuXbSQ4Dx9aCLy
Wyc4n68tXCKwWmPzbqRWQywQd3V4+pjhp7L5MCC80OnKjS/JgLPcYUwCIrly+My6
6WvVpNhO4Y/9Ct+T9Mv1X+A2lrjb6/U7D8Wpy5iZtD2rpCSwMgELd2eOaj3YzY7U
tMdfmxuS01G+VBR+pun/AvY0HpZqP6fLS6opYUBN1hEesglJMA6uKIaVbkZIWhRM
Nm7TA18XNigaJlX70B6WZqucUGPnFBFP/GIU5B7V+h2nNN17HjQwKkLGxNRbTkvV
1EBTtzFqWvSHJQvt8iSBoaJOEab9GhXXAmlAgQRks6Yg80VYG8VGzmxCzKBZnECJ
XMQoP7r+0w+mwNHZFc2/RpCwstXFS5x1o0vM7ncjgD8Bpizhk8m4Lpo+MWX6rP0Z
8+KnBBlqZH0n11jdR+fsu3hHPQZo+FAmOHrOsszYNIhIVzAHsvhXGlbcDNQKKVEc
78/eUB6fX+EGMHojOqNaTKbaZhGloEnWEXtPoWAlNSYYnjpr6mpNL12B7YD626Uh
RLxm46zZY9vD0lBPNeU1vDqBO4vHA2c/0EAyyVkU34bQS+C6gQk=
=DP6U
-END PGP SIGNATURE-

Bug#1021998: CXL -- Salsa MR added

[Adam Borowski]

https://salsa.debian.org/kernel-team/linux/-/merge_requests/563

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos?
⠈⠳⣄

Bug#1022830: apt ignores versioned provides if non-matching version is installed via another dep

[duck]

Package: apt
Version: 2.5.3+b1
Severity: important
Control: affects -1 redmine


Quack,

I had a weird FTBFS in #1022340 and it looks like the resolver is just 
skipping the versioned dep because another dep provides the same virtual 
package. Unfortunately it does not resolve the required version and 
should install the non-virtual package providing the right version (they 
are co-installable). More info in the referenced BR.


I bumped the severity because I don't see any way to work around this. 
We certainly cannot drop the provides or that would break things. We 
also cannot change the content of the Ruby standard library. Maybe 
redmine does not need the new features in 3.2.0 but since they 
specifically bump the dep I would not bet on that.


Could you have a look please?

Regards.
\_o<

--
Marc Dequènes

Bug#1022826: [Pkg-samba-maint] Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Arnaud Rebillout]

On Wed, 26 Oct 2022 18:13:51 +0300 Michael Tokarev  wrote:
> Control: tag -1 + moreinfo unreproducible
>
> 26.10.2022 17:45, Arnaud Rebillout wrote:
> > Package: samba-common-bin
> > Severity: normal
> > User: de...@kali.org
> > Usertags: origin-kali
> >
> > Dear Maintainer,
> >
> > This command fails:
> >
> > # testparm /etc/samba/smb.conf --suppress-prompt
> > Load smb config files from <>
> > Error loading services.
>
> Which version of samba-common-bin is that?
>
> I was about to close this bug right away because you didn't
> specify a version. But I'd give it a try anyway.
>
> The thing is that the libpopt is bundled with samba sources, and
> current samba in debian unstable (4.16.6+dfsg-3) already has the
> necessary fixes for it. There should be, in theory, no issues with
> the fixed/new libpopt.
>
> I just tested that one with current libpopt, - it works as expected
> here.

Sorry about forgetting the version.

So this is version 2:4.16.6+dfsg-3. Right now I can fire a Debian sid 
container and reproduce the issue with:


  # apt update && apt install -y smbclient
  # testparm /etc/samba/smb.conf --suppress-prompt
  Load smb config files from gW???U
  Error loading services.

NB: you MUST pass /etc/samba/smb.conf in argument to trigger the issue.

The issue with libpopt seems to be documented at 
https://github.com/rpm-software-management/popt/issues/80.


However I didn't notice that samba embeds its own libpopt, so now I'm 
confused. Are you 100% sure it's the embedded lib that is used?


  # ldd /usr/bin/testparm | grep popt
  libpopt.so.0 => /lib/x86_64-linux-gnu/libpopt.so.0 (0x7f52a45d1000)

Or does the line above suggests that it uses the shared library? (real 
question, I'm not familiar with ldd)


Cheers, and thanks for the quick reply.

Arnaud

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

[Bernhard Übelacker]

Dear Maintainer,
I tried to collect some more information about this issue.


With the help of rr-debugger I reached this function,
which "returns" a pointer to a static variable buf:

(rr) bt
#0  0x563a2b2373b6 in menuSize (options=, mode=, width=0x7ffdd199be38, height=0x7ffdd199be3c) at ./whiptail.c:236
#1  guessSize (options=, text=, title=, 
fullButtons=, flags=, mode=, width=, height=) at ./whiptail.c:262
#2  main (argc=, argv=) at ./whiptail.c:520
(rr) list 202,237
202 static int menuSize(int * height, int * width, enum mode mode,
203 poptContext options) {
204 const char ** argv = poptGetArgs(options);
205 const char ** items = argv;
206 int h = 0;
207 int tagWidth = 0;
208 int descriptionWidth = 0;
209 int overhead = 10;
210 static char buf[20];
211
...
232
233 h = min(h, SLtt_Screen_Rows - *height - 4);
234 *height = *height + h + 1;
235 sprintf(buf, "%d", h);
236*items = buf;  <
237 return 0;
(rr) print 
$7 = (char (*)[20]) 0x563a2b23b2c0 


A little later this pointer is attempted to be freed inside libpopt0:

(rr) bt
...
#5  0x7f49c889322a in malloc_printerr (str=str@entry=0x7f49c89b41d0 "free(): 
invalid pointer") at ./malloc/malloc.c:5659
#6  0x7f49c8894d6c in _int_free (av=, p=, 
have_lock=have_lock@entry=0) at ./malloc/malloc.c:4434
#7  0x7f49c88978df in __GI___libc_free (mem=) at 
./malloc/malloc.c:3386
#8  0x7f49c8fff829 in _free (p=) at ./src/poptint.h:22
#9  poptResetContext (con=) at ./src/popt.c:220
#10 poptResetContext (con=0x563a2cb8b440) at ./src/popt.c:202
#11 0x7f49c9001635 in poptFreeContext (con=con@entry=0x563a2cb8b440) at 
./src/popt.c:1531
#12 0x563a2b237071 in main (argc=, argv=) 
at ./whiptail.c:628
...
(rr) print p
$1 = (const void *) 0x563a2b23b2c0 
...
(rr) print con->leftovers[3]
$3 = (poptString) 0x563a2b23b2c0  "3"



A package built with following modification,
to allocate memory that is freeable,
does no longer show this crash.
(While I have not further investigated,
if libpopt0 is supposed to free this pointer.)

--- newt-0.52.21.orig/whiptail.c
+++ newt-0.52.21/whiptail.c
@@ -207,7 +207,7 @@ static int menuSize(int * height, int *
int tagWidth = 0;
int descriptionWidth = 0;
int overhead = 10;
-static char buf[20];
+charbuf[20];

if ( argv == 0 || *argv == 0 )

return 0;
@@ -233,7 +233,7 @@ static int menuSize(int * height, int *
h = min(h, SLtt_Screen_Rows - *height - 4);
*height = *height + h + 1;
sprintf(buf, "%d", h);
-   *items = buf;
+   *items = strdup(buf);
return 0;
}



Following Debian bug seems to mention similar issues in gdisk and svox:

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

And libpopt0 upstream tracker sounds also related:

https://github.com/rpm-software-management/popt/issues/80


Kind regards,
Bernhard

Bug#1021530: wireplumber: No sound after upgrade to 0.4.12-1

[Kurt Meyer]

Uninstalling PulseAudio is a workaround, not a bug fix in my opinion. The 
latest wireplumber and libwireplumber-0.4-0 upgrade still results in no audio. 
Additionally, I failed to mention in my previous reply that I was also unable 
to stream video with the upgrades; e.g. YouTube.

The Debian Wiki page for Pipewire states that Pipewire as a replacement for 
PulseAudio "may be a comfortable drop-in replacement..." under Debian Testing 
and Unstable. Additionally, there's no mention that both can't or shouldn't be 
used together. If this is no longer the case, then shouldn't there have been an 
apt-listchanges News report after the recent wireplumber and 
libwireplumber-0.4-0 upgrades?

Bug#1022828: grep: Remove patch than disables stray backslash warnings

[Santiago Ruano Rincón]

Control: block -1 by 1019725


signature.asc
Description: PGP signature

Bug#1022340: redmine: FTBFS: Could not find gem 'csv (~> 3.2.0)' in cached gems or installed locally. The source contains the following gems matching 'csv': csv-3.1.9

[duck]

Quack,

Thanks for the report.

When I first read the logs I could not fathom what was going on: we B-D 
on ruby-csv (>= 3.2.0) and it's not even installed!
So it happens that libruby3.0 provides ruby-csv but it explicitly 
specify ruby-csv (= 3.1.9).
I seems the resolver is confused by the fact libruby3.0 also has to be 
present to satisfy another dep.

I'm going to open a BR to get some help.

Regards.
\_o<

--
Marc Dequènes

Bug#1022828: grep: Remove patch than disables stray backslash warnings

[Santiago Ruano Rincón]

Source: grep
Version: 3.8-3
Severity: normal

A bug to track to restore 3.8 upstream behaviour about stray backslash
warnings. The debian patch that disables those warnings should be
removed in a future release.

Cheers,

 -- Santiago

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

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=es_CO.UTF-8, LC_CTYPE=es_CO.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


signature.asc
Description: PGP signature

Bug#1022829: ITP: golang-opentelemetry-proto -- OpenTelemetry Go API and SDK - proto

[Thomas Goirand]

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

* Package name: golang-opentelemetry-proto
  Version : 0.19.0
  Upstream Author : The OpenTelemetry Authors
* URL : https://github.com/open-telemetry/opentelemetry-proto-go
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenTelemetry Go API and SDK - proto

 OpenTelemetry-Go is the Go implementation of OpenTelemetry. It provides a set
 of APIs to directly measure performance and behavior of your software and send
 this data to observability platforms.
 .
 This package contains the proto module.

Note: This is an indirect new dependency for Etcd 3.5.5 that I would like to
upload for Bookworm.

Bug#1022826: [Pkg-samba-maint] Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Michael Tokarev]

Control: tag -1 + moreinfo unreproducible

26.10.2022 17:45, Arnaud Rebillout wrote:

Package: samba-common-bin
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This command fails:

   # testparm /etc/samba/smb.conf --suppress-prompt
   Load smb config files from <>
   Error loading services.


Which version of samba-common-bin is that?

I was about to close this bug right away because you didn't
specify a version. But I'd give it a try anyway.

The thing is that the libpopt is bundled with samba sources, and
current samba in debian unstable (4.16.6+dfsg-3) already has the
necessary fixes for it.  There should be, in theory, no issues with
the fixed/new libpopt.

I just tested that one with current libpopt, - it works as expected
here.

/mjt

Bug#1022798: duplication of library vs updating dependencies

[Shengjing Zhu]

On Wed, Oct 26, 2022 at 10:45 PM Jeffrey Cliff  wrote:
>
> "duplicate the source."
>
> it is one thing that could be done
>
> the other way is for the packages that are staled by this upgrade of
> golang-goprotobuf-dev (which is what this appears to be, in a separate
> package) to be updated
>
> would that not be the way these kinds of upgrades would normally
> occur, insated of just accepting the go ecosystem's needless
> duplication of libraries?
>
> was there any discussion that lead to this duplication of this library
> as a way out of this particular dependency hell somewhere?
>

https://lists.debian.org/debian-go/2020/07/msg6.html
https://lists.debian.org/debian-go/2021/08/msg00061.html
https://lists.debian.org/debian-go/2022/06/msg00070.html

Well, one thread per year from 2020.

tl,dr
Because some important packages can't be migrated to the new version,
and removing that would mean removing all the container tools like
containerd/docker/podman.

-- 
Shengjing Zhu

Bug#1022827: ITP: rust-rusty-pool -- self growing / shrinking ThreadPool implementation

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-rusty-pool
  Version : 0.7.0
  Upstream Author : robinfriedli 
* URL : https://github.com/robinfriedli/rusty_pool
* License : Apache-2.0
  Programming Lang: Rust
  Description : self growing / shrinking ThreadPool implementation

 Self growing / shrinking "ThreadPool" implementation
 based on crossbeam's multi-producer multi-consumer channels
 that enables awaiting the result of a task
 and offers async support.

This package is needed for rust-threadfin testsuite.
It will be maintained in the collaborative Debian section of Salsal, at
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNZSJ8ACgkQLHwxRsGg
ASH1eA/9GlGfhEliOwjE92C0xVnFUXhDvPHuKQwBc53fZ+ig5LzMu05Cdnv8layD
6tO7HSPm+Fsg0bbFA2yUsl83/4ieaH9Kv3yTYiLCX5ScxkCmdwKhyhNlRbpI+aX5
tlHwi+AGxr71Ol9gTYcBRUhXhBS//nnHVKJFyXI+IO6bqxIUjzNJ7Kj+Mv7l37Dj
AxsC5gyE57wxBvr1TYoJsXFiawOUmLQnRpSTRZXZYKKf1BTq1fhKqoYEL74h1/Yo
pRNxnY7BAKXOdOdGiqJqRFVBzKthhRyLVQlCPEyt1ddk8YlN2J25PENi+SZ0ty2s
CPG1G/mK5/YNZP7UVgYIh4IdVNiLJE7kWu20vZjgcfXvn75JHvndorK31b1kPN0M
GexTsjryFKShz8A+HOdNvN2rboD5u6AQhf3iaulsYJWBaGRdgCF1OtJKzNdJGwTQ
cK51PjK2GQfrVWh14h/rLezH+10DAqb6rIGfKCphVH5rbNUuu2e+5JJDEOQZHOOo
05xt/X+7XsB93PQtmUYag5wILUcOlJkJVWDiRY7EBD+FL7fWsK93Io9LUiMs+WkN
XugqwBHInqFyAI6MZ5uU7OIyy9wytfLbjcayO6YPhnrMafUn5j/Snt4BWXZaBhUT
B5xIwt1QzueQzhs1bke/ete9UUSxvIVWB2l0MGxr/SGnijagR7A=
=fipN
-END PGP SIGNATURE-

Bug#1022826: samba-common-bin: testparm fails if given a config file, due to libpopt 1.19+dfsg-1

[Arnaud Rebillout]

Package: samba-common-bin
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Dear Maintainer,

This command fails:

  # testparm /etc/samba/smb.conf --suppress-prompt
  Load smb config files from <>
  Error loading services.

However this command succeeds:

  # testparm --suppress-prompt
  [...]

The second command is identical to the first one, except that we don't
explicitly pass the location of the config file to test. If not
specified, the default config file is /etc/samba/smb.conf.

It seems that the issue is due to the package libpopt0. The command
worked fine with libpopt0 1.18-3, and it crashes with libpopt0
1.19+dfsg-1 that just landed in Debian testing, hence in Kali Linux.

The issue was initially reported in the Kali bug tracker at
https://bugs.kali.org/view.php?id=8024#c17003, and it can be reproduced
in Debian unstable.

Thanks,

Arnaud

Bug#1022798: duplication of library vs updating dependencies

[Jeffrey Cliff]

"duplicate the source."

it is one thing that could be done

the other way is for the packages that are staled by this upgrade of
golang-goprotobuf-dev (which is what this appears to be, in a separate
package) to be updated

would that not be the way these kinds of upgrades would normally
occur, insated of just accepting the go ecosystem's needless
duplication of libraries?

was there any discussion that lead to this duplication of this library
as a way out of this particular dependency hell somewhere?

Jeff Cliff
-- 

End the campaign to Cancel Richard Stallman - go to stallmansupport.org !

Bug#1022566: fonts-mplus: upgrade of mplus leaves an old /usr/share/fonts/truetype/mplus behind

[Hideki Yamane]

control: reassign -1 fontconfig
control: forcemerge -1 897040

Hi,

On Mon, 24 Oct 2022 05:27:14 +0200
Alexandre Detiste  wrote:
> After upgrade of mplus, I still have got old loose dir and cache file
> from previous version:
> 
> /usr/share/fonts/truetype/mplus
> /usr/share/fonts/truetype/mplus/.uuid
> 
> Please remove these files on upgrade.

 It was not created by fonts packages, but by fontconfig.
 And, it seemed to be fixed in upstream now.
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040
 


-- 
Hideki Yamane 

Bug#1013361: clarification

[Gürkan Myczko]

ruptime/ruptimed has ben released long ago under the AGPL-3.0

there's no reason for it to go into non-free, it's software for main

best,

Bug#1022825: libyaml-dev: Include yamlConfig.cmake

[Bastian Germann]

Package: libyaml-dev
Severity: wishlist
Version: 0.2.5-1

Please include yamlConfig.cmake as part of the -dev package.

Bug#1022824: ITP: rust-threadfin -- thread pool for running multiple tasks on group of threads

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: rust-threadfin
  Version : 0.1.1
  Upstream Author : Stephen M. Coakley 
* URL : https://github.com/sagebind/threadfin
* License : Expat
  Programming Lang: Rust
  Description : thread pool for running multiple tasks on group of threads

 A thread pool for running multiple tasks
 on a configurable group of threads.

This package is needed for rust-isahc testsuite.
It will be maintained in the collaborative Debian section of Salsa, at
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmNZPScACgkQLHwxRsGg
ASGd8A/9Gsxdnnmul0eYCxJaL86AV/1DxVcBoQurxCnjoean8hVy7QyPZb9b1T20
/kx5yJpvXgsHSnWbecFeWRLMQaeRK06wemAkf7IplblNReIA7tx4gLjUQz/ec7q0
ZRpEeY9GiQA5t3xf4/OQvA3gNg4YO2/ZUcnbmq//nogxqo82f3eTeGFUXvq++T9b
lDWRx7iiCAy0UqCrtlMvgJIb5t51LzZq/iP63TWjvVw4tMzGVOovfi3BFIKb1vDi
2FPhGT6HJeGrYAokor+cITmlQTYv0aHAwLcK9CE+QkE59N7sr+SkKvxW+oDbrSOw
Fy3PDIpf4VM2DSyUrWhQzt9kVC2U2AwAP9jI20Gf4nYFO1rsghuGs+F/2P37YNNx
W/nEOAmFFQqAiLZbpXhI5e6UgHfpd2zW3kzVTWP1Ab4OBAop1b+CfiX+g+lM4w5o
JGnQQHUeTs97wN5biOfMTASGN2vMbh4DRiFKAS/yQ0IqVjejKqoBl9czvY3agk1L
In/VwZWTvn5oAWV4unrATb6YqfLFYgowdObACBGyujHedrItc1CntscVDHxvSZOx
eKBg65tttHErfVHSfUzf4a+Citrf8r5UPVq30zhYAZyFxx5LRsv903dotVkE260Q
ojUdbbfnbS6Les7iMwHnOR/XcsxbTnipczLJmQXdA78AXJ4GhPc=
=z1Co
-END PGP SIGNATURE-

Bug#1022823: nfs-kernel-server: /etc/default/nfs-kernel-server needs RPCNFSDOPTS

[Alfredo Sola]

Package: nfs-kernel-server
Version: 1:1.3.4-6
Severity: wishlist

Dear Maintainer,

I needed a way to have rpc.nfsd bind to a specific IP address.

The man page for rpc.nfsd documents a parameter exactly for this, plus some 
others.

At first signt, it seems that there is no Debian way to pass parameters to 
rpc.nfsd.

But there is; RPCNFSDOPTS can be set on /etc/default/nfs-kernel-server. It will 
then
be sourced from /usr/lib/systemd/scripts/nfs-utils_env.sh, which sends its 
variables
to /run/sysconfig/nfs-utils, from where they are read by nfs-server.service.

Setting RPCNFSDOPTS solves this issue, so I am suggesting that it be added 
(empty)
to /etc/default/nfs-kernel-server, along with a commentary pointing to the 
rpc.nfsd
man page for information on parameters.

-- Package-specific info:
-- rpcinfo --
   program vers proto   port  service
104   tcp111  portmapper
103   tcp111  portmapper
102   tcp111  portmapper
104   udp111  portmapper
103   udp111  portmapper
102   udp111  portmapper
134   tcp   2049  nfs
-- /etc/default/nfs-kernel-server --
RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"
NEED_SVCGSSD=""
RPCSVCGSSDOPTS=""
RPCNFSDOPTS="-H 10.RED.ACT.ED -N 2 -N 3"
-- /etc/exports --
/srv/REDACTED 10.RED.ACT.EF(rw,insecure,nohide,sync,anonuid=4001,anongid=4002)
/srv/REDACTED 10.RED.ACT.EF(rw,insecure,nohide,sync,anonuid=4001,anongid=4002)
-- /proc/fs/nfs/exports --
# Version 1.1
# Path Client(Flags) # IPs

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

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

Versions of packages nfs-kernel-server depends on:
ii  keyutils  1.6.1-2
ii  libblkid1 2.36.1-8+deb11u1
ii  libc6 2.31-13+deb11u4
ii  libcap2   1:2.44-1
ii  libsqlite3-0  3.34.1-3
ii  libtirpc3 1.3.1-1+deb11u1
ii  libwrap0  7.6.q-31
ii  lsb-base  11.1.0
ii  netbase   6.3
ii  nfs-common1:1.3.4-6
ii  ucf   3.0043

nfs-kernel-server recommends no packages.

nfs-kernel-server suggests no packages.

-- no debconf information

Bug#1022822: apache2: improve apache2 OOM handling w/systemd

[Brad Barnett]

Package: apache2
Version: 2.4.54-2
Severity: important
X-Debbugs-Cc: debian-bu...@l8r.net

Dear Maintainer,

A single apache2 thread was hit by the linux kernel OOM killer, and was killed. 
 Systemd "helpfully" decided to then halt apache2 completely.

As per this bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=1947475

there is a new OOM option to systemd.  Suggest setting this to 
OOMPolicy=continue for apache2, as most definitely killing all of apache2, for 
one thread's OOM even, is typically not the desired (or expected) behaviour.




-- Package-specific info:

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

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 apache2 depends on:
ii  apache2-bin  2.4.54-2
ii  apache2-data 2.4.54-2
ii  apache2-utils2.4.54-2
ii  init-system-helpers  1.60
ii  lsb-base 11.1.0
ii  mime-support 3.66
ii  perl 5.32.1-4+deb11u2
ii  procps   2:3.3.17-5

Versions of packages apache2 recommends:
ii  ssl-cert  1.1.2

Versions of packages apache2 suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2-bin depends on:
ii  libapr1  1.7.0-8
ii  libaprutil1  1.6.1-5+b2
ii  libaprutil1-dbd-sqlite3  1.6.1-5+b2
ii  libaprutil1-ldap 1.6.1-5+b2
ii  libbrotli1   1.0.9-2+b2
ii  libc62.33-8
ii  libcrypt11:4.4.18-4
ii  libcurl4 7.84.0-2
ii  libjansson4  2.14-2
ii  libldap-2.5-02.5.12+dfsg-2
ii  liblua5.3-0  5.3.6-1
ii  libnghttp2-141.48.0-1
ii  libpcre2-8-0 10.40-1
ii  libssl3  3.0.4-2
ii  libxml2  2.9.14+dfsg-1+b1
ii  perl 5.32.1-4+deb11u2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u1

Versions of packages apache2-bin suggests:
pn  apache2-doc  
pn  apache2-suexec-pristine | apache2-suexec-custom  
pn  www-browser  

Versions of packages apache2 is related to:
ii  apache2  2.4.54-2
ii  apache2-bin  2.4.54-2

-- Configuration Files:

-- no debconf information