Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Biebl]

Control: reassign -1 libc6
Control: found -1 2.32-1
Control: severity -1 serious
Control: affects -1 + systemd

Hi Michael

Am 07.09.21 um 00:39 schrieb Michael Hudson-Doyle:
On Tue, 7 Sept 2021 at 10:21, Michael Biebl > wrote:


Am 06.09.21 um 23:45 schrieb Vincent Bernat:
  > Package: systemd
  > Version: 247.9-1
  > Severity: normal
  >
 > Hey!
 >
 > After upgrading to libc6 2.32-1, some services are unable to restart.
 > In my case, systemd-resolved, systemd-timesyncd and colord. Using
 > "systemctl daemon-reexec" fixes the issue. Unsure if there is really
 > something to be fixed but as I didn't find anything about that, a bug
 > report may help others. I suppose the problem is related to NSS.
 >
 > Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time
Synchronization...
 > Sep 06 23:06:43 chocobo systemd[236983]:
systemd-timesyncd.service: Failed to determine user credentials: No
such process
 > Sep 06 23:06:43 chocobo systemd[236983]:
systemd-timesyncd.service: Failed at step USER spawning
/lib/systemd/systemd-timesyncd: No such process
 >
 >


@libc maintainers: any ideas what could be causing this? If this is
triggered by a libc6 update, should this be reassigned to glibc?


We went through this in Ubuntu recently and decided that restarting 
systemd in glibc's postinst was the safest option: 
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276 



What's happening is that systemd is running with the old glibc, forks 
and then does NSS things that cause the new glibc's NSS modules to load 
and they don't necessarily work, leading to failures in any unit that 
specifies User=. At least for Ubuntu's builds the NSS modules seem to be 
ABI compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but 
they are definitely not between 2.33 and 2.34.


Thanks for this information. This is indeed an icky issue and I feel 
like we are between a rock and a hard place.
I'm not a huge fan of going back to re-exec systemd again directly in 
libc6.postinst, but your proposed patch to at least check that the 
systemd binary can be sucessfully executed should at least deal with the 
situation sufficiently, where a library is (temporarily) missing.
I do wonder though, if this this will mean that on dist-upgrades the 
daemon-reexec will be skipped.


Anyway, I think it's best to reassign this libc6 for now and mark it as 
RC so the package doesn't migrate to testing for now.


Regards,
Michael



OpenPGP_signature
Description: OpenPGP digital signature

Bug#907118: Goeie dag

[dir comp]

Ek het hierdie sakegeleentheid -voorstel vir u wat ons sal baat; Ek sal ook
daarvan hou dat jy dit sien.

Groete,
Frank William
64 980 4011

Bug#742900: Goeie dag

[dir comp]

Ek het hierdie sakegeleentheid -voorstel vir u wat ons sal baat; Ek sal ook
daarvan hou dat jy dit sien.

Groete,
Frank William
64 980 4011

Bug#867853: Goeie dag

[dir comp]

Ek het hierdie sakegeleentheid -voorstel vir u wat ons sal baat; Ek sal ook
daarvan hou dat jy dit sien.

Groete,
Frank William
64 980 4011

Bug#829444: Accepting / adopting DEP-14

[Otto Kekäläinen]

Hello!

Any updates on the Debian package git branch layout?

I am about to start working on mariadb-10.6 and will create a new repo
for it, and would be open to adopting DEP-14 if it is finalized.

If gbp-buildpackage adopts the current  DEP-14, please mention it in
the changelog:
https://tracker.debian.org/media/packages/g/git-buildpackage/changelog-0.9.23

Latest reference to DEP-14 is in 2016. Following DEP-14 would be
easiest if git-buildpackage simply did so by default.

Also, it would be nice to see a couple of links to repositories that
have DEP-14. Even better would be some stats on the different
suggested conventions to see what their adoption rate currently is,
and what has turned out to be the most popular conventions.

Thanks if you have time to update the status on this,

- Otto

Bug#993802: RFS: psad/2.4.6-1 [QA] -- Port Scan Attack Detector

[Boyuan Yang]

Control: tags -1 +moreinfo

On Mon, 6 Sep 2021 14:29:30 -0300 Leandro Cunha 
wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "psad":
> 
>  * Package name    : psad
>    Version : 2.4.6-1
>    Upstream Author : Michael B. Rash 
>  * URL : http://www.cipherdyne.org/psad/
>  * License : GPL-2+, other-1, other-2
>  * Vcs : https://salsa.debian.org/debian/psad
>    Section : admin
> 
> It builds those binary packages:
> 
>   psad - Port Scan Attack Detector
> 
> To access further information about this package, please visit the
> following URL:
> 
>   https://mentors.debian.net/package/psad/
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
https://mentors.debian.net/debian/pool/main/p/psad/psad_2.4.6-1.dsc
> 
> Changes since the last upload:
> 
>  psad (2.4.6-1) unstable; urgency=medium
>  .
>    * QA upload.
>    * New upstream release.
>    * Add debian/upstream/metadata and fixed Lintian report.
>    * Add debian/salsa-ci.yml.
>    * debian/control:
>  - Set maintainer Debian QA Group .
>  - Update Vcs-Git and Vcs-Browser of anonscm to Salsa reported by
Lintian.
>  - Add Rules-Requires-Root reported by Lintian.
>    * debian/docs and debian/psad.manpages:
>  - There has been a change of upstream in the file directories to doc
>    folder and removed FW_EXAMPLE_RULES file.
>    * debian/watch:
>  - Use secure URI reported by Lintian.
>  - Change version of 3 to 4 reported by Lintian.
>    * debian/copyright:
>  - Remove line 10 unused paragraph in file reported by Lintian.
>  - Add myself.
>  - Fix Upstream-Name.
>    * Drop debian/patches/fix_spelling.diff applied by upstream.
>    * Remove trailing whitespace reported by Lintian.

Please address my comments in https://bugs.debian.org/993745 . When solved, I
can review and upload this version.

Thanks,
Boyuan Yang


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

Bug#993745: O: psad -- Designed to work with iptables to detect port scans

[Boyuan Yang]

X-Debbugs-CC: franck.jonco...@gmail.com leandrocunha...@gmail.com

Hi,

On Sun, 5 Sep 2021 18:02:50 -0300 Leandro Cunha 
wrote:
> Package: wnpp
> Severity: normal
> 
> Hi,
> 
> I communicate that due to the inactivity since 2018 in the psad package,
> I am orphaning this package and in this case the QA group becomes the
> maintainer. If you are still interested in working on this package, please
> respond to this bug, which I can close. Thanks for the work.
> 
> Maintaining a package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
> 
> If you want to be the new maintainer, please see
> https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
> instructions how to adopt a package properly.

I believe what you are doing is exactly called "packaging hijacking", which is
unfavorable. Since the original maintainer did not volunteerly orphan the
package and that the Debian MIA Team did not kick in, we must not assume that
the original package maintainer has given up the maintenance responsibility.

Debian has a readily-available process to handle current situation (ITS) and I
believe you also know it. We should follow this procedure to take over package
maintenance in order to ensure smooth takeover where no argument would take
place.

My suggestion is to convert this orphaning report to ITS report and start ITS
process immediately according to
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#package-salvaging
.

This mail copy is also sent to the original package maintainer (Franck
Joncourt). Franck: please let us know whether you are still going to maintain
this package in Debian. If there's no response, we will continue with the ITS
process and take over the maintenance of package psad in Debian.

Thanks,
Boyuan Yang


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

Bug#788411: Please update the patch

[Helmut Grohne]

Hi Anton,

On Mon, Sep 06, 2021 at 09:45:34PM +0200, Anton Gladky wrote:
> Please cancel NMU upload, because I am preparing the next gmp version,
> where some
> more bug sare fixed.
 
Great, cancelled. Please upload your solution before both bookworm and
the need for another rebase.

Helmut

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Holger Wansing]

Control: retitle -1 Install CUPS for all *-desktop tasks, now that 
task-print-service is no longer existing
Control: tags -1 + patch


Holger Wansing  wrote (Sun, 5 Sep 2021 21:48:35 +0200):
> Hmm, apparently you are right.
> (I was under the impression, that the libcups2 package pulls all the needed
> cups packages, but I was wrong here.)
> 
> So we will need to add cups to all the *-desktop tasks probably, to
> make this work again.
> (Rationale: the print server task has been removed from tasksel under the
> assumption, that cups is installed with all desktop environments anyway.
> However, this is not true as it seems, at least not now.)

The attached diff should do it.

Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/control b/debian/control
index 9cff6f6d..1f469e86 100644
--- a/debian/control
+++ b/debian/control
@@ -31,80 +31,82 @@ Recommends: laptop-detect, tasksel
 Conflicts: tasksel (<< 2.67)
 Description: official tasks used for installation of Debian systems
  This package contains data about the standard tasks available on a Debian
  system.
 
 Package: task-desktop
 Architecture: all
 Description: Debian desktop environment
  This task package is used to install the Debian desktop.
 Depends: ${misc:Depends},
 	xorg,
 	xserver-xorg-video-all,
 	xserver-xorg-input-all,
 	desktop-base,
 Recommends:
 # One of the actual desktop tasks is needed to get a full desktop environment.
 # The order here is significant when installing this task manually;
 # when tasksel installs this task it instead selects one of these based
 # on the tasksel/desktop debconf setting.
 	task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop,
 # For use by third-party apps.
 	xdg-utils,
 # Font with wide unicode coverage, prevents “Unicode tofu”
 	fonts-symbola,
 # mdns/zeroconf stuff
 	avahi-daemon,
 	libnss-mdns,
 # desktop machines might not be up 24/7
 	anacron,
 # Make sure that CDs etc can be ejected. May not be installed by d-i.
 	eject,
 # wireless networking tools (they're more and more used on desktops too)
 	iw,
 # sound
 	alsa-utils,
 # For use by users, to elevate privileges
 	sudo,
 # firefox is the most popular web browser at the moment,
 # although both gnome and kde offer their own too
 	firefox | firefox-esr,
+# print system
+	cups,
 
 Package: task-gnome-desktop
 Architecture: all
 Description: GNOME
  This task package is used to install the Debian desktop, featuring
  the GNOME desktop environment, and with other packages that Debian users
  expect to have available on the desktop.
 Depends: ${misc:Depends},
 	task-desktop,
 # only depend on a very minimal gnome desktop, to ensure it fits on CD1
 	gnome-core,
 Recommends:
 # The full gnome desktop environment should be included if possible
 # even if the larger gnome metapackage doesn't fit.
 	gnome,
 # Package management
 	synaptic,
 # GNOME support in LibreOffice
 	libreoffice-gnome,
 # libreoffice is the best word processor / office suite at the moment
 	libreoffice-writer,
 	libreoffice-calc,
 	libreoffice-impress,
 # make help menu work
 	libreoffice-help-en-us,
 # make thesaurus work
 	mythes-en-us,
 # make spellchecker work
 	hunspell-en-us,
 # make hyphenation work
 	hyphen-en-us,
 # we need a working network setup at least
 	network-manager-gnome,
 
 Package: task-gnome-flashback-desktop
 Architecture: all
 Description: GNOME Flashback
  This task package is used to install the Debian desktop, featuring
  the GNOME Flashback desktop environment, and with other packages that
  Debian users expect to have available on the desktop.

Bug#993827: upgrade-reports: Installation of firewalld caused surprising results

[Kjetil Kjernsmo]

Package: upgrade-reports
Severity: normal

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

My previous release is: Buster
I am upgrading to: Bullseye
Upgrade date: 2021-09-04  15:05:52
uname -a after upgrade: Linux robin 5.10.0-8-amd64 #1 SMP Debian
5.10.46-4 (2021-08-03) x86_64 GNU/Linux

Method:  apt full-upgrade

Contents of /etc/apt/sources.list:

deb http://ftp.no.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp.no.debian.org/debian/ bullseye main contrib non-free

deb http://security.debian.org/debian-security bullseye-security main
contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security
main contrib non-free

# bullseye-updates, previously known as 'volatile'
deb http://ftp.no.debian.org/debian/ bullseye-updates main
deb-src http://ftp.no.debian.org/debian/ bullseye-updates main


The upgrade went smoothly, except for one problem, it closed all ports
except 22. 

It took me a while to figure out, but I eventually solved it by doing 
 systemctl stop firewalld.service 
 systemctl disable firewalld.service 

I did not have time for a more thorough investigation than the time it
took to figure it out, but I hope this report is useful nevertheless.

I believe that what happened is that firewalld has a default setup
that closes everything except port 22. This box didn't need a firewall
of its own, it is behind a firewall managed by a different system, but
apparently, iptables was installed as a dependency of Docker. Then,
I have configured apt with
APT::Install-Suggests "true";
and so firewalld got installed as a result. It was not suggested by
iptables in Buster.

I leave it to you to determine what the appropriate action might be. I
guess the Install-Suggests is a relatively rarely used feature, so it
is not very likely to be a widespread problem. I don't know if it is
possible to have firewalld ask the user whether they want to close
down if it is installed as a dependency or something.

Cheers,

Kjetil
   

Bug#993837: shotcut FTBFS with mlt 7

[Adrian Bunk]

Source: shotcut
Version: 21.01.29+ds-1
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=shotcut=sid

...
cd src/ && ( test -e Makefile || /usr/lib/qt5/bin/qmake -o Makefile 
/<>/src/src.pro 'QMAKE_CFLAGS_RELEASE=-g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 'QMAKE_CFLAGS_DEBUG=-g 
-O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
'QMAKE_CXXFLAGS_RELEASE=-g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2' 'QMAKE_CXXFLAGS_DEBUG=-g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2' 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr ) && make -f Makefile
Project ERROR: mlt++ development package not found
make[1]: *** [Makefile:74: sub-src-make_first] Error 3

Bug#993836: kdenlive FTBFS with mlt 7

[Adrian Bunk]

Source: kdenlive
Version: 21.04.3-3
Severity: serious
Tags: ftbfs
Control: close -1 21.08.0-1

https://buildd.debian.org/status/package.php?p=kdenlive=sid

...
-- Checking for module 'mlt++'
--   No package 'mlt++' found
CMake Error at 
/usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:165 (message):
  Could NOT find MLT (missing: MLT_LIBRARIES MLTPP_LIBRARIES MLT_INCLUDE_DIR
  MLTPP_INCLUDE_DIR) (Required is at least version "6.20.0")
Call Stack (most recent call first):
  /usr/share/cmake-3.18/Modules/FindPackageHandleStandardArgs.cmake:458 
