Bug#958476: python3-gevent: gevent 1.4 not compatible with python 3.8

[Matthias Klose]

Control: tags -1 + patch

I packaged the recent version, cause the current isn't compatible with 3.9
either. All triggered autopkg tests passed.

Packaging proposal at
https://launchpad.net/ubuntu/+source/python-gevent/20.9.0-0ubuntu1

Bug#975900: aria2: autopkgtest needs update for new version of python3-defaults: output to stderr

[Matthias Klose]

Control: tags -1 + patch

patch at
https://patches.ubuntu.com/a/aria2/aria2_1.35.0-2ubuntu1.patch

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Niels Thykier]

Control: tags -1 moreinfo

Marc Ferland:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> [...]
> 
> Changes since the last upload:
> 
>  libzc (0.4.3-1) unstable; urgency=low
>  .
>* New upstream release.
>* New Dockerfile to simplify debian releases.
>* Removed zc_file_info_offset() function from API.
>* Added two new functions to the API: zc_file_info_offset_begin() and
>  zc_file_info_offset_end().
>* ABI change libzc4 -> libzc6
>* Added the possibility to specify the filenames instead of the
>  offsets in the plaintext cracker in yazc tool.
>* Added the -S option to the plaintext cracker to print time stats.
> 
> Regards,
> --
>   Marc Ferland
> 

Hi Marc,


I found a few issues I would like to see resolved before I will sponsor
the upload.


Changelog
=

I see the following changes since 0.4.1-1 that I cannot find documented
in debian/changelog:

 * Rules-Requires-Root has been set to "no"

 * Multi-Arch has been set to same for two binary packages.

 * Standards-Versions has been bumped to 4.5.0

Please document these in the 0.4.3-1 changelog.


_Pedantic_ side note: It is custom to only mention uploads that have
been uploaded in the debian/changelog.  As 0.4.2-1 was never in Debian
unstable (and I presume in no other distro as well given it says
"unstable") then it should have been omitted.

SONAME bump
===

The library changes SONAME and there is no mention of it.  This requires
a transition if the package has reverse dependencies, but there is no
comment from you on whether you have started the relevant transition
procedures or that they are irrelevant because your package has no
reverse dependencies in unstable and testing.


In #902476, I have exempted you from some of these requirements
previously on the basis that I wanted you to do them correctly next time
(which would be now). :)

~Niels

Bug#976187: runit-systemd => runit-run transition fails to enable unit

[Jamie Heilman]

Package: runit
Version: 2.1.2-38

The runit-run package fails to enable the runit.service unit during
installation on systems that use systemd.  This is surprising behavior
that isn't documented in the NEWS file (if it was even intentional)
and leaves folks with a previously working setup w/runit-systemd a
system that won't start runit on next reboot.

-- 
Jamie Heilman http://audible.transient.net/~jamie/

Bug#976171: fmutils failed, breaking tex-common

[Hilmar Preuße]

Control: reassign -1  texlive-latex-base
Control: severity 976170 serious
Control: forcemerge -1 976170

Am 01.12.2020 um 02:07 teilte Vincent Lefevre mit:


Dup of bug 976170?


Probably. Forcemerge.

Hilmar
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature

Bug#976181: ITP: golang-github-harrymichal-go-version -- Version normalizer and comparison library for go

[Hayley Hughes]

Package: wnpp
Severity: wishlist
Owner: Hayley Hughes 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name : golang-github-harrymichal-go-version
 Version : 1.0.1-1
 Upstream Author : Ondřej Míchal
* URL : https://github.com/HarryMichal/go-version
* License : MIT
 Programming Lang: Go
 Description : Version normalizer and comparison library for go

