date:20201124


If it's still reproducible, can you raise this upstream please at
https://github.com/systemd/systemd/issues

Regards,
Michael

Bug#975683: color_sampler_pack/colors/Mustang.vim: Please rename

2020-11-24 Thread Oliver Schode

Package: vim-scripts
Version: 20201113
Severity: normal

Hi,

please rename:

Mustang.vim ==> mustang.vim


While the scheme works even with a wrong file name, vim looks for the
correct one and prints an error message on startup. Hence this only happens
when set (capitalized) in .vimrc.

Regards
Oliver

Bug#768352: gsasl: Does not support GSSAPI.

2020-11-24 Thread Simon Josefsson

fixed 768352 1.8.0-7
thanks

This problem should have been resolved after fixing 776847.  Notice
that GSSAPI are present in the output below (this is on a Debian buster
machine).

/Simon

jas@latte:~$ env LANG=C gsasl msa.wesleyan.edu 25 --client-mechanisms
This client supports the following mechanisms:
ANONYMOUS EXTERNAL LOGIN PLAIN SECURID NTLM DIGEST-MD5 CRAM-MD5 SCRAM-
SHA-1 SAML20 OPENID20 GSSAPI GS2-KRB5
jas@latte:~$ 


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

Bug#957919: w-scan and GCC 10

2020-11-24 Thread Rob Moss

Greetings,

I've attached a patch that applies the same changes as the corresponding
commit for w_scan2, which allows w-scan to compile successfully with GCC 10.

Sincerely,
Rob


support_fno-common_compilation
Description: Binary data

Bug#975682: acpi: please also report the ETA

2020-11-24 Thread Thorsten Glaser

Package: acpi
Version: 1.7-1.1
Severity: wishlist
Tags: upstream patch
X-Debbugs-Cc: t...@mirbsd.de

$ acpi
Battery 0: Discharging, 58%, 01:48:28 remaining

When I run this command multiple times, I cannot see
whether the rate goes up or down, at least not easily
(need to output the time-of-running and calculate it
myself).

With the patch below, this becomes:

$ acpi
Battery 0: Discharging, 57%, 00:53:53 remaining (ca. 2020-11-25T03:22:39+0100)
$ acpi
Battery 0: Discharging, 57%, 01:42:19 remaining (ca. 2020-11-25T04:11:16+0100)

Two mostly-consecutive calls, but the first one still
had the man-db update running on another terminal, so
I can now see easily the discharging rate goes down.

Oh, and please also drop the useless AM_CFLAGS line
from debian/rules, it's not only unused but also wrong ;-)

Thanks in advance for applying and forwarding upstream!