(_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindMLT.cmake:64 (find_package_handle_standard_args)
  CMakeLists.txt:60 (find_package)


-- Configuring incomplete, errors occurred!


This is already fixed in experimental.

Bug#993835: rnp FTBFS: rnp_tests.test_key_add_userid (Failed)

[Adrian Bunk]

Source: rnp
Version: 0.14.0-6
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=rnp=sid

...
test 135
Start 135: rnp_tests.test_key_add_userid

135: Test command: /<>/build/src/tests/rnp_tests 
"--gtest_filter=rnp_tests.test_key_add_userid" "--gtest_also_run_disabled_tests"
135: Environment variables: 
135:  RNP_TEST_DATA=/<>/src/tests/data
135: Test timeout computed to be: 3000
135: Note: Google Test filter = rnp_tests.test_key_add_userid
135: [==] Running 1 test from 1 test suite.
135: [--] Global test environment set-up.
135: [--] 1 test from rnp_tests
135: [ RUN  ] rnp_tests.test_key_add_userid
135: unknown file: Failure
135: C++ exception with description "rnp_exception" thrown in the test body.
135: [  FAILED  ] rnp_tests.test_key_add_userid (31 ms)
...

99% tests passed, 1 tests failed out of 213

Total Test time (real) = 650.07 sec

The following tests FAILED:
135 - rnp_tests.test_key_add_userid (Failed)
Errors while running CTest
make[1]: *** [Makefile:129: test] Error 8

Bug#993834: xgks FTBFS: dh_missing: error: missing files, aborting

[Adrian Bunk]

Source: xgks
Version: 2.6.1+dfsg.2-11
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=xgks=sid

...
   dh_missing -a -O--sourcedirectory=src -O--no-parallel
dh_missing: warning: usr/bin/gksdemo exists in debian/tmp but is not installed 
to anywhere 
dh_missing: warning: usr/bin/hanoi exists in debian/tmp but is not installed to 
anywhere 
dh_missing: warning: usr/bin/star exists in debian/tmp but is not installed to 
anywhere 
dh_missing: warning: usr/lib/libudport.a exists in debian/tmp but is not 
installed to anywhere (related file: "build-gfortran/libudport.a")
dh_missing: warning: usr/lib/libxgks.a exists in debian/tmp but is not 
installed to anywhere (related file: "build-gfortran/lib/c/libxgks.a")
dh_missing: error: missing files, aborting

While detecting missing files, dh_missing noted some files with a 
similar name to those
that were missing.  This error /might/ be resolved by replacing 
references to the
missing files with the similarly named ones that dh_missing found - 
assuming the content
is identical.

As an example, you might want to replace:
 * build-gfortran/libudport.a
with:
 * usr/lib/libudport.a
in a file in debian/ or as argument to one of the dh_* tools called 
from debian/rules.
(Note it is possible the paths are not used verbatim but instead 
directories 
containing or globs matching them are used instead)

Alternatively, add the missing file to debian/not-installed if it 
cannot and should not
be used.

The following debhelper tools have reported what they installed (with 
files per package)
 * dh_install: libxgks-dev (63), libxgks2 (2), libxgks2-data (18)
 * dh_installdocs: libxgks-dev (3), libxgks2 (0), libxgks2-data (0)
 * dh_installexamples: libxgks-dev (3), libxgks2 (0), libxgks2-data (0)
 * dh_installman: libxgks-dev (6), libxgks2 (0), libxgks2-data (0)
If the missing files are installed by another tool, please file a bug 
against it.
When filing the report, if the tool is not part of debhelper itself, 
please reference the
"Logging helpers and dh_missing" section from the "PROGRAMMING" guide 
for debhelper (10.6.3+).
  (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz)
Be sure to test with dpkg-buildpackage -A/-B as the results may vary 
when only a subset is built
If the omission is intentional or no other helper can take care of this 
consider adding the
paths to debian/not-installed.
make: *** [debian/rules:11: binary-arch] Error 25

Bug#993833: libguestfs FTBFS with Go 1.16

[Adrian Bunk]

Source: libguestfs
Version: 1:1.44.1-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=libguestfs=sid

...
Making all in golang
make[4]: Entering directory '/<>/debian/build-1/golang'
[ ../../../golang != . ] && ln -s 
/<>/debian/build-1/../../golang/src ./src
../run go install libguestfs.org/guestfs
run: warning: You used './configure --disable-appliance' so LIBGUESTFS_PATH
run: warning: has not been set automatically.
go install: version is required when current directory is not in a module
Try 'go install libguestfs.org/guestfs@latest' to install the latest 
version
make[4]: *** [Makefile:2615: pkg/linux_amd64/libguestfs.org/guestfs.a] Error 1

Bug#993832: synfig FTBFS with mlt 7

[Adrian Bunk]

Source: synfig
Version: 1.4.0+dfsg-2
Severity: serious
Tags: ftbfs bookworm sid

https://buildd.debian.org/status/package.php?p=synfig=sid

...
checking for mlt++... configure: error:  ** You need to install mlt++.

Bug#993755: libcrypt.so.1: cannot open shared object file when upgrading from Stretch to Sid

[Otto Kekäläinen]

Thanks for a quick reply. I understand why libc6 maintainers prefer
not to touch the dependencies they have unless the issue is severe.

I guess the workaround for this is to manually start the upgrade by
installing perl-base before upgrading the rest of the system.

Bug#971590: rt-tests: bump to a new upstream release

[Punit Agrawal]

Hi Uwe,

I was looking to update the rt-tests package in Debian as it is lagging
behind upstream.

Before digging into the task, I wanted to check if you're planning to
make any changes or had any patches that haven't been pushed. Pointers
to any particular issues to watch out for would also be appreciated.

Things I've noticed so far -

* the upstream branch[0] is not fast-forwardable to latest upstream
  changes and will need a rebase / force-push

* there is a rt-tests repo on salsa[1] which has updates from Anders
  (cc'd) but I don't see the results uploaded anywhere.

If you're not interested in the package anymore (or don't have the
time), I am happy to help out going forward (or takeover as
appropriate).

Let me know your thoughts.

Thanks,
Punit

[0] https://git.pengutronix.de/cgit/ukl/rt-tests/log/?h=upstream
[1] https://salsa.debian.org/debian/rt-tests

Bug#993791: obs-plugins: Please, add move-transition to plugins

[Eriberto Mota]

Em seg., 6 de set. de 2021 às 12:41, Sebastian Ramacher
 escreveu:
>
> Control: tags -1 moreinfo
>
> On 2021-09-06 12:10:20 -0300, Joao Eriberto Mota Filho wrote:
> > Package: obs-plugins
> > Version: 27.0.1+dfsg1-1
> > Severity: wishlist
> >
> > Dear maintainer,
> >
> > Since OBS-27, move-transition[1] is supported. This very useful plugin 
> > needs to
> > be built with OBS (not independent).
>
> Any why can't it be built with libobs-dev? This should contain all
> headers that are required to build an OBS plugin.

Thanks for your quick reply.

I tried to build move-transition yesterday. However, the cmake failed
in several ways. I know autotools very well, but I don't know cmake.
Also, the upstream put in README to build inside of OBS. After some
work and several changes in CMakeLists.txt, now I have already
packaged move-transition using libobs-dev and I am sorry for my
mistake. However, I have two problems and I need help.

1. move-transition needs plugins/obs-transitions/easings.h from OBS.
Could you provide this file to avoid a copy from obs-studio?

2. I think I found a mistake in libobs-dev. All headers are in
/usr/include/obs/, however the /usr/include/obs/obs-frontend-api.h has
two includes pointing to /usr/include/. IMHO, the fix for this is:

--- obs-frontend-api.h.orig 2021-09-06 23:17:30.132174882 -0300
+++ obs-frontend-api.h  2021-09-06 23:17:04.324371729 -0300
@@ -1,7 +1,7 @@
 #pragma once

-#include 
-#include 
+#include 
+#include 

 #ifdef __cplusplus
 extern "C" {

This solution worked for me.

Thanks in advance.

Regards,

Eriberto

Bug#807996: Hélooooooo ?

[Calantha Camara]

Bug#993346: pytest-mock: please upgrade to latest upstream release

[Sandro Tosi]

> I have prepared a 3.6.1-1 release in salsa [1] (it seems the existing
> patches are no longer needed thanks to the work with upstream, and most
> of the changes were adjustments related to the tests).

debian/changelog misses several of your changes, please update and
i'll then sponsor it

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#993597: xdvik-ja: fails to show Japanese characters

[Youhei SASAKI]

Hi,

I don't think it is possible to set this up in Debconf or postinst.
So, how about a note in "NEWS.Debian" and details in "README.Debian"?

Best Regards,
Youhei
--
Youhei SASAKI 
  
GPG fingerprint:
  4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07

Bug#933751: mini-buildd (build-)depends on cruft package.

[Sandro Tosi]

Stephan,

On Fri, 28 Feb 2020 00:57:29 -0500 Scott Kitterman  wrote:
> > I am pressing for a release asap (~months), then everything will be
> > fine again ;).
>
> The months are up to six now.  How's it going?

please do accelerate the release of mini-buildd from experimental to
unstable: the fact you're keeping a severely buggy package in unstable
for so long is bad practice in itself, but it's also causing a lot of
cruft packages to be kept in the archive *just* for mini-buildd (f.e.
the chain python-keyring -> python-setuptool-scm) for a relatively
miniscule popcon installation base.

in the upload for 1.0.49 on Aug 20, you stated:

   See 1.0.46 comments for rational still uploading py2.
   2.0 will come soon (2 weeks).

2 weeks have passed, please upload it with urgency.

Regards,
Sandro

Bug#993831: Please update to version 2.0.5

[Daniel Leidert]

Package: ruby-nokogumbo
Version: 2.0.2-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to the latest release.

Regards, Daniel

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
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

Versions of packages ruby-nokogumbo depends on:
ii  libc6  2.32-1
ii  libruby2.7 2.7.4-1
ii  libxml22.9.12+dfsg-3
ii  ruby   1:2.7+2
ii  ruby-nokogiri  1.11.7+dfsg-2

ruby-nokogumbo recommends no packages.

ruby-nokogumbo suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmE2qBkACgkQS80FZ8KW
0F3M6g/+NHDwX7I6oP+97WEWWaMSl1VMA/4VTLynqydvx5ZRoYqEvWC81ExD2a69
9uAjUnztWaph51PZydC9PHJDUYQZnMDrPm0AKLqn2CAmmPAypYS3f55iHl54ZECU
DwrB6mQ2Ku8H/41teG4xY82CgpY/QnTPs3LkTcjRAZx4KjjowJ0nevB1UrBe2KKs
WOp4eXmHgMpgkdPOIENT4/ePshLlif5pb5v+K1IJLAwyw+Ag4Mg3eZYkb6wPr12S
EZ9j0wBAbVNWjB6E+fLNX7tKiP/cSB3RdCFZNAwQmk7e9oDcRkYbP26UTeNcX7eb
Iuj8WCyfGPQDKuQ/Ns7yX+5VOIz5k1/7wi8QRyXVaxRSavuwyNH8L4Yj09UdgeSx
m2QZDeFVQ9UrpuH3fxhTLrUlMzkGSqKReJ5nHki0T/+gwvit7z+GKogKN07R7L79
AKt5Bg1SrVVz874zahu7Nx5dHBLz+NDqcSWJcXonLnZLnkNglOGDTnQxjdpjZ3Nh
/uRcye9JVAqyBRfDOm1Q0W4ZJU+qcC4sXrdP5BglU8FDdi09fmJSgVXXU/XByRFl
i9v+8kzV7vZcl6SL/hfLjQydf25EeAYHBNu13tDjCcaV5WHLSARG/NVoEwepyqYA
PbTSrXT70ELoH+q22qLh9odHS5nqeg04xIdZzOLPLfust2tDn5Y=
=XKUi
-END PGP SIGNATURE-

Bug#993830: Please update to 1.12

[Daniel Leidert]

Package: ruby-nokogiri
Version: 1.11.7+dfsg-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please update to the latest version.



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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
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

Versions of packages ruby-nokogiri depends on:
ii  libc6   2.32-1
ii  libruby2.7 [ruby-racc]  2.7.4-1
ii  libxml2 2.9.12+dfsg-3
ii  libxslt1.1  1.1.34-4
ii  ruby1:2.7+2
ii  ruby-pkg-config 1.4.6-1

ruby-nokogiri recommends no packages.

ruby-nokogiri suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmE2p+gACgkQS80FZ8KW
0F1f/Q//UgVgWaIJM11Hj/LTnlzq8ZlRFEsSChhGoVTlTMoV3vePEl6wEHi/BE0J
zUVRvQ8I58xQPVo4UIDmuuRQRqTpRhqG/VF4ZhZ449UdagPsT8cH5/Au3DsqKdwV
1+Np51FA01elRmP7+Ll9JNC8Cm4dfTv3JiA5GikWLd0nCgTqqgLyUUHvecC9Py4D
C7H2RuteMUGt0u9vPr3N0/LlSDfVbGUZgQAc2pth/2kghl0OwfeU2C8cZZMXGh9c
mFUhMLhQzDBqTmADvJ3sPwmNZL1x31R41e/ekno5tPMZVyWIqueypj117j2KM6uF
B5Hy0JvomTzkRPv5UOmXHDQXg2HkbIpzSAiYlbFVeX1BK2DcRKb6sSb8BG9B2Gxt
VKQHOjNcfC+NivJGE6ixVg+UwdedNpUsycWSuevETpsvMr+6oI0bBgq5jket+umJ
rt/PW7cwJ1iXVbYYKZHuColrFkL6yh6XegmSZyYxlni1ya6O5wcivAzdZ9EUG0Hi
jd37vrw6gbYfJ+l0FugcUGEX/SJ28CjOFGvi+5KjzSP9IerHs1OpSHBB3D3mNSWC
jGfssip77CxfO7JxYjnrMj/gX0vphpRiZY5rBfIhKiHKgvuXG272q90RMwhlYQXk
0vbeqceQkYgeJFOiy+HYHFG6AIdrgVOuVEUj7DBnlS6QO8rgI14=
=4X2w
-END PGP SIGNATURE-

Bug#993828: Please build with ruby-nokogiri shipping nokogiri.h to enable line-number support etc.

[Daniel Leidert]

Package: ruby-nokogumbo
Version: 2.0.2-2
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

While I was finally updating ruby-html-proofer (with ruby-nokogumbo >= 2.0) I
noticed that its messages didn't contain line numbers anymore. I checked the
build log and it appears that it checks for nokogiri.h:

[..]
checking for nokogiri.h in 
/usr/share/rubygems-integration/2.7.0/gems/nokogiri-1.11.7/ext/nokogiri... 
[..]

and without that present it seems to disable some features. Having it built
with that file present fixes the missing line-numbering issue. So we require
ruby-nokogiri to ship the header and ruby-nokogumbo to build with the header
present.

Regards, Daniel


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
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

Versions of packages ruby-nokogumbo depends on:
ii  libc6  2.32-1
ii  libruby2.7 2.7.4-1
ii  libxml22.9.12+dfsg-3
ii  ruby   1:2.7+2
ii  ruby-nokogiri  1.11.7+dfsg-2

ruby-nokogumbo recommends no packages.

ruby-nokogumbo suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmE2py4ACgkQS80FZ8KW
0F1Iuw//RWd57clkikl0i8gdlUIDqmrbwFVQNfZh1qfrfiAyRjCkXkEHgSPBH6qU
z5dALjY1M4SI2L74pbeTwPA4POy13wJRpd7iPalCWF7ExOFbkjuyWK8MYIRaeu28
fW4WTq6RHJqqGfqRi1GEWqkbN6Y20385/3va+StzHD1buJEHTNEZtfB7p1BMcX+A
BL3z/9h4IUgN9USuRUfn8Kh9PCHObqT+8OyKrgvpjuj301QP0X3o4JjvtCXRs37D
6CnExl8QtZ2V4sJqpt2Zq7UshbwkFbNEGwsT6cY0/3SzsdrfOimy7oJu2SY1wuNT
nMXHMz/nXX25Q0OJN7xDhVmSmUjqvshznTTpdVdLka2ccDyb04opwe6oPCJ8wlhd
tB/fNFDNKtb0HWmBf/7qKaHCaLmBvzWACZ3KRX0ZWYs5gVnofjGMYqebwnQNTdcK
nGhIKoKOEA2cuD9DttHhtsLe0vHdV9oLKuS0gVr67+hqefiZoM7CpxktgdaGbbfW
S/yRbZAKaefvxJUVfxnPq0zQAlkpSjAv4iJTKRDM/pdQ3nFeyjWSkO+XWRLA0zPv
nRi+SFQZ0yUNpp1MF0YFwuGgqV7bkn5qUtzYUADxzM9lUbxfc8l77GrqjJsVWcLM
0cpOv4yPAY8Ex/varosIWyNktArHudrUajCHKbTY+BEf5W3MRNg=
=TCVw
-END PGP SIGNATURE-

Bug#993829: Please ship nokogiri.h header file

[Daniel Leidert]

Package: ruby-nokogiri
Version: 1.11.7+dfsg-2
Severity: wishlist
X-Debbugs-Cc: debian-r...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Nokogumbo 2.0 requires nokogiri.h being present during compilation. If we
change to the gem installation layout this file might already be installed
automatically.

Regards, Daniel



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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
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

Versions of packages ruby-nokogiri depends on:
ii  libc6   2.32-1
ii  libruby2.7 [ruby-racc]  2.7.4-1
ii  libxml2 2.9.12+dfsg-3
ii  libxslt1.1  1.1.34-4
ii  ruby1:2.7+2
ii  ruby-pkg-config 1.4.6-1

ruby-nokogiri recommends no packages.

ruby-nokogiri suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAmE2p64ACgkQS80FZ8KW
0F3MbA/8DWWbMe6KNbQiSrCcxQ7Yqq8PIIHlDPVKoWD0l7omvJqiAJ8ONH30Xh4d
HdtvAATVWc1Z9OjF7MHJcJHGZWavoCCGZgaGIZBMjEWLbGk4CY4ocxhssORw/Y77
lAhb5rfhjSFOQMUdoDfWXvKEoQroXq7pqhqtQDqyHf2i7zj082aIiUaUdS0/c0AX
KWQBPlgRXfJQVUKsofJTHgh9yxxmcILPjdJu1M2j5YHbYuiP25Y7v+OCpJBVbkVP
FsB11GSbaq7CYlUXRNxg++sGRNgdoj5VbToJ7NxXsCuBgyb7p4pV23gGCpyUDz7M
5vkgRF4N4ytyBoUBl+pQzIyh+HMMb/hNiY3Qdp1t5/qZp+5nzModqwCA8j/LiP5B
25jreYDqWquyPmJaEub+yklFF83K3Kc5yoO18rETOghMDJ+5CBe/q13f8sQOrTER
ZWwHTAEhaULkkVx/n6kxZubcuKOoA6TLlaHCEmCqkOJsErN/+ZefqwdwovIaNgJN
htQG6Z+tLdgxemiruTLmnmasE6MV+xOpSH4QP2z6JTs0HiNkwAnz5UQKBMxipbIG
DaeX5tbrL7op40ZTFpelxJNlu/eIQJmiuVDMWPRjpRAc+JzB3ossnfVlhOrx3IlP
JjGu7kmOKs0oCQ1D9B11JkJJR8CueDnKKlYJYTCS5aXkvHD/veE=
=LtK6
-END PGP SIGNATURE-

Bug#844148: reproducible on big but not small machines

[Adam Borowski]

> > VM with 64 cores

> Neither ACL2 nor underlying gcl makes any use of threads or locks

I assume the 64-core box has adequate memory as well.

For me, also on a 64-core box with "only" 128GB RAM, acl2 takes a
three-digit number of gigs for itself, ignoring any other processes
that are also running on the machine.  It keeps doing something nasty,
with garbage collection prominently showing in stack traces.

On a small box, it also hogs most of the memory for itself, being strongly
anti-social, but finishes successfully.

On a tiny box that's still fine for building any other package, it OOMs.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Felix Lechner]

Hi,

On Mon, Sep 6, 2021 at 3:42 PM Jelmer Vernooij  wrote:
>
> something needs to tell the maintainer their package is wrong.

I struggle with telling anyone that "their package is wrong," when a
maintainer, possibly overwhelmed by zealous metadata collection
(hello, DuckDuckGo), added a defensible value. The sources I saw that
listed "https://github.com/join; for Registration pointed to upstreams
offering issue resolution via Github. I believe the site requires
users to be registered. Moreover, the URL appeared to be correct.

> If they're a part of the debian/ packaging, then surely they're in the
> realm of what lintian checks for?

Lintian can do it, but you presented neither a good set of prohibited
or a good set of allowed values. In fact neither side is well-defined,
which makes for poor tags

> Should we create separate linters
> for certain files under debian/ like debian/upstream/metadata ?

I would certainly welcome such a tool.

Kind regards
Felix Lechner

Bug#993806: kodi: No audio on DVD playback, AC3 Support

[Aaron]

I notice -DENABLE_INTERNAL_FFMPEG=OFF \ in rules.
Would switching to -DENABLE_INTERNAL_FFMPEG=ON fix this?

Arch has this flag on and has working audio for DVDs.

Aaron.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

Bug#993811: midish: please package newest version

[Mark Nipper]

Package: midish
Version: 1.0.4-1.1+b4
Severity: normal

I stumbled upon this program recently thanks to it being
available in Debian.  However, it looks like 1.0.4 is absolutely
ancient at this point (2010-11-20 11:09:52 +0100 seems to be the
time stamp for that tag in the upstream Git repo).

It would be lovely if we could get 1.3.1 packaged at this
point.  Quite a lot of new features have been added in the last
decade.

Thanks!

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

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

Versions of packages midish depends on:
ii  libasound21.2.5.1-1
ii  libc6 2.31-17
ii  libreadline8  8.1-2

midish recommends no packages.

midish suggests no packages.

-- no debconf information

-- 
Mark Nipper
ni...@bitgnome.net

Bug#993825: buster-pu: package hdf5/1.10.6+repack-4+deb11u1

[Gilles Filippini]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Release team,

I'd like to upload a fix for hdf5 1.10.6+repack-4 into stable.

[ Reason ]
This is a fix for RC bug #992068 which makes libhdf5-mpich-dev failing
a piuparts upgrade test.

[ Impact ]
No impact but fixing the bug.

[ Tests ]
Piuparts upgrade test of libhdf5-mpich-dev on the upgrade path
  squeeze -> wheezy -> jessie -> stretch -> buster -> bullseye

[ Risks ]
None.

[ 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
  [ ] the issue is verified as fixed in unstable
  Couldn't check that myself because piuparts fails to start from any
  suite before stretch on my box.

[ Changes ]
I followed the recommendation from the bug submitter:
> Making the libmpich-dev versioned (buster shipped with 3.3-3 which uses
> the new alternatives scheme) ensures that libmpich-dev gets upgraded
> (or rather installed, kicking out the ancient libmpich1.0-dev from
> squeeze).

Thanks,

_g.

-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEEoJObzArDE05WtIyR7+hsbH/+z4MFAmE2nEIACgkQ7+hsbH/+
z4Phpwf/XkIdQQfZHt03cw9SPi6xpuavElt2CyHQ3z36yl/tS2XY9YgI3uAUucSh
1lL7pizC4VeSJNDApEGlSQwi4VDvlKuoANGFP3YQjhyogeZoqnfloxqHslYP8gAL
zqSB0nqwSKzu+FEy4QTEddbJUcac7tbWj0szYosiT+ncDxSzH2hystSsV26W1HMu
fqgCTu2hwV3UWoAMruaiRBqrlIIf4Q801dCozFr5Wyz+4CqJNdJN2gmDnezcfF3I
UwUf/h3EMFMqds7X1RFXzkhWKI+DiLRAKh+S7sB2q+gzxWRxTOQOL0BOtk6Lw/7b
H0QMwMmT1sgVVRqSoEokl/pg1OhgyQ==
=2/US
-END PGP SIGNATURE-
diff -Nru hdf5-1.10.6+repack/debian/changelog 
hdf5-1.10.6+repack/debian/changelog
--- hdf5-1.10.6+repack/debian/changelog 2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/changelog 2021-08-15 15:56:44.0 +0200
@@ -1,3 +1,11 @@
+hdf5 (1.10.6+repack-4+deb11u1) bullseye; urgency=medium
+
+  [ Andreas Beckmann ]
+  * libhdf5-mpich-dev: bump libmpich-dev dependency to (>= 3.3-3~) (Closes:
+#992068)
+
+ -- Gilles Filippini   Sun, 15 Aug 2021 15:56:44 +0200
+
 hdf5 (1.10.6+repack-4) unstable; urgency=medium
 
   * Revert support for read-only S3 virtual file driver, as it introduced
diff -Nru hdf5-1.10.6+repack/debian/control hdf5-1.10.6+repack/debian/control
--- hdf5-1.10.6+repack/debian/control   2021-06-16 23:57:23.0 +0200
+++ hdf5-1.10.6+repack/debian/control   2021-08-15 15:56:44.0 +0200
@@ -480,7 +480,7 @@
  zlib1g-dev,
  libaec-dev,
  libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
  ${misc:Depends}
 Suggests: libhdf5-doc
 Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)
diff -Nru hdf5-1.10.6+repack/debian/control.in 
hdf5-1.10.6+repack/debian/control.in
--- hdf5-1.10.6+repack/debian/control.in2021-06-16 23:57:23.0 
+0200
+++ hdf5-1.10.6+repack/debian/control.in2021-08-11 16:32:44.0 
+0200
@@ -480,7 +480,7 @@
  zlib1g-dev,
  libaec-dev,
  libjpeg-dev,
- libmpich-dev,
+ libmpich-dev (>= 3.3-3~),
  ${misc:Depends}
 Suggests: libhdf5-doc
 Breaks: libhdf5-mpi-dev (= 1.10.6+repack-1~exp4)

Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Hudson-Doyle]

On Tue, 7 Sept 2021 at 10:21, Michael Biebl  wrote:

> Am 06.09.21 um 23:45 schrieb Vincent Bernat:
>  > Package: systemd
>  > Version: 247.9-1
>  > Severity: normal
>  >
> > Hey!
> >
> > After upgrading to libc6 2.32-1, some services are unable to restart.
> > In my case, systemd-resolved, systemd-timesyncd and colord. Using
> > "systemctl daemon-reexec" fixes the issue. Unsure if there is really
> > something to be fixed but as I didn't find anything about that, a bug
> > report may help others. I suppose the problem is related to NSS.
> >
> > Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time
> Synchronization...
> > Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service:
> Failed to determine user credentials: No such process
> > Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service:
> Failed at step USER spawning /lib/systemd/systemd-timesyncd: No such process
> >
> >
>
>
> @libc maintainers: any ideas what could be causing this? If this is
> triggered by a libc6 update, should this be reassigned to glibc?
>

We went through this in Ubuntu recently and decided that restarting systemd
in glibc's postinst was the safest option:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1942276

What's happening is that systemd is running with the old glibc, forks and
then does NSS things that cause the new glibc's NSS modules to load and
they don't necessarily work, leading to failures in any unit that specifies
User=. At least for Ubuntu's builds the NSS modules seem to be ABI
compatible between 2.32 and 2.33 (I didn't try 2.31 vs 2.32) but they are
definitely not between 2.33 and 2.34.

Cheers,
mwh

Bug#993083: Confirmation and journal

[Eric Van Buggenhaut]

Rob pointed to the exact source of the bug. I was unable to start
deluged daemon until I patched

/usr/lib/python3/dist-packages/deluge/log.py

On Sat, 04 Sep 2021 19:29:39 +0100 Rob  wrote:

> Hello,
>
> I can confirm this is happening as well, the journal output is slightly
> more informative than the deluged log:
>
> Sep 04 18:32:06 testvm deluged[2132]: Unhandled error in Deferred:
> Sep 04 18:32:06 testvm deluged[2132]: Traceback (most recent call last):
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3/dist-packages/deluge/core/daemon_entry.py", line 112,
> in run_daemon
> Sep 04 18:32:06 testvm deluged[2132]: daemon = Daemon(
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3/dist-packages/deluge/core/daemon.py", line 94, in
> __init__
> Sep 04 18:32:06 testvm deluged[2132]: log.info('Deluge daemon %s',
> get_version())
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1613,
> in unwindGenerator
> Sep 04 18:32:06 testvm deluged[2132]: return
> _cancellableInlineCallbacks(gen)
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1529,
> in _cancellableInlineCallbacks
> Sep 04 18:32:06 testvm deluged[2132]: _inlineCallbacks(None, g,
> status)
> Sep 04 18:32:06 testvm deluged[2132]: ---  ---
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 1418,
> in _inlineCallbacks
> Sep 04 18:32:06 testvm deluged[2132]: result = g.send(result)
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3/dist-packages/deluge/log.py", line 69, in info
> Sep 04 18:32:06 testvm deluged[2132]: yield
> LoggingLoggerClass.info(self, msg, *args, **kwargs)
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3.9/logging/__init__.py", line 1442, in info
> Sep 04 18:32:06 testvm deluged[2132]: self._log(INFO, msg, args,
> **kwargs)
> Sep 04 18:32:06 testvm deluged[2132]: File
> "/usr/lib/python3.9/logging/__init__.py", line 1573, in _log
> Sep 04 18:32:06 testvm deluged[2132]: fn, lno, func, sinfo =
> self.findCaller(stack_info, stacklevel)
> Sep 04 18:32:06 testvm deluged[2132]: builtins.TypeError: findCaller()
> takes from 1 to 2 positional arguments but 3 were given
> Sep 04 18:32:06 testvm deluged[2132]: Temporarily disabling observer
> LegacyLogObserverWrapper( >) due to
> exception: [Failure instance: Traceback: :
> findCaller() t
> akes from 1 to 2 positional arguments but 3 were given
> Sep 04 18:32:06 testvm deluged[2132]:
>
/usr/lib/python3/dist-packages/pkg_resources/_vendor/pyparsing.py:646:__getattr__
> Sep 04 18:32:06 testvm deluged[2132]:
> /usr/lib/python3/dist-packages/twisted/internet/defer.py:962:__del__
> Sep 04 18:32:06 testvm deluged[2132]:
> /usr/lib/python3/dist-packages/twisted/logger/_logger.py:190:failure
> Sep 04 18:32:06 testvm deluged[2132]:
> /usr/lib/python3/dist-packages/twisted/logger/_logger.py:144:emit
> Sep 04 18:32:06 testvm deluged[2132]: ---  ---

Bug#993824: transition: libqalculate

[Phil Morrell]

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

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

Please can we go ahead with the auto-libqalculate transition now? The
new version is in experimental and has built on all release arches,
including ports that gnuplot-nox is available for.

https://buildd.debian.org/status/package.php?p=libqalculate=experimental

It has 4 reverse dependencies which have all been test built with the
new version and we have significant team overlap with them for future
uploads.
--
emorrp1


signature.asc
Description: PGP signature

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Jelmer Vernooij]

On Mon, Sep 06, 2021 at 03:10:05PM -0700, Felix Lechner wrote:
> On Mon, Sep 6, 2021 at 2:26 PM Jelmer Vernooij  wrote:
> > It won't provide maintainers of packages that use
> > invalid settings that they are. Isn't that purpose of lintian?
> I am not sure. Is it perhaps a gray zone the Janitor could fill?
I don't see how the janitor is related here. It's not a linting tool
and it can't report issues to maintainers. lintian-brush can fix a
subset of issues reported by lintian (where it can edit the canonical
source that matches the output scanned by lintian), but in the cases
where it can't we need the maintainer to fix the issue - and something
needs to tell the maintainer their package is wrong.

> There are a few open questions: Why for example does the Github signup
> page occur so often in the archive? [1] Do we actually need the field?
> [2] I am not even sure the reference is incorrect. What if an upstream
> manages bug reports via Github's issue tracker, like gocryptfs? [3]
> (Please don't worry—I did not set the Registration field there. [4])
> 
> To be sure, I am not opposed to your suggestion in principle, but
> people do a lot of weird stuff. Is the obscure (and often ignored)
> upstream metadata really worth our attention?

Whether these fields are useful enough to be included in
debian/upstream/metadata is a great question, and I'm very happy to
receive pushback in that regard. That should probably be a part of the
wider discussion around the finaliation of DEP-12.

> > Or, looking at a counter-example - there is e.g. a pypi-homepage
> > tag; not just a homepage classification.
> 
> I think there is a difference. A project's home page is often the
> first point of contact, especially in search of documentation. When do
> people look at the Registration field in the upstream metadata,
> please?

I think we should either kill these fields if they're not useful,
/or/ make sure that they have correct values in them. Leaving them with
often incorrect data makes them even less useful and just adds extra noise and 
work.

If they're a part of the debian/ packaging, then surely they're in the
realm of what lintian checks for? Should we create separate linters
for certain files under debian/ like debian/upstream/metadata ?

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#993699: SoapySDR transition is in progress

[Andreas Bombe]

severity 993699 serious
thanks


The SoapySDR transition is starting, so I am raising the severity of
this bug to serious.

Bug#993701: SoapySDR transition is in progress

[Andreas Bombe]

severity 993701 serious
thanks


The SoapySDR transition is starting, so I am raising the severity of
this bug to serious.

Bug#993698: SoapySDR transition is in progress

[Andreas Bombe]

severity 993698 serious
thanks


The SoapySDR transition is starting, so I am raising the severity of
this bug to serious.

Bug#993823: buster-pu: package clamav/0.103.3+dfsg-0+deb10u1

[Sebastian Andrzej Siewior]

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

This is an update of clamav to version 0.103.3 which is considered as a
LTS version. It contains only important fixes. The details were
documented by upstream at

https://blog.clamav.net/2021/09/changes-to-clamav-end-of-life-policy.html

I had this updated version running on one of my machines. The 103.3
version is in unstable since July.
It addresses a clamdscan related regression which was introduced in
103.2.

Side note: As per
   https://docs.clamav.net/faq/faq-eol.html#definitions

upstream defines "support" as also including "Signature Database (CVD)
Access". Therefore it would be nice to include this into
buster/updates once time permits.

Sebastian
diff -Nru clamav-0.103.2+dfsg/clamd/scanner.c 
clamav-0.103.3+dfsg/clamd/scanner.c
--- clamav-0.103.2+dfsg/clamd/scanner.c 2021-04-06 21:03:42.0 +0200
+++ clamav-0.103.3+dfsg/clamd/scanner.c 2021-06-19 23:15:59.0 +0200
@@ -146,8 +146,8 @@
 
 if (NULL != filename) {
 if (CL_SUCCESS != cli_realpath((const char *)filename, 
_filename)) {
-conn_reply_errno(scandata->conn, msg, "Failed to determine real 
path:");
-logg("^Failed to determine real path for: %s\n", filename);
+conn_reply_errno(scandata->conn, msg, "File path check failure:");
+logg("^File path check failure for: %s\n", filename);
 logg("*Quarantine of the file may fail if file path contains 
symlinks.\n");
 } else {
 free(filename);
@@ -180,25 +180,30 @@
 else
 logg("!Memory allocation failed during cli_ftw()\n");
 scandata->errors++;
+free(filename);
 return CL_EMEM;
 case error_stat:
-conn_reply_errno(scandata->conn, msg, "lstat() failed:");
-logg("^lstat() failed on: %s\n", msg);
+conn_reply_errno(scandata->conn, msg, "File path check failure:");
+logg("^File path check failure on: %s\n", msg);
 scandata->errors++;
+free(filename);
 return CL_SUCCESS;
 case warning_skipped_dir:
-logg("^Directory recursion limit reached, skipping %s\n",
- msg);
+logg("^Directory recursion limit reached, skipping %s\n", msg);
+free(filename);
 return CL_SUCCESS;
 case warning_skipped_link:
 logg("$Skipping symlink: %s\n", msg);
+free(filename);
 return CL_SUCCESS;
 case warning_skipped_special:
 if (msg == scandata->toplevel_path)
 conn_reply(scandata->conn, msg, "Not supported file type", 
"ERROR");
 logg("*Not supported file type: %s\n", msg);
+free(filename);
 return CL_SUCCESS;
 case visit_directory_toplev:
+free(filename);
 return CL_SUCCESS;
 case visit_file:
 break;
diff -Nru clamav-0.103.2+dfsg/clamdscan/proto.c 
clamav-0.103.3+dfsg/clamdscan/proto.c
--- clamav-0.103.2+dfsg/clamdscan/proto.c   2021-04-06 21:03:42.0 
+0200
+++ clamav-0.103.3+dfsg/clamdscan/proto.c   2021-06-19 23:15:59.0 
+0200
@@ -238,6 +238,10 @@
 {
 const struct optstruct *opt;
 
+if (!path) {
+return 1;
+}
+
 if ((opt = optget(clamdopts, "ExcludePath"))->enabled) {
 while (opt) {
 if (match_regex(path, opt->strarg) == 1) {
diff -Nru clamav-0.103.2+dfsg/clamsubmit/clamsubmit.c 
clamav-0.103.3+dfsg/clamsubmit/clamsubmit.c
--- clamav-0.103.2+dfsg/clamsubmit/clamsubmit.c 2021-04-06 21:03:42.0 
+0200
+++ clamav-0.103.3+dfsg/clamsubmit/clamsubmit.c 2021-06-19 23:15:59.0 
+0200
@@ -1,3 +1,30 @@
+/*
+ *  ClamAV Malware and False Positive Reporting Tool
+ *
+ *  Copyright (C) 2014-2020 Cisco Systems, Inc. and/or its affiliates. All 
rights reserved.
+ *
+ *  Authors: Shawn Webb, Steve Morgan
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ *  MA 02110-1301, USA.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "clamav-config.h"
+#endif
+
+#include 
 #include 
 #include 
 #if HAVE_UNISTD_H
@@ -23,6 +50,7 @@
 #include "misc.h"
 #include "getopt.h"
 #include "cert_util.h"
+#include "output.h"
 
 #define OPTS "e:p:n:N:V:H:h?v?d"
 
@@ -32,7 +60,6 @@
 
 

Bug#993822: bullseye-pu: package clamav/0.103.3+dfsg-0+deb11u1

[Sebastian Andrzej Siewior]

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

This is an update of clamav to version 0.103.3 which is considered as a
LTS version. It contains only important fixes. The details were
documented by upstream at

https://blog.clamav.net/2021/09/changes-to-clamav-end-of-life-policy.html

The 103.3 version is in unstable since July.
It addresses a clamdscan related regression which was introduced in
103.2.

Side note: As per
   https://docs.clamav.net/faq/faq-eol.html#definitions

upstream defines "support" as also including "Signature Database (CVD)
Access". Therefore it would be nice to include this into
bullseye/updates once time permits.

Sebastian
diff -Nru clamav-0.103.2+dfsg/clamd/scanner.c 
clamav-0.103.3+dfsg/clamd/scanner.c
--- clamav-0.103.2+dfsg/clamd/scanner.c 2021-04-06 21:03:42.0 +0200
+++ clamav-0.103.3+dfsg/clamd/scanner.c 2021-06-19 23:15:59.0 +0200
@@ -146,8 +146,8 @@
 
 if (NULL != filename) {
 if (CL_SUCCESS != cli_realpath((const char *)filename, 
_filename)) {
-conn_reply_errno(scandata->conn, msg, "Failed to determine real 
path:");
-logg("^Failed to determine real path for: %s\n", filename);
+conn_reply_errno(scandata->conn, msg, "File path check failure:");
+logg("^File path check failure for: %s\n", filename);
 logg("*Quarantine of the file may fail if file path contains 
symlinks.\n");
 } else {
 free(filename);
@@ -180,25 +180,30 @@
 else
 logg("!Memory allocation failed during cli_ftw()\n");
 scandata->errors++;
+free(filename);
 return CL_EMEM;
 case error_stat:
-conn_reply_errno(scandata->conn, msg, "lstat() failed:");
-logg("^lstat() failed on: %s\n", msg);
+conn_reply_errno(scandata->conn, msg, "File path check failure:");
+logg("^File path check failure on: %s\n", msg);
 scandata->errors++;
+free(filename);
 return CL_SUCCESS;
 case warning_skipped_dir:
-logg("^Directory recursion limit reached, skipping %s\n",
- msg);
+logg("^Directory recursion limit reached, skipping %s\n", msg);
+free(filename);
 return CL_SUCCESS;
 case warning_skipped_link:
 logg("$Skipping symlink: %s\n", msg);
+free(filename);
 return CL_SUCCESS;
 case warning_skipped_special:
 if (msg == scandata->toplevel_path)
 conn_reply(scandata->conn, msg, "Not supported file type", 
"ERROR");
 logg("*Not supported file type: %s\n", msg);
+free(filename);
 return CL_SUCCESS;
 case visit_directory_toplev:
+free(filename);
 return CL_SUCCESS;
 case visit_file:
 break;
diff -Nru clamav-0.103.2+dfsg/clamdscan/proto.c 
clamav-0.103.3+dfsg/clamdscan/proto.c
--- clamav-0.103.2+dfsg/clamdscan/proto.c   2021-04-06 21:03:42.0 
+0200
+++ clamav-0.103.3+dfsg/clamdscan/proto.c   2021-06-19 23:15:59.0 
+0200
@@ -238,6 +238,10 @@
 {
 const struct optstruct *opt;
 
+if (!path) {
+return 1;
+}
+
 if ((opt = optget(clamdopts, "ExcludePath"))->enabled) {
 while (opt) {
 if (match_regex(path, opt->strarg) == 1) {
diff -Nru clamav-0.103.2+dfsg/clamsubmit/clamsubmit.c 
clamav-0.103.3+dfsg/clamsubmit/clamsubmit.c
--- clamav-0.103.2+dfsg/clamsubmit/clamsubmit.c 2021-04-06 21:03:42.0 
+0200
+++ clamav-0.103.3+dfsg/clamsubmit/clamsubmit.c 2021-06-19 23:15:59.0 
+0200
@@ -1,3 +1,30 @@
+/*
+ *  ClamAV Malware and False Positive Reporting Tool
+ *
+ *  Copyright (C) 2014-2020 Cisco Systems, Inc. and/or its affiliates. All 
rights reserved.
+ *
+ *  Authors: Shawn Webb, Steve Morgan
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ *  MA 02110-1301, USA.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "clamav-config.h"
+#endif
+
+#include 
 #include 
 #include 
 #if HAVE_UNISTD_H
@@ -23,6 +50,7 @@
 #include "misc.h"
 #include "getopt.h"
 #include "cert_util.h"
+#include "output.h"
 
 #define OPTS "e:p:n:N:V:H:h?v?d"
 
@@ -32,7 +60,6 @@
 
 typedef struct _header_data {
 int len;
-char 

Bug#993806: kodi: No audio on DVD playback, AC3 Support

[Aaron]

Package: kodi
Version: 2:19.1+dfsg2-2
Severity: important
X-Debbugs-Cc: ukbeas...@protonmail.com

Dear Maintainer,


   1. Installed libdvd-pkg and ran sudo dpkg-reconfigure libdvd-pkg.
   2. Mounted DVD in KDE and open DVD in kodi.
   3. Noticed no audio is playing.
   4. Press "o" during playback and see that Audio stream is unknown. (AC3 
decoded)


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

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

Versions of packages kodi depends on:
ii  kodi-bin   2:19.1+dfsg2-2
ii  kodi-data  2:19.1+dfsg2-2

Versions of packages kodi recommends:
ii  kodi-repository-kodi [kodi-repository]  2:19.1+dfsg2-2
ii  kodi-visualization-spectrum 19.0.0+ds1-1

kodi suggests no packages.

-- no debconf information

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Felix Lechner]

Hi,

On Mon, Sep 6, 2021 at 2:26 PM Jelmer Vernooij  wrote:
>
> It won't provide maintainers of packages that use
> invalid settings that they are. Isn't that purpose of lintian?

I am not sure. Is it perhaps a gray zone the Janitor could fill?

There are a few open questions: Why for example does the Github signup
page occur so often in the archive? [1] Do we actually need the field?
[2] I am not even sure the reference is incorrect. What if an upstream
manages bug reports via Github's issue tracker, like gocryptfs? [3]
(Please don't worry—I did not set the Registration field there. [4])

To be sure, I am not opposed to your suggestion in principle, but
people do a lot of weird stuff. Is the obscure (and often ignored)
upstream metadata really worth our attention?

> Or, looking at a counter-example - there is e.g. a pypi-homepage
> tag; not just a homepage classification.

I think there is a difference. A project's home page is often the
first point of contact, especially in search of documentation. When do
people look at the Registration field in the upstream metadata,
please?

Kind regards
Felix Lechner

[1] 
https://codesearch.debian.net/search?q=https%3A%2F%2Fgithub.com%2Fjoin=1=1
[2] https://wiki.debian.org/UpstreamMetadata
[3] https://github.com/rfjakob/gocryptfs
[4] https://sources.debian.org/src/gocryptfs/1.8.0-1/debian/upstream/metadata/

Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Michael Biebl]

Am 06.09.21 um 23:45 schrieb Vincent Bernat:
> Package: systemd
> Version: 247.9-1
> Severity: normal
>

Hey!

After upgrading to libc6 2.32-1, some services are unable to restart.
In my case, systemd-resolved, systemd-timesyncd and colord. Using
"systemctl daemon-reexec" fixes the issue. Unsure if there is really
something to be fixed but as I didn't find anything about that, a bug
report may help others. I suppose the problem is related to NSS.

Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time Synchronization...
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed to 
determine user credentials: No such process
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed at 
step USER spawning /lib/systemd/systemd-timesyncd: No such process





@libc maintainers: any ideas what could be causing this? If this is 
triggered by a libc6 update, should this be reassigned to glibc?




OpenPGP_signature
Description: OpenPGP digital signature

Bug#993821: After upgrading libc, some services are unable to restart (including systemd-resolved)

[Vincent Bernat]

Package: systemd
Version: 247.9-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hey!

After upgrading to libc6 2.32-1, some services are unable to restart.
In my case, systemd-resolved, systemd-timesyncd and colord. Using
"systemctl daemon-reexec" fixes the issue. Unsure if there is really
something to be fixed but as I didn't find anything about that, a bug
report may help others. I suppose the problem is related to NSS.

Sep 06 23:06:43 chocobo systemd[1]: Starting Network Time Synchronization...
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed to 
determine user credentials: No such process
Sep 06 23:06:43 chocobo systemd[236983]: systemd-timesyncd.service: Failed at 
step USER spawning /lib/systemd/systemd-timesyncd: No such process



- -- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.3.1-1
ii  libapparmor1 3.0.3-2
ii  libaudit11:3.0.5-1
ii  libblkid12.37.2-2
ii  libc62.32-1
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.25-2
ii  libcryptsetup12  2:2.4.0-1
ii  libgcrypt20  1.9.4-2
ii  libgnutls30  3.7.2-2
ii  libgpg-error01.42-3
ii  libip4tc21.8.7-1
ii  libkmod2 29-1
ii  liblz4-1 1.9.3-2
ii  liblzma5 5.2.5-2
ii  libmount12.37.2-2
ii  libpam0g 1.4.0-10
ii  libseccomp2  2.5.1-1
ii  libselinux1  3.1-3
ii  libsystemd0  247.9-1
ii  libzstd1 1.4.8+dfsg-2.1
ii  mount2.37.2-2
ii  systemd-timesyncd [time-daemon]  247.9-1
ii  util-linux   2.37.2-2

Versions of packages systemd recommends:
ii  dbus  1.12.20-2

Versions of packages systemd suggests:
ii  policykit-10.105-31
ii  systemd-container  247.9-1

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.9-1
ii  libpam-systemd   247.9-1
ii  udev 247.9-1

- -- Configuration Files:
/etc/systemd/logind.conf changed:
[Login]
HandlePowerKey=ignore

/etc/systemd/resolved.conf changed:
[Resolve]
DNSSEC=allow-downgrade


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJGBAEBCAAwFiEErvI0h2bzccaJpzYAlaQv6DU1JfkFAmE2jA8SHGJlcm5hdEBk
ZWJpYW4ub3JnAAoJEJWkL+g1NSX5HXcQAKG5+toLrAqmXBjrFCHUauoUJ1MKEXYp
gMk11uNJd61yY0gW7eQHNJ1bl1aeXQ5FBOw830xMVFn9qXcCAghrDcB8yT8Vlsw9
XQQakme/+qUNU6xg4RW9IRbrqH32AhV1hp4rkrchjVYpoLng26JOV7zKSs7PrhL/
THtVzuxRnqgyQ0j742yDmw5X6y/jqBIyOgdVWm176kYIaIvkob8i8YzF8eSjQCgq
0PEDVwtbkDUu8M79lA2QPTya+3y9xD/vp01/hbyMA7+lOfQKC5ylX5rklsMhsWez
mLwRBj3UYGGYm6jRWwYRbciSCpYLxsz0RVz6+T8FStyGqh3vNBAWFQHYn47QtypU
2t4JGgJV+Z6yDeY2eh/ltk2kk+yhsMJtDzEoY7unsG4fWa8MoxgdKeIwbQ3Hujir
uyQMD170q5/AkPWsmKeJm2OdBF9nRs8dGU+VGi80XZzld0Ociu0tcUQu9F9LbrNj
5HdvUlkY6rkW0OsTpDBjKqVyB/DMHT9ciS5o9a/C6ZwRMspyItxKrxtN+9M2VIN3
5BHv/2vuZfh5OqDCtlVVwEhj2YZUVlEmtIJ+UfA7VfupXHwNiCvI8QOWkKcOvkMJ
1FurFmmJ3WED/2qLfr25GhZgyUGDb/3NluuHHnwRIkpCBYyV4qOSnAd/z4SUa+wv
p2k968FNOmUz
=jj8P
-END PGP SIGNATURE-

Bug#993820: gnome-music: Gnome Music doesn't start.

[Sebastián Lacuesta]

Package: gnome-music
Version: 40.1.1-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: sebastianlacue...@gmail.com

Package just doesn't start. Here's a console dump:

$ gnome-music

(org.gnome.Music:423406): Grilo-WARNING **: 18:36:18.430: [registry]
../src/grl-registry.c:1519: Plugin 'grl-tracker3' not available
Traceback (most recent call last):
  File "/usr/bin/gnome-music", line 132, in 
sys.exit(main())
  File "/usr/bin/gnome-music", line 127, in main
return run_application()
  File "/usr/bin/gnome-music", line 115, in run_application
app = Application('org.gnome.Music')
  File "/usr/lib/python3/dist-packages/gnomemusic/application.py", line 75, in
__init__
self._coregrilo = CoreGrilo(self)
  File "/usr/lib/python3/dist-packages/gnomemusic/coregrilo.py", line 96, in
__init__
self._on_tracker_available_changed(None, None)
  File "/usr/lib/python3/dist-packages/gnomemusic/coregrilo.py", line 123, in
_on_tracker_available_changed
self._registry.activate_plugin_by_id("grl-tracker3")
gi.repository.GLib.Error: grilo.error.general: Plugin “grl-tracker3” not
available (14)



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

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

Versions of packages gnome-music depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-1
ii  gir1.2-dazzle-1.03.40.0-2
ii  gir1.2-glib-2.0  1.68.0-2
ii  gir1.2-goa-1.0   3.40.0-2
ii  gir1.2-grilo-0.3 0.3.13-1.1
ii  gir1.2-gst-plugins-base-1.0  1.18.4-dmo1
ii  gir1.2-gstreamer-1.0 1.18.4-2.1
ii  gir1.2-gtk-3.0   3.24.30-3
ii  gir1.2-mediaart-2.0  1.9.5-1
ii  gir1.2-pango-1.0 1.48.9+ds1-2
ii  gir1.2-soup-2.4  2.74.0-2
ii  gir1.2-totemplparser-1.0 3.26.5-5
ii  gir1.2-tracker-3.0   3.1.1-3
ii  gnome-settings-daemon40.0.1-1
ii  grilo-plugins-0.30.3.13-2+b1
ii  libc62.31-17
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.68.4-1
ii  libgtk-3-0   3.24.30-3
ii  libpango-1.0-0   1.48.9+ds1-2
ii  libpangocairo-1.0-0  1.48.9+ds1-2
ii  python3  3.9.2-3
ii  python3-gi   3.40.1-2
ii  python3-gi-cairo 3.40.1-2
ii  python3-requests 2.25.1+dfsg-2
ii  tracker  3.1.1-3

gnome-music recommends no packages.

Versions of packages gnome-music suggests:
ii  gnome-online-accounts  3.40.0-2

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Jelmer Vernooij]

On Mon, Sep 06, 2021 at 01:44:31PM -0700, Felix Lechner wrote:
> On Mon, Sep 6, 2021 at 12:56 PM Jelmer Vernooij  wrote:
> > it would simply be a list of
> > known bad values
> 
> I am not sure I agree with the hardcoding of those values unless they
> create legal issues like license violations or the risk of criminal
> prosecution. How about we repurpose the classification tag
> 'upstream-metadata-field-present' to also provide the field contents,
> which is what you are after?
> 
> You could then use Lintian's query interface to examine the values to
> your liking.

That will mean maintainers need to decide which values are valid and
which ones aren't. It won't provide maintainers of packages that use
invalid settings that they are. Isn't that purpose of lintian?

Or, looking at a counter-example - there is e.g. a pypi-homepage
tag; not just a homepage classification.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#273323: doc-debian: please ship typesettable version of social contract and dfsg documents

[Diederik de Haas]

Package: doc-debian
Version: 6.5
Followup-For: Bug #273323
X-Debbugs-Cc: debian-proj...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I wanted to print the Debian Social Contract, which turned out to be WAY
more difficult then I expected and then it should be.

So I went to https://www.debian.org/social_contract and wanted to print
that. Apparently there isn't a print stylesheet for it, so if you print
that, you also get 'Blog', 'Micronews', 'Planet' and a search box.
Of course I didn't mind the Debian logo.
The last page (of the print preview) shows that it's available in a whole
bunch of languages, which is good, but undesirable for a print version. 
And then you get a bunch of links, also undesirable for a print version.

Then I went looking for a PDF version and didn't find anything.

I did find a 'social-contract.txt.gz' (why compressed?), but that's
missing any form of nice formatting (that the webpage does have).
I did try 'zcat ' and editing that in
LibreOffice Writer, but apparently I've lost my skills in office
programs, so I bailed on that.

I ended up using a Firefox addon (Print Edit WE) to strip all the things
I didn't need. That still didn't give me an option to have
- - 1 page with the Social Contract and
- - 1 page with the Debian Free Software Guidelines

(I also lost the Debian logo, but that may be a PEBKAC issue)
It doesn't have to be a 2 page document, but that seems kind of nice.

It really shouldn't be this hard to print the most essential document of
the Debian Project.
It was surprising (and a bit disappointing) that there isn't a nicely
formatted printable document/PDF available.

So hereby my +1 to getting this bug fixed.

Cheers,
  Diederik


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

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

doc-debian depends on no packages.

Versions of packages doc-debian recommends:
ii  debian-faq  10.1

Versions of packages doc-debian suggests:
ii  firefox [www-browser]   88.0.1-1
ii  firefox-esr [www-browser]   78.13.0esr-1
ii  ghostscript [postscript-viewer] 9.53.3~dfsg-7+b1
ii  konqueror [www-browser] 4:21.08.0-1
ii  okular [postscript-viewer]  4:21.08.0-1
ii  qpdfview-ps-plugin [postscript-viewer]  0.4.18-5
ii  qutebrowser [www-browser]   2.3.1-1
ii  w3m [www-browser]   0.5.3+git20210102-6

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT1sUPBYsyGmi4usy/XblvOeH7bbgUCYTaBAwAKCRDXblvOeH7b
bt67AP9BUY8KDSj0YMWMbwkBQS8SVcvR19de+lz6FPQX/HHnVgD8Dhffl9+ikEZn
ob3WraENDf4xMZTMSqGJf0kB8X+8YQU=
=v0jd
-END PGP SIGNATURE-

Bug#993819: release-notes: Please document the removal of wicd

[Roger Lynn]

Package: release-notes
Severity: important

Hi,

Please document the removal of wicd in Bullseye. This seems particularly
dangerous if the upgrade is being done over a network connection being managed
by wicd as it seems likely that the connection will be lost when wicd is
removed (due to dependency problems). It would also be helpful if alternatives
could be suggested.

Thanks,

Roger

Bug#993818: ruby-nokogiri: WARNING: Nokogiri was built against libxml version 2.9.12, but has dynamically loaded 2.9.10

[Pirate Praveen]

Package: ruby-nokogiri
Version: 1.11.7+dfsg-2
Severity: serious
Justification: migration to testing blocked

autopkgtest for cewl is failing in testing

https://ci.debian.net/data/autopkgtest/testing/amd64/c/cewl/15073435/log.gz

terceiro on irc:
this type of warning is a PITA; I usually patch them out
(after checking that the package does work with whatever version we 
have in debian :))
just checked, the dependency is automatically generated; probably 
patching to remove the check and warning is the way to go

Bug#993817: ruby-licensee: autopkgtest regression on 9386

[Pirate Praveen]

Package: ruby-licensee
Version: 9.14.1-3
Severity: serious
Control: forwarded -1 https://github.com/licensee/licensee/issues/503

Autopkgtest regression on i386 is blocking the migration to testing

https://ci.debian.net/data/autopkgtest/testing/i386/r/ruby-licensee/15051694/log.gz

Reported upstream https://github.com/licensee/licensee/issues/503

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Felix Lechner]

Control: retitle -1 lintian: export upstream metadata in classification tag

Hi,

On Mon, Sep 6, 2021 at 12:56 PM Jelmer Vernooij  wrote:
>
> it would simply be a list of
> known bad values

I am not sure I agree with the hardcoding of those values unless they
create legal issues like license violations or the risk of criminal
prosecution. How about we repurpose the classification tag
'upstream-metadata-field-present' to also provide the field contents,
which is what you are after?

You could then use Lintian's query interface to examine the values to
your liking.

Kind regards
Felix Lechner

Bug#993816: xfce4: Changed from german to english after Debian update to bullseye

[Wolf-Dieter Groll]

Package: xfce4
Version: 4.16
Severity: important
X-Debbugs-Cc: wolf-dieter.gr...@gmx.de

Dear Maintainer,

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

After the update from Debian 10 to 11, the keyboard and the menus of XFCE
changed from german to english, despite the correct language setting
(LANG=de_DE.UTF-8).
I was able to correct the keyboard settings with ibus-setup, but I found no way
to set the language for the menus.

   * What led up to the situation?

Update from buster to bullseye

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

ibus-setup could repair the wrong setting of the keyboard for this user.
dpkg-reconfigure locales did not change the language of the menus

   * What was the outcome of this action?
Keyboard usable, but menus are still in english

   * What outcome did you expect instead?

To regain my XFCE Desktop I had with Debian Buster

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


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 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 xfce4 depends on:
ii  libxfce4ui-utils 4.16.0-1
ii  thunar   4.16.8-1
ii  xfce4-appfinder  4.16.1-1
ii  xfce4-panel  4.16.2-1
ii  xfce4-pulseaudio-plugin  0.4.3-1
ii  xfce4-session4.16.0-1
ii  xfce4-settings   4.16.0-1
ii  xfconf   4.16.0-2
ii  xfdesktop4   4.16.0-1
ii  xfwm44.16.1-1

Versions of packages xfce4 recommends:
ii  desktop-base  11.0.3
ii  tango-icon-theme  0.8.90-8
ii  thunar-volman 4.16.0-1
ii  xfce4-notifyd 0.6.2-1
ii  xorg  1:7.7+22

Versions of packages xfce4 suggests:
ii  xfce4-goodies4.14.0
ii  xfce4-power-manager  4.16.0-1

Bug#927786: Patch for #927786

[Ben Morris]

The upstream source checks for the ability to build against libfuse by 
searching hard-coded locations for fuse.h. In the interest of multiarch 
support, the Debian package instead uses the compiler to locate the header.

However, this compiler-based check was failing, not because fuse is not 
available, but because of a missing cflag. I have modified the check to use 
the cflags that pkg-config provides for fuse.

My modified multiarch-libc.patch is attached.

Note:
It seems to me that the check could simply be removed, since the 
Debian package should probably fail to build if its dependencies are somehow 
not detected, rather than silently building with reduced functionality. 
However, this is my first attempt to submit a patch to the Debian BTS, so I've 
instead gone with what seemed like the least drastic change.


Ben MorrisIndex: wit-3.01a/setup.sh
===
--- wit-3.01a.orig/setup.sh
+++ wit-3.01a/setup.sh
@@ -18,13 +18,14 @@ revision_next=$revision_num
 
 tim=($(date --utc --date="@${SOURCE_DATE_EPOCH:-$(date +%s)}" '+%s %Y-%m-%d %T'))
 defines=
+: "${CC:=cc}"
 
 have_fuse=0
-[[ $NO_FUSE != 1 && -r /usr/include/fuse.h || -r /usr/local/include/fuse.h ]] \
+[[ $NO_FUSE != 1 ]] && echo '#include ' | "$CC" $(pkg-config --cflags fuse) -E - >/dev/null 2>&1 \
 	&& have_fuse=1
 
 have_zlib=0
-if [[ $NO_ZLIB != 1 && -r /usr/include/zlib.h || -r /usr/local/include/zlib.h ]]
+if [[ $NO_ZLIB != 1 ]] && echo '#include ' | "$CC" -E - >/dev/null 2>&1
 then
 have_zlib=1
 defines="$defines -DHAVE_ZLIB=1"
@@ -41,16 +42,16 @@ else
 xflags=
 fi
 
-[[ -r /usr/include/bits/fcntl.h ]] \
-	&& grep -qw fallocate /usr/include/bits/fcntl.h \
+echo '#include ' | "$CC" -E - >/dev/null 2>&1 \
+	&& echo '#include ' | "$CC" -E - 2>/dev/null | grep -qw fallocate \
 	&& defines="$defines -DHAVE_FALLOCATE=1"
 
-[[ -r /usr/include/fcntl.h ]] \
-	&& grep -qw posix_fallocate /usr/include/fcntl.h \
+echo '#include ' | "$CC" -E - >/dev/null 2>&1 \
+	&& echo '#include ' | "$CC" -E - 2>/dev/null | grep -qw posix_fallocate \
 	&& defines="$defines -DHAVE_POSIX_FALLOCATE=1"
 
-[[ -r /usr/include/linux/fiemap.h ]] \
-	&& grep -qw fiemap_extent /usr/include/linux/fiemap.h \
+echo '#include ' | "$CC" -E - >/dev/null 2>&1 \
+	&& echo '#include ' | "$CC" -E - 2>/dev/null | grep -qw fiemap_extent \
 	&& defines="$defines -DHAVE_FIEMAP=1"
 
 [[ $STATIC = 1 ]] || STATIC=0

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Jelmer Vernooij]

On Mon, Sep 06, 2021 at 12:51:43PM -0700, Felix Lechner wrote:
> On Mon, Sep 6, 2021 at 12:24 PM Jelmer Vernooij  wrote:
> >
> > Registration: https://github.com/join
> 
> As a tool without network access, Lintian may not be well-suited to
> synchronize upstream metadata.

This wouldn't require network access - it would simply be a list of
known bad values, in the same way that we have those in other places
(e.g. known bad hosting sites for Homepage).

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Felix Lechner]

Hi,

On Mon, Sep 6, 2021 at 12:24 PM Jelmer Vernooij  wrote:
>
> Registration: https://github.com/join

As a tool without network access, Lintian may not be well-suited to
synchronize upstream metadata.

Kind regards
Felix Lechner

Bug#788411: Please update the patch

[Anton Gladky]

Hi Helmut,

thanks a lot for updated patch!

Please cancel NMU upload, because I am preparing the next gmp version,
where some
more bug sare fixed.

Also this debdiff introduces lintian-error [1] which should be fixed.

[1] https://salsa.debian.org/science-team/gmp/-/jobs/1917314
Thanks again

Anton


Am Mo., 6. Sept. 2021 um 08:11 Uhr schrieb Helmut Grohne :

> Control: tags -1 -moreinfo +pending
>
> Hi Anton,
>
> On Mon, Aug 30, 2021 at 10:44:34PM +0200, Anton Gladky wrote:
> > It looks like the symbol-file cannot be applied any more.
>
> Yes, it (the shell form) can still be applied.
>
> > Could you please update it, if this bug is still relevant?
>
> Yes, it still is relevant. There is no need to update it.
>
> > If not - please close it. Thanks.
>
> Closing it with my 2:6.2.1+dfsg-1.1 upload. Thanks.
>
> NMU diff attached for conformance with dev-ref.
>
> Helmut
>

Bug#993814: ITP: r-bioc-biocio -- standard input and output for Bioconductor packages

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-biocio -- standard input and output for Bioconductor 
packages
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-bioc-biocio
  Version : 1.2.0
  Upstream Author : Martin Morgan,
* URL : https://bioconductor.org/packages/BiocIO/
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : standard input and output for Bioconductor packages
 Implements `import()` and `export()` standard generics
 for importing and exporting biological data formats. `import()`
 supports whole-file as well as chunk-wise iterative import. The
 `import()` interface optionally provides a standard mechanism for
 'lazy' access via `filter()` (on row or element-like components of
 the file resource), `select()` (on column-like components of the
 file resource) and `collect()`. The `import()` interface
 optionally provides transparent access to remote (e.g. via https)
 as well as local access. Developers can register a file extension,
 e.g., `.loom` for dispatch from character-based URIs to specific
 `import()` / `export()` methods based on classes representing file
 types, e.g., `LoomFile()`.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-biocio

Bug#993813: warn about known invalid fields in debian/upstream/metadata

[Jelmer Vernooij]

Package: lintian
Version: 2.104.0
Severity: wishlist

Some packages have known incorrect values in debian/upstream/metadata. For 
example:

Registration: https://github.com/join

is certain to be incorrect - as we don't package GitHub.

It would be great if lintian could warn about these.

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 lintian depends on:
ii  binutils2.37-4
ii  bzip2   1.0.8-4
ii  diffstat1.64-1
ii  dpkg1.20.9
ii  dpkg-dev1.20.9
ii  file1:5.39-3
ii  gettext 0.21-4
ii  gpg 2.2.27-2
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.40
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b7
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.26-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.9
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1.1
ii  libhtml-html5-entities-perl 0.004-1.1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-2
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1.1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.118-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-2
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012002-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.08-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repack-1+b1
ii  lzip1.22-3
ii  lzop1.04-2
ii  man-db  2.9.4-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.32.1-5
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2

lintian recommends no packages.

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.59-1

-- no debconf information

Bug#993806: kodi: No audio on DVD playback, AC3 Support

[Mattia Rizzolo]

On Mon, Sep 06, 2021 at 07:13:31PM +, Aaron wrote:
> I notice -DENABLE_INTERNAL_FFMPEG=OFF \ in rules.
> Would switching to -DENABLE_INTERNAL_FFMPEG=ON fix this?

Regardless of whether turning that switch on would fix the bug, that's
not considered as compliant in Debian, where we strive *very* hard to
avoid using internal copies of shared libraries.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#993805: UDD: duplicate entries for the same release

[Mattia Rizzolo]

On Mon, Sep 06, 2021 at 03:02:01PM -0400, Sandro Tosi wrote:
> > setuptools-scm/4.1.2-3 is still there, because apparently
> > python-setuptools-scm is still in unstable.
> 
> interesting, how did you find that out?

$ vim 
/var/lib/apt/lists/deb.debian.org_debian_dists_unstable_main_binary-amd64_Packages
-> hit /
-> type "setuptools"
-> hit return
-> hit "n" a few times
;)

> > Hopefully somebody else from debian-qa can tell why
> > python-setuptools-scm is still in Packages.
> 
> i think it's because mini-buildd -> python-keyring -> python-setuptools-scm
> 
> it appears that mini-buildd is about to release to unstable a python3
> versions, which will drop this chain of dependencies

Possibly.

I still find very odd that

$ dak rm -Rn python-setuptools-scm

doesn't find anything though.  dak is obviously aware of the package...

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#993812: ITP: r-cran-restfulr -- GNU R interface to RESTful web wervices

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-restfulr -- GNU R interface to RESTful web wervices
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-restfulr
  Version : 0.0.13
  Upstream Author : Michael Lawrence
* URL : https://cran.r-project.org/package=restfulr
* License : Artistic-2.0
  Programming Lang: GNU R
  Description : GNU R interface to RESTful web wervices
 Models a RESTful service as if it were a nested R list.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-restfulr

Bug#993573: transition: libdav1d

[Dylan Aïssi]

Hi,

Le lun. 6 sept. 2021 à 17:07, Sebastian Ramacher
 a écrit :
>
> Please go ahead
>

Thanks, uploaded!

Best,
Dylan

Bug#993317: golang-github-checkpoint-restore-go-criu: Please upgrade to upstream version 5.1.0

[Shengjing Zhu]

On Tue, Aug 31, 2021 at 1:15 AM Reinhard Tartler  wrote:
>
> Source: golang-github-checkpoint-restore-go-criu
> Severity: normal
>
> This is needed for podman 3.0:
>
> https://github.com/containers/podman/blob/v3.3.0/go.mod#L10

As stated on https://github.com/checkpoint-restore/go-criu/
v5 -> criu 3.15
v4 -> criu 3.14

criu in Debian is slow at updating, I won't expect v3.15 will be in
unstable any soon..

Are you able to get criu working with podman? If so we can go and test
go-criu v5 with criu v3.14.

-- 
Shengjing Zhu

Bug#993805: UDD: duplicate entries for the same release

[Sandro Tosi]

> setuptools-scm/4.1.2-3 is still there, because apparently
> python-setuptools-scm is still in unstable.

interesting, how did you find that out?

> Hopefully somebody else from debian-qa can tell why
> python-setuptools-scm is still in Packages.

i think it's because mini-buildd -> python-keyring -> python-setuptools-scm

it appears that mini-buildd is about to release to unstable a python3
versions, which will drop this chain of dependencies

thanks for looking into this

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#993810: pure-ftpd: CVE-2021-40524

[Salvatore Bonaccorso]

Source: pure-ftpd
Version: 1.0.49-4.1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pure-ftpd.

CVE-2021-40524[0]:
| In Pure-FTPd 1.0.49, an incorrect max_filesize quota mechanism in the
| server allows attackers to upload files of unbounded size, which may
| lead to denial of service or a server hang. This occurs because a
| certain greater-than-zero test does not anticipate an initial -1
| value.


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-40524
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40524
[1] https://github.com/jedisct1/pure-ftpd/pull/158

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#915541: Removal of upstream "--will-cite" functionality has been reverted

[Ole Tange]

On Fri, Sep 3, 2021 at 5:05 PM Felix Lechner  wrote:
> On Fri, Sep 3, 2021 at 7:50 AM Tobias Frost  wrote:
> >
> > But as said earlier: This is not a license issue; the license of GNU 
> > parallel
> > would allow removal, but this would make upstream sad.
> > The status quo is likely to mke our users sad, though.

Maybe it would help if the consequences were explained to them:

* Do you want the software with no citation notice and risk that the
maintainer will step down because he cannot afford spending time on it
- thus getting less free software in the long run?
* Or do you want to spend the 10 seconds it takes to silence the
notice if you don't want to see it?

I think more users would be more sad if the software was no longer
maintained. But you will no doubt get a few vocal exceptions.

But maybe there exists a third option.

> Maybe the debconf system can provide a choice? The default could be
> consistent with Debian's standards.

Can we agree that a click-wrap requires the user to actively do
something (e.g. clicking) before he can use the software? If so: The
citation notice is not a click-wrap, because the GNU Parallel will run
just fine without silencing the notice. It doesn't even break scripts.

It is still not clear to me how the default behaviour of the current
version of GNU Parallel conflicts with Debian's standards: The
citation notice provides you with useful information if you are a
researcher who publishes; it does not limit who can use the software.
If you believe it conflicts with Debian's standards, point to the
specific paragraph. (I accept that wording in version 20141022 was
unclear - and I can see how you could argue that back then).

The ultimate goal has never been to have a license notice. The goal is
to make it possible for me to spend time developing free software. In
practice this means either pay my salary or have GNU Parallel cited,
so it is easier for me to get a job that pays my salary.

It is unlikely that the Debian project will provide my salary, so let
us focus on the second part.

Before the license notice was implemented researchers forgot to cite
GNU Parallel; not because they did not want to honor the tradition,
but simply because they forgot. The citation notice changed this for
the better.

If there is a different way that will ensure researchers will not
forget, it would be acceptable to me.

I am open to (but not convinced) that a debconf choice would
accomplish this. If you believe it will, please elaborate how.


/Ole

Bug#993809: bullseye-pu: package segemehl/0.3.4-3+deb11u1 (Pre-approval)

[Nilesh Patra]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nil...@debian.org

[ Reason ]
The package segfauls to !amd64 and !i386 architectures. The version in
bullseye does not have autopkgtests, when we added those and uploaded
_after_ the bullseye release, tests were segfaulting on arm64, ppc64el
and armhf. Note that there has been no new upstream release, just test
addition with a few cosmetics.
Unfortunantely, the failing logs of the 0.3.4-4 version have disappeared
from here[1]
But, trying on a arm64 porter box confirms the experience.

 % ./segemehl -x index.idx -d seq1.fa
[SEGEMEHL] Mon Sep  6 18:29:55 2021: reading database sequences.
zsh: segmentation fault  ./segemehl -x index.idx -d seq1.fa

% ./segemehl -i index.idx -d seq1.fa -q myseq.fa > mymap.sam
[SEGEMEHL] Mon Sep  6 18:44:08 2021: reading queries in 'myseq.fa'.
...this keeps running forever

This has been fixed in unstable with the relevant patch, and upload[2]
0.3.4-5 and it migrated to testing after everything passes

[1]: https://ci.debian.net/data/autopkgtest/unstable/arm64/s/segemehl/
[2]: 
https://tracker.debian.org/news/1251311/accepted-segemehl-034-5-source-into-unstable/

Since I noticed and fixed it before any bug was filed, there does not
exist a corresponding RC bug in the database. Let me know if I should
file one and process BTS commands on that.

[ Impact ]
Users will find a broken segfaulting package on !amd64 and !i386
machines

[ Tests ]
Autopkgtests have been added. I've manually run them on porter boxes,
and it looks good (as it should)
The revision in unstable also has tests passing

https://ci.debian.net/data/autopkgtest/unstable/arm64/s/segemehl/14839955/log.gz

[ Risks ]
Being a leaf package with a not-very-high popcon, risk is pretty low

[ 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 stable
  [x] the issue is verified as fixed in unstable
diff -Nru segemehl-0.3.4/debian/changelog segemehl-0.3.4/debian/changelog
--- segemehl-0.3.4/debian/changelog 2021-02-18 15:14:26.0 +0530
+++ segemehl-0.3.4/debian/changelog 2021-09-06 23:46:30.0 +0530
@@ -1,3 +1,11 @@
+segemehl (0.3.4-3+deb11u1) bullseye; urgency=medium
+
+  * d/p/arm64.patch: Fix autopkgtest segaults on !amd64 and !i386
++ Change the signed-ness for needed chars to fix segfault
+  * Add autopkgtests
+
+ -- Nilesh Patra   Mon, 06 Sep 2021 23:46:30 +0530
+
 segemehl (0.3.4-3) unstable; urgency=medium
 
   * Team Upload.
diff -Nru segemehl-0.3.4/debian/examples segemehl-0.3.4/debian/examples
--- segemehl-0.3.4/debian/examples  1970-01-01 05:30:00.0 +0530
+++ segemehl-0.3.4/debian/examples  2021-09-06 23:45:58.0 +0530
@@ -0,0 +1 @@
+debian/tests/data/*
\ No newline at end of file
diff -Nru segemehl-0.3.4/debian/patches/arm64.patch 
segemehl-0.3.4/debian/patches/arm64.patch
--- segemehl-0.3.4/debian/patches/arm64.patch   1970-01-01 05:30:00.0 
+0530
+++ segemehl-0.3.4/debian/patches/arm64.patch   2021-09-06 23:43:50.0 
+0530
@@ -0,0 +1,75 @@
+Description: Change the signed-ness for several chars to fix segfault
+Author: Nilesh Patra 
+Last-Update: 2021-08-24
+--- a/libs/biofiles.c
 b/libs/biofiles.c
+@@ -1916,7 +1916,7 @@
+ Uint max, Uint *minlen, Uint *maxlen, unsigned char *minq, unsigned char 
*maxq) 
+ {
+ 
+-  char ch;
++  signed char ch;
+   char idchar=0;
+   int ret=0;
+   off_t curseqoffset, lastindexoffset=0;
+@@ -2515,7 +2515,7 @@
+ {
+ 
+   FILE *fp;
+-  char ch;
++  signed char ch;
+   char *buffer;
+   char *descrbuffer = NULL;
+   char *seqbuffer = NULL;
+--- a/libs/fileio.c
 b/libs/fileio.c
+@@ -498,7 +498,7 @@
+ void
+ bl_freplacestr(char *filename, char *str, Uint len, char stop){
+   int i = 0;
+-  char ch;
++  signed char ch;
+   FILE *fp;
+ 
+   fp = fopen(filename, "rb+");  
+@@ -523,7 +523,8 @@
+ 
+ int
+ bl_fgets(void *space, FILE *fp, char **str) {
+-  char ch, *buffer;
++  signed char ch;
++  char *buffer;
+   size_t buffersize = MAXBUFFERSIZE;
+   size_t len = 0;
+ 
+@@ -549,7 +550,7 @@
+ char* 
+ readfile(void* space, char* filename, size_t* strlen) {
+ 
+-  char ch;
++  signed char ch;
+   char *buffer;
+   FILE *fp;
+   size_t buffersize = MAXBUFFERSIZE;
+--- a/libs/merge.c
 b/libs/merge.c
+@@ -596,7 +596,7 @@
+   if (!file->complete && !file->eof){
+ 
+ #ifndef FILEBUFFEREDMERGE
+-char ch;
++signed char ch;
+ Uint buffersize = 1024;
+ buffer = ALLOCMEMORY(NULL, NULL, char, buffersize);
+ len = 0;
+--- a/libs/samheader.c
 b/libs/samheader.c
+@@ -460,7 +460,7 @@
+ {
+   FILE *fp;
+   off_t offset = 0;
+-  char ch;
++  signed char ch;
+   char *buffer;
+   //  char *descrbuffer = NULL;
+   //  char *seqbuffer = NULL;
diff -Nru segemehl-0.3.4/debian/patches/series 
segemehl-0.3.4/debian/patches/series
--- 

Bug#993808: golang-github-dgraph-io-badger-dev: integer overflow when compiling on 32bit platform

[Peymaneh Nejad]

Package: golang-github-dgraph-io-badger-dev
Version: 2.2007.2-2
Severity: important

Dear Maintainer,

A package that depends on badger fails to build on arches armhf and i386[1]:

```
# github.com/dgraph-io/badger
src/github.com/dgraph-io/badger/value.go:50:5: constant 4294967295 overflows int
```

The bug should be fixed in v2.2007.3[2] via this patch[3]

Could you please upgrade the package or backport the fix?

kind regards,
Peymaneh

[1] https://qa.debian.org/excuses.php?package=golang-github-smallstep-nosql
[2] https://github.com/dgraph-io/badger/releases/tag/v2.2007.3
[3] https://github.com/dgraph-io/badger/pull/1558

Bug#993807: fixes needing backporting for "content changed while it was being sent" and "failed to send content to remote"

[Joey Hess]

Package: git-annex
Version: 8.20210223-2
Severity: normal

There have been some two related fixes upstream since this version
to bugs that affect a sizable number of git-annex users, and make
git-annex fairly unusable. (Unable to send content to remotes, which
a crucial part of many workflows. I'll leave you to decide the real
severity.) 

These problems were introduced in the upgrade to git-annex version 8. I
noticed Debian needs to be fixed because a user reported both of
problems after upgrading their Debian system to this version.
https://git-annex.branchable.com/bugs/sync_failing_after_debian_bullseye_upgrade/

The original bug report for both issues was
https://git-annex.branchable.com/bugs/__34__failed_to_send_content_to_remote__34__/

The "content changed while it was being sent" was fixed in
git-annex 8.20210803, in commit 3b5a3e168d8decd196509ad582ad4b8795d979a6

The "failed to send content to remote" was fixed in the same 
version, in a series of commits. I think all of these commits are
necessary but have not verified.
73e0cbbb19703f08daf783d8788370726f852162
a30656037459b4006ba6ec12bd1cb4e705d04ea8
817ccbbc47156c24aade4c6c4dc0c195332a991e
d2aead67bd17faac753ccf41964789a3a62ddaf3

It may be that this second commit sequence also fixes the prior problem,
since I think they had the same root cause. But I have not tested
git-annex without both fixes.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#993252: Astroquery doesn't work with Astropy 4.3.1

[Ole Streicher]

Control: tags -1 patch

Hi Nilesh, Vincent,

from astropy's CHANGES.rst, version 4.3:

* astropy.utils.data.get_pkg_data_path is publicly scoped (previously
  the private function _find_pkg_data_path) for obtaining file paths
  without checking if the file/directory exists, as long as the package
  and module do. [#11006]

This should be the replacement. And this is the patch in astroquery that 
fixes it:


https://github.com/astropy/astroquery/commit/cfb75e1e50.patch

Cheers

Ole

Bug#993806: kodi: No audio on DVD playback, AC3 Support

[Vasyl Gello]

Hi Aaron!

Can you please enable debugging of FFmpeg and capture Kodi log reproducing the 
issue?
I recall there was an issue described on Kodi forums, but I want to check once 
more against your log.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#993805: UDD: duplicate entries for the same release

[Sandro Tosi]

Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: mo...@debian.org

Hello,
I noticed how some packages have duplicate entries in UDD.sources for the same
release:


udd=> select source, version, release from sources where source = 
'setuptools-scm' and release = 'sid';
 source | version | release
+-+-
 setuptools-scm | 4.1.2-3 | sid
 setuptools-scm | 6.0.1-1 | sid


and AFAICS there's no reason setuptools-scm/4.1.2-3 should be in sid (it was
uploaded between oldstable and stable).

Turns out, there are more than 600 pkgs in this state:


udd=> select count (*) from (select source, release, count(*) from sources 
where release = 'sid' group by 1, 2  having count(*) > 1) as x;
 count
---
   602
(1 row)


Is this something do address within UDD import process or the entries are coming
from someplace else? if the latter, please forward this bug to the appropriate
team/package.

Regards,
Sandro

Bug#993786: gcc-defaults-ports: Please add cross-compilers for ARC

[Alexey Brodkin]

Source: gcc-defaults-ports
Version: 1.190
Severity: normal
Tags: patch

Dear Maintainer,

Now when we work on Debian port for ARC processors it's very handy to have
a cross-compiler and ideally crossbuild-essential for ARC.

Please refer to the following patch which adds ARC to the list of
generated cross-compilers.

-Alexey

diff --git a/debian/rules b/debian/rules
index 57c332e..a4102c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -208,12 +208,12 @@ ifneq (,$(filter $(DEB_HOST_ARCH), i386 kfreebsd-i386 
hurd-i386))
 endif
 DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

-all_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k mipsel mips64 
mips64el or1k powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x sh4 sparc 
sparc64 x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386
+all_archs  = alpha amd64 arc armel armhf arm64 hppa i386 ia64 m68k mipsel 
mips64 mips64el or1k powerpc powerpcspe ppc64 ppc64el riscv64 s390 s390x sh4 
sparc sparc64 x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386

 gcc9_archs = powerpcspe
-gcc10_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k mipsel mips64 
mips64el or1k powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 x32 
hurd-i386 kfreebsd-amd64 kfreebsd-i386
+gcc10_archs  = alpha amd64 arc armel armhf arm64 hppa i386 ia64 m68k mipsel 
mips64 mips64el or1k powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 
x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386

-gnat_archs  = alpha amd64 armel armhf arm64 hppa i386 ia64 m68k mipsel mips64 
mips64el or1k powerpc powerpcspe ppc64 ppc64el s390 s390x sh4 sparc sparc64 x32 
hurd-i386 kfreebsd-amd64 kfreebsd-i386
+gnat_archs  = alpha amd64 arc armel armhf arm64 hppa i386 ia64 m68k mipsel 
mips64 mips64el or1k powerpc powerpcspe ppc64 ppc64el s390 s390x sh4 sparc 
sparc64 x32 hurd-i386 kfreebsd-amd64 kfreebsd-i386
 gnat9_archs  =

 # CV_XXX is the complete version number, including the release, without epoch
@@ -321,7 +321,7 @@ go_multilib_archs = $(filter $(go_archs), $(filter-out 
armel armhf, $(multilib_a

 d_multilib_archs = $(filter-out armel, $(multilib_archs))

-ada_archs = alpha amd64 arm64 armel armhf hppa i386 ia64 m68k \
+ada_archs = alpha amd64 arc arm64 armel armhf hppa i386 ia64 m68k \
mips64 mipsel mips64el mipsn32 mipsn32el \
mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el \
powerpc ppc64 ppc64el riscv64 s390 s390x sh4 sparc sparc64 \
@@ -344,6 +344,7 @@ m2_archs = alpha amd64 arm64 armel armhf i386 ia64 \

 HOST_ARCHS_alpha = amd64 i386 x32
 HOST_ARCHS_amd64 = arm64 i386 ppc64el x32
+HOST_ARCHS_arc = amd64 i386 x32
 HOST_ARCHS_armhf = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_armel = amd64 i386 x32 arm64 ppc64el
 HOST_ARCHS_arm64 = amd64 i386 x32 ppc64el
@@ -393,7 +394,7 @@ ifeq (,$(CROSS_ARCHS))
 endif
   else # -ports package
 ifneq (,$(filter $(DEB_HOST_ARCH),amd64 i386 x32))
-  CROSS_ARCHS  ?= alpha hppa m68k ppc64 riscv64 sh4 sparc64 \
+  CROSS_ARCHS  ?= alpha arc hppa m68k ppc64 riscv64 sh4 sparc64 \
$(if $(filter $(vendor), Ubuntu),, powerpc) \
$(if $(filter $(DEB_HOST_ARCH), amd64 i386), x32)
 else ifeq ($(DEB_HOST_ARCH),arm64)

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

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#993804: nfs-utils needs to take over libnfsidmap-regex

[Salvatore Bonaccorso]

Source: nfs-utils
Version: 1:2.5.4-1~exp1
Severity: serious
Justification: needs to be fixed before landing in stable release
X-Debbugs-Cc: 
car...@debian.org,gur...@phys.ethz.ch,manuel.maestin...@inf.ethz.ch

Since 2-4-4-rc3+ upsream libnfsidmap-regex is maintained within
nfs-utils source so we need to take over (with appropriate relations
of debian/control) the src:libnfsidmap-regex package.

Regards,
Salvatore

Bug#993803: weechat: CVE-2021-40516

[Salvatore Bonaccorso]

Source: weechat
Version: 3.0.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for weechat.

CVE-2021-40516[0]:
| WeeChat before 3.2.1 allows remote attackers to cause a denial of
| service (crash) via a crafted WebSocket frame that trigger an out-of-
| bounds read in plugins/relay/relay-websocket.c in the Relay plugin.


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-40516
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40516
[1] 
https://github.com/weechat/weechat/commit/8b1331f98de1714bae15a9ca2e2b393ba49d735b

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Vincent Lefevre]

Control: affects -1 rpcbind

On 2021-09-06 19:06:13 +0200, Niels Thykier wrote:
> Control: reassign -1 debhelper
> Control: affects -1 systemd

This bug actually affects rpcbind.

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

Bug#993802: RFS: psad/2.4.6-1 [QA] -- Port Scan Attack Detector

[Leandro Cunha]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: psad
   Version : 2.4.6-1
   Upstream Author : Michael B. Rash 
 * URL : http://www.cipherdyne.org/psad/
 * License : GPL-2+, other-1, other-2
 * Vcs : https://salsa.debian.org/debian/psad
   Section : admin

It builds those binary packages:

  psad - Port Scan Attack Detector

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/psad/psad_2.4.6-1.dsc

Changes since the last upload:

 psad (2.4.6-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release.
   * Add debian/upstream/metadata and fixed Lintian report.
   * Add debian/salsa-ci.yml.
   * debian/control:
 - Set maintainer Debian QA Group .
 - Update Vcs-Git and Vcs-Browser of anonscm to Salsa reported by Lintian.
 - Add Rules-Requires-Root reported by Lintian.
   * debian/docs and debian/psad.manpages:
 - There has been a change of upstream in the file directories to doc
   folder and removed FW_EXAMPLE_RULES file.
   * debian/watch:
 - Use secure URI reported by Lintian.
 - Change version of 3 to 4 reported by Lintian.
   * debian/copyright:
 - Remove line 10 unused paragraph in file reported by Lintian.
 - Add myself.
 - Fix Upstream-Name.
   * Drop debian/patches/fix_spelling.diff applied by upstream.
   * Remove trailing whitespace reported by Lintian.

Regards,
-- 
  Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Bug#993784: SQL syntax errors in proftpd-mod-pgsql

[Hilmar Preuße]

On 9/6/21 2:32 PM, Philipp Ewald wrote:

Hi,


as in "https://github.com/proftpd/proftpd/issues/1149; wrote there is a
Systax error.


Patch has been applied to the repository, tagged pending.


by trying to Insert there was adding extra single quotes.

proftpd[4984] 127.0.0.1 (62.96.182.48[62.96.182.48]): mod_sql/4.5:
unrecoverable backend error: (mod_sql_postgres/4.0.4) ERROR:  syntax
error at or near "cms"
LINE 1: INSERT INTO users_website_tallies VALUES (''cms'', 0.00)

There are already patches but maybe not ready when bullseye released?


Well, we could have applied the patch at that time. Unfortunately we
don't follow upstreams bug tracker, hence I wasn't aware of the issue.

Hilmar
--
#206401 http://counter.li.org

Bug#993801: piuparts testbed is missing debianutils: why?

[Georges Khaznadar]

Package: piuparts
Version: 1.1.4
Severity: normal

Dear Maintainer,

I discovered recently that piupart's testbed is missing the command `tempfile`,
which
I was using to write a a backup of a database to /var/tmp in a postrm script.

I wonder why the tesbed is missing this package, which is part of Debian's
essential packages, as reported by `aptitude search '?priority(required)'`

If `tempfile` is not part of piupart's testbed, is there a recommended way to
create an
unpredictable file name, in order to save backup data without a risk of
vulnerability?
(if my postrm script writes to a predictable file name like /var/tmp/foo,
somebody
can create in advance a link with this name, to access backup information,
which results in
an unexpected data leak)


-- System Information:
Debian Release: 11.0
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-security'), (400, 'unstable'),
(100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages piuparts depends on:
ii  debootstrap  1.0.123
ii  debsums  3.0.2
ii  libjs-sphinxdoc  3.4.3-2
ii  lsb-release  11.1.0
ii  lsof 4.93.2+dfsg-1.1
ii  mount2.36.1-8
ii  piuparts-common  1.1.4
ii  python3  3.9.2-3
ii  python3-debian   0.1.39

Versions of packages piuparts recommends:
ii  adequate  0.15.6

Versions of packages piuparts suggests:
ii  docker.io  20.10.5+dfsg1-1+b5
pn  schroot

Bug#993800: ITP: python-gast -- compatibility layer for the AST of various Python versions

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: debian-pyt...@lists.debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-gast
  Version : 0.5.2
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/gast
* License : BSD
  Programming Lang: Python
  Description : compatibility layer for the AST of various Python versions

Provides an homogeneous API over the Abstract Syntax Trees of various
Python versions (including Python 2 and Python 3), which itself is
compatible with the standard library "ast" module API.

This package is a dependency of ITP "pythran" [1] (and also of ITP
"beniget" [2], another dependency itself). My intent is to package this
software under the umbrella of the Debian Python team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993797

---
Diego M. Rodriguez

Bug#993328: openscap: FTBFS with Perl 5.34: hardcodes Perl version 5.32

[Hideki Yamane]

On Mon, 30 Aug 2021 23:50:41 +0300 Niko Tyni  wrote:
> This package fails to build from source with Perl 5.34 (currently in
> experimental). This is because debian/rules hardcodes Perl version
> 5.32.0.

 It was dealt with as below, but in NEW queue now...

commit c1060eee08d477cbc59426dbf6b38886fae3441b
Author: Hideki Yamane 
Date:   Sun Jul 4 03:41:48 2021 +0900

Do not specify specific version number to deal with changes

Perl5 transition would break build without this commit.
And it is expected to change soname in the future.




-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#993316: systemd: missing /lib/systemd/system/rpcbind.service file

[Niels Thykier]

Control: reassign -1 debhelper
Control: affects -1 systemd

Michael Biebl:
> Am 30.08.21 um 18:31 schrieb Vincent Lefevre:
>> Package: systemd
>> Version: 247.9-1
>> Severity: critical
>> Justification: breaks unrelated software
>>
>> systemd provides a dangling symlink:
>>
>> $ ls -l /lib/systemd/system/portmap.service
>> lrwxrwxrwx 1 root root 15 2021-08-17 17:31:36
>> /lib/systemd/system/portmap.service -> rpcbind.service
>> $ ls -L /lib/systemd/system/portmap.service
>> ls: cannot access '/lib/systemd/system/portmap.service': No such file
>> or directory
> 
> This symlink is created via
> 
> dh_link lib/systemd/system/rpcbind.service
> lib/systemd/system/portmap.service
> 
> I wonder if debhelper can do something about this or if this is one of
> the cases where the package is best updated manually.
> 
> I suspect we have a few packages which create such aliasing symlinks via
> *.links files or explicit calls to dh_link
> 
> 
> Niels, what's your thought on this?
> 
> 
>> This breaks checkrestart:
> 
> [...]
> 
> Regards,
> Michael
> 

Hi,

I am moving this bug to debhelper.

~Niels

Bug#993799: libwacom: Please increase tests timeout to avoid FTBFS on sparc64

[Laurent Bigonville]

Source: libwacom
Version: 1.11-1
Severity: important

Hello,

libwacom currently FTBFS on sparc64 due to a timeout in the tests:

https://buildd.debian.org/status/fetch.php?pkg=libwacom=sparc64=1.11-1=1630946766=0

Could you please increase the timeout?

If you look at the history it's sometimes building fine, sometimes not

Kind regards,
Laurent Bigonville


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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#993797: ITP: python-beniget -- collection of compile-time Python AST analyzers

[Diego M. Rodriguez]

Package: wnpp
X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org

Owner: "Diego M. Rodriguez" 
Severity: wishlist

* Package name: python-beniget
  Version : 0.4.1
  Upstream Author : Serge Guelton 
* URL : https://github.com/serge-sans-paille/beniget
* License : BSD
  Programming Lang: Python
  Description : collection of compile-time Python AST analyzers

Collection of compile-time analyzers of Python Abstract Syntax Trees
that can be used as building blocks to write static analyzers or
compilers:
* Ancestors: map a node to the list of its enclosing nodes
* DefUseChains: map a node to the list of definition points in that node
* UseDefChains: map a node to its list of potential definitions

This package is a dependency of ITP "pythran" [1]. My intent is to
package this software under the umbrella of the Debian Python team.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991143
---
Diego M. Rodriguez

Bug#993798: icedtea-netx: upgrade to debian 11 makes an Exception rise: A fatal error occurred while trying to verify jars.

[Josep Lladonosa i Capell]

Package: icedtea-netx
Version: 1.8.4-1
Severity: important
X-Debbugs-Cc: jlladon...@gmail.com

Dear Maintainer,

I upgraded a Debian 10.10 to Debian 11 (bullseye).

After this, a remote Java application stopped running. It was running perfectly 
on Debian 10. In fact
I have checked this on a virtualized Debian 10.8 and it runs perfectly.

javaws launch reports this:

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not 
initialize application. The application has not been initialized, for more 
information execute javaws from the command line.
at 
java.desktop/net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:822)
at 
java.desktop/net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:531)
at 
java.desktop/net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:945)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: A 
fatal error occurred while trying to verify jars. An exception has been thrown 
in class JarCertVerifier. Being unable to read the cacerts or trusted.certs 
files could be a possible cause for this exception.: zip file is empty
at 
java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:739)
at 
java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.(JNLPClassLoader.java:338)
at 
java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:421)
at 
java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:495)
at 
java.desktop/net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:468)
at 
java.desktop/net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:814)
... 2 more

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

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

Versions of packages icedtea-netx depends on:
ii  default-jre  2:1.11-72
ii  librhino-java1.7.7.2-3
ii  libtagsoup-java  1.2.1+-1.1

icedtea-netx recommends no packages.

icedtea-netx suggests no packages.

-- no debconf information

Bug#993654: nobody can reply to "gregor herrmann "

[積丹尼 Dan Jacobson]

gh> This "From" is indeed a bit unfortunate but there's nothing
gh> indiviudal salsa users can do about it …

OK, filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993654#30 .

Bug#927255: powerpc-utils is uninstallable

[John Paul Adrian Glaubitz]

Hello!

On 9/6/21 18:36, Pierre Neyron wrote:
> Yes, the following command running on a buster system complains about
> pmac-utils in the second stage:
> 
> debootstrap --foreign --arch=ppc64 --no-check-gpg '--include=locales
> openssh-server linux-image-powerpc64' sid /rootfs
> https://deb.debian.org/debian-ports

pmac-utils is part of the unreleased repository, so you need to install
it afterwards. I don't recommend running debootstrap with the kernel
included which probably pulls in powerpc-utils.

Once you have created the chroot, use the following sources.list [1] which
should allow you to install powerpc-utils.

Adrian

> [1] https://people.debian.org/~glaubitz/sources.list

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#927255: powerpc-utils is uninstallable

[Pierre Neyron]

Hello,

Yes, the following command running on a buster system complains about
pmac-utils in the second stage:

debootstrap --foreign --arch=ppc64 --no-check-gpg '--include=locales
openssh-server linux-image-powerpc64' sid /rootfs
https://deb.debian.org/debian-ports

chroot /rootfs /usr/bin/qemu-ppc64-static /bin/bash
/debootstrap/debootstrap --second-stage

[...]
I: Configuring initramfs-tools...
W: Failure while configuring base packages.  This will be re-attempted
up to five times.
W: See //debootstrap/debootstrap.log for details (possibly the package
powerpc-utils is at fault)

which says:

dpkg: error processing package powerpc-utils (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 powerpc-utils
dpkg: dependency problems prevent configuration of powerpc-utils:
 powerpc-utils depends on pmac-utils; however:
  Package pmac-utils is not installed.


The packages page https://packages.debian.org/sid/powerpc-utils
shows pmac-utils as dependence but not available also.

Best regards
Pierre

Bug#993123: frog FTCBFS: hard codes the build architecture pkg-config

[Maarten van Gompel]

Hi Helmut,

On 21-08-27 04:23, Helmut Grohne wrote:
> Source: frog
> Version: 0.20-2
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> frog fails to cross build from source, because configure.ac hard codes
> the build architecture pkg-config in one place (after correctly
> detecting the host architecture one). Simply using the correct
> substitution variable makes frog cross buildable. Please consider
> applying the attached patch.
>
> Helmut

Thanks for the patch! I have applied it upstream and will try to soon prepare a
new debian release for Frog that includes it.

Regards,

--

Maarten van Gompel
Digital Infrastructure
Humanities Cluster
Koninklijke Nederlandse Akademie van Wetenschappen (KNAW)

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
Telegram:   proycon  IRC: proycon (libera.chat + oftc)
Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
Twitter:https://twitter.com/proycon
ORCID:  https://orcid.org/-0002-1046-0006

Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Pieter Hollander]

PS: Additionally, I forgot to mention that adding dad-attempts 0 to the 
br0 inet6 config also solves the issues of networking failing.


On 06/09/2021 14:17, Pieter Hollander wrote:

Hi all,

I tried the fixes proposed here. Unfortunately, adding bridge_ports or 
bridge_hw did not solve the issue.
The workaround of changing exit 1 to exit 0 in the 
/lib/ifupdown/settle-dad.sh "DAD timed out: section did cause 
networking to start up successfully, although it still logs the timeout.


systemd[1]: Starting Raise network interfaces...
ifup[1463]: Waiting for DAD... Done
ifup[1606]: Waiting for DAD... Timed out
systemd[1]: Finished Raise network interfaces.

Using a dummy port to perform DAD sounds like the best solution to me.

Back to the workaround: It also solves the problems I encountered with 
Unbound & PostgreSQL being unable to bind to the IPv6 interface 
address specified.


Thank you all for the swift replies. This is my first Debian bug 
report and it's great to be met with this amount of responses.

Feel free to move it to ifupdown if that's more applicable.

It sounds good to fix it with a long-term solution in Bookworm,
but as I know multiple people depending on a configuration similar to 
the one I described earlier, it might be wise to fix in Bullseye as well.


Best regards,
Pieter

On 06/09/2021 11:04, Santiago Garcia Mantinan wrote:

Hi!

I'm CCing Josué because this seems to be more on ifupdown's side than on
bridge-utils.


auto br0
iface br0 inet static
 address  10.10.10.1
 netmask  255.255.255.0
 bridge_ports none
 bridge_stp off
 bridge_fd 0

iface br0 inet6 static
 address 2001:db8::2
 netmask 64

These stanzas are missing the "bridge_hw" entry which can be a MAC
address or the name of the interface whose MAC to take.  Thus your
bridge ends up being connected to nothing.
I know we are having quite some trouble with the random bridge mac 
address,

but this doesn't seem to be one of those cases.

For what I see this is a problem with DAD, the bridge is created 
without any

port attached to it, so the kernel doesn't allow it to transition from:
18: br0    inet6 X/64 scope link tentative \   valid_lft forever 
preferred_lft forever

to:
18: br0    inet6 X/64 scope link \   valid_lft forever 
preferred_lft forever


This is because without any port on the bridge the kernel cannot do 
any DAD.
So, without trasitioning it remains on tentative all the time, and 
thus the
script /lib/ifupdown/settle-dad.sh from the package ifupdown exits 
with a
timeout message, like the one you are seing and an error status of 1, 
thus

breaking the network setup.

I have thanged the exit 1 to an exit 0 on that script and everything 
works
like expected, this is a nasty workaround while we don't arrive to a 
better

solution, the other solution would be to attach something to the bridge,
maybe even a dummy port or similar.

Josué, we've had the idea of integrating bridge setup (now on 
bridge-utils)
into ifupdown, I wouldn't mind doing this for Bookworm, I would 
continue to

take care of this part to the best of my knowledte even if it is on
ifupdown.  Maybe it it is the time to do that.  As for this bug, the
workaround I describe is not a valid solution, but maybe we can check 
on the

settle-dad script to see if the device is a bridge without any interface
added to it, and thus not transitioning, and return with a 0 on the 
timeout

in that case?

About integration...  we have talked about that on some bugs that are
somehow half way between bridge-utils and ifupdown, last one may be 
#939713,
I would try to rewrite everything on the ifupdown scripts to depend 
on ip

and not brctl, so that ifupdown wouldn't depend on bridge-utils.

We can start some other thread on this if you want or we can talk 
about this

on irc or mail, whatever.

As for this bug... I believe it is on the ifupdown side, so I think we
should reasign it, unless you see a way to fix this problem on the
bridge-utils side, but I can't think about any fix on bridge-utils side
right now.

Regards.

Bug#993716: bridge-utils: IPv6 network bridge fails after upgrading Buster to Bullseye

[Pieter Hollander]

Hi all,

I tried the fixes proposed here. Unfortunately, adding bridge_ports or 
bridge_hw did not solve the issue.
The workaround of changing exit 1 to exit 0 in the 
/lib/ifupdown/settle-dad.sh "DAD timed out: section did cause networking 
to start up successfully, although it still logs the timeout.


systemd[1]: Starting Raise network interfaces...
ifup[1463]: Waiting for DAD... Done
ifup[1606]: Waiting for DAD... Timed out
systemd[1]: Finished Raise network interfaces.

Using a dummy port to perform DAD sounds like the best solution to me.

Back to the workaround: It also solves the problems I encountered with 
Unbound & PostgreSQL being unable to bind to the IPv6 interface address 
specified.


Thank you all for the swift replies. This is my first Debian bug report 
and it's great to be met with this amount of responses.

Feel free to move it to ifupdown if that's more applicable.

It sounds good to fix it with a long-term solution in Bookworm,
but as I know multiple people depending on a configuration similar to 
the one I described earlier, it might be wise to fix in Bullseye as well.


Best regards,
Pieter

On 06/09/2021 11:04, Santiago Garcia Mantinan wrote:

Hi!

I'm CCing Josué because this seems to be more on ifupdown's side than on
bridge-utils.


auto br0
iface br0 inet static
 address  10.10.10.1
 netmask  255.255.255.0
 bridge_ports none
 bridge_stp off
 bridge_fd 0

iface br0 inet6 static
 address 2001:db8::2
 netmask 64

These stanzas are missing the "bridge_hw" entry which can be a MAC
address or the name of the interface whose MAC to take.  Thus your
bridge ends up being connected to nothing.

I know we are having quite some trouble with the random bridge mac address,
but this doesn't seem to be one of those cases.

For what I see this is a problem with DAD, the bridge is created without any
port attached to it, so the kernel doesn't allow it to transition from:
18: br0inet6 X/64 scope link tentative \   valid_lft forever 
preferred_lft forever
to:
18: br0inet6 X/64 scope link \   valid_lft forever preferred_lft forever

This is because without any port on the bridge the kernel cannot do any DAD.
So, without trasitioning it remains on tentative all the time, and thus the
script /lib/ifupdown/settle-dad.sh from the package ifupdown exits with a
timeout message, like the one you are seing and an error status of 1, thus
breaking the network setup.

I have thanged the exit 1 to an exit 0 on that script and everything works
like expected, this is a nasty workaround while we don't arrive to a better
solution, the other solution would be to attach something to the bridge,
maybe even a dummy port or similar.

Josué, we've had the idea of integrating bridge setup (now on bridge-utils)
into ifupdown, I wouldn't mind doing this for Bookworm, I would continue to
take care of this part to the best of my knowledte even if it is on
ifupdown.  Maybe it it is the time to do that.  As for this bug, the
workaround I describe is not a valid solution, but maybe we can check on the
settle-dad script to see if the device is a bridge without any interface
added to it, and thus not transitioning, and return with a 0 on the timeout
in that case?

About integration...  we have talked about that on some bugs that are
somehow half way between bridge-utils and ifupdown, last one may be #939713,
I would try to rewrite everything on the ifupdown scripts to depend on ip
and not brctl, so that ifupdown wouldn't depend on bridge-utils.

We can start some other thread on this if you want or we can talk about this
on irc or mail, whatever.

As for this bug... I believe it is on the ifupdown side, so I think we
should reasign it, unless you see a way to fix this problem on the
bridge-utils side, but I can't think about any fix on bridge-utils side
right now.

Regards.

Bug#993796: bullseye-pu: package knot-resolver/5.3.1-1

[Jakub Ružička]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: jakub.ruzi...@nic.cz

[ Reason ]
Fixing bug #991463 (CVE-2021-40083) - potential DoS.

[ Impact ]
Vulnerability to DoS attack.

[ Tests ]
I've tested the fix manually by running the deckard (DNS test harness)
test sets/resolver/val_iter_high.rpl supplied with the upstream fix.

It's not trivial to setup system for deckard so I've used upstream
Debian bullseye docker image from Knot CI:

docker run -it --privileged 
registry.nic.cz/knot/knot-resolver/ci/debian-11:knot-3.0

With current knot-resolver-5.3.1-1 the test failed.
With suggested knot-resolver-5.3.1-1+deb11u1 the test passed.

[ Risks ]
This is a simple backport of upstream fix.

Upstream tests run during package build so chances of something
breaking are small.

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

[ Changes ]
Backport of upstream fix for #991463:

https://gitlab.nic.cz/knot/knot-resolver/-/merge_requests/1169/diffs#c22c39e3a02cdfb0d3d47b16ff46e65d196df19d
diff -Nru knot-resolver-5.3.1/debian/changelog 
knot-resolver-5.3.1/debian/changelog
--- knot-resolver-5.3.1/debian/changelog2021-04-12 05:59:28.0 
+
+++ knot-resolver-5.3.1/debian/changelog2021-08-31 16:20:00.0 
+
@@ -1,3 +1,10 @@
+knot-resolver (5.3.1-1+deb11u1) bullseye; urgency=medium
+
+  * Fix possible assertion failure in NSEC3 edge-case (CVE-2021-40083)
+(Closes: #991463)
+
+ -- Jakub Ružička   Tue, 31 Aug 2021 16:20:00 +
+
 knot-resolver (5.3.1-1) unstable; urgency=medium
 
   [ Jakub Ružička ]
diff -Nru knot-resolver-5.3.1/debian/gbp.conf 
knot-resolver-5.3.1/debian/gbp.conf
--- knot-resolver-5.3.1/debian/gbp.conf 2021-04-12 05:59:28.0 +
+++ knot-resolver-5.3.1/debian/gbp.conf 2021-08-31 16:20:00.0 +
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/bullseye
 debian-tag = debian/%(version)s
 upstream-branch = upstream
 upstream-tag = upstream/%(version)s
diff -Nru 
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
 
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
--- 
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
 1970-01-01 00:00:00.0 +
+++ 
knot-resolver-5.3.1/debian/patches/0002-validator-avoid-assertion-in-an-edge-case.patch
 2021-08-31 16:20:00.0 +
@@ -0,0 +1,58 @@
+From: =?utf-8?b?VmxhZGltw61yIMSMdW7DoXQ=?= 
+Date: Mon, 12 Apr 2021 15:23:02 +0200
+Subject: [PATCH] validator: avoid assertion in an edge-case
+
+Case: NSEC3 with too many iterations used for a positive wildcard proof.
+
+To really fix the answers, this also needed fixing the `any_rank` part
+which I somehow forgot in commit 7107faebc :-(
+---
+ lib/dnssec/nsec3.c   | 7 +++
+ lib/dnssec/nsec3.h   | 1 +
+ lib/layer/validate.c | 3 ++-
+ 3 files changed, 10 insertions(+), 1 deletion(-)
+
+diff --git a/lib/dnssec/nsec3.c b/lib/dnssec/nsec3.c
+index e9e536a..f3a48c0 100644
+--- a/lib/dnssec/nsec3.c
 b/lib/dnssec/nsec3.c
+@@ -596,6 +596,13 @@ int kr_nsec3_wildcard_answer_response_check(const 
knot_pkt_t *pkt, knot_section_
+   if (rrset->type != KNOT_RRTYPE_NSEC3) {
+   continue;
+   }
++  if (knot_nsec3_iters(rrset->rrs.rdata) > 
KR_NSEC3_MAX_ITERATIONS) {
++  /* Avoid hashing with too many iterations.
++   * If we get here, the `sname` wildcard probably ends 
up bogus,
++   * but it gets downgraded to KR_RANK_INSECURE when 
validator
++   * gets to verifying one of these over-limit NSEC3 RRs. 
*/
++  continue;
++  }
+   int ret = covers_name(, rrset, sname);
+   if (ret != 0) {
+   return ret;
+diff --git a/lib/dnssec/nsec3.h b/lib/dnssec/nsec3.h
+index 1e316f5..0fdbfce 100644
+--- a/lib/dnssec/nsec3.h
 b/lib/dnssec/nsec3.h
+@@ -39,6 +39,7 @@ int kr_nsec3_name_error_response_check(const knot_pkt_t 
*pkt, knot_section_t sec
+  * KNOT_ERANGE - NSEC3 RR that covers a wildcard
+  * has been found, but has opt-out flag set;
+  * otherwise - error.
++ * Records over KR_NSEC3_MAX_ITERATIONS are skipped, so you probably get 
kr_error(ENOENT).
+  */
+ int kr_nsec3_wildcard_answer_response_check(const knot_pkt_t *pkt, 
knot_section_t section_id,
+ const knot_dname_t *sname, int 
trim_to_next);
+diff --git a/lib/layer/validate.c b/lib/layer/validate.c
+index cf5dda2..cf5c88a 100644
+--- a/lib/layer/validate.c
 b/lib/layer/validate.c
+@@ -894,7 

Bug#993356: golang-go: Bump version to Go 1.16

[Anthony Fok]

Hi Gregor,

On Tue, Aug 31, 2021 at 4:27 AM Gregor Riepl  wrote:
> Package: golang-go
> Version: 2:1.15~1
> Severity: wishlist
> X-Debbugs-Cc: onit...@gmail.com
>
> Dear Maintainer,
>
> Please bump the version of the package to 1.16.
>
> bookworm already includes 1.16, while the upstream stable version is 1.17.
> It would be very helpful to have the default Go binary point to 1.16 now.

I agree, and I have been personally waiting for it too.

> Are there any bugs that prevent updating the default?

I don't think there is any, besides the fact that everyone has been
busy and hadn't gotten around to it yet?  :-)

So, I went ahead and upgraded it for the very first time.  2:1.16~1
has just been uploaded.  Hope I didn't introduce any new bugs!  Haha!

> Thank you very much.

You're very welcome!

Cheers,
Anthony

Bug#927255: powerpc-utils is uninstallable

[John Paul Adrian Glaubitz]

Hello!

On 9/6/21 17:45, Pierre Neyron wrote:
> any news regarding this bug ? This is indeed annoying when
> debootstraping a ppc64 BE system.

Do you still experience this issue? I can install powerpc-utils just fine on
ppc64. debootstapping the powerpc and ppc64 ports also works as otherwise the
install media [1] wouldn't work.

Adrian

> [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-04-17/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#927255: powerpc-utils is uninstallable

[Pierre Neyron]

Hello

any news regarding this bug ? This is indeed annoying when
debootstraping a ppc64 BE system.

Regards
-- 
Pierre

Bug#993793: bullseye-pu: package reportbug/7.10.3

[Thomas Goirand]

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

Hi,

[ Reason ]
This fixes the suite names against stable.
Note that Sandro Tosi (maintainer of reportbug) agrees
that I do this update in Stable.

[ Impact ]
Can't choose bullseye-pu otherwise.

[ Tests ]
Tried the fixed version: works! :)

[ Risks ]
No risk, IMO. It's a trivial patch.

[ 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

Cheers,

Thomas Goirand (zigo)
diff -Nru reportbug-7.10.3/debian/changelog 
reportbug-7.10.3+deb11u1/debian/changelog
--- reportbug-7.10.3/debian/changelog   2021-02-24 22:32:29.0 +0100
+++ reportbug-7.10.3+deb11u1/debian/changelog   2021-09-06 17:35:39.0 
+0200
@@ -1,3 +1,11 @@
+reportbug (7.10.3+deb11u1) bullseye; urgency=medium
+
+  [ Thomas Goirand ]
+  * Update suite names vs stable/oldstable, so it's possible to request for
+bullseye-pu (Closes: #992332).
+
+ -- Thomas Goirand   Mon, 06 Sep 2021 17:35:39 +0200
+
 reportbug (7.10.3) unstable; urgency=medium
 
   * reportbug/debbugs.py: handle installation-reports (Closes: #931438)
diff -Nru reportbug-7.10.3/reportbug/__init__.py 
reportbug-7.10.3+deb11u1/reportbug/__init__.py
--- reportbug-7.10.3/reportbug/__init__.py  2021-02-24 22:32:07.0 
+0100
+++ reportbug-7.10.3+deb11u1/reportbug/__init__.py  2021-09-06 
17:35:39.0 +0200
@@ -25,7 +25,7 @@
 __all__ = ['bugreport', 'utils', 'urlutils', 'checkbuildd', 'checkversions',
'debbugs', 'exceptions', 'submit', 'tempfile', 'mailer']
 
-VERSION_NUMBER = "7.10.3"
+VERSION_NUMBER = "7.10.3+deb11u1"
 
 VERSION = "reportbug " + VERSION_NUMBER
 COPYRIGHT = VERSION + '\nCopyright (C) 1999-2008 Chris Lawrence 
' + \
diff -Nru reportbug-7.10.3/reportbug/utils.py 
reportbug-7.10.3+deb11u1/reportbug/utils.py
--- reportbug-7.10.3/reportbug/utils.py 2021-02-09 18:38:37.0 +0100
+++ reportbug-7.10.3+deb11u1/reportbug/utils.py 2021-09-06 17:35:39.0 
+0200
@@ -95,12 +95,13 @@
'/usr/man', '/usr/doc', '/usr/bin']
 
 # A map between codenames and suites
-CODENAME2SUITE = {'wheezy': 'oldoldoldstable',
-  'jessie': 'oldoldstable',
-  'stretch': 'oldstable',
-  'buster': 'stable',
-  'bullseye': 'testing',
-  'bookworm': 'next-testing',
+CODENAME2SUITE = {'wheezy': 'oldoldoldoldstable',
+  'jessie': 'oldoldoldstable',
+  'stretch': 'oldoldstable',
+  'buster': 'oldstable',
+  'bullseye': 'stable',
+  'bookworm': 'testing',
+  'trixie': 'next-testing',
   'sid': 'unstable',
   'experimental': 'experimental'}
 SUITE2CODENAME = dict([(suite, codename) for codename, suite in 
list(CODENAME2SUITE.items())])

Bug#993791: obs-plugins: Please, add move-transition to plugins

[Sebastian Ramacher]

Control: tags -1 moreinfo

On 2021-09-06 12:10:20 -0300, Joao Eriberto Mota Filho wrote:
> Package: obs-plugins
> Version: 27.0.1+dfsg1-1
> Severity: wishlist
> 
> Dear maintainer,
> 
> Since OBS-27, move-transition[1] is supported. This very useful plugin needs 
> to
> be built with OBS (not independent).

Any why can't it be built with libobs-dev? This should contain all
headers that are required to build an OBS plugin.

Cheers

> 
> [1] https://github.com/exeldro/obs-move-transition
> 
> move-transition is a plugin for OBS Studio to move source to a new position
> during scene transition. This plugin provides a professional effect to videos.
> 
> I have move-transition compiled in obs-studio_27.0.1+dfsg1-1 (rebuilt) and it
> works fine.
> 
> Alternatively, if not possible add it directly in the obs-studio, if you allow
> me to make it, I can submit a new package to Debian, using a clone of the
> obs-studio already packaged by you, to provide the plugin only. However, it is
> a workaround and I think the best way is adding move-transition to your
> package.
> 
> I also can send a PR to Salsa to help you to implement it. Please, let me know
> if it is desirable.
> 
> Regards,
> 
> Eriberto
> 

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

[Paul Flaherty]

Thanks for the information sorry for the misunderstanding.

Get Outlook for iOS

From: Simon McVittie 
Sent: Sunday, September 5, 2021 8:09:24 PM
To: Paul Flaherty 
Cc: 992...@bugs.debian.org <992...@bugs.debian.org>; 
debian-gtk-gn...@lists.debian.org 
Subject: Re: Bug#992870: transition: GNOME 40 (libmutter-8-0 and friends)

On Sun, 05 Sep 2021 at 23:56:23 +, Paul Flaherty wrote:
> I am wondering if we can do a transition on gnome web

I think you are misunderstanding what is being tracked in #992870.

GNOME Web in Debian is the epiphany-browser package, which is already
at version 40 in testing/unstable.

> and also what other
> applications have been transitioned over to gnome 40 and GTK 4

The transition-tracking bug #992870 is about updating core components
of the GNOME desktop itself, in Debian testing/unstable. It is not about
individual applications.

Individual applications are not generally "transitioned over to gnome 40".
GNOME 40 versions of several applications are already in testing/unstable.
Some others are not yet available because they are blocked by separate
library transitions for libgweather and evolution-data-server, but those
are not part of the transition discussed in #992870.

Individual applications can switch from GTK 3 to GTK 4 without needing
coordination with the release team. This requires considerable changes
to happen in each application upstream, and will often take months or
years (some applications still use GTK 2). It does not have to happen
all at once: we can have a mixture of GTK 2, 3 and 4 applications if
necessary.

The only reason why GTK 4 was required for gnome-shell 40 is that one of
the few applications that is already using GTK 4 is gnome-extensions-app,
in the gnome-shell-extension-prefs package.

smcv

Bug#993438: python3-pygments: Markdown and Output lexers cannot be found

[Francesco Potortì]

>> Package: python3-pygments
>> Version: 2.7.1+dfsg-2.1
>> Severity: normal
>> X-Debbugs-Cc: none, Francesco Potortì 
>>
>>   get_lexer_by_name("markdown")
>> does not work: it does not find the lexer.
>> However,
>>   get_lexer_by_name("md")
>> works, so this is a bug with a workaround.
>>
>>   get_lexer_by_name("output")
>> does not work: it does not find the lexer.
>> This time, it seems that OutputLexer is not really there, as
>>   from pygments.lexers import OutputLexer
>> does not work either.
>
>If the version (2.7.1) is correct, this is expected: the "markdown"
>alias is new in 2.8.0, while the Output lexer is new in 2.10.0.

Ok, thanks, will wait :)

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it