Version normalizer and comparison library for go, heavy based on PHP
version_compare function and Version comparsion libs from Composer
(https://github.com/composer/composer) PHP project.

Required for packaging golang-github-containers-toolbox (See: #972674)

Bug#976080: pdfxup doesn't work anymore

[Julien Puydt]

Le dimanche 29 novembre 2020 à 20:38 +0100, Hilmar Preuße a écrit :
> 
> It looks like the usual incompatible change in gs. Could you load the
> latest version of pdfxup from CTAN and check if that solves your
> issue?

It doesn't. Not the same line numbers, but same errors.

Cheers,

JP

Bug#974705: Changes to job handling cause hangs in wait

[Herbert Xu]

On Tue, Dec 01, 2020 at 05:06:18PM +1100, Herbert Xu wrote:
>
> For some reason this is causing the final two tee's to be created
> as children of debian/tests/timedated rather than the bash shell.

An alternative to changing the parent is of course to do

wait $MONPID

instead of

wait

I think this makes more sense anyway as otherwise someone could
easily introduce a hang if they unwittingly add a backgrounded
job to this script.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#974705: Changes to job handling cause hangs in wait

[Herbert Xu]

On Tue, Dec 01, 2020 at 04:38:37PM +1100, Herbert Xu wrote:
> 
> FWIW I'm unable to reproduce it with autopkgtest.  This is what
> I get:
> 
> root@test0:~# autopkgtest --test-name=timedated systemd-246.6/ -B -- lxc -s 
> autopkgtest-sid
> autopkgtest [16:32:45]: starting date: 2020-12-01
> autopkgtest [16:32:45]: version 5.15
> autopkgtest [16:32:45]: host test0; command line: /usr/bin/autopkgtest 
> --test-name=timedated systemd-246.6/ -B -- lxc -s autopkgtest-sid
> autopkgtest [16:33:13]: testbed dpkg architecture: amd64
> autopkgtest [16:33:13]: testbed running kernel: Linux 5.9.0-rc1+ #18 SMP 
> PREEMPT Sat Aug 29 23:45:30 AEST 2020
> autopkgtest [16:33:13]:  unbuilt-tree systemd-246.6/
> autopkgtest [16:33:18]: testing package systemd version 246.6-5

Nevermind, I see that the script has been modified to use bash.

I can reproduce the problem now so it's all good.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#974705: Changes to job handling cause hangs in wait

[Herbert Xu]

On Mon, Nov 16, 2020 at 10:29:16AM +, Andrej Shadura wrote:
> 
> I’d like to forward a bug report I received. Michael, who reported it,
> was able to bisect it to 6c691b3, which was the first of the series of
> commits changing job handling.
> 
> I must note that I had troubles debugging it: I was only able to
> reproduce the issue in an autopkgtest virtual machine, but not on my
> normal system nor in a fresh Debian unstable Docker container.

FWIW I'm unable to reproduce it with autopkgtest.  This is what
I get:

root@test0:~# autopkgtest --test-name=timedated systemd-246.6/ -B -- lxc -s 
autopkgtest-sid
autopkgtest [16:32:45]: starting date: 2020-12-01
autopkgtest [16:32:45]: version 5.15
autopkgtest [16:32:45]: host test0; command line: /usr/bin/autopkgtest 
--test-name=timedated systemd-246.6/ -B -- lxc -s autopkgtest-sid
autopkgtest [16:33:13]: testbed dpkg architecture: amd64
autopkgtest [16:33:13]: testbed running kernel: Linux 5.9.0-rc1+ #18 SMP 
PREEMPT Sat Aug 29 23:45:30 AEST 2020
autopkgtest [16:33:13]:  unbuilt-tree systemd-246.6/
autopkgtest [16:33:18]: testing package systemd version 246.6-5
autopkgtest [16:33:18]: build not needed
autopkgtest [16:33:18]: test timedated: preparing testbed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  acl libnss-systemd
The following NEW packages will be installed:
  acl libnss-systemd
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 255 kB of archives.
After this operation, 577 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 libnss-systemd amd64 246.6-5 
[194 kB]
Get:2 http://deb.debian.org/debian sid/main amd64 acl amd64 2.2.53-8 [60.8 kB]
Fetched 255 kB in 1s (489 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package libnss-systemd:amd64.
(Reading database ... 12641 files and directories currently installed.)
Preparing to unpack .../libnss-systemd_246.6-5_amd64.deb ...
Unpacking libnss-systemd:amd64 (246.6-5) ...
Selecting previously unselected package acl.
Preparing to unpack .../acl_2.2.53-8_amd64.deb ...
Unpacking acl (2.2.53-8) ...
Setting up libnss-systemd:amd64 (246.6-5) ...
First installation detected...
Checking NSS setup...
Setting up acl (2.2.53-8) ...
Setting up autopkgtest-satdep (0) ...
Processing triggers for libc-bin (2.31-4) ...
(Reading database ... 12667 files and directories currently installed.)
Removing autopkgtest-satdep (0) ...
autopkgtest [16:33:29]: test timedated: [---
original tz: Etc/UTC
timedatectl works
change timezone
reset timezone to original
no adjtime file
UTC set in adjtime file
non-zero values in adjtime file
fourth line adjtime file
no final newline in adjtime file
only one line in adjtime file
only one line in adjtime file, no final newline
only two lines in adjtime file
only two lines in adjtime file, no final newline
unknown value in 3rd line of adjtime file
disable NTP
enable NTP
re-disable NTP
autopkgtest [16:33:32]: test timedated: ---]
autopkgtest [16:33:32]: test timedated:  - - - - - - - - - - results - - - - - 
- - - - -
timedatedPASS
autopkgtest [16:33:32]:  summary
timedatedPASS
root@test0:~# 

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#974705: Changes to job handling cause hangs in wait

[Herbert Xu]

On Tue, Dec 01, 2020 at 04:42:03PM +1100, Herbert Xu wrote:
>
> Nevermind, I see that the script has been modified to use bash.
> 
> I can reproduce the problem now so it's all good.

OK the problem is this:

sh -c 'sleep 1d& exec $MYSHELL -c "sleep 1& wait"'

You can replace MYSHELL with whatever shell you want to use.

Essentially dash will now wait for all children, even ones that
were created prior to its existence, however, bash only waits for
children that it created directly.

FWIW ksh exhibits the same behaviour as dash and I think there
is nothing wrong with this.

So the problem is really in the parent of this shell, which appears
to be bash:

bash -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 || true;  
. ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/autopkgtest-lxc.is4n6xxr/downtmp/build.f2G/real-tree"; mkdir -p 
-m 1777 -- "/tmp/autopkgtest-lxc.is4n6xxr/downtmp/timedated-artifacts"; export 
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.is4n6xxr/downtmp/timedated-artifacts";
 export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755 
"/tmp/autopkgtest-lxc.is4n6xxr/downtmp/autopkgtest_tmp"; export 
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.is4n6xxr/downtmp/autopkgtest_tmp"; export 
ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive; export 
LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=2; unset LANGUAGE LC_CTYPE 
LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME 
LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f 
/tmp/autopkgtest_script_pid; set -C; echo $$ > /tmp/autopkgtest_script_pid; set 
+C; trap "rm -f /tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd 
"$buildtree"; export AUTOPKGTEST_NORMAL_USER=; export ADT_NORMAL_USER=; chmod 
+x 
/tmp/autopkgtest-lxc.is4n6xxr/downtmp/build.f2G/real-tree/debian/tests/timedated;
 touch /tmp/autopkgtest-lxc.is4n6xxr/downtmp/timedated-stdout 
/tmp/autopkgtest-lxc.is4n6xxr/downtmp/timedated-stderr; 
/tmp/autopkgtest-lxc.is4n6xxr/downtmp/build.f2G/real-tree/debian/tests/timedated
 2> >(tee -a /tmp/autopkgtest-lxc.is4n6xxr/downtmp/timedated-stderr >&2) > 
>(tee -a /tmp/autopkgtest-lxc.is4n6xxr/downtmp/timedated-stdout);

For some reason this is causing the final two tee's to be created
as children of debian/tests/timedated rather than the bash shell.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#976186: node-backbone: Please provides typescript definition

[Xavier Guimard]

Package: node-backbone
Version: 1.3.3~dfsg-5
Severity: important

node-typescript-types is deprecated, please embed @types/backbone in
node-backbone.

Bug#976183: ITP: golang-github-godbus-dbus -- Native Go bindings for D-Bus

[Shengjing Zhu]

On Tue, Dec 1, 2020 at 12:21 PM Hayley Hughes  wrote:
>
> Package: wnpp
> Severity: wishlist
> Owner: Hayley Hughes 
> X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org
>
> * Package name : golang-github-godbus-dbus
>   Version : 5.0.3-1
>   Upstream Author :
> * URL : https://github.com/godbus/dbus

Duplicated of https://tracker.debian.org/pkg/golang-dbus

-- 
Shengjing Zhu

Bug#976162: closed by Sebastiaan Couwenberg (Re: Bug#976162: postgis v3.0.3 pdpg package for amd64 for Ubuntu focal missing)

[Sebastiaan Couwenberg]

On 11/30/20 9:02 PM, Tomas Pospisek wrote:
> Sebastiaan Couwenberg wrote on Mon, 30 Nov:
> 
>> On 11/30/20 7:56 PM, Tomas Pospisek wrote:
>>
>>> There is no 3.0.3 package for postgis for focal on pdgd for amd64:
>>
>> The Debian BTS is not appropriate for this issue, use the
>> pgsql-pkg-deb...@postgresql.org mailing list, or
>> https://redmine.postgresql.org/projects/pgapt/issues instead.
> 
> Ah, thanks. I was pointed to https://wiki.postgresql.org/wiki/Apt#Bugs
> and it reads there:
> 
>> Bugs
>>
>> Please report bugs:
>>
>> * on the pgsql-pkg-deb...@postgresql.org mailing list, or
>> * open an issue in Redmine, or
>> * open a bug in the Debian BTS.
> 
> Which as you explained should probably read
> 
> * open a bug in the Debian BTS only if it's a bug in a package
>   released through Debian's own package repository.

Third party repos should not suggest reporting bugs in Debian the
prevent issues like this. But at least they list it as last resort.

The PGDG packages use the same source packages as Debian so many
packaging issues affect Debian as well, so the BTS can be used for those
issues that affect Debian as well.

This bugreport is not about packaging, and not even about Debian. So
definitely not appropriate for the Debian BTS.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#976185: i386 baseline violation in QCMS code

[Fanael Linithien]

Package: firefox
Version: 83.0-1

Firefox crashes with SIGILL on CPUs that don't support SSE2, even
though Debian's baseline doesn't require it.

The crash manifests itself in qcms_transform_data_bgra_out_lut_sse2,
which uses SSE2 intrinsics, and so should never be reached on CPUs
that don't support SSE2, but is, at least on my Pentium III.

I'm 95% sure that the origin of the problem is sse_version_available,
in gfx/qcms/src/transform.rs: it's incorrectly defined to always
return 2, which is correct on AMD64, but not on IA-32:

/* we know at build time that 64-bit CPUs always have SSE2
 * this tells the compiler that non-SSE2 branches will never be
 * taken (i.e. OK to optimze away the SSE1 and non-SIMD code */
return 2;

The upstream commit that introduced the regression appears to be
25a50264ae3204f2df9add308fc712df45947637, which also incorrectly
dropped support for SSE 1, which is IIRC still supported by upstream,
it's just not tier 1 anymore and upstream *binaries* don't support it.

Bug#974857: new upstream version 20.10.0-beta1

[El boulangero]

I just uploaded docker.io 20.10.0~rc1+dfsg2-3 to experimental. containerd
has been completely removed from this version. Now docker.io build-depends
on golang-github-containerd-containerd-dev, and at runtime it depends on
containerd.

There's still some work to be done on the package, mainly updating /
cleaning up the build depend tree. I'll work on that this week. Cheers.

  Arnaud

On Sat, Nov 28, 2020 at 12:35 AM Shengjing Zhu  wrote:

> On Fri, Nov 27, 2020 at 11:19 PM Shengjing Zhu  wrote:
> [...]
> >
> > > What do you think of that ? Would you mind looking at
> https://salsa.debian.org/docker-team/docker/-/commit/da70c7e, and tell me
> if that makes sense to apply these patches in containerd ? Or do you have a
> better idea ?
> > >
> >
> > I will try to backport.
>
> It's in experimental now.
>
> --
> Shengjing Zhu
>

Bug#972674: ITP: toolbox -- Unprivileged container development environment

[Hayley Hughes]

Hey all,

Thanks Raphael for CCing the correct people and thanks to Reinhard for 
offering to sponsor.


Would you be happy to maintain the packaging under the golang-team 
umbrella or would you have
other preferences? Having it in the debian/ namespace on salsa would 
work for me

equally well.


I would be happy to maintain it under the golang team umbrella. 
Although it might make things a little easier for them if I changed it 
over to using dh_golang to keep things more consistent with other go 
packages. I only really chose to go with meson because I needed 
something that I knew would just work for the short term.


 I agree with Raphael, the currently chosen names are too generic for 
integration

into a general-purpose distribution such as Debian. I'd propose:

src:golang-github-containers-toolbox to produce toolbox-podman (or 
podman-toolbox)


I definitely agree and will look into fixing everything sometime today.

Kind regards,
Hayley

On Mon, Nov 30, 2020 at 07:26, Reinhard Tartler  
wrote:

Thanks Raphael for highlighting Hayley's work.


On 11/30/20 4:22 AM, Raphael Hertzog wrote:

 Hi,

 On Thu, 22 Oct 2020, Hayley Hughes wrote:

 * URL : <>

 Toolbox is a tool that offers a familiar package based environment 
for
 developing and debugging software that runs fully unprivileged 
using Podman.

 […]

 I have already made some progress which can be found on salsa
 (<>) for my own benefit 
(please feel
 free to review it and suggest changes) and I thought that it might 
be an
 idea to make an attempt to properly package it and add it to the 
Debian

 archives.

 Will be keen to hear what others think.


 I was looking for the package and I'm glad that you are working on
 packaging it.

 I have put in CC Reinhard Tartler and Dmitry Smirnov that are the
 Uploaders of podman and buildah, maybe they would be willing to 
sponsor

 your package and integrate it in the pkg-go team.


I looked at the upstream README and over the packaging, which seems 
clean to me.
Curiously, while written in go, it doesn't use the dh_golang 
debhelper but
the upstream meson build system. That's a first for me, but 
(probably) not concerning.


I'd be happy to upload the package on your behalf.

Would you be happy to maintain the packaging under the golang-team 
umbrella or would you have
other preferences? Having it in the debian/ namespace on salsa would 
work for me

equally well.



 As for the discussion about the package name, podman-toolbox or
 container-toolbox looks good to me.


I agree with Raphael, the currently chosen names are too generic for 
integration

into a general-purpose distribution such as Debian. I'd propose:

src:golang-github-containers-toolbox to produce toolbox-podman (or 
podman-toolbox)



[currently, the packaging uses src:toolbox and toolbox as binary 
package name]


Best,
-rt

Bug#975997: [pcp] Bug#975997: pcp: Upgrade failure due to unversioned libpcp3 dependency

[Nathan Scott]

Hi Matthew,

On Sat, Nov 28, 2020 at 7:38 PM Matthew Gabeler-Lee  wrote:
>
> Attempting an `apt upgrade` on my bullseye system failed, due to improper
> dependency info in the pcp package.  The libpcp3 dependency has no version
> constraints, and the new version of libpcp3 requires pulling in a new
> version of perl, so `apt upgrade` left it out.  This then resulted in the
> attempt to restart the pcp service failing due to a missing symbol:

Thanks for the report - this is resolved in the upstream PCP git repo now,
and will be uploaded in a couple of weeks after further testing.

cheers.

--
Nathan

Bug#975411: meson: autopkgtest arm64

[Michel Le Bihan]

Hello,

I implemented this test in 
https://github.com/mesonbuild/meson/commit/631a7b5a2a8ffa31d0d126608e79841be02ecfea
 . Please enable it in the next version.

Michel Le Bihan

Bug#976182: javatools: jh_build man page not formatting correctly

[Wookey]

Source: javatools
Version: 0.77
Severity: normal


man jh_build shows extra capital Is in the FILES section:
so it comes out like this:

   A file consisting of each build to perform.  One build per line 
where each line consists of:

 I I [... I]

Looking at the code I think that I is supposed to display
"string" in an italic font, but for some reason it's not being processed
as desired, even though this seems to be working elsewhere in the
file.

podchecker said there was nothing wrong with it (except the empty
DESCRIPTION section, which should be removed or filled)

I had a go at fixing it but I've never understood nroff/groff/troff and
how that interacts with pod2man so I failed. But something is wrong
here, and it produces quite a confusing man page.

Bug#976180: RFS: libzc/0.4.3-1 -- Command line tool for the libzc library

[Marc Ferland]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libzc
   Version : 0.4.3-1
   Upstream Author : Marc Ferland 
 * URL : https://github.com/mferland/libzc
 * License : LGPL-2.1+, GPL-3+ with Autoconf exception, GPL-3+
 * Vcs : [fill in URL of packaging vcs]
   Section : libs

It builds those binary packages:

  yazc - Command line tool for the libzc library
  libzc6 - fast password cracking library for zip archives
  libzc-dev - fast password cracking library for zip archives (dev)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libz/libzc/libzc_0.4.3-1.dsc

Changes since the last upload:

 libzc (0.4.3-1) unstable; urgency=low
 .
   * New upstream release.
   * New Dockerfile to simplify debian releases.
   * Removed zc_file_info_offset() function from API.
   * Added two new functions to the API: zc_file_info_offset_begin() and
 zc_file_info_offset_end().
   * ABI change libzc4 -> libzc6
   * Added the possibility to specify the filenames instead of the
 offsets in the plaintext cracker in yazc tool.
   * Added the -S option to the plaintext cracker to print time stats.

Regards,
--
  Marc Ferland

Bug#976176: linux-image-4.19.0-11-amd64: ALSA regression: no sound from ALC295 headphone jack starting in 4.19.0-11

[Kevin]

Package: src:linux
Version: 4.19.146-1
Severity: important

On an ASUS GL703GM-NS73 laptop, which reports using a Realtek ALC295, there is
no sound from the headphone jack beginning with 4.19.0-11. I have replicated
the problem using Debian Live distributions to remove any variables that may
be specific to my personal installation.

Debian Live 10.4 KDE (kernel 4.19.0-9-amd64) and Debian Live 10.5 KDE 
(kernel 4.19-0-10-amd64) both function as expected; sound is present from
the external speakers connected to the headphone jack from boot time,
unplugging from the headphone jack results in sound correctly switching
to the laptop's internal speakers, and replugging into the headphone
jack results in sound correctly switching back to the external speakers.

Debian Live 10.6 KDE and GNOME (both kernel 4.19.0-11-amd64) result in
no sound from the external speakers connected to the headphone jack from
boot time. The audio devices appear as expected in 'pavucontrol' and
'alsa-mixer'. Unplugging from the headphone jack results in sound 
correctly switching to the laptop's internal speakers; the sound works
as expected. Replugging the external speakers back into the headphone
jack once again results in no sound. 

I will attach the output of 'alsa-info' from the above Debian Live distros
in a follow-up. The below information is from Debian Live 10.6 KDE,
where I am running 'reportbug'.

As an aside I can confirm that this problem persists in 4.19.0-12 on my
(non-Live) installation, but I am only submitting information from Debian
Live distros 4.19.0-9 through -11. 

There may be relevant information in this Manjaro thread, although it is
referring to newer kernels:
https://forum.manjaro.org/t/sound-from-speakers-no-sound-from-3-5mm-jack-audio/5343


-- Package-specific info:
** Version:
Linux version 4.19.0-11-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.146-1 (2020-09-17)

** Command line:
BOOT_IMAGE=/live/vmlinuz-4.19.0-11-amd64 boot=live components splash quiet 
findiso=

** Not tainted

** Kernel log:
[7.958432] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[7.958433] RAPL PMU: hw unit of domain psys 2^-14 Joules
[7.959679] asus_wmi: ASUS WMI generic driver loaded
[7.961024] pstore: Using compression: deflate
[7.961032] pstore: Registered efi as persistent store backend
[7.974184] asus_wmi: Initialization: 0x1
[7.974204] asus_wmi: BIOS WMI version: 9.0
[7.974217] asus_wmi: SFUN value: 0x21
[7.974758] input: Asus WMI hotkeys as 
/devices/platform/asus-nb-wmi/input/input26
[7.974843] asus_wmi: Number of fans: 0
[7.982736] ACPI Warning: \_SB.IETM._TRT: Return Package has no elements 
(empty) (20180810/nsprepkg-96)
[7.986503] ACPI: AC Adapter [AC0] (on-line)
[7.991654] battery: ACPI: Battery Slot [BAT0] (battery present)
[8.055647] iTCO_vendor_support: vendor-support=0
[8.067558] idma64 idma64.0: Found Intel integrated DMA 64-bit
[8.069403] mei_me :00:16.0: enabling device ( -> 0002)
[8.077367] idma64 idma64.1: Found Intel integrated DMA 64-bit
[8.078986] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[8.079184] iTCO_wdt iTCO_wdt: can't request region for resource [mem 
0x00c5fffc-0x00c5]
[8.079187] iTCO_wdt: probe of iTCO_wdt failed with error -16
[8.108757] sd 0:0:0:0: Attached scsi generic sg0 type 0
[8.108792] sd 1:0:0:0: Attached scsi generic sg1 type 0
[8.231007] alg: No test for fips(ansi_cprng) (fips_ansi_cprng)
[8.364905] input: ELAN1203:00 04F3:307A Touchpad as 
/devices/pci:00/:00:15.1/i2c_designware.1/i2c-2/i2c-ELAN1203:00/0018:04F3:307A.0001/input/input28
[8.364982] hid-multitouch 0018:04F3:307A.0001: input,hidraw0: I2C HID v1.00 
Mouse [ELAN1203:00 04F3:307A] on i2c-ELAN1203:00
[8.389863] proc_thermal :00:04.0: enabling device ( -> 0002)
[8.390389] proc_thermal :00:04.0: Creating sysfs group for 
PROC_THERMAL_PCI
[8.602056] media: Linux media interface: v0.10
[8.613097] Bluetooth: Core ver 2.22
[8.613104] NET: Registered protocol family 31
[8.613105] Bluetooth: HCI device and connection manager initialized
[8.613107] Bluetooth: HCI socket layer initialized
[8.613108] Bluetooth: L2CAP socket layer initialized
[8.613111] Bluetooth: SCO socket layer initialized
[8.613473] snd_hda_intel :01:00.1: enabling device ( -> 0002)
[8.613513] snd_hda_intel :01:00.1: Disabling MSI
[8.613516] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[8.636977] usbcore: registered new interface driver btusb
[8.637858] Bluetooth: hci0: Firmware revision 0.1 build 130 week 44 2018
[8.658058] videodev: Linux video capture interface: v2.00
[8.659480] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC295: 
line_outs=1 (0x17/0x0/0x0/0x0/0x0) type:speaker
[8.659481] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[

Bug#976173: alsa-utils package should have dependency on pciutils package

[Kevin]

Package: alsa-utils
Version: 1.1.8-2
Severity: minor

The diagnostic script /usr/sbin/alsa-info will not run unless the lspci 
command is available. lspci is provided by the pciutils package. 

For example, Debian Live 10.6 KDE (the system I am running 'reportbug' on) 
includes alsa-utils but not pciutils, and running /usr/sbin/alsa-info 
results in the message:

This script requires lspci. Please install it, and re-run this script.



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

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

Versions of packages alsa-utils depends on:
ii  kmod  26-1
ii  libasound21.1.8-1
ii  libc6 2.28-10
ii  libfftw3-single3  3.3.8-2
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libsamplerate00.1.9-2
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  lsb-base  10.2019051400
ii  whiptail  0.52.20-8

alsa-utils recommends no packages.

alsa-utils suggests no packages.

-- no debconf information

Bug#976179: mirror submission for mirror.bizflycloud.vn

[Nguyen Trang]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.bizflycloud.vn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Maintainer: Nguyen Trang 
Country: VN Vietnam
Location: Vietnam
Sponsor: BizFly Cloud https://bizflycloud.vn/




Trace Url: http://mirror.bizflycloud.vn/debian/project/trace/
Trace Url: 
http://mirror.bizflycloud.vn/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://mirror.bizflycloud.vn/debian/project/trace/mirror.bizflycloud.vn

Bug#976172: xfonts-utils: fonttosfnt gives error "Couldn't select character map"

[Reuben Thomas]

Package: xfonts-utils
Version: 1:7.7+6
Severity: normal

It seems that the call to FT_Select_Charmap at read.c:231 does not work for
some fonts, at least. I tried it with a Latin-1 encoded BDF font.

By default, fonttosfnt wants to reencode as Unicode, which is fine. Freetype
finds the Latin-1 encoding of the BDF font, and thus decides it needs to be
reencoded, although for some reason it records the charmap as Unicode (which
is fine, being a superset of Latin-1).

The logic at read.c:228 then tries to select the ft_encoding_none charmap,
which is only valid for bitmap fonts with no encoding (reading the freetype
source, ftobjs.c:3512). But this bitmap font has an encoding, so it is not
allowed.

I think the test at line 228 is bogus: for a symbol font (i.e. one that
declares no encoding) it’s OK to use ft_encoding_none. Otherwise, if we’re
recoding (i.e. we have a mapping) then we should use ft_encoding_unicode. If
we’re in neither case, then we should just use the existing charmap, i.e.
not call FT_Select_Charmap. Hence, this stanza should look something like:

rc = 0; // In case we do nothing
if(symbol)
rc = FT_Select_Charmap(face, ft_encoding_none);
else if(mapping)
rc = FT_Select_Charmap(face, ft_encoding_unicode);

Of course in my case, the selection of a Charmap is a no-op, since it merely
reselects the only charmap in the font.

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

Kernel: Linux 5.4.0-54-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfonts-utils depends on:
ii  libc6 2.31-0ubuntu9.1
ii  libfontenc1   1:1.1.4-0ubuntu1
ii  libfreetype6  2.10.1-2ubuntu0.1
ii  x11-common1:7.7+19ubuntu14
ii  xfonts-encodings  1:1.0.5-0ubuntu1
ii  zlib1g1:1.2.11.dfsg-2ubuntu1.2

xfonts-utils recommends no packages.

xfonts-utils suggests no packages.

-- no debconf information

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Antoine Le Gonidec]

Le 30/11/2020 à 18:02, Mourad De Clerck a écrit :

Can you verify in "about:support" whether webrender is really disabled? I see:
* "Compositing: Basic"
* "WEBRENDER: disabled by user: User force-disabled WR"


Informations from the "WEBRENDER" tab are:
- available by default
- disabled by user: User force-disabled WR
- disabled by env: Not qualified

"Composition" is set to "Basic".

My add-ons installed from Debian repositories are still silently disabled on 
launch, I have to switch them off then on again to get them working for the 
current session. And of course start again when I restart Firefox.

It does not seem the disabling of webrender changed anything for me. Actually I 
did not check if it was in use before I force-disabled it.



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976178: ITP: cardano -- Cardano is a 3rd generation proof of stake decentralized blockchain platform

[Failfection]

Package: wnpp
Severity: wishlist
Owner: Failfection 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: cardano
  Version : 1.21.1
  Upstream Author : IOHK 
* URL : https://github.com/input-output-hk/cardano-node
* License : Apache-2.0
  Programming Lang: Haskell
  Description : Cardano is a 3rd generation proof-of-stake
decentralized blockchain platform

Cardano is a blockchain platform for changemakers, innovators, and
visionaries, with the tools and technologies required to create
possibility for the many, as well as the few, and bring about
positive global change. The aim is to build a financial system for
all developing countries and the world.

The cardano package contains everything needed to run a cardano node. This
integrates the ledger, ouroboros consensus, network/relay components.

Tools such as cardano-cli and cardano-node are included.

Remark: Package is currently maintained by the [FAIL] stake pool owner.
Github / site reference to be built and updated at
https://failfection.com/cardano. Also will be requesting a sponsor ideally
from haskell team.

Bug#976171: fmutils failed, breaking tex-common

[Vincent Lefevre]

Dup of bug 976170?

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

976170:

fmtutil [ERROR]: running `aleph -ini   -jobname=lamed -progname=lamed 
*lambda.ini  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#861180: HI

[Jennifer Peace]

Hello Dear friend,

It is my pleasure meeting you, I hope all is well with you and how are you
enjoying your day?

Bug#952959: netdata: Please package Netdata v1.25.0

[Marco d'Itri]

On Oct 09, Daniel Baumann  wrote:

> status update: I'll give it another go during this weekend to finish up
> stuff.
Did you make any progress? The freeze is getting close. :-(
Did you consider temporarily disabling the Go components?
I do not know much about Go either, OTOH I still successfully packaged 
some Go software without learning anything useful about the language!

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted

[Oxan van Leeuwen]

On 30-11-2020 19:28, Ansgar wrote:> I think we should keep the 
requirement.  Legacy init.d scripts are still

handled as conffiles and kept around even if the package is removed
(unlike systemd unit files).  Thus init scripts are still run[1] and
should behave sensibly.

For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors.  So the init script still needs to
do something sensible (probably just do nothing).


I don't think this requirement is necessary to handle that case. There 
is already a separate, explicit requirement for init scripts to not fail 
for removed-but-not-purged packages a few paragraphs before, and Policy 
explicitly states init scripts should use ``test -f daemon || exit 0''.



   [1]: For packages shipping native .service files for systemd, this
   might mean that for removed-but-not-purged packages suddenly the
   sysvinit script gets started?  After all there is no longer a .service
   files to prefer over the sysvinit script...


At least for packages using debhelper that's not the case, as 
dh_installsystemd (and its predecessor dh_systemd_enable) mask the 
service on package removal.


Cheers,
Oxan

Bug#976177: ghostscript: segfault in PDF->PNG conversion on big-endian triggered by ocrmypdf autopkgtest

[Stefano Rivera]

Package: ghostscript
Version: 9.53.0~~rc1~dfsg-1
Severity: normal
Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=703164

The ocrmypdf autopkgtest triggers a segfault on s390x, in
tests/test_graft:test_no_graphless_graft
https://github.com/jbarlow83/OCRmyPDF/blob/master/tests/test_graft.py#L16

Input file (input.pdf) attached.
Command: gs -dQUIET -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dFirstPage=3 
-dLastPage=3 -r300.00x300.00 -o output.png -sstdout=%stderr 
-dAutoRotatePages=/None -f input.pdf

I can't reproduce the issue on upstream git, with their bundled lcms2mt,
but once I delete that, then I can. Reproduced on s390x and ppc64.

The patch landed in response to
https://bugs.ghostscript.com/show_bug.cgi?id=703164 fixes the bug, but breaks
support for non-bundled lcms2, so that lead to
https://bugs.ghostscript.com/show_bug.cgi?id=703208

Cherry-picking these two commits should fix the bug:
1. 
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=bd48c43be5f736393372dffbad627ed6fc486238
2. 
https://github.com/stefanor/ghostpdl/commit/c988b051115c1fac4e0d7f4c1bd807646d83b1ec

SR
From 47d803266a4c83264779840280d58d458fc2402d Mon Sep 17 00:00:00 2001
From: Michael Vrhel 
Date: Fri, 20 Nov 2020 11:45:50 -0800
Subject: [PATCH 1/2] Bug 703164: Endian issues with CMM

The interface code to the CMM was corrected to indicate when a
endian swap was needed on the data.  This should only occur
in the case when we are dealing with transparency buffers
during the put image blending operation that may include
a color conversion.  The final blend bakes the data as BE
so if we are on a LE machine, the CMM will need to know to
swap the bytes (assuming the pdf14 device is using 16bit buffers).

The code was rewritten to make it clear that this setting is no
BE vs LE but simply an endian swap.  That was a source of confusion.

Revealed in this testing was the lack of some proper error
reporting during buffer conversions, which were fixed.
---
 base/gdevp14.c   | 57 
 base/gscms.h |  2 +-
 base/gsicc_cache.c   |  7 +
 base/gsicc_lcms2mt.c | 33 ++-
 base/gxblend.c   |  5 ++--
 base/gxblend.h   |  2 +-
 base/gxblend1.c  |  5 +++-
 base/gxi12bit.c  |  8 --
 base/gxicolor.c  |  8 --
 base/gxipixel.c  |  8 --
 base/gxiscale.c  | 18 ++---
 devices/vector/gdevxps.c |  4 ++-
 12 files changed, 94 insertions(+), 63 deletions(-)

diff --git a/base/gdevp14.c b/base/gdevp14.c
index 75e8fc71e..f161717e9 100644
--- a/base/gdevp14.c
+++ b/base/gdevp14.c
@@ -887,13 +887,14 @@ resolve_matte(pdf14_buf *maskbuf, byte *src_data, int src_planestride, int src_r
need to do the offset to our data in the buffer. Bug 700686: If we are in
a softmask that includes a matte entry, then we need to undo the matte
entry here at this time in the image's native color space not the parent
-   color space.   The big_endian term here is only set to true if the data
-   has been baked as such during the put_image blending operation.  */
+   color space.   The endian_swap term here is only set to true if the data
+   has been baked as BE during the put_image blending operation and we are
+   on a LE machine.  */
 static forceinline pdf14_buf*
 template_transform_color_buffer(gs_gstate *pgs, pdf14_ctx *ctx, gx_device *dev,
 pdf14_buf *src_buf, byte *src_data, cmm_profile_t *src_profile,
 cmm_profile_t *des_profile, int x0, int y0, int width, int height, bool *did_alloc,
-bool has_matte, bool deep, bool big_endian)
+bool has_matte, bool deep, bool endian_swap)
 {
 gsicc_rendering_param_t rendering_params;
 gsicc_link_t *icc_link;
@@ -913,6 +914,8 @@ template_transform_color_buffer(gs_gstate *pgs, pdf14_ctx *ctx, gx_device *dev,
 pdf14_buf *output = src_buf;
 pdf14_mask_t *mask_stack;
 pdf14_buf *maskbuf;
+int code;
+
 *did_alloc = false;
 
 /* Same profile */
@@ -970,10 +973,8 @@ template_transform_color_buffer(gs_gstate *pgs, pdf14_ctx *ctx, gx_device *dev,
 gsicc_init_buffer(_buff_desc, des_profile->num_comps, 1procs.map_buffer)(dev, icc_link, _buff_desc, _buff_desc,
 src_data, des_data);
 gsicc_release_link(icc_link);
+if (code < 0)
+return NULL;
 
 output->planestride = des_planestride;
 output->rowstride = des_rowstride;
@@ -1045,28 +1048,28 @@ static pdf14_buf*
 pdf14_transform_color_buffer_no_matte(gs_gstate *pgs, pdf14_ctx *ctx, gx_device *dev,
 pdf14_buf *src_buf, byte *src_data, cmm_profile_t *src_profile,
 cmm_profile_t *des_profile, int x0, int y0, int width, int height, bool *did_alloc,
-bool deep, bool big_endian)
+bool deep, bool endian_swap)
 {
 if (deep)
 return template_transform_color_buffer(pgs, ctx, dev, src_buf, src_data, src_profile,
-

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Josh Triplett]

On Mon, 30 Nov 2020 10:55:44 + Mark Hindley  wrote:
> On Sun, Nov 29, 2020 at 11:58:15PM +, Simon McVittie wrote:
> > On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:
> > > #921012 is about changing network-manager to Depend upon "default-logind |
> > > logind" rather than libpam-systemd
> > 
> > This is a change that is *sometimes* appropriate, but sometimes not,
> > depending on what facility the dependent package intends to receive
> > from the dependency. It needs to be assessed on a case-by-case basis,
> > and cannot be done mechanically across the distribution.
> > 
> > default-logind | logind is appropriate if the package's needs are
> > limited to "something that looks sufficiently similar to systemd-logind"
> > (like for example policykit-1, where I applied exactly that change),
> > but is not appropriate if it needs other systemd-specific facilities
> > (like for example dbus-user-session, which currently needs a working
> > `systemd --user` and has no way to function correctly otherwise).
> > 
> > I haven't fully investigated what facilities NM requires from
> > systemd. According to #921012 it requires hostnamed in its default
> > configuration, and according to the Gentoo wiki it expects to see
> > /etc/machine-id for DHCPv6. There might be others.
> 
> In my testing, network-manager works without issue using libpam-elogind. It 
> does
> not require 'systemd -- user' and falls back to legacy implementations if
> hostnamed is not available.

Which would then make those legacy fallbacks load-bearing, when they
previously were not. If (hypothetically) network-manager upstream
decided to remove those legacy fallbacks, the maintainer would then be
in a position of either:

1) not noticing, and having users experience breakage that could have
been foreseen, in addition to one of the following two options,

2) changing the dependency accordingly to reflect the new hard
requirement on hostnamed, and potentially finding themselves hauled in
front of the TC *yet again*, or

3) maintaining a downstream patch forever. This would, again, put
someone in the position of having to maintain support for alternative
init systems, which the GR does not require any maintainer to do. And
keep in mind that rebasing patches for new upstream versions isn't
typically work that can be offloaded, even if someone were willing to do
so; the nature of such work is that it typically has to be done all at
once.

This would be a much more reasonable request if the alternative
implementations provided a version of hostnamed (and anything else
network-manager relies on), such that network-manager could
transparently rely on such functionality without having to implement a
fallback itself. With the fallback code provided within the alternative
implementations themselves, that would ensure that any bug reports on
that fallback code would *also* be the responsibility of the alternative
implementations.

> > I think we have three options:
> > 
> > * overrule the NM maintainer on both #921012 (logind dependency) and
> >   #964139 (init script inclusion) as you ask;
> > * decline to overrule the NM maintainer on either point;
> > * overrule the NM maintainer on #921012 but do not overrule on #964139, and
> >   instead expect the init script to be provided by some other package that
> >   is maintained by people who are interested in non-systemd init systems
> > 
> > I don't think it would make any sense to overrule on #964139 but
> > not on #921012, because if NM depends on libpam-systemd (which
> > requires/assumes systemd as pid 1), then people who want to use non-default
> > init systems will remain equally unable to use NM. Do you agree?
> 
> I agree fully. However I would also propose the inverse logic: #921012 appears
> to be resolvable in that NM works with elogind without problems and 
> exploration
> of alternative technologies such as elogind was explicitly included in the
> winning GR option. But to overrule #921012 but not #964139 would also make
> people who want to use non-default init systems still equally unable to use 
> NM.

Only until, as observed in the mail you're replying to, someone
interested in an alternative init system implements a solution for:
> putting init-system integration in a place where the maintenance
> responsibility and effort rests with those who are interested in
> supporting the relevant init system.

Bug#976166: mmdebstrap 0.7.2-3: problems with the "--include" option

[Johannes Schauer]

Hi Karsten,

Quoting Karsten Merker (2020-11-30 20:55:45)
> Do you have any idea what could be going wrong here?

thanks a lot for your extensive bug report! The problem was introduced just
recently when I tried to source the packages with a certain priority only from
the suite given as a CLI argument. Here, the value you set with --include gets
overwritten:

https://sources.debian.org/src/mmdebstrap/0.7.2-3/mmdebstrap/#L2099

And this happens only when you mix more than one Packages file -- which happens
to be the case for Debian ports because arch-any and arch-all Packages files
are split. Here is how to trigger the bug without Debian ports and with my
native architecture (amd64):

$ mmdebstrap --customize-hook='chroot "$1" dpkg -l | grep doc-debian' \
--include=doc-debian unstable /dev/null \
"deb http://deb.debian.org/debian/ sid main" \
"deb http://deb.debian.org/debian/ unstable main"

This will fail because the "grep" in --customize-hook will fail and thus
confirm the fact that doc-debian didn't get installed as requested.

I will create a test case for this to prevent this from happening in the future
and fix the bug asap.

Thank you! :)

cheers, josch

signature.asc
Description: signature

Bug#975977: tor generates invalid adress for hiddenservice when runninf on armv5tel architectures

[jfparis]

On Mon, Nov 30, 2020 at 01:29:04PM +, Peter Palfrader wrote:
> On Fri, 27 Nov 2020, Jean-Francois Paris wrote:
> 
> > I believe that tor generates invalid hidden service onion addresses when 
> > running on armv5tel platform
> 
> I don't have access to an armv5tel system, but at least running armel on
> ARMv7 cpus (both abel.d.o and harries.d.o) I cannot reproduce this
> issue.

Hi peter

I replayed the below. 
the shasum is matching
however I have the following hostname
upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyac43yd.onion

It is not going to be easy to fix if you cannot replicate. Let me know if I can 
help

Regards

jf


> 
> Here's what I tried:
> 
> } [sid_armel-dchroot] weasel@harris:~$ cat torrc
> } HiddenServiceDir /home/weasel/hs
> } HiddenServicePort 80 127.0.0.1:8080
> 
> } [sid_armel-dchroot] weasel@harris:~$ mkdir hs
> } [sid_armel-dchroot] weasel@harris:~$ chmod go-rwx -R hs
> } [sid_armel-dchroot] weasel@harris:~$
> 
> } [sid_armel-dchroot] weasel@harris:~$ echo 
> 'PT0gZWQyNTUxOXYxLXNlY3JldDogdHlwZTAgPT0AAACg6zoxlQ2hy7C6fUoTgIa0GLMk/YdVs2ic6jUDCzztZeLWcfqwCQ5/KoPk9v99cuWKO5mNpVrDtbOc27UUyC7e'
>  | base64 -d > hs/hs_ed25519_secret_key
> 
> } [sid_armel-dchroot] weasel@harris:~$ echo 
> '6bff2f57fcd69049091dcfa42b08fb84919d60dac919cbb16e3df1d960bb7843  
> ./hs/hs_ed25519_secret_key' | sha256sum -c
> } ./hs/hs_ed25519_secret_key: OK
> 
> 
> } [sid_armel-dchroot] weasel@harris:~$ /usr/sbin/tor -f torrc Log 'info 
> stdout'
> } # And kill it using ^C after a few seconds
> 
> And then I get
> } [sid_armel-dchroot] weasel@harris:~$ cat hs/hostname
> } upxkcswnvepfls7vcy5vuixy54hlugfjnzhvl5ygfbjtm7znkyahcvad.onion
> 
> on armel, armhf, and also amd64.
> 
> 
> -- 
> |  .''`.   ** Debian **
>   Peter Palfrader   | : :' :  The  universal
>  https://www.palfrader.org/ | `. `'  Operating System
> |   `-https://www.debian.org/

Bug#976091: closed by Debian FTP Masters (reply to Andrej Shadura ) (Bug#976091: fixed in wpa 2:2.9.0-16)

[Jérôme de Bretagne]

Thank you so much for your reactivity and this updated version, I can
confirm it has fixed the issue indeed.

Bug#903428: deduplicating jquery/

[Craig Small]

Hi,
  WordPress has a bunch of these dependencies which float in and out of
lining up between what Debian has and what upstream WordPress uses. As an
added bonus, they sometimes slightly adjust their copies.
I use lintian overrides and dh-linktree and this helps, but the result is
less than good and often just means WordPress ships with its own copies of
javascript libraries.

It makes me rather sad, but fixing it would cost a lot of time (and also
what Russ said, which was a good summary of the problem) so I don't see a
good solution.
But if you ever find one, I'll gladly update WordPress to use it :)

 - Craig

Bug#976159: xfonts-utils: bdftopcf(1) documentation of some flags is misleading

[Reuben Thomas]

Package: xfonts-utils
Version: 1:7.7+6
Severity: normal

The -t and -i flags for bdftopcf are documented thus:

   -t  When this option is specified, bdftopcf will convert fonts into 
"terminal" fonts when possible.  A terminal
   font has each glyph image padded to the same size; the X server 
can usually render these types of fonts
   more quickly.

   -i  This option inhibits the normal computation of ink metrics.  
When a font has glyph images which do not fill
   the bitmap image (i.e., the "on" pixels don't extend to the 
edges of the metrics) bdftopcf computes the
   actual ink metrics and places them in the .pcf file; the -t 
option inhibits this behaviour.

However, looking at the source code bdftopcf.c, they are both parsed, but
ignored. I suggest changing the man page to read:

   -t, -i  Ignored.

Further, it may be worth patching the code, as currently it reads:

case 't':  /* attempt to make terminal fonts if possible */
if (argv[0][2] != '\0')
goto usage;
break;

case 'i':  /* inhibit ink metric computation */
if (argv[0][2] != '\0')
goto usage;
break;

It might make sense to add a “TODO:” at the start of each comment.

Further investigation might reveal that the flags used to do something, but
the above changes would at least help reduce confusion without prejudice to
(unlikely?) future improvements.

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

Kernel: Linux 5.4.0-54-generic (SMP w/16 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfonts-utils depends on:
ii  libc6 2.31-0ubuntu9.1
ii  libfontenc1   1:1.1.4-0ubuntu1
ii  libfreetype6  2.10.1-2ubuntu0.1
ii  x11-common1:7.7+19ubuntu14
ii  xfonts-encodings  1:1.0.5-0ubuntu1
ii  zlib1g1:1.2.11.dfsg-2ubuntu1.2

xfonts-utils recommends no packages.

xfonts-utils suggests no packages.

-- no debconf information

Bug#954403: joblib: configuration error installing python3-joblib

[Sebastian Ramacher]

Control: reassign -1 python3-minimal 3.8.6-1
Control: affects -1 src:joblib

On 2020-03-21 11:25:31 +0200, Graham Inggs wrote:
> Source: joblib
> Version: 0.14.0-3
> Severity: serious
> Control: affects -1 src:spades src:circlator
> 
> Hi Maintainer
> 
> While attempting to run the autopkgtests triggered by python3-defaults
> for spades [1] and circlator [2], python3-joblib fails to install with
> the following error:
> 
> Setting up python3-joblib (0.14.0-3) ...
> ...
>   File 
> "/usr/lib/python3/dist-packages/joblib/test/test_func_inspect_special_encoding.py",
> line 0
> SyntaxError: unknown encoding: big5
> 
> dpkg: error processing package python3-joblib (--configure):
>  installed python3-joblib package post-installation script subprocess
> returned error exit status 1

That's not an issue in joblib, but in py3compile. If python3.X is
installed, everything works as expected as one can see in the
statsmodels and scikit-learn tests. Compilation fails if
python3.X-minimal is installed, but python3.X is not. Then some module
handling encoding is not installed and py3compile fails.

One can easily reproduce this issue in current unstable with
python3.8-minimal installed and python3.8 removed. In the autopkgtests
of circlator and spades we also see

The following packages were automatically installed and are no longer required:
  libpython3.8-minimal python3.8-minimal
Use 'apt autoremove' to remove them.

Reassigning to python3-minimal which contains py3compile. Not sure what
the best option here is to fix in py3compile, but ignoring that
particular error would be a start. A file without bytecode would be
better than installation failure in this case.

Cheers

> 
> I've set the severity serious as this blocks the migration of
> python3-defaults with Python 3.8 as default.
> 
> Regards
> Graham
> 
> 
> [1] 
> https://ci.debian.net/user/britney/jobs?package=spades[]=testing[]=amd64
> [2] 
> https://ci.debian.net/user/britney/jobs?package=circlator[]=testing[]=amd64

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#976104: openvpn enforces suppress-timestamps in systemd even with log-append inside config

[Bernhard Schmidt]

On Sun, Nov 29, 2020 at 08:11:09PM +0100, Josip Rodin wrote:

Dear Josip,

> For some reason, the systemd unit config shipped by openvpn in
> /lib/systemd/system/openvpn-server@.service says --suppress-timestamps, but
> then a log-append inside the server config file logs no timestamps there,
> either, which doesn't make much sense.
> 
> What would be the reason for this, can it be removed or worked around
> somehow, please?
> 
> I see the same file content is present in 2.4.7-1, too.

openvpn-server@.service and openvpn-client@.service are maintained by
upstream, I guess the reason is to have them logged properly by systemd
instead of log-append. If you want to change this I suggest to talk to
upstream or override it locally.

The openvpn@.service unit that Debian has "always" shipped does not set
this option (yes this duplication is somewhat unfortunate).

Bernhard

Bug#976070: openvpn fails with iproute option

[Bernhard Schmidt]

On Sun, Nov 29, 2020 at 11:05:36AM +0100, Glennie Vignarajah wrote:

Hi,

> Hello,
> In order to use openvpn with non root priviliges, iproute is need as
> state in openvpn's howto document [1]. By default, iproute is disabled
> on compile time and needs to enabled with ``--enable-iproute2``.
> 
> Could you, please, rebuild the openvpn package with this option?
> 
> Many thaks and kind regards
> 
> 1: https://community.openvpn.net/openvpn/wiki/HOWTO#UnprivilegedmodeLinuxonly

Upstream actually suggested to drop iproute2 and use the newer netlink
based approach.

---
Netlink support
On Linux, if configured without ``--enable-iproute2``, configuring IP
addresses and adding/removing routes is now done via the netlink(3)
kernel interface.  This is much faster than calling ``ifconfig`` or
``route`` and also enables OpenVPN to run with less privileges.
---

However, there is a bug over with ArchLinux that suggests this does not
work out-of-the-box when you set User/Group in the configuration as
opposed to setting it in the systemd unit

https://bugs.archlinux.org/task/68480

(did not load for me at the moment, Google Cache helped)

Could you try a fix similar to the one Arch used in 

https://github.com/archlinux/svntogit-packages/commit/a871e4297bb73be9c9f5eeb33630b24766366ac5#diff-d7067e90cf384bf5e9e8791cc82be773e5bce9152438b1b51ae424b0c111d1fc

That is, set the user inside the systemd unit instead of in the openvpn
config and add AmbientCapabilities?

Bernhard

Bug#976170: tex-common: Problem installation in update.

[Santiago José López Borrazás]

El 30/11/20 a las 22:42, Norbert Preining escribió:
reassign 976170 texlive-latex-base retitle 976170 lamed format gone,  > needs to break against old texlive-formats-extra thanks > > Hi Hilmar, > 
> lamed format is not supported anymore, see svn 56521 of tl, or > 
https://git.texlive.info/texlive/commit/?id=534911737e36bfcec8bad990f0b7245ce2902758 
> > since aleph (engine) does not support the necessary commands.
 > We need to add a Breaks: texlive-formats-extra (<< 2020.20201129) to > 
texlive-latex-base so that the latex-base is only updated together > with 
formats-extra, from where the lamed format should disappear. > > OK. The 
problem,indeed, it is in the affected package that you indicate.


It didn't count that it would affect tex-latex-base than anything else.


--
Saludos de Santiago José López Borrazás.
Enviando desde Mozilla Thunderbird.

Bug#976175: blhc: false positive "NONVERBOSE BUILD" for waf-builds

[IOhannes m zmoelnig]

Package: blhc
Version: 0.12-2
Severity: normal

Dear Maintainer,

the blhc pipeline on salsa fails for me, with a "NONVERBOSE BUILD" error
message.

https://salsa.debian.org/multimedia-team/ardour/-/jobs/1188803

E.g. it reports an error like:
> 20288:NONVERBOSE BUILD: [ 763/1064] Compiling gtk2_ardour/vca_master_strip.cc

However, the build is indeed verbose, but as the build-system of the package in
question is WAF, the compiler/linker flags are output as python lists (that are
used to build the actual command) rather than the command itself.

E.g.

```sh
$ sed -n '20288,+1p' debian/output/ardour_6.5.0+ds0-1+salsaci_amd64.build
[ 763/1064] Compiling gtk2_ardour/vca_master_strip.cc
23:24:09 runner ['/usr/lib/ccache/g++', 
'-I/builds/multimedia-team/ardour/debian/output/source_dir', '-g', '-O2', 
'-fdebug-prefix-map=/builds/multimedia-team/ardour/debian/output/source_dir=.', 
'-fstack-protector-strong', '-Wformat', '-Werror=format-security', 
'-I/usr/include/qm-dsp', '-DHAVE_RF64_RIFF', '-DWAF_BUILD', '-DNDEBUG', 
'-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', 
'-fstrength-reduce', '-pipe', '-DARCH_X86', '-mmmx', '-msse', '-mfpmath=sse', 
'-DUSE_XMMINTRIN', '-DBUILD_SSE_OPTIMIZATIONS', '-DLXVST_64BIT', '-Wall', 
'-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', 
'-DBOOST_SYSTEM_NO_DEPRECATED', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', 
'-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="6"', 
'-std=c++11', '-DBOOST_NO_AUTO_PTR', '-Woverloaded-virtual', 
'-Wno-unused-local-typedefs', '-D__STDC_LIMIT_MACROS', 
'-D__STDC_FORMAT_MACROS', '-DCANVAS_COMPATIBILITY', '-DCANVAS_DEBUG', 
'-DBOOST_ERROR_CODE_HEADER_ONLY', '-pthread', '-pthread', '-pthread', 
'-pthread', '-pthread', '-pthread', '-pthread', '-Igtk2_ardour', 
'-I../gtk2_ardour', '-Ilibs', '-I../libs', '-Ilibs/vst3', '-I../libs/vst3', 
'-Ilibs/surfaces/control_protocol', '-I../libs/surfaces/control_protocol', 
'-Ilibs/surfaces/control_protocol/control_protocol', 
'-I../libs/surfaces/control_protocol/control_protocol', '-Ilibs/waveview', 
'-I../libs/waveview', '-Ilibs/ardour', '-I../libs/ardour', '-Ilibs/midi++2', 
'-I../libs/midi++2', '-Ilibs/evoral', '-I../libs/evoral', 
'-Ilibs/audiographer', '-I../libs/audiographer', '-Ilibs/audiographer/src', 
'-I../libs/audiographer/src', '-Ilibs/ptformat', '-I../libs/ptformat', 
'-Ilibs/canvas', '-I../libs/canvas', '-Ilibs/widgets', '-I../libs/widgets', 
'-Ilibs/gtkmm2ext', '-I../libs/gtkmm2ext', '-Ilibs/pbd', '-I../libs/pbd', 
'-Ilibs/evoral/libsmf', '-I../libs/evoral/libsmf', '-Ilibs/temporal', 
'-I../libs/temporal', '-Ilibs/lua', '-I../libs/lua', '-Ilibs/zita-resampler', 
'-I../libs/zita-resampler', '-Ilibs/zita-convolver', 
'-I../libs/zita-convolver', '-I/usr/include/uuid', '-I/usr/include/freetype2', 
'-I/usr/include/libpng16', '-I/usr/include/glibmm-2.4', 
'-I/usr/lib/x86_64-linux-gnu/glibmm-2.4/include', '-I/usr/include/glib-2.0', 
'-I/usr/lib/x86_64-linux-gnu/glib-2.0/include', '-I/usr/include/sigc++-2.0', 
'-I/usr/lib/x86_64-linux-gnu/sigc++-2.0/include', '-I/usr/include/gtk-2.0', 
'-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include', '-I/usr/include/pango-1.0', 
'-I/usr/include/atk-1.0', '-I/usr/include/gdk-pixbuf-2.0', 
'-I/usr/include/libmount', '-I/usr/include/blkid', '-I/usr/include/fribidi', 
'-I/usr/include/cairo', '-I/usr/include/pixman-1', '-I/usr/include/harfbuzz', 
'-I/usr/include/x86_64-linux-gnu', '-I/usr/include/gtkmm-2.4', 
'-I/usr/lib/x86_64-linux-gnu/gtkmm-2.4/include', '-I/usr/include/atkmm-1.6', 
'-I/usr/include/gtk-unix-print-2.0', '-I/usr/include/gdkmm-2.4', 
'-I/usr/lib/x86_64-linux-gnu/gdkmm-2.4/include', '-I/usr/include/giomm-2.4', 
'-I/usr/lib/x86_64-linux-gnu/giomm-2.4/include', '-I/usr/include/pangomm-1.4', 
'-I/usr/lib/x86_64-linux-gnu/pangomm-1.4/include', 
'-I/usr/include/cairomm-1.0', 
'-I/usr/lib/x86_64-linux-gnu/cairomm-1.0/include', '-I/usr/include/taglib', 
'-I/usr/include/libxml2', '-I/usr/include/lilv-0', '-I/usr/include/sratom-0', 
'-I/usr/include/sord-0', '-I/usr/include/serd-0', '-I/usr/include/raptor2', 
'-I/usr/include/suil-0', 
'-I/builds/multimedia-team/ardour/debian/output/source_dir/build', 
'-DINTERNAL_SHARED_LIBS=1', '-DUSE_EXTERNAL_LIBS=1', '-DHAVE_ALSA=1', 
'-DHAVE_PULSEAUDIO=1', '-DHAVE_GLIB=1', '-DHAVE_GTHREAD=1', '-DHAVE_GLIBMM=1', 
'-DHAVE_SNDFILE=1', '-DHAVE_GIOMM=1', '-DHAVE_CURL=1', '-DHAVE_ARCHIVE=1', 
'-DHAVE_LO=1', '-DHAVE_TAGLIB=1', '-DHAVE_VAMPSDK=1', '-DHAVE_VAMPHOSTSDK=1', 
'-DHAVE_RUBBERBAND=1', '-DEXPORT_VISIBILITY_HIDDEN=0', '-DENABLE_NLS=1', 
'-DLXVST_SUPPORT=1', '-DVST3_SUPPORT=1', '-DPTFORMAT=1', 
'-DCONFIG_ARCH="x86_64"', '-DHAVE_TOOLS_SANITY_CHECK=1', 
'-DHAVE_TOOLS_GCCABICHECK=1', '-DHAVE_LIBS_CLEARLOOKS_NEWER=1', 
'-DHAVE_LIBFLUIDSYNTH=1', '-DHAVE_LIBS_FLUIDSYNTH=1', '-DHAVE_HIDAPI=1', 
'-DHAVE_LIBS_HIDAPI=1', '-DHAVE_LIBLTC=1', '-DHAVE_LIBS_LIBLTC=1', 
'-DHAVE_LIBS_LUA=1', '-DHAVE_LIBS_PTFORMAT=1', '-DHAVE_BASE_PITCH_H=1', 
'-DHAVE_LIBS_QM_DSP=1', '-DHAVE_FFTW3F=1', 

Bug#976174: ITP:papershaper--automagic wallpaper swapper

[Devops PK Carlisle LLC]

Package: wnpp
Severity: wishlist
Owner: Devops PK Carlisle LLC 
X-Debbugs-Cc: debian-de...@lists.debian.org, dev...@pkcarlisle.com

* Package name: papershaper
* URL : https://github.com/pkcarlislellc/git-papershaper
* License : LGPL-3+
  Programming Lang: Python
  Description : automagic wallpaper swapper

Papershaper automatically changes wallpaper from either locally stored
images,from webcams, or both. User chooses how often Papershaper updates
wallpaper.

Originally written in Python 2, now updated to default to Python 3
(Python 2 code is still included for those who want it).

Available for download at https://github.com/pkcarlislellc/git-papershaper

Available as a tar.gz from https://sourceforge.net/projects/papershaper/

Fully documented at both of these sources.

Bug#976170: tex-common: Problem installation in update.

[Norbert Preining]

reassign 976170 texlive-latex-base
retitle 976170 lamed format gone, needs to break against old 
texlive-formats-extra
thanks

Hi Hilmar,

lamed format is not supported anymore, see svn 56521 of tl, or
https://git.texlive.info/texlive/commit/?id=534911737e36bfcec8bad990f0b7245ce2902758
since aleph (engine) does not support the necessary commands.

We need to add a 
Breaks: texlive-formats-extra (<< 2020.20201129)
to texlive-latex-base so that the latex-base is only updated together
with formats-extra, from where the lamed format should disappear.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#903428: deduplicating jquery/

[Wookey]

I was just updating a package and got the using lintian grumbling that
javadoc has added 1.3MB of jquery to my package (almost doubling its
installed size).

There are 5 of these on my system (I'm surprised its not more
actually, surely some people must have tens or hundreds of these as
both doxygen and javadoc do this?).

Having read #903428 I see there is no enthusiasm for fixing this in
the tooling. And also that I am not the only person coming across this
and wondering what to do about it. I've had this experience before
with both doxygen and javadoc and have spent some years assuming that
someone will sort this out eventually.

Whilst I agree that having a local jquery in each such set of docs is
not that big a deal, do we not potetially end up with an awful lot of
them across the distro so maybe it is worth taking more seriously? If
it really is only 5 on everyone's machines then I guess we can live
with that.

Given that the maintainers of both javadoc and doxygen have declared
this "wontfix" should we not at least stop lintian complaining about
it? Unless the project disgrees with the maintainers decisions here it
seems perverse to continue to mark this as an issue.

And also at least document some dh runes for doing the necesarry
symlinking to use the system copy so that packagers can just find the
"standard solution" and use that without having to read a great long
bug report, find that everyone has thrown up their hands, and write
pleading mails :-) (Acompanied by a note about the practical risk of
incompatible version changes over time - I know I don't know how much
I should worry about that in practice (given that my inclination is to
use the system version, because I'm much more bothered about the
duplication than the problem that the search function in the API docs
for an obscure package might stop working one day ...)

This feels like the sort of makework we used to be better at dealing
with. Am I just getting grumpy in my old age?

Perhaps there are docs for packagers on this somewhere, in which case can
someone reply so they are in the bug report. Cheers.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Bug#957184: eurephia: diff for NMU version 1.1.0-6.1

[Alberto Gonzalez Iniesta]

Hi, Sudip.

Thanks for the upload. No need to cancel it :-)

On Mon, Nov 30, 2020 at 08:52:30PM +, Sudip Mukherjee wrote:
> Control: tags 957184 + patch
> Control: tags 957184 + pending
> --
> 
> Dear maintainer,
> 
> I've prepared an NMU for eurephia (versioned as 1.1.0-6.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should cancel it.
> 
> --
> Regards
> Sudip
> 
> diff -Nru eurephia-1.1.0/debian/changelog eurephia-1.1.0/debian/changelog
> --- eurephia-1.1.0/debian/changelog   2016-09-16 08:38:26.0 +0100
> +++ eurephia-1.1.0/debian/changelog   2020-11-30 20:44:45.0 +
> @@ -1,3 +1,11 @@
> +eurephia (1.1.0-6.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Fix ftbfs with GCC-10. (Closes: #957184)
> +- Use fcommon with CFLAGS.
> +
> + -- Sudip Mukherjee   Mon, 30 Nov 2020 20:44:45 
> +
> +
>  eurephia (1.1.0-6) unstable; urgency=medium
>  
>* Make build reproducible. Thanks Chris Lamb for the patch!
> diff -Nru eurephia-1.1.0/debian/rules eurephia-1.1.0/debian/rules
> --- eurephia-1.1.0/debian/rules   2015-07-07 16:04:12.0 +0100
> +++ eurephia-1.1.0/debian/rules   2020-11-29 22:27:12.0 +
> @@ -3,7 +3,7 @@
>   dh $@
>  
>  override_dh_auto_configure:
> - $(shell DEB_CFLAGS_MAINT_APPEND="-fPIC -std=gnu89" dpkg-buildflags 
> --export=configure) ./configure --prefix /usr --plug-in --fw-iptables 
> --db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm --openvpn-src 
> /usr/include/openvpn
> + $(shell DEB_CFLAGS_MAINT_APPEND="-fPIC -std=gnu89 -fcommon" 
> dpkg-buildflags --export=configure) ./configure --prefix /usr --plug-in 
> --fw-iptables --db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm 
> --openvpn-src /usr/include/openvpn
>  override_dh_auto_clean:
>   rm -rf configure.log
>   dh_auto_clean

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#957228: freebirth: diff for NMU version 0.3.2-9.3

[Sudip Mukherjee]

Control: tags 957228 + patch
Control: tags 957228 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -u freebirth-0.3.2/debian/changelog freebirth-0.3.2/debian/changelog
--- freebirth-0.3.2/debian/changelog
+++ freebirth-0.3.2/debian/changelog
@@ -1,3 +1,11 @@
+freebirth (0.3.2-9.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957228)
+- Use fcommon with CFLAGS.
+
+ -- Sudip Mukherjee   Mon, 30 Nov 2020 20:56:31 
+
+
 freebirth (0.3.2-9.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u freebirth-0.3.2/debian/rules freebirth-0.3.2/debian/rules
--- freebirth-0.3.2/debian/rules
+++ freebirth-0.3.2/debian/rules
@@ -5,7 +5,7 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
-CFLAGS=-g -Wall $(shell pkg-config --cflags gtk+-2.0) $(shell dpkg-buildflags 
--get CFLAGS)
+CFLAGS=-g -Wall $(shell pkg-config --cflags gtk+-2.0) $(shell dpkg-buildflags 
--get CFLAGS) -fcommon
 LDFLAGS=$(shell pkg-config --libs gtk+-2.0) $(shell dpkg-buildflags --get 
LDFLAGS)
 
 # Handle DEB_BUILD_OPTIONS

Bug#957184: eurephia: diff for NMU version 1.1.0-6.1

[Sudip Mukherjee]

Control: tags 957184 + patch
Control: tags 957184 + pending
--

Dear maintainer,

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

--
Regards
Sudip

diff -Nru eurephia-1.1.0/debian/changelog eurephia-1.1.0/debian/changelog
--- eurephia-1.1.0/debian/changelog 2016-09-16 08:38:26.0 +0100
+++ eurephia-1.1.0/debian/changelog 2020-11-30 20:44:45.0 +
@@ -1,3 +1,11 @@
+eurephia (1.1.0-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957184)
+- Use fcommon with CFLAGS.
+
+ -- Sudip Mukherjee   Mon, 30 Nov 2020 20:44:45 
+
+
 eurephia (1.1.0-6) unstable; urgency=medium
 
   * Make build reproducible. Thanks Chris Lamb for the patch!
diff -Nru eurephia-1.1.0/debian/rules eurephia-1.1.0/debian/rules
--- eurephia-1.1.0/debian/rules 2015-07-07 16:04:12.0 +0100
+++ eurephia-1.1.0/debian/rules 2020-11-29 22:27:12.0 +
@@ -3,7 +3,7 @@
dh $@
 
 override_dh_auto_configure:
-   $(shell DEB_CFLAGS_MAINT_APPEND="-fPIC -std=gnu89" dpkg-buildflags 
--export=configure) ./configure --prefix /usr --plug-in --fw-iptables 
--db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm --openvpn-src 
/usr/include/openvpn
+   $(shell DEB_CFLAGS_MAINT_APPEND="-fPIC -std=gnu89 -fcommon" 
dpkg-buildflags --export=configure) ./configure --prefix /usr --plug-in 
--fw-iptables --db-sqlite3 --sqlite3-path /var/lib/eurephia --eurephiadm 
--openvpn-src /usr/include/openvpn
 override_dh_auto_clean:
rm -rf configure.log
dh_auto_clean

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Antoine Le Gonidec]

Le 29/11/2020 à 16:25, Mourad De Clerck a écrit :

As a workaround, I disabled webrender using "gfx.webrender.force-disabled" set to 
"true", and my extensions (ublock, bitwarden) seem to work properly again.


Did you check that the add-ons are still active after a couple restarts of 
Firefox?
The suggested workaround seems to have no effect here.

All installed from Debian Sid repositories:
- Firefox 83.0-1
- webext-ublock-origin-firefox 1.30.0+dfsg-1
- webext-umatrix 1.4.0+dfsg-1



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976169: psi4: autopkgtest regression in testing: ImportError: cannot import name 'core' from partially initialized module 'psi4'

[Paul Gevers]

Source: psi4
Version: 1:1.3.2-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

With a recent change in testing (I believe the added support of
Python3.9) the autopkgtest of psi4 started to fail. I copied some of the
output at the bottom of this report. Can you please investigate the
situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/p/psi4/8534048/log.gz

autopkgtest [19:22:54]: test testsuite.sh: [---
Running test simint/scf5... Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 55, in 
from . import core
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/psi4", line 177, in 
import psi4
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 60, in 
raise ImportError("{0}".format(err))
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)
FAILED
LOG:


2020-11-30 19:22
Skipping test gcp/hf3c
Running test python/energy... Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 55, in 
from . import core
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/psi4", line 177, in 
import psi4
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 60, in 
raise ImportError("{0}".format(err))
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)
FAILED
LOG:


2020-11-30 19:22
Skipping test v2rdm_casscf/v2rdm3
Skipping test cfour/sp-rhf-ccsd_t_
Running test sapt1... Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 55, in 
from . import core
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/psi4", line 177, in 
import psi4
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 60, in 
raise ImportError("{0}".format(err))
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)
FAILED
LOG:


2020-11-30 19:22
Skipping test libefp/qchem-qmefp-sp
Skipping test dftd3/energy
Running test erd/scf5... Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 55, in 
from . import core
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/psi4", line 177, in 
import psi4
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 60, in 
raise ImportError("{0}".format(err))
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)
FAILED
LOG:


2020-11-30 19:22
Running test scf-property... Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 55, in 
from . import core
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/psi4", line 177, in 
import psi4
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 60, in 
raise ImportError("{0}".format(err))
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely due to a circular import)
(/usr/lib/x86_64-linux-gnu/psi4/__init__.py)
FAILED
LOG:


