Bug#1006289: marisa's autopkgtest regressed since rebuild for ruby3.0 as default

[Boyuan Yang]

X-Debbugs-CC: kanash...@debian.org terce...@debian.org gunna...@debian.org

Hi all,

(see bottom)

在 2022-02-22星期二的 22:05 +0100，Paul Gevers写道：
> Source: marisa
> Version: 0.2.6-8
> Severity: serious
> X-Debbugs-Cc: kanash...@debian.org, terce...@debian.org
> 
> Dear maintainer,
> 
> As part of the ongoing transition from ruby2.7 as default ruby to
> ruby3.0 as default, your package got rebuild. In that rebuild it
> correctly picked up a dependency on libruby3.0, but as it also depends
> on ruby (unversioned) it seems to not be able to work in testing, as
> seen by the autopkgtest regression.
> 
> I don't know what the best way forward is, but I think the right
> version of ruby needs to be detected during build and included in
> ${misc:Depends} or something similar. I have included two ruby
> maintainers in the X-Debbugs-CC for advice.
> 
> Paul
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/marisa/19472910/log.gz
> 
> [...]
> 
> Setting up libruby3.0:amd64 (3.0.2-7) ...
> Setting up libruby2.7:amd64 (2.7.4-1+b1) ...
> Setting up ruby2.7 (2.7.4-1+b1) ...
> Setting up ruby (1:2.7.6) ...
> 
> [...]
> 
> autopkgtest [20:54:51]: test ruby: [---
> === ruby ===
> /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in
> `require': cannot load such file -- marisa (LoadError)
> from
> /usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in
> `require'
> from bindings/ruby/sample.rb:1:in `'
> autopkgtest [20:54:51]: test ruby: ---]

Compared to
https://salsa.debian.org/input-method-team/marisa/-/merge_requests/1 ,
I am more into a more generic solution to avoid version hardcoding:

diff --git a/debian/control b/debian/control
index 39c36da..dec2dc7 100644
--- a/debian/control
+++ b/debian/control
@@ -95,7 +95,7 @@ Architecture: any
 Multi-Arch: foreign
 Depends:
  libmarisa0 (= ${binary:Version}),
- ruby,
+ ruby (>= ${ruby:Build-Version}),
  ${misc:Depends},
  ${shlibs:Depends},
 Description: Ruby bindings for MARISA
diff --git a/debian/rules b/debian/rules
index 20a945c..9acebb2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -79,3 +79,9 @@ override_dh_auto_install:
rm $(CURDIR)/debian/libmarisa-perl$(PERL_VENDOR_ARCH)/sample.pl
# install ruby modules
cd bindings/ruby; make install DESTDIR=$(CURDIR)/debian/ruby-marisa
+
+# record minimum ruby version requirement
+# see https://bugs.debian.org/1006289
+override_dh_gencontrol:
+   dh_gencontrol -- \
+   -V"ruby:Build-Version=$$(dpkg-query -f='$${Version}' -W ruby)"

I will make an upload with this solution to see how things works. The testing
migration will unfortunately be blocked till ruby3.0 migrates, but that should
be the expected behavior. I really don't want to hack into marisa's (custom)
ruby building chain to support multiple ruby versions.

BTW: it would be great if Ruby could provide some similar substvar (or via
${ruby:Depends}), though it is not possible for now since ${ruby:Depends} is
currently from gem2deb and not for non-gem packages.

Thank you all for caring marisa package!

Best,
Boyuan Yang


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

Bug#1006309: boost-defaults: boost 1.74 2 years old and not C++20 compatible

[Christophe Prud'homme]

Source: boost-defaults
Severity: important

Dear Maintainer,


   * What led up to the situation?
boost 1.74 is 2 years old and not C++20 compatible.

C++20 is out for 2 years now, G++ and Clang now support it quite well

boost 1.74 (the default boost) is incompatible with C++20. Boost 1.77 or
1.78 are needed at least.

In practice, the boost packages are becoming obsolete and not in line with
the C++ compiler developments

Boost is however an important software piece for C++ developers.

We thus need to use other distribution channels, which is a pity.

We could provide packaging help if needed.


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500,
'focal'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-72-generic (SMP w/56 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


[image: photo]
Christophe Prud'homme
Professor at  Université de Strasbourg
A  7 rue René Descartes, 67084 Strasbourg
P  +33 368850089  < +33 368850089>
M  +33 687646051  <+33 687646051>
E  christophe.prudho...@cemosis.fr  
W  http://www.cemosis.fr  
 

Create your own email signature

‌

Bug#1000336: Upgrading tbb

[Diane Trout]

On Wed, 2022-02-23 at 00:31 -0500, M. Zhou wrote:
> Hello guys. Finally it's all green on our release architectures
> https://buildd.debian.org/status/package.php?p=onetbb=experimental
> 
> I shall request the slot for transition once finished the rebuild
> of its reverse dependencies and filed FTBFS bugs if any.

Wonderful! That is great news.

Thank you!

Diane

Bug#1006308: seatd-launch: CVE-2022-25643

[Salvatore Bonaccorso]

Source: seatd
Version: 0.6.3-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for seatd.

CVE-2022-25643[0]:
| seatd-launch in seatd 0.6.x before 0.6.4 allows removing files with
| escalated privileges when installed setuid root. The attack vector is
| a user-supplied socket pathname.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-25643
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25643
[1] 
https://lists.sr.ht/~kennylevinsen/seatd-announce/%3CETEO7R.QG8B1KGD531R1%40kl.wtf%3E

Regards,
Salvatore

Bug#1006306: apper: apper_installer functionality broken?

[Boyuan Yang]

Package: apper
Severity: grave
Version: 1.0.0-3
Tags: sid
X-Debbugs-CC: m...@debian.org

Hi,

I received a user report that they cannot use Apper to install deb packages on
Debian Unstable. I reproduced this issue in the following way:

* Right-click on a deb package (in any file manager app of your choice), and
select "Apper Installer" to open it.
* Nothing happens.

In system journal, the following error occurs:

=
2月 23 01:40:46 hosiet-vm-home dbus-daemon[2238]: [session uid=1000 pid=2238]
Activating service name='org.freedesktop.PackageKit' requested by ':1.108'
(uid=1000 pid=5894 comm="apper /dev/shm/flameshot_11.0.0-2_amd64.deb ")
2月 23 01:40:46 hosiet-vm-home dbus-daemon[5901]: writing oom_score_adj error:
Permission denied
2月 23 01:40:46 hosiet-vm-home dbus-daemon[2238]: [session uid=1000 pid=2238]
Activated service 'org.freedesktop.PackageKit' failed: Failed to execute
program org.freedesktop.PackageKit: No such file or directory


The same error will also take place when I manually execute "apper
/path/to/name.deb". This functionality seems to be provided by
/usr/share/applications/org.kde.apper_installer.desktop .

I have no idea why service org.freedesktop.PackageKit is looking for
nonexistant executable "org.freedesktop.PackageKit". Contents of
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service already
points to the correct executable. My Debian Sid environment already has
PackageKit installed.

Could you please take a look into it?

-- 
Thanks,
Boyuan Yang


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

Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Martin-Éric Racine]

On Wed, Feb 23, 2022 at 1:10 AM Noah Meyerhans  wrote:
>
> On Tue, Feb 22, 2022 at 08:27:10PM +0100, Marco d'Itri wrote:
> > On Feb 22, Noah Meyerhans  wrote:
> >
> > > For servers, the ideal situation is somewhat less clear, but there was
> > > at least some interest in using systemd-networkd (with or without
> > > netplan).
> > Why even consider netplan, I wonder?
>
> It's not something I'm interested in, but there were some arguments made
> in favor of it in the earlier thread.
> https://lists.debian.org/debian-devel/2021/09/msg00410.html

On the plus side, netplan uses a centralized configuration file just
as /etc/network/interface currently does. On the minus side, YAML
really makes for cluttered config files. I don't like it.

I tried networkd. It comes with the same problem as all of systemd:
every tiniest thing is expected to have its own unit file; there is no
centralized /etc/network/interface and no support for WPA. It sucks.

NM works well on laptops via GNOME's NM applet, but is a PITA for
everything else.

Personally, I'd migrate dhclient to dhcpcd5. NM already has a dhcpcd5
backend, as indicated in #964947 by Michael Biebel.

Integrating bridge-utils into ifupdown and uniformizing the
configuration syntax would also be desirable.

Martin-Éric

Bug#1006305: openh264 FTCBFS: uses the build architecture compiler during make install

[Helmut Grohne]

Source: openh264
Version: 2.2.0+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

openh264 fails to cross build from source. It really does very much
right. dh_auto_build passes cross tools to make. Passing ARCH= helps a
lot. Also passing OS might be an improvement when building for
non-Linux. Usually though the build step succeeds. What fails is make
install, because dh_auto_install does not pass cross tools and make
install then proceeds to rebuild some files with the build architecture
compiler. An easy way to fix that is letting dpkg's buildtools.mk supply
them via the environment for all targets. Doing so makes openh264 cross
buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru openh264-2.2.0+dfsg/debian/changelog 
openh264-2.2.0+dfsg/debian/changelog
--- openh264-2.2.0+dfsg/debian/changelog2022-02-04 15:50:23.0 
+0100
+++ openh264-2.2.0+dfsg/debian/changelog2022-02-23 07:15:26.0 
+0100
@@ -1,3 +1,10 @@
+openh264 (2.2.0+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Also supply build tools to make install. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 23 Feb 2022 07:15:26 +0100
+
 openh264 (2.2.0+dfsg-1) unstable; urgency=medium
 
   * New upstream version 2.2.0+dfsg
diff --minimal -Nru openh264-2.2.0+dfsg/debian/rules 
openh264-2.2.0+dfsg/debian/rules
--- openh264-2.2.0+dfsg/debian/rules2022-02-04 15:32:31.0 +0100
+++ openh264-2.2.0+dfsg/debian/rules2022-02-23 07:15:25.0 +0100
@@ -4,6 +4,9 @@
 CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
 CPPFLAGS=$(shell dpkg-buildflags --get CPPFLAGS)
 
+DPKG_EXPORT_BUILDTOOLS=1
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 

Bug#1004556: libmpich-dev: The simplest MPI program compiled with mpich crashes

[Alastair McKinstry]

I can disable pmix support in mpich.

Pmix is working fine in openmpi, so it’s an mpich/pmix issue of some sort (or 
maybe ch4)

Regards
Alastair

On 22/02/2022, 14:57, "debian-science-maintainers on behalf of Drew Parsons" 
 wrote:

Package: mpich
Followup-For: Bug #1004556

My guess is that this bug is ongoing in 4.0-2 because of pmix support.

4.0-2 is still configured --with-pmix=/usr/lib/x86_64-linux-gnu/pmix2
and still Depends: libpmix2 (>= 4.1.2)

pmix support was added in 4.0~b1-2 along with ucx.

I gather ucx was deactivated in 4.0-2 but pmix was not. Looks like pmix
also needs to go (unless the problem is ch4, which was also added in
4.0~b1-2). But the error message references PMIX.


Ironically, I find that an executable compiled against mpich 4.0-1
fails with mpiexec.mpich (as raised in this bug) but actually passes
when run with mpiexec.openmpi.  Awkward.

-- 
debian-science-maintainers mailing list
debian-science-maintain...@alioth-lists.debian.net

https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#1000336: Upgrading tbb

[Andreas Tille]

Am Wed, Feb 23, 2022 at 12:31:07AM -0500 schrieb M. Zhou:
> Hello guys. Finally it's all green on our release architectures
> https://buildd.debian.org/status/package.php?p=onetbb=experimental
> 
> I shall request the slot for transition once finished the rebuild
> of its reverse dependencies and filed FTBFS bugs if any.

Sounds good - thanks a lot for your work on this

Andreas. 

-- 
http://fam-tille.de

Bug#1005438: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl"

[Andreas Tille]

Hi Stefano,

Am Wed, Feb 23, 2022 at 01:56:11AM + schrieb Stefano Rivera:
> Hi Andreas (2022.02.22_07:57:25_+)
> > I've put all developers mentioned as Uploader in CC.  Given that the
> > last non-team upload was two years ago which might have lead to the
> > situation that following upstream changes is stalled it would be great
> > if you confirm that you intend to continue working on this package.
> 
> I think it's high time to get pygame 2 into Debian. There's probably
> some transition required, and maybe some rev-deps will need to be
> removed, but pygame 1.9 isn't supportable forever.

Missing myself the slightest insight into pygame I'd say we should start
rather sooner than later.
 
> I've done some of the recent uploads, kicking the can down the road, but
> they're getting harder and harder.

Definitely.  And thanks for keeping it alife so far.

Kind regards

Andreas. 

-- 
http://fam-tille.de

Bug#1000336: Upgrading tbb

[M. Zhou]

Hello guys. Finally it's all green on our release architectures
https://buildd.debian.org/status/package.php?p=onetbb=experimental

I shall request the slot for transition once finished the rebuild
of its reverse dependencies and filed FTBFS bugs if any.

On Tue, 2022-02-08 at 17:59 -0500, M. Zhou wrote:
> Hi Diane,
> 
> Thank you. I have added that patch in the git repository.
> 
> On Tue, 2022-02-08 at 13:49 -0800, Diane Trout wrote:
> > Hi,
> > 
> > After Andreas pointed it out I looked through some of the build
> > failures for onetbb and talked to upstream about the i386 failure.
> > https://github.com/oneapi-src/oneTBB/issues/370#issuecomment-1030387116
> > 
> > They have a patch.
> > https://github.com/oneapi-src/oneTBB/commit/542a27fa1cfafaf76772e793549d9f4d288d03a9
> > 
> > I've tested it against a checkout of the 2021.5.0-1 version of onetbb
> > on i386 and it does build with it applied. Once there was a test
> > failure, and once all tests ran successfully
> > 
> > I see that you've made some more progress for the memory alignment
> > bugs
> > so I didn't commit "Detect 32 bit x86 systems while adding -mwaitpkg
> > option" i386 patch but could if you want.
> > 
> > Diane
> > 
> > 
> 

Bug#1006274: transition: rakudo

[M. Zhou]

On Tue, 2022-02-22 at 21:52 +0100, Sebastian Ramacher wrote:
> > 
> > Rakudo upstream has released 2022.02 version, and I have uploaded it to
> > experimental. In the past few weeks the architecture of the raku-*
> > packages has been changed to any, which means binnmus should be possible.
> > Shall we start the rakudo 2022.02 transition?
> 
> Please go ahead

Uploaded.

Bug#1002445: About shortuuid (was: FTBFS: AssertionError...)

[Kouhei Maeda]

Dear Martin.

I'm sorry.
Please go ahead.
--
Kouhei Maeda 
 KeyID 4096R/B8F286F62206360F7D4108172E8162547E37CE41


2022年1月30日(日) 18:51 Martin :

> Dear Kouhei Maeda,
>
> one of my packages, libervia-backend resp. salutatoi, depends on
> shortuuid and due to bug #1002445 of 2021-12-22 in shortuuid it will be
> removed from testing soon.
>
> If you don't have the time to fix the bug right now, I could make an NMU
> (non-maintainer upload), but I wonder, if it would be better to move the
> package to the "Debian Python Team"? That would allow many people to
> make changes, whenever necessary. You would remain in charge of the
> package, of course.
>
> Please, if you don't mind, just send me a short note "go ahead", and I
> would move the package to the team, fix the bug and update it!
>
> Many thanks in advance!
>
> Cheers, Martin
>

Bug#1006157: /lib/modules/5.16.0-1-sparc64-smp/kernel/fs/ext4/ext4.ko: [sparc64+ext4] reads see zeros w/ simultaneous write

[Noah Misch]

On Sun, Feb 20, 2022 at 03:31:27PM +0100, Salvatore Bonaccorso wrote:
> Unless mistaken this looks like to be an upstream issue, think would
> be better suited to directly report it upstream. Can you do so and
> keep us in the loop?

https://marc.info/?t=16453926991 has my upstream report.  Anatoly Pugachev
confirmed the behavior on sparc64 5.17.0-rc5, so I'm assuming this is not
Debian-specific.  I will update this bug with any major news.

Bug#1006296: ITP: git-credential-libsecret -- Git helper for accessing credentials via libsecret.

[Arnaud Rebillout]

On 2/23/22 05:20, M Hickford wrote:

Package: wnpp
Severity: wishlist
Owner: M Hickford 
X-Debbugs-Cc: debian-de...@lists.debian.org, mirth.hickf...@gmail.com

* Package name: git-credential-libsecret
* URL : 
https://github.com/git/git/commits/master/contrib/credential/libsecret/git-credential-libsecret.c
* License : GPL
   Programming Lang: C
   Description : Git helper for accessing credentials via libsecret.



FWIW this file is already shipped in the git package:

  $ apt-file search git-credential-libsecret
  git: 
/usr/share/doc/git/contrib/credential/libsecret/git-credential-libsecret.c


Cheers,

  Arnaud

Bug#1005006: [Debichem-devel] Bug#1005006: avogadro: manipulation tools do not work

[Aritz Erkiaga]

I've sent a pull request upstream to fix this bug: 
https://github.com/OpenChemistry/avogadrolibs/pull/825


While I'm very sure the fix can't cause further breakage, I'm still 
unsure how the problem actually arises.



Aritz Erkiaga

Bug#942851: perl-modules-5.30: CPAN.pm is insecure by default, no warnings

[Vincent Lefevre]

Now, there's CVE-2020-16156. If this bug had been fixed, the
vulnerability would have been avoided.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16156
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

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

Bug#1005438: pygame: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.10 3.9" --system=custom --test-args "/usr/bin/xvfb-run {interpreter} -m pygame.tests.__main__ --exclude opengl"

[Stefano Rivera]

Hi Andreas (2022.02.22_07:57:25_+)
> I've put all developers mentioned as Uploader in CC.  Given that the
> last non-team upload was two years ago which might have lead to the
> situation that following upstream changes is stalled it would be great
> if you confirm that you intend to continue working on this package.

I think it's high time to get pygame 2 into Debian. There's probably
some transition required, and maybe some rev-deps will need to be
removed, but pygame 1.9 isn't supportable forever.

I've done some of the recent uploads, kicking the can down the road, but
they're getting harder and harder.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#1006197: gpg hangs when importing keys with "gpg: waiting for lock (held by xxxxxxx) (deadlock?)"

[Ron Murray]

   After thinking about this a little more, I wondered whether the
trust db may have been corrupted (even a "list-keys" took a long time,
displaying messages about the trust db. Some Googling led me to the "--
update-trustdb" for gpg. It took a while to run, but it seems to have
fixed the problem.

   You can probably close this bug.

Thanks,

 .Ron

-- 
Ron Murray 
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761



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

Bug#1006303: vc4-drm: probe of gpu failed with error -2

[Andy Valencia]

Package: raspi-firmware
X-Debbugs-Cc: deb-b...@vsta.org
Version: 1.20220120+ds-1
Severity: important

Dear Maintainer,

After a dist-upgrade on 2/21/2021, DRM is apparently broken
on my 8gb Pi4:

[6.419137] vc4-drm gpu: failed to bind fe40.hvs (ops vc4_hvs_ops 
[vc4]): -2
[6.439133] vc4-drm gpu: master bind failed: -2
[6.455849] vc4-drm: probe of gpu failed with error -2

This is a stock install of bookworm/sid.  I can start Xorg,
but video rendering is via SDL:

[vo/sdl] Using opengl
[vo/sdl] Warning: this legacy VO has bad performance. Consider fixing your 
graphics drivers, or not forcing the sdl VO.

With marginal video rendering performance.

Before this latest update, it was working quite well.  apt
history does show the firmware being updated:

raspi-firmware:arm64 (1.20210805+ds-1, 1.20220120+ds-1)

(I can attach the full apt history if it helps.)

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

Kernel: Linux 5.16.0-1-arm64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages raspi-firmware depends on:
ii  dosfstools  4.2-1
ii  dpkg1.21.1

raspi-firmware recommends no packages.

raspi-firmware suggests no packages.

-- no debconf information

Bug#1006302: beav: reproducible-builds: BuildId differences in /usr/bin/beav caused by build paths.

[Vagrant Cascadian]

Source: beav
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The Build ID for /usr/bin/beav varies depending on the build path:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/beav.html

  Build·ID:·b98458c1b98af30cedde216318ef9d49db589091
  vs.
  Build·ID:·84365d92cbb6e196f85314ed4e72a254acdad00d


The attached patch to debian/rules fixes this by passing
-ffile-prefix-map via CFLAGS.


Alternately, updating the packaging to use dh/debhelper at a recent
compat level would also likely fix this.


There is one other outstanding issue with embedded timestamps (#777287)
that triggers reproducibility issues, but with both patches applied,
beav should build reproducibly on tests.reproducible-builds.org!


Given that Sam Hocevar is on the lowNMU list and hasn't responded to the
other patches on this package for some years, I plan to upload an NMU to
fix this soon.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#1006289: marisa's autopkgtest regressed since rebuild for ruby3.0 as default

[Gunnar Hjalmarsson]

X-Debbugs-Cc: kanash...@debian.org, terce...@debian.org

Hi Paul,

I submitted this MR:

https://salsa.debian.org/input-method-team/marisa/-/merge_requests/1

Can someone confirm that it would help?

One reason why I hesitate is that it would make ruby-marisa 
uninstallable in testing ATM.


--
Cheers,
Gunnar Hjalmarsson

Bug#700610: bsh (BeanShell) security vulnerability (CVE-2016-2510)

[Thorsten Glaser]

On Tue, 22 Feb 2022, Thomas Uhle wrote:

> What do you think, wouldn't it be time for an update in Debian?

The comment
> at https://github.com/beanshell/beanshell/issues/603 .
reads for me more like a “maybe remove it instead…”.

Honestly though, if it’s not available in Central, upstreams will
not use it and stick to old beta versions. If Debian has a newer
one, which may be incompatible, we’re inviting problems.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg


/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against  Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Tue, 2022-02-22 at 15:02 +0100, Marc Haber wrote:
> adduser --system should enforce policy for system users. The local
> administrator is free to ignore Debian policy as they see fit. adduser
> should not enforce things on the local admin that don't apply to them.
> 
> Maybe we add, some time in the future, an option --ignore-policy that a
> local admin can use, so that maintainer scripts get the support of
> policy enforcement.

I agree with this. The strictness should be something that can be
disabled if the local administrator so desires.

> > If useradd is intended to replace adduser, I would like to know as most
> > of my work would be lessened in importance.
> 
> I don't think there is any such intention in Debian. There is simply no
> mechanism to bring this forward other than talking and convincing each
> and every package maintainer.

It would be a ton of work. That's for sure.

-- 
Jason Franklin

Bug#1006301: unison-2.51+4.13.1 -addversionno is broken

[Vincent Lefevre]

Package: unison-2.51+4.13.1
Version: 2.51.5-1+b1
Severity: important

Like with unison-2.51+4.11.1 (Debian bug 990694), -addversionno is
broken:

$ unison-2.51+4.13.1 -addversionno foo ssh://localhost/foo2
Unison 2.51.5 (ocaml 4.13.1): Contacting server...
Connected to zira (from ::1)
OS: Debian GNU/Linux bookworm/sid [x86_64]
DISPLAY: localhost:10.0
zsh:1: command not found: unison-2.51
Fatal error: Lost connection with the server

Since the symlink unison-2.51 should currently point to the stable
version unison-2.51+4.11.1 (due to the old bug 990694) in order to
be able to synchronize with Debian/stable machines, there is no
real workaround. Fortunately, it seems that unison-2.51+4.11.1 and
unison-2.51+4.13.1 are completely compatible, no that nothing breaks
yet. But with a potentially incompatible future version, this could
make unison unusable when one has both Debian 11 bullseye and unstable
(future Debian 12) remote machines.

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

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

Versions of packages unison-2.51+4.13.1 depends on:
ii  libc6  2.33-7

Versions of packages unison-2.51+4.13.1 recommends:
ii  openssh-client [ssh-client]  1:8.8p1-1

unison-2.51+4.13.1 suggests no packages.

-- no debconf information

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

Bug#1005653: (no subject)

[Hubert Chathi]

On Mon, 21 Feb 2022 09:14:22 -0800, ZenWalker  said:

> maybe
> https://github.com/Nheko-Reborn/nheko/commit/b439e1fa41b26db5f1d0d16bd1da664338b435e7
> fixes the bug, which is included in version 0.9.1

> There is plans to package nheko 0.9.1 ?

Yes, I should be able to upload it in the next few days.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Noah Meyerhans]

On Tue, Feb 22, 2022 at 08:27:10PM +0100, Marco d'Itri wrote:
> On Feb 22, Noah Meyerhans  wrote:
> 
> > For servers, the ideal situation is somewhat less clear, but there was
> > at least some interest in using systemd-networkd (with or without
> > netplan).
> Why even consider netplan, I wonder?

It's not something I'm interested in, but there were some arguments made
in favor of it in the earlier thread.
https://lists.debian.org/debian-devel/2021/09/msg00410.html

Bug#1005187: collectd build-depends on package that is not in testing.

[Bernd Zeimetz]

On Tue, 2022-02-22 at 22:37 +, Peter Green wrote:
> 
> To the best of my knowledge there is no mechanism to automatically remove
> packages with broken build-dependencies from testing. I certainly
> don't recall collectd being listed for autoremoval at the time I filed the
> bug.

No idea, but things work as expected, got this mail on january 9th:

collectd 5.12.0-7 is marked for autoremoval from testing on 2022-02-04

It (build-)depends on packages with these RC bugs:
997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal
and no format arguments [-Werror=format-security]
 https://bugs.debian.org/997189


> 
> The auto-removals system does take account of reverse build-dependencies when
> deciding what extra removals to trigger, but unfortunately the same does not
> apply to manual removals by the release team.
> 

Not sure, but in the next mail the removal date changed, I'd assume as the
removal from testing was used as base date for the autoremoval, not the filed
bug:
(mail from january 31st)

collectd 5.12.0-8 is marked for autoremoval from testing on 2022-02-28

It (build-)depends on packages with these RC bugs:
1002985: ruby-redis, src:ruby-fakeredis: ruby-redis breaks ruby-fakeredis
autopkgtest
 https://bugs.debian.org/1002985
997189: liboping: FTBFS: oping.c:1159:25: error: format not a string literal
and no format arguments [-Werror=format-security]
 https://bugs.debian.org/997189


> In particular the following scenario can happen.
> 
> Package a build-depends (but does not depend) on package b.
> Package b is rc buggy.
> The autoremovals system sends out mails notifying maintainers that if the 
> situation doesn't change, it will remove packages b and a
> Package b gets manually removed by the release team.
> The package with the rc bug is no longer in testing, so it drops off the 
> autoremoval system's list of issues.
> Package a does not actually get autoremoved despite the earlier mail from the 
> autoremovals system.
> 
> I suspect that may well be what happened here (liboping was manually
> removed from testing as it was blocking the perl transition).
> > 
> > 

Don't think so, at least thats how I interpret the mails I've got.


> > It basically adds the extra work of tracking and closing this bug manually.
> 
> I understand that and that is why I am selective about when I file such bugs.
> If I see indications that the underlying issue is likely to be fixed on
> a reasonable timescale, I generally will hold-off filing bugs on the reverse
> dependencies.
> 
> In this case I saw no such indications. The bug report was over a month
> old with no maintainer response, and the package had not seen a maintainer
> upload in over a year.
> 


The maintainer is busy with real life, if I'd have known that it blocks the
perl transition, I'd have fixed oping earlier.



> > 
> > If you want to add such bugs, please link them properly to the bugs that
> > caused the issue and make sure that it is closed automatically as soon as 
> > the
> > issue is fixed.
> 
> If the bts had a system to automatically close bugs when another package 
> migrates
> to testing I would use it but afaict it doesn't.
> 
> I am not going to build custom automation for such a small volume of bugs.
> 

Ah thought that it would be automatically generated.

> It certainly makes sense to link to the underlying bug though, I'll try and 
> remember
> that next time.
> 

That would be appreciated.

> I guess I could also set "blocks", but i'm not entirely convinced it's 
> appropriate,
> it's the maintainers call not mine as to whether to fix the issue by fixing 
> the
> unmaintained package they build-depend on or by eliminating the 
> build-dependency
> on it.


True.


But I still think that these things shouldn't need manual investigation and
bugs at all, if autoremovals doesn't handle manual removals (I guess it does,
but add a delay), that should be fixed. Manually filing bugs also needs time.


Cheers,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#700610: bsh (BeanShell) security vulnerability (CVE-2016-2510)

[Thomas Uhle]

Dear maintainers,

there was published a new release of BeanShell 14 months ago. You can find 
the sources of version 2.1.0 on GitHub at


https://github.com/beanshell/beanshell/releases/tag/2.1.0

The new version has not been published on Maven though (where versions 
from 2.0b4 to 2.0b6 are still the newest releases), but this is explained 
on GitHub at https://github.com/beanshell/beanshell/issues/603 .
Anyway, version 2.1.0 is an official release linked from 
https://www.beanshell.org/download.html and there is also stated that 
version 2.0b4 is now merely a legacy release.


What do you think, wouldn't it be time for an update in Debian?

Best regards,

Thomas Uhle

Bug#1006300: src:libvirt: libvirt should no longer build the libvirt-daemon-driver-xen package on i386

[Maximilian Engelhardt]

Package: src:libvirt
Version: 8.0.0-1
Severity: normal
Tags: patch

Hi,

Starting with version 4.16, the xen package in Debian stopped building xen on
the i386 architecture. We only realized shortly after uploading to unstable
that this change also affects the packages that depend on us.

One step to clean this up now is to adjust libvirt accordingly and stop
building the libvirt-daemon-driver-xen package on i386.
Attached is a patch that does this by removing i386 from ARCHES_XEN as well as
adjusting package dependencies. Please review and apply the patch.

If you have any questions feel free to ask on #debian-xen or on the
pkg-xen-de...@lists.alioth.debian.org list.

Thanks,
Maxidiff -Nru libvirt-8.0.0/debian/changelog libvirt-8.0.0/debian/changelog
--- libvirt-8.0.0/debian/changelog	2022-01-22 19:22:57.0 +0100
+++ libvirt-8.0.0/debian/changelog	2022-02-21 23:13:01.0 +0100
@@ -1,3 +1,11 @@
+libvirt (8.0.0-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove i386 from ARCHES_XEN. Starting with xen version 4.16, xen is no
+longer built on the i386 architecture in Debian.
+
+ -- Maximilian Engelhardt   Mon, 21 Feb 2022 23:13:01 +0100
+
 libvirt (8.0.0-1) unstable; urgency=medium
 
   * [a26cc81] New upstream version 8.0.0
diff -Nru libvirt-8.0.0/debian/control libvirt-8.0.0/debian/control
--- libvirt-8.0.0/debian/control	2022-01-22 19:22:57.0 +0100
+++ libvirt-8.0.0/debian/control	2022-02-20 23:35:29.0 +0100
@@ -45,7 +45,7 @@
  libtirpc-dev,
  libudev-dev [linux-any],
  libwireshark-dev,
- libxen-dev [amd64 arm64 armhf i386],
+ libxen-dev [amd64 arm64 armhf],
  libxml2-dev,
  libxml2-utils,
  libyajl-dev,
@@ -221,7 +221,7 @@
 
 Package: libvirt-daemon-driver-xen
 Section: admin
-Architecture: amd64 arm64 armhf i386
+Architecture: amd64 arm64 armhf
 Multi-Arch: no
 Depends:
  libvirt-daemon (= ${binary:Version}),
@@ -474,7 +474,7 @@
 Multi-Arch: same
 Depends:
  libvirt0 (= ${binary:Version}),
- libxen-dev [i386 amd64 armhf arm64],
+ libxen-dev [amd64 armhf arm64],
  ${misc:Depends},
 Recommends:
  pkg-config,
diff -Nru libvirt-8.0.0/debian/rules libvirt-8.0.0/debian/rules
--- libvirt-8.0.0/debian/rules	2022-01-22 19:22:57.0 +0100
+++ libvirt-8.0.0/debian/rules	2022-02-20 23:38:09.0 +0100
@@ -16,7 +16,7 @@
 include /usr/share/dpkg/buildflags.mk
 
 ARCHES_LXC  = alpha amd64 arm64 armel armhf hppa i386 m68k mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
-ARCHES_XEN  = amd64 arm64 armhf i386
+ARCHES_XEN  = amd64 arm64 armhf
 ARCHES_VBOX = amd64 i386
 
 ifneq (,$(findstring $(DEB_HOST_ARCH_OS), linux))


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

Bug#1005187: collectd build-depends on package that is not in testing.

[Peter Green]

On 22/02/2022 12:57, Bernd Zeimetz wrote:

Hi,

I fail to understand why you are opening this bug at all.


rc bugs are how we track packages in testing that are not living up to the
standards Debian sets and ultimately trigger their removal.
"packages must be buildable within the same release" has been part of the rc
policy for as long as I can remember.


collectd would have been removed from testing automatically anyway, people
are notified about that.


To the best of my knowledge there is no mechanism to automatically remove
packages with broken build-dependencies from testing. I certainly
don't recall collectd being listed for autoremoval at the time I filed the
bug.

The auto-removals system does take account of reverse build-dependencies when
deciding what extra removals to trigger, but unfortunately the same does not
apply to manual removals by the release team.

In particular the following scenario can happen.

Package a build-depends (but does not depend) on package b.
Package b is rc buggy.
The autoremovals system sends out mails notifying maintainers that if the 
situation doesn't change, it will remove packages b and a
Package b gets manually removed by the release team.
The package with the rc bug is no longer in testing, so it drops off the 
autoremoval system's list of issues.
Package a does not actually get autoremoved despite the earlier mail from the 
autoremovals system.

I suspect that may well be what happened here (liboping was manually
removed from testing as it was blocking the perl transition).


It basically adds the extra work of tracking and closing this bug manually.


I understand that and that is why I am selective about when I file such bugs.
If I see indications that the underlying issue is likely to be fixed on
a reasonable timescale, I generally will hold-off filing bugs on the reverse
dependencies.

In this case I saw no such indications. The bug report was over a month
old with no maintainer response, and the package had not seen a maintainer
upload in over a year.



If you want to add such bugs, please link them properly to the bugs that
caused the issue and make sure that it is closed automatically as soon as the
issue is fixed.


If the bts had a system to automatically close bugs when another package 
migrates
to testing I would use it but afaict it doesn't.

I am not going to build custom automation for such a small volume of bugs.

It certainly makes sense to link to the underlying bug though, I'll try and 
remember
that next time.

I guess I could also set "blocks", but i'm not entirely convinced it's 
appropriate,
it's the maintainers call not mine as to whether to fix the issue by fixing the
unmaintained package they build-depend on or by eliminating the build-dependency
on it.

Bug#1006299: capnproto: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: capnproto
Version: 0.8.0-2
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Your package is failing to build using OpenSSL 3.0 with the
following error:

| kj/compat/tls.c++:334: unimplemented bio_ctrl; cmd = 73
| kj/compat/tls-test.c++:487: failed: expected 
::kj::_::hasSubstring(e->getDescription(), message); exception description 
didn't contain expected substring; e->getDescription() = TLS peer's certificate 
is not trusted; reason = self-signed certificate
| stack: 55cd3a1bae3a 55cd3a1b4b74 55cd3a1b4ef9 7f3b37dad28d 7f3b37d5747b 
7f3b37dae0b1 7f3b37dae8e1 7f3b37d84d8f 7f3b37d5747b 7f3b37d80d41 7f3b37dac4cc 
7f3b379417ec 55cd39f65b19
| [ FAIL ] kj/compat/tls-test.c++:490: TLS certificate validation (69115 μs)
| [ TEST ] kj/compat/tls-test.c++:508: TLS client certificate verification
…
| 
| kj/compat/tls.c++:334: unimplemented bio_ctrl; cmd = 76
| kj/compat/tls.c++:334: unimplemented bio_ctrl; cmd = 76
| kj/compat/tls.c++:62: failed: OpenSSL error; message = error:1669:STORE 
routines::unregistered scheme
| error:8002:system library::No such file or directory
| stack: 7f3b37e906b9 7f3b37e90a14 7f3b37e01b00 7f3b37e01a1b 55cd3a1b3254 
7f3b37dad28d
| [ FAIL ] kj/compat/tls-test.c++:508: TLS client certificate verification 
(69064 μs)
| 
…
| 859 test(s) passed 
| 2 test(s) failed 
| FAIL: capnp-test
| Randomly testing backwards-compatibility scenarios with seed: 1644880416
| PASS: capnp-evolution-test
| PASS: src/capnp/compiler/capnp-test.sh
| ===
| 1 of 3 tests failed
| Please report to capnpr...@googlegroups.com
| ===
| make[4]: *** [Makefile:3441: check-TESTS] Error 1

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006297: caml-crush: FTBFS with OpenSSL 3.0

[Sebastian Andrzej Siewior]

Source: caml-crush
Version: 1.0.12-1
Severity: important
Tags: bookworm sid
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: ftbfs-3.0

Your package is failing to build using OpenSSL 3.0 with the
following error:

| checking OCaml package nettls-gnutls... found
| configure: Using native C RPC over ssl (OpenSSL) for client side ...
| checking for openssl/ssl.h... yes
| checking for SSL_read in -lssl... yes
| checking for OPENSSL_init_ssl in -lssl... yes
| checking for SSL_write in -lssl... yes
| configure: Openssl >= 1.1.0 detected
| checking for OPENSSL_init_ssl in -lssl... (cached) yes
| checking for SSL_CTX_new in -lssl... yes
| checking for SSL_CTX_load_verify_locations in -lssl... yes
| checking for SSL_CTX_use_certificate_file in -lssl... yes
| checking for SSL_CTX_use_PrivateKey_file in -lssl... yes
| checking for SSL_CTX_check_private_key in -lssl... yes
| checking for SSL_new in -lssl... yes
| checking for SSL_set_fd in -lssl... yes
| checking for SSL_connect in -lssl... yes
| checking for SSL_get_peer_certificate in -lssl... no
| configure: error: Cannot find symbol in openssl library.
|   cd build-SERVER && tail -v -n \+0 config.log
| ==> config.log <==
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.

For more information see:
https://www.openssl.org/docs/man3.0/man7/migration_guide.html

Sebastian

Bug#1006298: RFP: turbowarp -- TurboWarp as a desktop app

[Hilmar Preusse]

Package: wnpp
Severity: wishlist

* Package name: turbowarp
  Version : 1.1.3
  Upstream Author : https://github.com/GarboMuffin
* URL : https://desktop.turbowarp.org/
* License : GPL-3
  Programming Lang: Javascript
  Description : TurboWarp as a desktop app

TurboWarp as a desktop app.

Use TurboWarp, the scratch mod with a compiler, dark mode,
addons and more, with an app on your desktop. It also works
when you are offline.

TurboWarp is not affiliated with Scratch, the Scratch Team,
or the Scratch Foundation. 

 - There does not seem to be a new version of package
   "scratch" for Linux any more in upstream. This package will
   be a replacement, which seems to work fine.
 - Currently I don't plan to maintain this package myself at
   all as I'm not familiar with the build system. I'm willing
   to contribute if needed. The upstream provides a separate
   Debian package, which could be useful if the sources are
   available.


signature.asc
Description: PGP signature

Bug#1006296: ITP: git-credential-libsecret -- Git helper for accessing credentials via libsecret.

[M Hickford]

Package: wnpp
Severity: wishlist
Owner: M Hickford 
X-Debbugs-Cc: debian-de...@lists.debian.org, mirth.hickf...@gmail.com

* Package name: git-credential-libsecret
* URL : 
https://github.com/git/git/commits/master/contrib/credential/libsecret/git-credential-libsecret.c
* License : GPL
  Programming Lang: C
  Description : Git helper for accessing credentials via libsecret.

Bug#1006294: bullseye-pu: package knewstuff/5.78.0-4

[Patrick Franz]

Package: release.debian.org
Severity: important
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org

[ Reason ]
A bug in plasma-discover causes a Denial of Service attack
against the KDE servers. 3 packages needs to be patch to
mitigate the attack: knewstuff, plasma-desktop and
plasma-discover.
This update fixes bug #1006126 for bullseye and has been 
fixed in unstable in version 5.90.0-1 for knewstuff.

[ Impact ]
Running the old version causes considerable load for the KDE
servers.

[ Tests ]
No manual tests have been performed.

[ Risks ]
The risks are rather low as the update is a single patch.
The patch has been created by KDE upstream specifically for the
version in bullseye.

[ 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 update contains a single patch to help ease the load on
KDE servers.

[ Other info ]
It would be good if users of KDE plasma could receive the update
as quick as possible.
diffstat for knewstuff-5.78.0 knewstuff-5.78.0

 changelog   |8 
 patches/knewstuff_dns.patch |   28 
 patches/series  |1 +
 3 files changed, 37 insertions(+)

diff -Nru knewstuff-5.78.0/debian/changelog knewstuff-5.78.0/debian/changelog
--- knewstuff-5.78.0/debian/changelog   2021-02-24 23:04:55.0 +0100
+++ knewstuff-5.78.0/debian/changelog   2022-02-22 22:02:10.0 +0100
@@ -1,3 +1,11 @@
+knewstuff (5.78.0-4+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Cherry-pick commit to fix the Denial of Service bug in Discover
+(Closes: #1006126).
+
+ -- Patrick Franz   Tue, 22 Feb 2022 22:02:10 +0100
+
 knewstuff (5.78.0-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru knewstuff-5.78.0/debian/patches/knewstuff_dns.patch 
knewstuff-5.78.0/debian/patches/knewstuff_dns.patch
--- knewstuff-5.78.0/debian/patches/knewstuff_dns.patch 1970-01-01 
01:00:00.0 +0100
+++ knewstuff-5.78.0/debian/patches/knewstuff_dns.patch 2022-02-22 
21:57:05.0 +0100
@@ -0,0 +1,28 @@
+From abaa25340b96307fcc7e586ed00bfde67500b57d Mon Sep 17 00:00:00 2001
+From: Aleix Pol 
+Date: Tue, 8 Feb 2022 11:48:11 +0100
+Subject: [PATCH] Engine: Ensure we are not using the wrong ProvidersUrl
+
+---
+ src/core/engine.cpp | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/core/engine.cpp b/src/core/engine.cpp
+index c5894747..30fdf2bb 100644
+--- a/src/core/engine.cpp
 b/src/core/engine.cpp
+@@ -237,7 +237,10 @@ bool Engine::init(const QString )
+ 
+ qCDebug(KNEWSTUFFCORE) << "Categories: " << m_categories;
+ m_providerFileUrl = group.readEntry("ProvidersUrl");
+-
++if (m_providerFileUrl == 
QLatin1String("https://download.kde.org/ocs/providers.xml;)) {
++m_providerFileUrl = 
QStringLiteral("https://autoconfig.kde.org/ocs/providers.xml;);
++qCWarning(KNEWSTUFFCORE) << "Please make sure" << configfile << "has 
ProvidersUrl=https://autoconfig.kde.org/ocs/providers.xml;;
++}
+ d->tagFilter = group.readEntry("TagFilter", 
QStringList(QStringLiteral("ghns_excluded!=1")));
+ d->downloadTagFilter = group.readEntry("DownloadTagFilter", 
QStringList());
+ 
+-- 
+GitLab
+
diff -Nru knewstuff-5.78.0/debian/patches/series 
knewstuff-5.78.0/debian/patches/series
--- knewstuff-5.78.0/debian/patches/series  2021-02-24 11:36:14.0 
+0100
+++ knewstuff-5.78.0/debian/patches/series  2022-02-22 21:57:39.0 
+0100
@@ -1 +1,2 @@
 
upstream-a3050ecf-qtquickengine-check-knscore-engine-is-valid-before-search.patch
+knewstuff_dns.patch

Bug#1006293: bullseye-pu: package plasma-desktop/4:5.20.5-4

[Patrick Franz]

Package: release.debian.org
Severity: important
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org

[ Reason ]
A bug in plasma-discover causes a Denial of Service attack
against the KDE servers. 3 packages needs to be patch to
mitigate the attack: knewstuff, plasma-desktop and
plasma-discover.
This update fixes bug #1006125 for bullseye and has been 
fixed in unstable.

[ Impact ]
Running the old version causes considerable load for the KDE
servers.

[ Tests ]
No manual tests have been performed.

[ Risks ]
The risks are rather low as the update is a single patch.
The patch has been created by KDE upstream specifically for the
version in bullseye.

[ 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 update contains a single patch to help ease the load on
KDE servers.

[ Other info ]
It would be good if users of KDE plasma could receive the update
as quick as possible.
diffstat for plasma-desktop-5.20.5 plasma-desktop-5.20.5

 changelog|8 
 patches/plasma-desktop-dns.patch |   39 +++
 patches/series   |1 +
 3 files changed, 48 insertions(+)

diff -Nru plasma-desktop-5.20.5/debian/changelog 
plasma-desktop-5.20.5/debian/changelog
--- plasma-desktop-5.20.5/debian/changelog  2021-02-24 13:35:04.0 
+0100
+++ plasma-desktop-5.20.5/debian/changelog  2022-02-20 18:50:03.0 
+0100
@@ -1,3 +1,11 @@
+plasma-desktop (4:5.20.5-4+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Cherry-pick commit to fix the Denial of Service bug in Discover
+(Closes: #1006125).
+
+ -- Patrick Franz   Sun, 20 Feb 2022 18:50:03 +0100
+
 plasma-desktop (4:5.20.5-4) unstable; urgency=medium
 
   * Team upload.
diff -Nru plasma-desktop-5.20.5/debian/patches/plasma-desktop-dns.patch 
plasma-desktop-5.20.5/debian/patches/plasma-desktop-dns.patch
--- plasma-desktop-5.20.5/debian/patches/plasma-desktop-dns.patch   
1970-01-01 01:00:00.0 +0100
+++ plasma-desktop-5.20.5/debian/patches/plasma-desktop-dns.patch   
2022-02-20 18:40:00.0 +0100
@@ -0,0 +1,39 @@
+Author: Dan Leinir Turthra Jensen 
+Description: Fix Denial of Service bug in Discover.
+Forwarded: not-needed
+
+---
+ attica-kde/kdeplugin/kdeplatformdependent.cpp | 19 +++
+ 1 file changed, 19 insertions(+)
+
+diff --git a/attica-kde/kdeplugin/kdeplatformdependent.cpp 
b/attica-kde/kdeplugin/kdeplatformdependent.cpp
+index fbc15ec4e..2c21fe7e6 100644
+--- a/attica-kde/kdeplugin/kdeplatformdependent.cpp
 b/attica-kde/kdeplugin/kdeplatformdependent.cpp
+@@ -125,6 +125,25 @@ QNetworkRequest 
KdePlatformDependent::addOAuthToRequest(const QNetworkRequest 
+ const QString bearer = bearer_format.arg(token);
+ notConstReq.setRawHeader("Authorization", bearer.toUtf8());
+ }
++
++// Add cache preference in a granular fashion (we will almost certainly 
want more of these, but...)
++static const QStringList 
preferCacheEndpoints{QLatin1String{"/content/categories"}};
++for (const QString  : preferCacheEndpoints) {
++if (notConstReq.url().toString().endsWith(endpoint)) {
++QNetworkCacheMetaData 
cacheMeta{m_accessManager->cache()->metaData(notConstReq.url())};
++if (cacheMeta.isValid()) {
++// If the expiration date is valid, but longer than 24 hours, 
don't trust that things
++// haven't changed and check first, otherwise just use the 
cached version to relieve
++// server strain and reduce network traffic.
++const QDateTime 
tomorrow{QDateTime::currentDateTime().addDays(1)};
++if (cacheMeta.expirationDate().isValid() && 
cacheMeta.expirationDate() < tomorrow) {
++
notConstReq.setAttribute(QNetworkRequest::CacheLoadControlAttribute, 
QNetworkRequest::PreferCache);
++}
++}
++break;
++}
++}
++
+ return notConstReq;
+ }
+ 
+-- 
diff -Nru plasma-desktop-5.20.5/debian/patches/series 
plasma-desktop-5.20.5/debian/patches/series
--- plasma-desktop-5.20.5/debian/patches/series 2021-02-24 13:33:20.0 
+0100
+++ plasma-desktop-5.20.5/debian/patches/series 2022-02-20 18:44:56.0 
+0100
@@ -3,3 +3,4 @@
 upstream_5.21+lts_folder_view_de-duplicate_switch_width_height_logic.patch
 upstream_5.21+lts_folder_view_Fix_display_on_not-skinny_vertical_panels.patch
 upstream-1be25dec-fix-crash-deleting-from-activity-manager.patch
+plasma-desktop-dns.patch

Bug#1006292: bullseye-pu: package plasma-discover/5.20.5-3

[Patrick Franz]

Package: release.debian.org
Severity: important
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: delta...@debian.org, debian-qt-...@lists.debian.org

[ Reason ]  
A bug in plasma-discover causes a Denial of Service attack
against the KDE servers. 3 packages needs to be patch to
mitigate the attack: knewstuff, plasma-desktop and 
plasma-discover.
This update fixes bug #1006124 for bullseye and has been
fixed in unstable.

[ Impact ]
Running the old version causes considerable load for the KDE
servers.

[ Tests ] 
No manual tests have been performed. 

[ Risks ] 
The risks are rather low as the update is a single patch.
The patch has been created by KDE upstream specifically for the
version in bullseye.

[ 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 update contains a single patch to help ease the load on 
KDE servers.

[ Other info ]
It would be good if users of KDE plasma could receive the update
as quick as possible.
diffstat for plasma-discover-5.20.5 plasma-discover-5.20.5

 changelog  |8 
 patches/discover_dns.patch |   31 +++
 patches/series |1 +
 3 files changed, 40 insertions(+)

diff -Nru plasma-discover-5.20.5/debian/changelog 
plasma-discover-5.20.5/debian/changelog
--- plasma-discover-5.20.5/debian/changelog 2021-03-10 23:53:46.0 
+0100
+++ plasma-discover-5.20.5/debian/changelog 2022-02-22 22:20:28.0 
+0100
@@ -1,3 +1,11 @@
+plasma-discover (5.20.5-3+deb11u1) bullseye; urgency=medium
+
+  * Team upload.
+  * Cherry-pick commit to fix the Denial of Service bug in Discover
+(Closes: #1006124).
+
+ -- Patrick Franz   Tue, 22 Feb 2022 22:20:28 +0100
+
 plasma-discover (5.20.5-3) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru plasma-discover-5.20.5/debian/patches/discover_dns.patch 
plasma-discover-5.20.5/debian/patches/discover_dns.patch
--- plasma-discover-5.20.5/debian/patches/discover_dns.patch1970-01-01 
01:00:00.0 +0100
+++ plasma-discover-5.20.5/debian/patches/discover_dns.patch2022-02-22 
22:17:27.0 +0100
@@ -0,0 +1,31 @@
+From efb34c2aa235b703bc55cb9b37fedebed0ac7df8 Mon Sep 17 00:00:00 2001
+From: Ben Cooksley 
+Date: Mon, 7 Feb 2022 06:39:12 +1300
+Subject: [PATCH] Disable the building of the KNS backend until it can be
+ corrected to not cause a Denial of Service attack on KDE.org infrastructure.
+
+(cherry picked from commit f66df3531670592960167f5060feeed6d6c792be)
+---
+ libdiscover/backends/CMakeLists.txt | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/libdiscover/backends/CMakeLists.txt 
b/libdiscover/backends/CMakeLists.txt
+index 5f87f639f..0fbdc524f 100644
+--- a/libdiscover/backends/CMakeLists.txt
 b/libdiscover/backends/CMakeLists.txt
+@@ -8,9 +8,9 @@ function(add_unit_test name)
+ Qt5::Test Qt5::Core ${EXTRA_LIBS})
+ endfunction()
+ 
+-if(KF5Attica_FOUND AND KF5NewStuff_FOUND)
+-   add_subdirectory(KNSBackend)
+-endif()
++#if(KF5Attica_FOUND AND KF5NewStuff_FOUND)
++#   add_subdirectory(KNSBackend)
++#endif()
+ 
+ if(packagekitqt5_FOUND AND AppStreamQt_FOUND)
+ add_subdirectory(PackageKitBackend)
+-- 
+GitLab
+
diff -Nru plasma-discover-5.20.5/debian/patches/series 
plasma-discover-5.20.5/debian/patches/series
--- plasma-discover-5.20.5/debian/patches/series2021-03-10 
23:53:46.0 +0100
+++ plasma-discover-5.20.5/debian/patches/series2022-02-22 
22:17:51.0 +0100
@@ -1 +1,2 @@
 https_only_links.patch
+discover_dns.patch

Bug#1001652: Please update package to latest release, which is Rapid Photo Downloader 0.9.29

[Damon Lynch]

As always the tarball is available at https://launchpad.net/rapid/+download

Rapid Photo Downloader 0.9.29 does not contain any new package
requirements compared to 0.9.27, but it does contain new requirements
compared to the existing package in Debian. Among them is a new Python
package that is not in Debian:

https://github.com/damonlynch/showinfilemanager

In my initial bug report to make the package update request, I
mistakenly listed fuse as a dependency. I wrongly assumed fuse was a
dependency of ifuse, which is required by Rapid Photo Downloader
0.9.27 onward. However it turns out that fuse3 is now preferred to
fuse.

Thanks,
Damon
-- 
https://damonlynch.net

Bug#878192: Info received ()

[Deborah Perro]

Fuck Off
On Tue, Feb 22, 2022 at 1:27 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> 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):
>  Debian Cloud Team 
>
> If you wish to submit further information on this problem, please
> send it to 878...@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.
>
> --
> 878192: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878192
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1006291: python-dbusmock: Include bluetooth discoverable fix

[Jeremy Bicha]

Source: python-dbusmock
Version: 0.25.0-1
X-Debbugs-CC: mp...@debian.org

Could you include this commit in Debian?

https://github.com/martinpitt/python-dbusmock/commit/b6cc605d

The latest release of gnome-bluetooth (42 Beta) includes a build test
that depends on behavior fixed by that commit.

Thank you,
Jeremy Bicha

Bug#1006290: kvmtoo: CVE-2021-45464: hypervisor escape and host code execution

[Salvatore Bonaccorso]

Source: kvmtool
Version: 0.20170904-1.1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for kvmtool.

CVE-2021-45464[0]:
| hypervisor escape and host code execution

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-45464
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45464
[1] https://www.kalmarunionen.dk/writeups/2021/hxp-2021/lkvm/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1006289: marisa's autopkgtest regressed since rebuild for ruby3.0 as default

[Paul Gevers]

Source: marisa
Version: 0.2.6-8
Severity: serious
X-Debbugs-Cc: kanash...@debian.org, terce...@debian.org

Dear maintainer,

As part of the ongoing transition from ruby2.7 as default ruby to
ruby3.0 as default, your package got rebuild. In that rebuild it
correctly picked up a dependency on libruby3.0, but as it also depends
on ruby (unversioned) it seems to not be able to work in testing, as
seen by the autopkgtest regression.

I don't know what the best way forward is, but I think the right
version of ruby needs to be detected during build and included in
${misc:Depends} or something similar. I have included two ruby
maintainers in the X-Debbugs-CC for advice.

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/m/marisa/19472910/log.gz

[...]

Setting up libruby3.0:amd64 (3.0.2-7) ...
Setting up libruby2.7:amd64 (2.7.4-1+b1) ...
Setting up ruby2.7 (2.7.4-1+b1) ...
Setting up ruby (1:2.7.6) ...

[...]

autopkgtest [20:54:51]: test ruby: [---
=== ruby ===
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require': 
cannot load such file -- marisa (LoadError)
from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
from bindings/ruby/sample.rb:1:in `'
autopkgtest [20:54:51]: test ruby: ---]