diff -u acpi-1.7/debian/changelog acpi-1.7/debian/changelog
--- acpi-1.7/debian/changelog
+++ acpi-1.7/debian/changelog
@@ -1,3 +1,10 @@
+acpi (1.7-1.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Display estimated end time for {,dis}charging, too
+
+ -- Thorsten Glaser   Wed, 25 Nov 2020 02:24:31 +0100
+
 acpi (1.7-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- acpi-1.7.orig/acpi.c
+++ acpi-1.7/acpi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "list.h"
 #include "acpi.h"
@@ -383,11 +384,19 @@
}
 
if (seconds > 0) {
+   char stm[128];
+   time_t t = time(NULL) + seconds;
+   struct tm tm;
+
+   if (!localtime_r(, ) || !strftime(stm, sizeof(stm),
+ " (ca. %FT%T%z)", ))
+   stm[0] = '\0';
+
hours = seconds / 3600;
seconds -= 3600 * hours;
minutes = seconds / 60;
seconds -= 60 * minutes;
-   printf(", %02d:%02d:%02d%s", hours, minutes, seconds, 
poststr);
+   printf(", %02d:%02d:%02d%s%s", hours, minutes, seconds, 
poststr, stm);
} else if (poststr != NULL) {
printf(", %s", poststr);
}


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages acpi depends on:
ii  libc6  2.31-4

acpi recommends no packages.

acpi suggests no packages.

-- no debconf information

Bug#975681: greenbone-security-assistant: (Build-)Depends on obsolete openvas-libraries

2020-11-24 Thread Andreas Beckmann

Source: greenbone-security-assistant
Version: 7.0.3+dfsg.1-1
Severity: serious
Tags: sid bullseye
Control: block 971709 with -1

src:openvas-libraries has been superseded by src:gvm-libs and is scheduled
for removal.
But greenbone-security-assistant still build-depends on libopenvas-dev (>= 9)
and the binary package therefore depends on libopenvas9.

Andreas

Bug#975289: Acknowledgement (systemd: always reporting unit file has "changed on disk" when override.conf is present)

Am Mittwoch, den 25.11.2020, 02:10 +0100 schrieb Michael Biebl:
> On Sun, 22 Nov 2020 15:54:12 +0100 Richard van den Berg
>  wrote:
> > This looks a lot like
> > https://github.com/systemd/systemd/issues/17312 
> > which apparently was fixed by
> > https://github.com/systemd/systemd/pull/16885
> > 
> > Can this PR be applied to the debian systemd package in unstable?
> > Or do 
> > I need to wait until 247 is officially released?
> 
> This PR is part of the systemd-stable branch and included in 246.4
> and
> later. See
> 
> https://github.com/systemd/systemd-stable/commit/97fdde323978912b59d598c17976500482188d61
> https://github.com/systemd/systemd-stable/commit/0500968241c89501b477aa1075e1f3960a0d
> https://github.com/systemd/systemd-stable/commit/8ae22f0d64006dfe8dd4738a48198019ec9bd2c5
> https://github.com/systemd/systemd-stable/commit/715507c2772272a285a2f14c9bd7f7a734cdc518
> 
> 

Can you break this down to a more minimal test case which would make
this easily reproducible with systemd from unstable?


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

Bug#975289: Acknowledgement (systemd: always reporting unit file has "changed on disk" when override.conf is present)

On Sun, 22 Nov 2020 15:54:12 +0100 Richard van den Berg  
wrote:
> This looks a lot like https://github.com/systemd/systemd/issues/17312 
> which apparently was fixed by https://github.com/systemd/systemd/pull/16885
> 
> Can this PR be applied to the debian systemd package in unstable? Or do 
> I need to wait until 247 is officially released?

This PR is part of the systemd-stable branch and included in 246.4 and
later. See

https://github.com/systemd/systemd-stable/commit/97fdde323978912b59d598c17976500482188d61
https://github.com/systemd/systemd-stable/commit/0500968241c89501b477aa1075e1f3960a0d
https://github.com/systemd/systemd-stable/commit/8ae22f0d64006dfe8dd4738a48198019ec9bd2c5
https://github.com/systemd/systemd-stable/commit/715507c2772272a285a2f14c9bd7f7a734cdc518




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

Bug#975657: [Pkg-rust-maintainers] Bug#975657: debcargo: Debcargo, cargo, and other Rust packaging tools are NOT in testing

2020-11-24 Thread peter green


On 25/11/2020 00:55, peter green wrote:


and a bunch more similar errors, I really have no idea where to start on fixing 
this.


Forgot to mention in a previous mail I have pushed my work in process to a 
branch
"debcargo-minimalfixes" in case anyone else wants to pick it up.

Bug#975657: [Pkg-rust-maintainers] Bug#975657: debcargo: Debcargo, cargo, and other Rust packaging tools are NOT in testing

2020-11-24 Thread peter green

On 24/11/2020 19:04, Sylvestre Ledru wrote:

Hello,

Le 24/11/2020 à 19:06, Calum McConnell a écrit :
> Package: debcargo
> Severity: important
> X-Debbugs-Cc: calumlikesapple...@gmail.com
>

As the freeze approaches, it becomes more important to make sure that every
package desired for the next release is actually
present in Debian. Many of the important rust packages have not been in
testing for several months, and must be fixed and updated soon.

Do you have a list of packages you have in mind?

Cargo is in testing (version 0.43.1)

AIUI the "cargo" crate is packaged twice in Debian.

The "cargo" source package uses embedded rust libraries (to avoid bootstrapping
nightmares) and builds
the cargo tool. It is currently in testing, though it seems to have a FTBFS
issue which is not yet
reported in the BTS.

the "rust-cargo" source package on the other hand builds the librust-cargo-dev
and librust-cargo+openssl-dev
packages and is not in testing.

Debcargo indeed needs some love (i reported bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963916).

As NEW is super fast lately,

Speed is all very well, but is there any resolution to the dispute over feature
packages that has caused
a large number of uploads to be rejected recently after sitting in new for
ages? I understand one of the ftpmasters
has proposed an archive split, but I don't think it's actually been implemented
yet and I would be surprised if it
was implemented in time for bullseye.

peter, do you think you could have a new look?

I've been trying to help out a bit with getting rust in testing back into a
healthy state
and trying to keep it that way, but I am NOT a rust expert and I am NOT
comfortable taking responsibility for
major updates/transitions or packaging rust crates that are new to Debian.

Anyway with that disclaimer out of the way lets take a look at the issues with
getting debcargo back into testing.

The first issue is that the autopkgtests in rust-cargo and rust-vte have never
passed. Should they simply be marked
as broken?

The second issue is rust-core-foundation is currently
uninstallable/unbuildable, due to a recent update of
rust-core-foundatoin-sys which in turn means rust-cargo and rust-debcargo are
unbuildable. It looks like the new
version was marked as released in the vcs but not actually uploaded to the
archive.

The third issue is what to do about rust-cargo itself. The version currently in
Debian is quite some way behind
upstream and depends on the old version of rust-core-foundation. It looks like
ximin was in the process of updating it
to 0.47.0 but stopped. I looked at building 0.47 (and before that 0.49) but
quickly ran intodependency issues.
Tracking through I see.

* rust-cargo 0.47.0
* rust-git2 0.13.12
* rust-git2-sys 0.12.14
* libgit2-dev -- currently in experimental
* rust-im-rc 15.0.0
* The featureset packages that I disabled to avoid new and because one of
them
had unsatisfiable dependencies have been re-enabled in git.
* Neither refpool or metrohash seems to have been packaged, either in
debian or in debcargo-conf
the latter seems to be a hard dependency.
* semver 0.11.0
* Autopkgtests fail for most featuresets, the version currently in the
archive doesn't have any
autopkgtests though.

Plus outside of the direct dependency lines, several of those packages have
other reverse dependencies.

In summary this is a far bigger set of changes than I am personally prepared to
take responsibility
for in packages I have very little knowledge of.

So I looked at the less ambitious option of keeping rust-cargo at the version
currently in sid
and figuring out the minimum changes relative to current sid to get things
sane. I got as far as

* Update rust-core-foundation to 0.9.1
* Keep rust-vte at 0.3.3, mark the autpkgtest as broken and relax the
dependency on rust-utf8parse.
* Keep rust-cargo at 0.43.1, mark the autpkgtest as broken and relax the
dependency on rust-core-foundation
* Relax dependency on rust-semver-parser in rust-debcargo.

Unfortunately it seems that there have been API changes in semver-parser that
actually effect debcargo

Running `LD_LIBRARY_PATH='/tmp/autopkgtest.Q6QoAY/build.Kd0/src/target/debug/deps:/usr/lib'
CARGO_PKG_VERSION_PATCH=3 CARGO_PKG_VERSION_MAJOR=2 CARGO_PKG_VERSION=2.4.3
CARGO_PKG_NAME=debcargo CARGO=/usr/bin/cargo CARGO_PKG_DESCRIPTION='Create a Debian package from
a Cargo crate.' CARGO_PKG_HOMEPAGE=
CARGO_PKG_REPOSITORY='https://salsa.debian.org/rust-team/debcargo' CARGO_PKG_VERSION_PRE=
CARGO_MANIFEST_DIR=/tmp/autopkgtest.Q6QoAY/build.Kd0/src CARGO_PKG_AUTHORS='Josh Triplett
:Ximin Luo :Vasudev Kamath
' CARGO_PKG_VERSION_MINOR=4 rustc --crate-name debcargo
--edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib
--emit=dep-info,metadata,link -C debuginfo=2 -C metadata=c8362fd769a53753 -C
extra-filename=-c8362fd769a53753 --out-dir

Bug#975655: RFS: smlnj -- Standard ML of New Jersey interactive compiler [QA upload]

2020-11-24 Thread Brett Gilio

Fabian Wolff  writes:

> I have now packaged the latest upstream version,
> 110.98.1, which, most notably, contains actual support for amd64:
> Until now, the smlnj package on amd64 shipped 32-bit binaries; see
> #796661.
>

YAY!

-- 
Brett M. Gilio
bre...@gnu.org
https://brettgilio.com/
GNU Project webmaster [https://gnu.org/help/]
E82A C026 95D6 FF02 43CA 1E5C F6C5 2DD1 BA27 CB87

Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

2020-11-24 Thread Ryutaroh Matsumoto

Hi Michael,

Thank you very much for your investigation.

> We probably need to cherry-pick two changes

Can I wait inclusion of those two changes into the next Debian
systemd package, then see if what happens on my amd64 qemu
testbed and arm64 one?

I will be very busy in the next one week, and will become less busy
afterwards...

Best regards, Ryutaroh

From: Michael Biebl 
Subject: Re: Bug#973287: systemd autopkgtest-virt-lxc failure on arm64
Date: Tue, 24 Nov 2020 21:21:51 +0100

> Am Montag, den 23.11.2020, 18:09 +0900 schrieb Ryutaroh Matsumoto:
>> Hi Michael,
>> 
>> I run autopkgtest QEMU on systemd 246.6-4 by an amd64 testbed made
>> by debci setup -a amd64 -b qemu -s sid. Then root-unittests and
>> upstream failed.
>> The log is attached as the first attachment.
>> 
> 
> We probably need to cherry-pick two changes
> https://github.com/systemd/systemd/commit/0af05e485a3a88f454c714901eb6109307dc893e
> https://github.com/systemd/systemd/pull/17706
> 
>> 
>> I wonder if all the tests succeed on autopkgtest-virt-qemu
>> on your Debian amd64 computer...
> 
> With the above two changes, qemu on amd64 passes here.
> 
> Michael

Bug#975680: boxbackup-client: Postinst script generates sha1 rather than sha256 csr

2020-11-24 Thread Dean Hamstead

Package: boxbackup-client
Version: 0.13~~git20200326.g8e8b63c-1
Severity: normal

bbackupd-config generates sha256 csr's but the postinst script for the
package produces sha1 csr's which are unusable

See 
https://salsa.debian.org/debian/boxbackup/-/blob/master/debian/boxbackup-client.postinst#L234

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

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

Versions of packages boxbackup-client depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-4
ii  libedit2   3.1-20191231-1
ii  libgcc-s1  10.2.0-18
ii  libssl1.1  1.1.1h-1
ii  libstdc++6 10.2.0-18
ii  lsb-base   11.1.0
ii  openssl1.1.1h-1
ii  perl   5.32.0-5
ii  ucf3.0043
ii  zlib1g 1:1.2.11.dfsg-2

boxbackup-client recommends no packages.

boxbackup-client suggests no packages.

-- debconf information excluded

Bug#975333: msmtp: AppArmor profile breaks --file, logfile, and passwordeval

2020-11-24 Thread Simon Deziel


On 2020-11-24 4:23 a.m., Emmanuel Bouthenot wrote:

Hi,

On Tue, Nov 24, 2020 at 12:03:07AM -0500, Simon Deziel wrote:
[...]


Yes, an opt-in approach seems ideal.


Here's the proposal:

https://salsa.debian.org/kolter/msmtp/-/merge_requests/16


Thanks Simon for your merge request.

I'd like to propose some improvements:

  - a debconf question which ask to enable/disable AppArmor
  - make it idempotent, so that it could possible to enable or disable
apparmor profile with dpkg-reconfigure even if the package was
already installed
  - add a debian/NEWS entry so that users which already use msmtp could
be aware that it is now easy and possible to disable AppArmor


Those make sense. I'll back to you with something, hopefully in a not 
too distant future.


Regards,
Simon

Bug#958604: ircd-irc2: Build-Depends on deprecated dh-systemd which is going away

2020-11-24 Thread Nicholas D Steeves

Oh my, it seems I forgot to include one commit.  Sorry attaching it now!
P.S. I would be happy to NMU ircd-irc2 one week from now if necessary.

From 8d71d441761b4650968614d6bc41e591ec837631 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 24 Nov 2020 08:05:10 -0500
Subject: [PATCH 1/2] Drop unnecessary dh-systemd build-dep

---
 debian/changelog | 8 
 debian/control   | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 0998a93..e0db207 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ircd-irc2 (2.11.2p3~dfsg-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709)
+already provides this (Closes: #958604).
+
+ -- Nicholas D Steeves   Tue, 24 Nov 2020 08:03:21 -0500
+
 ircd-irc2 (2.11.2p3~dfsg-5) unstable; urgency=medium
 
   * Update defaults to production use case
diff --git a/debian/control b/debian/control
index 9b60452..d2f3a60 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: net
 Priority: optional
 Maintainer: Kurt Roeckx 
 Uploaders: Kilian Krause 
-Build-Depends: debhelper (>= 9.20160709~), dh-systemd (>= 1.5), zlib1g-dev, autotools-dev
+Build-Depends: debhelper (>= 9.20160709~), zlib1g-dev, autotools-dev
 Standards-Version: 3.9.5
 Homepage: http://www.irc.org/
 Vcs-Svn: https://anonscm.debian.org/collab-maint/deb-maint/ircd-irc2/
-- 
2.27.0

From f3a7b3caec870e3be993d7913c9111810967d8e9 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 24 Nov 2020 08:11:34 -0500
Subject: [PATCH 2/2] update ircd-irc2.lintian-overrides to use new tag name

---
 debian/changelog   | 7 +--
 debian/ircd-irc2.lintian-overrides | 6 +++---
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index e0db207..9fcf743 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,11 @@
-ircd-irc2 (2.11.2p3~dfsg-5.1) UNRELEASED; urgency=medium
+ircd-irc2 (2.11.2p3~dfsg-6) UNRELEASED; urgency=medium
 
-  * Non-maintainer upload.
+  [ Nicholas D Steeves ]
   * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709)
 already provides this (Closes: #958604).
+  * ircd-irc2.lintian-overrides:
+"package-contains-upstream-install-documentation" no longer exists, so
+use its replacement "package-contains-upstream-installation-documentation".
 
  -- Nicholas D Steeves   Tue, 24 Nov 2020 08:03:21 -0500
 
diff --git a/debian/ircd-irc2.lintian-overrides b/debian/ircd-irc2.lintian-overrides
index 82d533d..08adafd 100644
--- a/debian/ircd-irc2.lintian-overrides
+++ b/debian/ircd-irc2.lintian-overrides
@@ -1,5 +1,5 @@
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
 ircd-irc2: description-synopsis-starts-with-article
 
-- 
2.27.0



Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#975679: mesa-vulkan-drivers: Include v3dv on arm. Include zink on arm and ppc.

2020-11-24 Thread Witold Baryluk

Package: mesa-vulkan-drivers
Version: 20.2.2-1
Severity: normal
X-Debbugs-Cc: witold.bary...@gmail.com

Dear Maintainer,

Mesa 2.2.0 has v3dv Vulkan driver in stable condition, and it just passed
official Khronos confornmance tests for Vulkan 1.0.

I would suggest enabling v3dv vulkan driver on arm64 so it can be used
easily.

It should work on armel and armhf too, and it probably makes sense to
enable it there too. However upstream Mesa CI / CD pipelines only do
builds and tests on arm64.


I would also suggest changing the current restriction of zink to be
expanded to all architectures where there is any Vulkan loader or AMD
Vulkan driver. Currently zink is restricted to be build on amd64, i386
and x32, which is unecassary restriction.

zink should be build additionally on arm64 armel armhf mips64el mipsel
powerpc ppc64 ppc64el s390x sparc64, and possible more (i.e. alpha, hppa,
m68k, sparc64, riscv64), as all of them do have vulkan loaders,
validation layers, and together with `lavapipe` technically vulkan can be
used on all archs that do have LLVM support in some way or form.
In the future zink should also be able to wrok with non-Mesa Vulkan
implementation.



Thank you!


Regards,
Witold

Bug#975678: lyx: Strict imagemagick policies render LyX unusable when working with vector graphics

2020-11-24 Thread Pavel Sanda

Package: lyx
Version: 2.3.2-1
Severity: important

Dear package maintainer(s),

we (LyX developers) are getting repeated reports of LyX's broken handling
of pdf/postscript graphics rendering (LaTeX export works fine).

This is because of debian stringent policy in /etc/ImageMagick-6/policy.xml
disabling ghostscript handling.

This was likely introduced due to ghostcript vulnerabilities couple years
back, which are fixed now, but the fear of new potential vulnerabilities
probably caused the ongoing ban of ghostcript.

While I understand the possible security implications on servers, the current
policy renders LyX unusable for anyone on desktop, who wishes to use eps/pdf
vector graphics, which is typical graphics input format in LaTeX world.

On top of this, if user is not root as well, he can't even override these 
policies.
This puts us in a weird position, that we can't help some users even when
we detect why their documents do not compile anymore.

Would you be willing to make some compromise on systems where users install LyX?
I can imagine different ways, e.g.:
- allow eps/pdf coders when LyX is installed
- ask user when installing LyX whether he wants to to allow such coders
- or at least issue warning that unless admin tweaks policy.xml
  LyX won't function properly.

Or any other approach which would help to solve this issue.

I see that the imagemagick policy patch in question is in buster but not in 
bullseye. Not sure whether it means debian wants to keep future imagemagick 
policies in their vanilla form or it was moved to debconf. In any case I would 
like raise our voice about this problem explicitely.

While this bug is sort of generalized version of #971630 (we also want eps
format to work) and might not be high priority from imagemagick POV (could
be considered a corner case), I file this under LyX as the consequences
are way more serious for its functionality.

Thanks,
Pavel



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

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

Versions of packages lyx depends on:
ii  libc62.28-10
ii  libenchant1c2a   1.6.0-11.1+b1
ii  libgcc1  1:8.3.0-6
ii  libmagic11:5.35-4+deb10u1
ii  libmythes-1.2-0  2:1.2.4-3
ii  libqt5core5a 5.11.3+dfsg1-1+deb10u4
ii  libqt5gui5   5.11.3+dfsg1-1+deb10u4
ii  libqt5svg5   5.11.3-2
ii  libqt5widgets5   5.11.3+dfsg1-1+deb10u4
ii  libstdc++6   8.3.0-6
ii  lyx-common   2.3.2-1
ii  xdg-utils1.1.3-1+deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages lyx recommends:
ii  dvipng   1.15-1.1
ii  evince [pdf-viewer]  3.30.2-3+deb10u1
ii  fonts-lyx2.3.2-1
ii  ghostscript  9.27~dfsg-2+deb10u4
ii  gv [pdf-viewer]  1:3.7.4-2
ii  imagemagick  8:6.9.10.23+dfsg-2.1+deb10u1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+deb10u1
ii  poppler-utils0.71.0-5
ii  preview-latex-style  11.91-2
ii  psutils  1.17.dfsg-4
ii  texlive-fonts-recommended2018.20190227-2
ii  texlive-generic-extra2018.20190227-2
ii  texlive-generic-recommended  2018.20190227-2
ii  texlive-latex-extra  2018.20190227-2
ii  texlive-latex-recommended2018.20190227-2
ii  texlive-science  2018.20190227-2
ii  xpdf [pdf-viewer]3.04-13

Versions of packages lyx suggests:
pn  chktex  
pn  gnuhtml2latex   
pn  groff   
ii  inkscape0.92.4-3
pn  latex2rtf   
ii  librsvg2-bin2.44.10-2.1
pn  libtiff-tools   
pn  linuxdoc-tools  
pn  noweb   
ii  rcs 5.9.4-5
pn  sgmltools-lite  
ii  texlive-plain-generic [tex4ht]  2018.20190227-2
pn  texlive-xetex   
pn  writer2latex
pn  wv  

-- no debconf information

Bug#958604: ircd-irc2: Build-Depends on deprecated dh-systemd which is going away

2020-11-24 Thread Nicholas D Steeves

Control: tag -1 + patch

Hi,

bi...@debian.org writes:

> Source: ircd-irc2
> Severity: normal
> User: pkg-systemd-maintain...@lists.alioth.debian.org
> Usertags: dh-systemd-removal
>
> Hi,
>
> your package ircd-irc2 declares a build dependency on dh-systemd.
> dh-systemd was merged into debhelper in version 9.20160709 [1] and since
> stretch, dh-systemd is an empty transitional package.
>
> For bullseye we intend to drop this empty transitional package.
>
> Once we drop dh-systemd, this bug report will become RC.
>
> Please update your package accordingly. The change should be as simple as
> replacing the build dependency on dh-systemd with a build dependency on
> debhelper (>= 9.20160709).
>

Here is a patch that fixes this bug plus one lintian error.

From f3a7b3caec870e3be993d7913c9111810967d8e9 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 24 Nov 2020 08:11:34 -0500
Subject: [PATCH] update ircd-irc2.lintian-overrides to use new tag name

---
 debian/changelog   | 7 +--
 debian/ircd-irc2.lintian-overrides | 6 +++---
 2 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index e0db207..9fcf743 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,11 @@
-ircd-irc2 (2.11.2p3~dfsg-5.1) UNRELEASED; urgency=medium
+ircd-irc2 (2.11.2p3~dfsg-6) UNRELEASED; urgency=medium
 
-  * Non-maintainer upload.
+  [ Nicholas D Steeves ]
   * Drop unnecessary dh-systemd build-dep, because debhelper (>= 9.20160709)
 already provides this (Closes: #958604).
+  * ircd-irc2.lintian-overrides:
+"package-contains-upstream-install-documentation" no longer exists, so
+use its replacement "package-contains-upstream-installation-documentation".
 
  -- Nicholas D Steeves   Tue, 24 Nov 2020 08:03:21 -0500
 
diff --git a/debian/ircd-irc2.lintian-overrides b/debian/ircd-irc2.lintian-overrides
index 82d533d..08adafd 100644
--- a/debian/ircd-irc2.lintian-overrides
+++ b/debian/ircd-irc2.lintian-overrides
@@ -1,5 +1,5 @@
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
-ircd-irc2: package-contains-upstream-install-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.appendix.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.sgml.gz
+ircd-irc2: package-contains-upstream-installation-documentation usr/share/doc/ircd-irc2/INSTALL.txt.gz
 ircd-irc2: description-synopsis-starts-with-article
 
-- 
2.27.0



Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#963654: pillow: FTBFS with Sphinx 3.1: /<>/docs/conf.py:292: RemovedInSphinx40Warning: The app.add_javascript() is deprecated. Please use app.add_js_file() instead.

2020-11-24 Thread s3v

Dear Maintainers,


both testing and sid have Sphinx 3.3 now and this package builds fine... [1]

Kind Regards

[1] https://buildd.debian.org/status/package.php?p=pillow=sid

Bug#975677: sawfish: requires gdk-pixbuf-xlib-2.0.pc but does not build-depend on a package containing it

Source: sawfish
Version: 1:1.11.90-1.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

To reproduce: build sawfish on a release architecture in unstable (I used
amd64).

> checking for gtk+-2.0 >= 2.24.0
> ... yes
> checking for gdk-pixbuf-xlib-2.0 >= 2.23.0
> ... no
> configure: error: cannot locate gdk-pixbuf-xlib-2.0 >= 2.24.0

This is because the deprecated gdk-pixbuf-xlib-2.0 module used to be
pulled in as an indirect dependency by GTK 2. However, GTK 2 doesn't
actually use that module, and as a result libgtk2.0-dev no longer depends
on it, causing sawfish to fail to build.

In the short term, please build-depend on either

libgdk-pixbuf-xlib-2.0-dev | libgdk-pixbuf2.0-dev

if you want backports to older Debian to be possible, or

libgdk-pixbuf-xlib-2.0-dev

if not. That's enough to close this bug. (This might also be a good
opportunity to check that all the other packages required at build time
are in the Build-Depends.)

For the longer term, the upstream maintainers of gdk-pixbuf have deprecated
the gdk-pixbuf-xlib-2.0 module[0] and do not intend to maintain it further,
so it would be better if sawfish can stop using it.

Thanks,
smcv

[0] https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

Bug#974762: apt-listbugs: [INTL:pt] Portuguese translation for debconf messages

2020-11-24 Thread Francesco Poli

On Sun, 22 Nov 2020 17:49:30 + tra...@debianpt.org wrote:

> Goos afternoon,
> 
> thanks for reviewing this.
> I'm sending a new version.

Thank you.
Some doubts remain.

First doubt
===

#. TRANSLATORS: %{plist} is a comma-separated list of %{npkgs} packages to be 
pinned.
#: ../lib/aptlistbugs/logic.rb:576 ../lib/aptlistbugs/logic.rb:655
msgid ""
"The following %{npkgs} package will be pinned:\n"
" %{plist}\n"
"Are you sure?"
msgid_plural ""
"The following %{npkgs} packages will be pinned:\n"
" %{plist}\n"
"Are you sure?"
msgstr[0] ""
"O seguinte %{npkgs} pacote será marcado como fixo:\n"
" %{plist}\n"
"Tem a certeza?"
msgstr[1] ""
"Os seguintes %{npkgs} pacotes serão marcados como fixos:\n"
" %{plist}\n"
"Tem a certeza?"

Why "marcado come fixo"? The phrase "will be pinned" has been
translated as "será fixado" elsewhere...
I changed the translation into:

msgstr[0] ""
"O seguinte %{npkgs} pacote será fixado:\n"
" %{plist}\n"
"Tem a certeza?"
msgstr[1] ""
"Os seguintes %{npkgs} pacotes serão fixados:\n"
" %{plist}\n"
"Tem a certeza?"

Please speak up, in case I have to revert this change.

Second doubt

#. TRANSLATORS: %{blist} is a comma-separated list of %{nbugs} bugs to be 
dodged.
#: ../lib/aptlistbugs/logic.rb:614
msgid ""
"The following %{nbugs} bug will be dodged:\n"
" %{blist}\n"
"Are you sure?"
msgid_plural ""
"The following %{nbugs} bugs will be dodged:\n"
" %{blist}\n"
"Are you sure?"
msgstr[0] ""
"O seguinte %{nbugs} será evitado:\n"
" %{blist}\n"
"Tem a certeza?"
msgstr[1] ""
"Os seguintes %{nbugs} serão evitados:\n"
" %{blist}\n"
"Tem a certeza?"

The word "bug" is still missing from the translations.
I changed them into:

msgstr[0] ""
"O seguinte %{nbugs} bug será evitado:\n"
" %{blist}\n"
"Tem a certeza?"
msgstr[1] ""
"Os seguintes %{nbugs} bugs serão evitados:\n"
" %{blist}\n"
"Tem a certeza?"

Please speak up, in case I have to revert this change.

Third doubt
===

#: ../lib/aptlistbugs/logic.rb:670
msgid "There are no dodge/pin/ignore operations to undo. Ignoring %s command."
msgstr ""
"Não existem operações evitar/fixar/igonar para desfazer. A ignorar o comando "
"%s."

This looks like a typo ("igonar").
I changed the translation into:

msgstr ""
"Não existem operações evitar/fixar/ignorar para desfazer. A ignorar o comando "
"%s."

Please speak up, in case I have to revert this change.

Fourth doubt

#: ../lib/aptlistbugs/logic.rb:707
msgid ""
" d .. - dodge bugs  by pinning affected pkgs\n"
" (restart APT session to enable).\n"
msgstr ""
" d .. - evitar bugs  ao fixar os pacotes afetados\n"
" (reiniciar a sessão APT para activar).\n"

Why "afetados"? For better consistency, I changed the translation into:

msgstr ""
" d .. - evitar bugs  ao fixar os pacotes afectados\n"
" (reiniciar a sessão APT para activar).\n"

Please speak up, in case I have to revert this change.

Fifth doubt
===

#. TRANSLATORS: %{packgl} is a list of packages.
#: ../lib/aptlistbugs/logic.rb:780
msgid "%{packgl} will be pinned. Restart APT session to enable"
msgstr "%{packgl} serão fixados. Reiniciar a sessão APT para ativar"

Why "ativar"? For better consistency, I changed the translation into:

msgstr "%{packgl} serão fixados. Reiniciar a sessão APT para activar"

Please speak up, in case I have to revert this change.

Thanks for your contributions!

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

pgpjbB_eVVkdh.pgp
Description: PGP signature

Bug#975676: ITP: python-gftools -- Google Fonts Tools

2020-11-24 Thread Romain Porte

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org

* Package name: python-gftools
  Version : 0.5.1
  Upstream Author : Google Fonts Tools Authors
* URL : https://github.com/googlefonts/gftools
* License : Apache-2.0
  Programming Lang: Python
  Description : Google Fonts Tools

Google Fonts Tools is a set of command-line tools for testing font
projects.

I intent to co-maintain this package with the Debian Fonts team. This
package can be used in fonts source packages as it is already done
by some upstreams to fix font metadata, perform hinting, etc.


signature.asc
Description: PGP signature

Bug#975675: ITP: python-absl -- Abseil Python Common Libraries

2020-11-24 Thread Romain Porte

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org

* Package name: python-absl
  Version : 0.11.0
  Upstream Author : The Abseil Authors
* URL : https://abseil.io/
* License : Apache-2.0
  Programming Lang: Python
  Description : Abseil Python Common Libraries

This package is required as a dependency for python3-gftools, a set of
tools for interacting with fonts. This tool can then be used to clean
fonts metadata in Debian font packages.

I intent to co-maintain this package under the Debian Fonts packaging
team, as this package will mainly be used for gftools.


signature.asc
Description: PGP signature

Bug#969672: gnutls28: please upgrade to guile-3.0 soon, if feasible

2020-11-24 Thread Rob Browning

Hmm, didn't see this until now (don't think I received a mail from the
bug tracker).

> Andreas Metzler  writes:

> a full build fails reproducibly for me when building in /dev/shm.

Building in /dev/shm?  And on what architecture, etc.

> I did a test upload to experimental yesterday, it also failed on
> arm64, since a guile test did hang.

If we think it's arm64 specific, I can try that on one of the
porterboxes -- think a a sid chroot should suffice?

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#975115: webext-dav4tbsync and webext-tbsync out of sync

2020-11-24 Thread Carl Suster

Package: webext-dav4tbsync
Followup-For: Bug #975115

Hi Mechtilde,

I've just upgraded to tbsync 2.19-1 and now I have the opposite problem: tbsync
recognises that dav4tbsync is is installed, but claims that eas4tbsync is
missing.

The situation for the EAS provider is now similar to what I reported above. The
debug log shows:

** Wed Nov 25 2020 09:14:49 GMT+1100 (AEDT) **
[EventLog] : FAILED to load provider 
API version mismatch, TbSync@2.4 vs eas@Beta 2.4

** Wed Nov 25 2020 09:14:52 GMT+1100 (AEDT) **
[Loaded provider] : dav::CalDAV & CardDAV (1.23)

There's also a message in the log concerning the DAV provider, though it's
perhaps unrelated:

Component returned failure code: 0x8000 (NS_ERROR_UNEXPECTED) 
[nsIPrefBranch.getCharPref]


promisifiedHttpRequest/<@chrome://dav4tbsync/content/includes/network.js:515:64

promisifiedHttpRequest@chrome://dav4tbsync/content/includes/network.js:494:12
sendRequest@chrome://dav4tbsync/content/includes/network.js:428:33

I wonder if it's just that the providers need a stricter versioned dependency
relationship with the main tbsync package to reflect whatever API version
checks tbsync is doing internally?

Cheers,
Carl

-- System Information:
thunderbird1:78.5.0-1
webext-tbsync  2.19-1
webext-dav4tbsync  1.23-1
webext-eas4tbsync  1.20-1

Bug#939763: sphinxsearch: Still maintained (same version since stretch)?

2020-11-24 Thread Vasyl Gello

Dear colleagues,

>It has unsafe defaults in sample files with listener
> listening to 0.0.0.0, cf. #939762.

Unfortunately version 3.1.1 is also prone to #939762.

It is not maintained anymore so there are two alternatives:

* Switch to Manticore Search, the maintained fork by Manticore Software.
* Back-port critical patches to Sphinx Search

Given that the current maintainer is not interested, I'd phase out Sphinx and 
rolled Manticore instead.

I will be able to package Manticore after I get in with Kodi.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

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

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

signature.asc
Description: PGP signature

Bug#975674: RM: nvidia-settings [ppc64el armhf i386] -- ROM; ANAIS; architecture not supported by nvidia-graphics-drivers

2020-11-24 Thread Andreas Beckmann

Package: ftp.debian.org
Severity: normal

please remove the cruft binary package nvidia-settings
from the architectures were it is no longer built.
Don't remove the nvidia-settings source package from these
architectures, there is still libnvctrl0 etc. being built.

The architectures in question still have their
nvidia-settings-legacy-### or nvidia-settings-tesla-###
that is compatible with the corresponding driver packages.

  libxnvctrl-dev  | 450.80.02-1   | unstable | amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x
  libxnvctrl0 | 450.80.02-1   | unstable | amd64, arm64, armel, 
armhf, i386, mips64el, mipsel, ppc64el, s390x
  nvidia-settings | 440.59-1  | unstable | source
* nvidia-settings | 440.59-1  | unstable/contrib | ppc64el ***
  nvidia-settings | 440.100-1 | unstable | source
* nvidia-settings | 440.100-1 | unstable/contrib | armhf, i386 ***
  nvidia-settings | 450.80.02-1   | unstable | source
  nvidia-settings | 450.80.02-1   | unstable/contrib | amd64, arm64

Thanks

Andreas

Bug#975453: mutter: Valve Source engine games no have fullscreen (Counter Strike Global Offensive)

2020-11-24 Thread blogdron

OHH SOYYY. I paste broken script

This fixed and tested and works fine now
```sh
#! /bin/bash

sudo apt build-dep mutter  &&
sudo apt install  rpm2cpio &&
mkdir  new-mutter  &&
cd new-mutter  &&
mkdir  rpm-mutter  &&
cd rpm-mutter  &&
wget -P ./ "
https://kojipkgs.fedoraproject.org//packages/mutter/3.38.1/3.fc33/src/mutter-3.38.1-3.fc33.src.rpm;
&&
sync  &&
rpm2cpio mutter-3.38.1-3.fc33.src.rpm | cpio -i --make-directories &&
cd ../ &&
apt source mutter  &&
cp ./rpm-mutter/0001-window-props-Also-check-for-actual-values-change.patch
./mutter-3.38.1/debian/patches/  &&
echo "0001-window-props-Also-check-for-actual-values-change.patch" >>
./mutter-3.38.1/debian/patches/series  &&
cd  mutter-3.38.1  &&
debuild -b -uc -us &&
while true; do
read -p "Do you wish to install new deb package witch fix fullscreen?
[yes/no]" yn
case $yn in
[Yy]* ) cd ../ && sudo dpkg -i ./*.deb && echo "NOW NEED RESTART
YOU GNOME SESSION" ; break;;
[Nn]* ) exit;;
* ) echo "Please answer yes or no.";;
esac
done
```

Sorry :)

Bug#957919: w-scan and GCC 10

2020-11-24 Thread Rob Moss

Greetings,

As of September 2017, w-scan is no longer being developed. There is a fork
called w_scan2, and the latest version (1.0.9, May 2020) compiles
successfully with GCC 10. Would it be possible to package this instead, so
that a w_scan equivalent is retained in Debian Bullseye?

Another alternative would be to see whether the (very few) changes made in
w_scan2 to make it compile with GCC 10 might fix this bug in w-scan? Here
is a link to the relevant commit, which replaces 3 lines in src/si_types.h:

https://github.com/stefantalpalaru/w_scan2/commit/7440dd5c161eaac27c1a5488aa4cab7ba5934345

Sincerely,
Rob

Bug#975673: fbxkb: requires gdk-pixbuf-xlib-2.0.pc but does not build-depend on a package containing it

Source: fbxkb
Version: 0.6-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

To reproduce: build fbxkb on a release architecture in unstable (I used
amd64).

> make[1]: Entering directory '/<>'
> Package gdk-pixbuf-xlib-2.0 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `gdk-pixbuf-xlib-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'gdk-pixbuf-xlib-2.0' found

This is because the deprecated gdk-pixbuf-xlib-2.0 module used to be
pulled in as an indirect dependency by GTK 2. However, GTK 2 doesn't
actually use that module, and as a result libgtk2.0-dev no longer depends
on it, causing fbxkb to fail to build.

In the short term, please build-depend on either

libgdk-pixbuf-xlib-2.0-dev | libgdk-pixbuf2.0-dev

if you want backports to older Debian to be possible, or

libgdk-pixbuf-xlib-2.0-dev

if not. That's enough to close this bug. (This might also be a good
opportunity to check that all the other packages required at build time
are in the Build-Depends.)

For the longer term, the upstream maintainers of gdk-pixbuf have deprecated
the gdk-pixbuf-xlib-2.0 module[0] and do not intend to maintain it further,
so it would be better if fbxkb can stop using it.

Thanks,
smcv

[0] https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

Bug#975672: xylib: FTBFS against boost_1.74

Package: xylib
Version: 1.3-1.1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

conftest.cpp:28:10: fatal error: boost/detail/endian.hpp: No such file or 
directory
   28 | #include 
  |  ^
compilation terminated.


It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/xylib_1.3-1.1_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9d1ERHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/waOURAAh0gMvgbDF86uhGQVolROmamNgpIP163n
8FYc2Ad7QjLXCjY1gJzjvwPj+H/AGixXGowbedBMTPAJsy4KevcWahUtjVUIQtfm
AmLeY3D8N/eJxumDfMGbXPuBpju2kbuCI2n1Thld/Zym4lmVDn/ecv2ul7g+omLg
D0Rbuw+FahHn3AmJb+SHqvcPAxtmJhlnB61kxCFu/BabRfjVCW4YH0DT+ajEM/OE
JQXuuqbMYLMDHwLLsjrZ9WQBz90ZxGYlaJgSTcomwrVzZpHIL70DUfUsfZbSrLa3
802lM9sSnqDLE58woCRnqSmKPil4Js2uX/a/mL+CX33UVqepM5YcRaLpa7lr4rzN
k4wfKxhbjWyt7J22XrcGwmmhVahXFxuiIoT9fTWVuvtJFzQzdzq9tO9XvqFnclzN
0IoLIDzARSxUeRp/56p5RZ7DPY9fSm3WbPPTEhqlpJyZVKaG4VoBi2rCPGdXJc+i
xgslChddtuvBTv1uc3kALGrw9W0WeJEhe3Io97Zopd5MZn1YqbkHinpOz0CrMEva
MMaFQlfCkhOen03KJGi0Ck/kXm9sv7LlioPfcfxClfS/N/BaPo108ri+II7cdOz3
TPb4P3BAK8m6LtqhRl3Wzq3O3d/yh+x/9MewYUzdR7T+S16SSBkExfxClSGD6vqM
4oysi1HTyHs=
=8gO2
-END PGP SIGNATURE-

Bug#975671: xqf: requires gdk-pixbuf-xlib-2.0.pc but does not build-depend on a package containing it

Source: xqf
Version: 1.0.6-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

To reproduce: build xqf on a release architecture in unstable (I used
amd64).

> checking for gtk+-2.0 >= 2.0.0 gdk-pixbuf-xlib-2.0 x11... no
> configure: error: Package requirements (gtk+-2.0 >= 2.0.0 gdk-pixbuf-xlib-2.0 
> x11) were not met:
> 
> No package 'gdk-pixbuf-xlib-2.0' found

This is because the deprecated gdk-pixbuf-xlib-2.0 module used to be
pulled in as an indirect dependency by GTK 2. However, GTK 2 doesn't
actually use that module, and as a result libgtk2.0-dev no longer depends
on it, causing xqf to fail to build.

In the short term, please build-depend on either

libgdk-pixbuf-xlib-2.0-dev | libgdk-pixbuf2.0-dev

if you want backports to older Debian to be possible, or

libgdk-pixbuf-xlib-2.0-dev

if not. That's enough to close this bug. (This might also be a good
opportunity to check that all the other packages required at build time
are in the Build-Depends.)

For the longer term, the upstream maintainers of gdk-pixbuf have deprecated
the gdk-pixbuf-xlib-2.0 module[0] and do not intend to maintain it further,
so it would be better if xqf can stop using it.

Thanks,
smcv

[0] https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

Bug#975661: rquantlib: FTBFS against boost_1.74

2020-11-24 Thread Dirk Eddelbuettel



Hi Anton,

On 24 November 2020 at 20:53, Anton Gladky wrote:
| Package: rquantlib
| Version: 0.4.12-1
| Severity: important
| Tags: ftbfs
| User: team+bo...@tracker.debian.org
| Usertags: boost174
| 
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA512
| 
| Dear maintainer,
| 
| it was discovered that your package failed to build
| against boost_1.74. Logs can be found here [1]. Most relevant
| part is probably this:

Thanks, that is pertinent. The error is actually from the final step where R
tries to load the package it just built.  So the simplest solution then is to
check that libquantlib0-dev was also / already rebuilt against the same Boost
version.

Can you check that? The logs below are inconclusive but it looks like 1.74
comes from a side repo?

I could easily adjust the build-dependency. Can we test with a rebuilt
build-dependency? 

Dirk
 
 
| =
| 
| installing to 
/<>/debian/r-cran-rquantlib/usr/lib/R/site-library/00LOCK-rquantlib-0.4.12/00new/RQuantLib/libs
| ** R
| ** data
| ** demo
| ** inst
| ** byte-compile and prepare package for lazy loading
| ** help
| *** installing help indices
| ** building package indices
| ** testing if installed package can be loaded from temporary location
| 
|  *** caught segfault ***
| address 0x7f4c6172ed80, cause 'invalid permissions'
| 
| Traceback:
|  1: dyn.load(file, DLLpath = DLLpath, ...)
|  2: library.dynam(lib, package, package.lib)
|  3: loadNamespace(package, lib.loc)
|  4: doTryCatch(return(expr), name, parentenv, handler)
|  5: tryCatchOne(expr, names, parentenv, handlers[[1L]])
|  6: tryCatchList(expr, classes, parentenv, handlers)
|  7: tryCatch({attr(package, "LibPath") <- which.lib.locns <- 
loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos, deps, 
exclude, include.only)}, error = function(e) {P <- if (!is.null(cc <- 
conditionCall(e))) paste(" in", deparse(cc)[1L])else ""msg <- 
gettextf("package or namespace load failed for %s%s:\n %s", 
sQuote(package), P, conditionMessage(e))if (logical.return) 
message(paste("Error:", msg), domain = NA)else stop(msg, call. = FALSE, 
domain = NA)})
|  8: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return = 
TRUE)
|  9: withCallingHandlers(expr, packageStartupMessage = function(c) 
tryInvokeRestart("muffleMessage"))
| 10: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
character.only = TRUE, logical.return = TRUE))
| 11: doTryCatch(return(expr), name, parentenv, handler)
| 12: tryCatchOne(expr, names, parentenv, handlers[[1L]])
| 13: tryCatchList(expr, classes, parentenv, handlers)
| 14: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch))) 
call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix <- 
paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type = 
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L + 
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if 
(w > LONG) prefix <- paste0(prefix, "\n  ")}else prefix <- 
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent && 
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile) 
   .Internal(printDeferredWarnings())}invisible(structure(msg, class = 
"try-error", condition = e))})
| 15: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
character.only = TRUE, logical.return = TRUE)))
| 16: tools:::.test_load_package("RQuantLib", 
"/<>/debian/r-cran-rquantlib/usr/lib/R/site-library/00LOCK-rquantlib-0.4.12/00new")
| An irrecoverable exception occurred. R is aborting now ...
| Segmentation fault
| ERROR: loading failed
| 
| =
| 
| 
| 
| It is planned to push boost_1.74 as the default version in Debian/Bullseye.
| 
| [1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/rquantlib_0.4.12-1_unstable_boost.log
| 
| Best regards
| 
| Anton
| 
| - -- System Information:
| Debian Release: bullseye/sid
|   APT prefers testing
|   APT policy: (500, 'testing')
| Architecture: amd64 (x86_64)
| Foreign Architectures: i386
| 
| Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
| Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
| Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not 
set
| Shell: /bin/sh linked to /bin/dash
| Init: systemd (via /run/systemd/system)
| LSM: AppArmor: enabled
| 
| -BEGIN PGP SIGNATURE-
| 
| iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9ZMERHGdsYWRrQGRl
| Ymlhbi5vcmcACgkQ0+Fzg8+n/wbvfQ//fnWf/HRrIIyOKTdgCXdZDvRa3bQfVyCQ
| 1RqYyROsSEqt6IFYR3WUlSA/dZmMLilghsZN2AACUJfKakZbXutNmJQ9hljIB6Qt
|

Bug#975670: uhd: FTBFS against boost_1.74

Package: uhd
Version: 3.15.0.0-3
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[120/553] /usr/bin/c++ -DBOOST_ALL_NO_LIB 
-DBOOST_ASIO_DISABLE_STD_EXPERIMENTAL_STRING_VIEW 
-DBOOST_ASIO_DISABLE_STD_STRING_VIEW -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK 
-DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK 
-DBOOST_SERIALIZATION_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK 
-DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DHAVE_CONFIG_H -DUHD_DLL_EXPORTS 
-DUHD_LOG_CONSOLE_COLOR -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 
-DUHD_LOG_MIN_LEVEL=1 -DUHD_RFNOC_ENABLED -Iinclude 
-I/<>/host/include -I/<>/host/lib/include 
-Ilib/ic_reg_maps -I/<>/host/lib/convert -Ilib/convert 
-I/<>/host/lib/rfnoc/nocscript -Ilib/rfnoc/nocscript 
-I/<>/host/lib/usrp 
-I/<>/host/lib/usrp/common/ad9361_driver 
-I/<>/host/lib/usrp/common -Ilib/transport/nirio/lvbitx 
-I/usr/include/libusb-1.0 -I/<>/host/lib/deps/rpclib/include -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden 
-fvisibility-inlines-hidden -O2 -g -DNDEBUG -fPIC   -Wall -Wextra 
-Wsign-compare -std=gnu++14 -MD -MT 
lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o -MF 
lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o.d -o 
lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o -c 
/<>/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp
FAILED: lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o 
/usr/bin/c++ -DBOOST_ALL_NO_LIB 
-DBOOST_ASIO_DISABLE_STD_EXPERIMENTAL_STRING_VIEW 
-DBOOST_ASIO_DISABLE_STD_STRING_VIEW -DBOOST_ATOMIC_DYN_LINK 
-DBOOST_CHRONO_DYN_LINK -DBOOST_DATE_TIME_DYN_LINK 
-DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_FILESYSTEM_DYN_LINK 
-DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK 
-DBOOST_SERIALIZATION_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK 
-DBOOST_UNIT_TEST_FRAMEWORK_DYN_LINK -DHAVE_CONFIG_H -DUHD_DLL_EXPORTS 
-DUHD_LOG_CONSOLE_COLOR -DUHD_LOG_CONSOLE_LEVEL=2 -DUHD_LOG_FILE_LEVEL=2 
-DUHD_LOG_MIN_LEVEL=1 -DUHD_RFNOC_ENABLED -Iinclude 
-I/<>/host/include -I/<>/host/lib/include 
-Ilib/ic_reg_maps -I/<>/host/lib/convert -Ilib/convert 
-I/<>/host/lib/rfnoc/nocscript -Ilib/rfnoc/nocscript 
-I/<>/host/lib/usrp 
-I/<>/host/lib/usrp/common/ad9361_driver 
-I/<>/host/lib/usrp/common -Ilib/transport/nirio/lvbitx 
-I/usr/include/libusb-1.0 -I/<>/host/lib/deps/rpclib/include -g 
-O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden 
-fvisibility-inlines-hidden -O2 -g -DNDEBUG -fPIC   -Wall -Wextra 
-Wsign-compare -std=gnu++14 -MD -MT 
lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o -MF 
lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o.d -o 
lib/CMakeFiles/uhd.dir/rfnoc/dma_fifo_block_ctrl_impl.cpp.o -c 
/<>/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp
/<>/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp: In constructor 
‘dma_fifo_block_ctrl_impl::dma_fifo_block_ctrl_impl(const 
uhd::rfnoc::make_args_t&)’:
/<>/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp:61:21: error: ‘_1’ 
was not declared in this scope
   61 | _1,
  |  

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/uhd_3.15.0.0-3_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9c/4RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYaPRAAgiVWgH2O5xY6ooneLxMyQjPPV0/WL9im
feBkYiyJ0kC/QYMRQQ3d1TcKnlPUWRRnRf9+BPm+chje6OL6sBZN8kU3D1+C/6W8
qv0wuFAGuOYeDTIrB84+TGbTJcBDR+iuGMl1k5QhqoFC8UwjEOFKN4/VrhO2VwTy
clux/esTomVuL4HRDDOo6Q43rHJpqLtM9J0qCY1TDf4lCxC4k9L/0gYH5MP5fOkD
if/TxQaevzL8sMCClxo0/rbeqWX2aDcqetBagUcq8oeM/3LaMqf0APWcRer6dxXr
e24Tjd1q9sowAk0YrISayAv5/M0MRGK4nXX8FNvyW2PaZdJsFoZSeRpK0fuMQcm2
4gvGQfPgtHcJuM55MtWC/e3hL9RrbDkUMSXJV5HYtflISqSe/OlGb51dgdXzIWqo
wjOncxh/8Ns+0dbg+x0C9DmxDHeYnUMXpoM/YJYmqtwNUG7r2GQWrqFA2lSPmsoY
d2dAfaMLun/t4HnJw/Kq2ftnH9ED3RooaBkqDYoYsyRPdWRZ3qwEPRCdu7XQXd9U
2Ju5+LsfepMmehRkPdmPPlBe/I1ndlzTXHn2wEqdh4NzAMKpGBJpWOqjWiFBM2G4
5kp2p1y/d+cyEvTXZ8/wqaQxrP1xVnn7Yb86H23ABRJR20FKZdxJCJUTQ/DMy1Js

Bug#975453: mutter: Valve Source engine games no have fullscreen (Counter Strike Global Offensive)

2020-11-24 Thread blogdron

Just notice :)

Hello again. In Fedora 33 bug fixed i  get patch from fedora source package
and add it in debian mutter source,
next i rebuild mutter and install new custom deb packages and restart
restart gnome session.

It fixed this problem  i test cs:go game and sdl2 applications all works
fine =)

i wrote script for get/patch/build and install

```sh
#! /bin/bash

sudo apt build-dep mutter  &&
sudo apt install  rpm2cpio &&
mkdir  new-mutter  &&
cd new-mutter  &&
mkdir  rpm-mutter  &&
cd rpm-mutter  &&
wget -P ./ "
https://kojipkgs.fedoraproject.org//packages/mutter/3.38.1/3.fc33/src/mutter-3.38.1-3.fc33.src.rpm;
&&
sync  &&
rpm2cpio mutter-3.38.1-3.fc33.src.rpm | cpio -i --make-directories &&
cd ../ &&
apt source mutter  &&
cp ./rpm-mutter/0001-window-props-Also-check-for-actual-values-change.patch
./mutter-3.38.1/debian/patches/  &&
echo "0001-window-props-Also-check-for-actual-values-change.patch" >>
./mutter-3.38.1/debian/patches/series  &&
cd  mutter-3.38.1  &&
debuild -b -uc -us &&
while true; do
read -p "Do you wish to install new deb package witch fix fullscreen?
[yes/no]" yn
case $yn in
[Yy]* ) cd ../ && sudo dpkg -i ./*.deb && echo "NOW NEED RESTART
YOU GNOME SESSION" break;;
[Nn]* ) exit;;
* ) echo "Please answer yes or no.";;
esac
done
```

I do not call for this solution, but it can help those who are very
important that they have full-screen applications working right now and
they cannot wait.

p.s. Sorry for my english, I am using an online translator for this text. =)

dron  ^.^

Bug#975417: updating metadata for version tracking

2020-11-24 Thread Steve McIntyre

Control: fixed -1 37-6
thanks

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"We're the technical experts.  We were hired so that management could
 ignore our recommendations and tell us how to do our jobs."  -- Mike Andrews

Bug#975665: Corrected message

Excuse me for the wrong template in the initial message.
Here is the fixed version:

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[ 16%] Building C object
src/qhull/CMakeFiles/qhullstatic.dir/src/libqhull_r/rboxlib_r.c.o
cd /<>/obj-x86_64-linux-gnu/src/qhull && /usr/bin/cc
-DSLIC3R_GUI -DUNICODE -DWXINTL_NO_GETTEXT_MACRO -D_UNICODE
-DwxNO_UNSAFE_WXSTRING_CONV -DwxUSE_UNICODE
-I/<>/src/qhull/src -I/<>/src
-I/<>/obj-x86_64-linux-gnu/src/platform
-I/<>/src/clipper -I/<>/src/polypartition
-isystem /usr/include/eigen3 -g -O2
-fdebug-prefix-map=/<>=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3
-DNDEBUG -fPIC -Werror=return-type -Wno-ignored-attributes
-Wno-unknown-pragmas -o
CMakeFiles/qhullstatic.dir/src/libqhull_r/rboxlib_r.c.o -c
/<>/src/qhull/src/libqhull_r/rboxlib_r.c
/<>/src/admesh/stlinit.cpp:31:10: fatal error:
boost/detail/endian.hpp: No such file or directory
   31 | #include 

Maybe just changing the header to  can
fix the problem.

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/slic3r-prusa_2.2.0+dfsg1-3_unstable_boost.log

Best regards

Anton

Bug#975425: buster-pu: package efivar/32-2+deb10u1

2020-11-24 Thread Steve McIntyre

Hey Adam,

On Tue, Nov 24, 2020 at 08:52:20PM +, Adam Barratt wrote:
>Control: tags -1 + confirmed
>
>Hi,
>
>On Sun, 2020-11-22 at 02:54 +, Steve McIntyre wrote:
>> I'd like to upload a stable update for efivar, with two (sets of)
>> fixes backported from upstream.
>> 
>>  * Firstly, there's a simple initialisation fix to fix some possible
>>crashes.
>> 
>>  * Secondly, there's support for newer systems that need extra NVME
>>support doing device lookups. (#975417). This is an important
>>update for supporting installation and boot on those new
>>systems. The reporter of the bug has tested with test packages and
>>all looks good.
>
>The metadata for #975417 implies that it still affects unstable. From
>reading the bug log and your mail above I assume it's simply missing a
>fixed version.

Exactly, yes.

>Assuming that's the case, please go ahead but please also fix the
>metadata to more accurately reflect the situation.

Will do, thanks!

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Bug#975425: buster-pu: package efivar/32-2+deb10u1

2020-11-24 Thread Adam D. Barratt

Control: tags -1 + confirmed

Hi,

On Sun, 2020-11-22 at 02:54 +, Steve McIntyre wrote:
> I'd like to upload a stable update for efivar, with two (sets of)
> fixes backported from upstream.
> 
>  * Firstly, there's a simple initialisation fix to fix some possible
>crashes.
> 
>  * Secondly, there's support for newer systems that need extra NVME
>support doing device lookups. (#975417). This is an important
>update for supporting installation and boot on those new
>systems. The reporter of the bug has tested with test packages and
>all looks good.

The metadata for #975417 implies that it still affects unstable. From
reading the bug log and your mail above I assume it's simply missing a
fixed version.

Assuming that's the case, please go ahead but please also fix the
metadata to more accurately reflect the situation.

Regards,

Adam

Bug#959469: buster-pu: package openssl/1.1.1g-1

2020-11-24 Thread Sebastian Andrzej Siewior

On 2020-11-24 20:18:15 [+], Adam D. Barratt wrote:
> That would be preferable at this point, yes, sorry. We should try and
> make sure it's sorted soon afterwards though, to avoid things getting
> stuck again.

I will set up an alarm on my side :)

> At some point, could we please have a combined / single diff between
> the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
> assume)?

Sure. I will prepare one tomorrow.

> Regards,
> 
> Adam

Sebastian

Bug#975669: xpra.os_util.is_systemd_pid1() returns False on systemd

2020-11-24 Thread Sergio Gelato

Package: xpra
Version: 2.4.3+dfsg1-1

(The same code is in upstream svn trunk.)

Consider this:

$ python
Python 2.7.16 (default, Oct 10 2019, 22:02:15) 
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xpra.os_util import is_systemd_pid1
>>> is_systemd_pid1()
False
>>> 
$ cat /proc/1/cmdline
/sbin/init$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Apr 27  2020 /sbin/init -> /lib/systemd/systemd*

The test is confused by the symlink and returns a false negative.

I had been wondering why systemd-run wasn't being used even if I explicitly 
asked for it.

Fix with caution, as doing so may expose latent bugs.

Bug#975667: supercollider: FTBFS against boost_1.74

Package: supercollider
Version: 3.10.4+repack-1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[1/558] /usr/bin/c++ -DBOOST_CHRONO_HEADER_ONLY -DBOOST_NO_AUTO_PTR 
-DSC_DATA_DIR=\"/usr/share/SuperCollider\" -I../external_libraries/boost -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG   
-fschedule-insns2 -fomit-frame-pointer -Wreturn-type -fno-math-errno 
-fno-signaling-nans -fsigned-zeros -fno-associative-math -pthread 
-fvisibility=hidden -std=gnu++11 -MD -MT 
external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o -MF 
external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o.d -o 
external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o -c 
../external_libraries/oscpack_build.cpp
FAILED: external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o 
/usr/bin/c++ -DBOOST_CHRONO_HEADER_ONLY -DBOOST_NO_AUTO_PTR 
-DSC_DATA_DIR=\"/usr/share/SuperCollider\" -I../external_libraries/boost -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O2 -g -DNDEBUG   
-fschedule-insns2 -fomit-frame-pointer -Wreturn-type -fno-math-errno 
-fno-signaling-nans -fsigned-zeros -fno-associative-math -pthread 
-fvisibility=hidden -std=gnu++11 -MD -MT 
external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o -MF 
external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o.d -o 
external_libraries/CMakeFiles/oscpack.dir/oscpack_build.cpp.o -c 
../external_libraries/oscpack_build.cpp
../external_libraries/oscpack_build.cpp:1:10: fatal error: 
boost/detail/endian.hpp: No such file or directory
1 | #include 
  |  ^~~~
 
Maybe just changing the header to  can fix the 
problem.

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/supercollider_3.10.4+repack-1_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9csYRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/waSWQ/5AY9zhiXLzXCjD888eklyx8u/jKeSw/v/
lfugfHHV+fI/k+XJzAsMvPoqxWrCjOaI9FH9o69LbRX7OgQ/hP9mKfoSeddmDg/k
FHgVEEBzGLK/Jsfg6ANccWosGJYzxfww87xW1HzHTC4ruucXiuVE+qg+vr1rLS0p
zmzB7BZ2xKkkv/LVjSYbXIV4aIpnTOvIlTmRO4ja8kVyFiu7Tt7pCxsmOEYxSBzI
HhXiqb9epxuJVw1D0BfltrtDiIileyDEmrRIgFIXA0nO07CeIZAk9KjacTXJsA0c
gRSOfgYWongNCLkwg7B9YwpL/sN8AArSunUnmQKxXxtTz2sKGZDDv8aGBprENzgZ
vGF/voBVUV9y+WcX/Yo0DZhUGNv//mq9bi1rcEiYKuxlwNHWSZX0cOwHCmb/H5r+
xGvm871yjxYOb6Ot9yjzpWBM9GkhuJ7hkmq3vxVK8ZHm9/aGxHuZ2JrxXCPiicwC
R0/W+WfmWUhGXnkDoYVOnh8pXVvF0x4uQVCd+vO+TfjxLKdgBu1/T7Erm+Hvrwyr
IL/9eOI2D9IU7ao6yUnMEpEfP8CmaKZMFXPCz5pV/oGNb/B3OPZhnvriL6F0BWjq
mu2LMPXKEh1Ly+Ikb2BOFUui5HVjs53S3uvq7wQp7iSAelFbrlL7JXUgVezTOIo9
8RpTbBQtwCc=
=0Nwc
-END PGP SIGNATURE-

Bug#975668: lxpanel FTBFS: includes without dependency

Source: lxpanel
Version: 0.10.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

To reproduce: build lxpanel on a release architecture in unstable (I used
amd64).

> plugin.c:32:10: fatal error: gdk-pixbuf-xlib/gdk-pixbuf-xlib.h: No such file 
> or directory
>32 | #include 
>   |  ^~~
> compilation terminated.

This is because the deprecated gdk-pixbuf-xlib-2.0 module used to be
pulled in as an indirect dependency by GTK 2. However, GTK 2 doesn't
actually use that module, and as a result libgtk2.0-dev no longer depends
on it, causing lxpanel to fail to build.

In the short term, please build-depend on either

libgdk-pixbuf-xlib-2.0-dev | libgdk-pixbuf2.0-dev

if you want backports to older Debian to be possible, or

libgdk-pixbuf-xlib-2.0-dev

if not. That's enough to close this bug. (This might also be a good
opportunity to check that all the other packages required at build time
are in the Build-Depends.)

For the longer term, the upstream maintainers of gdk-pixbuf have deprecated
the gdk-pixbuf-xlib-2.0 module[0] and do not intend to maintain it further,
so it would be better if lxpanel can stop using it.

Thanks,
smcv

[0] https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

Bug#975666: sslsniff: FTBFS against boost_1.74

Package: sslsniff
Version: 0.8-8.1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

In file included from SSLConnectionManager.cpp:22:
RawBridge.hpp: In constructor 
‘RawBridge::RawBridge(boost::shared_ptr
 >, boost::asio::ip::tcp::endpoint&, const boost::asio::executor&)’:
RawBridge.hpp:46:59: error: no matching function for call to 
‘boost::asio::basic_stream_socket::basic_stream_socket(const
 boost::asio::executor&)’
   46 | executor(executor), destination(destination), closed(0)
  |  

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/sslsniff_0.8-8.1_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9ce8RHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYUPg/9GKMsr+qHs78cpVLaJfmTFzRFXjgrWGYM
VUD7t7ORIWvqMWsWoYO1ExHaRqJSihCNvPbnoPi/NT9NgJwCu/t4a0GilNE4AICD
RCM+4YA59SJufyKfJfejvM8PDcLMtXrws63oBJRTrbci+BYPLmfdaCm3dOlXPUFA
Yskw6Bj26Jsm6T+XRzISBsOvVPM4HHzJ3KWTets3dYmTUCyVBjCueyNceyC5Iips
IaK6AYtUWHpPenYWCSzBI35lxTc1LV+hXMgSsrR4SDru9Nj5RdD8FHwcf3BClfzs
pv61Pun4LmAIPM4LUrJvX+CFuTx3JnPLJ6DIM34sto7omYKCD3a5LBpYZ4uJefOC
AgR+PRTUeNA2LGw0eThCHX98mgvFwmd2dMNwEA3YtilA9HenTA9pfolxCzEbdajm
q0XdS95ELORmfdRIm3887L4TSzq6VaYPqyxAigVSwP5hKNK7Dyhj/iG7uudtnc34
HMeQlXStv5nhyuiz6mNOzu6DRJXHOpo+dSPDmbiJ+YbiJVSr48pF+AYzCYJ/ryRy
yzWRjfLLTJML9eyvUBhq1ze3VutPw3TmgQV8vHOteaUHW36NWR63094hJ1t1Z5wK
ai7wjgfwaAW0yNbBFjsCb4iOskx2jY8bsi/X3EqJJHFDINqqHoYSKiJdzzvwYW+o
hM/6mE5sOIg=
=Ht92
-END PGP SIGNATURE-

Bug#975665: slic3r-prusa: FTBFS against boost_1.74

Package: slic3r-prusa
Version: 2.2.0+dfsg1-3
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

/<>/libcudf/src/dependency.cpp:476:85: error: ‘_2’ was not 
declared in this scope
  476 | boost::sort(candidates, 
boost::bind(::edgeSort, this, _1, _2));

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/aspcud_1.9.4-2_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJEBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9cUwRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbvzQ/4zqaYSC0OeAjSmj+ZIlxssk0b83n1D8px
bj1q5q2a2+uY14QNXxrsXesCnLd9p2CBtyzR0uDLx9wLdzvK88houfejBiaXKxdl
7MLbAP1Yl8g10zFISDcfydqmd1MdT3hJresIJcaRmV5CRgGC7qwuDwFR7Q034RHq
xdmZylBrIsvzWzIIqPcBhKKCJVMZNY4o+F0oAGQURkPOImT3JPDQeGfr6usVeB1V
7VPRy0dD59sV9SKQrhT4rDMFT6DZZJD666jDWPwvSRpw/EuEsVFe5SPtA1WbofMG
6c5F4JCsIlT75pED6fDwhbpLSGUANgpXSo3L7ImugRaElFgE07+OZ1pi7RO3zuBL
A6apcXMLYyrxmuQzIQXRYOOsA5P3LpJZVwZjBzvNTUxCRuzO2ytwCwpWfSs/H6mr
aFZNbqd/wGQi362HWsUYu9reUg08YZ1lKC29uVqPLHVtOr9XqBGkCm/5WgtMhzaL
AxKml5ferbk3TtgtlbyZZ9hzTvFnIYL7NW61lwjefo9BtUc1H39DSDpPJbWkmZ23
CmUP116uyzuPtyf7aJLtnzPJa/eoDxLyLrxRQUPeSzny4AfWLVHuT9t8Vv71w1A1
FHY3elwf8YdNaOaSTMwvuqmxcxEDOQHRd5rsBVRPqJ7Mam5DFoK4+DSIUISG+5a/
jQvCpLh/Uw==
=aJlx
-END PGP SIGNATURE-

Bug#975664: mlocate: obsolete-conffile /etc/updatedb.conf

2020-11-24 Thread Thorsten Glaser

Package: mlocate
Version: 0.26-4
Severity: normal
User: debian...@lists.debian.org
Usertags: adequate obsolete-conffile
X-Debbugs-Cc: t...@mirbsd.de

After today’s upgrade, adequate warns about:

mlocate: obsolete-conffile /etc/updatedb.conf

And, indeed, mlocate_0.26-4_amd64.deb no longer ships this file.
The debian/changelog is quiet about this. So this is most likely
a mistake?


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages mlocate depends on:
ii  adduser  3.118
ii  libc62.31-4

mlocate recommends no packages.

Versions of packages mlocate suggests:
pn  nocache  

-- no debconf information

Bug#975663: alltray: requires gdk-pixbuf-xlib-2.0.pc but does not build-depend on a package containing it

Source: alltray
Version: 0.71b-1.2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

To reproduce: build alltray on a release architecture in unstable (I used
amd64).

> configure: error: Package requirements (gtk+-2.0 >= 2.2.0 gdk-2.0 gconf-2.0 
> gdk-pixbuf-xlib-2.0) were not met:
>
> No package 'gdk-pixbuf-xlib-2.0' found

This is because the deprecated gdk-pixbuf-xlib-2.0 module used to be
pulled in as an indirect dependency by GTK 2. However, GTK 2 doesn't
actually use that module, and as a result libgtk2.0-dev no longer depends
on it, causing alltray to fail to build.

In the short term, please build-depend on either

libgdk-pixbuf-xlib-2.0-dev | libgdk-pixbuf2.0-dev

if you want backports to older Debian to be possible, or

libgdk-pixbuf-xlib-2.0-dev

if not. That's enough to close this bug. (This might also be a good
opportunity to check that all the other packages required at build time
are in the Build-Depends.)

For the longer term, the upstream maintainers of gdk-pixbuf have deprecated
the gdk-pixbuf-xlib-2.0 module[0] and do not intend to maintain it further,
so it would be better if alltray can stop using it.

Thanks,
smcv

[0] https://gitlab.gnome.org/Archive/gdk-pixbuf-xlib

Bug#975086: buster-pu: package dav4tbsync

2020-11-24 Thread Adam D. Barratt

Hi,

On Sat, 2020-11-21 at 15:13 +, Adam D. Barratt wrote:
> On Sat, 2020-11-21 at 14:04 +0100, Mechtilde Stehmann wrote:
> > I hope this is the file you missed.
> 
> Well, yes and no. That looks more like the diff between the current
> package in unstable and what you're proposing to upload, whereas I
> was more thinking of the diff between 1.21-1~deb10u1 and the proposed
> new version.
> 
> Comparing the package from p-u against unstable gives us:
> 
> 176 files changed, 7432 insertions(+), 2366 deletions(-)
> 
> of which a significant portion appears to be Google Javascript
> libraries. I assume the new upstream version is needed specifically
> to allow Thunderbird 78 compatibility, rather than simply adding the
> manifest.json changes?

Just a quick note / reminder that if we want to get the newer update
into the upcoming point release then it needs to have been uploaded and
processed by this coming weekend.

If compatibility with Thunderbird 78 means we definitely need 1.23
rather than an updated 1.21, then I guess we have to go with that.

Regards,

Adam

Bug#975662: RFS: pyrandom2/1.0.1-2.1 [NMU] [RC] -- backport of Python 2.7's random module

2020-11-24 Thread Juhani Numminen

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: pyrandom2
   Version : 1.0.1-2.1
   Upstream Author : Stephan Richter: https://pypi.org/user/srichter/
 * URL : https://pypi.org/project/random2/
 * License : Python
 * Vcs : https://salsa.debian.org/hle/pyrandom2
   Section : python

It builds those binary packages:

  python3-random2 - backport of Python 2.7's random module

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/pyrandom2/pyrandom2_1.0.1-2.1.dsc

Changes since the last upload:

 pyrandom2 (1.0.1-2.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add python3.9.patch fixing tests with py3.9 (Closes: #973085).

I'm trying to keep pysolfc from being removed from testing.
https://tracker.debian.org/pkg/pysolfc

Regards,
--
  Juhani Numminen

Bug#973287: systemd autopkgtest-virt-lxc failure on arm64

Am Montag, den 23.11.2020, 18:09 +0900 schrieb Ryutaroh Matsumoto:
> Hi Michael,
> 
> I run autopkgtest QEMU on systemd 246.6-4 by an amd64 testbed made
> by debci setup -a amd64 -b qemu -s sid. Then root-unittests and
> upstream failed.
> The log is attached as the first attachment.
> 

We probably need to cherry-pick two changes
https://github.com/systemd/systemd/commit/0af05e485a3a88f454c714901eb6109307dc893e
https://github.com/systemd/systemd/pull/17706

> 
> I wonder if all the tests succeed on autopkgtest-virt-qemu
> on your Debian amd64 computer...

With the above two changes, qemu on amd64 passes here.

Michael


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

Bug#959469: buster-pu: package openssl/1.1.1g-1

2020-11-24 Thread Adam D. Barratt

On Fri, 2020-11-20 at 21:04 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-20 17:24:30 [+], Adam D. Barratt wrote:
> > Predictably we're again quite close to a point release. :-( (One
> > week from freeze, specifically.)
> 
> oh.

In fairness, given an approximately two month cycle, we're never /that/
far away from a point release. But some points are obviously closer
than others.

> > Looking at the upstream issues regarding certificate validation
> > changes between 1.1.1e and f/g, #11456 appears to have been
> > addressed already, but #11625 is still open and looks stalled. Have
> > you seen any more reports of that issue?
> 
> Not that I am aware of.

OK, thanks.

> I don't want to rush anything. I have no problem to delay this until
> after the point release if you prefer to do so.

That would be preferable at this point, yes, sorry. We should try and
make sure it's sorted soon afterwards though, to avoid things getting
stuck again.

At some point, could we please have a combined / single diff between
the current 1.1.1d-0+deb10u3 and the proposed 1.1.1h-0+deb10u1 (I
assume)?

Regards,

Adam

Bug#972040: ftbfs dh_missing fails

2020-11-24 Thread Sebastien Bacher

tags 972040 patch
user ubuntu-de...@lists.ubuntu.com
usertags 972040 origin-ubuntu hirsute ubuntu-patch

thank you

The attached patch should fix the issue

diff -Nru jq-1.6/debian/changelog jq-1.6/debian/changelog
--- jq-1.6/debian/changelog	2020-10-10 15:50:26.0 +0200
+++ jq-1.6/debian/changelog	2020-11-24 20:45:35.0 +0100
@@ -1,3 +1,13 @@
+jq (1.6-3) unstable; urgency=medium
+
+  * Fix the build failing on dh_missing (Closes: #972040)
+  * debian/jq.docs:
+- use the correct paths to install the documentation
+  * debian/rules:
+- clean the .la
+
+ -- Sebastien Bacher   Tue, 24 Nov 2020 20:45:35 +0100
+
 jq (1.6-2) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru jq-1.6/debian/jq.docs jq-1.6/debian/jq.docs
--- jq-1.6/debian/jq.docs	2020-10-10 15:46:12.0 +0200
+++ jq-1.6/debian/jq.docs	2020-11-24 20:45:35.0 +0100
@@ -1,2 +1,2 @@
-README
-AUTHORS
+usr/share/doc/jq/README
+usr/share/doc/jq/AUTHORS
diff -Nru jq-1.6/debian/rules jq-1.6/debian/rules
--- jq-1.6/debian/rules	2020-10-10 15:46:12.0 +0200
+++ jq-1.6/debian/rules	2020-11-24 20:45:35.0 +0100
@@ -13,6 +13,10 @@
 	cd docs && rake manpage > ../jq.1
 	dh_auto_configure -- --disable-static
 
+override_dh_install:
+	find debian/tmp -name '*.la' -print -delete
+	dh_install
+
 override_dh_auto_test:
 	VERBOSE=1 dh_auto_test

Bug#974691: gtkterm: German message catalogue

2020-11-24 Thread Willem van den Akker

Merged with upstream.

On Fri, 2020-11-13 at 20:48 +0100, Markus Hiereth wrote:
> Package: gtkterm
> Version: 1.11-1
> Severity: normal
> 
> Dear Willem,
> 
> attached to this report, You recieve the german message catalogue for
> gtkterm
> 
> Consider the following corrections / changes 
> 
> #: ../src/cmdline.c:48
> msgid "--parity  or -a : partity (default none)\n"
> s/partity/parity
> 
> 
> #: ../src/cmdline.c:53
> msgid ""
> "--rts_time_before  or -x : for rs485, time in ms before transmit
> with "
> "rts on\n"
> s/rs485/RS-485 as this is the usual Abbreviation
> 
> #: ../src/cmdline.c:54
> msgid ""
> "--rts_time_after  or -y : for rs485, time in ms after transmit
> with rts "
> "on\n"
> s/rs485/RS-485 as this is the usual Abbreviation
> 
> 
> #: ../src/parsecfg.c:385
> #, c-format
> msgid ""
> "%s(%d)\n"
> "There is no closing brace.\n"
> s/brace/bracket as braces are {} and brackets are [] and ()
> 
> #: ../src/term_config.c:193
> msgid ""
> "No serial devices found!\n"
> "\n"
> "Searched the following paths:\n"
> "\t/dev/ttyS*\n"
> consider s/the following paths/the following device path patterns  
> (just to stress that all usual device files have been probed)
> 
> #: ../src/term_config.c:457
> msgid "RS485 half-duplex parameters (RTS signal used to send)"
> consider s/RS485/RS-485 as this is the usual Abbreviation
> 
> Best regards
> Markus
> 
> 
> 
> -- System Information:
> Debian Release: 10.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 4.19.0-9-686-pae (SMP w/1 CPU core)
> Locale: LANG=de_DE.ISO-8859-1, LC_CTYPE=de_DE.ISO-8859-1
> (charmap=ISO-8859-1), LANGUAGE=de_DE.ISO-8859-1 (charmap=ISO-8859-1)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gtkterm depends on:
> ii  libatk1.0-0  2.30.0-2
> ii  libc6    2.28-10
> ii  libcairo-gobject2    1.16.0-4
> ii  libcairo2    1.16.0-4
> ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
> ii  libglib2.0-0 2.58.3-2+deb10u2
> ii  libgnutls30  3.6.7-4+deb10u5
> ii  libgtk-3-0   3.24.5-1
> ii  libpango-1.0-0   1.42.4-8~deb10u1
> ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
> ii  libpcre2-8-0 10.32-5
> ii  libvte-2.91-0    0.54.2-2
> ii  zlib1g   1:1.2.11.dfsg-1
> 
> gtkterm recommends no packages.
> 
> gtkterm suggests no packages.
> 
> -- no debconf information
>

Bug#975661: rquantlib: FTBFS against boost_1.74

Package: rquantlib
Version: 0.4.12-1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:


=

installing to 
/<>/debian/r-cran-rquantlib/usr/lib/R/site-library/00LOCK-rquantlib-0.4.12/00new/RQuantLib/libs
** R
** data
** demo
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded from temporary location

 *** caught segfault ***
address 0x7f4c6172ed80, cause 'invalid permissions'

Traceback:
 1: dyn.load(file, DLLpath = DLLpath, ...)
 2: library.dynam(lib, package, package.lib)
 3: loadNamespace(package, lib.loc)
 4: doTryCatch(return(expr), name, parentenv, handler)
 5: tryCatchOne(expr, names, parentenv, handlers[[1L]])
 6: tryCatchList(expr, classes, parentenv, handlers)
 7: tryCatch({attr(package, "LibPath") <- which.lib.locns <- 
loadNamespace(package, lib.loc)env <- attachNamespace(ns, pos = pos, deps, 
exclude, include.only)}, error = function(e) {P <- if (!is.null(cc <- 
conditionCall(e))) paste(" in", deparse(cc)[1L])else ""msg <- 
gettextf("package or namespace load failed for %s%s:\n %s", 
sQuote(package), P, conditionMessage(e))if (logical.return) 
message(paste("Error:", msg), domain = NA)else stop(msg, call. = FALSE, 
domain = NA)})
 8: library(pkg_name, lib.loc = lib, character.only = TRUE, logical.return = 
TRUE)
 9: withCallingHandlers(expr, packageStartupMessage = function(c) 
tryInvokeRestart("muffleMessage"))
10: suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
character.only = TRUE, logical.return = TRUE))
11: doTryCatch(return(expr), name, parentenv, handler)
12: tryCatchOne(expr, names, parentenv, handlers[[1L]])
13: tryCatchList(expr, classes, parentenv, handlers)
14: tryCatch(expr, error = function(e) {call <- conditionCall(e)if 
(!is.null(call)) {if (identical(call[[1L]], quote(doTryCatch))) 
call <- sys.call(-4L)dcall <- deparse(call)[1L]prefix <- 
paste("Error in", dcall, ": ")LONG <- 75Lsm <- 
strsplit(conditionMessage(e), "\n")[[1L]]w <- 14L + nchar(dcall, type = 
"w") + nchar(sm[1L], type = "w")if (is.na(w)) w <- 14L + 
nchar(dcall, type = "b") + nchar(sm[1L], type = "b")if 
(w > LONG) prefix <- paste0(prefix, "\n  ")}else prefix <- 
"Error : "msg <- paste0(prefix, conditionMessage(e), "\n")
.Internal(seterrmessage(msg[1L]))if (!silent && 
isTRUE(getOption("show.error.messages"))) {cat(msg, file = outFile) 
   .Internal(printDeferredWarnings())}invisible(structure(msg, class = 
"try-error", condition = e))})
15: try(suppressPackageStartupMessages(library(pkg_name, lib.loc = lib, 
character.only = TRUE, logical.return = TRUE)))
16: tools:::.test_load_package("RQuantLib", 
"/<>/debian/r-cran-rquantlib/usr/lib/R/site-library/00LOCK-rquantlib-0.4.12/00new")
An irrecoverable exception occurred. R is aborting now ...
Segmentation fault
ERROR: loading failed

=



It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/rquantlib_0.4.12-1_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9ZMERHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbvfQ//fnWf/HRrIIyOKTdgCXdZDvRa3bQfVyCQ
1RqYyROsSEqt6IFYR3WUlSA/dZmMLilghsZN2AACUJfKakZbXutNmJQ9hljIB6Qt
dsmK7kiZ/Nd2hfHFDY4VTG1FdIw7XnyfCQCm/pyLKXTOFpbDKOPKpw6DN3ABNt/h
k8D15FuZyUKAg/Z5vooV0kYEtYljyAVtmXYfTtI+NgGN/MtvISxysESWtZt1V1ZX
kxryjQjwhQkW/s47dnJlznZWpF8kp4XC/PlVncvBA3fxMEp4r+ueDuGqO4wAVPae
84PVhnOsFvbh2rwAxVbn7HCVOx7ecrI8F/gJ+rxLS7hS3ktZRzij9pjsMWEUwzFX
Im7OHEx4FT4S+kCpEgR4TcF6V8vSE38Ka3VX5JfcG63uBQ3vFItCNm70a8CNNzaA
YpxpH45MfT144f4/NgtCIbkwc0Ji7fU0ZtL8bQ8Z/FiQPkwsNi0GTJLbBKAlmSUX
fpYTSJxEzfI6ESEm4vDcN4BP+wh8a8tvoRc6sG2f7T0zAvC8ZTIozThx/yh5GG7Q
/axN6+TywiGVpetEVd9bBcFcj4RTwYPWI4N32as9Pcp5wtUbY0xp6n0QzEEeluIG
wmDTC6jhd4XdRata8BZSXWDF0DusjSG48sxNXOgtoBw+6wD/4YDtopMg7IuaCZeQ
r0kCcUqL7VA=
=kCZa
-END PGP SIGNATURE-

Bug#975561: journal: do not trigger assertion when journal_file_close() get NULL

Control: fixed -1 243-1


Hello Boris

Am Montag, den 23.11.2020, 17:14 +0100 schrieb Boris Granwehr:
> 
> Sometimes the systemd-journald process crashes on startup with the
> error message:
> Failed to create new runtime journal: No such file or directory
> Assertion 'f' failed at ../src/journal/journal-file.c:332, function
> journal_file_close().
> Aborting.
> 
> This is caused by changing the "storage" parameter in
> "/etc/systemd/journald.conf"
> from the default value "volatile" to "auto" (if "/var/log/journal"
> exists)
> or to changing it to "persistent".
> 
> The following systemd 243 upstream commit fixes this bug:
> https://github.com/systemd/systemd/pull/12679/files
> 
> The bug is fixed for debian releases since bullseye (systemd 246).
> Is it possible to fix the bug also for older debian releases like
> stretch

The change looks ok for a stable upload (i.e. buster) and I can include
that in the next stable point release after 10.7 (for 10.7 it is too
late).
For old-stable I don't plan to make any further uploads.




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

Bug#975660: scram: FTBFS against boost_1.74

Package: scram
Version: 0.16.2-1
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

[ 19%] Building CXX object src/CMakeFiles/scram.dir/config.cc.o
cd /<>/obj-x86_64-linux-gnu/src && /usr/bin/c++ -DBOOST_ALL_NO_LIB 
-DBOOST_FILESYSTEM_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK 
-DBOOST_RANDOM_DYN_LINK -DBOOST_SYSTEM_DYN_LINK 
-DPROJECT_SOURCE_DIR=\"/<>\" -Dscram_EXPORTS 
-I/<>/obj-x86_64-linux-gnu/src -I/<>/src 
-I/<> -isystem /usr/include/libxml2 -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-new-ttp-matching 
-O3 -DNDEBUG -fPIC -std=c++17 -o CMakeFiles/scram.dir/config.cc.o -c 
/<>/src/config.cc
In file included from /<>/src/settings.cc:27:
/<>/src/settings.cc: In member function ‘scram::core::Settings& 
scram::core::Settings::algorithm(std::string_view)’:
/<>/src/error.h:39:40: error: 
‘BOOST_THROW_EXCEPTION_CURRENT_FUNCTION’ was not declared in this scope
   39 |   throw err << 
::boost::throw_function(BOOST_THROW_EXCEPTION_CURRENT_FUNCTION) \

It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/scram_0.16.2-1_unstable_boost.log

Best regards

Anton

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

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

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+9Y0wRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wZ/vQ/+I16O0GIcjOiVDon3vjDctFUItgC3ynuq
ceER0Hu6uHZxn3SWUzhQqCc4cVVp3wTXIELn6iYc3Ekv2H2ZgZYKP9sF6F5u6Ue3
7PxElbjUBZz/SQjMNyRALWZY/ZSFqlLr6iCZ9YIYA9Di/bE8y6gBNMdmczWG32yy
umvpDH3sVd1S0ORLzvuCANfrQb6YZO5SFZYlE6zvqaIdXqbTICGLyx4QLMYIDE8e
07TcTPz61htFCfz55M6KUAtgO0ihPS0dCu19rp+8Gpf2n2PIZbytvtFWGZZPlAxy
Bz9aY4PFqJKFs454hLb6SXNuF59QhNOCCg97+jxmqIy3OqyrEnQqv5RvwkgDoxsq
2rjbUGZMnWaUyb5tJuc3WKBUBvmIYcg0ciZYKDNwAhy2ECBRZvRRKXWT29tHS8Z3
3A37OcIbwx/Nre1x6ayyS8T5j3iHnTq5s4t7CwqOJWRHovyFWRTU7vCf51dDBTe6
8vxhrRzCv2UFfeDIOFnN6zNFGm+n+q5wWj/YVUHGGzUSbGa82+v7iQL3/+iI9pdP
1CYmueriQAuyiqsktxCASiYCuj+vbHgmTklWfnzeRdpEg3lE14A2sC7sHH8/KAYt
kuGW2JO+lZAuZKUB5ZLVEc4uumdL+XzpqcprrpJZNDgeS6nrdKWJE7IMNFddReAK
JrxPYAPm+fo=
=H+2c
-END PGP SIGNATURE-

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

2020-11-24 Thread Juhani Numminen

Hi,

la 7. marrask. 2020 klo 9.38 Juhani Numminen
(juhaninummin...@gmail.com) kirjoitti:
> Fedora have decided to disable the failing part of that test.[1]
> Python docs for the tested function now state "Changed in version 3.9:
> This method now accepts zero for k."[2]
>
> [1] 
> https://src.fedoraproject.org/rpms/python-random2/blob/master/f/python-random2.spec#_39
> [2] https://docs.python.org/3/library/random.html#random.getrandbits

I propose the attached pyrandom2 NMU which aims to fix py3.9 test failures.
I will try to see if someone could sponsor the upload for me.

Thanks,
--
Juhani
diff -Nru pyrandom2-1.0.1/debian/changelog pyrandom2-1.0.1/debian/changelog
--- pyrandom2-1.0.1/debian/changelog	2019-08-02 14:43:29.0 +0300
+++ pyrandom2-1.0.1/debian/changelog	2020-11-24 20:26:34.0 +0200
@@ -1,3 +1,10 @@
+pyrandom2 (1.0.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add python3.9.patch fixing tests with py3.9 (Closes: #973085).
+
+ -- Juhani Numminen   Tue, 24 Nov 2020 20:26:34 +0200
+
 pyrandom2 (1.0.1-2) unstable; urgency=medium
 
   * Drop Python 2 support.
diff -Nru pyrandom2-1.0.1/debian/patches/python3.9.patch pyrandom2-1.0.1/debian/patches/python3.9.patch
--- pyrandom2-1.0.1/debian/patches/python3.9.patch	1970-01-01 02:00:00.0 +0200
+++ pyrandom2-1.0.1/debian/patches/python3.9.patch	2020-11-24 20:26:34.0 +0200
@@ -0,0 +1,31 @@
+Description: fix tests with python 3.9
+ Python docs for the function being tested now state:
+ "Changed in version 3.9: This method now accepts zero for k."
+ https://docs.python.org/3/library/random.html#random.getrandbits
+Author: Juhani Numminen 
+Bug-Debian: https://bugs.debian.org/973085
+Last-Update: 2020-11-24
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/src/tests.py
 b/src/tests.py
+@@ -291,7 +291,8 @@
+ # Verify argument checking
+ self.assertRaises(TypeError, self.gen.getrandbits)
+ self.assertRaises(TypeError, self.gen.getrandbits, 1, 2)
+-self.assertRaises(ValueError, self.gen.getrandbits, 0)
++if sys.version_info < (3, 9):
++self.assertRaises(ValueError, self.gen.getrandbits, 0)
+ self.assertRaises(ValueError, self.gen.getrandbits, -1)
+ self.assertRaises(TypeError, self.gen.getrandbits, 10.1)
+ 
+@@ -448,7 +449,8 @@
+ self.assertRaises(TypeError, self.gen.getrandbits)
+ self.assertRaises(TypeError, self.gen.getrandbits, 'a')
+ self.assertRaises(TypeError, self.gen.getrandbits, 1, 2)
+-self.assertRaises(ValueError, self.gen.getrandbits, 0)
++if sys.version_info < (3, 9):
++self.assertRaises(ValueError, self.gen.getrandbits, 0)
+ self.assertRaises(ValueError, self.gen.getrandbits, -1)
+ 
+ def test_randbelow_logic(self, _log=log, int=int):
diff -Nru pyrandom2-1.0.1/debian/patches/series pyrandom2-1.0.1/debian/patches/series
--- pyrandom2-1.0.1/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ pyrandom2-1.0.1/debian/patches/series	2020-11-23 13:28:38.0 +0200
@@ -0,0 +1 @@
+python3.9.patch

Bug#975657: [Pkg-rust-maintainers] Bug#975657: debcargo: Debcargo, cargo, and other Rust packaging tools are NOT in testing

2020-11-24 Thread Calum McConnell

On Tue, 2020-11-24 at 20:04 +0100, Sylvestre Ledru wrote:
> 
> Hello,
> Le 24/11/2020 à 19:06, Calum McConnell a écrit :
> > Package: debcargo
> > Severity: important
> > X-Debbugs-Cc: calumlikesapple...@gmail.com
> >
> 
> > As the freeze approaches, it becomes more important to make sure that
> > every package desired for the next release is actually
> > present in Debian.  Many of the important rust packages have not been
> > in testing for several months, and must be fixed and updated soon.
> > 
> 
> Do you have a list of packages you have in mind?
> 
> Cargo is in testing (version 0.43.1)
Whoops, yeah.  Rust-cargo isn't, however, which was what I meant (I
thought they were the same: like python3-pip)

But for the most part,  I was only thinking about those core, package
maintenance tools.  I really don't have a list, but I assume all the ones
I am intrested in are connected, and their blocked for mostly the same
reason.
> 



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

Bug#975115: [Pkg-mozext-maintainers] Bug#975115: webext-dav4tbsync and webext-tbsync out of sync

2020-11-24 Thread Tom Jampen

Hi

Thanks, Mechtilde for your fast reply and sorry for my delayed answer. I
didn't realize I had to subscribe to "my own" bugs...

Thanks, Carl for providing the necessary information in the meantime.

I'm using Backports of your tbsync-packages for Buster (with the latest
thunderbird).

But of course, I've tested under sid as well (a fresh install in a new
VM before I opened the bug) with the same result.

I'm happy to help testing or provide more info.

Regards
Tom

Bug#975659: libaio-ocaml: FTBFS with ocaml 4.11

2020-11-24 Thread Andreas Beckmann

Source: libaio-ocaml
Version: 1.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

libaio-ocaml/experimental FTBFS since the upgrade to ocaml 4.11:

ocamlc -a -cclib -laio_stubs -cclib -laio   -dllib dllaio_stubs.so -custom  
   -o aio.cma aio_buffer.cmo aio.cmo
Please specify at most one of -pack, -a, -c, -output-obj

There is also a bunch of deprecation warnings, see the attached buildlog.


Andreas


libaio-ocaml_1.0.1-1.log.gz
Description: application/gzip

Bug#975657: [Pkg-rust-maintainers] Bug#975657: debcargo: Debcargo, cargo, and other Rust packaging tools are NOT in testing

2020-11-24 Thread Sylvestre Ledru


Hello,

Le 24/11/2020 à 19:06, Calum McConnell a écrit :
> Package: debcargo
> Severity: important
> X-Debbugs-Cc: calumlikesapple...@gmail.com
>
As the freeze approaches, it becomes more important to make sure that 
every package desired for the next release is actually
present in Debian.  Many of the important rust packages have not been 
in testing for several months, and must be fixed and updated soon.



Do you have a list of packages you have in mind?

Cargo is in testing (version 0.43.1)

Debcargo indeed needs some love (i reported bug 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963916).


As NEW is super fast lately, peter, do you think you could have a new look?
thanks

S

Bug#883932: Source for sword-comm-mhc

2020-11-24 Thread Roberto C . Sánchez

On Tue, Nov 24, 2020 at 10:33:47AM -0500, Roberto C. Sánchez wrote:
> 
> But the Salsa project page says the repository is empty.  I will push
> the code I have shortly.
> 
I have pushed everything to the Salsa repository, including all branches
(master, upstream, pristine-tar) and tags.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Bug#975658: libdrm2: Invalid read after the end of block in xf86drm.c:3594

2020-11-24 Thread Davide Prina

Package: libdrm2
Version: 2.4.103-1
Severity: normal
Tags: patch
X-Debbugs-Cc: davide.pr...@gmail.com

Hi,

the instruction (line 3594 of xf86drm.c file):
memcpy(device->nodes[type], node, max_node_length);

read from node over the node allocated size as you can see from valgrind
output that execute a piglit (see tha package piglit for mor info) test:

$ valgrind --num-callers=50 --exit-on-first-error=yes --keep-debuginfo=yes 
bin/arb_separate_shader_object-mix-and-match-tcs-tes

==33238== Invalid read of size 8
==33238==at 0x5C6F6CA: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==33238==by 0x5C707C1: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==33238==by 0x5C746FE: drmGetDevice2 (in 
/usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==33238==by 0x5C0D1B8: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x5C0326E: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x5BF1E08: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x5BEE4ED: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x4CEA640: ??? (in 
/usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.6.1)
==33238==by 0x49E0081: wfl_checked_display_connect (piglit-util-waffle.h:74)
==33238==by 0x49E0081: piglit_wfl_framework_init 
(piglit_wfl_framework.c:627)
==33238==by 0x49E055F: piglit_winsys_framework_init 
(piglit_winsys_framework.c:209)
==33238==by 0x49E0DCA: piglit_x11_framework_create 
(piglit_x11_framework.c:229)
==33238==by 0x49D4728: piglit_gl_test_run (piglit-framework-gl.c:221)
==33238==by 0x10A1A1: main (mix-and-match-tcs-tes.c:48)
==33238==  Address 0x58c1960 is 1 bytes after a block of size 15 alloc'd
==33238==at 0x483877F: malloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==33238==by 0x5C70638: ??? (in /usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==33238==by 0x5C746FE: drmGetDevice2 (in 
/usr/lib/x86_64-linux-gnu/libdrm.so.2.4.0)
==33238==by 0x5C0D1B8: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x5C0326E: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x5BF1E08: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x5BEE4ED: ??? (in 
/usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0.0.0)
==33238==by 0x4CEA640: ??? (in 
/usr/lib/x86_64-linux-gnu/libwaffle-1.so.0.6.1)
==33238==by 0x49E0081: wfl_checked_display_connect (piglit-util-waffle.h:74)
==33238==by 0x49E0081: piglit_wfl_framework_init 
(piglit_wfl_framework.c:627)
==33238==by 0x49E055F: piglit_winsys_framework_init 
(piglit_winsys_framework.c:209)
==33238==by 0x49E0DCA: piglit_x11_framework_create 
(piglit_x11_framework.c:229)
==33238==by 0x49D4728: piglit_gl_test_run (piglit-framework-gl.c:221)
==33238==by 0x10A1A1: main (mix-and-match-tcs-tes.c:48)

Afret installing the package with detached debug symbols you can see the
rows and file:
==17446== Invalid read of size 8
==17446==at 0x5C706CA: UnknownInlinedFun (string_fortified.h:34)
==17446==by 0x5C706CA: drmDeviceAlloc (xf86drm.c:3594)
==17446==by 0x5C717C1: drmProcessPciDevice (xf86drm.c:3610)
==17446==by 0x5C717C1: process_device (xf86drm.c:4012)
==17446==by 0x5C756FE: drmGetDevice2 (xf86drm.c:4190)
==17446==by 0x5C0E1B8: drm_get_id_path_tag_for_fd (loader.c:292)
==17446==by 0x5C0E1B8: loader_get_user_preferred_fd (loader.c:319)
==17446==by 0x5C0426E: dri3_create_screen (dri3_glx.c:866)
==17446==by 0x5BF2E08: AllocAndFetchScreenConfigs (glxext.c:818)
==17446==by 0x5BF2E08: __glXInitialize (glxext.c:949)
==17446==by 0x5BEF4ED: GetGLXPrivScreenConfig (glxcmds.c:174)
==17446==by 0x5BEF4ED: glXQueryExtensionsString (glxcmds.c:1307)
==17446==by 0x4CEB640: wrapped_glXQueryExtensionsString (glx_wrappers.h:129)
==17446==by 0x4CEB640: glx_display_set_extensions (glx_display.c:55)
==17446==by 0x4CEB640: glx_display_connect (glx_display.c:105)
[...]
==17446==  Address 0x58c2da0 is 1 bytes after a block of size 15 alloc'd
==17446==at 0x483877F: malloc (in 
/usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==17446==by 0x5C71638: process_device (xf86drm.c:3987)
==17446==by 0x5C756FE: drmGetDevice2 (xf86drm.c:4190)
==17446==by 0x5C0E1B8: drm_get_id_path_tag_for_fd (loader.c:292)
==17446==by 0x5C0E1B8: loader_get_user_preferred_fd (loader.c:319)
==17446==by 0x5C0426E: dri3_create_screen (dri3_glx.c:866)
==17446==by 0x5BF2E08: AllocAndFetchScreenConfigs (glxext.c:818)
==17446==by 0x5BF2E08: __glXInitialize (glxext.c:949)
==17446==by 0x5BEF4ED: GetGLXPrivScreenConfig (glxcmds.c:174)
==17446==by 0x5BEF4ED: glXQueryExtensionsString (glxcmds.c:1307)
==17446==by 0x4CEB640: wrapped_glXQueryExtensionsString (glx_wrappers.h:129)
==17446==by 0x4CEB640: glx_display_set_extensions (glx_display.c:55)
==17446==by 0x4CEB640: glx_display_connect

Bug#875847: Patch to fix ".qhc files not reproducible"

2020-11-24 Thread Dmitry Shachnev

Hi Kai!

On Thu, Oct 15, 2020 at 07:48:49AM +0200, Kai Pastor, DG0YT wrote:
> This patch fixes the creation of the offending timestamp, by clamping to
> SOURCE_DATE_EPOCH as specified.

Thank you for the patch and sorry for delayed response!

> I also left a link to this Debian bug in Qt's code review for the offending
> change.

Can you please share a link to the mentioned code review?

https://bugreports.qt.io/browse/QTBUG-62697 has only some old reviews from
2018 linked.

> Clamp registered collection time-stamp to SOURCE_DATE_EPOCH if set.
> --- a/src/assistant/help/qhelpcollectionhandler.cpp
> +++ b/src/assistant/help/qhelpcollectionhandler.cpp
> @@ -2197,7 +2197,14 @@
>  m_query->addBindValue(fileName);
>  const QFileInfo fi(absoluteDocPath(fileName));
>  m_query->addBindValue(fi.size());
> -m_query->addBindValue(fi.lastModified().toString(Qt::ISODate));
> +QDateTime last_modified = fi.lastModified();
> +if (qEnvironmentVariableIsSet("SOURCE_DATE_EPOCH"))
> +{
> +qint64 source_date_epoch = 
> qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH");
> +if (source_date_epoch < last_modified.toSecsSinceEpoch())
> +
> last_modified.setSecsSinceEpoch(qEnvironmentVariableIntValue("SOURCE_DATE_EPOCH"));

I think we can use setSecsSinceEpoch(source_date_epoch) here?

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#975571: linux: No rule to make target 'scripts/module.lds' while building out-of-tree modules

2020-11-24 Thread Salvatore Bonaccorso

Control: tags -1 + confirmed

Hi Andreas,

On Mon, Nov 23, 2020 at 06:46:26PM +0100, Andreas Beckmann wrote:
> Source: linux
> Version: 5.10~rc4-1~exp1
> Severity: important
> 
> Hi,
> 
> building out-of-tree modules againt Linux 5.10 headers in experimental fails 
> with
> 
> No rule to make target 'scripts/module.lds', needed by 
> '/path/to/module.ko'.  Stop.
> 
> e.g.
> 
> make[3]: *** No rule to make target 'scripts/module.lds', needed by 
> '/var/lib/dkms/r8168/8.048.03/build/r8168.ko'.  Stop.
> 
> make[4]: *** No rule to make target 'scripts/module.lds', needed by 
> '/var/lib/dkms/bbswitch/0.8/build/bbswitch.ko'.  Stop.
> 
> make[5]: *** No rule to make target 'scripts/module.lds', needed by 
> '/usr/src/modules/nvidia-kernel/nvidia-drm.ko'.  Stop.

Thanks for reporting.

We need to do something about the following upstream change,
596b0474d3d9 ("kbuild: preprocess module linker script")[1].

Regards,
Salvatore

 [1] https://git.kernel.org/linus/596b0474d3d9b1242eab713f84d8873f9887d980

Bug#975657: debcargo: Debcargo, cargo, and other Rust packaging tools are NOT in testing

2020-11-24 Thread Calum McConnell

Package: debcargo
Severity: important
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As the freeze approaches, it becomes more important to make sure that every 
package desired for the next release is actually
present in Debian.  Many of the important rust packages have not been in 
testing for several months, and must be fixed and updated soon.


- -- 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-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl+9S6YdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzKfsA/9FOtEq7p8nsGfR6w/
W4WWAJWJ1KWSNuRpWQsCzngdwQhzDY+XIRW1GZjrpe2+JWyvWDyJgxklBJxUyN4y
TTew6mTDiXOTLNiH3lfQiGabD4uEgR/lvTjktLdmvLnLRu2e8zIF8w/cSi3/lJMw
o5izJlGs6GqSZYCGn4yrZxXWgWGf60cQUXnZLeZokn5LweMTwNva9PivOmiwdd2D
y8EaQjE4VhybzLn+19o4Py3zhyLrBXk1Zuu7xjf0Lthrbw/WuuRxOv7lr3fpwH5v
2hs82f/f1uzK8TqBqcwFYAC1ZMZnIk76xC7Ez07bwtCDySb1CtcOzPElxqPaS62R
ib2bcbZGAgsjWB4Mwz9EF5mpQZsMyBbT5JY1znaZlejoQ4mK1TMKGbbK9LSPobAL
P4/g4+U/1P3PvMuva7MmkLik92WMmDk2Zlzv8L4XMg89UC/VetyPcciAdNY1p6jt
tS12y3AHIVMDb9PH0Hg79fUUkIshciCwLxk/hQEb0HFmUk4NVMFRiiuglQ2EP75q
tCHGKLqcsfzhnGUBfDn7AvvqLRFd5aivCCLza1FmmLnEpo3efb8hgc52+YXfU4Ko
3KP+j7WxrMtzYOaePVCUgulHy894RMMIXEL8X7EZblhlmgvOkTj2tQhxSSlq3DGA
qrvJ9VbfaNKzcTKlgWMhwKp8ASM=
=9vOh
-END PGP SIGNATURE-

Bug#971302: uploaded upstream 2.4.2 to the delayed queue

2020-11-24 Thread Matthias Klose

uploaded upstream 2.4.2 to the delayed queue.

Bug#975650: blhc: reports false positives for missing flags

2020-11-24 Thread Fabian Wolff

Hi Eriberto,

thanks for your quick reply!

On 11/24/20 5:59 PM, Eriberto wrote:
> Since 0.12 version, blhc is able to ignore false positives spotted by
> line(s) "injected" inside .build file via debian/rules. See more
> details in blhc(1) manpage. There are examples in
> /usr/share/doc/blhc/README.Debian. Please, check also the debian/rules
> files in blhc, ngetty, libinsane, calibre, dxvk and picard-tools.
> 
> Please, let me know if I can close this bug.

Well, just because you can work around it doesn't mean that the bug is
fixed, right? I'm trying to help improve blhc, so that false positives
such as the ones I was describing ideally don't even arise.

Let's wait to see what Simon thinks of this; if he deems it irrelevant
and/or doesn't want to fix it, then you can close the bug.

Best,
Fabian

Bug#974550: golang-github-gomodule-redigo-dev: New upstream version available, using lower version number

2020-11-24 Thread Michael Prokop

* Michael Prokop [Thu Nov 12, 2020 at 07:55:47AM +0100]:
> Package: golang-github-gomodule-redigo-dev
> Version: 2.0.0-1
> Severity: normal

> while it looks like version 2.0.0-1 of the
> golang-github-gomodule-redigo-dev package matches the latest
> upstream version, this doesn't seem to really match reality.

> Looking at https://github.com/gomodule/redigo/tags we have the
> following versions/tags with their corresponding "release date" next
> them:

> v1.8.2 on 2020-06-08
> v1.8.1 on 2020-05-06
> v1.8.0 on 2020-04-30
> v1.7.2 on 2020-04-30
> v1.7.1 on 2020-04-30
> v1.7.0 on 2018-12-13
> v2.0.0 on 2018-03-14(!)

> So v2.0.0 is actually the oldest version, while upstream's
> newest version as of today is v1.8.2, due to a version number
> downgrade to 1.7.0 after the 2.0.0 release back in 2018).

> We can either only introduce an epoch version :-/ - or hope for
> upstream raising their version number, I tried to bring this up at
> upstream at https://github.com/gomodule/redigo/issues/532

So sadly my request to fix the version situation from upstream side
was closed (see https://github.com/gomodule/redigo/issues/532),
so I'm afraid we have to introduce an epoch version to handle this. :(

Dmitry, is there any chance you could take care this?

regards
-mika-


signature.asc
Description: Digital signature

Bug#975656: linux-image-5.9.0-2-amd64: Since upgrade to 5.9.0-2-amd64 screen blanking doesn't work once the machine was in sleep mode

2020-11-24 Thread raumkundschafter

Package: src:linux
Version: 5.9.6-1
Severity: normal
X-Debbugs-Cc: raumkundschaf...@hasa-labs.org

Dear Maintainer,

   * What led up to the situation?
   Following an upgrade of the kernel and putting the machine to sleep, after 
wakeup the screen doesn't go black anymore automatically.

 * What exactly did you do (or not do) that was effective (or
 ineffective)?
Using the command "sleep 1; xset dpms force off" does work 
though.
I was checking the setting with "xset -q" and this command 
reports the following:
DPMS (Energy Star):
Standby: 600Suspend: 0Off: 900
DPMS is Enabled
Monitor is On
   
 * What was the outcome of this action?
A black screen 

   * What outcome did you expect instead?
After sleep mode the screen should go black after some time

-- Package-specific info:
** Version:
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)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.9.0-2-amd64 
root=UUID=4cd4458a-ad22-459b-bc22-0ce0ae649d36 ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[157401.004138] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.004141] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.004143] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.004146] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.004148] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.004152] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.004155] iwlwifi :00:14.3: expected hw-decrypted unicast frame for 
station
[157401.034246] wlp0s20f3: authenticate with 60:38:e0:b6:60:92
[157401.041354] wlp0s20f3: send auth to 60:38:e0:b6:60:92 (try 1/3)
[157401.081072] wlp0s20f3: authenticated
[157401.081197] wlp0s20f3: associating with AP with corrupt probe response
[157401.082756] wlp0s20f3: associate with 60:38:e0:b6:60:92 (try 1/3)
[157401.084517] wlp0s20f3: RX ReassocResp from 60:38:e0:b6:60:92 (capab=0x511 
status=0 aid=2)
[157401.086739] wlp0s20f3: associated
[157401.086769] wlp0s20f3: Limiting TX power to 14 (17 - 3) dBm as advertised 
by 60:38:e0:b6:60:92
[157666.212116] wlp0s20f3: disconnect from AP 60:38:e0:b6:60:92 for new auth to 
60:38:e0:b6:60:91
[157666.297271] wlp0s20f3: authenticate with 60:38:e0:b6:60:91
[157666.303340] wlp0s20f3: send auth to 60:38:e0:b6:60:91 (try 1/3)
[157666.342423] wlp0s20f3: authenticated
[157666.342760] wlp0s20f3: associating with AP with corrupt probe response
[157666.346215] wlp0s20f3: associate with 60:38:e0:b6:60:91 (try 1/3)
[157666.350667] wlp0s20f3: RX ReassocResp from 60:38:e0:b6:60:91 (capab=0x411 
status=0 aid=5)
[157666.356255] wlp0s20f3: associated
[157697.905352] wlp0s20f3: disconnect from AP 60:38:e0:b6:60:91 for new auth to 
60:38:e0:b6:60:92
[157697.914535] wlp0s20f3: authenticate with 60:38:e0:b6:60:92
[157697.917797] wlp0s20f3: send auth to 60:38:e0:b6:60:92 (try 1/3)
[157697.969339] wlp0s20f3: authenticated
[157697.969539] wlp0s20f3: associating with AP with corrupt beacon and probe 
response
[157697.970435] wlp0s20f3: associate with 60:38:e0:b6:60:92 (try 1/3)
[157697.972184] wlp0s20f3: RX ReassocResp from 60:38:e0:b6:60:92 (capab=0x511 
status=0 aid=2)
[157697.974151] wlp0s20f3: associated
[157698.047399] wlp0s20f3: Limiting TX power to 14 (17 - 3) dBm as advertised 
by 60:38:e0:b6:60:92
[161738.582340] iwlwifi :00:14.3: Unhandled alg: 0x71b
[161738.585412] iwlwifi :00:14.3: Unhandled alg: 0x71b
[163600.586936] FAT-fs (sda2): Volume was not properly unmounted. Some data may 
be corrupt. Please run fsck.
[163611.994615] EXT4-fs (sda1): mounted filesystem with ordered data mode. 
Opts: (null)
[163914.130353] EXT4-fs (sda1): error count since last fsck: 1
[163914.130360] EXT4-fs (sda1): initial error at time 1590435311: 
ext4_find_entry:1484: inode 2
[163914.130364] EXT4-fs (sda1): last error at time 1590435311: 
ext4_find_entry:1484: inode 2
[169048.463108] wlp0s20f3: disconnect from AP 60:38:e0:b6:60:92 for new auth to 
60:38:e0:b6:60:91
[169048.469303] wlp0s20f3: authenticate with 60:38:e0:b6:60:91
[169048.474075] wlp0s20f3: send auth to 60:38:e0:b6:60:91 (try 1/3)
[169048.513342] wlp0s20f3: authenticated
[169048.513526] wlp0s20f3: associating with AP with corrupt probe response
[169048.516717] wlp0s20f3: associate with 60:38:e0:b6:60:91 (try 1/3)
[169048.521224] wlp0s20f3: RX ReassocResp from 60:38:e0:b6:60:91 (capab=0x411 
status=0 aid=4)
[169048.524033] wlp0s20f3: associated
[169194.133587] wlp0s20f3: disconnect from AP 60:38:e0:b6:60:91 for new auth to 
60:38:e0:b6:60:92
[169194.139026] wlp0s20f3: authenticate with 60:38:e0:b6:60:92
[169194.141759] wlp0s20f3: send auth to

Bug#975644: fail2ban: Debian files (copyright, control) are not up-to-date

2020-11-24 Thread Sylvestre Ledru


control: severity -1 normal

Le 24/11/2020 à 16:10, Vincent Lefevre a écrit :

Package: fail2ban
Version: 0.11.1-3
Severity: important

The copyright file contains:



Thanks, I will upload a fix

But I don't think it deserves an important severity.

Cheers

S

Bug#951077: closed by Thomas Goirand (Fixed in 1.28.0 ?)

2020-11-24 Thread Michael Prokop

* Debian Bug Tracking System [Mon Nov 23, 2020 at 10:45:07AM +]:

> This is an automatic notification regarding your Bug report
> which was filed against the git-review package:

> #951077: git-review: man page out of sync with implementation

> It has been closed by Thomas Goirand .

[...]

> It looks like to me there's no much difference between the man page and
> the --help anymore. Anyway, that's an upstream thing, and I don't wish
> to become the man page maintainer, so if you want to fix, feel free to
> either file a bug upstream or contribute there.

IMO this is rather unlovely bug handling (especially as it's still
ontopic). Anyway, I took care of forwarding this towards upstream:
https://storyboard.openstack.org/#!/story/2008387

regards
-mika-


signature.asc
Description: Digital signature

Bug#975655: RFS: smlnj -- Standard ML of New Jersey interactive compiler [QA upload]

2020-11-24 Thread Fabian Wolff

Package: sponsorship-requests
Severity: normal

Dear Mentors,

I am looking for a sponsor for a QA upload of the 'smlnj' package.

The Debian package has not been updated in four years except for minor
maintenance work. I have now packaged the latest upstream version,
110.98.1, which, most notably, contains actual support for amd64:
Until now, the smlnj package on amd64 shipped 32-bit binaries; see
#796661.

This is fixed now, but since upstream does not yet support the NLFFI
component for amd64, I had to drop the two corresponding packages for
amd64. They never should have been built on this architecture, anyway,
though, because as I was saying, prior to the version I have now
packaged, the amd64 packages contained 32-bit code.

Apart from this, I performed some maintenance work, such as accounting
for the fact that compat 11 changed the directory into which the -doc
package installs most of its contents. I also added a simple
autopkgtest to verify that the package is functional. The package is
not Lintian-clean, but my changes did not cause any additional
warnings that are not already present in the current version.


I would also like to ask you to give me "Maintainer" access to the
Salsa repository (https://salsa.debian.org/debian/smlnj) so that I can
push my changes to it; currently, you can look at them in this fork
and on Mentors:

  https://salsa.debian.org/wolff/smlnj
  https://mentors.debian.net/package/smlnj/


Thanks!
Fabian

Bug#975641: flatpak: Some executables are missing from the packaging