2020-11-30 19:22
Skipping test mrcc/ccsdt
Running test dfmp2-1... Traceback (most recent call last):
  File "/usr/lib/x86_64-linux-gnu/psi4/__init__.py", line 55, in 
from . import core
ImportError: cannot import name 'core' from partially initialized module
'psi4' (most likely 

Bug#976060: Migrate to udd-mirror.debian.net

[Markus Koschany]

Thanks for the patch Asheesh!


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

Bug#976168: apt: Typo when updating/installing packages

[Miquel Ortega]

Package: apt
Version: 2.1.11
Severity: minor
Tags: l10n

Dear Translator,

When installing a new package, apt issues the following warning:

Després d'aquesta operació saran 2.140 MB d'espai en disc addicional

This has a spelling mistake (saran). The same happens when updating packages.

Many thanks,
Miquel



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-.*-5\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-.*-5\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-.*-5\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-.*-5\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.9\.0-3-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.9\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.9\.0-3-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; 
fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "false";
APT::Compressor::zstd::Cost "60";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir 

Bug#969074: [PATCH] d/p/lp-1894129-*: fix FTBFS (LP: #1894129 Closes: #969074)

[Paul Gevers]

Hi all, Christian,

On Tue,  8 Sep 2020 15:40:11 +0200 Christian Ehrhardt
 wrote:
> Signed-off-by: Christian Ehrhardt 
> ---
>  ...raseReserved-override-driver-queue_p.patch |  74 
>  ...BlockEraseReserved-skip-unless-iSCSI.patch |  39 
>  ...e-Write-override-driver-queue_pdu-ca.patch |  71 
>  ...e-Write-skip-InvalidDataOutSize-unle.patch |  39 
>  ...EraseReserved-override-driver-queue_.patch |  74 
>  ...ryptoEraseReserved-skip-unless-iSCSI.patch |  39 
>  ...iteReserved-override-driver-queue_pd.patch |  68 +++
>  ...-test-tool-Use-extern-int-in-headers.patch |  58 ++
>  ...mdSnTooHigh-override-driver-queue_pd.patch |  68 +++
>  ...mdSnTooLow-override-driver-queue_pdu.patch |  69 
>  ...ataSnInvalid-override-driver-queue_p.patch | 166 ++
>  ...-unused-iscsi_queue_pdu-symbol-overl.patch | 104 +++
>  debian/patches/series |  12 ++
>  13 files changed, 881 insertions(+)
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-BlockEraseReserved-override-driver-queue_p.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-BlockEraseReserved-skip-unless-iSCSI.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-Compare-Write-override-driver-queue_pdu-ca.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-Compare-Write-skip-InvalidDataOutSize-unle.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-CryptoEraseReserved-override-driver-queue_.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-CryptoEraseReserved-skip-unless-iSCSI.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-OverwriteReserved-override-driver-queue_pd.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-Use-extern-int-in-headers.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-iSCSICmdSnTooHigh-override-driver-queue_pd.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-iSCSICmdSnTooLow-override-driver-queue_pdu.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-iSCSIDataSnInvalid-override-driver-queue_p.patch
>  create mode 100644 
> debian/patches/lp-1894129-test-tool-remove-unused-iscsi_queue_pdu-symbol-overl.patch

If your comfortable, can this please be uploaded? libiscsi is a key
package (so won't be autoremoved) and the freeze is getting near. Let's
not wait with fixing this until the latest moment.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976162: closed by Sebastiaan Couwenberg (Re: Bug#976162: postgis v3.0.3 pdpg package for amd64 for Ubuntu focal missing)

[Tomas Pospisek]

Sebastiaan Couwenberg wrote on Mon, 30 Nov:


On 11/30/20 7:56 PM, Tomas Pospisek wrote:


There is no 3.0.3 package for postgis for focal on pdgd for amd64:


The Debian BTS is not appropriate for this issue, use the
pgsql-pkg-deb...@postgresql.org mailing list, or
https://redmine.postgresql.org/projects/pgapt/issues instead.


Ah, thanks. I was pointed to https://wiki.postgresql.org/wiki/Apt#Bugs and 
it reads there:



Bugs

Please report bugs:

* on the pgsql-pkg-deb...@postgresql.org mailing list, or
* open an issue in Redmine, or
* open a bug in the Debian BTS.


Which as you explained should probably read

* open a bug in the Debian BTS only if it's a bug in a package
  released through Debian's own package repository.

?

Thanks!
*t

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Matthew Vernon]

Hi,

On 29/11/2020 16:59, Simon McVittie wrote:

Some procedural points, without going into the merits of the technical
committee doing as you ask or not:


Broadly, I expect the TC to know their procedural stuff better than I 
do, but I'll try and answer your points :)



On Wed, 18 Nov 2020 at 17:33:26 +, Matthew Vernon wrote:

I invite the technical committee to rule that:
* The network-manager init script should be restored
* Network-manager should Depend: on default-logind | logind rather than
libpam-systemd


This looks like a request to use the technical committee's power to
overrule the maintainer of network-manager under section 6.1.4 of the
Debian constitution. Is that what you are asking for?


Yes, I think so; I mean, you might also decide that this is a matter 
where jurisdictions overlap (between the init diversity folk and the 
network-manager maintainers), and I wouldn't think that unreasonable.



* Similar init-compatibility changes should not be blocked by package
maintainers unless they are defective on their own merits


This seems like a broader request, and it's less clear which of the
technical committee's powers you are asking us to use. Please could
you either clarify what you are asking us to do, or reduce the scope
of this request to the issue that you are immediately concerned with,
namely network-manager?


I'm not going to answer this directly, but instead try and explain what 
I was hoping to achieve - as you say (in text I've snipped), there are a 
number of ways you might wish to address this question.


Let us beg the question for the moment, and suppose you agree with me 
that the changes I outline should be made to network-manager. Suppose 
further that there are other packages where fundamentally the same 
question arises between now and the bullseye freeze (this isn't a 
hypothetical; there are). I would suggest that it's not in anyone's 
interests for each bug report to have to come before the TC in turn (I 
think this is obviously true, but can justify this if you like).


To that end, you might want to say something about the more general case 
at least in period leading to the bullseye release, whether that's 
expressed as deciding a matter of policy or giving advice. If that's a 
longer decision-making process, I don't see why you couldn't say "The TC 
rules on the request to overrule thus; and will say more on the matter 
hereafter" and then say something more general later.


I don't think any statement of this kind would be overriding the GR - as 
I said in my initial bug report, I think the GR supports what I'm trying 
to achieve here (pace Josh).


To briefly address the question on network-managers utility raised 
elsewhere: I think it is true both that there are many systems where it 
is roughly essential (portable devices - nothing else comes close from a 
managing multiple networks POV), and also classes of systems where being 
able to install GNOME without it is clearly desirable (desktop systems 
with complex but stable networking where ifupdown or netplan are more 
appropriate).


Regards,

Matthew

Bug#973353: src:imlib2: fails to migrate to testing for too long: FTBFS on s390x

[Paul Gevers]

Control: tags -1 ftbfs
Control: reopen -1

Hi,

On Thu, 29 Oct 2020 11:49:42 +0100 Paul Gevers  wrote:
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.

This package is a key package, and as such will not be autoremoved.

> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bullseye, so
> it doesn't affect (old-)stable.

As this bug seem to require a reupload to fix the FTBFS, I have reopened
it (I should not have closed it), and tagged it ftbfs.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976167: src:rust-redox-syscall: fails to migrate to testing for too long: FTBFS everywhere

[Paul Gevers]

Source: rust-redox-syscall
Version: 0.1.40-2
Severity: serious
Control: close -1 0.1.57-1
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 971209

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package
src:rust-redox-syscall in its current version in unstable has been
trying to migrate for 60 days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=rust-redox-syscall




OpenPGP_signature
Description: OpenPGP digital signature

Bug#959991: joblib: build and install documentation

[Sandro Tosi]

> I don't have any particular interest in this package,

then maybe let the maintainer take care of it?

> but if you
> supply a patch, I am happy to apply it and do a team upload.

no thanks

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

Bug#959991: joblib: build and install documentation

[Graham Inggs]

Hi Sandro

On Fri, 8 May 2020 at 02:00, Sandro Tosi  wrote:
> the upstream tarball contains the doc dir, so please build it and ship it in a
> -doc package.  sphinx-gallery will benefit from it since it uses joblib
> intersphinx data for its tests.

I don't have any particular interest in this package, but if you
supply a patch, I am happy to apply it and do a team upload.

Regards
Graham

Bug#976111: topydo 0.13-3 upload seems to hang ci.debian.net workers while testing todo.txt-base

[Paul Gevers]

Hi David,

On 30-11-2020 17:05, David Steele wrote:
> All works well, until you test the new version of one package along with
> the old version of the other. In one scenario there is a recursion, where
> topydo ends up calling itself via the alternatives hook.

Ack. That's probably what we're seeing then.

> I didn't worry too much about this when I submitted the new packages,
> because the issue was transient, and the common popcon is like 5. I
> failed to consider that ci would evaluate the packages independently,
> and would choke.

Happens. Glad you're able to point us at the problem so quickly. I have
blocklisted todo.txt-base already yesterday, so the infrastructure is
somewhat protected now. I'll lift the block once you close this bug.

> I'm reworking the packages so that they can manage this upgrade
> without complaint. That process will take at least days. I'd be willing to
> consider more drastic means to resolve this, either by overriding the
> failures this one time, or by deleting the packages from the distribution
> and starting fresh. 

Take the time you need. Better do it well now than rush.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#976164: RM: xnnpack [armhf] -- RoQA; package no longer builds on armhf

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block 973560 by -1

See #973560 for background.

Bug#975994: zimlib breaks python-libzim autopkgtest: segfaults

[Paul Gevers]

Hi Kunal

On 30-11-2020 02:34, Kunal Mehta wrote:
> So I plan to close this bug with an upload of python-libzim 0.0.3-2 that
> depends on libzim-dev >= 6.3.0. Will that be enough for the CI system or
> do I also need to have zimlib Break the older python-libzim versions?

That versioned Depends relation should be enough for CI. But what about
users that do a partial upgrade? (Yes, I know, officially not supported
in Debian, but in practice it works pretty well).

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#975379: 0ad from git master builds and runs on arm64

[Hans-Christoph Steiner]

https://trac.wildfiregames.com/ticket/4893 has been fixed and released.
So I checked out 0ad from git and ran a build:

./update-workspaces.sh -j1  --disable-atlas
cd gcc
make

It built using the included libmozjs.  It runs and seems to play fine! 
I tried to update/build using -j5 before, and there was a build error.

Bug#976163: ruby-gh: ftbfs with ruby-faraday 1.x

[Pirate Praveen]

Package: ruby-gh
Version: 0.18.0-1
Severity: important

This package ftbfs with ruby-faraday 1.x which was in experimental for 
a long time.


It'd be nice to have ruby-faraday 1.x in unstable soon. So please fix 
it or let me know if it is okay for me to proceed with ruby-faraday 1.0 
upload to unstable.


/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:309:in `to_specs': 
Could not find 'faraday' (~> 0.8) - did find: [faraday-1.1.0] 
(Gem::MissingSpecVersionError)


Full log is attached.



autopkgtest [00:22:04]: version 5.10
autopkgtest [00:22:04]: host mahishasura; command line: /usr/bin/autopkgtest --user debci --apt-upgrade --log-file=/tmp/ruby-faraday_1.1.0-2_amd64.3IWiskBEvM/autopkgtest/ruby-gh.log /home/praveen/forge/build-area/ruby-faraday_1.1.0-2_all.deb ruby-gh -- lxc --sudo autopkgtest-unstable-amd64
autopkgtest [00:22:51]:  test bed setup
Get:1 http://deb.debian.org/debian unstable InRelease [146 kB]
Get:2 http://deb.debian.org/debian-debug unstable-debug InRelease [42.7 kB]
Get:3 http://deb.debian.org/debian unstable/main Sources.diff/Index [37.0 kB]
Ign:3 http://deb.debian.org/debian unstable/main Sources.diff/Index
Get:4 http://deb.debian.org/debian unstable/contrib Sources.diff/Index [15.3 kB]
Ign:4 http://deb.debian.org/debian unstable/contrib Sources.diff/Index
Get:5 http://deb.debian.org/debian unstable/non-free Sources.diff/Index [25.1 kB]
Ign:5 http://deb.debian.org/debian unstable/non-free Sources.diff/Index
Get:6 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index [37.0 kB]
Ign:6 http://deb.debian.org/debian unstable/main amd64 Packages.diff/Index
Get:7 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index [22.5 kB]
Ign:7 http://deb.debian.org/debian unstable/contrib amd64 Packages.diff/Index
Get:8 http://incoming.debian.org/debian-buildd buildd-unstable InRelease [39.7 kB]
Get:9 http://deb.debian.org/debian unstable/non-free amd64 Packages.diff/Index [18.6 kB]
Ign:9 http://deb.debian.org/debian unstable/non-free amd64 Packages.diff/Index
Get:10 http://deb.debian.org/debian-debug unstable-debug/contrib Sources.diff/Index [8,144 B]
Ign:10 http://deb.debian.org/debian-debug unstable-debug/contrib Sources.diff/Index
Get:11 http://deb.debian.org/debian-debug unstable-debug/main Sources.diff/Index [37.0 kB]
Ign:11 http://deb.debian.org/debian-debug unstable-debug/main Sources.diff/Index
Get:12 http://deb.debian.org/debian-debug unstable-debug/contrib amd64 Packages.diff/Index [10.1 kB]
Ign:12 http://deb.debian.org/debian-debug unstable-debug/contrib amd64 Packages.diff/Index
Get:13 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages.diff/Index [37.0 kB]
Ign:13 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages.diff/Index
Get:14 http://deb.debian.org/debian unstable/main Sources [9,049 kB]
Get:15 http://incoming.debian.org/debian-buildd buildd-unstable/contrib Sources [912 B]
Get:16 http://incoming.debian.org/debian-buildd buildd-unstable/main Sources [103 kB]
Get:17 http://deb.debian.org/debian unstable/contrib Sources [49.2 kB]
Get:18 http://deb.debian.org/debian unstable/non-free Sources [88.6 kB]
Get:19 http://deb.debian.org/debian unstable/main amd64 Packages [8,531 kB]
Get:20 http://incoming.debian.org/debian-buildd buildd-unstable/contrib amd64 Packages [1,228 B]
Get:21 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 Packages [77.7 kB]
Get:22 http://deb.debian.org/debian unstable/contrib amd64 Packages [59.4 kB]
Get:23 http://deb.debian.org/debian unstable/non-free amd64 Packages [106 kB]
Get:24 http://deb.debian.org/debian-debug unstable-debug/contrib Sources [22.0 kB]
Get:25 http://deb.debian.org/debian-debug unstable-debug/main Sources [2,818 kB]
Get:26 http://deb.debian.org/debian-debug unstable-debug/contrib amd64 Packages [27.2 kB]
Get:27 http://deb.debian.org/debian-debug unstable-debug/main amd64 Packages [3,469 kB]
Fetched 24.9 MB in 3s (7,214 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
  libperl5.30 libpython3.8-minimal perl-modules-5.30 python3.8-minimal
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  bsdextrautils ca-certificates file libhogweed6 libjson-c5 libmagic-mgc
  libmagic1 libnettle8 libnsl2 libnss-nis libnss-nisplus libperl5.32
  libpython3.9-minimal libpython3.9-stdlib libtirpc-common libtirpc3 mailcap
  media-types mime-support openssl perl-modules-5.32 python3.9
  python3.9-minimal
The following packages will be upgraded:
  apt base-passwd bash binutils binutils-common binutils-x86-64-linux-gnu
  bsdutils bzip2 coreutils dash dbus debconf debianutils dmsetup dpkg dpkg-dev
  eatmydata fdisk findutils gcc-10-base gcc-9-base grep ifupdown init
  init-system-helpers iproute2 libacl1 libapparmor1 libapt-pkg6.0 libassuan0
  libaudit-common 

Bug#976081: [Pkg-javascript-devel] Bug#976081: Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib

[Pirate Praveen]

On Tue, Dec 1, 2020 at 00:28, Pirate Praveen  
wrote:



On Mon, Nov 30, 2020 at 19:46, Paolo Greppi  
wrote:
The resulting package was not installable due to node-babel-runtime 
missing from testing


May be we can add babel-runtime as a component? (it is going to 
contrib anyway)


Or see if we can replace babel-runtime to @babel/runtime with patch and 
node-babel7 as runtime dependency.

Bug#976081: [Pkg-javascript-devel] Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib

[Pirate Praveen]

On Mon, Nov 30, 2020 at 19:46, Paolo Greppi  
wrote:
On Sun, 29 Nov 2020 18:02:16 +0530 Pirate Praveen 
 wrote:

Control: clone -1 -2
Control: retitle -2 "Provide prebuilt yarnpkg in contrib"

On Sat, Nov 28, 2020 at 22:07, Paolo Greppi  
wrote:
>> 3. Build it using 'deb >> 
https://snapshot.debian.org/archive/debian/20200502T085134Z sid >> 
main' (the last version that builds in sid) and embed the built >> 
files in the package (as two steps, like we bootstrap babel, rollup 
>> etc). This will mean, we will have to move it to contrib. I 
prefer >> shipping yarn in contrib to missing it in bullseye.

> > +1

I have a created a new branch master-contrib in salsa and pushed my 
changes.
Please review the changes and if it looks good, we can upload it. 
Also we can move this discussion to the cloned bug.


I have made a couple of commits to master-contrib branch.

The resulting package was not installable due to node-babel-runtime 
missing from testing


May be we can add babel-runtime as a component? (it is going to contrib 
anyway)



Also it does not install the man manpage.


Pushed a change, so it should get installed now.

Bug#976162: postgis v3.0.3 pdpg package for amd64 for Ubuntu focal missing

[Tomas Pospisek]

Source: postgis
Version: 3.0.3
Severity: normal

There is no 3.0.3 package for postgis for focal on pdgd for amd64:

http://apt.postgresql.org/pub/repos/apt/dists/focal-pgdg/main/binary-amd64/Packages

Weirdly enough it apparently *was* built for non-Intel/AMD
architectures but not for amd64:

https://www.postgresql.org/message-id/E1khVKm-0005cE-Kc%40atalia.postgresql.org

Note also that the line with focal and amd64 in it is apparently also missing 
the "source"?

Thanks *a lot* <3 <3 <3! for building these
*t

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

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#976081: [Pkg-javascript-devel] Bug#976081: yarnpkg: Provide prebuilt yarnpkg in contrib

[Paolo Greppi]

On Sun, 29 Nov 2020 18:02:16 +0530 Pirate Praveen  
wrote:

Control: clone -1 -2
Control: retitle -2 "Provide prebuilt yarnpkg in contrib"

On Sat, Nov 28, 2020 at 22:07, Paolo Greppi  
wrote:
>> 3. Build it using 'deb 
>> https://snapshot.debian.org/archive/debian/20200502T085134Z sid 
>> main' (the last version that builds in sid) and embed the built 
>> files in the package (as two steps, like we bootstrap babel, rollup 
>> etc). This will mean, we will have to move it to contrib. I prefer 
>> shipping yarn in contrib to missing it in bullseye.
> 
> +1


I have a created a new branch master-contrib in salsa and pushed my 
changes.
Please review the changes and if it looks good, we can upload it. Also 
we can move this discussion to the cloned bug.


I have made a couple of commits to master-contrib branch.

The resulting package was not installable due to node-babel-runtime missing 
from testing.

I naïvely removed that from the run time deps, but now yarnpkg fails with:

  internal/modules/cjs/loader.js:905
throw err;
^

  Error: Cannot find module 'babel-runtime/helpers/asyncToGenerator'
  Require stack:
  - /usr/share/nodejs/yarn/lib/cli/index.js
  - /usr/share/nodejs/yarn/bin/yarn.js
  at Function.Module._resolveFilename 
(internal/modules/cjs/loader.js:902:15)
  at Function.Module._load (internal/modules/cjs/loader.js:747:27)
  at Module.require (internal/modules/cjs/loader.js:974:19)
  at require (internal/modules/cjs/helpers.js:88:18)
  at _load_asyncToGenerator (/usr/share/nodejs/yarn/lib/cli/index.js:17:54)
  at /usr/share/nodejs/yarn/lib/cli/index.js:21:41
  at Object. (/usr/share/nodejs/yarn/lib/cli/index.js:605:3)
  at Module._compile (internal/modules/cjs/loader.js:1085:30)
  at Object.Module._extensions..js (internal/modules/cjs/loader.js:1114:10)
  at Module.load (internal/modules/cjs/loader.js:950:32) {
code: 'MODULE_NOT_FOUND',
requireStack: [
  '/usr/share/nodejs/yarn/lib/cli/index.js',
  '/usr/share/nodejs/yarn/bin/yarn.js'
]
  }

Also it does not install the man manpage.

Paolo

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Carsten Schoenert]

Hello Jeffrey,

Am 30.11.20 um 18:58 schrieb Jeffrey Ratcliffe:
> I was sent an inline PGP message

is there a particular reason why you want to use inline PGP? This is an
old technique that shouldn't get used any longer, it's a dead horse.
PGP/MIME is the thing users should use instead. Thunderbird uses
PGP/MIME by default and I currently see no way to enforce inline PGP for
sending encrypted emails with Thunderbird?

You are aware that inline PGP is incompatible while using with HTML emails?

-- 
Regards
Carsten

Bug#976161: original-awk: new upstream version 20180827

[Richard Noble]

Package: original-awk
Version: 2012-12-20-6
Severity: wishlist

Awk is now hosted at github: https://github.com/onetrueawk/awk

The most recent tagged release is 20180827:

https://github.com/onetrueawk/awk/releases/tag/20180827

Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted

[Bill Allombert]

On Mon, Nov 30, 2020 at 02:37:08PM +0100, Oxan van Leeuwen wrote:
> Source: debian-policy
> Version: 4.5.1.0
> Severity: normal
> 
> Currently Policy requires that init.d scripts, and only init.d scripts, don't 
> fail if the corresponding /etc/default is removed (section 9.3.2, 
> second-to-last 
> paragraph).
> 
> Personally I interpret "not fail" as "succeed to function", i.e. it has to 
> actually start the daemon. I don't think that's a particularly sensible 
> requirement.

'not fail' here means that the script terminates with return code 0.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#976160: ruby-behance: ftbfs with ruby-faraday 1.x

[Pirate Praveen]

Package: ruby-behance
Version: 0.6.1-2
Severity: important

This package ftbfs with ruby-faraday 1.x which was in experimental for 
a long time.


It'd be nice to have ruby-faraday 1.x in unstable soon. So please fix 
it or let me know if it is okay for me to proceed with ruby-faraday 1.0 
upload to unstable.


/usr/lib/ruby/vendor_ruby/rubygems/dependency.rb:309:in `to_specs': 
Could not find 'faraday' (~> 0.15) - did find: [faraday-1.1.0] 
(Gem::MissingSpecVersionError)


Full log is attached.

sbuild (Debian sbuild) 0.78.1 (09 February 2019) on mahishasura

+==+
| ruby-behance 0.6.1-2 (amd64) Mon, 30 Nov 2020 18:33:12 + |
+==+

Package: ruby-behance
Version: 0.6.1-2
Source Version: 0.6.1-2
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary

I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-269a2b79-1cbc-457f-9446-8a0233e70230' with '<>'
I: NOTICE: Log filtering will replace 'build/ruby-behance-mykXG2/resolver-H5CM9G' with '<>'

+--+
| Update chroot|
+--+

Get:1 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ InRelease
Ign:1 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ InRelease
Get:2 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Release [948 B]
Get:3 http://127.0.0.1:3142/deb.debian.org/debian unstable InRelease [146 kB]
Get:2 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Release [948 B]
Get:4 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Release.gpg
Ign:4 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Release.gpg
Get:5 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Packages [619 B]
Ign:5 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Packages
Get:5 file:/build/ruby-behance-mykXG2/resolver-STtq11/apt_archive ./ Packages [888 B]
Get:6 http://deb.debian.org/debian experimental InRelease [75.4 kB]
Get:7 http://127.0.0.1:3142/deb.debian.org/debian unstable/main Sources.diff/Index [37.0 kB]
Ign:7 http://127.0.0.1:3142/deb.debian.org/debian unstable/main Sources.diff/Index
Get:8 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 Packages.diff/Index [37.0 kB]
Ign:8 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 Packages.diff/Index
Get:9 http://127.0.0.1:3142/deb.debian.org/debian unstable/main Sources [9049 kB]
Get:10 http://deb.debian.org/debian experimental/main amd64 Packages [414 kB]
Get:11 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 Packages [8531 kB]
Fetched 18.3 MB in 3s (7202 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
  bsdmainutils calendar libbsd0 libicu63 libmpdec2 libpython3.8-minimal
  libpython3.8-stdlib libssw-dev libssw0 ncal python3.8 python3.8-minimal
Use 'apt autoremove' to remove them.
The following NEW packages will be installed:
  libisl23 libperl5.32 libpython3.9-minimal libpython3.9-stdlib mailcap
  media-types perl-modules-5.32 python3.9 python3.9-minimal
The following packages will be upgraded:
  apt bash binutils binutils-common binutils-x86-64-linux-gnu bsdextrautils
  bsdutils ccache cpp-10 cpp-9 dash fakeroot fdisk file g++-10 g++-9 gcc-10
  gcc-10-base gcc-9 gcc-9-base grep init-system-helpers libapt-pkg6.0 libasan5
  libasan6 libatomic1 libbinutils libblkid1 libcap-ng0 libcc1-0 libctf-nobfd0
  libctf0 libelf1 libfakeroot libfdisk1 libffi7 libgcc-10-dev libgcc-9-dev
  libgcc-s1 libglib2.0-0 libgmp10 libgomp1 libgssapi-krb5-2 libidn2-0 libitm1
  libk5crypto3 libkrb5-3 libkrb5support0 libksba8 libldap-2.4-2 libldap-common
  liblsan0 libmagic-mgc libmagic1 libmount1 libncursesw6 libnghttp2-14
  libpython3-stdlib libquadmath0 libreadline8 libseccomp2 libsmartcols1
  libstdc++-10-dev libstdc++-9-dev libstdc++6 libsystemd0 libtinfo6 libtsan0
  libubsan1 libudev1 libuuid1 libxml2 linux-libc-dev mime-support mount
  ncurses-base ncurses-bin perl perl-base python3 python3-minimal
  readline-common tar util-linux
84 upgraded, 9 newly installed, 0 to remove and 0 not upgraded.
Need to get 211 MB of archives.
After this operation, 387 MB disk space will be freed.
Get:1 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 bash amd64 5.1~rc3-1 [1415 kB]
Get:2 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 bsdutils amd64 1:2.36.1-2 [148 kB]
Get:3 http://127.0.0.1:3142/deb.debian.org/debian unstable/main amd64 dash amd64 

Bug#976155: [Pkg-javascript-devel] Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid

[Pirate Praveen]

On Mon, Nov 30, 2020 at 19:35, Jonas Smedegaard  wrote:

Btw, it seems you need to push latest changes to git for yarnpkg


The recent changes are in master-1 branch as we could not fix the 
master branch (attempted to build with babel 7 without success).

Bug#976155: [Pkg-javascript-devel] Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2020-11-30 19:31:26)
> Quoting Pirate Praveen (2020-11-30 18:43:27)
> > On Mon, Nov 30, 2020 at 18:32, Jonas Smedegaard  wrote:
> > > yarnpkg depends on node-node-uuid.
> > > 
> > > node-node-uuid was deprecated 2 yars ago, replaced by node-uuid.
> > > 
> > > Please change to instead depend on node-uuid.
> > > 
> > > Raised severity as this is the last package relying on the old name, 
> > > and we want to drop it before freeze.
> > 
> > Since node-yarnpkg is not in bullseye and ftbfs already (it needs a 
> > snapshot.debian.org chroot with babel 6 from the time 1.22.4-3 was 
> > built by buildd), I think you can request node-node-uuid to be removed 
> > from bullseye or add an rc bug for auto removal. We can fix 
> > node-yarnpkg if we need to fix another breakage like node-mkdirp 1.0. 
> > Or if someone wants to fix it earlier, feel free.
> 
> Thanks for the heads-up.
> 
> node-node-uuid is just a virtual package so no ftpmaster requests are 
> involved, though.

I am talking nonsense above: not a virtual package but not a separate 
_source_ package is the reason there's no need to involve ftpmasters 
here.

Btw, it seems you need to push latest changes to git for yarnpkg.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#976155: [Pkg-javascript-devel] Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid

[Jonas Smedegaard]

Quoting Pirate Praveen (2020-11-30 18:43:27)
> On Mon, Nov 30, 2020 at 18:32, Jonas Smedegaard  wrote:
> > yarnpkg depends on node-node-uuid.
> > 
> > node-node-uuid was deprecated 2 yars ago, replaced by node-uuid.
> > 
> > Please change to instead depend on node-uuid.
> > 
> > Raised severity as this is the last package relying on the old name, 
> > and we want to drop it before freeze.
> 
> Since node-yarnpkg is not in bullseye and ftbfs already (it needs a 
> snapshot.debian.org chroot with babel 6 from the time 1.22.4-3 was 
> built by buildd), I think you can request node-node-uuid to be removed 
> from bullseye or add an rc bug for auto removal. We can fix 
> node-yarnpkg if we need to fix another breakage like node-mkdirp 1.0. 
> Or if someone wants to fix it earlier, feel free.

Thanks for the heads-up.

node-node-uuid is just a virtual package so no ftpmaster requests are 
involved, though.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted

[Ansgar]

Oxan van Leeuwen writes:
> Currently Policy requires that init.d scripts, and only init.d scripts, don't
> fail if the corresponding /etc/default is removed (section 9.3.2, 
> second-to-last
> paragraph).
[...]
> The other option is that "not fail" means that the init script is allowed to 
> not
> start the daemon, but it shouldn't cause any further breakage. That seems 
> like a
> sensible requirement to me, but the wording could use some clarification in 
> this
> case.

I think we should keep the requirement.  Legacy init.d scripts are still
handled as conffiles and kept around even if the package is removed
(unlike systemd unit files).  Thus init scripts are still run[1] and
should behave sensibly.

For removed-but-not-purged packages, removing /etc/default/${foo}
probably shouldn't result in errors.  So the init script still needs to
do something sensible (probably just do nothing).

(There are other problems as a sysvinit script cannot really be a noop
for removed-but-purged packages as the LSB header still does something,
but improving that is probably not too welcome as it would require
changes in sysvinit.)

Ansgar

  [1]: For packages shipping native .service files for systemd, this
  might mean that for removed-but-not-purged packages suddenly the
  sysvinit script gets started?  After all there is no longer a .service
  files to prefer over the sysvinit script...

Bug#969703: Mitigated in 0.2.6.1-2

[Göran Weinholt]

Hello Rob,

I've uploaded guile-lib 0.2.6.1-2, which should work with both Guile 2.2
and Guile 3.0. It depends on guile-3.0 | guile-2.2. I think you can
cross off guile-lib from your list, but perhaps we can keep the bug open
since I actually need to remove the guile-2.2 support at some point.

-- 
Göran Weinholt   | https://weinholt.se/
Debian Developer | 73 de SA6CJK

Bug#976158: nginx: need to replace nginx.net on nginx.org

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

Package: nginx
Version: 1.18.0-6
Severity: normal
X-Debbugs-Cc: serfyo...@yandex.ru

Dear Maintainer,

Maybe should replace nginx in the package descriptions
   "Homepage: https://nginx.net; on "http://nginx.org/;,
otherwise get an error message when viewing the site.

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

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

Versions of packages nginx depends on:
ii  nginx-core  1.18.0-6+b1

nginx recommends no packages.

nginx suggests no packages.

-- no debconf information

Bug#975157: (no subject)

[Ryan Pavlik]

This has been fixed upstream, so an upcoming update will resolve it.



signature.asc
Description: OpenPGP digital signature

Bug#976157: thunderbird: Thunderbird refuses to decrypt inline PGP message

[Jeffrey Ratcliffe]

Package: thunderbird
Version: 1:78.5.0-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I was sent an inline PGP message

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

In the past, enigmail recognised and decrypted these with no problem.

   * What was the outcome of this action?

Now, thunderbird does not recognise that the message is encrypted, and pressing
the OpenPGP button, thunderbird claims that it is not encrypted.

   * What outcome did you expect instead?

I expected Thunderbird to recognise and decrypt the message, just as enigmail
had done in the past.

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



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

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

Versions of packages thunderbird depends on:
ii  debianutils 4.11.2
ii  fontconfig  2.13.1-4.2
ii  libatk1.0-0 2.36.0-2
ii  libbotan-2-17   2.17.2+dfsg-2
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-4
ii  libcairo-gobject2   1.16.0-4
ii  libcairo2   1.16.0-4
ii  libdbus-1-3 1.12.20-1
ii  libdbus-glib-1-20.110-5
ii  libevent-2.1-7  2.1.12-stable-1
ii  libffi7 3.3-5
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.2+dfsg-4
ii  libgcc-s1   10.2.0-16
ii  libgdk-pixbuf2.0-0  2.40.0+dfsg-7
ii  libglib2.0-02.66.3-1
ii  libgtk-3-0  3.24.23-2
ii  libicu6767.1-4
ii  libjson-c5  0.15-1
ii  libnspr42:4.29-1
ii  libnss3 2:3.59-1
ii  libpango-1.0-0  1.46.2-3
ii  libstdc++6  10.2.0-16
ii  libvpx6 1.8.2-1
ii  libx11-62:1.6.12-1
ii  libx11-xcb1 2:1.6.12-1
ii  libxcb-shm0 1.14-2
ii  libxcb1 1.14-2
ii  libxext62:1.3.3-1+b2
ii  libxrender1 1:0.9.10-1
ii  psmisc  23.3-1
ii  x11-utils   7.7+5
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages thunderbird recommends:
ii  hunspell-ar [hunspell-dictionary]3.2-1.1
ii  hunspell-be [hunspell-dictionary]0.53-3
ii  hunspell-bg [hunspell-dictionary]1:7.0.1-1
ii  hunspell-bn [hunspell-dictionary]1:7.0.1-1
ii  hunspell-bs [hunspell-dictionary]1:7.0.1-1
ii  hunspell-ca [hunspell-dictionary]3.0.6+repack1-1
ii  hunspell-cs [hunspell-dictionary]1:7.0.1-1
ii  hunspell-da [hunspell-dictionary]1:7.0.1-1
ii  hunspell-de-at [hunspell-dictionary] 20161207-8
ii  hunspell-de-ch [hunspell-dictionary] 20161207-8
ii  hunspell-de-de [hunspell-dictionary] 20161207-8
ii  hunspell-en-gb [hunspell-dictionary] 1:7.0.1-1
ii  hunspell-en-us [hunspell-dictionary] 1:2019.10.06-1
ii  hunspell-eu [hunspell-dictionary]0.5.20151110-5
ii  hunspell-fr-classical [hunspell-dictionary]  1:6.4.1-1
ii  hunspell-gl [hunspell-dictionary]1:7.0.1-1
ii  hunspell-gu [hunspell-dictionary]1:7.0.1-1
ii  hunspell-hi [hunspell-dictionary]1:7.0.1-1
ii  hunspell-hr [hunspell-dictionary]1:7.0.1-1
ii  hunspell-hu [hunspell-dictionary]1:7.0.1-1
ii  hunspell-id [hunspell-dictionary]1:7.0.1-1
ii  hunspell-is [hunspell-dictionary]1:7.0.1-1
ii  hunspell-it [hunspell-dictionary]1:7.0.1-1
ii  hunspell-kk [myspell-dictionary] 1.1-2
ii  hunspell-kmr [hunspell-dictionary]   1:7.0.1-1
ii  hunspell-ko [hunspell-dictionary]0.7.92-1
ii  hunspell-lt [hunspell-dictionary]1:7.0.1-1
ii  hunspell-lv [hunspell-dictionary]1.4.0-1
ii  hunspell-ne [hunspell-dictionary]1:7.0.1-1
ii  hunspell-nl [hunspell-dictionary]2:2.10-6
ii  hunspell-pl [hunspell-dictionary]1:7.0.1-1
ii  hunspell-pt-br [hunspell-dictionary] 1:7.0.1-1
ii  hunspell-pt-pt [hunspell-dictionary] 1:7.0.1-1
ii  hunspell-ro [hunspell-dictionary]1:7.0.1-1
ii  hunspell-ru [hunspell-dictionary]1:7.0.1-1
ii  hunspell-se [hunspell-dictionary]1.0~beta6.20081222-1.2
ii  hunspell-si [hunspell-dictionary]1:7.0.1-1
ii  hunspell-sl [hunspell-dictionary]1:7.0.1-1
ii  hunspell-sr [hunspell-dictionary]1:7.0.1-1
ii  hunspell-sv [hunspell-dictionary]1:7.0.1-1
ii  hunspell-te [hunspell-dictionary]1:7.0.1-1
ii  hunspell-th 

Bug#881788: opusfile: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Gentle ping on this?


Regards,

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

Bug#885063: cairomm: please make the build reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

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

Bug#835816: rt-extension-customfieldsonupdate: please make the build (mostly) reproducible

[Chris Lamb]

Chris Lamb wrote:

> [..]

Friendly ping on this?


Regards,

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

Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted

[Oxan van Leeuwen]

Source: debian-policy
Version: 4.5.1.0
Severity: normal

Currently Policy requires that init.d scripts, and only init.d scripts, don't 
fail if the corresponding /etc/default is removed (section 9.3.2, 
second-to-last 
paragraph).

Personally I interpret "not fail" as "succeed to function", i.e. it has to 
actually start the daemon. I don't think that's a particularly sensible 
requirement. Policy doesn't require programs to function if their native 
configuration files are removed, so why should default files be any different? 
Furthermore, this requirement doesn't exist for systemd unit files, and there 
are in fact unit files in the archive that fail if the default file is removed.

Also, to me removing configuration files seems like a "don't break your system" 
kind of action. If the system administrator does it, they get to keep the 
pieces 
and are reponsible for the fallout.

The other option is that "not fail" means that the init script is allowed to 
not 
start the daemon, but it shouldn't cause any further breakage. That seems like 
a 
sensible requirement to me, but the wording could use some clarification in 
this 
case.

Bug#976155: [Pkg-javascript-devel] Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid

[Pirate Praveen]

On Mon, Nov 30, 2020 at 18:32, Jonas Smedegaard  wrote:

Package: yarnpkg
Version: 1.22.4-4
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

yarnpkg depends on node-node-uuid.

node-node-uuid was deprecated 2 yars ago, replaced by node-uuid.

Please change to instead depend on node-uuid.

Raised severity as this is the last package relying on the old name,
and we want to drop it before freeze.


Since node-yarnpkg is not in bullseye and ftbfs already (it needs a 
snapshot.debian.org chroot with babel 6 from the time 1.22.4-3 was 
built by buildd), I think you can request node-node-uuid to be removed 
from bullseye or add an rc bug for auto removal. We can fix 
node-yarnpkg if we need to fix another breakage like node-mkdirp 1.0. 
Or if someone wants to fix it earlier, feel free.

Bug#976156: libapache-mod-auth-kerb probably shouldn't be released in its current form

[Sam Hartman]

package: libapache-mod-auth-kerb
severity: serious
version: 5.4-2.4
tags: security
justification: unmaintained with security weaknesses

Hi.  As part of a recent krb5 transition, I took a look at
libapache-mod-auth-kerb.
As part of that transition, libapache-mod-auth-kerb was removed from
testing.
I think that in its current state, that's a good idea.
So I'm opening a serious bug as Kerberos maintainer, questioning whether
libapache-mod-auth-kerb uses Kerberos securely.
If someone is going to step up and agree to spend real time maintaining
libapache-mod-auth-kerb, and they choose to downgrade this bug, I have
no objection.
What I don't want to see happen is the package continue to be vaguely
unmaintained and be released in its current form.

There are better replacements for  this package already in Debian.
My recommendation would be that for spnego authentication use
libapache2-mod-auth-gssapi.
For basic authentication use PAM and libpam-krb5 or libpam-sss.

The two biggest security issues I see are:

1) Vulnerable to dictionary attacks because  of old Kerberos API usage.
Kerberos as designed is vulnerable to dictionary attacks.  There is a
mechanism called timestamp (or encrypted challenge) preauthentication in
which  the client rather than the KDC produces the attackable quantity.
That way, you need to observe an exchange with a legitimate user in
order to attack a password.
libapache-mod-auth-kerb supports that.
However if you can observe exchanges between the webserver and KDC, you
can attack the passwords.

Modern Kerberos has a facility called FAST  that prevents this type of
dictionary attack by encrypting the entire Kerberos exchange.
Libapache-mod-auth-kerb does not support FAST because it does not use
the right APIs to provide an armour ticket to the Kerberos library.

2) Rather than using the verify_init_creds API within the Kerberos
library, libapache-mod-auth-kerb open-codes its own initial credentials
verification API based on old code extracted from the Kerberos library.
I am concerned that this code may have been improved and enhanced in
security relevant ways in the many years since it was extracted.
I'd recommend this be audited.

3) Replay cache usage.  The code currently doesn't provide a replay
cache for SPNEGO tokens.
I am not sure this is a good idea, and comments in the code indicate it
is a security problem.
It's a bit tricky.  It's quite possibly the case that replay caches are
not needed provided that TLS is used for the HTTP connection, and that
the cost of replay caches is too high.

I think this should be audited, and either the comments in the code
explaining that not using replay caches are a security problem replaced
with an explanation of why they are not (or turn on the replay cache).
The bugs in MIT Kerberos 1.3 that made replay caches problematic are not
an issue in 2020.

Again, I'm happy if someone steps up to spend significant effort
modernizing and maintaining the package and wants to downgrade this bug.
Be aware that you probably end up becoming upstream as well.


signature.asc
Description: PGP signature

Bug#976155: yarnpkg: depends on obsolete virtual node-node-uuid

[Jonas Smedegaard]

Package: yarnpkg
Version: 1.22.4-4
Severity: grave
Justification: renders package unusable

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

yarnpkg depends on node-node-uuid.

node-node-uuid was deprecated 2 yars ago, replaced by node-uuid.

Please change to instead depend on node-uuid.

Raised severity as this is the last package relying on the old name,
and we want to drop it before freeze.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/FLKwACgkQLHwxRsGg
ASH50g/+M4XGPGcy9FRzeKx/9mh5jiyo3G6uJkr6gi8+aVDCKwWf/WnnEdAsPiL0
3SZdhih+EffgzkDLv/On6h5cMcSRr54I2QtKdwpRWS2Dr/RbhjWp9+FgQdCr7qPC
FJxXJdzANYqxhLVRhmZOj5VDHVJNfFc9VlhJXdQ8a9nPK11cO5ksZ4a49MOZYvkL
a19BsiMMqFjSDqzGUb7rOiouTUS9HQixt4Kn0en2qhOZ+1Ff1T/EmCe9ZPSdJ0Ou
ic3MQGf2mhJkKGf3Ebd591y1pfIeH/rWpqIJrzMQchvikwGn48FxHXVj3bigOHHy
Mt4GbNfXq3CxwN2OwSajPYM5YuLaMYPTUrwfGqunheZG+YHc4hVbKbdJD3SghW7w
LNTQOZeBM+Lxw8o4TYJCpJaMWh6upgldRUzhytGvQHDLY+OJ7brB+tVthocDGgXD
04529fWiBzgPV02OXNlWofdFCYRZjj0+Jy0BuPODEPDpN4mR7RbIRS72P64BeNZf
PAvW2J5As60O1aw6jKvt/022tNKuXkSbqqs6RinlB++9YMh7C/O4CSQGRV6wimgv
kBJDysPD9NCV6uA4lVHwgfOFoL7BQSlCyAjYcCX2txDA3yuHV58eNPYBoqa3cvdS
5g9Ilq2GIebzFQv747KJaubDteoxIf0nSAMrrsmjbX45V/PKSJA=
=hRxU
-END PGP SIGNATURE-

Bug#976056: nvidia-legacy-340xx-driver: requires DRM_LEGACY, disabled from Linux 5.9.11 onwards

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.108-8
Followup-For: Bug #976056
X-Debbugs-Cc: pitsior...@gmail.com

As it seems, arch builds its kernel with the same parameter disabled, as seen
on line 6528 here
https://github.com/archlinux/svntogit-packages/blob/packages/linux/trunk/config

And yet, nvidia 340 from aur still works, possibly because of this patch
https://aur.archlinux.org/cgit/aur.git/tree/0003-kernel-5.9.patch?h=nvidia-340xx

As I have said in previous bug reports, I really do not know how to patch
stuff. But if someone guides me, I am willing to try it with debian's 5.9.11.



-- Package-specific info:
uname -a:
Linux mitsos 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64 GNU/Linux

/proc/version:
Linux version 5.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-17) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.9-1 (2020-11-19)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 10.2.0 (Debian 10.2.0-16) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.152444] Console: colour VGA+ 80x25
[0.589867] pci :01:00.0: vgaarb: setting as boot VGA device
[0.589867] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.589867] pci :01:00.0: vgaarb: bridge control possible
[0.589867] vgaarb: loaded
[0.773909] Linux agpgart interface v0.103
[3.150010] nvidia: loading out-of-tree module taints kernel.
[3.150022] nvidia: module license 'NVIDIA' taints kernel.
[3.212616] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.246017] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.253080] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.253092] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[3.620844] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[3.750995] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[3.780945] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[3.787570] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
[3.788308] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13
[9.684983] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Nov 30 15:29 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Nov 30 15:30 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Nov 30 15:30 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Nov 30 15:29 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jun  8 11:36 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jun  8 11:36 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jun  8 11:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jun  8 11:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   25 Jun  8 11:36 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jun  8 11:36 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jun  8 11:36 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Jun  8 11:36 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Jun  8 11:36 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Jun  8 11:36 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Jun  8 11:36 
/etc/alternatives/glx--nvidia_drv.so -> /usr/lib/nvidia/nvidia_drv.so
lrwxrwxrwx 1 root root   28 Jan  5  2020 /etc/alternatives/nvidia -> 
/usr/lib/nvidia/legacy-340xx
lrwxrwxrwx 1 root 