Bug#1006288: prebuild and/or cache pages of some packages

[Geert Stappers]

Package: bugs.debian.org
Severity: wishlist


Hello Debian BTS People,


https://bugs.debian.org/foo gets redirected
to https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foo;dist=unstable
and then gets 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foo;dist=unstable
build.

In case package "foo" has many bugs is the response time very long.

The idea c.q. wish is to prebuild and/or cache pages
for packages like "linux" and "wnpp".


Not hindered by implementation knowledge, I would make cronjob that
captures the output of 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable
and store it at https://bugs.debian.org/wnpp and tell the webserver
to NOT redirect to the cgi-bin/pkgreport.cgi for package wnpp

 
Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1006274: transition: rakudo

[Sebastian Ramacher]

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/rakudo.html

On 2022-02-22 09:45:35, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> Rakudo upstream has released 2022.02 version, and I have uploaded it to
> experimental. In the past few weeks the architecture of the raku-*
> packages has been changed to any, which means binnmus should be possible.
> Shall we start the rakudo 2022.02 transition?

Please go ahead

> BTW, since we have a permanent transition tracker
> https://release.debian.org/transitions/html/rakudo.html
> Do we have to request for transition slot every time?

Yes. As the current setup requires a lockstep transition, this is
ideally coordinated with us. We want to avoid conflicts between such
lockstep transitions and other transition.