Bug#969174: firefox: FF80 seems to have broken all add-ons on existing profiles

[Mourad De Clerck]

On 30/11/2020 17:45, Antoine Le Gonidec wrote:
Did you check that the add-ons are still active after a couple restarts 
of Firefox?

The suggested workaround seems to have no effect here.


I just tried restarting multiple times (4-5), it still works for me.

Can you verify in "about:support" whether webrender is really disabled? 
I see:

* "Compositing: Basic"
* "WEBRENDER: disabled by user: User force-disabled WR"

Regards,

-- M

Bug#964127: plplot: Please switch from sip4 to sip5

[Rafael Laboissière]

Control: forwarded -1 https://sourceforge.net/p/plplot/mailman/message/37165423/
Control: tags -1 + upstream

* Dmitry Shachnev  [2020-11-30 18:50]:


On Mon, Nov 30, 2020 at 02:25:43PM +0100, Rafael Laboissière wrote:

This is something that must be done upstream, isn't it?  As a Debian
developer with zero knowledge about Qt, I am not really willing to replace
the upstream authors in this development.

If you are willing to prepare a patch for the plplot package, I would gladly 
integrate it and forward it to the upstream authors.


Maybe you can start with filing a bug upstream, pointing them to the SIP v5 
documentation and the examples of porting?


Done.

Best,

Rafael Laboissière

Bug#913864: Pinning

[Geert Stappers]

On Mon, Nov 30, 2020 at 04:03:25PM +0100, Karsten wrote:
> It seems new that the pinning does not automatically update to a newer 
> version when it exists.

Yes, that is the idea of pinning.

https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version

Bug#976154: libpam-mount-bin doesn't install pmt-ehd's manpage (pmt-ehd.8)

[Paride Legovini]

Package: libpam-mount-bin
Version: 2.16-10
Severity: normal
X-Debbugs-Cc: par...@debian.org

Dear Maintainer,

The libpam-mount-bin package installs the /usr/sbin/pmt-ehd binary
but not its manpage, which is available in the source package in
doc/pmt-ehd.8. Please add it to d/libpam-mount-bin.manpages.

Thanks!

Paride


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

Kernel: Linux 5.9.0-3-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.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 libpam-mount-bin depends on:
ii  libc62.31-4
ii  libcryptsetup12  2:2.3.4-1
pn  libhx32  
pn  libpam-mount 

libpam-mount-bin recommends no packages.

libpam-mount-bin suggests no packages.

Bug#975951: libreoffice tries to access files of firefox profiles (AppArmor)

[Rene Engelhard]

Hi,

On Fri, Nov 27, 2020 at 07:25:19PM +0100, Jörg Sommer wrote:
> Rene Engelhard schrieb am Fr 27. Nov, 16:48 (+0100):
> > > Package: libreoffice
> >
> > No, libreoffice does not contain anything except dependencies. Do you mean 
> > libreoffice-core?
>
> I don't know which package contains this functionality. And it shouldn't
> matter. I file a bug report to a *project* and I'm really don't know which