In any case you would need to ask for binNMUs anways. The best place to
coordinate those rebuilds is a tranistion bug.

Cheers

> 
> Thanks!
> 
> Ben file:
> 
> title = "rakudo";
> is_affected = .depends ~ "raku-api-2021.12" | .depends ~ "raku-api-2022.02";
> is_good = .depends ~ "raku-api-2022.02";
> is_bad = .depends ~ "raku-api-2021.12";
> Thank you for using reportbug
> 

-- 
Sebastian Ramacher

Bug#1005693: Bug#1005884: iwlwifi bug fix

[Salvatore Bonaccorso]

Hi Bernhard,

On Tue, Feb 22, 2022 at 07:34:17AM +, Bernhard wrote:
> Hello Holger
> Hello Salvatore
> 
> This bugfix also closes my installation report #1005693.
> Do you think, you can release 5.16.10-2 with this bugfix in the next
> days?
> Without this bugfix, installation of sid with iwlwifi card present in
> the system is not possible.

Not sure yet. While I have already cherry-picked the respective commit
(cf.
https://salsa.debian.org/kernel-team/linux/-/commit/ec0760c7cc4bbaccc913df3e22fd3e296c519936)
for the next upload, I'm actually pondering to move on the next stable
import (5.16.11, to be released tomorrow).

Regards,
Salvatore

Bug#1006219: new expat causes regressions in the python autopkg tests

[Salvatore Bonaccorso]

Hi Matthias

On Mon, Feb 21, 2022 at 09:35:06PM +0100, Matthias Klose wrote:
> On 2/21/22 21:31, Salvatore Bonaccorso wrote:
> > Control: forwarded -1 https://bugs.python.org/issue46811
> > Control: affects -1 + src:expat
> > Control: clone -1 -2 -3
> > Control: reassign -1 src:python3.10 3.10.2-1
> > Control: reassign -2 src:python3.9 3.9.10-1
> > Control: reassign -3 src:python2.7 2.7.18-12
> > 
> > Hi László, hi Matthias,
> > 
> > On Mon, Feb 21, 2022 at 08:44:26PM +0100, Salvatore Bonaccorso wrote:
> >> Hi,
> >>
> >> On Mon, Feb 21, 2022 at 05:10:02PM +0100, László Böszörményi wrote:
> >>> Control: tags -1 +confirmed
> >>>
> >>> Hi Matthias,
> >>>
> >>> On Mon, Feb 21, 2022 at 2:57 PM Matthias Klose  wrote:
>  The new expat causes regressions in the python autopkg tests. I also see 
>  there
>  is a new upstream 2.4.6. Didn't check that yet.
> >>>  Basically 2.4.5-2 and 2.4.6 should be identical. I can package the
> >>> latter for you if you want.
> >>> Will contact upstream about this and see what he finds.
> >>
> >> It looks this is actually an issue in python's testsuite. Upstream
> >> report is at https://bugs.python.org/issue46811 and
> >> https://github.com/python/cpython/pull/31453 .
> > 
> > So given the above, I'm trying to reassign it now to the relevant
> > python packages accordingly, bear with me that I have not done
> > mistkaes with the control commands.
> 
> thanks for looking at these. I'll prepare uploads soonish.

many thanks!

Regards,
Salvatore

Bug#1006284: the idea

[Geert Stappers]

Something like https://bugs.debian.org/debbugs-source/mainline/README.md
but with a recent file date. ( I fear that content from 2015-02-10
is outdated.)

Bug#1005889: dbus: flaky autopkgtest on ppc64el: dbus/integration/transient-services.sh.test

[Paul Gevers]

Hi,

On 21-02-2022 20:03, Paul Gevers wrote:

I have a possible patch which I'll upload soon. Would you be able to
schedule several consecutive runs on the affected hardware to make
sure it's really fixed? 10 runs should be enough for a reasonable level
of confidence.


Sure, but anybody (with Salsa credentials) can schedule those jobs. Just 
hitting the retry button will do. Results should be fast too as they are 
scheduled with higher prio.


11 runs happened. None of them failed.

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006287: RFS: hpnssh/1:8.8p1-hpn16v1-9 [ITP] -- high performance secure shell client and server (metapackage)

[rapier]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "hpnssh":

 * Package name: hpnssh
   Version : 1:8.8p1-hpn16v1-9
   Upstream Author : rap...@psc.edu
 * URL : http://www.hpnssh.org/
 * License : Mazieres-BSD-style, 
Expat-with-advertising-restriction, OpenSSH, Beer-ware, 
Powell-BSD-style, BSD-3-clause, public-domain

 * Vcs : https://github.com/rapier1/openssh-portable
   Section : net


HPNSSH is a fork of OpenSSH focused on high throughput and performance 
for high speed networks. In addition to significant improved throughput 
this package provides enhanced functionality such as resuming failed scp 
transfers, OOB TCP stack instrument reporting for diagnostics, a 
threaded AES-CTR cipher, the uses of a null cipher post-authentication 
for non-interactive session (data transfer), and so forth. More 
information can be found at https://psc.edu/hpn-ssh-home. This work is 
funded by the National Science Foundation (award #: 2004012 
https://nsf.gov/awardsearch/showAward?AWD_ID=2004012).


HPNSSH does not conflict with existing OpenSSH installations.

It builds those binary packages:

  hpnssh-client - secure shell (SSH) client, for secure access to 
remote machines
  hpnssh-server - secure shell (SSH) server, for secure access from 
remote machines
  hpnssh-sftp-server - secure shell (SSH) sftp server module, for SFTP 
access from remote machines

  hpnssh-tests - OpenSSH regression tests
  hpnssh - secure shell client and server (metapackage)
  hpnssh-askpass-gnome - interactive X program to prompt users for a 
passphrase for ssh-add

  hpnssh-client-udeb - secure shell client for the Debian installer
  hpnssh-server-udeb - secure shell server for the Debian installer

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hpnssh/hpnssh_8.8p1-hpn16v1-9.dsc


Changes for the initial release:

 hpnssh (1:8.8p1-hpn16v1-9) sid; urgency=medium
 .
   * Updated copyright.
   * Updated some debian files to work under debian as opposed
 to ubuntu. Specifically hpnssh-server.runit so it creates the
 correct diretcory in /etc/sv

Regards,
--
  Chris Rapier

Bug#1006286: hivex: wrongly detects ruby versions during build

[Paul Gevers]

Source: hivex
Version: 1.3.21-1
Severity: serious
Tags: patch
Justification: FTBFS
Control: block 1004915 by -1

Dear maintainer,

>From https://salsa.debian.org/libvirt-team/hivex/-/merge_requests/1
'''
It fixes a FTBFS against ruby3.0 (ongoing transition). This is the
same patch proposed here to libguestfs:

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

This isn't totally true as it doesn't FTBFS (yet), but if fails to
pick up a dependency on ruby3.0, which is now the default ruby,
causing the transition to delay.

Paul

Bug#981878: ruby-gitlab-pg-query downloads from the internet during the build

[Paul Gevers]

Hi Pirate,

On Sun, 07 Mar 2021 00:47:46 +0530 Pirate Praveen 
 wrote:
Once ruby-pg-query is accepted 
and its reverse dependencies switch to the new package, I will request 
removal of this package.


What's the status on this?

Paul
PS: please CC, I'm not subscribed


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1006284: a README at debbugs-source

[Geert Stappers]

Package: bugs.debian.org
Severity: normal


Hello Debian BTS people,


The webpage of this issue links
to https://bugs.debian.org/debbugs-source/

Over there is currently:

Index of /debbugs-source
[ICO]   Name  Last modified   Size
[PARENTDIR]   Parent Directory-
[DIR]   bugscan.git/  2019-08-24 00:08-
[DIR]   bugscan.old/  2011-06-16 17:06-
[DIR]   bugscan/  2019-08-24 00:08-
[DIR]   debbugs-database/ 2018-03-28 23:11-
[DIR]   debbugs-package-update.git/   2018-11-02 05:56-
[DIR]   debbugs.git/  2022-01-12 05:26-
[DIR]   debian-pregit/2012-03-23 02:37-
[DIR]   debian.old/   2010-05-04 21:03-
[DIR]   debian/   2018-03-29 21:49-
[DIR]   mainline-pregit/  2012-03-23 02:37-
[DIR]   mainline/ 2019-11-24 04:37-
[TXT]   update_branch.sh  2012-03-23 15:291.6K
[ ]   update_branch.sh_bak2007-03-08 02:25540
Apache Server at bugs.debian.org Port 443



It would be an improvement if there is a "README" file
that describes what the visitor is looking at
and tells what the visitor might be looking for.
 


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#881541: (no subject)

[Kacper Gutowski]

close 881541
thanks

This is long obsolete and not found in 
any of the versions still supported.


-k

Bug#898089: reproducable

[Geert Stappers]

FYI

Triggering the 500 Internal Server Error was today possible.


In other words:  I should not close this old bug report.

Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Marco d'Itri]

On Feb 22, Noah Meyerhans  wrote:

> For servers, the ideal situation is somewhat less clear, but there was
> at least some interest in using systemd-networkd (with or without
> netplan).
Why even consider netplan, I wonder?

> So we may not need to specifically promote a DHCP client like dhcpcd5 to
> priority:important.  Systemd-networkd could be the default, and
> NetworkManager could be used when it's present.
I agree: while dhcpcd5 appears to be very good I do not think that it 
should be the default DHCP client since we already have very popular 
clients in the default Debian installations.
NetworkManager works great as the default client on desktops and 
systemd-networkd is more than enough for typical servers.

BTW: iwd, which at some point I expect should replace wpa_supplicant, 
has its own built-in DHCP client too.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Martin-Éric Racine]

On Tue, Feb 22, 2022 at 9:14 PM Noah Meyerhans  wrote:
> On Tue, Feb 22, 2022 at 11:22:08AM +0200, Martin-Éric Racine wrote:
> > Given how upstream ISC will stop development of its DHCP suite by the end 
> > of 2022 [1], Debian will need to select a new stock DHCP client to ship 
> > with Priority:Important.
> >
> > dhcpcd5 seems like the most potential replacement. It covers most IPv4 and 
> > IPv6 usage cases, and upstream regularly updates the code. However, the 
> > Debian package hasn't been updated in ages.
>
> We talked a little bit about the future of DHCP clients in #995189,
> though we didn't come up with a definitive plan.  Regardless of what
> happens with dhcpcd5, we do need to move forward with something.  Doing
> nothing (which effectively leaves us with an unsupported dhclient by
> default) is not a good option.
>
> As far as I know, there are no drop-in replacements for dhclient.  Thus,
> the change is going to be pretty significant for dhclient users.  On the
> plus side, we get to use this as an opportunity to figure out what we
> really want to support long-term.

Agreed.

> For desktop systems running NetworkManager, it sounds like we don't need
> a dedicated DHCP client at all; nm has DHCP client support built in and
> uses it by default.

NM has support for a variety of DHCP backends. dhclient and dhcpcd5
are both supported. In #964947, Michael Biebel mentions that enabling
the dhcpcd5 backend has been requested, but cannot proceed until
Debian has a recent enough version in the repository.

> For servers, the ideal situation is somewhat less clear, but there was
> at least some interest in using systemd-networkd (with or without
> netplan).

I would avoid anything systemd or NM specific.

Martin-Éric

Bug#1006283: milter fails on utf-8 text

[Matus UHLAR - fantomas]

Package: pyspf-milter
Version: 2.9.2-1

Hello,

it seems that pyspf-milter fails if the incoming message contains unicode 
content. 


Looks like it fails even in case when it could continue successfully:

Feb 17 22:25:57 fantomas sm-mta[13913]: STARTTLS=server, 
relay=lists.sourceforge.net [216.105.38.7], version=TLSv1.2, verify=NOT, 
cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Feb 17 22:25:57 fantomas pyspf-milter[1573]: prepend Authentication-Results: 
fantomas.fantomas.sk; spf=pass (sender SPF authorized) 
smtp.mailfrom=lists.sourceforge.net (client-ip=216.105.38.7; 
helo=lists.sourceforge.net; 
envelope-from=courier-users-boun...@lists.sourceforge.net; receiver=)
Feb 17 22:25:57 fantomas sm-mta[13913]: 21HLPo98013913: 
from=, size=6029, class=-30, nrcpts=2, 
msgid=<5946cd31-34c2-b6f7-4cfd-8b33236d5...@dmj.nu>, bodytype=8BITMIME, proto=ESMTPS, 
daemon=MTA-v4, relay=lists.sourceforge.net [216.105.38.7]
Feb 17 22:25:57 fantomas pyspf-milter[1573]: UnicodeDecodeError: 'utf-8' codec 
can't decode byte 0xc2 in position 542: invalid continuation byte
Feb 17 22:25:57 fantomas pyspf-milter[1573]: pyspf-filter: milter claimed not 
to reply in state 7 but did anyway 4
Feb 17 22:26:57 fantomas sm-mta[13913]: 21HLPo98013913: Milter (pyspf-milter): 
timeout before data read, where=eom

Jan  9 06:59:33 fantomas sm-mta[5692]: STARTTLS=server, 
relay=lists.sourceforge.net [216.105.38.7], version=TLSv1.2, verify=NOT, 
cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256/256
Jan  9 06:59:33 fantomas pyspf-milter[3257]: prepend Authentication-Results: 
fantomas.fantomas.sk; spf=pass (sender SPF authorized) 
smtp.mailfrom=lists.sourceforge.net (client-ip=216.105.38.7; 
helo=lists.sourceforge.net; 
envelope-from=courier-users-boun...@lists.sourceforge.net; receiver=)
Jan  9 06:59:33 fantomas sm-mta[5692]: 2095xQbw005692: 
from=, size=6862, class=-30, nrcpts=2, 
msgid=<2982fa42cb1d0a63fd9f17017eece510fc426a9f.ca...@mariochiari.net>, 
bodytype=8BITMIME, proto=ESMTPS, daemon=MTA-v4, relay=lists.sourceforge.net [216.105.38.7]
Jan  9 06:59:33 fantomas pyspf-milter[3257]: UnicodeDecodeError: 'utf-8' codec 
can't decode byte 0xc1 in position 370: invalid start byte
Jan  9 06:59:33 fantomas pyspf-milter[3257]: pyspf-filter: milter claimed not 
to reply in state 7 but did anyway 4
Jan  9 07:00:33 fantomas sm-mta[5692]: 2095xQbw005692: Milter (pyspf-milter): 
timeout before data read, where=eom

I have set mailserver to accept mail for these cases and I may provide 
example of data if needed


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
My mind is like a steel trap - rusty and illegal in 37 states.

Bug#1006264: RFH: dhcpcd5 -- DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support

[Noah Meyerhans]

On Tue, Feb 22, 2022 at 11:22:08AM +0200, Martin-Éric Racine wrote:
> Given how upstream ISC will stop development of its DHCP suite by the end of 
> 2022 [1], Debian will need to select a new stock DHCP client to ship with 
> Priority:Important.
> 
> dhcpcd5 seems like the most potential replacement. It covers most IPv4 and 
> IPv6 usage cases, and upstream regularly updates the code. However, the 
> Debian package hasn't been updated in ages.

We talked a little bit about the future of DHCP clients in #995189,
though we didn't come up with a definitive plan.  Regardless of what
happens with dhcpcd5, we do need to move forward with something.  Doing
nothing (which effectively leaves us with an unsupported dhclient by
default) is not a good option.

As far as I know, there are no drop-in replacements for dhclient.  Thus,
the change is going to be pretty significant for dhclient users.  On the
plus side, we get to use this as an opportunity to figure out what we
really want to support long-term.

For desktop systems running NetworkManager, it sounds like we don't need
a dedicated DHCP client at all; nm has DHCP client support built in and
uses it by default.

For servers, the ideal situation is somewhat less clear, but there was
at least some interest in using systemd-networkd (with or without
netplan).

So we may not need to specifically promote a DHCP client like dhcpcd5 to
priority:important.  Systemd-networkd could be the default, and
NetworkManager could be used when it's present.

noah

Bug#1005297: gcc-12-12-20220222: FTBFS on hurd-i386. Was: gcc-12-12-20220214: FTBFS on hurd-i386

[Svante Signell]

retitle 1005297 gcc-12-12-20220222: FTBFS on hurd-i386
thanks

On Fri, 2022-02-18 at 10:18 +, Debian Bug Tracking System wrote:
> Thank you for the additional information you have supplied regarding
> this Bug report.

Hello,

Unfortunately the patch Makefile.in.diff is needed to for a successful build.
Attached here for completeness.

Thanks!
--- a/src/Makefile.in	2022-02-15 00:20:00.0 +0100
+++ b/src/Makefile.in	2022-02-15 00:25:27.0 +0100
@@ -66351,6 +66351,8 @@
 all-m4: maybe-all-build-texinfo
 configure-target-libgo: maybe-configure-target-libffi
 all-target-libgo: maybe-all-target-libffi
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
 configure-target-libphobos: maybe-configure-target-libbacktrace
 configure-stage1-target-libphobos: maybe-configure-stage1-target-libbacktrace
 configure-stage2-target-libphobos: maybe-configure-stage2-target-libbacktrace
@@ -66516,8 +66518,6 @@
 configure-target-fastjar: maybe-configure-target-zlib
 all-target-fastjar: maybe-all-target-zlib
 configure-target-libgo: maybe-all-target-libstdc++-v3
-all-target-libgo: maybe-all-target-libbacktrace
-all-target-libgo: maybe-all-target-libatomic
 configure-target-libgm2: maybe-all-target-libstdc++-v3
 all-target-libgm2: maybe-all-target-libatomic
 configure-target-liboffloadmic: maybe-configure-target-libgomp

Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility

[Ricardo Fraile]

Please, check related bug on 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004710

Bug#1006282: ITP: hpnssh -- High Performance OpenSSH

[rapier]

Package: sponsorship-requests
Severity: normal
Owner: rap...@psc.edu


Mentors,

* Package name: hpnssh
  Version : 16.1
  Upstream Author : Chris Rapier
* URL : https://github.com/rapier1/openssh-portable
  License : BSD
  Description : A fork of OpenSSH with enhanced performance and
functionality
  Website : https://www.psc.edu/hpn-ssh-home

HPNSSH was first developed around 15 years ago to address significant 
performance issue in OpenSSH due to undersized buffers in the 
implementation of SSHv2. Throughput performance gains of two orders of 
magnitude were common. Since then additional functionality includes:

* resumption of failed SCP transfers
* the use of none/null encryption after authentication for data transfers
* A threaded AES-CTR cipher implementation
* OOB reporting on TCP stack instruments for diagnostics
* Various performance enhancements

On well tuned 10Gb connected hosts throughput rates of more than 8Gb/s 
are possible.


HPNSSH uses different naming nomenclature in order to allow for side by 
side installation with OpenSSH.


Current development work has been support by a grant for the National 
Science Foundation and is being conducted at the Pittsburgh 
Supercomputing Center which is part of Carnegie Mellon University.

Bug#878192:

[Deborah Perro]

Bug#1006281: libgtk-3-0: Please chery-pick the fix for clipboard handling to bullseye-updates

[Amr Ibrahim]

Package: libgtk-3-0
Version: 3.24.24-4
Severity: normal
Tags: upstream

Dear Maintainer,

On Wayland, copy-pasting text from Evince is sometimes broken.

Here is the upstream bug:
https://gitlab.gnome.org/GNOME/gtk/-/issues/4340

And here is the fix to gtk-3-24:
https://gitlab.gnome.org/GNOME/gtk/-/commit/e23b4dd21b41329a804fadf6a89c79be17dffcdf

I'm experiencing this bug very often since I frequently copy-paste text between
Wayland clients. So please cherry-pick the fix to bullseye-updates.

Best,
Amr


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

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

Versions of packages libgtk-3-0 depends on:
ii  adwaita-icon-theme   3.38.0-1
ii  hicolor-icon-theme   0.17-2
ii  libatk-bridge2.0-0   2.38.0-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13+deb11u2
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libcolord2   1.4.5-3
ii  libcups2 2.3.3op2-3+deb11u1
ii  libepoxy01.5.5-1
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libfribidi0  1.0.8-2
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-common  3.24.24-4
ii  libharfbuzz0b2.7.4-1
ii  libjson-glib-1.0-0   1.6.2-1
ii  libpango-1.0-0   1.46.2-3
ii  libpangocairo-1.0-0  1.46.2-3
ii  libpangoft2-1.0-01.46.2-3
ii  librest-0.7-00.8.1-1.1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libwayland-cursor0   1.18.0-2~exp1.1
ii  libwayland-egl1  1.18.0-2~exp1.1
ii  libx11-6 2:1.7.2-1
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.2.0-2
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxi6   2:1.7.10-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon01.0.3-2
ii  libxrandr2   2:1.5.1-1
ii  shared-mime-info 2.0-1

Versions of packages libgtk-3-0 recommends:
ii  libgtk-3-bin 3.24.24-4
ii  librsvg2-common  2.50.3+dfsg-1

Versions of packages libgtk-3-0 suggests:
ii  gvfs  1.46.2-1

Versions of packages libgtk-3-0 is related to:
pn  appmenu-gtk3-module   
pn  fcitx-frontend-gtk3   
pn  gcin-gtk3-immodule
pn  gtk-vector-screenshot 
pn  gtk3-engines-xfce 
pn  gtk3-im-libthai   
pn  hime-gtk3-immodule
ii  ibus-gtk3 1.5.23-2
pn  imhangul-gtk3 
ii  libcanberra-gtk3-module   0.30-7
pn  libcaribou-gtk3-module
pn  libgtk3-nocsd0
pn  maliit-inputcontext-gtk3  
pn  packagekit-gtk3-module
pn  scim-gtk-immodule 
pn  topmenu-gtk3  
pn  uim-gtk3  
pn  uim-gtk3-immodule 

Bug#1000766: Processed (with 1 error): Package is linux

[Geert Stappers]

Control: reassign -1 linux

On Tue, Feb 22, 2022 at 05:39:05PM +, Debian Bug Tracking System wrote:
> Processing control commands:
> 
> > assign -1 linux
> Unknown command or malformed arguments to command.
> 

Bug#1004368: chromium: "Stack smashing detected" messages

[Andres Salomon]

On Wed, 26 Jan 2022 03:11:16 -0500 Andres Salomon wrote:
> > *** stack smashing detected ***: terminated
> >


I backported clang-13 to debian stable and used it to build chromium. 
Nothing else was backported or changed (other than the requisite changes 
needed to tell chromium to use clang-13 and friends instead of clang). 
The stack smashing error messages disappeared. So this is absolutely an 
issue with building against clang-11 in stable.

Bug#1000766: Package is linux

[Geert Stappers]

Control: assign -1 linux



Hello Kirill,


BlueTooth controller stuff is NOT package  bugs.debian.org


See also https://wiki.debian.org/DebianKernelReportingBugs


 
Groeten
Geert Stappers
DD
-- 
Silence is hard to parse

Bug#1006280: perl: panic on s///gre with tainted utf8 strings

[Kacper Gutowski]

Package: perl
Version: 5.34.0-3
Severity: normal

Sometimes when doing s///gre on tainted utf8 string, perl warns about 
malformed UTF-8 characters or outright panics.


This warns:
$ perl -Twe '$_ = $^X =~ s/./"\x{10469}"/gre'
Malformed UTF-8 character (unexpected end of string) in substitution iterator 
at -e line 1.

These die:
$ perl -Twe '$_ = $^X =~ s/.*/"\x{10469}"/gre'
panic: sv_pos_b2u: bad byte offset, blen=4, byte=13 at -e line 1.
$ perl -Twe '$_ = "\x{105}$^X" =~ s/./""/gre'
panic: sv_pos_b2u: bad byte offset, blen=0, byte=2 at -e line 1.

Notably, all these warnings and panics go away when taint mode is not 
used or no tainted strings are involved, or when there are no UTF-8 
characters involved.  No problems seem to appear when not using "/r" 
either so currently I'm just using a temporary variable as a workaround.


I think it might be an upstream bug.  It seems superficially similar to 
RT #122148 from 2014, but I know nothing about internals so that's it.



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

Kernel: Linux 5.15.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages perl depends on:
ii  dpkg   1.21.1
ii  libperl5.345.34.0-3
ii  perl-base  5.34.0-3
ii  perl-modules-5.34  5.34.0-3

Versions of packages perl recommends:
ii  netbase  6.3

Versions of packages perl suggests:
pn  libtap-harness-archive-perl  
ii  libterm-readline-gnu-perl1.42-2+b1
ii  make 4.3-4.1
ii  perl-doc 5.34.0-3

-- no debconf information

Bug#1006279: Please update to latest release 1.4.1 including configuration file and systemd support

[Daniel Leidert]

Source: wondershaper
Version: 1.1a-10.1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seems the develolment of wondershaper has been moved to github and there has
been some development going on since the last release packaged in Debian.

https://github.com/magnific0/wondershaper

Packaging this might also provide fixes for some of the outstanding bug reports.

Regards, Daniel


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmIVF/EACgkQS80FZ8KW
0F1vKw//ep3y7l5gFQvGlfo5BZMFsLXSA4aXXWSThD/5ShFb4/fN3V//nXCktnhs
o+cf/iKCRqq77tgsd081TrZriKrVB5fc6TDETI+GV6GXbhUm8zALWoK7yLIRuuq5
s9Kokfl5BJyID9O3VUNZpSyn4B69pWpWpMTgoYM9sh6AB+6LeHdBewFESSWxHuVe
6WPyfSqZvINSZ4U1As7YRcCMcAmwH/SvIBvEA8YIvsnkBo+ijMvI7RqDSoUoQBXA
v/lmZJV6YBeqqlnNDKX8SUHnJHp7AfH8ULkIhl2L0CnnmS7HSbChTwrvgVb/bxEE
OzrBpOuKeBgfzqM3JkSJQCHJstyegpXGO3BmbdQ9xNp77udbbR/jFMhjlgGxlUK3
BHz9tPLcvQa/SFoO8ar0x+DlLU4Od4f0l7trxnjVneeiHGbqMf/tAmRlfJHT/yki
8bErOtV2BHeS/54bUYbd4hCm46c/yHp6RDXoDNgg/uRotLrM9gHpqOwnNqxXq8aQ
5AdYUSnUuZiuTiT9YmN1RMpSRZAKFjJZ/xup2bhMKY+fjdw0ddJ1+yUQLYGlrb3v
VjwppBz9/NhfdZYkr16mhBL7N1W5u5fbCxYbHRu3CJf89+yIRU7ZUgb3AcYNvBnV
N0uXSKiZRENFQpIHJpPiAaAxSfmrDrfOJLfDVgvdrhWPl9n+6aE=
=VbZZ
-END PGP SIGNATURE-

Bug#1004556: libmpich-dev: The simplest MPI program compiled with mpich crashes

[Drew Parsons]

Package: mpich
Followup-For: Bug #1004556

My guess is that this bug is ongoing in 4.0-2 because of pmix support.

4.0-2 is still configured --with-pmix=/usr/lib/x86_64-linux-gnu/pmix2
and still Depends: libpmix2 (>= 4.1.2)

pmix support was added in 4.0~b1-2 along with ucx.

I gather ucx was deactivated in 4.0-2 but pmix was not. Looks like pmix
also needs to go (unless the problem is ch4, which was also added in
4.0~b1-2). But the error message references PMIX.


Ironically, I find that an executable compiled against mpich 4.0-1
fails with mpiexec.mpich (as raised in this bug) but actually passes
when run with mpiexec.openmpi.  Awkward.

Bug#1006278: ITP: tokenize-rt -- A wrapper around the stdlib `tokenize` which roundtrips.

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: python-tokenize-rt
  Version : 2.1.0
  Upstream Author : Anthony Sottile 
* URL : https://github.com/asottile/tokenize-rt
* License : MIT
  Programming Lang: Python
  Description : A wrapper around the stdlib `tokenize` which roundtrips.

Python's stdlib tokenize module does not properly roundtrip. This wrapper
around the stdlib provides two additional tokens ESCAPED_NL and UNIMPORTANT_WS,
and a Token data type. Use src_to_tokens and tokens_to_src to roundtrip.

This library is useful for writing a refactoring tool based on the python
tokenization.

Bug#1006277: RFP: easyeffects -- Audio effects for PipeWire applications (formerly - pulseeffects)

[Roman Lebedev]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-multime...@lists.debian.org, by...@debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: easyeffects
  Version : 6.2.3
  Upstream Author : wwmm 
* URL : https://github.com/wwmm/easyeffects
* License : GNU GPL v3
  Programming Lang: C++
  Description : Audio effects for PipeWire applications (formerly - 
pulseeffects)

The existing Debian package named pulseeffects is dead upstream,
and the new versions are called easyeffects.

I'm not sure whether pulseeffects can be used with pipewire,
or of easyeffects can be used with pulseaudio,
but i think they can simply be packaged in parallel,
at least for a bit.

Lately, i've been using pulseeffects more and more, so i believe
that packaging easyeffects may make the migration to pipewire
almost seamless.

Roman.


-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAmIVDucACgkQCDw+u0oW
ieDgGw//bKqJlNV4z+LTKbQkZoQHXpijPiK1P/HmcLTPihIFb547RkjVundsBGB1
ANoOfY42StZkeus/kzPw93BvTV9BXnjtF1R6xrSlOx9ERZU9NWm09A5p9ic0jhpA
Mgc6198WiDkaL7AoWIibqWxyLJB0dKwPIbvSyc3Dj0LUZDdkzRgUw13SRP6KorF+
zLDhwztqQ9Jvf3qM8HBahUVFY7ZLYQy33Eew+8JoMArX7Sy53yXe5Nu2FX6llcEs
7AEFuevAXWeaK+yx+ZKIwr9f/CDj3VGGY+V32svQNzU6Zx6cq4qbalpFGncH8z2v
MUZOhWTeQA9y9aHRMIlZEfzVQ7vj0aI3j9sQTrNwzmdYulzlAPL9+yzHglsktzuU
UfrVGJcGKBTFZPenojxrTvVhzSSrdYmamrh8xzmAaCyG7kDHzGfAXHkkjC4vKrec
jXMgLi8sBJMph5aD8nYer9e8jNI+HGKg5EN9HCBPpL/hTCs2whEHD1pyPycBMwwx
ibM2OkFtYQVaRHEBSSVP0QPDlXfKu2tCXQm/wEUapP1NdEKDsMtJayuYJKplMGia
mJiuM2MPO19WRSziJ6gbxQZXypBjmE3nane0JjniYEbKAsFtFUcG+cOiXiF0xnQn
uclqUw/mcFVa4jmOCxUgRoFniXRanyjGm9O7LQ1jvpotN3UiVow=
=KkFt
-END PGP SIGNATURE-

Bug#1006276: wireguard-go: Please rename bin/wireguard to bin/wireguard-go

[Shengjing Zhu]

Package: wireguard-go
Severity: important
X-Debbugs-Cc: z...@debian.org

Dear Maintainer,

Upstream docs[1] refer its name with bin/wireguard-go, please follow.
Besides, the name bin/wireguard seems too common.

[1] https://git.zx2c4.com/wireguard-go/about/

Bug#1006269: appstream: apt hook shows non-actionable warnings if Flathub metadata has issues

[Matthias Klumpp]

Hi!

Am Di., 22. Feb. 2022 um 11:33 Uhr schrieb Simon McVittie :
>
> Package: appstream
> Version: 0.15.1-1
> Severity: normal
>
> I cannot reproduce this right now (it seems to be intermittent?), but
> the steps that previously reproduced it were:
>
> * Have flatpak installed
> * Have Flathub configured as a remote in the system repository
>   /var/lib/flatpak: https://flatpak.org/setup/Debian
> * Have appstream installed
> * `sudo apt update`, or the equivalent in aptitude

You will be able to reproduce this all the time by running:
sudo appstreamcli refresh --force

> Expected result: no error messages unless there is something that the
> sysadmin needs to resolve.
>
> Actual result, as reported at https://github.com/flatpak/flatpak/issues/4642
> and https://github.com/flathub/cc.nift.nsm/issues/3:
>
> ** (appstreamcli:11481): WARNING **: 21:53:33.554: Found icon of unknown 
> type 'unknown' in 'system/flatpak/flatpak/cc.nift.nsm/*', skipping it.
> ** (appstreamcli:11481): WARNING **: 21:53:33.554: Found icon of unknown 
> type 'unknown' in 'system/flatpak/flatpak/cc.nift.nsm/*', skipping it.
>
> If this happens again I'll try to capture the Appstream XML that Flathub was
> sending at the time.

This is an odd one... While there is nothing the user can do here, we
do want to know if the server was sending bad data. This was
originally intended to alert when there's bad data in the Debian
repositories, but since Flatpak data is cached too now in the same
pass, we get this message as well now. I am not sure if that's a good
or a bad thing though ^^
Potentially we could only generate caches for the OS data on APT
updates, and not Flatpak as well.

> appstreamcli should perhaps have a --quiet option that tries to recover
> from this sort of thing without issuing warnings, which could be used
> in the apt hook?

It actually does run in quiet mode :-) However, if there's an issue
that results in metadata being dropped entirely for $reasons, it
currently complains quite loudly so the server side can be fixed.

There seems to be something wrong with Flatpak's or Flathub's
AppStream generator (even if the input is bad, the output of the
server shouldn't be bad too!) - I was meaning to report that, but so
far didn't have the time. Looks like others were faster now :-D

Cheers,
Matthias


-- 
I welcome VSRE emails. See http://vsre.info/

Bug#1006275: linux-image-5.16.0-1-amd64: Request por CONFIG_HID_NINTENDO=m

[Ricardo Pérez]

Package: src:linux
Version: 5.16.7-2
Severity: normal
X-Debbugs-Cc: rica...@ubuntu.com

Dear Maintainer,

please consider setting CONFIG_HID_NINTENDO=m to enable Nintendo Switch
Pro Controller support.

Thanks in advance.

-- Package-specific info:
** Version:
Linux version 5.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.2.0-16) 11.2.0, GNU ld (GNU Binutils for Debian) 2.37.90.20220130) #1 SMP 
PREEMPT Debian 5.16.7-2 (2022-02-09)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.16.0-1-amd64 
root=UUID=b792d089-204b-4725-9a09-a41655e2b549 ro quiet

** Tainted: POE (12289)
 * proprietary module was loaded
 * externally-built ("out-of-tree") module was loaded
 * unsigned module was loaded

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: Micro-Star International Co., Ltd.
product_name: MS-7B85
product_version: 1.0
chassis_vendor: Micro-Star International Co., Ltd.
chassis_version: 1.0
bios_vendor: American Megatrends Inc.
bios_version: 1.B0
board_vendor: Micro-Star International Co., Ltd.
board_name: B450 GAMING PRO CARBON AC (MS-7B85)
board_version: 1.0

** Loaded modules:
rfcomm
ctr
ccm
algif_aead
des_generic
libdes
ecb
md4
cmac
algif_hash
algif_skcipher
af_alg
bnep
nls_ascii
nls_cp437
vfat
fat
iwlmvm
btusb
btrtl
btbcm
btintel
intel_rapl_msr
intel_rapl_common
mac80211
bluetooth
edac_mce_amd
libarc4
snd_hda_codec_realtek
snd_hda_codec_generic
ledtrig_audio
snd_hda_codec_hdmi
jitterentropy_rng
sha512_ssse3
kvm_amd
pkcs8_key_parser
sha512_generic
iwlwifi
snd_hda_intel
kvm
nvidia_drm(POE)
snd_intel_dspcfg
snd_intel_sdw_acpi
snd_hda_codec
ses
enclosure
snd_hda_core
drbg
irqbypass
ansi_cprng
sd_mod
snd_hwdep
scsi_transport_sas
ghash_clmulni_intel
ecdh_generic
cfg80211
sg
joydev
snd_pcm
drm_kms_helper
ecc
snd_timer
rfkill
aesni_intel
snd
cec
crypto_simd
ccp
soundcore
rc_core
cryptd
sp5100_tco
rng_core
watchdog
k10temp
rapl
nvidia_modeset(POE)
efi_pstore
pcspkr
wmi_bmof
evdev
acpi_cpufreq
nvidia(POE)
drm
nct6775
hwmon_vid
fuse
configfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_logitech_hidpp
hid_logitech_dj
uas
usb_storage
hid_generic
usbhid
hid
ahci
xhci_pci
libahci
xhci_hcd
libata
nvme
igb
nvme_core
scsi_mod
usbcore
crc32_pclmul
crc32c_intel
t10_pi
dca
crc_t10dif
ptp
crct10dif_generic
pps_core
crct10dif_pclmul
gpio_amdpt
i2c_piix4
i2c_algo_bit
scsi_common
usb_common
crct10dif_common
wmi
gpio_generic
button

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) Root Complex [1022:1450]
Subsystem: Micro-Star International Co., Ltd. [MSI] Family 17h (Models 
00h-0fh) Root Complex [1462:7b85]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

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

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

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

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

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host 

Bug#998842: octave: inv() causes segfault if io package pre-loaded

[Leonardo Vainsencher]

Hi Sébastien,

Here is the requested information ...
(see also attached: gdb.txt, bug1.m)
(bug1.m contains code to reproduce the problem)

---

bash> gdb -n -ex 'set logging on' -ex 'set pagination off' octave-cli
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
   .

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from octave-cli...
Reading symbols from 
/usr/lib/debug/.build-id/6b/51e9e0a81c4d17ab5907d0bce9c440138d7f62.debug...
Copying output to gdb.txt.
Copying debug output to gdb.txt.
(gdb) run --no-init-file
Starting program: /usr/bin/octave-cli --no-init-file
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee50a700 (LWP 90588)]
[New Thread 0x7fffedd09700 (LWP 90589)]
[New Thread 0x7fffe5508700 (LWP 90590)]
[New Thread 0x7fffdcd07700 (LWP 90591)]
[New Thread 0x7fffd4506700 (LWP 90592)]
[New Thread 0x7fffc3d05700 (LWP 90593)]
[New Thread 0x7fffc3504700 (LWP 90594)]
[New Thread 0x7fffb2906700 (LWP 90595)]
GNU Octave, version 6.2.0
Copyright (C) 2021 The Octave Project Developers.
This is free software; see the source code for copying conditions.
There is ABSOLUTELY NO WARRANTY; not even for MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  For details, type 'warranty'.

Octave was configured for "x86_64-pc-linux-gnu".

Additional information about Octave is available at https://www.octave.org.

Please contribute if you find this software useful.
For more information, visit https://www.octave.org/get-involved.html

Read https://www.octave.org/bugs.html to learn how to submit bug reports.
For information about changes from previous versions, type 'news'.

octave:1> pkg('load','io'); bug1; disp('OK');

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
0x7fff9962e62d in ?? ()
(gdb) thread apply all bt full

... (see attached gdb.txt)

---

Hope this can help.
Regards,
L.


From: Sébastien Villemot 
Sent: Monday, February 21, 2022 12:30 PM
To: Leonardo Vainsencher ; 
998...@bugs.debian.org <998...@bugs.debian.org>
Subject: Re: Bug#998842: octave: inv() causes segfault if io package pre-loaded

CAUTION: Email originated externally, do not click links or open attachments 
unless you recognize the sender and know the content is safe.

Starting program: /usr/bin/octave-cli --no-init-file
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffee50a700 (LWP 90588)]
[New Thread 0x7fffedd09700 (LWP 90589)]
[New Thread 0x7fffe5508700 (LWP 90590)]
[New Thread 0x7fffdcd07700 (LWP 90591)]
[New Thread 0x7fffd4506700 (LWP 90592)]
[New Thread 0x7fffc3d05700 (LWP 90593)]
[New Thread 0x7fffc3504700 (LWP 90594)]
[New Thread 0x7fffb2906700 (LWP 90595)]

Thread 1 "octave-cli" received signal SIGSEGV, Segmentation fault.
0x7fff9962e62d in ?? ()

Thread 9 (Thread 0x7fffb2906700 (LWP 90595) "octave-cli"):
#0  0x758e7ba2 in __GI___sigtimedwait (set=set@entry=0x76b92e80 
, info=info@entry=0x7fffb28efa20, timeout=timeout@entry=0x0) at 
../sysdeps/unix/sysv/linux/sigtimedwait.c:29
resultvar = 18446744073709551612
sc_cancel_oldtype = 0
sc_ret = 
result = 
#1  0x758e71cc in __GI___sigwait (set=set@entry=0x76b92e80 
, sig=sig@entry=0x7fffb28efad4) at 
../sysdeps/unix/sysv/linux/sigwait.c:28
si = {si_signo = 0, si_errno = 0, si_code = 0, __pad0 = 0, _sifields = 
{_pad = {0 }, _kill = {si_pid = 0, si_uid = 0}, _timer = 
{si_tid = 0, si_overrun = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, _rt 
= {si_pid = 0, si_uid = 0, si_sigval = {sival_int = 0, sival_ptr = 0x0}}, 
_sigchld = {si_pid = 0, si_uid = 0, si_status = 0, si_utime = 0, si_stime = 0}, 
_sigfault = {si_addr = 0x0, si_addr_lsb = 0, _bounds = {_addr_bnd = {_lower = 
0x0, _upper = 0x0}, _pkey = 0}}, _sigpoll = {si_band = 0, si_fd = 0}, _sigsys = 
{_call_addr = 0x0, _syscall = 0, _arch = 0}}}
ret = 
#2  0x7690bb61 in signal_watcher (arg=0x77b43b60 
) at liboctave/wrappers/signal-wrappers.c:697
sig_caught = 0
handler = 0x77b43b60 
async_signals = 
#3  0x744d2ea7 in start_thread (arg=) at 
pthread_create.c:477

Bug#1005253: [Pkg-shadow-devel] Bug#1005253: Bug#1005253: shadow: Improved manual page useradd.8

[Serge E. Hallyn]

On Fri, Feb 11, 2022 at 07:14:27PM +0100, Markus Hiereth wrote:
> Hi Serge,
> 
> "Serge E. Hallyn"  schrieb am 11. Februar 2022 um 18:13
>  
> > Thanks.  The diff is especially helpful.  Although a few of these hunks
> > appear to be just changes to the line breaks.
> 
> > > @@ -219,14 +221,17 @@
> > >   
> > >   
> > > 
> > > - The number of days after a password expires until the account is
> > > - permanently disabled. A value of 0 disables the account as soon
> > > - as the password has expired, and a value of -1 disables the
> > > - feature.
> > > +defines the number of days after the password exceeded its 
> > > maximum
> > > +age where the user is expected to replace this password. The 
> > > value
> > 
> > How about 'number of days after the password exceeded its maximum
> > age during which the user may login by immediately replacing this
> > password. The value is stored in the shadow password file.'
> 
> I also thought that there is something better then "where the user..."

Actually how about "may still login by..."

> > > 
> > >   If not specified, useradd will use the
> > > - default inactivity period specified by the
> > > + default inactivity onset specified by the
> > 
> > "onset" is weird here.
> 
> I looked up in a dictionary: "onset is the first attack or beginning
> (of something bad)" . There are similar usages: "onset of winter", a
> "hard onset" in phonetics, in medicine they speak of the "onset" of a
> disease.
> 
> What do you think of "begin of inactivity"?
> 
> You know I also suggested "grace period". But, expressing it this way,
> the connection to inactivity gets lost.
> 
> I really dislike "inactivity period" as the user does not define the
> duration of inactivity but the number of days he will be able to do
> something against a shift of his account into the inactive state.

Grace period is good, actually.  How about
"grace period before the account becomes inactive"?

> > >   INACTIVE variable in
> > >   /etc/default/useradd, or -1 by default.
> > > 
> > > @@ -237,8 +242,9 @@
> > > -g, 
> > > --gidGROUP
> > >   
> > >   
> > > +   
> > 
> > This i assume is leftover marker to be dropped.
> 
> Sure.
> 
> 
> > > @@ -398,10 +407,18 @@
> > > -o, --non-unique
> > >   
> > >   
> > > -   Allow the creation of a user account with a duplicate 
> > > (non-unique) UID.
> > > +   
> > > + allows the creation of an account with an already existing
> > > + UID.
> > > +   
> > > 
> > >   This option is only valid in combination with the
> > > - -u option.
> > > + -u option. As a user identity
> > > + serves as
> > > + key to map between users on one hand and permissions, file
> > > + ownerships and other aspects that determine the system's
> > > + behavior on the other hand, more than one login name
> > > + will access the account of the given UID.
> > > 
> > >   
> > >
> > > @@ -410,14 +427,25 @@
> > > -p, 
> > > --passwordPASSWORD
> > >   
> > >   
> > > +   
>  
> > Drop this?
> 
> yes
> 
>  
> > > @@ -488,11 +516,11 @@
> > >   
> > >   
> > > 
> > > - The name of the user's login shell. The default is to leave this
> > > - field blank, which causes the system to select the default login
> > > - shell specified by the SHELL variable in
> > > - /etc/default/useradd, or an empty string
> > > - by default.
> > > +sets the path to the user's login shell. Without this option,
> > > +the system will use the SHELL variable 
> > > specified
> > > + in /etc/default/useradd, or, if that is as
> > > + well not set, the field for the login shell in /etc/passwd
> > > + remains empty.
> > > 
> > >   
> > >
> > > @@ -533,13 +561,16 @@
> > >
> > >
> > >   
> > > -   -Z, 
> > > --selinux-userSEUSER
> > > +   -Z, --selinux
> > > +   -userSEUSER
>  
> > Is the line break here accidental?
> 
> Yes. I did not care for line breaks. This is a case where it would be
> better avoided or done in another way, without separation of --selinux-user.
> 
> > >   
> > >   
> > > 
> > > - The SELinux user for the user's login. The default is to leave this
> > > - field blank, which causes the system to select the default SELinux
> > > - user.
> > > + defines the SELinux user for the new account. Without this
> > > + option, a SELinux uses the default user. Note that the
> > 
> > s/a SELinux/SELinux/
> 
> Yes.
> 
> 
> 
> > > + shadow system doesn't store the selinux-user, it uses
> > > + semanage
> > > + 8 for that.
> > > 
> > >   
> > >
> > > @@ -561,7 +592,7 @@
> > > 
> > > 
> > >   
> > > -   The path prefix for a new user's home directory. The
> > > +   The path prefix for new users' home directory. The
> > 
> > the 'a' is more natural in English.
> 
> No problen, use the singular
> 
> 
> 
> > > @@ -578,7 +609,8 

Bug#1006274: transition: rakudo

[M. Zhou]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

Rakudo upstream has released 2022.02 version, and I have uploaded it to
experimental. In the past few weeks the architecture of the raku-*
packages has been changed to any, which means binnmus should be possible.
Shall we start the rakudo 2022.02 transition?

BTW, since we have a permanent transition tracker
https://release.debian.org/transitions/html/rakudo.html
Do we have to request for transition slot every time?

Thanks!

Ben file:

title = "rakudo";
is_affected = .depends ~ "raku-api-2021.12" | .depends ~ "raku-api-2022.02";
is_good = .depends ~ "raku-api-2022.02";
is_bad = .depends ~ "raku-api-2021.12";
Thank you for using reportbug

Bug#904742: jp: name conflict of /usr/bin/jp with sat-xmpp-jp

[Martin]

The program jp (package sat-xmpp-jp) has been renamed to libervia-cli
(package libervia-cli). Problem solved.

Bug#1006273: review Ubuntu changes for inclusion in Debian

[Marc Haber]

Package: sudo
Version: 1.9.9-1
Severity: minor

X-Debbugs-Cc: sl...@ubuntu.com

Hi,

Ubuntu seems to do some things that look worth doing in Debian as well.
The following is taken from their changelog for 1.9.9-1ubuntu2 and 
1.9.9-1ubuntu1:

d/t/control: skip 03-getroot-ldap autopkgtest on non-containers
allow removal of 'sudo' in autopkgtest (SUDO_FORCE_REMOVE=yes)
compile with --without-lecture --with-tty-tickets --enable-admin-flag

they seem to do different things with pam_env that we do.

Would some team members comment, and maybe the ubuntu maintainer can
give additional input?

Greetings
Marc

Bug#986844: ranger: ftbfs - autopkgtest flakiness

[Heinrich Schuchardt]

The problem is still evident in Ubuntu's testing landscape
https://autopkgtest.ubuntu.com/packages/r/ranger/jammy/amd64
and in Debian
https://tests.reproducible-builds.org/debian/history/armhf/ranger.html

Ubuntu maintainers would prefer to avoid a diff to Debian. Could you, 
please, consider the suggested patch.


Best regards

Heinrich

Bug#1004710: Invoke "useradd -r" when creating a system user

[Marc Haber]

On Sun, Feb 13, 2022 at 01:52:14PM -0500, Jason Franklin wrote:
> On Sun, 2022-02-13 at 19:18 +0100, Marc Haber wrote:
> > On Sun, Feb 13, 2022 at 12:27:26PM -0500, Jason Franklin wrote:
> > > That warning is not emitted here when "-r" is added to the call made
> > > from within adduser. The range discrepancy needs to be sorted out with
> > > discussion, I think.
> > 
> > Policy also helps here, it's rather explicit in defining the uid ranges.
> > Are we in line with policy?
> 
> Adduser is in line with policy for the moment. Improvements can be made
> in this regard.
> 
> For example, some UIDs are explicitly forbidden by policy, but adduser
> and useradd allow them.  These should be blocked, and tests should be
> written to prove this.

adduser --system should enforce policy for system users. The local
administrator is free to ignore Debian policy as they see fit. adduser
should not enforce things on the local admin that don't apply to them.

Maybe we add, some time in the future, an option --ignore-policy that a
local admin can use, so that maintainer scripts get the support of
policy enforcement.

> > Useradd is more and more taking over functionality that has
> > traditionally been implemented in adduser. Maybe they're working towards
> > adduser just being a shim for backwards compatibility. Do you want me to
> > reach out to them?
> 
> Please do.

You were faster than me, that's fine.

> I am actually a bit worried that my work is in vain. The useradd utility
> does have quite a few features that clash with or overtake those
> previously offered by adduser.

Adduser is used by over 1000 Debian packages and explicitly mentioned in
policy (9.2.2, "packages SHOULD use adduser --system")). There is zero
indication that this is going to change any time soon. There might other
tools be available that allow creation of system users, but adduser is
most probably going to stay the canonical tool for doing so.

> If useradd is intended to replace adduser, I would like to know as most
> of my work would be lessened in importance.

I don't think there is any such intention in Debian. There is simply no
mechanism to bring this forward other than talking and convincing each
and every package maintainer.

> I'm a bit uncertain as to where I stand in this regard.

You're a member of the maintainer team of the "leading" user creating
tool in Debian. You can decide whether to simplify your code by relying
more on useradd int the future or not.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#1006272: graphicsmagick: gm(1) refers to nonexistant mogrify(1)

[David Bremner]

Package: graphicsmagick
Version: 1.4+really1.3.37+hg16662-1+b1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It looks like some of the man pages are not installed? or maybe
installed under a different name?


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

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

Versions of packages graphicsmagick depends on:
ii  libc62.33-6
ii  libgraphicsmagick-q16-3  1.4+really1.3.37-1+b1

graphicsmagick recommends no packages.

Versions of packages graphicsmagick suggests:
pn  graphicsmagick-dbg  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmIU6JYACgkQA0U5G1Wq
FSE5eQ/9FEDvGHMXKGlQzD7b+ICYSt3pBlHRi4qL9ewmOKJuVLirFGB263/HXXfk
BUKuM3ECW23u82kjCCt30iwXAFtD6Xmig9rRN7pyEasNW9OkXAXhLiA/gdZ8cYQa
Py3/pg8QaPNg3P2Dul0XI5xI16jSJvcnbMtXnP8E6Gtx5g1GZsTawaUGuxr5wuMA
RtphZlnGp5fcrzvC6LlqfKkc4JxhpNRzS+kfDy6Kjtly2QJz7YjjcXv0TS9CFHQH
SGaPzCPhxVzyOKYliT3AueymJxWz6yx5x71lnL7y0uJEHpnfBARzOaQglawUX4Dy
G3cNDa75BPVUfrl4jRCy6mJ8bh/gb1WciarYxaKUhlCtD8VLllkwBmWiahxrhuEP
qaxVZo+7/8tn97XMOA+C8QJcRrRsacl1RfmAoedCU6zZdCo45dKIUPjZXvOGDHOG
85jfawDe02XCePy+i+LAUt4YuvHvpaRCsuc6SlcTJko+6UY47UiPZoIEGRCUDeHQ
5mCAqTb06wa06kyabwcJPKHCDAcWMtN5zCrGPj5+1M/uI+Pb8uZbLBJvgd12svTA
vU5D7fjyZS4xSO+0odoYqdg93PKoeSvtBxBI6f9LDbAvzYKzoAp11Yrzy5dZHoRZ
8joNUpvYKxJsv6tPJHJN81Fc3Q+Y1PskPRwOVYMLcWfZQIvjOSE=
=K2ht
-END PGP SIGNATURE-

Bug#1006261: Fix

[Alexandre Ghiti]

I finally found a fix for this issue, any comment is welcome:

diff -Nru 
lintian-2.114.0/t/recipes/checks/binaries/prerequisites/numpy/binaries-missing-depends-on-numpy-abi/build-spec/debian/rules
lintian-2.114.0ubuntu2/t/recipes/checks/binaries/prerequisites/numpy/binaries-missing-depends-on-numpy-abi/build-spec/debian/rules
--- 
lintian-2.114.0/t/recipes/checks/binaries/prerequisites/numpy/binaries-missing-depends-on-numpy-abi/build-spec/debian/rules
   2021-11-27 18:20:56.0 +0100
+++ 
lintian-2.114.0ubuntu2/t/recipes/checks/binaries/prerequisites/numpy/binaries-missing-depends-on-numpy-abi/build-spec/debian/rules2022-02-22
11:12:19.0 +0100
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f

 export DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie
-export DEB_LDFLAGS_MAINT_APPEND=-Wl,--no-as-needed
+export DEB_LDFLAGS_MAINT_APPEND=-Wl,--no-as-needed -fPIC

 %:
 dh $@ --buildsystem pybuild

Bug#1005900: [PATCH v2] um: Fix uml_mconsole stop/go

[anton . ivanov]

From: Anton Ivanov 

Moving to an EPOLL based IRQ controller broke uml_mconsole stop/go
commands. This fixes it and restores stop/go functionality.

Fixes: ff6a17989c08 ("Epoll based IRQ controller")
Signed-off-by: Anton Ivanov 
---
 arch/um/drivers/mconsole_kern.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index 6ead1e240457..8ca67a692683 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -224,7 +224,7 @@ void mconsole_go(struct mc_request *req)
 
 void mconsole_stop(struct mc_request *req)
 {
-   deactivate_fd(req->originating_fd, MCONSOLE_IRQ);
+   block_signals();
os_set_fd_block(req->originating_fd, 1);
mconsole_reply(req, "stopped", 0, 0);
for (;;) {
@@ -247,6 +247,7 @@ void mconsole_stop(struct mc_request *req)
}
os_set_fd_block(req->originating_fd, 0);
mconsole_reply(req, "", 0, 0);
+   unblock_signals();
 }
 
 static DEFINE_SPINLOCK(mc_devices_lock);
-- 
2.30.2

Bug#1005900: [PATCH] um: Fix uml_mconsole stop/go

[Johannes Berg]

On Tue, 2022-02-22 at 10:57 +, anton.iva...@cambridgegreys.com
wrote:
> From: Anton Ivanov 
> 
> Moving to an EPOLL based IRQ controller broke uml_mconsole stop/go
> commands. This fixes it and restores stop/go functionality.
> 
> Fixes: ff6a17989c08b0bb0fd490cc500b084581b3a9b9 Epoll based IRQ controller

The right format would be

Fixes: ff6a17989c08 ("Epoll based IRQ controller")

Don't think I can comment on the patch itself, sorry.

johannes

Bug#995402: libclass-dbi-sweet-perl: FTBFS: test failure

[Heinrich Schuchardt]

Related Ubuntu bug https://bugs.launchpad.net/debiantesting/+bug/1961751

Suggested solution: drop package as upstream is not maintained anymore

Bug#1005900: [PATCH] um: Fix uml_mconsole stop/go

[Anton Ivanov]

On 22/02/2022 12:11, Johannes Berg wrote:

On Tue, 2022-02-22 at 10:57 +, anton.iva...@cambridgegreys.com
wrote:

From: Anton Ivanov 

Moving to an EPOLL based IRQ controller broke uml_mconsole stop/go
commands. This fixes it and restores stop/go functionality.

Fixes: ff6a17989c08b0bb0fd490cc500b084581b3a9b9 Epoll based IRQ controller

The right format would be

Fixes: ff6a17989c08 ("Epoll based IRQ controller")


Ack, will resubmit shortly.



Don't think I can comment on the patch itself, sorry.


The old poll controller had all IO IRQs shared and disabled IRQ processing 
while in the IRQ loop. Thus a while(;;) in the IRQ loop combined with a 
blocking read was an effective way to stop processing.

That is no longer the case.

1. While individual IRQs are not reentrant (there is a check for that in the 
IRQ handler), other IRQs will be processed and each FD is allocated a separate 
one. So looping inside one will not stop the kernel. It will still handle timer 
IRQs and other IO.

2. In the old controller disable_fd() was the reentrance guard. It removed the 
fd from the poll set so that it is not triggered again until the IRQ is 
handled. It was used everywhere in the beginning of each handler (followed by 
re-enable at IRQ exit). It has different semantics, cost and should not be used 
without need in the epoll case. In fact, I removed it throughout, but somehow 
missed the mconsole. Still having it was a bug.

As we do not have any means to shut-off the IRQs in the IRQ controller itself, 
the easiest way to stop them is to kill signals - as per the patch.



johannes


--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Bug#1005887: unixodbc-dev does not contain unixodbc_conf.h

[Hugh McMaster]

Hallo Jan,

On Tue, 22 Feb 2022 at 07:06, Jan Wielemaker wrote:
>
> Thanks for your answer.  I'm not convinced.  You are telling that we
> must define macros to make sql.h get the right type for SQLBIGINT.
> Getting the right type (some alias for int64_t or a struct) is IMO
> something that should be done by unixodb such that the application
> gets a working SQLBIGINT that matches the library.  That is how it
> used to be as long as we use unixodbc.   sql.h used to do so by
> including the platform dependent type configuration file.  As it
> is working now, we actually have to know which of the HAVE_* and
> SIZEOF_* macros we must define before including sql.h.
> If this is no longer how it works, do you happen to know the
> motivation why not?


This is how the headers should ideally be used. However, most programs
don't #define SIZEOF_LONG_INT and rely on the presence of
unixodbc_conf.h to #define all relevant macros (generally, just
SIZEOF_LONG_INT and HAVE_LONG_LONG). This is much easier and most
likely the expected behaviour.

If you look at sqltypes.h, you'll notice #ifndef SIZEOF_LONG_INT then
#includes unixodbc_conf.h.

unixodbc_conf.h is an arch-specific header, which mostly contains
information on how unixodbc was built. Most of this information is not
relevant to downstream packages. I'm working with upstream to split
unixodbc_conf.h into a public header that contains relevant #defines
and a private header with the build-system information.

In the meantime, I'll update the Debian package to avoid this issue by
including the relevant macros from unixodbc_conf.h. That way, defining
SIZEOF_LONG_INT will not be required and everything should work as it
did previously.

Bug#1006271: network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses

[Mad Horse]

Package: network-manager
Version: 1.35.91-1
Severity: important

Dear Maintainer,

network-manager 1.35.91-1 and 1.35.92-1 will abort if DHCPv6 server sends
multiple IPv6 addresses,( as under a default-configured openwrt router ) 
because

in this case, nm_dhcp_utils_merge_new_dhcp6_lease() would call
nm_l3_config_data_new_clone() with ifindex=-1, which may originally result
ifindex = src->ifindex; but now in order to make such effect, ifindex 
should be

set to 0 instead a negative value, otherwise such call will abort
network-manager for violating the assertion nm_assert(ifindex >= 0) in
nm_l3_config_data_new_clone().


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages network-manager depends on:
ii adduser 3.118
ii dbus 1.12.20-3
ii libaudit1 1:3.0.7-1
ii libbluetooth3 5.62-2
ii libc6 2.33-6
ii libcurl3-gnutls 7.81.0-1
ii libglib2.0-0 2.70.4-1
ii libgnutls30 3.7.3-4+b1
ii libjansson4 2.13.1-1.1
ii libmm-glib0 1.18.6-1
ii libndp0 1.6-1+b1
ii libnewt0.52 0.52.21-5+b1
ii libnm0 1.35.91-1
ii libpsl5 0.21.0-1.2
ii libreadline8 8.1.2-1
ii libselinux1 3.3-1+b1
ii libsystemd0 250.3-2
ii libteamdctl0 1.31-1
ii libudev1 250.3-2
ii policykit-1 0.105-32
ii udev 250.3-2

Versions of packages network-manager recommends:
ii dnsmasq-base [dnsmasq-base] 2.86-1.1
ii iptables 1.8.7-1
ii libpam-systemd 250.3-2
ii modemmanager 1.18.6-1
ii ppp 2.4.9-1+1
ii wireless-regdb 2021.08.28-1
ii wpasupplicant 2:2.9.0-23

Versions of packages network-manager suggests:
ii libteam-utils 1.31-1

Versions of packages network-manager is related to:
ii isc-dhcp-client 4.4.1-2.3

-- no debconf information

Bug#1005900: [PATCH] um: Fix uml_mconsole stop/go

[anton . ivanov]

From: Anton Ivanov 

Moving to an EPOLL based IRQ controller broke uml_mconsole stop/go
commands. This fixes it and restores stop/go functionality.

Fixes: ff6a17989c08b0bb0fd490cc500b084581b3a9b9 Epoll based IRQ controller
Signed-off-by: Anton Ivanov 
---
 arch/um/drivers/mconsole_kern.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/um/drivers/mconsole_kern.c b/arch/um/drivers/mconsole_kern.c
index 6ead1e240457..8ca67a692683 100644
--- a/arch/um/drivers/mconsole_kern.c
+++ b/arch/um/drivers/mconsole_kern.c
@@ -224,7 +224,7 @@ void mconsole_go(struct mc_request *req)
 
 void mconsole_stop(struct mc_request *req)
 {
-   deactivate_fd(req->originating_fd, MCONSOLE_IRQ);
+   block_signals();
os_set_fd_block(req->originating_fd, 1);
mconsole_reply(req, "stopped", 0, 0);
for (;;) {
@@ -247,6 +247,7 @@ void mconsole_stop(struct mc_request *req)
}
os_set_fd_block(req->originating_fd, 0);
mconsole_reply(req, "", 0, 0);
+   unblock_signals();
 }
 
 static DEFINE_SPINLOCK(mc_devices_lock);
-- 
2.30.2

Bug#1006270: network-manager: crashes if DHCPv6 server sends multiple IPv6 addresses

[Mad Horse]

Package: .
Version: 1.35.91-1
Severity: important

Dear Maintainer,

network-manager 1.35.91-1 and 1.35.92-1 will abort if DHCPv6 server sends
multiple IPv6 addresses,( as under a default-configured openwrt router ) 
because

in this case, nm_dhcp_utils_merge_new_dhcp6_lease() would call
nm_l3_config_data_new_clone() with ifindex=-1, which may originally result
ifindex = src->ifindex; but now in order to make such effect, ifindex 
should be

set to 0 instead a negative value, otherwise such call will abort
network-manager for violating the assertion nm_assert(ifindex >= 0) in
nm_l3_config_data_new_clone().


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

Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=zh_CN.utf8, LC_CTYPE=zh_CN.utf8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages network-manager depends on:
ii adduser 3.118
ii dbus 1.12.20-3
ii libaudit1 1:3.0.7-1
ii libbluetooth3 5.62-2
ii libc6 2.33-6
ii libcurl3-gnutls 7.81.0-1
ii libglib2.0-0 2.70.4-1
ii libgnutls30 3.7.3-4+b1
ii libjansson4 2.13.1-1.1
ii libmm-glib0 1.18.6-1
ii libndp0 1.6-1+b1
ii libnewt0.52 0.52.21-5+b1
ii libnm0 1.35.91-1
ii libpsl5 0.21.0-1.2
ii libreadline8 8.1.2-1
ii libselinux1 3.3-1+b1
ii libsystemd0 250.3-2
ii libteamdctl0 1.31-1
ii libudev1 250.3-2
ii policykit-1 0.105-32
ii udev 250.3-2

Versions of packages network-manager recommends:
ii dnsmasq-base [dnsmasq-base] 2.86-1.1
ii iptables 1.8.7-1
ii libpam-systemd 250.3-2
ii modemmanager 1.18.6-1
ii ppp 2.4.9-1+1
ii wireless-regdb 2021.08.28-1
ii wpasupplicant 2:2.9.0-23

Versions of packages network-manager suggests:
ii libteam-utils 1.31-1

Versions of packages network-manager is related to:
ii isc-dhcp-client 4.4.1-2.3

-- no debconf information

Bug#1006009: qtimageformats-opensource-src: FTBFS on mipsel: test failure

[Sebastian Ramacher]

Control: tags -1 patch

On 2022-02-21 22:05:53, Sebastian Ramacher wrote:
> On 2022-02-20 18:33:22, Dmitry Shachnev wrote:
> > Control: reassign -1 libwebp7 1.2.1-7
> > Control: affects -1 src:qtimageformats-opensource-src
> > 
> > Hi Sebastian and libwebp maintainers!
> > 
> > On Fri, Feb 18, 2022 at 10:39:23PM +0100, Sebastian Ramacher wrote:
> > > Source: qtimageformats-opensource-src
> > > Version: 5.15.2-2
> > > Severity: serious
> > > Tags: ftbfs
> > > Justification: fails to build from source (but built successfully in the 
> > > past)
> > > X-Debbugs-Cc: sramac...@debian.org
> > >
> > > qtimageformats-opensource-src FTBFS on mipsel:
> > >
> > > TIFFReadDirectory: Warning, Sum of Photometric type-related color 
> > > channels and ExtraSamples doesn't match SamplesPerPixel. Defining 
> > > non-color channels as ExtraSamples..
> > > TIFFReadDirectory: Warning, Sum of Photometric type-related color 
> > > channels and ExtraSamples doesn't match SamplesPerPixel. Defining 
> > > non-color channels as ExtraSamples..
> > > PASS   : tst_qtiff::tiffGrayscale()
> > > FAIL!  : tst_qwebp::writeImage(kollada_noalpha-100) '!reread.isNull()' 
> > > returned FALSE. ()
> > >Loc: [tst_qwebp.cpp(174)]
> > > PASS   : tst_qwebp::cleanupTestCase()
> > > Totals: 10 passed, 1 failed, 0 skipped, 0 blacklisted, 632ms
> > > * Finished testing of tst_qwebp *
> > >
> > > See
> > > https://buildd.debian.org/status/fetch.php?pkg=qtimageformats-opensource-src=mipsel=5.15.2-2%2Bb1=1645209225=0
> > 
> > It looks to me like a bug in new libwebp version: encoder generates broken
> > webp files on mipsel.
> > 
> > I can reproduce it without any Qt code by encoding the attached PNG file and
> > then trying to decode it back:
> > 
> > (sid_mipsel-dchroot)mitya57@eller:~$ cwebp kollada_noalpha.png -lossless -o 
> > kollada_noalpha.webp
> > Saving file 'kollada_noalpha.webp'
> > File:  kollada_noalpha.png
> > Dimension: 436 x 160
> > Output:37004 bytes (4.24 bpp)
> > Lossless-ARGB compressed size: 37004 bytes
> >   * Header size: 636 bytes, image data size: 36342
> >   * Precision Bits: histogram=3 transform=3 cache=1
> > (sid_mipsel-dchroot)mitya57@eller:~$ dwebp kollada_noalpha.webp
> > Decoding of kollada_noalpha.webp failed.
> > Status: 3(BITSTREAM_ERROR)
> > 
> > I am also attaching the generated broken WEBP file.
> 
> A git bisect run suggests that this issue was introduced upstream in
> dea3e89983f299b3325898fa5b9474be258553b2 and is not yet fixed.

Disabling the mips specific optimizations works around this issue. See
the attached patch for a temporary fix until this issue is properly
fixed upstream.

Cheers
-- 
Sebastian Ramacher
diff --git a/src/dsp/dsp.h b/src/dsp/dsp.h
index fafc2d05..d466893c 100644
--- a/src/dsp/dsp.h
+++ b/src/dsp/dsp.h
@@ -97,17 +97,17 @@ extern "C" {
 
 #if defined(__mips__) && !defined(__mips64) && \
 defined(__mips_isa_rev) && (__mips_isa_rev >= 1) && (__mips_isa_rev < 6)
-#define WEBP_USE_MIPS32
+/* #define WEBP_USE_MIPS32 */
 #if (__mips_isa_rev >= 2)
-#define WEBP_USE_MIPS32_R2
+/* #define WEBP_USE_MIPS32_R2 */
 #if defined(__mips_dspr2) || (defined(__mips_dsp_rev) && __mips_dsp_rev >= 2)
-#define WEBP_USE_MIPS_DSP_R2
+/* #define WEBP_USE_MIPS_DSP_R2 */
 #endif
 #endif
 #endif
 
 #if defined(__mips_msa) && defined(__mips_isa_rev) && (__mips_isa_rev >= 5)
-#define WEBP_USE_MSA
+/* #define WEBP_USE_MSA */
 #endif
 
 #endif  /* EMSCRIPTEN */

Bug#1006131: rus-ispell: please stop build-depending on myspell-tools

[Agustin Martin]

Control: tags -1 +pending

El mar, 22 feb 2022 a las 8:05, Mikhail Gusarov
() escribió:
>
> Hello Agustin,
>
> On 21 Feb 2022, at 23:46, Agustin Martin wrote:
>
> >> Could you show me the difference?
>
> > Find attached diff. SInce flags are sorted differently by i2myspell
> > and ispellaff2myspell , I made some magic for easier check of result,
> > actually diffing sorted affix files. This is what leads to that file
>
> Thanks. Looks fine for me.
> Actually, new file has the Cyrillic letters sorted in the right order :)

Thanks a lot,

-- 
Agustin

Bug#1006269: appstream: apt hook shows non-actionable warnings if Flathub metadata has issues

[Simon McVittie]

Package: appstream
Version: 0.15.1-1
Severity: normal

I cannot reproduce this right now (it seems to be intermittent?), but
the steps that previously reproduced it were:

* Have flatpak installed
* Have Flathub configured as a remote in the system repository
  /var/lib/flatpak: https://flatpak.org/setup/Debian
* Have appstream installed
* `sudo apt update`, or the equivalent in aptitude

Expected result: no error messages unless there is something that the
sysadmin needs to resolve.

Actual result, as reported at https://github.com/flatpak/flatpak/issues/4642
and https://github.com/flathub/cc.nift.nsm/issues/3:

** (appstreamcli:11481): WARNING **: 21:53:33.554: Found icon of unknown 
type 'unknown' in 'system/flatpak/flatpak/cc.nift.nsm/*', skipping it.

** (appstreamcli:11481): WARNING **: 21:53:33.554: Found icon of unknown 
type 'unknown' in 'system/flatpak/flatpak/cc.nift.nsm/*', skipping it.

If this happens again I'll try to capture the Appstream XML that Flathub was
sending at the time.

appstreamcli should perhaps have a --quiet option that tries to recover
from this sort of thing without issuing warnings, which could be used
in the apt hook?

smcv

Bug#1005671: libvirt-python: FTBFS: ERROR: failed virDomainSetLaunchSecurityState

[Guido Günther]

Hi Fabio,
On Tue, Feb 22, 2022 at 10:15:22AM +0100, Fabio Fantoni wrote:
> Hi, is there someone working on this? if yes let me know please otherwise
> I'll try to do it when I have time

Thanks for the reminder. I just uploaded a new version.
Cheers,
 -- Guido

Bug#1005739: Re: Re: Bug#1005739: RFS: ukui-bluetooth/1.0.2-1 [ITP] -- Bluetooth manager for UKUI desktop environment

[handsome_feng]

Hi, This is because ukui-bluetooth gets position from the dbus of ukui-panel, 
now
we added an if judgment to deal with the situation when no ukui-panel (but 
QSystemTrayIcon::geometry() not work whell under some DE, will keep 
investigating).


I have uploaded the new version to the mentors:
https://mentors.debian.net/package/ukui-bluetooth/


Regards,
handsome_feng










在2022年02月18 22时56分，"Adam Borowski"写道：

On Fri, Feb 18, 2022 at 05:30:35PM +0800, handsome_feng wrote:
> Hi, 
> 
> I can't reproduce it locally(Debian unstable), could you show me the
> result of 'apt-cache policy ukui-panel'  and 'cat /etc/os-release' ?

[~]$ apt-cache policy ukui-panel
ukui-panel:
  Installed: (none)
  Candidate: 3.0.5-1
  Version table:
 3.0.5-1 500
500 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages
500 http://apt-rosy.angband.pl:3142/debian bookworm/main amd64 Packages
[~]$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/;
SUPPORT_URL="https://www.debian.org/support;
BUG_REPORT_URL="https://bugs.debian.org/;


>>> It builds successfully, however, if I start it and click on the icon, I get
>>> a segfault.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Being wise is hard, but wise-ass... ooh, this one I can deliver!
⠈⠳⣄

Bug#1006268: links2: still shows cached pages pages despite “-aggressive-cache 0 -format-cache-size 0”

[Axel Stammler]

Package: links2
Version: 2.21-1+b1
Severity: normal
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

Links 2 always shows previously loaded content whatever combination of command 
line
options I use. It only shows new content when it is called immediately again a 
second time.


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

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

Versions of packages links2 depends on:
ii  libbrotli1 1.0.9-2+b2
ii  libbz2-1.0 1.0.8-4
ii  libc6  2.31-13+deb11u2
ii  libcairo2  1.16.0-5
ii  libdirectfb-1.7-7  1.7.7-9
ii  libevent-2.1-7 2.1.12-stable-1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.4+dfsg-1
ii  libglib2.0-0   2.66.8-1
ii  libgomp1   10.2.1-6
ii  libgpm21.20.7-8
ii  libjpeg62-turbo1:2.0.6-4
ii  liblz1 1.12-1
ii  liblzma5   5.2.5-2
ii  libpng16-161.6.37-3
ii  librsvg2-2 2.50.3+dfsg-1
ii  libssl1.1  1.1.1k-1+deb11u1
ii  libtiff5   4.2.0-1
ii  libx11-6   2:1.7.2-1
ii  libzstd1   1.4.8+dfsg-2.1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages links2 recommends:
ii  ca-certificates   20210119
ii  gnome-terminal [x-terminal-emulator]  3.38.3-1
ii  konsole [x-terminal-emulator] 4:20.12.3-1
ii  lxterminal [x-terminal-emulator]  0.4.0-1
ii  mlterm [x-terminal-emulator]  3.9.0-1
ii  xterm [x-terminal-emulator]   366-1

links2 suggests no packages.

-- debconf-show failed

Bug#1006267: Recommends (not Depends) xdg-desktop-portal-*? (don't require fuse/bwrap)

[Trent W. Buck]

Package: chromium
Version: 98.0.4758.102-1~deb11u1
Severity: normal

(This was initially sent to 1005...@bugs.debian.org;
dilinger convinced me this should be a new ticket.)

Hi, I ship chromium in prisons, where we extremely do not want
unprivileged users to be able to add new drivers (fuse) and
applications (flatpak/bubblewrap/xdg-desktop-portal). [*]

https://bugs.debian.org/1005230 and
https://bugs.debian.org/1005410 were recently fixed by adding
Depends: xdg-desktop-portal-gtk | xdg-desktop-portal-backend
which means chromium now hard-depends on fuse and bubblewrap.

 1. xdg-desktop-portal-* is not needed for XFCE and sway users.

As an experiment, I tried

   dpkg --force-depends --purge \
   xdg-desktop-portal \
   xdg-desktop-portal-backend \
   xdg-desktop-portal-gtk \
   fuse libfuse2 \
   fuse3 libfuse3-3 \
   bubblewrap flatpak \
   libgnome-desktop-3-19

And after doing so, I rebooted, logged into a GUI as a new user,
started chromium, successfully browsed to https://example.com/, and
successfully used File Open and File Save dialogues (the were GTK3-style).

I tested this with Debian 11 / Xorg / XFCE.
I tested this with Debian 11 / sway / Xwayland.

In both cases, everything worked,
i.e. the desktop portal is (presumably) not needed.

I'm not sure why other people seem to need xdg-desktop-portal-*.
My only guess is that I was testing in a qemu VM, and
maybe chromium silently disables sandboxing when it detects a VM???

I briefly tried to test task-gnome-desktop, but
gdm3 didn't auto-start, so I gave up.

I didn't test KDE, LXDE, Cinnamon, Mate, wlroots, or plain X (no DE/WM at 
all).

Boring details (turnkey test script ) are in my earlier emails here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005230#25


 2. I have a viable workaround, which
is just to make a fake xdg-desktop-portal package.
This is not really interesting to anyone else, but
I attach it for completeness.


>From MY perspective, the "easy" answer is to just downgrade Depends to 
>Recommends.

However this will re-break chromium for people who have neither gtk*
nor xdg-desktop-portal* installed (i.e. #1005230).

dilinger suggested something like the below.
Getting this just right will require some Deep Thinks.
I don't understand chromium internals enough to do that myself :-(

Depends: libgtk-4-1 |
 libgtk-3-0 |
 xdg-desktop-portal-gtk |
 xdg-desktop-portal-backend


[*] I have a bunch of other layers to block these, but
"libfuse* isn't even installed" is really nice layer to have.
e.g. detainee kernels have CONFIG_FUSE_FS disabled
(though CONFIG_USER_NS is enabled due to systemd).
Format: 3.0 (native)
Source: xdg-desktop-portal-ersatz
Binary: xdg-desktop-portal-ersatz
Architecture: all
Version: 11.0
Maintainer: Trent W. Buck 
Uploaders: Trent W. Buck 
Standards-Version: 4.3.0
Build-Depends: debhelper-compat (= 13)
Package-List:
 xdg-desktop-portal-ersatz deb metapackages optional arch=all
Checksums-Sha1:
 00944a5479997e1b0bf1ee953b263e7c6eb2ada4 2008 
xdg-desktop-portal-ersatz_11.0.tar.xz
Checksums-Sha256:
 c682a6987abb0b0c6c8a9d125a544f7300d3ac114501ec44723cf9351de00e2d 2008 
xdg-desktop-portal-ersatz_11.0.tar.xz
Files:
 6b2741ba9134a28c6e35ae8d317f7565 2008 xdg-desktop-portal-ersatz_11.0.tar.xz


xdg-desktop-portal-ersatz_11.0.tar.xz
Description: application/xz


xdg-desktop-portal-ersatz_11.0_all.deb
Description: application/vnd.debian.binary-package
 dpkg-buildpackage -us -uc -ui
dpkg-buildpackage: info: source package xdg-desktop-portal-ersatz
dpkg-buildpackage: info: source version 11.0
dpkg-buildpackage: info: source distribution bullseye
dpkg-buildpackage: info: source changed by Trent W. Buck 
 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (native)'
dpkg-source: info: building xdg-desktop-portal-ersatz in 
xdg-desktop-portal-ersatz_11.0.tar.xz
dpkg-source: info: building xdg-desktop-portal-ersatz in 
xdg-desktop-portal-ersatz_11.0.dsc
 debian/rules binary
dh binary
   create-stamp debian/debhelper-build-stamp
dpkg-deb: building package 'xdg-desktop-portal-ersatz' in 
'../xdg-desktop-portal-ersatz_11.0_all.deb'.
 dpkg-genbuildinfo
 dpkg-genchanges  >../xdg-desktop-portal-ersatz_11.0_amd64.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: full upload; Debian-native package (full source is 
included)
Now running lintian xdg-desktop-portal-ersatz_11.0_amd64.changes ...
warning: running with root privileges is not recommended!
W: xdg-desktop-portal-ersatz: debian-changelog-line-too-long line 4
W: xdg-desktop-portal-ersatz: debian-changelog-line-too-long line 7
W: xdg-desktop-portal-ersatz: extended-description-line-too-long line 14

Bug#1006266: reportbug: does not work if Socks proxy is used in environment

[Axel Stammler]

Package: reportbug
Version: 7.10.3+deb11u1
Severity: normal
X-Debbugs-Cc: a...@users.sourceforge.net

Dear Maintainer,

I use Tor Socks and these environment settings:

$ set | grep -i proxy
ALL_PROXY=socks://127.0.0.1:9050/
NO_PROXY=localhost,127.0.0.0/8,::1,10.0.0.0/8,192.168.0.0/16
all_proxy=socks://127.0.0.1:9050/
no_proxy=localhost,127.0.0.0/8,::1,10.0.0.0/8,192.168.0.0/16

Report Bugs complains and exits:

Checking for newer versions at madison...
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2381, in 
main()
  File "/usr/bin/reportbug", line 1120, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1697, in user_interface
(avail, toonew) = checkversions.check_available(
  File "/usr/lib/python3/dist-packages/reportbug/checkversions.py", line 294, 
in check_available
stuff = get_versions_available(package, timeout, dists, http_proxy, arch)
  File "/usr/lib/python3/dist-packages/reportbug/checkversions.py", line 135, 
in get_versions_available
page = open_url(url, http_proxy, timeout)
  File "/usr/lib/python3/dist-packages/reportbug/urlutils.py", line 183, in 
open_url
page = urlopen(url, proxies, timeout)
  File "/usr/lib/python3/dist-packages/reportbug/urlutils.py", line 127, in 
urlopen
return requests.get(url, headers=headers, proxies=proxies, 
timeout=timeout).text
  File "/usr/lib/python3/dist-packages/requests/api.py", line 76, in get
return request('get', url, params=params, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 542, in 
request
resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 655, in send
r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 412, in send
conn = self.get_connection(request.url, proxies)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 309, in 
get_connection
proxy_manager = self.proxy_manager_for(proxy)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 182, in 
proxy_manager_for
manager = self.proxy_manager[proxy] = SOCKSProxyManager(
  File "/usr/lib/python3/dist-packages/urllib3/contrib/socks.py", line 198, in 
__init__
raise ValueError("Unable to determine SOCKS version from %s" % proxy_url)
ValueError: Unable to determine SOCKS version from socks://127.0.0.1:9050/

If I put a line with “http_proxy” without arguments into ~/.reportbugrc, there 
is no
change. If I add “all_proxy” without argounts, Report Bug cannot reach the 
Debian servers:

Error retrieving information on existing bug reports from the BTS. The 
following error was detected:
Unable to connect to Debian BTS (error: "ServerNotFoundError('Unable to find 
the server at bugs.debian.org')");
Do you still want to file a report [y|N|q|?]?

I hope this report can be sent out anyway.


-- Package-specific info:
** Environment settings:
EDITOR="/usr/bin/utvim"
PAGER="/usr/bin/less"
INTERFACE="text"

** /home/axel/.reportbugrc:
reportbug_version "7.10.3+deb11u1"
mode novice
ui text
realname "Axel Stammler"
email "a...@users.sourceforge.net"
no-cc
list-cc-me
smtphost reportbug.debian.org
http_proxy
all_proxy

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

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

Versions of packages reportbug depends on:
ii  apt2.2.4
ii  python33.9.2-3
ii  python3-reportbug  7.10.3+deb11u1
ii  sensible-utils 0.0.14

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.39-3
ii  gnupg 2.2.27-2
ii  python3-urwid 2.1.2-1
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-4.1

Versions of packages python3-reportbug depends on:
ii  apt2.2.4
ii  file   1:5.39-3
ii  python33.9.2-3
ii  python3-apt2.2.1
ii  python3-debian 0.1.39
ii  python3-debianbts  3.1.0
ii  python3-requests   2.25.1+dfsg-2
ii