No, you file it against a *package*. If there was no libreoffice dummy package
reporing it against libreoffice would simply result in a bug for 
"unknown-package",
there is no "filing against a project" in Debians BTS. :)

> You might view a bug report as an incident in a component

That's what "bug" implies, yes... And you filed it as a "normal" bug :)

> and would like to organize all bug reports.

Exactly.

> > How it is a bug when LO does what it's supposed to do in case people want to
> > sign their documents (with S/MIME, gpg is something else) *and which is
> > documented*?
>
> I didn't touch anything that had to do with signing. I've got a document
> as a mail attachment and hit enter. I use LibreOffice four or five times
> per year.

Me too :)

Anyways, that probably means it initializes xmlsecurity/nss and thus acesses 
this.

> To be fair I don't look at my logs.

You wrote in your initial report "I'm seeing many entries like these in my 
log:".

> But I get AppArmor messages via mail. That's why I've spotted this (and
> other) problems.
>
> > > operation="open" profile="libreoffice-soffice" 
> > > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > > comm="soffice.bin" requested_mask="wc" denied_mask="wc" fsuid=1000 
> > > ouid=1000
> > > operation="file_lock" profile="libreoffice-soffice" 
> > > name="/home/joerg/.mozilla/firefox/aelzkv52.dev/cert9.db" pid=486621 
> > > comm="soffice.bin" requested_mask="k" denied_mask="k" fsuid=1000 ouid=1000
> >
> > Access to the Mozilla profile is completely expected in how it's
>
> Yes, that's what you expect, but a) the AppArmor rules expect something
> else

They (apparently) miss key4.db, yes. Otherwise they allow "r" access.

"w" or "c" access shoudn't be allowed and yes, upstream acknowldeges it should 
probably
just be open "r"ead-only. (which is included in the IRC logs I sent in my other 
reply)

If you read what I wrote in my initial reply: I didn't deny that the profie 
might need
adaptions.

That doesn't change that you say in this bug that this access shouldn't happen 
at all,
which somewhat can agree with but as long as they use nss and don't want 
~/.pki/nssdb
because there is no (GUI) key management tool for this this discussion is moot.

It's not Debians "job" to replace something integral like this which also 
probably affects
file format and standards by something else.

> and b) from a generic point of view, I as a software developer
> wouldn't expect any project accessing the internal files of another
> project. This makes any change very difficult, because you have to
> consider all possible external users if you touch anything. That's
> horrible.

Internal details are handled by the nss security library.

Which knows the format because it's it's native format.
(That's why the mozilla profile is used in the first place anyway, LO
just initializes possible locations.)

> > Key *management* is something LO should not do and cannot do anyway. (same 
> > with gpg)
>
> Yes, indeed. Why doesn't it use helper tools like openssl?

See my other reply. They care more about end-users with no clue
instead of "openssl" or "certutil" for that matter...

> It requests the tools for it.

... and LO doesn't do any key management either. It just initializes the XML
signing library, which uses nss. (and not openssl, which is IMHO bad,
I agree.)

> At least, I can tell (but this is another problem) LibreOffice crashes
> with gpg using tofu.
>
> apparmor="DENIED" operation="open" profile="libreoffice-soffice//gpg" 
> name="/home/joerg/.gnupg/tofu.db" pid=708430 comm="gpg" requested_mask="wc" 
> denied_mask="wc" fsuid=1000 ouid=1000
>
> If you don't care about it drop this. I've fixed it for me, so it doesn't
> bother me any more.

Again that "tofu" gpg thingy...

Is there any website or so recommending to set this?

This is not default and "normal" gpg just works. See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955271 where this already
was reported.

If you change options you also need to change other stuff if needed.

> … by using a private key store. So, you are telling me it's difficult,

Anything needing to sign stuff needs to access the private key store, wherever
that lies. Whether ~/.pki/nssdb or the firefox profile.

Also gnupg needs to access their own key store (and so does LO if signing a 
document with
gpg - via libgpgme -, also only in "r" mode;).

You are suggesting not to access any key store => no signing at all. (INSIDE the
document), not something like gpg --detach-sign.
And no, LO has no business of 

Bug#970849: fixed in brightnessctl 0.5.1-3

[Vincent Lefevre]

On 2020-11-30 15:33:23 +, Debian FTP Masters wrote:
>* brightness-udev
>  + Do not print the name of devices in postinst
>  + Use external helper to avoid errors on certain hardware
>Closes: #970849

Thanks.

BTW, I've noticed that the issue disappeared 3 weeks ago with the
upgrade to the following kernel:

Linux version 5.9.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-16) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.6-1 (2020-11-08)

and it has not reappeared since. The files on which there was an error
now exist:

zira:~> ll /sys/class/leds/*/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:43 
/sys/class/leds/hda::micmute/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:43 
/sys/class/leds/hda::mute/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:43 
/sys/class/leds/hp::hddprotect/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input0::capslock/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input0::numlock/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input0::scrolllock/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input9::capslock/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input9::compose/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input9::kana/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input9::numlock/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:42 
/sys/class/leds/input9::scrolllock/brightness
-rw-rw-r-- 1 root input 4096 2020-11-30 02:44:43 
/sys/class/leds/phy0-led/brightness

(this was previously something like input31 instead of input9). And
now "journalctl -b" reports only input9 and input10 instead of 6 input
values (see initial bug report); this may be related.

However, I could not find the mention of a fix in the linux changelog,
nor a bug reported at bugzilla.kernel.org.

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

Bug#976144: librttopo1: buggy/missing geojson support

[Roman Kurakin]

Package: librttopo1
Version: 1.1.0-2+1
Severity: important
Tags: patch upstream

Since librttopo is suggested as a replacement for liblwgeom, and the part of it
functionality is missing (switched off by ifdef) the bug becomes critical.

Functionality is switched off due to missing code in configure.  Looks like it
was lost while fork from original liblwgeom (part of postgis project).

All of the versions currently in debian are affected by this problem.



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

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

Versions of packages librttopo1 depends on:
ii  libc6 2.28-10
ii  libgeos-c1v5  3.7.1-1

librttopo1 recommends no packages.

librttopo1 suggests no packages.

-- no debconf information
Index: librttopo-1.1.0/configure.ac
===
--- librttopo-1.1.0.orig/configure.ac
+++ librttopo-1.1.0/configure.ac
@@ -131,6 +131,67 @@ RTGEOM_GEOS_VERSION="$GEOS_MAJOR_VERSION
 AC_DEFINE_UNQUOTED([RTGEOM_GEOS_VERSION], [$RTGEOM_GEOS_VERSION], [GEOS 
library version])
 AC_SUBST([RTGEOM_GEOS_VERSION])
 
+# ===
+# Detect if json-c installed
+# ===
+
+CHECK_JSON=yes
+HAVE_JSON=no
+HAVE_JSON_C=no
+
+AC_ARG_WITH([json],
+   [AS_HELP_STRING([--without-json], [build without json-c support])],
+   [CHECK_JSON="$withval"], [])
+
+if test "$CHECK_JSON" != "no"; then
+
+AC_ARG_WITH([jsondir],
+   [AS_HELP_STRING([--with-jsondir=PATH], [specify the json-c installation 
directory])],
+   [JSONDIR="$withval"], [JSONDIR=])
+
+if test ! "x$JSONDIR" = "x"; then
+   # Make sure that the directory exists
+   if test "x$JSONDIR" = "xyes"; then
+   AC_MSG_ERROR([you must specify a parameter to --with-jsondir, 
e.g. --with-jsondir=/path/to])
+   else
+   AC_MSG_RESULT([Using user-specified json-c directory: $JSONDIR])
+
+   # Add the include directory to JSON_CPPFLAGS
+   JSON_CPPFLAGS="-I$JSONDIR/include"
+   JSON_LDFLAGS="-L$JSONDIR/lib"
+   fi
+fi
+
+# Check that we can find the json/json.h header file
+CPPFLAGS_SAVE="$CPPFLAGS"
+CPPFLAGS="$JSON_CPPFLAGS"
+AC_CHECK_HEADER([json/json.h], [HAVE_JSON=yes], [
+  AC_CHECK_HEADER([json-c/json.h], [HAVE_JSON=yes; HAVE_JSON_C=yes], [])
+])
+CPPFLAGS="$CPPFLAGS_SAVE"
+
+# Ensure we can link against libjson
+LIBS_SAVE="$LIBS"
+LIBS="$JSON_LDFLAGS"
+AC_CHECK_LIB([json-c], [json_object_get], [HAVE_JSON=yes; 
JSON_LDFLAGS="${JSON_LDFLAGS} -ljson-c"], [
+  AC_CHECK_LIB([json], [json_object_get], [HAVE_JSON=yes; 
JSON_LDFLAGS="${JSON_LDFLAGS} -ljson"], [], [])
+], [])
+LIBS="$LIBS_SAVE"
+
+if test "$HAVE_JSON" = "yes"; then
+   AC_DEFINE([HAVE_LIBJSON], 1, [Define to 1 if libjson is present])
+fi
+if test "$HAVE_JSON_C" = "yes"; then
+   AC_DEFINE([HAVE_LIBJSON_C], 1, [Define to 1 if libjson resides in a 
json-c subdir])
+fi
+
+AC_SUBST([JSON_CPPFLAGS])
+AC_SUBST([JSON_LDFLAGS])
+AC_SUBST([HAVE_JSON])
+
+fi
+
+
 # SRID stuff
 SRID_MAX=99
 SRID_USR_MAX=998999
Index: librttopo-1.1.0/src/rtin_geojson.c
===
--- librttopo-1.1.0.orig/src/rtin_geojson.c
+++ librttopo-1.1.0/src/rtin_geojson.c
@@ -47,17 +47,17 @@
 
 #include 
 
-static void geojson_rterror(char *msg, int error_code)
+static void geojson_rterror(const RTCTX *ctx, char *msg, int error_code)
 {
   RTDEBUGF(ctx, 3, "rtgeom_from_geojson ERROR %i", error_code);
   rterror(ctx, "%s", msg);
 }
 
 /* Prototype */
-static RTGEOM* parse_geojson(json_object *geojson, int *hasz, int root_srid);
+static RTGEOM* parse_geojson(const RTCTX *ctx, json_object *geojson, int 
*hasz, int root_srid);
 
 static json_object*
-findMemberByName(json_object* poObj, const char* pszName )
+findMemberByName(const RTCTX *ctx, json_object* poObj, const char* pszName )
 {
   json_object* poTmp;
   json_object_iter it;
@@ -75,7 +75,7 @@ findMemberByName(json_object* poObj, con
   {
 if( NULL == json_object_get_object(poTmp)->head )
 {
-  geojson_rterror("invalid GeoJSON representation", 2);
+  geojson_rterror(ctx, "invalid GeoJSON representation", 2);
   return NULL;
 }
 
@@ -95,7 +95,7 @@ findMemberByName(json_object* poObj, con
 
 
 static int
-parse_geojson_coord(json_object *poObj, int *hasz, RTPOINTARRAY *pa)
+parse_geojson_coord(const RTCTX *ctx, json_object *poObj, int *hasz, 
RTPOINTARRAY *pa)
 {
   RTPOINT4D pt;
 
@@ -110,7 +110,7 @@ parse_geojson_coord(json_object *poObj,
 
 if ( nSize < 2 )
  

Bug#973096: python-bleach: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.9 3.8" returned exit code 13

[Lee Garrett]

Hi,

I've prepared a fix for this package at

https://salsa.debian.org/python-team/packages/python-bleach/-/merge_requests/1

I lack permissions to merge to master and upload this package. The patch
itself is based on a pending upstream MR, details are in the quilt patch
annotation.

Regards,
Lee

Bug#750202: closed by "G. Branden Robinson" (Re: Bug#750202: GROFF_SGR [sic] variable not documented)

[Gavin Smith]

On Mon, Nov 30, 2020 at 11:30 AM Debian Bug Tracking System
 wrote:
> > If I remember correctly (I raised this bug over 6 years ago:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750202) it is not
> > GROFF_NO_SGR. It is GROFF_SGR.
>
> I think you must be mistaken; there is no match for GROFF_SGR in the
> current groff source tree, nor in its entire Git history (with patches
> showing).

I am not mistaken. I'm not sure if you really understand what the problem was.

https://metadata.ftp-master.debian.org/changelogs//main/g/groff/groff_1.22.4-3_changelog

* Disable the new ANSI colour/bold/underline escapes in nroff mode,
because most pagers either fail to cope with it or need special options
to do so. It can be re-enabled by editing /etc/groff/man.local and
/etc/groff/mdoc.local, or by setting the environment variable GROFF_SGR
to something non-empty.

Does that say GROFF_SGR, or does it say GROFF_NO_SGR?

I don't know how to look at the Git history for the Debian groff
packages (if there is one) but the file is /etc/groff/mdoc.local which
is provided by the package groff-base.

>
> > Is it important that overstrike sequences be used by default for bold
> > or underlined text? I know that "less" recognizes these, but I
> > couldn't tell you what else does.
>
> In my experience, less stuff (maybe I should say "fewer stuff"...)

Stuff is a mass noun so no plural.

> recognizes these overstriking semantics than recognizes SGR escapes.
> But some people, like Thomas Dickey and Ingo Schwarze, violently oppose
> SGR escapes in nroff output.

They are probably not actually violent about it, though ;-)

I don't know much about groff but one way forward might be to enable
it in more cases. For example when I run "man bc" there are several
programs run, one of which will be nroff. If all of the programs
involved understand the ECMA-48 "SGR" codes then there would be no
harm in switching to SGR codes in this case. (In case you were
wondering, it stands for "Select Graphic Rendition".)

Bug#976143: ITP: license-expression -- a small utility library to parse, compare, simplify and normalize license expressions

[Stephan Lachnit]

Package: wnpp

* Package name: license-expression
* Version : 1.2
* Upstream Author : nexB 
* URL : https://github.com/nexB/license-expression
* License : Apache-2.0
* Programming Lang: Python
* Description : a small utility library to parse, compare, simplify and 
normalize license expressions

Required dependency for reuse. Would maintain in the DPT.

Bug#976056: nvidia-legacy-340xx-driver: requires DRM_LEGACY, disabled from Linux 5.9.11 onwards

[jim_p]

Package: nvidia-legacy-340xx-driver
Version: 340.108-8
Followup-For: Bug #976056
X-Debbugs-Cc: pitsior...@gmail.com

That is tough! It may also be the end for me on debian, after ~13 years,
because my financial status does not allow a hw upgrade right now. Why is that
kernel parameter so important?
Can't you just make a patch that works?
Also, will the same happen on future versions of the kernel, e.g in the
forthcoming 5.10 which is an lts?

As for building the kernel on my own, I think I am not able to. I tried it once
for an old atom pc and I failed completely. For now, I have uninstalled linux-
image-amd64 so as to stay in 5.9.9 for as long as I can. I may check other
kernels for debian later this week, e.g. liquorix, just in case they are built
differently.



-- Package-specific info:
uname -a:
Linux mitsos 5.9.0-3-amd64 #1 SMP Debian 5.9.9-1 (2020-11-19) x86_64 GNU/Linux

/proc/version:
Linux version 5.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.0-17) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP Debian 
5.9.9-1 (2020-11-19)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 11 11:06:58 
PST 2019
GCC version:  gcc version 10.2.0 (Debian 10.2.0-16) 

lspci 'display controller [030?]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GT218 [GeForce 
210] [10de:0a65] (rev a2) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. GT218 [GeForce 210] [1043:8490]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.152444] Console: colour VGA+ 80x25
[0.589867] pci :01:00.0: vgaarb: setting as boot VGA device
[0.589867] pci :01:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.589867] pci :01:00.0: vgaarb: bridge control possible
[0.589867] vgaarb: loaded
[0.773909] Linux agpgart interface v0.103
[3.150010] nvidia: loading out-of-tree module taints kernel.
[3.150022] nvidia: module license 'NVIDIA' taints kernel.
[3.212616] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
[3.246017] nvidia :01:00.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=none:owns=io+mem
[3.253080] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on 
minor 0
[3.253092] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.108  Wed Dec 
11 11:06:58 PST 2019
[3.620844] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[3.750995] input: HDA NVidia HDMI/DP,pcm=3 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input10
[3.780945] input: HDA NVidia HDMI/DP,pcm=7 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input11
[3.787570] input: HDA NVidia HDMI/DP,pcm=8 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input12
[3.788308] input: HDA NVidia HDMI/DP,pcm=9 as 
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input13
[9.684983] caller _nv000788rm+0xe4/0x1c0 [nvidia] mapping multiple BARs

Device node permissions:
crw-rw+ 1 root video 226,   0 Nov 30 15:29 /dev/dri/card0
crw-rw-rw-  1 root root  195,   0 Nov 30 15:30 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Nov 30 15:30 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Nov 30 15:29 pci-:01:00.0-card -> ../card0
video:*:44:jim

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jun  8 11:36 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jun  8 11:36 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   43 Jun  8 11:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jun  8 11:36 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   25 Jun  8 11:36 
/etc/alternatives/glx--linux-libglx.so -> /usr/lib/nvidia/libglx.so
lrwxrwxrwx 1 root root   42 Jun  8 11:36 
/etc/alternatives/glx--nvidia-blacklists-nouveau.conf -> 
/etc/nvidia/nvidia-blacklists-nouveau.conf
lrwxrwxrwx 1 root root   36 Jun  8 11:36 
/etc/alternatives/glx--nvidia-bug-report.sh -> 
/usr/lib/nvidia/nvidia-bug-report.sh
lrwxrwxrwx 1 root root   39 Jun  8 11:36 
/etc/alternatives/glx--nvidia-drm-outputclass.conf -> 
/etc/nvidia/nvidia-drm-outputclass.conf
lrwxrwxrwx 1 root root   28 Jun  8 11:36 
/etc/alternatives/glx--nvidia-load.conf -> /etc/nvidia/nvidia-load.conf
lrwxrwxrwx 1 root root   32 Jun  8 11:36 
/etc/alternatives/glx--nvidia-modprobe.conf -> /etc/nvidia/nvidia-modprobe.conf
lrwxrwxrwx 1 root root   29 Jun  8 11:36