Bug#944856: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u2

[Dmitry Shachnev]

Control: fixed 935627 qtbase-opensource-src/5.12.2+dfsg-1
Control: tags -1 - moreinfo

Hi Adam!

On Sat, Dec 07, 2019 at 07:35:27PM +, Adam D. Barratt wrote:
> Hmmm. Is the BTS metadata for #935627 accurate? The final entry in the
> log is currently a "pending" tag from August, but no bug closure, and
> the fix doesn't appear to be mentioned in the current git changelog.

That bug was filed when Qt 5.12 was already available in experimental, and
the first line of it says “Qt5 < 5.12 have a rather nasty bug […]”.

The relevant upstream patch [1] was merged in v5.12.0-beta1 already.
So I'm adjusting the metadata to show that it is fixed in 5.12. Hope it's
better now.

I don't want to close it because the fix in testing / 5.12 is not what the
reporter wanted. So I would prefer to let it be closed by buster upload.

[1]: https://codereview.qt-project.org/c/qt/qtbase/+/239918

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#946378: squashfs-tools: xattr-related non-determinism ⇒ non-reproducible SquashFS

[intrigeri]

Package: squashfs-tools
Version: 1:4.4-1
Severity: normal
Tags: patch
User: tails-...@boum.org
Usertags: reproducible-builds

Hi,

as reported on https://github.com/plougher/squashfs-tools/issues/78,
mksquashfs sometimes produces non-reproducible SquashFS when xattrs
are used in the input directory. This causes trouble for Tails.

Unfortunately I did not manage to create a minimal reproducer for the
problem, but the attached patch fixes the problem for me in my
real-world scenario. This patch has been submitted upstream 2 years
ago¹; I'm trying to encourage upstream to review it but I don't know
how long it will take, so it would be sweet if we could have this
trivial fix in Debian earlier :)

[1] https://github.com/plougher/squashfs-tools/pull/39

Cheers,
-- 
intrigeri

commit ad4b8f0aad4c659c1e437ed94897230cbdb9800d
Author: Henrik Grindal Bakken 
Origin: https://github.com/plougher/squashfs-tools/pull/39/commits/ad4b8f0aad4c659c1e437ed94897230cbdb9800d
Date:   Wed Dec 6 13:18:51 2017 +0100

xattr: Initialize header to avoid valgrind warning

The 'unused' field was written uninitialized to disk.  This introduces
a randomness into the file system, and it also ends up as a valgrind
warning.

--- a/squashfs-tools/xattr.c
+++ b/squashfs-tools/xattr.c
@@ -425,7 +425,7 @@
 	int i, avail_bytes;
 	char *datap = data_cache;
 	long long start_bytes = bytes;
-	struct squashfs_xattr_table header;
+	struct squashfs_xattr_table header = {};
 
 	if(xattr_ids == 0)
 		return SQUASHFS_INVALID_BLK;

Bug#946376: package info uninstallable

[Mechtilde Stehmann]

Hello,

for me I could solve the problem.

the reason was a defect file /etc/environment which was written last at
2018-12-29.

I never touched it. There was an imcompletly quoted path. This defined
the path to JAVA_HOME for Java 11.

So I'll close this bug.

-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#946376: package info uninstallable

[Norbert Preining]

On Sun, 08 Dec 2019, Mechtilde Stehmann wrote:
> /usr/sbin/update-info-dir: 3: /etc/environment: Syntax error:
> Unterminated quoted string

You have a broken file
/etc/environment
as clearly stated.

Please check that.

Norbert

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

Bug#946377: geocode-glib: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: geocode-glib
Version: 3.26.1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

ear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The geocode-glib tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru geocode-glib-3.26.1/debian/tests/build 
geocode-glib-3.26.1/debian/tests/build
--- geocode-glib-3.26.1/debian/tests/build  2019-03-15 03:02:30.0 
-0700
+++ geocode-glib-3.26.1/debian/tests/build  2019-12-07 22:36:37.0 
-0800
@@ -7,6 +7,12 @@
 
 cd "${AUTOPKGTEST_TMP:-"${ADTTMP}"}"
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat > trivial.c <
 
@@ -17,6 +23,6 @@
 }
 EOF
 
-gcc -o trivial trivial.c $(pkg-config --cflags --libs geocode-glib-1.0)
+${CROSS_COMPILE}gcc -o trivial trivial.c $(${CROSS_COMPILE}pkg-config --cflags 
--libs geocode-glib-1.0)
 test -x trivial
 ./trivial

Bug#942999: doxypy: Python2 removal in sid/bullseye

[Graham Inggs]

Control: severity -1 serious

Both python-odf and scolasync no longer build-depend on doxypy.

Bug#946376: package info uninstallable

[Mechtilde Stehmann]

Package: info
Version: 6.7.0.dfsg.2-5
Severity: critical

Hello,

I want to install the package info.

I get the following message:
install-info (6.7.0.dfsg.2-5) wird eingerichtet ...
/usr/sbin/update-info-dir: 3: /etc/environment: Syntax error:
Unterminated quoted string
dpkg: Fehler beim Bearbeiten des Paketes install-info (--configure):
 »installiertes install-info-Skript des Paketes
post-installation«-Unterprozess gab den Fehlerwert 2 zurück
Fehler traten auf beim Bearbeiten von:
 install-info
E: Sub-process /usr/bin/dpkg returned an error code (1)

Now I can't do any update of another package. so I set the severity to
critical.


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

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




-- 
Mechtilde Stehmann
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#946375: pulseaudio: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: pulseaudio
Version: 13.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The pulseaudio tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pulseaudio-13.0/debian/tests/build pulseaudio-13.0/debian/tests/build
--- pulseaudio-13.0/debian/tests/build  2019-09-17 23:38:48.0 -0700
+++ pulseaudio-13.0/debian/tests/build  2019-12-07 21:38:59.0 -0800
@@ -10,6 +10,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < buildtest.c
 #include 
 #include 
@@ -23,7 +30,7 @@
 }
 EOF
 
-gcc -o buildtest buildtest.c $(pkg-config --cflags --libs libpulse)
+${CROSS_COMPILE}gcc -o buildtest buildtest.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs libpulse)
 echo "build: OK"
 [ -x buildtest ]
 ./buildtest

Bug#946308: /usr/games/fs2_open: fs2_open crashes immediately (illegal instruction)

[Nils Dagsson Moskopp]

Bernhard Übelacker  writes:

> Dear Maintainer,
> I tried to reproduce inside a minimal Buster i386 qemu VM
> and received also an "Illegal instruction" message.
>
> It looks like it tries to execute an AVX instruction that
> my CPU should support, but is not enabled inside the VM.
>
> The usage of AVX might originate from the compiler
> flag "-march=native".
> This might be added in configure.ac, lines 149 or 163.

To clarify:

- line 149 is for a target architecture matching “x86_64-*-linux*”
- line 163 is for a target architecture matching “*-*-linux*”

In both cases, using “-march=native” seems like a wrong thing to use.
 states clearly:

Using -march=native enables all instruction subsets supported by the
local machine (hence the result might not run on different machines).

> The solution could be to just add this configure flag:
> -CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech
> +CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech 
> --enable-generic-architecture
>
> Then these flags get used instead:
>   -mtune=generic -mfpmath=sse -msse -msse2
> Do these also violate the i386 Buster baseline?
>
> Kind regards,
> Bernhard

I have re-built the Debian package according to those instructions and
it seems to work on my machine … Then again, I suspect this would also
have been the case if I just had rebuilt the package – due to “native”
architecture choice. It now gives an entirely different error message:

; cd /usr/share/games/freespace2-open/ && fs2_open
ERROR: " Web cursor bitmap not found.  This is most likely due to one of three 
reasons: 1) You're running FreeSpace Open from somewhere other than 
your FreeSpace 2 folder; 2) You've somehow corrupted your FreeSpace 2 
installation, e.g. by modifying or removing the retail VP files;   3) You 
haven't installed FreeSpace 2 at all.  (Note that installing FreeSpace Open 
does NOT remove the need for a FreeSpace 2 installation.) Number 1 can be fixed 
by simply moving the FreeSpace Open executable file to the FreeSpace 2 folder.  
Numbers 2 and 3 can be fixed by installing or reinstalling FreeSpace 2." at 
graphics/2d.cpp:1079
AL lib: (EE) alc_cleanup: 1 device not closed

I definitely have not installed FreeSpace 2 content, so I expect this.

Bug#877802: lintian: Please include file name and line number in output

[Felix Lechner]

Hi Chris,

On Sat, Dec 7, 2019 at 2:57 PM Chris Lamb  wrote:
>
> If it helps, my plan was that we call "tag" with many more arguments
> which all end up in said metadata, but each tag had a "to_string"
> method (or similar) that would render it into the existing flat,
> plaintext string... both for the benefit of retaining command-line
> conciseness but also for the benefit of existing overrides and to
> roll this out over many many releases.

Please let me pick your brain. My current solution is to instantiate
tags as they are issued, but they are a bit cumbersome to use. Did you
have a more concise approach?

Kind regards
Felix Lechner

Bug#612146: pkill via process number

[積丹尼 Dan Jacobson]

OK. Then at man pkill
   -F, --pidfile file
  Read PID's from file.  This option is perhaps more useful for 
pkill than pgrep.

add example

$ sleep &
[2] 40473
$ pkill -F /dev/stdin <<< $!
[2]+  Terminated  sleep 

as the workaround allowing pkill to work directly with process numbers.

Bug#926618: RFP: webext-plasma-integration -- provides integration of web browsers with the Plasma desktop

[John Scott]

On Thu, 11 Apr 2019 11:30:43 -0400 Nicholas D Steeves  
wrote:
> I wonder if that package fulfills this RFP?  If not, and if this bug
> remains inactive for a month, please ping me and I'll take a look.
Ping :)

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

Bug#936508: fdb: Python2 removal in sid/bullseye

[Scott Kitterman]

On Saturday, December 7, 2019 8:03:42 PM EST Russell Stuart wrote:
> On Sat, 2019-12-07 at 23:46 +, Scott Kitterman wrote:
> > I won't, but I think you have it backwards.  Until changes like this
> > are made, python2 can't be removed.  Your approach leaves us with a
> > Catch 22.
> 
> Thanks.
> 
> Part of the reason for my reluctance is I don't understand the haste in
> removing Python2.  It will wither and die anyway in it's own time, but
> why is it necessary to speed that process up?
> 
> As the fdb maintainer I agree it would be nice to have just one version
> to support, but I am also a fdb user.  For a user it creates a lot of
> urgent work.  I (I suspect like a lot of sysadmin's who use python as
> an alternative to bash) have accumulated a lot of python2 scripts over
> the decades.  When I touch one I convert it to python3, but it's a slow
> process.  I can't see any good reason to speed it up, and it doesn't
> help python3 is worse than python2 as a bash replacement.
> 
> Now you are forcing me to speed that process up.  If I thought I was an
> outlier then c'est la vie I guess, but my gut feeling is I am not, and
> there have been comments made in passing on debian-devel that back that
> up.
> 
> There hasn't been much discussion so far, but when it happens I suspect
> there is going to be a lot of push back.  Thus my wait and see
> attitude.  In the mean time if maintaining Python2 is too much of a
> burden you could always orphan it.

Neither the Debian Python interpreter maintainer nor the members of the major 
Python related teams (DPMT and PAPT) think shipping a python interpreter 
without security support is a good idea.  That's, AIUI, the primary driver.  
So far, I think we're about 60% through the upgrading/removal of python2 
related packages.

So far, there hasn't been significant push back that I've seen.  So far, we've 
been trying to gracefully unwind the python2 stack without breaking a lot of 
things.  I think it's more likely that things would get less graceful than 
that the goal would be abandoned.  At some point python-future is going to be 
removed from Testing and you'll have to decide if you want to ship fdb in the 
next release or not.

I'll go back to just waiting and seeing how this plays out.

Scott K

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

Bug#944947: python-uinput: diff for NMU version 0.11.2-2.1

[أحمد المحمودي]

On Mon, Dec 02, 2019 at 11:47:36PM -0500, Boyuan Yang wrote:
> I've prepared an NMU for python-uinput (versioned as 0.11.2-2.1) and
> uploaded it to DELAYED/1. Please feel free to tell me if I
> should delay it longer.
---end quoted text---

Thanks,

I wasn't able to upload since I don't have DM upload rights

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#854134: Could icons ship separately?

[Felix Lechner]

Control: tags -1 + moreinfo

Hi Laurent,

> A check should maybe be added to verify that the icon specified in the
> .desktop file exists in the hicolor theme in png format.

Could icons ship in a separate, architecture-independent package while
the desktop file is created from a template when the binary is build,
and may thus vary by architecture?

Some relationships may be hard to track, although Lintian can see them
if both installation (deb) packages were built from the same sources.
Are there icon sets that are maintained separately for the benefit of
other projects?

How about an info tag if a package's desktop file relies on external
icon resources?

Kind regards,
Felix

Bug#919602: apache2: reload via systemd: apache2.service: Failed to set up mount namespacing: No such file or directory

[Jason Lingohr]

On Wed, 23 Oct 2019 16:31:39 +0200 Sven Bartscher wrote:
> Hi,
>
> do you use tools to age out files in /var/tmp or /tmp? I recently
> encountered this problem myself (on Jessie) and the cause was, that
> tmpreaper deleted the private tmp directories of the apache2.service
> unit. I didn't observe the apache2 service being stopped after receiving
> the error though, so you problem might actually be separate from mine.


I'm having the same issue on a fresh buster install, and don't have 
tmpreaper installed.  I only see systemd-tmpfiles-clean.service run a 
few hours before.

Bug#943874: pure-ftpd: pure-ftp error on upgrade

[Andreas Beckmann]

Followup-For: Bug #943874

In sid pure-ftpd:amd64 ships

lrwxrwxrwx root/root 0 2019-10-30 17:37 ./usr/share/doc/pure-ftpd -> 
pure-ftpd-common

but pure-ftpd-common:all (which gets unpacked first) ships

drwxr-xr-x root/root 0 2019-10-30 17:37 ./usr/share/doc/pure-ftpd/
-rw-r--r-- root/root 12844 2019-10-30 17:37 ./usr/share/doc/pure-ftpd/FAQ.gz
-rw-r--r-- root/root  2090 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.Authentication-Modules.gz
-rw-r--r-- root/root  1124 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.Configuration-File
-rw-r--r-- root/root  4238 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.LDAP.gz
-rw-r--r-- root/root  1004 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.MacOS-X
-rw-r--r-- root/root  3684 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.MySQL.gz
-rw-r--r-- root/root  3312 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.PGSQL.gz
-rw-r--r-- root/root  5711 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.TLS.gz
-rw-r--r-- root/root  4497 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/README.Virtual-Users.gz
-rw-r--r-- root/root  4289 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/pure-ftpd.conf.gz
-rw-r--r-- root/root  2009 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/pureftpd-ldap.conf
-rw-r--r-- root/root  3455 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/pureftpd-mysql.conf
-rw-r--r-- root/root  2976 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/pureftpd-pgsql.conf
-rw-r--r-- root/root  2548 2019-10-30 17:37 
./usr/share/doc/pure-ftpd/pureftpd.schema
drwxr-xr-x root/root 0 2019-10-30 17:37 
./usr/share/doc/pure-ftpd-common/
-rw-r--r-- root/root  3493 2018-01-04 12:13 
./usr/share/doc/pure-ftpd-common/AUTHORS.gz
-rw-r--r-- root/root  2245 2011-09-07 05:02 
./usr/share/doc/pure-ftpd-common/HISTORY
-rw-r--r-- root/root44 2019-03-25 15:48 
./usr/share/doc/pure-ftpd-common/NEWS.gz
-rw-r--r-- root/root  2090 2019-03-25 17:10 
./usr/share/doc/pure-ftpd-common/README.Authentication-Modules.gz
-rw-r--r-- root/root  1124 2018-01-04 12:13 
./usr/share/doc/pure-ftpd-common/README.Configuration-File
-rw-r--r-- root/root  1311 2019-10-30 17:37 
./usr/share/doc/pure-ftpd-common/README.Debian
-rw-r--r-- root/root  2071 2018-01-04 12:13 
./usr/share/doc/pure-ftpd-common/README.Donations.gz
-rw-r--r-- root/root  4238 2018-01-04 12:13 
./usr/share/doc/pure-ftpd-common/README.LDAP.gz
-rw-r--r-- root/root  3684 2018-02-09 13:03 
./usr/share/doc/pure-ftpd-common/README.MySQL.gz
-rw-r--r-- root/root  3312 2018-01-04 12:13 
./usr/share/doc/pure-ftpd-common/README.PGSQL.gz
-rw-r--r-- root/root  5711 2019-03-25 15:48 
./usr/share/doc/pure-ftpd-common/README.TLS.gz
-rw-r--r-- root/root  4497 2018-01-04 12:13 
./usr/share/doc/pure-ftpd-common/README.Virtual-Users.gz
-rw-r--r-- root/root 26547 2019-03-25 18:25 
./usr/share/doc/pure-ftpd-common/README.gz
-rw-r--r-- root/root  6561 2018-02-26 00:19 
./usr/share/doc/pure-ftpd-common/THANKS.gz
-rw-r--r-- root/root  7899 2019-10-30 17:37 
./usr/share/doc/pure-ftpd-common/changelog.Debian.gz
-rw-r--r-- root/root 36745 2019-04-03 11:01 
./usr/share/doc/pure-ftpd-common/changelog.gz
-rw-r--r-- root/root  1463 2019-10-30 17:37 
./usr/share/doc/pure-ftpd-common/copyright
-rw-r--r-- root/root  2548 2011-09-07 05:02 
./usr/share/doc/pure-ftpd-common/pureftpd.schema

Note the duplication of some README files.

As a result there is no /usr/share/doc/pure-ftpd/copyright, which is a policy
violation on its own.

It is bad practice to have -doc symlinks from arch:any to arch:all packages.

Andreas

Bug#941198: In support of mandatory unit files

[Russ Allbery]

Tobias Frost  writes:

> JFTR, I maintain gmedia-resurrect and in this package I failed despite
> trying to create a systemd unit file with equal functinality as the
> init.d script*.  So for this package the proposoal would lead to
> regressions for the users.

A Policy should means that if there is some stronger reason (such as that
adding a unit file would introduce new bugs), there is nothing requiring
you to do so.  It indicates that not having a unit file is a bug, but it's
just a bug, and Debian packages are not expected to be bug-free.  Other
bugs may be more important.

That said, if you'd like help with this, I or someone else following this
thread may be willing to take a look and figure out a way to replicate the
init script behavior.  It's normally possible to handle /etc/default
conffiles in systemd units, although it can be a little complicated.

-- 
Russ Allbery (r...@debian.org)  

Bug#936508: fdb: Python2 removal in sid/bullseye

[Russell Stuart]

On Sat, 2019-12-07 at 23:46 +, Scott Kitterman wrote:
> I won't, but I think you have it backwards.  Until changes like this
> are made, python2 can't be removed.  Your approach leaves us with a
> Catch 22.

Thanks.

Part of the reason for my reluctance is I don't understand the haste in
removing Python2.  It will wither and die anyway in it's own time, but
why is it necessary to speed that process up?

As the fdb maintainer I agree it would be nice to have just one version
to support, but I am also a fdb user.  For a user it creates a lot of
urgent work.  I (I suspect like a lot of sysadmin's who use python as
an alternative to bash) have accumulated a lot of python2 scripts over
the decades.  When I touch one I convert it to python3, but it's a slow
process.  I can't see any good reason to speed it up, and it doesn't
help python3 is worse than python2 as a bash replacement.

Now you are forcing me to speed that process up.  If I thought I was an
outlier then c'est la vie I guess, but my gut feeling is I am not, and
there have been comments made in passing on debian-devel that back that
up.

There hasn't been much discussion so far, but when it happens I suspect
there is going to be a lot of push back.  Thus my wait and see
attitude.  In the mean time if maintaining Python2 is too much of a
burden you could always orphan it.


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

Bug#941198: In support of mandatory unit files

[Tobias Frost]

On Wed, Dec 04, 2019 at 07:03:09PM +0100, Simon Richter wrote:
> Hi,
> 
> chiming in as I've been pointed to this bug: I agree with Ansgar in that
> adding unit files does not hurt sysvinit support in the least, provided we
> still get to ignore them.
> 
> I'd even be in favour of making them mandatory (i.e. upgrading the lintian
> warning to an error), and I don't see how the GR outcome would affect the
> question of whether we want to ship unit files in packages, so I'd be fine
> with going ahead with this change even while the GR is still running.
> 
> As long as we support sysv-rc, init scripts will have to remain mandatory
> as well, though.
> 
> IMO, an ideal outcome would be that systemd can completely ignore any init
> scripts from Debian packages, i.e. the compatibility generator, if
> installed, would only have to generate units for init scripts that didn't
> come from a package, and default installations would not include this
> generator.

JFTR, I maintain gmedia-resurrect and in this package I failed despite trying
to create a systemd unit file with equal functinality as the init.d script*.
So for this package  the proposoal would lead to regressions for the users.
 
> The same should be done for cron files vs timer units -- ideally, we'd get
> to a state where cron files can be completely ignored by systemd because it
> is a bug to not have a timer unit with the same settings. That would allow
> systemd users to get rid of the spurious wakeups as well, which I'd
> consider a major win.
> 
>Simon

* I do not have currently the amount of spoons avialable to explain the details,
but it has to do with the confile in /etc/default needed to be read by the unit
file and parsed into daemon parameters.

Bug#936251:

[Diego Alvarez]

Package: src:bup
Version: 0.29.3-2
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal py2keep

I believe this application should be kept in debian for the time being,
given its function as a backup tool.
There is active work being done on it in order to make it compatible with
python3.
I'm not aware of the popcon numbers for it, but I believe it to be popular
enough to warrant keeping it around until the port to python3 has been
finished.

Bug#946374: gdk-pixbuf: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: gdk-pixbuf
Version: 2.40.0+dfsg-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The gdk-pixbuf tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gdk-pixbuf-2.40.0+dfsg/debian/tests/build 
gdk-pixbuf-2.40.0+dfsg/debian/tests/build
--- gdk-pixbuf-2.40.0+dfsg/debian/tests/build   2019-10-10 08:40:15.0 
-0700
+++ gdk-pixbuf-2.40.0+dfsg/debian/tests/build   2019-12-07 16:54:50.0 
-0800
@@ -8,6 +8,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < build_test.c
 
 #include 
@@ -22,7 +29,7 @@
 }
 EOF
 
-gcc -o build_test build_test.c -Wall -Werror `pkg-config --cflags --libs 
gdk-pixbuf-2.0`
+${CROSS_COMPILE}gcc -o build_test build_test.c -Wall -Werror 
`${CROSS_COMPILE}pkg-config --cflags --libs gdk-pixbuf-2.0`
 echo "build: OK"
 [ -x build_test ]
 ./build_test

Bug#946373: python3-sfml: copyright file missing (policy 12.5)

[Andreas Beckmann]

Package: python3-sfml
Version: 2.2~git20150611.196c88+dfsg-5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

a test with piuparts revealed that your package misses the copyright
file after installation, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

After the installation /usr/share/doc/$PACKAGE/ just contains the
changelog files.

>From the attached log (scroll to the bottom...):

0m26.6s ERROR: WARN: Inadequate results from running adequate!
  python3-sfml: missing-copyright-file /usr/share/doc/python3-sfml/copyright

  MISSING COPYRIGHT FILE: /usr/share/doc/python3-sfml/copyright
  # ls -lad /usr/share/doc/python3-sfml
  drwxr-xr-x 2 root root 100 Nov 20 05:14 /usr/share/doc/python3-sfml
  # ls -la /usr/share/doc/python3-sfml/
  total 12
  drwxr-xr-x   2 root root  100 Nov 20 05:14 .
  drwxr-xr-x 154 root root 3180 Nov 20 05:14 ..
  -rw-r--r--   1 root root  254 Nov 19 23:20 changelog.Debian.amd64.gz
  -rw-r--r--   1 root root 1990 Nov 19 23:20 changelog.Debian.gz
  -rw-r--r--   1 root root 1720 Jun 11  2015 changelog.gz

python3-sfml-dbg seems to have the same problem.


cheers,

Andreas


python3-sfml_2.2~git20150611.196c88+dfsg-5+b1.log.gz
Description: application/gzip

Bug#946372: fluidsynth: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: fluidsynth
Version: 1.1.11-4
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The fluidsynth tests currently fail in this environment, because they are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru fluidsynth-1.1.11/debian/tests/build 
fluidsynth-1.1.11/debian/tests/build
--- fluidsynth-1.1.11/debian/tests/build2018-03-15 09:24:33.0 
-0700
+++ fluidsynth-1.1.11/debian/tests/build2019-12-07 16:42:33.0 
-0800
@@ -8,6 +8,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < build_test.c
 #include 
 int main(int argc, char** argv) {
@@ -25,7 +32,7 @@
 }
 EOF
 
-gcc -o build_test build_test.c -lfluidsynth
+${CROSS_COMPILE}gcc -o build_test build_test.c -lfluidsynth
 echo "build: OK"
 [ -x build_test ]
 ./build_test

Bug#946371: cairo: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: cairo
Version: 1.16.0-4
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The cairo tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru cairo-1.16.0/debian/tests/build cairo-1.16.0/debian/tests/build
--- cairo-1.16.0/debian/tests/build 2019-03-15 00:57:56.0 -0700
+++ cairo-1.16.0/debian/tests/build 2019-12-07 16:18:51.0 -0800
@@ -8,6 +8,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < build_test.c
 /*
The source code I used here is the actual cairo's
@@ -37,7 +44,7 @@
 }
 EOF
 
-gcc -o build_test build_test.c `pkg-config --cflags --libs cairo`
+${CROSS_COMPILE}gcc -o build_test build_test.c `${CROSS_COMPILE}pkg-config 
--cflags --libs cairo`
 echo "build: OK"
 [ -x build_test ]
 ./build_test

Bug#944138: ITP: libtraceevent -- The libtraceevent library provides APIs to access kernel tracepoint events

[Sudip Mukherjee]

On Fri, Nov 15, 2019 at 11:44:03AM +, Sudip Mukherjee wrote:
> iiuc, Debian kernel can only have patches accepted upstream. And, so
> this is now blocked on:
> https://patchwork.kernel.org/patch/11243801/
> https://patchwork.kernel.org/patch/11246125/
> https://patchwork.kernel.org/patch/11246127/
> 
> I will wait till they are accepted and appears on linux-next.

wip merge request has been opened in salsa at:
https://salsa.debian.org/kernel-team/linux/merge_requests/192

Another patch had to be sent upstream, and once I get the Ack for that
the wip: can be removed from the merge request.

@Ben: if you get some time can you please have an initial look at this.

--
Regards
Sudip

Bug#946370: Packaging problems with yubikey-luks-open

[Josha Foust]

Package: yubikey-luks
Version: 0.5.1+29.g5df2b95-1

To unlock an encrypted Luks volume that has been setup with 
yubikey-luks-enroll, you call
yubikey-luks-open.  However this doesn't work for a couple reason.  First the 
package
installs it to /usr/lib instead of /usr/bin, so it isn't in the path.  Second 
it needs
expect to run, but that is not declared as a dependency.

$ /usr/lib/yubikey-luks/yubikey-luks-open -d /dev/sdh
setting disk to /dev/sdh.
This script will try opening yubikey-luks LUKS container on drive /dev/sdh . If 
this is not what you intended, exit now!
Enter password created with yubikey-luks-enroll: *
/usr/lib/yubikey-luks/yubikey-luks-open: 99: expect: not found

Bug#946361: at-spi2-core: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: at-spi2-core
Followup-For: Bug #946361
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Sorry, the previous patch was incomplete.  Please see attached a complete patch.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru at-spi2-core-2.34.0/debian/tests/control 
at-spi2-core-2.34.0/debian/tests/control
--- at-spi2-core-2.34.0/debian/tests/control2019-09-29 05:38:10.0 
-0700
+++ at-spi2-core-2.34.0/debian/tests/control2019-12-07 12:21:52.0 
-0800
@@ -1,2 +1,2 @@
 Tests: gedit dbind
-Depends: libatspi2.0-dev, build-essential, xauth, xvfb, dbus, at-spi2-core, 
gedit
+Depends: libatspi2.0-dev, build-essential, xauth, xvfb, dbus, at-spi2-core, 
gedit:native
diff -Nru at-spi2-core-2.34.0/debian/tests/dbind 
at-spi2-core-2.34.0/debian/tests/dbind
--- at-spi2-core-2.34.0/debian/tests/dbind  2019-09-29 05:38:10.0 
-0700
+++ at-spi2-core-2.34.0/debian/tests/dbind  2019-12-07 16:03:25.0 
-0800
@@ -3,10 +3,20 @@
 set -e
 
 WORKDIR=$AUTOPKGTEST_TMP
-gcc dbind/dbtest.c -o $WORKDIR/dbtest  \
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+${CROSS_COMPILE}gcc dbind/dbtest.c -o $WORKDIR/dbtest  \
-I . \
-   $(pkg-config --cflags glib-2.0) $(pkg-config --libs glib-2.0) \
-   $(pkg-config --cflags dbus-1) $(pkg-config --libs dbus-1) \
-   $(pkg-config --cflags atspi-2) $(pkg-config --libs atspi-2)
+   $(${CROSS_COMPILE}pkg-config --cflags glib-2.0) \
+   $(${CROSS_COMPILE}pkg-config --libs glib-2.0) \
+   $(${CROSS_COMPILE}pkg-config --cflags dbus-1) \
+   $(${CROSS_COMPILE}pkg-config --libs dbus-1) \
+   $(${CROSS_COMPILE}pkg-config --cflags atspi-2) \
+   $(${CROSS_COMPILE}pkg-config --libs atspi-2)
 
 exec dbus-run-session $WORKDIR/dbtest
diff -Nru at-spi2-core-2.34.0/debian/tests/gedit 
at-spi2-core-2.34.0/debian/tests/gedit
--- at-spi2-core-2.34.0/debian/tests/gedit  2019-09-29 05:38:10.0 
-0700
+++ at-spi2-core-2.34.0/debian/tests/gedit  2019-12-07 16:03:49.0 
-0800
@@ -3,8 +3,17 @@
 set -e
 
 WORKDIR=$AUTOPKGTEST_TMP
-gcc test/memory.c -o $WORKDIR/memory  \
-   $(pkg-config --cflags atspi-2) $(pkg-config --libs atspi-2) \
-   $(pkg-config --cflags gobject-2.0) $(pkg-config --libs gobject-2.0)
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
+${CROSS_COMPILE}gcc test/memory.c -o $WORKDIR/memory  \
+   $(${CROSS_COMPILE}pkg-config --cflags atspi-2) \
+   $(${CROSS_COMPILE}pkg-config --libs atspi-2) \
+   $(${CROSS_COMPILE}pkg-config --cflags gobject-2.0) \
+   $(${CROSS_COMPILE}pkg-config --libs gobject-2.0)
 
 exec xvfb-run -s -noreset -a dbus-run-session --dbus-daemon 
debian/tests/dbus-daemon -- $WORKDIR/memory

Bug#946365: kmail becomes unresponsive with active preview pane on wayland-plasma

[John Scott]

> Started kmail on wayland-plasma with active preview pane. The preview stays
> black at the beginning. When e.g.  hovering with the mouse over the preview,
Do you see a black rectangle like in the image I've attached? That is
https://bugs.kde.org/show_bug.cgi?id=397825 . If not, try to get a screenshot 
with Spectacle (it might not work unless you choose Full Screen or Current 
Screen).

> clicking on a different email or changing the folder the whole kmail
> software stops reacting and the title bar shows an unresponsive
> notification. No crash notification.
Have you tried using gdb to see what's going on? Do you get any output if you 
run KMail from a terminal emulator?

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

Bug#946118: synaptics touchpad does not work in debian installer graphical mode

[Samuel Thibault]

Samuel Thibault, le sam. 07 déc. 2019 22:54:09 +0100, a ecrit:
> Samuel Thibault, le mer. 04 déc. 2019 01:52:36 +0100, a ecrit:
> > Thinking of it... IIRC the touchpad is not working on my DELL XPS13
> > laptop in g-i.
> 
> Indeed, it doesn't work.
> 
> > What I can see of it on normal boot of installed system is:
> > 
> > [6.097298] input: DELL07E6:00 06CB:76AF Mouse as 
> > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input12
> > [6.097660] input: DELL07E6:00 06CB:76AF Touchpad as 
> > /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input13
> > [6.098066] hid-generic 0018:06CB:76AF.0002: input,hidraw1: I2C HID 
> > v1.00 Mouse [DELL07E6:00 06CB:76AF] on i2c-DELL07E6:00
> > 
> > and lsmod | grep i2c gives
> > 
> > i2c_designware_platform16384  0
> > i2c_designware_core20480  1 i2c_designware_platform
> > i2c_i801   32768  0
> > i2c_hid28672  0
> > hid   126976  4 i2c_hid,usbhid,hid_multitouch,hid_generic
> > 
> > I don't see the i2c_designware* modules in the g-i image, perhaps that
> > needs to be included for some hardware?
> 
> I tried to rmmod i2c_designware_platform on my installed system, the
> mouse stopped working, so it seems to be required, at the very least.
> 
> I tried to add i2c-modules to a g-i image, i2c_designware_platform
> didn't get loaded automatically, and even loading it manually didn't
> make the mouse detected.

I found that the i2c bus is behind a PCI card which is driven by the
intel_lpss_pci driver. Loading this by hand got the touchpad detected.
Xorg didn't pick it up however, only the touchscreen.

Samuel

Bug#936508: fdb: Python2 removal in sid/bullseye

[Scott Kitterman]

On December 7, 2019 11:23:50 PM UTC, Russell Stuart 
 wrote:
>On Sat, 2019-12-07 at 15:27 -0500, Scott Kitterman wrote:
>> Technically this is blocked by #938555, but it's only a Suggests
>> relationship, so I would think it's OK to go ahead to drop the
>> python-fdb binary.  If you are busy and would prefer someone else
>> handle it, please let me know and I'll be glad to do an NMU.
>
>My view is the appropriate time to look at it is when python2 is
>dropped.  Until then it's speculation as to whether it will be dropped,
>and I'm not interested in doing things that may have to be undone
>latter.
>
>Please do not NMU.

I won't, but I think you have it backwards.  Until changes like this are made, 
python2 can't be removed.  Your approach leaves us with a Catch 22.

Scott K

Bug#936508: fdb: Python2 removal in sid/bullseye

[Russell Stuart]

On Sat, 2019-12-07 at 15:27 -0500, Scott Kitterman wrote:
> Technically this is blocked by #938555, but it's only a Suggests
> relationship, so I would think it's OK to go ahead to drop the
> python-fdb binary.  If you are busy and would prefer someone else
> handle it, please let me know and I'll be glad to do an NMU.

My view is the appropriate time to look at it is when python2 is
dropped.  Until then it's speculation as to whether it will be dropped,
and I'm not interested in doing things that may have to be undone
latter.

Please do not NMU.


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

Bug#946369: gcr: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: gcr
Version: 3.34.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The gcr tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gcr-3.34.0/debian/tests/libgck-1-dev 
gcr-3.34.0/debian/tests/libgck-1-dev
--- gcr-3.34.0/debian/tests/libgck-1-dev2019-10-22 03:20:09.0 
-0700
+++ gcr-3.34.0/debian/tests/libgck-1-dev2019-12-07 15:30:29.0 
-0800
@@ -11,6 +11,13 @@
 export XDG_RUNTIME_DIR="$WORKDIR"
 trap 'rm -rf "$WORKDIR"' 0 INT QUIT ABRT PIPE TERM
 cd "$WORKDIR"
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < test.c
 #include 
 
@@ -26,7 +33,7 @@
 
 # Deliberately word-splitting cflags and pkg-config's output:
 # shellcheck disable=SC2046 disable=SC2086
-gcc ${cflags} -o gck-test test.c $(pkg-config --cflags --libs gck-1)
+${CROSS_COMPILE}gcc ${cflags} -o gck-test test.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs gck-1)
 echo "build: OK"
 [ -x gck-test ]
 ./gck-test
diff -Nru gcr-3.34.0/debian/tests/libgcr-3-dev 
gcr-3.34.0/debian/tests/libgcr-3-dev
--- gcr-3.34.0/debian/tests/libgcr-3-dev2019-10-22 03:20:09.0 
-0700
+++ gcr-3.34.0/debian/tests/libgcr-3-dev2019-12-07 15:30:29.0 
-0800
@@ -11,6 +11,13 @@
 export XDG_RUNTIME_DIR="$WORKDIR"
 trap 'rm -rf "$WORKDIR"' 0 INT QUIT ABRT PIPE TERM
 cd "$WORKDIR"
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < base.c
 #include 
 
@@ -37,21 +44,21 @@
 
 # Deliberately word-splitting cflags and pkg-config's output:
 # shellcheck disable=SC2046 disable=SC2086
-gcc ${cflags} -o gcr-test ui.c $(pkg-config --cflags --libs gcr-3)
+${CROSS_COMPILE}gcc ${cflags} -o gcr-test ui.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs gcr-3)
 echo "build: OK"
 [ -x gcr-test ]
 xvfb-run -a dbus-run-session -- ./gcr-test
 echo "run: OK"
 
 # shellcheck disable=SC2046 disable=SC2086
-gcc ${cflags} -o base-test base.c $(pkg-config --cflags --libs gcr-ui-3)
+${CROSS_COMPILE}gcc ${cflags} -o base-test base.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs gcr-ui-3)
 echo "build: OK"
 [ -x base-test ]
 ./base-test
 echo "run: OK"
 
 # shellcheck disable=SC2046 disable=SC2086
-gcc ${cflags} -o ui-test ui.c $(pkg-config --cflags --libs gcr-ui-3)
+${CROSS_COMPILE}gcc ${cflags} -o ui-test ui.c $(${CROSS_COMPILE}pkg-config 
--cflags --libs gcr-ui-3)
 echo "build: OK"
 [ -x ui-test ]
 xvfb-run -a dbus-run-session -- ./ui-test

Bug#946368: DeprecationWarning for using collections instead of collections.abc

[Toni]

Package: python3-jsonschema
Version: 2.6.0-4
Severity: minor
Tags: upstream


Hi,

please backport this fix from unstable:

  https://github.com/Julian/jsonschema/blob/master/jsonschema/compat.py#L11

It would kill a warning that is a bit obnoxious, and should have no ill
side effect.


Thanks,
Toni



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'proposed-updates'), (90, 'testing'), (70, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-jsonschema depends on:
ii  python33.7.3-1
ii  python3-pkg-resources  40.8.0-1

python3-jsonschema recommends no packages.

Versions of packages python3-jsonschema suggests:
pn  python-jsonschema-doc  

-- no debconf information

Bug#946367: gconf: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: gconf
Version: 3.2.6-5
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The gconf tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru gconf-3.2.6/debian/tests/build gconf-3.2.6/debian/tests/build
--- gconf-3.2.6/debian/tests/build  2016-10-11 07:56:11.0 -0700
+++ gconf-3.2.6/debian/tests/build  2019-12-07 15:21:37.0 -0800
@@ -8,6 +8,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < build_test.c
 #include 
 #include 
@@ -21,7 +28,7 @@
 }
 EOF
 
-gcc -o build_test build_test.c -Wall -Werror `pkg-config --libs --cflags 
gobject-2.0 gconf-2.0`
+${CROSS_COMPILE}gcc -o build_test build_test.c -Wall -Werror 
`${CROSS_COMPILE}pkg-config --libs --cflags gobject-2.0 gconf-2.0`
 echo "build: OK"
 [ -x build_test ]
 ./build_test

Bug#946366: dconf: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: dconf
Version: 0.34.0-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The dconf tests currently fail in this environment, because they are build
tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru dconf-0.34.0/debian/tests/build dconf-0.34.0/debian/tests/build
--- dconf-0.34.0/debian/tests/build 2019-09-11 01:14:17.0 -0700
+++ dconf-0.34.0/debian/tests/build 2019-12-07 15:11:51.0 -0800
@@ -8,6 +8,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < build_test.c
 #include 
 int main(int argc, char** argv) {
@@ -16,7 +23,7 @@
 }
 EOF
 
-gcc -o build_test build_test.c `pkg-config --cflags --libs dconf`
+${CROSS_COMPILE}gcc -o build_test build_test.c `${CROSS_COMPILE}pkg-config 
--cflags --libs dconf`
 echo "build: OK"
 [ -x build_test ]
 ./build_test

Bug#946365: kmail becomes unresponsive with active preview pane on wayland-plasma

[Silvério Santos]

Package: kmail
Version: 4:18.08.3-4
Severity: important

Dear Maintainer,

Started kmail on wayland-plasma with active preview pane. The preview stays
black at the beginning. When e.g.  hovering with the mouse over the preview,
clicking on a different email or changing the folder the whole kmail software
stops reacting and the title bar shows an unresponsive notification. No crash
notification.

When not interacting with the enabled preview pane the software stays
responsive, even the settings can be reached to disable preview, which makes
kmail work fine. EMail content can then be viewed in separately opened windows
by doubleclicking them. Disabling HTML preference does not help.

This problem does not happen with the preview pane disabled and in either
configuration on X-Window.

Running Debian testing, KMail 18.08.3-4




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

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

Versions of packages kmail depends on:
ii  akonadi-server4:18.08.3-11
ii  kdepim-runtime4:18.08.3-6
ii  kio   5.62.1-2+b1
ii  libc6 2.29-3
ii  libgcc1   1:9.2.1-21
ii  libgpgmepp6   1.13.1-1
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-18.08]   4:18.08.3-11
ii  libkf5akonadicontact5 [libkf5akonadicontact5-18.08]   4:18.08.3-4
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-18.08] 4:18.08.3-11
ii  libkf5akonadimime5 [libkf5akonadimime5-18.08] 4:18.08.3-3
ii  libkf5akonadisearch-bin   4:18.08.3-3
ii  libkf5akonadisearch-plugins   4:18.08.3-3
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-18.08]   4:18.08.3-3
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-18.08]   4:18.08.3-3
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-18.08]   4:18.08.3-11
ii  libkf5bookmarks5  5.62.0-1+b1
ii  libkf5calendarcore5abi2 [libkf5calendarcore5-18.08]   4:18.08.3-3
ii  libkf5calendarutils5 [libkf5calendarutils5-18.08] 4:18.08.3-4
ii  libkf5codecs5 5.62.0-1
ii  libkf5completion5 5.62.0-1+b1
ii  libkf5configcore5 5.62.0-1+b1
ii  libkf5configgui5  5.62.0-1+b1
ii  libkf5configwidgets5  5.62.0-1+b1
ii  libkf5contacts5 [libkf5contacts5-18.08]   4:18.08.3-4
ii  libkf5coreaddons5 5.62.0-1
ii  libkf5crash5  5.62.0-1+b1
ii  libkf5dbusaddons5 5.62.0-1
ii  libkf5followupreminder5 [libkf5followupreminder5-18.08]   4:18.08.3-4
ii  libkf5grantleetheme-plugins   18.08.3-3
ii  libkf5gravatar5abi2 [libkf5gravatar5-18.08]   4:18.08.3-3
ii  libkf5guiaddons5  5.62.0-2
ii  libkf5i18n5   5.62.0-1
ii  libkf5iconthemes5 5.62.0-1+b1
ii  libkf5identitymanagement5 [libkf5identitymanagement5-18.08]   18.08.3-4
ii  libkf5itemmodels5 5.62.0-1
ii  libkf5itemviews5  5.62.0-1+b1
ii  libkf5jobwidgets5 5.62.0-1+b1
ii  libkf5kcmutils5   5.62.0-1+b1
ii  libkf5kiocore55.62.1-2+b1
ii  libkf5kiofilewidgets5 5.62.1-2+b1
ii  libkf5kiowidgets5 5.62.1-2+b1
ii  libkf5kontactinterface5 [libkf5kontactinterface5-18.08]   18.08.3-3
ii  libkf5ksieveui5 [libkf5ksieveui5-18.08]   4:18.08.3-5
ii  libkf5libkdepim5 [libkf5libkdepim5-18.08] 4:18.08.3-4
ii  libkf5libkdepimakonadi5 [libkf5libkdepimakonadi5-18.08]   4:18.08.3-4
ii  libkf5libkleo5 [libkf5libkleo5-18.08] 4:18.08.3-4
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-18.08]   4:18.08.3-4
ii  libkf5mailtransport5 [libkf5mailtransport5-18.08] 18.08.3-4
ii  

Bug#877802: lintian: Please include file name and line number in output

[Chris Lamb]

Hi Felix,

> Mentioning source files and line numbers, on the other hand, requires
> a retooling in most checks.

Don't worry, I think we are talking about exactly the same thing.

I have a (very old) branch that starts to do this but I'm sure you
will get around to this before me though.

If it helps, my plan was that we call "tag" with many more arguments
which all end up in said metadata, but each tag had a "to_string"
method (or similar) that would render it into the existing flat,
plaintext string... both for the benefit of retaining command-line
conciseness but also for the benefit of existing overrides and to
roll this out over many many releases.

(As you imply, context is important to disambiguate points to filename
and — optionally — line number combinations in a source or binary
package.)


Regards,

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

Bug#946118: synaptics touchpad does not work in debian installer graphical mode

[Samuel Thibault]

Samuel Thibault, le mer. 04 déc. 2019 01:52:36 +0100, a ecrit:
> Thinking of it... IIRC the touchpad is not working on my DELL XPS13
> laptop in g-i.

Indeed, it doesn't work.

> What I can see of it on normal boot of installed system is:
> 
> [6.097298] input: DELL07E6:00 06CB:76AF Mouse as 
> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input12
> [6.097660] input: DELL07E6:00 06CB:76AF Touchpad as 
> /devices/pci:00/:00:15.1/i2c_designware.1/i2c-8/i2c-DELL07E6:00/0018:06CB:76AF.0002/input/input13
> [6.098066] hid-generic 0018:06CB:76AF.0002: input,hidraw1: I2C HID v1.00 
> Mouse [DELL07E6:00 06CB:76AF] on i2c-DELL07E6:00
> 
> and lsmod | grep i2c gives
> 
> i2c_designware_platform16384  0
> i2c_designware_core20480  1 i2c_designware_platform
> i2c_i801   32768  0
> i2c_hid28672  0
> hid   126976  4 i2c_hid,usbhid,hid_multitouch,hid_generic
> 
> I don't see the i2c_designware* modules in the g-i image, perhaps that
> needs to be included for some hardware?

I tried to rmmod i2c_designware_platform on my installed system, the
mouse stopped working, so it seems to be required, at the very least.

I tried to add i2c-modules to a g-i image, i2c_designware_platform
didn't get loaded automatically, and even loading it manually didn't
make the mouse detected.

Samuel

Bug#938986: check-all-the-things: diff for NMU version 2017.05.20+nmu1

[Sandro Tosi]

Control: tags 938986 + patch
Control: tags 938986 + pending
Control: tags 942918 + patch
Control: tags 942918 + pending


Dear maintainer,

I've prepared an NMU for check-all-the-things (versioned as 2017.05.20+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru check-all-the-things-2017.05.20/check-font-embedding-restrictions check-all-the-things-2017.05.20+nmu1/check-font-embedding-restrictions
--- check-all-the-things-2017.05.20/check-font-embedding-restrictions	2017-05-08 21:20:41.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/check-font-embedding-restrictions	2019-11-28 23:15:32.0 -0500
@@ -1,4 +1,4 @@
-#!/usr/bin/python2
+#!/usr/bin/python3
 
 import fontforge
 import deb822
@@ -38,9 +38,9 @@
 os.close(old)
 
 if embedding_restricted:
-print 'These fonts in Debian main/contrib have embedding'
-print 'restrictions, which are not DFSG compatible:'
-print
-print '\n'.join(sorted(embedding_restricted))
-print
-print 'https://www.microsoft.com/typography/otspec/os2.htm#fst'
+print('These fonts in Debian main/contrib have embedding')
+print('restrictions, which are not DFSG compatible:')
+print()
+print('\n'.join(sorted(embedding_restricted)))
+print()
+print('https://www.microsoft.com/typography/otspec/os2.htm#fst')
diff -Nru check-all-the-things-2017.05.20/data/fonts check-all-the-things-2017.05.20+nmu1/data/fonts
--- check-all-the-things-2017.05.20/data/fonts	2017-05-20 05:33:18.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/data/fonts	2019-11-28 23:19:00.0 -0500
@@ -18,7 +18,7 @@
 command = ftlint 16 {files} | grep -v ': OK\.$'
 
 [font-embedding-restrictions]
-apt = python, python-fontforge, python-debian
+apt = python3, python3-fontforge, python3-debian
 files = *.ttf *.otf *.sfd *.pfa *.pfb *.bdf *.pk *.ttc *.pcf
 command = check-font-embedding-restrictions {files}
 
diff -Nru check-all-the-things-2017.05.20/data/jpeg2000 check-all-the-things-2017.05.20+nmu1/data/jpeg2000
--- check-all-the-things-2017.05.20/data/jpeg2000	2017-05-20 05:33:18.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/data/jpeg2000	2019-11-29 01:05:36.0 -0500
@@ -1,6 +1,6 @@
 [jpylyzer]
 flags = images
-apt = python-jpylyzer, libxml2-utils
+apt = python3-jpylyzer, libxml2-utils
 files = *.jp2 *.j2k *.jpf *.jpx *.jpm *.mj2
 types = image/jp2
 command = jpylyzer --wrapper {files} | xmllint --format - | egrep 'fileName|isValid' | tr -d \\n | sed 's__&\n_g;s_ *__g;s_ *__g;s__ _g;s_False_is an invalid JPEG2000 file_g' | sed '/True *$/d'
diff -Nru check-all-the-things-2017.05.20/data/misc check-all-the-things-2017.05.20+nmu1/data/misc
--- check-all-the-things-2017.05.20/data/misc	2017-05-20 05:33:18.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/data/misc	2019-11-29 01:06:28.0 -0500
@@ -5,11 +5,7 @@
 # TODO: is --check=. reasonable?
 
 [suspicious-source]
-# We need:
-#   devscripts (<< 2.13.1~), python-magic
-# or
-#   devscripts (>= 2.13.1~), python3-magic
-apt = devscripts, devscripts (>= 2.13.1~) | python-magic, devscripts (<< 2.13.1~) | python3-magic
+apt = devscripts, devscripts (>= 2.13.1~), python3-magic
 command = suspicious-source
 
 [licensecheck-generated-files]
diff -Nru check-all-the-things-2017.05.20/data/python check-all-the-things-2017.05.20+nmu1/data/python
--- check-all-the-things-2017.05.20/data/python	2017-05-20 05:33:18.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/data/python	2019-11-29 01:07:14.0 -0500
@@ -61,7 +61,7 @@
 
 [pyroma]
 flags = dangerous fixme fixme-silent
-apt = python-pyroma
+apt = python3-pyroma
 files = ./setup.py
 command = pyroma -d .
 
@@ -73,7 +73,7 @@
 
 [python2-bandit]
 flags = fixme fixme-silent
-apt = python-bandit
+apt = python3-bandit
 files = *.py
 types = text/x-python
 command = python2-bandit -r .
diff -Nru check-all-the-things-2017.05.20/data/sh check-all-the-things-2017.05.20+nmu1/data/sh
--- check-all-the-things-2017.05.20/data/sh	2017-05-20 05:33:18.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/data/sh	2019-11-29 01:07:40.0 -0500
@@ -16,7 +16,7 @@
 command = shellcheck {files}
 
 [bashate]
-apt = python3-bashate | python-bashate
+apt = python3-bashate
 files = *.sh *.bash
 types = text/x-shellscript
 command = bashate --ignore E002,E003 {files}
diff -Nru check-all-the-things-2017.05.20/data/text check-all-the-things-2017.05.20+nmu1/data/text
--- check-all-the-things-2017.05.20/data/text	2017-05-20 05:33:18.0 -0400
+++ check-all-the-things-2017.05.20+nmu1/data/text	2019-11-29 01:07:51.0 -0500
@@ -1,12 +1,12 @@
 [rst-lint]
 flags = todo
-apt = python3-restructuredtext-lint | python-restructuredtext-lint
+apt = python3-restructuredtext-lint
 files = *.rst
 comment = rst-lint {files}
 
 [doc8]
 flags = todo
-apt = python3-doc8 | python-doc8
+apt = python3-doc8
 files = *.txt *.text *.rst
 comment = doc8 {files}
 
diff -Nru 

Bug#946364: chiark-scripts: install git-branchmove(1)

[Sean Whitton]

Package: chiark-scripts
Version: 6.1.0

Dear maintainer,

The command

% pod2man scripts/git-branchmove >git-branchmove.1

generates a suitable manpage for git-branchmove, so it would be good for
the package to install it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#930440: Missing file: /etc/containers/policy.json

[Cirujano Cuesta, Silvano]

No default is being provided for the signature verification policy: 
/etc/containers/policy.json

According the Readme (/usr/share/doc/podman/README.Debian) the default should 
be there to be reviewed.

Best,

  Silvano

Bug#936328: [Help] consensuscore: Python2 removal in sid/bullseye

[Andrey Rahmatullin]

On Sat, Dec 07, 2019 at 09:23:16PM +0100, Andreas Tille wrote:
> I tried to port consensuscore to Python3 in Git[1].  Unfortunately 2to3
> was not completely successfully since I get:
This isn't 2to3's fault.

>dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python3.8 setup.py build.
> WARNING: '' not a valid package name; please use only .-separated package 
> names in setup.py
> running build
> Traceback (most recent call last):
>   File "tools/find_boost", line 56, in 
> boost = find_boost()
>   File "tools/find_boost", line 44, in find_boost
> best_boost = max(boosts_found, key=lambda t: t[1])[0]
> TypeError: '>' not supported between instances of 'NoneType' and 'tuple'
Such meaningless comparisons are indeed not supported in Python3. You need
to filter out the items where version is None.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#932543: [Help] Please switch to Python 3

[Andreas Tille]

Control: tags -1 help

Hi,

I upgraded python-pbcommand Git[1] to latest upstream commit which is
work in progress to Python3.  Unfortunately I'm facing some remaining
test suite errors:

...
[gw3] [ 98%] PASSED 
tests/test_validators.py::TestValidators::test_validate_report 
tests/test_validators.py::TestValidators::test_validate_report_fails 
[gw3] [ 99%] PASSED 
tests/test_validators.py::TestValidators::test_validate_report_fails 
[gw0] [100%] FAILED 
tests/test_testkit_xunit.py::TestXunitOutput::test_merge_junit_files_cmdline 

=== FAILURES ===
___ TestMalformedReport.test_bad_01 
[gw0] linux -- Python 3.8.0 /usr/bin/python3.8

self = 

def test_bad_01(self):
r = Report("stuff", uuid=1234)
>   d = r.to_dict()

tests/test_models_report.py:355: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pbcommand/models/report.py:778: in to_dict
_d = dict(v=pbcommand.get_version(),
pbcommand/__init__.py:19: in get_version
return ".".join([str(i) for i in VERSION])
pbcommand/__init__.py:19: in 
return ".".join([str(i) for i in VERSION])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

.0 = 

>   VERSION = (int(x) for x in __VERSION__.split('.'))
E   ValueError: invalid literal for int() with base 10: 'unknown'

pbcommand/__init__.py:9: ValueError
 TestReportModel.test_from_simple_dict _
[gw2] linux -- Python 3.8.0 /usr/bin/python3.8

self = 

def test_from_simple_dict(self):
r = Report.from_simple_dict("pbcommand_test", {"n_reads": 50},
"pbcommand")
>   json_dict = json.loads(r.to_json())

tests/test_models_report.py:34: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
pbcommand/models/report.py:801: in to_json
s = _to_json_with_decoder(self.to_dict())
pbcommand/models/report.py:778: in to_dict
_d = dict(v=pbcommand.get_version(),
pbcommand/__init__.py:19: in get_version
return ".".join([str(i) for i in VERSION])
pbcommand/__init__.py:19: in 
return ".".join([str(i) for i in VERSION])
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

.0 = 

>   VERSION = (int(x) for x in __VERSION__.split('.'))
E   ValueError: invalid literal for int() with base 10: 'unknown'

pbcommand/__init__.py:9: ValueError
 TestXunitOutput.test_merge_junit_files_cmdline 
[gw0] linux -- Python 3.8.0 /usr/bin/python3.8

self = 

def test_merge_junit_files_cmdline(self):
x1, x2 = self._get_junit_files()
x_merged = tempfile.NamedTemporaryFile(suffix=".xml").name
args = ["python3", "-m" "pbcommand.testkit.merge_junit_files",
"-o", x_merged, x1, x2, "--quiet"]
>   assert subprocess.call(args) == 0
E   assert 1 == 0
E -1

E +0

tests/test_testkit_xunit.py:106: AssertionError
- Captured stderr call -
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/testkit/merge_junit_files.py",
 line 43, in 
sys.exit(main())
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/testkit/merge_junit_files.py",
 line 39, in main
setup_log_func=setup_log)
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/cli/core.py",
 line 212, in pacbio_args_runner
dump_alarm_on_error=dump_alarm_on_error)
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/cli/core.py",
 line 160, in _pacbio_main_runner
alog.info("Using pbcommand v{v}".format(v=pbcommand.get_version()))
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/__init__.py",
 line 19, in get_version
return ".".join([str(i) for i in VERSION])
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/__init__.py",
 line 19, in 
return ".".join([str(i) for i in VERSION])
  File 
"/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/pbcommand/__init__.py",
 line 9, in 
VERSION = (int(x) for x in __VERSION__.split('.'))
ValueError: invalid literal for int() with base 10: 'unknown'
- generated xml file: 
/build/python-pbcommand-1.1.1+git20191122.ec024c3/.pybuild/cpython3_3.8_pbcommand/build/nosetests.xml
 -
--- coverage: platform linux, python 3.8.0-final-0 ---
Coverage XML written to file 

Bug#945585: Too many levels of symbolic links" error

[Chris Dos]

Seems I spoke too soon. Looks like I found a different kind of bug related to
this. I've applied the patch listed above. My rpool looks like this:
rpool 1.27T 2.95T 176K none
rpool/ROOT 145G 2.95T 50.1G /
rpool/mysql 53.0G 2.95T 23.0G /var/lib/mysql
rpool/mysql-log 5.79G 2.95T 1.44G /var/lib/mysql-log
rpool/plexmediaserver 206G 2.95T 171G /var/lib/plexmediaserver
rpool/spool 115G 2.95T 35.5G /var/spool
rpool/virtual_machines 778G 2.95T 743G /var/lib/libvirt

I can see inside snapshots for rpool/ROOT:
windwalker:~# ls /.zfs/snapshot/zfs-auto-snap_daily-2019-12-07-1107/
bin boot.tar.xz dead.letter etc lib lost+found mnt opt proc run share sys tmp 
var
boot cdrom dev home lib64 media netshares path root sbin srv tftpboot usr

Looking inside snapshots for any other dataset in rpool results in "Too many
levels of symbolic links" error:
ls /var/lib/libvirt/.zfs/snapshot/zfs-auto-snap_daily-2019-12-07-1107/
ls: cannot access
'/var/lib/libvirt/.zfs/snapshot/zfs-auto-snap_daily-2019-12-07-1107/': Too
many levels of symbolic links

I've updated the ZFS issues ticket.

Chris

Bug#946213: RFS: git-delta/0.0.15 -- Syntax-highlighting pager for git and diff output

[Dan Davison]

>
>
>
> > It builds the following binary package:
> >
> >   delta - A syntax-highlighting pager for git and diff output
>
> That name is already used by an unrelated package.
>

Currently (FreeBSD, Rust Cargo, Arch Linux, Homebrew) the package name is
"git-delta", which installs an executable named "delta". Can it do the same
for Debian?


> > *.deb files for the latest version are at
> > https://github.com/dandavison/delta/releases/tag/0.0.15
>
> We need sources (ie, the .dsc file and stuff referenced from it) rather
> than
> binary artefacts.
>

Is this document what I should be following?
https://wiki.debian.org/SimplePackagingTutorial.

Thanks!

Dan


>
> Without the source, I can't upload nor review anything.  On the other hand,
> a glance at your tool's README seems awesome!
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
> ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
> ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
> ⠈⠳⣄ etc), let the drink age at least 3-6 months.
>

Bug#944866: limnoria 2017.01.10-1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 944866 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: limnoria
Version: 2017.01.10-1+deb9u1

Explanation: fix remote information disclosure and possibly remote code 
execution in the Math plugin [CVE-2019-19010]

Bug#946159: libxslt 1.1.29-2.1+deb9u2 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946159 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: libxslt
Version: 1.1.29-2.1+deb9u2

Explanation: fix dangling pointer in xsltCopyText [CVE-2019-18197]

Bug#946363: reportbug can't identify the package of a bug specified with -N when the bug is files against a source package

[Sven Bartscher]

Package: reportbug
Version: 7.5.3
Severity: normal

Greetings

I recently tried to submit an additional report for the bug #939875
which is filed against src:linux, but apparently reportbug struggles
to identify src:linux as a proper package name:

$ reportbug --pgp --email 'kritzef...@debian.org' -N 939875  
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: UTF-8
Please change your locale if this is incorrect.

Using 'Sven Bartscher ' as your from address.
Retrieving report #939875 from Debian bug tracking system...
What do you want to do now? [N|x|o|r|b|e|q|?]? x
Getting status for src:linux...
W: Paket src:linux kann nicht gefunden werden.
No matching source or binary packages.
A package named "src:linux" does not appear to be installed; do you want to 
search for a similar-looking filename in
an installed package [Y|n|q|?]?


reportbug still allows me to send the followup, if I press N:


A package named "src:linux" does not appear to be installed; do you want to 
search for a similar-looking filename in
an installed package [Y|n|q|?]? n
Getting available info for src:linux...
Will send report to Debian (per lsb_release).

Please provide a subject for your response.
[Re: linux-image-5.2.0-2-amd64: Suspend fails. Machine shuts down after approx 
30 seconds]> 

Enter any additional addresses this report should be sent to; press ENTER after 
each address. Press ENTER on a blank
line to continue.
> 

Spawning emacsclient...
Waiting for Emacs...


At this point the report template looks like this (delimiters inserted
by me):


START OF TEMPLATE
Subject: Re: linux-image-5.2.0-2-amd64: Suspend fails. Machine shuts down after 
approx 30 seconds
Followup-For: Bug #939875
Package: src:linux



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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
END OF TEMPLATE


This looks like it only gathered the generic system information, even
though reports for src:linux usually gather a lot more information.

Regards
Sven

-- Package-specific info:
** Environment settings:
EDITOR="emacsclient -t"
PAGER="less -R"
VISUAL="emacsclient -c"
DEBEMAIL="sven.bartsc...@credativ.de"
DEBFULLNAME="Sven Bartscher"
INTERFACE="text"

** /home/sven/.reportbugrc:
reportbug_version "7.1.7"
mode expert
ui text
smtphost "mail.credativ.com"
smtpuser "sba"
smtptls

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt1.8.4
ii  python33.7.5-1
ii  python3-reportbug  7.5.3
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail  
ii  debconf-utils   1.5.73
ii  debsums 2.2.4
ii  dlocate 1.07+nmu1
ii  emacs-bin-common1:26.1+1-4
ii  file1:5.37-6
ii  gnupg   2.2.17-3
ii  postfix [mail-transport-agent]  3.4.7-2
pn  python3-urwid   
pn  reportbug-gtk   
ii  xdg-utils   1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.4
ii  file   1:5.37-6
ii  python33.7.5-1
ii  python3-apt1.8.4+b1
ii  python3-debian 0.1.36
ii  python3-debianbts  2.8.2
ii  python3-requests   2.21.0-1
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#558404: Spaces in sources.list.d filenames also don't work

[Andrew Bobulsky]

Hi,

I got bit by this same issue 10 years later.

The files in sources.list.d cannot have spaces in their names for this
same underlying reason.

This took a lot of time to figure out because this restriction doesn't
appear to be mentioned in the doc.

Regards,
Andrew

Bug#877802: lintian: Please include file name and line number in output

[Felix Lechner]

Hi Chris,

On Sat, Dec 7, 2019 at 12:43 PM Chris Lamb  wrote:
>
> (FYI there's a wishlist bug somewhere requesting machine-readable
> output in a format such as JSON/Yaml/etc. where the fields are
> consistent and named reliably)

>From my perspective it is a different, although perhaps more helpful
item. Machine readable output is coming soon. I need it for something
too.

Mentioning source files and line numbers, on the other hand, requires
a retooling in most checks. I may provide the infrastructure, but
getting that information consistently right is challenging, especially
in checks looking at installation (deb) packages.

Kind regards,
Felix Lechner

Bug#946326: python3-reportbug: reportbug runs bugscript in "C" locale

[Nis Martensen]

On 07 Dec 2019 Changwoo Ryu wrote:
> 
> reportbug seems to run bugscript in "C" locale. In /usr/lib/python3/dist-
> packages/reportbug/utils.py:
> 
> rc = runner('LC_ALL=C %s %s %s' % (handler, pipes.quote(bugscript),
> pipes.quote(filename)))
> 
> 
> It prevents the ibus bugscript from getting "locale" command result. For
> example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946201#5
> 
> I understand that running locale dependent bugscript can be often buggy and
> confusing, but some bugscripts want the locale dependent behavior. I think
> settings locale settings should be up to the individual bugscript authors.

When programs called by bugscripts provide output in the user's locale,
this can make the information unintelligible to the debian maintainer.
Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546276
for why the "LC_ALL=C" was introduced ten years ago. I am not sure that
reverting this is a good idea. It should probably be documented in
README.developers, so bugscript authors are aware of it.

Note that reportbug already includes the most important locale
information in all bug reports by default. In your example, it is this
line in the "System Information" section of the report:
  Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

Bug#945590: reportbug: Cannot copy missing gtk+ package from window to command line

[Nis Martensen]

On 27 Nov 2019 Attila Rajmund Nohl wrote:
> when I start reportbug without the gir1.2-vte-2.91 package on my system, I get
> a dialog that this package is missing and cannot use the GTK+ interface.
> However, I cannot copy the package nem from the dialog to a shell to an
> "apt-get install" command - it would be easier if I could do that instead of
> typing the longish package name.

Please install the reportbug-gtk package. It will make sure that all
packages required by the GTK+ interface are installed.

Bug#946362: luakit: LuaKit does not connect to any website, webkit window remains unpainted

[nyov]

Package: luakit
Version: 1:2.1-1
Severity: important

Dear Maintainer,

I have (only just) noticed that I can no longer use luakit, as it
appears to not function any longer.
I have made sure to try without any pre-existing configuration, a
clean reinstall, and my observation has been seconded by someone else
on IRC.

luakit terminal output:

> $ luakit
> [0.089561] I [core/luah]: Loading rc: /etc/xdg/luakit/rc.lua
> [0.108781] I [lua/adblock]: found 0 filter lists
> [0.122010] I [lua/styles]: found 0 user stylesheets
> [0.123216] I [core/web_context]: Web process count: 4
> 
> ** (luakit:6276): WARNING **: 20:07:34.813: 
> webkit_web_context_set_web_process_count_limit is deprecated and does 
> nothing. Limiting the number of web processes is no longer possible for 
> security reasons

The luakit main window is white/grey. The lua interface works fine.
Trying to open any website does not result in change, a tcpdump on the
interface does not see any outgoing traffic attempt.

I assume this is a webkit API issue.


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

Kernel: Linux 4.9.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages luakit depends on:
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgtk-3-0  3.24.5-1
ii  libjavascriptcoregtk-4.0-18 2.26.2-1~deb10+1
ii  libluajit-5.1-2 2.1.0~beta3+dfsg-5.1
ii  libpango-1.0-0  1.42.4-7~deb10u1
ii  libsoup2.4-12.64.2-2
ii  libsqlite3-03.27.2-3
ii  libwebkit2gtk-4.0-372.26.2-1~deb10+1
ii  lua-filesystem [lua5.1-filesystem]  1.6.3-1

luakit recommends no packages.

luakit suggests no packages.

-- no debconf information

Bug#877802: lintian: Please include file name and line number in output

[Chris Lamb]

Hi Jelmer et al.,

> That said, I think it would be great to have this feature in lintian -
> easily being able to jump to the relevant line in an editor would be
> very useful.

(FYI there's a wishlist bug somewhere requesting machine-readable
output in a format such as JSON/Yaml/etc. where the fields are
consistent and named reliably)


Regards,

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

Bug#944794: dpdk 16.11.11-1+deb9u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 944794 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: dpdk
Version: 16.11.11-1+deb9u1

Explanation: new upstream stable release; fix vhost regression introduced by 
the fix for CVE-2019-14818

Bug#945518: dpdk 18.11.5-1~deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 945518 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: dpdk
Version: 18.11.5-1~deb10u1

Explanation: new upstream stable release

Bug#944865: limnoria 2019.02.23-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 944865 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: limnoria
Version: 2019.02.23-1+deb10u1

Explanation: fix remote information disclosure and possibly remote code 
execution in the Math plugin [CVE-2019-19010]

Bug#946361: at-spi2-core: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: at-spi2-core
Version: 2.34.0-3
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The at-spi2-core tests currently fail in this environment, because they have
a dependency on gedit, which tries to pull in the i386 version of gedit
instead of the amd64 version and this is not cross-installable.  However it
doesn't appear that there is anything in the test case that requires gedit
to be of the same architecture (at-spi2-core communicates with gedit over a
bus, not in process memory), so we should fix the test so that the amd64
version of gedit can be used.

One way to do this would be a multiarch annotation on the gedit package
itself.  It would not be correct to mark gedit Multi-Arch: foreign, because
there are reverse-dependencies of gedit that are plugins; so gedit would at
most be Multi-Arch: allowed.  However, in that case at-spi2-core would still
need to change in that case to specify a test dep on gedit:any instead of
gedit; so it's simpler to just change at-spi2-core to depend on gedit:native
as in the attached patch.

Support for cross-testing in autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru at-spi2-core-2.34.0/debian/tests/control 
at-spi2-core-2.34.0/debian/tests/control
--- at-spi2-core-2.34.0/debian/tests/control2019-09-29 05:38:10.0 
-0700
+++ at-spi2-core-2.34.0/debian/tests/control2019-12-07 12:21:52.0 
-0800
@@ -1,2 +1,2 @@
 Tests: gedit dbind
-Depends: libatspi2.0-dev, build-essential, xauth, xvfb, dbus, at-spi2-core, 
gedit
+Depends: libatspi2.0-dev, build-essential, xauth, xvfb, dbus, at-spi2-core, 
gedit:native

Bug#946178: mercurial: FTBFS on hurd-i386: Testsuite failures

[Samuel Thibault]

Hello,

Paul Sonnenschein, le jeu. 05 déc. 2019 07:43:10 +0100, a ecrit:
> Am Mittwoch, den 04.12.2019, 23:26 +0100 schrieb Samuel Thibault:
> > Paul Sonnenschein, le mer. 04 déc. 2019 21:45:14 +0100, a ecrit:
> > > The test-http-bad-server.t fails due to an unexpected behaviour of
> > > local sockets in the Hurd. This seems to be a bug in the Hurd
> > > itself
> > > (pflocal specifically), being in violation of the POSIX
> > > specification
> > > Issue 6 and newer.
> > 
> > Which violation is happening here?
> 
> According to POSIX, both read and recv shall set errno to ECONNRESET if
> "[a] read was attempted on a socket and the connection was forcibly
> closed by its peer." As far as I can tell, pflocal will never return
> ECONNRESET.

Yes. The question is what "forcibly" means. On TCP connections, when the
peer sends a RST, ECONNRESET makes complete sense: the stream is not
finished, it was really interrupted. What would be the equivalent for a
local socket?

I played a bit with Linux, and found the attached case to be returning
ECONNRESET, but it's not clear to me why that precise case should do
this. In such case OpenBSD returns 0.

Samuel
#include 
#include 
#include 

int main(void) {
	int sv[2];
	char buf[128];

	socketpair(PF_LOCAL, SOCK_STREAM, 0, sv);
	if (fork()) {
		close(sv[1]);
		sleep(1);
		int ret = read(sv[0], buf, sizeof(buf));
		if (ret < 0)
			perror("read");
		else
			printf("got %d bytes\n", ret);
	} else {
		write(sv[0], buf, sizeof(buf));
	}
	return 0;
}

Bug#936508: fdb: Python2 removal in sid/bullseye

[Scott Kitterman]

On Fri, 30 Aug 2019 07:16:59 + Matthias Klose  wrote:
> Package: src:fdb
> Version: 2.0.0-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
...

Technically this is blocked by #938555, but it's only a Suggests relationship, 
so I would think it's OK to go ahead to drop the python-fdb binary.  If you 
are busy and would prefer someone else handle it, please let me know and I'll 
be glad to do an NMU.

Scott K

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

Bug#944233: stretch-pu: package glib2.0/2.50.3-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed d-i

On Mon, 2019-12-02 at 15:24 +, Simon McVittie wrote:
> On Wed, 06 Nov 2019 at 13:01:41 +, Simon McVittie wrote:
> > A recent security fix to ibus (CVE-2019-14822, #940267, DSA-4525-1)
> > exposed an interoperability bug between GLib's implementation of D-
> > Bus
> > and the reference implementation libdbus (#941018). The practical
> > impact
> > is that Qt clients cannot use the updated ibus input method until
> > GLib
> > is fixed.
> > 
> > This is the same as #944133, but for the older GLib in stretch.
> 
> I've uploaded the proposed source package for your consideration.
> Please let me know if anything needs to be reverted or changed.

Sorry for the delay. This looks OK to me, but will need a d-i ack as
ever.

Regards,

Adam

Bug#946360: yeroth-erp-alert-3-0: Missing yeroth-erp-alert-3-0

[Xavier NOUMBISSI NOUNDOU, Ph.D. (ABD)]

Package: yeroth-erp-alert-3-0
Version: 3.0
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
I develop this software myself for 4 years now.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
This is the alert system of the free enterprise resource
planing software 'YEROTH-ERP-3.0-1'
(https://github.com/xnoumbissinoundou/yeroth-erp-3.0).

   * What was the outcome of this action?
Have this free software as standard program within Debian stable
(https://github.com/xnoumbissinoundou/yeroth-erp-alert-3.0)

   * What outcome did you expect instead?
Have a Debian mentor

Xavier NOUMBISSI NOUNDOU, Ph.D. (ABD), Waterloo, ON, 2011



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

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

Versions of packages yeroth-erp-alert-3-0 depends on:
ii  default-mysql-client  1.0.5
ii  libqt5sql55.11.3+dfsg1-1
ii  libqt5sql5-mysql  5.11.3+dfsg1-1
ii  xvfb  2:1.20.4-1

yeroth-erp-alert-3-0 recommends no packages.

yeroth-erp-alert-3-0 suggests no packages.

-- no debconf information

Bug#877802: lintian: Please include file name and line number in output

[Jelmer Vernooij]

Hi Felix,

On Sat, Dec 07, 2019 at 06:03:15AM -0800, Felix Lechner wrote:
> Would more reporting detail, as outlined in this bug, be useful to
> lintian-brush or to D-Janitor?
Not directly, I think the lintian-info field in the lintian output is
more useful for the janitor.

That said, I think it would be great to have this feature in lintian -
easily being able to jump to the relevant line in an editor would be
very useful.

Jelmer

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


signature.asc
Description: PGP signature

Bug#936328: [Help] consensuscore: Python2 removal in sid/bullseye

[Andreas Tille]

Control: tags -1 help

Hi,

I tried to port consensuscore to Python3 in Git[1].  Unfortunately 2to3
was not completely successfully since I get:


   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3.8 setup.py build.
WARNING: '' not a valid package name; please use only .-separated package names 
in setup.py
running build
Traceback (most recent call last):
  File "tools/find_boost", line 56, in 
boost = find_boost()
  File "tools/find_boost", line 44, in find_boost
best_boost = max(boosts_found, key=lambda t: t[1])[0]
TypeError: '>' not supported between instances of 'NoneType' and 'tuple'
error: Failed to configure ConsensusCore build
E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3.8 setup.py build.


Any hint how to fix this?

Kind regards

Andreas.


[1] https://salsa.debian.org/med-team/consensuscore

-- 
http://fam-tille.de

Bug#941365: buster-pu: package libimobiledevice/1.2.1~git20181030.92c5462-2

[Adam D. Barratt]

On Fri, 2019-11-22 at 17:32 +0100, Yves-Alexis Perez wrote:
> On Fri, 2019-11-08 at 21:55 +0100, Yves-Alexis Perez wrote:
> > On Fri, 2019-11-08 at 20:53 +, Adam D. Barratt wrote:
> > > Sorry for the delay in getting back to you.
> > 
> > Yeah, this time it's me who's really sorry.
> > > That sounds OK, but it looks like the fix still hasn't made it to
> > > sid,
> > > so I'm tagging this as moreinfo for now. Please remove the tag
> > > and
> > > confirm the final debdiff once that's sorted.
> > 
> > Indeed, I'm still waiting on upstream to actually chose the way
> > they bump
> > the
> > soname… I still don't have any answer on 
> > https://github.com/libimobiledevice/libusbmuxd/issues/81
> > 
> > I'll keep you posted as soon as possible.
> 
> Sorry, I replied to the wrong bug. I'll upload the isolated fix soon,
> likely this weekend, thanks.

Just to keep this up-to-date, the libimobiledevice upload made it to
sid, but is blocked by python3-plist needing to make it out of NEW.

Regards,

Adam

Bug#946359: pg-snakeoil: Selftest apears to be broken

[Sebastian Andrzej Siewior]

Package: pg-snakeoil
Version: 1.2-1
Severity: imporant

Hi,

clamav can't migrate because the debci-test for pg-snakeoil fails. I
*think* that the test itself is somehow borken since after installing
the bytecode.cvd itself appears on my system. Could you please take a
look?

However. The complete database (/var/lib/clamav/) contains today 454MiB.
I don't know what your self-test but using

| clamav$ cat unit_tests/input/clamav.hdb
| aa15bcf478d165efd2065190eb473bcb:544:ClamAV-Test-File

as a databse will find the un-offical test file:

|$ clamscan -d clamav.hdb split.clam.exe
|split.clam.exe: ClamAV-Test-File.UNOFFICIAL FOUND

and the testfile is 

| cat ./test/.split/split.clam.exeaa ./test/.split/split.clam.exeab  > 
split.clam.exe

Wouldn't that be enough?

Sebastian

Bug#944348: schleuder 3.4.0-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 944348 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: schleuder
Version: 3.4.0-2+deb10u1

Explanation: fix recognizing keywords in mails with "protected headers" and 
empty subject; strip non-self-signatures when refreshing or fetching keys; 
error if the argument provided to `refresh_keys` is not an existing list

Bug#946175: uif 1.1.9-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 946175 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: uif
Version: 1.1.9-1+deb10u1

Explanation: fix paths to ip(6)tables-restore in light of the migration to 
nftables

Bug#946358: gulkan: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: gulkan
Severity: important
Version: 0.13.2-1
X-Debbugs-CC: zu...@debian.org ajq...@debian.org

Dear gulkan maintainers,

Your package gulkan was uploaded with non-source-only uploads. Since July
2019, all uploads have to be source-only to be able to migrate to Testing.
Please make another source-only upload to fix this problem.

You may find more information about source-only uploads at 
https://wiki.debian.org/SourceOnlyUpload . Please let me know if you have more
questions.

-- 
Best,
Boyuan Yang


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

Bug#946357: libjson-perl: Please mark libjson-perl Multi-Arch: foreign (needed for mysql cross-testing)

[Steve Langasek]

Package: libjson-perl
Version: 4.02000-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires some changes to the archive so that test dependencies are
cross-installable in a multiarch fashion.  The mysql-8.0 package has a test
dependency on mysql-testsuite-8.0, which depends on libjson-perl. 
libjson-perl is an Arch: all package, so could reasonably satisfy this
dependency for a foreign-arch reverse-dep such as mysql-testsuite-8.0, but
this needs to be explicitly declared by making the package Multi-Arch:
foreign.

There is precedent for this, a handful of other perl modules already are
tagged Multi-Arch: foreign in the archive (libdpkg-perl, libdebhelper-perl,
liberror-perl, ...).

I've uploaded the attached patch to Ubuntu, in the hopes of making mysql-8.0
cross-testable.  Please consider applying in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libjson-perl-4.02000/debian/control 
libjson-perl-4.02000/debian/control
--- libjson-perl-4.02000/debian/control 2019-02-24 06:56:57.0 -0800
+++ libjson-perl-4.02000/debian/control 2019-12-07 11:48:36.0 -0800
@@ -19,6 +19,7 @@
 
 Package: libjson-perl
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${perl:Depends}
 Recommends: libjson-xs-perl (>= 2.340)

Bug#941713: ntpsec 1.1.3+dfsg1-2+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 941713 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: ntpsec
Version: 1.1.3+dfsg1-2+deb10u1

Explanation: fix slow DNS retries; fix ntpdate -s (syslog) to fix the if-up 
hook; documentation fixes

Bug#940647: libmysofa 0.6~dfsg0-3+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 940647 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: libmysofa
Version: 0.6~dfsg0-3+deb10u1

Explanation: security fixes [CVE-2019-16091 CVE-2019-16092 CVE-2019-16093 
CVE-2019-16094 CVE-2019-16095]

Bug#945965: bgpdump 1.6.0-1+deb10u1 flagged for acceptance

[Adam D Barratt]

package release.debian.org
tags 945965 = buster pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian buster.

Thanks for your contribution!

Upload details
==

Package: bgpdump
Version: 1.6.0-1+deb10u1

Explanation: fix segmentation fault

Bug#946356: joe: fails to display some modern Unicode characters

[Adam Borowski]

Package: joe
Version: 4.6-1+b1
Severity: normal

Hi!
Georgian Mtavruli characters display as <1C90>, despite having been added
to Unicode in version 11 (June 2018).  Joe has a tool to regenerate its
character properties table from UnicodeData, but this needs to be invoked
by hand.

Thus, please run uniproc against unicode-data 12 (released March 2019, plus
reiwa in May 2019) -- which will unbreak all such characters.


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

Kernel: Linux 5.4.1-00189-g495895f855ae (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages joe depends on:
ii  libc62.29-3
ii  libncurses6  6.1+20191019-1
ii  libtinfo66.1+20191019-1

joe recommends no packages.

joe suggests no packages.

-- no debconf information

Bug#946355: glib2.0: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: glib2.0
Version: 2.63.1-2
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Dear maintainers,

In Ubuntu, we are in the process of moving the i386 architecture to a
compatibility-only layer on amd64, and therefore we are also moving our
autopkgtest infrastructure to test i386 binaries in a cross-environment.

This requires changes to some tests so that they are cross-aware and can do
the right thing.

The glib2.0 tests currently fail in this environment, because there are
build tests that do not invoke the toolchain in a cross-aware manner.  I've
verified that the attached patch lets the tests successfully build (and run)
i386 tests on an amd64 host.

Note that upstream autopkgtest doesn't currently set DEB_HOST_ARCH so this
is a complete no-op in Debian for the moment.  Support for cross-testing in
autopkgtest is currently awaiting review at
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/69 and once
landed, will still have no effect unless autopkgtest is invoked with a '-a'
option.  So this change should be safe to land in your package despite this
not being upstream in autopkgtest.

Unfortunately in the case of glib2.0, this is an incomplete solution for
cross-testing compatibility, because in addition to the build tests, glib2.0
has two other tests that depend on libglib2.0-tests and this package is not
cross-installable because dh-python causes it to have a dependency on
python3:any but on python3.7, and it's impossible to install the
foreign-arch (i386) version of python3.7.  There is discussion on the
autopkgtest MP about how to filter out some tests when cross-testing, which
may wind up being a solution, but I think this is also a bug in dh-python
that it generates a dependency on same-arch python3.7, so I think this patch
is worth inclusion in glib2.0 as-is.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru glib2.0-2.63.1/debian/tests/build glib2.0-2.63.1/debian/tests/build
--- glib2.0-2.63.1/debian/tests/build   2019-11-18 05:59:35.0 -0800
+++ glib2.0-2.63.1/debian/tests/build   2019-12-06 21:31:37.0 -0800
@@ -34,6 +34,13 @@
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
 cd $WORKDIR
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cat < glib.c
 #include 
 
@@ -119,7 +126,7 @@
 ;;
 esac
 
-gcc $cflags -o ${lib}-$mode ${lib}.c `pkg-config $pcflags --cflags --libs 
${packages}`
+${CROSS_COMPILE}gcc $cflags -o ${lib}-$mode ${lib}.c 
`${CROSS_COMPILE}pkg-config $pcflags --cflags --libs ${packages}`
 echo "build ($lib, $mode): OK"
 [ -x ${lib}-$mode ]
 foo=bar ./${lib}-$mode

Bug#944856: buster-pu: package qtbase-opensource-src/5.11.3+dfsg1-1+deb10u2

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sat, 2019-11-23 at 18:42 +0100, Julien Cristau wrote:
> Control: tag -1 confirmed
> 
> On Sat, Nov 16, 2019 at 04:06:59PM +0300, Dmitry Shachnev wrote:
> > I would like to update qtbase-opensource-src in Buster, to fix the
> > following
> > bugs:
> > 
> > #911702 — okular does not print to network printer
> > #911844 — okular prints to the wrong printer
> > #935909 — segfault when removing rich content (like tables) from
> > QLabel
> > #935627 — graphics tablet hover events (tooltips/mouse-over) broken
> > 
> > The fix for the first two bugs has already been ACKed during the
> > freeze in #930669, but the fix did not reach bullseye because it
> > was built against gcc-8 from sid.
> > 
> > All these bugs are already fixed in sid/bullseye.
> > 
> > The debdiff against the current version in buster (which was a
> > security upload) is attached.
> > 
> Looks OK to me, thanks.

Hmmm. Is the BTS metadata for #935627 accurate? The final entry in the
log is currently a "pending" tag from August, but no bug closure, and
the fix doesn't appear to be mentioned in the current git changelog.

Regards,

Adam

Bug#717818: Implemented for multiple image formats, except .ICO

[Felix Lechner]

Hi Helmut,

> Please issue a message for each file, that has PNG contents, but is not
> named *.png or *.PNG.

A new check covers several image formats and names:


https://salsa.debian.org/lintian/lintian/commit/12b81f00021fc7ded44388125e763a179bbd794e

> The tag should likely be pedantic

There are two tags. The standard one is pedantic.

> maybe some extensions such as .ico, .gif, .jpg, .jpeg, .pbm
> .tiff, .xpm could raise the tag to something normal

This is where the second tag comes in. Image files whose names suggest
another format are misleading. They are tagged at the slightly higher
severity wishlist. It works across all formats, not just PNG.

I did not implement .ICO because it is, or has evolved into, a
container format that can also contain PNG images.

Kind regards
Felix Lechner

Bug#946197: Let's switch to OpenRC?

[Dmitry Bogatov]

control: tags -1 +wontfix

[2019-12-05 10:32] Thomas Goirand 
> Source: sysvinit
> Severity: normal
>
> Dear sysvinit maintainers,
>
> OpenRC is actively maintained upstream, and is a full replacement of sysv-rc,
> including many improvements.
>
> Currently, packages are stuck with long, non-declarative sysv-rc scripts, and
> cannot switch to superior runscripts, interpreted by /sbin/openrc-run, which
> enable declarative-only scripts.
>
> So, my proposal is to get rid of sysv-rc provided by sysvinit, in the favor of
> OpenRC, so that developers can start replacing their init scripts by superior
> runscripts.

Personally, I like openrc more that sysv-rc, but as was already pointed,
sysv-rc already here and works, while pushing support for another init
system into ~1300 packages is hard.

And if current General Resolution will favor systemd-only vision of
Debian future, then it will become plainly impossible.

Tagging as wontfix.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#946354: linux-image-4.19.0-6-amd64: Filesystem access gets stuck when LVM snapshot creation interrupted

[Sven Strickroth]

Package: src:linux
Version: 4.19.67-2+deb10u2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I'm using LVM snapshots for creating consistent backups of ext4 filesystems.
Since a few months I'm experiencing severe problems causing the whole system
to get stuck. First I thought this was a hardware issue, but I found some
ways to reproduce this or a similar issue (even on a different system in a VM).

Steps to reproduce this issue:
Have a LVM set up with one LV (test, size: 2G) formatted with ext4 and
mounted. Do some work on the mounted FS (e.g., using fio) and create a
snapshot while the FS is busy using

lvcreate --snapshot -p r -L 1G --name snap /dev/vg/test

and issue Ctrl+C immediately before the command finishes. Now the system
will get into a broken state (this is especially a problem if you snapshot
/var): All further writes to the mounted LV will be stalled forever as well
as LVM commands such as pvdisplay and lvs.

After a few minutes the are the following errors logged in the kernel ring
buffer:
[  605.032827] INFO: task pvdisplay:878 blocked for more than 120 seconds.
[  605.032926]   Not tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2
[  605.033000] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  605.033088] pvdisplay   D0   878543 0x8004
[  605.033094] Call Trace:
[  605.033113]  ? __schedule+0x2a2/0x870
[  605.033119]  ? _cond_resched+0x15/0x30
[  605.033124]  schedule+0x28/0x80
[  605.033130]  schedule_timeout+0x26d/0x390
[  605.033139]  ? __kfifo_from_user_r+0xb0/0xb0
[  605.033144]  ? __percpu_ref_switch_mode+0xd4/0x180
[  605.033149]  wait_for_completion+0x11f/0x190
[  605.033159]  ? wake_up_q+0x70/0x70
[  605.033166]  exit_aio+0xdc/0xe3
[  605.033177]  mmput+0x28/0x130
[  605.033183]  do_exit+0x290/0xb90
[  605.033190]  ? __switch_to_asm+0x41/0x70
[  605.033195]  ? __switch_to_asm+0x41/0x70
[  605.033200]  ? __switch_to_asm+0x35/0x70
[  605.033204]  ? __switch_to_asm+0x41/0x70
[  605.033209]  ? __switch_to+0x115/0x440
[  605.033214]  ? __switch_to_asm+0x41/0x70
[  605.033219]  do_group_exit+0x3a/0xa0
[  605.033226]  get_signal+0x137/0x790
[  605.033231]  do_signal+0x36/0x6c0
[  605.033239]  ? finish_wait+0x80/0x80
[  605.033246]  ? __hrtimer_init+0xb0/0xb0
[  605.033250]  ? do_io_getevents+0x7c/0xc0
[  605.033260]  exit_to_usermode_loop+0x89/0xf0
[  605.033266]  do_syscall_64+0x10d/0x110
[  605.033272]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  605.033278] RIP: 0033:0x7f2ad18a9f59
[  605.033290] Code: Bad RIP value.
[  605.033293] RSP: 002b:7ffca85d4628 EFLAGS: 0246 ORIG_RAX: 
00d0
[  605.033298] RAX: fffc RBX: 7f2ad154a700 RCX: 7f2ad18a9f59
[  605.033299] RDX: 0040 RSI: 0001 RDI: 7f2ad1255000
[  605.033301] RBP: 7f2ad1255000 R08:  R09: 0002a85d46b0
[  605.033303] R10: 7ffca85d46b0 R11: 0246 R12: 0001
[  605.033305] R13:  R14: 0040 R15: 7ffca85d46b0
[  605.033314] INFO: task fio:1010 blocked for more than 120 seconds.
[  605.033385]   Not tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2
[  605.033458] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  605.033542] fio D0  1010   1006 0x
[  605.033546] Call Trace:
[  605.033553]  ? __schedule+0x2a2/0x870
[  605.033558]  schedule+0x28/0x80
[  605.033564]  rwsem_down_read_failed+0x111/0x180
[  605.033572]  ? kmem_cache_alloc_trace+0x155/0x1d0
[  605.033581]  call_rwsem_down_read_failed+0x14/0x30
[  605.033587]  __percpu_down_read+0x4f/0x80
[  605.033596]  __sb_start_write+0x5f/0x70
[  605.033603]  mnt_want_write+0x20/0x50
[  605.033609]  path_openat+0xc88/0x1480
[  605.033616]  ? alloc_set_pte+0xf2/0x560
[  605.033624]  ? filemap_map_pages+0x360/0x3a0
[  605.033629]  do_filp_open+0x93/0x100
[  605.033635]  ? __handle_mm_fault+0x1090/0x1270
[  605.033641]  ? __check_object_size+0x15d/0x189
[  605.033647]  do_sys_open+0x186/0x210
[  605.033655]  do_syscall_64+0x53/0x110
[  605.033661]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  605.033664] RIP: 0033:0x7f06d6ea4d0e
[  605.033669] Code: Bad RIP value.
[  605.033671] RSP: 002b:7ffdb6c3df30 EFLAGS: 0293 ORIG_RAX: 
0101
[  605.033675] RAX: ffda RBX: 7f06ca1e9510 RCX: 7f06d6ea4d0e
[  605.033677] RDX: 4042 RSI: 7f06ca1e9690 RDI: ff9c
[  605.033678] RBP:  R08:  R09: 560c2b42dc20
[  605.033680] R10: 0180 R11: 0293 R12: 4042
[  605.033682] R13: 4042 R14: 7f06a9c1d000 R15: 
[  725.866073] INFO: task pvdisplay:878 blocked for more than 120 seconds.
[  725.866161]   Not tainted 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2
[  725.866235] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[  725.866321] pvdisplay   D

Bug#946292: at-spi2-atk: please make autopkgtests cross-test-friendly

[Steve Langasek]

On Sat, Dec 07, 2019 at 06:07:58PM +0100, Samuel Thibault wrote:
> Hello,

> Steve Langasek, le ven. 06 déc. 2019 10:20:22 -0800, a ecrit:
> >  cd $WORKDIR
> > -meson $SRCDIR 2>&1
> > +if [ -n "$DEB_HOST_MULTIARCH" ]; then
> > +export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
> > +cross_file=cross_file.txt
> > +cat > $cross_file < > +[binaries]
> > +c = '/usr/bin/$DEB_HOST_GNU_TYPE-gcc'
> > +cpp = '/usr/bin/$DEB_HOST_GNU_TYPE-g++'
> > +ar = '/usr/bin/$DEB_HOST_GNU_TYPE-ar'
> > +strip = '/usr/bin/$DEB_HOST_GNU_TYPE-strip'
> > +EOF

> Would it be possible to tell meson to similarly change pkgconfig calls
> to /usr/bin/$DEB_HOST_GNU_TYPE-pkg-config?

If that's supported by meson, then yes, that should also work.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#946353: tran: Conflict for [ა] in mtavruli>latin, it resolves to [a] and [a]

[Jakub Wilk]

Package: tran
Version: 4-1
Severity: grave

tran no longer works in unstable:

  $ echo foo | tran
  Conflict for [ა] in mtavruli>latin, it resolves to [a] and [a]


-- System Information:
Architecture: i386

--
Jakub Wilk

Bug#945592: buster-pu: package openstack-dashboard-apache/3:14.0.2-3

[Adam D. Barratt]

Control: tags -1 + moreinfo
Control: retitle -1 buster-pu: package horizon/3:14.0.2-3

On Wed, 2019-11-27 at 15:57 +0100, Michal Arbet wrote:
> Openstack-dashboard-apache package is used to configure apache2 to
> provide openstack-dashboard (horizon) and also configure openstack-
> dashboard's webroot.
> 
> As upstream moved WEBROOT variable from local_settings.py to
> defaults.py, it has to been overriden in /etc/openstack-
> dashboard/local_settings.d and openstack-dashboard-apache
> has to configure this variable and rebuild static files if needed.
> 
> This is now achieved by openstack-dashboard-apache which is calling
> trigger of openstack-dashboard when needed.

When did that change happen? Has the package been broken since before
the release?

So far as I can tell, the way this change is managed is not policy
compliant. /etc/openstack-dashboard/local_settings.d/* are conffiles
shipped by the package, which are then modified by the postinst script,
overwriting any local administrator changes.

As a side note, this:

+   CURRENT_WEBROOT=$(cat ${OS_WEBROOT_CONF_PATH}  | grep ^WEBROOT 
| sed -e 's/"*'\''*\ *//g' | awk -F '=' '{print $2}')

is a rather convoluted construction, for what appears to be equivalent
to

CURRENT_WEBROOT=$(sed -re "s/^WEBROOT *= *\"?([^\"]*)\"?$/\1/" 
${OS_WEBROOT_CONF_PATH})

(and also inconsistent with the later change, which allows either
spaces or tabs. In fact, given that the intent seems to be just to
check if the current value is equivalent to the proposed one, replacing
that and the subsequent test with

if grep -Eq "^WEBROOT\s*=\s*\"?${WEBROOT}\"?$" ${OS_WEBROOT_CONF_PATH}; then

would seem to suffice.)

Regards,

Adam

Bug#940975: jQuery may not need two different packages

[Xavier]

Hi,

I prepared node-jquery 3.4.1. Do you think it's time to add
Breaks/Provides/Replaces libjs-jquery ?

Cheers,
Xavier

Bug#946352: gcc-9-cross-mipsen_2+c1+b1_i386.changes REJECTED

[Aurelien Jarno]

Source: gcc-9-cross-mipsen
Version: 2+c1

On 2019-12-07 17:37, Debian FTP Masters wrote:
> 
> cpp-9-mips-linux-gnu_9.2.1-21cross1_i386.deb: trying to install to unstable, 
> but could not find source (gcc-9-cross-mipsen 2+c1+b1)
> 
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 

Looks like gcc-9-cross-mipsen is not binNMUable. It should be fixed or
at the very least needs a new source upload for the libisl22 transition.

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

Bug#946351: RM: dans-gdal-scripts -- ROM; Dead upstream

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove dans-gdal-scripts from the archive, it's dead upstream and won't 
work correctly with GDAL 3.

Kind Regards,

Bas

Bug#946350: RM: tofu -- RoQA; dead upstream, dead name, python2

[Dimitri John Ledkov]

Package: ftp.debian.org
Severity: normal

tofu is orphaned for 3903 days.

tofu is an abandoned upstream project with all URLs not serving any
content.

tofu name in pypi has long got taken over by a different project.

tofu is written in obsolete python2 language.

tofu has no reverse (build) dependencies, and only a recommends from a
meta-package.

Please remove tofu from unstable & testing.

Regards,

Dimitri.

Bug#944417: transition: cgal

[Joachim Reichel]

Hi Paul,

could you please trigger another binNMU for gudhi on mips64el? There was a
problem in CGAL that I fixed in 5.0-5.

Thanks,
  Joachim

Bug#946158: lightdm-gtk-greeter or libcairo2 segfault immediately after submitting password, unlocking session

[dinar qurbanov]

yes, i386. i will write this in other bug reports. md5sums match, at
least first and last 4 characters of them... i checked partition with
badblocks -v /dev/sda6 and no error was found. ok, i have, just now,
installed systemd-coredump.

Bug#946349: backintime-qt: Backup initiated from the GUI overwrites remote backup path permissions to 0700

[Sven Geuer]

Package: backintime-qt
Version: 1.2.1-2
Severity: important
Tags: upstream

Dear Maintainer,

backing up to a ssh-mounted remote path forces the remote paths access
permissions to 0700 when initiating the backup from the GUI.

How to reproduce:

- start up backintime-qt
- set up a configuration to back up a directory to a ssh-mounted remote
directory
- check the access permissions of the remote directory (normally 0755)
- trigger a backup
- check the access permissions of the remote directory, now they are set to
0700.

It‘s also reproducible with an existing configuration:

- make sure the remote directory's permissions are different than 0700, for
example 0750.
- start up backintime-qt
- trigger a backup
- check the access permissions of the remote directory, now they are set to
0700.


I did some code analysis and this is what I believe causes the bug:

 When being started up backintime-qt ssh-mounts the remote path calling
MountControl.mount() in /usr/share/backintime/common/mount.py from package
backintime-common.

MountControl.mount() forces the mount point‘s permissions to 0700 (see details
below).

When the actual mount happens the mount point‘s permissions gets substituted by
the remote path‘s permissions.

While the remote path still is mounted MountControl.mount() is called again
when starting a backup.

With both calls MountControl.mount() calls Mount.createMountStructure().

Mount.createMountStructure() always calls tool.mkdir(self.currentMountpoint,
0o700) in /usr/share/backintime/common/tools.py.

Function mkdir(path, mode) does a chmod to the given or a default mode if the
given path already exist!

So, when MountControl.mount() is called with an already mounted remote path,
the remote path‘s permissions get‘s replaced!


Expectation:

Backintime should never alter the remote path‘s permissions as they may be
crafted for a specific purpose.



Please forward this issue to upstream.

There are two issues at upstream not tracked down yet, which seem to refer to
the same flaw:

https://github.com/bit-team/backintime/issues/954
https://github.com/bit-team/backintime/issues/974

Regards,
Sven



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

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

Versions of packages backintime-qt depends on:
ii  backintime-common1.2.1-2
ii  libnotify-bin0.7.8-1
ii  policykit-1  0.105-26
ii  python3  3.7.5-1
ii  python3-dbus.mainloop.pyqt5  5.12.3+dfsg-3+b1
ii  python3-pyqt55.12.3+dfsg-3+b1
ii  x11-utils7.7+4

Versions of packages backintime-qt recommends:
ii  python3-secretstorage  2.3.1-2

Versions of packages backintime-qt suggests:
pn  meld | kompare  

-- no debconf information

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31

[Colin Watson]

On Sat, Dec 07, 2019 at 04:52:19PM +0100, Bernhard Übelacker wrote:
> I could reproduce the issue in a i386 qemu VM with
> a downgraded 3.16-3-686-pae kernel.
> Attached file contains a debug session.
> 
> At the sysenter instruction in function shmdt
> the signal SIGSYS is received.

Since you're building it locally already, it would be helpful if you
could follow the debugging instructions in a comment near the top of
sandbox-seccomp-filter.c (either the auditctl approach, or if that
doesn't work on such an old kernel, the ""uncomment this macro"
approach).

-- 
Colin Watson   [cjwat...@debian.org]

Bug#946292: at-spi2-atk: please make autopkgtests cross-test-friendly

[Samuel Thibault]

Hello,

Steve Langasek, le ven. 06 déc. 2019 10:20:22 -0800, a ecrit:
>  cd $WORKDIR
> -meson $SRCDIR 2>&1
> +if [ -n "$DEB_HOST_MULTIARCH" ]; then
> +export PKG_CONFIG_PATH="/usr/lib/$DEB_HOST_MULTIARCH/pkgconfig"
> +cross_file=cross_file.txt
> +cat > $cross_file < +[binaries]
> +c = '/usr/bin/$DEB_HOST_GNU_TYPE-gcc'
> +cpp = '/usr/bin/$DEB_HOST_GNU_TYPE-g++'
> +ar = '/usr/bin/$DEB_HOST_GNU_TYPE-ar'
> +strip = '/usr/bin/$DEB_HOST_GNU_TYPE-strip'
> +EOF

Would it be possible to tell meson to similarly change pkgconfig calls
to /usr/bin/$DEB_HOST_GNU_TYPE-pkg-config?

Samuel

Bug#941440: wxMaxima Pandoc problem

[John Scott]

wxMaxima FTBFS's for me with
$ pdf-engine /usr/bin/xelatex not known

I see that the 19.10.0 Debian package builds now by skipping the PDF manual 
when it can't be built. I think I've found the root of the problem with 
Pandoc.

It turns out this is a regression that's been there for ages and fixed in 
Pandoc 2.2.2 [1], just shy of the 2.2.1 version in Buster. wxMaxima doesn't 
build-dep on Pandoc and I'm building in a non-clean environment, but perhaps 
the following check done by CMake should be made aware of the Pandoc bug in 
the upstream part of wxMaxima by bumping the version:
-- pandoc version >= 2 found - using option --pdf-engine

https://github.com/jgm/pandoc/issues/4681#issuecomment-403617849



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

Bug#946141: [akonadi-backend-sqlite] Failed to commit transaction for database update

[alexs]

Start-Date: 2019-12-02 09:29:50 Commandline: /usr/bin/unattended-upgrade
Upgrade: akonadi-backend-sqlite:amd64 (4:18.08.3-11, 4:19.08.3-1)
End-Date: 2019-12-02 09:29:52



$ LANG=C akonadictl start org.kde.pim.akonadictl: Starting Akonadi
Server... qt.qpa.xcb: Has MIT-SHM : true qt.qpa.xcb: Has MIT-SHM FD :
true qt.qpa.xcb: Using XInput version 2.2 qt.qpa.screen: Output
DisplayPort-0 is not connected qt.qpa.screen: EDID data for output
"HDMI-A-0": identifier '', manufacturer 'Philips Consumer Electronics
Company',model 'PHL 276E8V-', serial '245', physical size: 600.00x340.00
qt.qpa.screen: Output DVI-D-0 is not connected qt.qpa.screen: adding
QXcbScreen(0x5587963346c0, name="HDMI-A-0", geometry=2560x1440+0+0,
availableGeometry=2560x1380+0+0, devicePixelRatio=1.0,
logicalDpi=QPair(134.0,134.0), physicalSize=597.0x336.0mm,
screenNumber=0, virtualSize=2560x1440 (2560.0x1440.0mm),
orientation=Qt::LandscapeOrientation, depth=24, refreshRate=59.0,
root=6cd, windowManagerName="KWin") (Primary: true ) qt.qpa.screen:
primary output is "HDMI-A-0" qt.qpa.input.devices: input device Virtual
core XTEST pointer ID 4 qt.qpa.input.devices: has 10 buttons
qt.qpa.input.devices: has valuator "Rel X" recognized? true
qt.qpa.input.devices: has valuator "Rel Y" recognized? true
qt.qpa.input.devices: it's a scrolling device qt.qpa.input.devices:
input device USB USB Keyboard Consumer Control ID 9
qt.qpa.input.devices: has 7 buttons qt.qpa.input.devices: has valuator
"Rel X" recognized? true qt.qpa.input.devices: has valuator "Rel Y"
recognized? true qt.qpa.input.devices: has valuator "Rel Horiz Scroll"
recognized? true qt.qpa.input.devices: has valuator "Rel Vert Scroll"
recognized? true qt.qpa.input.devices: it's a scrolling device
qt.qpa.input.devices: input device Logitech USB Optical Mouse ID 11
qt.qpa.input.devices: has 7 buttons qt.qpa.input.devices: has valuator
"Rel X" recognized? true qt.qpa.input.devices: has valuator "Rel Y"
recognized? true qt.qpa.input.devices: has valuator "Rel Horiz Scroll"
recognized? true qt.qpa.input.devices: has valuator "Rel Vert Scroll"
recognized? true qt.qpa.input.devices: it's a scrolling device
qt.qpa.input.devices: input device lircd-uinput ID 12
qt.qpa.input.devices: has 20 buttons qt.qpa.input.devices: has valuator
"Rel X" recognized? true qt.qpa.input.devices: has valuator "Rel Y"
recognized? true qt.qpa.input.devices: has valuator "Rel Horiz Scroll"
recognized? true qt.qpa.input.devices: has valuator "Rel Vert Scroll"
recognized? true qt.qpa.input.devices: it's a scrolling device
qt.qpa.xcb: using glib dispatcher org.kde.pim.akonadictl: done.
Connecting to deprecated signal
QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
alexs@alexs:~/.config/QtProject$ qt.qpa.events: Event |
XCB_PROPERTY_NOTIFY(28) | sequence: 193 qt.qpa.events: Event |
XCB_PROPERTY_NOTIFY(28) | sequence: 194 org.kde.pim.akonadiserver:
Starting up the Akonadi Server... QSqlDatabasePrivate::addDatabase:
duplicate connection name 'initConnection', old connection removed.
org.kde.pim.akonadiserver: sqlite version is "3.30.1"
org.kde.pim.akonadiserver: sqlite journal mode is "wal"
org.kde.pim.akonadiprivate: StandardDirs::saveDir: failed to create
directory ' "/run/user/1000/akonadi" ' QDir::mkpath: Empty or null file
name org.kde.pim.akonadiserver: Creating socket directory with name ""
failed: Success org.kde.pim.akonadiserver: Could not create socket
directory for Akonadi. org.kde.pim.akonadiserver: Database
"/home/alexs/.local/share/akonadi/akonadi.db" opened using driver
"QSQLITE3" org.kde.pim.akonadiserver: Running DB initializer
org.kde.pim.akonadiserver: checking table "SchemaVersionTable"
org.kde.pim.akonadiserver: checking table "ResourceTable"
org.kde.pim.akonadiserver: checking table "CollectionTable"
org.kde.pim.akonadiserver: checking table "MimeTypeTable"
org.kde.pim.akonadiserver: checking table "PimItemTable"
org.kde.pim.akonadiserver: checking table "FlagTable"
org.kde.pim.akonadiserver: checking table "PartTypeTable"
org.kde.pim.akonadiserver: checking table "PartTable"
org.kde.pim.akonadiserver: checking table "CollectionAttributeTable"
org.kde.pim.akonadiserver: checking table "TagTypeTable"
org.kde.pim.akonadiserver: checking table "TagTable"
org.kde.pim.akonadiserver: checking table "TagAttributeTable"
org.kde.pim.akonadiserver: checking table
"TagRemoteIdResourceRelationTable" org.kde.pim.akonadiserver: checking
table "RelationTypeTable" org.kde.pim.akonadiserver: checking table
"RelationTable" org.kde.pim.akonadiserver: checking table
"PimItemFlagRelation" org.kde.pim.akonadiserver: checking table
"PimItemTagRelation" org.kde.pim.akonadiserver: checking table
"CollectionMimeTypeRelation" org.kde.pim.akonadiserver: checking table
"CollectionPimItemRelation" org.kde.pim.akonadiserver: DB initializer
done org.kde.pim.akonadiserver: skipping update 2
org.kde.pim.akonadiserver: skipping update 3 org.kde.pim.akonadiserver:
skipping update 4 org.kde.pim.akonadiserver: 

Bug#946348: openvpn openvpn-plugin-auth-pam.so moved to new file location, breaks config

[Stefan]

Package: openvpn
Version: 2.4.7-1
Severity: normal
Tags: newcomer

Dear Maintainer,

After upgrading from stretch to buster the file openvpn-plugin-auth-pam.so 
moved to a new location in 
/usr/lib/arm-linux-gnueabihf/openvpn/plugins/ . This breaks 
/etc/openvpn/server.conf, where this file is referenced with
/usr/lib/openvpn/.

Solved by creating a symlink and service restart: 

ln -s /usr/lib/arm-linux-gnueabihf/openvpn/plugins/openvpn-plugin-auth-pam.so 
/usr/lib/openvpn/.
systemctl restart openvpn



-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.19.75-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2
ii  libc6  2.28-10
ii  liblz4-1   1.8.3-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.3.1-5+rpt1
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1d-0+deb10u2
ii  libsystemd0241-7~deb10u2
ii  lsb-base   10.2019051400

Versions of packages openvpn recommends:
pn  easy-rsa  

Versions of packages openvpn suggests:
ii  openssl   1.1.1d-0+deb10u2
pn  openvpn-systemd-resolved  
ii  resolvconf1.79

-- debconf information excluded

Bug#946158: lightdm-gtk-greeter or libcairo2 segfault immediately after submitting password, unlocking session

[Bernhard Übelacker]

Hello dinar qurbanov,
I am guessing you are using Buster/stable i386?
If reportbug would be used for reporting bugs, such
information gets added automatically to the report.

Then the "Code" in the syslog the crash most probably
happened in _cairo_surface_set_error [1].

Unfortunately I doubt that information is enough for the
maintainer to fix this issue.

If it would be possible to install systemd-coredump,
then a backtrace for each crashing app would be added
to the journal, that could be of help.

And I cannot judge if this could be due to bad sectors on
your disk, therefore at least below the md5sums [2] of the files
I got installed. Maybe you want to lookup smartctl, if your
disk recorded itself some errors.

Kind regards,
Bernhard


[1] https://sources.debian.org/src/cairo/1.16.0-4/src/cairo-surface.c/#L201

[2]
# md5sum /usr/lib/i386-linux-gnu/libcairo.so.2.11600.0
273f0014984b9f43abbed04cd9e0bc0c  /usr/lib/i386-linux-gnu/libcairo.so.2.11600.0
# md5sum /usr/sbin/lightdm-gtk-greeter
dbfa2151ff036c85f4659358d7a5f392  /usr/sbin/lightdm-gtk-greeter

# from submitter:
Dec  4 14:28:08 localhost kernel: [ 5707.165413] lightdm-gtk-gre[9162]: 
segfault at 8 ip b73a92e4 sp bfa6f59c error 4 in 
libcairo.so.2.11600.0[b733d000+dd000]
Dec  4 14:28:08 localhost kernel: [ 5707.165431] Code: 51 14 89 54 24 04 e9 1b 
e5 fa ff 8d 76 00 31 c0 c3 8d 74 26 00 90 89 d0 c3 8d b4 26 00 00 00 00 8d b6 
00 00 00 00 8b 44 24 04 <8b> 40 08 c3 8d b4 26 00 00 00 00 90 8b 44 24 04 8b 40 
0c c3 8d b4


###

Buster/stable i386 qemu VM 2019-12-07

apt update
apt dist-ugprade


apt install mc gdb lightdm-gtk-greeter lightdm-gtk-greeter-dbgsym 
libcairo2-dbgsym


gdb -q --args lightdm-gtk-greeter

set width 0
set pagination off
b main
run

info share

0xb73f26a0  0xb74cd724  Yes /usr/lib/i386-linux-gnu/libcairo.so.2

find /b 0xb73f26a0, 0xb74cd724, 0x51, 0x14, 0x89, 0x54, 0x24, 0x04, 0xe9, 0x1b, 
0xe5, 0xfa, 0xff, 0x8d, 0x76, 0x00, 0x31, 0xc0, 0xc3, 0x8d, 0x74, 0x26, 0x00, 
0x90, 0x89, 0xd0, 0xc3, 0x8d, 0xb4, 0x26, 0x00, 0x00, 0x00, 0x00, 0x8d, 0xb6, 
0x00, 0x00, 0x00, 0x00, 0x8b, 0x44, 0x24, 0x04, 0x8b, 0x40, 0x08, 0xc3, 0x8d, 
0xb4, 0x26, 0x00, 0x00, 0x00, 0x00, 0x90, 0x8b, 0x44, 0x24, 0x04, 0x8b, 0x40, 
0x0c, 0xc3, 0x8d, 0xb4

0xb745d2ba <_cairo_surface_tag+4294956810>
1 pattern found.


(gdb) disassemble 0xb745d2a0,0xb745d2ba+20
Dump of assembler code from 0xb745d2a0 to 0xb745d2ce:
   0xb745d2a0 <_cairo_surface_set_error+0>: mov0x8(%esp),%edx
   0xb745d2a4 <_cairo_surface_set_error+4>: mov0x4(%esp),%ecx
   0xb745d2a8 <_cairo_surface_set_error+8>: cmp$0x66,%edx
   0xb745d2ab <_cairo_surface_set_error+11>:je 0xb745d2c8 
<_cairo_surface_set_error+40>
   0xb745d2ad <_cairo_surface_set_error+13>:lea-0x1(%edx),%eax
   0xb745d2b0 <_cairo_surface_set_error+16>:cmp$0x29,%eax
   0xb745d2b3 <_cairo_surface_set_error+19>:ja 0xb745d2d0 
<_cairo_surface_set_error+48>
   0xb745d2b5 <_cairo_surface_tag+-10491>:  xor%eax,%eax
   0xb745d2b7 <_cairo_surface_tag+-10489>:  lock cmpxchg %edx,0x14(%ecx)
   0xb745d2bc <_cairo_surface_set_error+28>:mov%edx,0x4(%esp)
   0xb745d2c0 <_cairo_surface_set_error+32>:jmp0xb740b7e0 <_cairo_error>
   0xb745d2c5 <_cairo_surface_set_error+37>:lea0x0(%esi),%esi
   0xb745d2c8 <_cairo_surface_set_error+40>:xor%eax,%eax
   0xb745d2ca <_cairo_surface_set_error+42>:ret
   0xb745d2cb <_cairo_surface_set_error+43>:lea0x0(%esi,%eiz,1),%esi
End of assembler dump.

(gdb) b *0xb745d2bc
Breakpoint 3 at 0xb745d2bc: file ../../../../src/cairo-surface.c, line 201.


(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0xb745d2ba in _cairo_atomic_int_cmpxchg_impl at 
../../../../src/cairo-atomic-private.h:118
3   breakpoint keep y   0xb745d2bc in _cairo_surface_set_error at 
../../../../src/cairo-surface.c:201


https://sources.debian.org/src/cairo/1.16.0-4/src/cairo-surface.c/#L201

Bug#946249: firefox 71 breaks most addons because of local storage errors

[Paride Legovini]

On Fri, 06 Dec 2019 13:54:04 +0100 Diederik de Haas
 wrote:
> Control: severity -1 important
> Control: forwarded -1 https://bugzilla.mozilla.org/show_bug.cgi?id=1601365
> 
> I increased the severity to important as it seems (almost) all extensions are 
> broken. Privacybadger made explicit that there was an error, but other may 
> fail silently. I don't see an error with uBlock Origin f.e., but one of the 
> bug reports did say it that that extension was affected as well.
> 
> I think one can make the case to raise the severity even further, to RC, as 
> extensions which (significantly) increase my privacy and one can also say 
> security (by blocking a lot of crap from websites).
> But I'll leave that decision to the maintainer(s).

I'm not 100% sure it's related to this issue, but with the upgrade to
version 71.0-1 firefox is unable to contact any website: after entering
a URL it just keeps waiting forever. Even locally hosted pages are
inaccessible (e.g. cups at localhost:631). Disabling the uBlock origin
add-on solves the issue. I have uBlock installed from the
webext-ublock-origin Debian  package (version 1.22.2+dfsg-1). I didn't
try installing the add-on from addons.mozilla.org.

Paride

Bug#912749: tmpfiles.d/speech-dispatcher.conf: warnings: Line references path below legacy directory /var/run/...

[Christian Göttsche]

Control: tags -1 patch

/var/run is deprecated, see
https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy

---
 debian/README.Debian  |  2 +-
 debian/patches/systemd-debian |  4 ++--
 debian/rules  |  2 +-
 debian/speech-dispatcher.init |  2 +-
 debian/speech-dispatcher.postinst |  6 +++---
 debian/speech-dispatcher.postrm   |  2 +-
 debian/speech-dispatcher.tmpfile  | 10 +-
 7 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/debian/README.Debian b/debian/README.Debian
index 8aa4fcf..4b8b9be 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -43,7 +43,7 @@ Dispatcher processes.

 If you want to run Speech Dispatcher as a system wide process, set RUN option
 in /etc/default/speech-dispatcher to `yes', and set the
SPEECHD_SOCKET environment
-variable to /var/run/speech-dispatcher/speechd.sock before starting clients.
+variable to /run/speech-dispatcher/speechd.sock before starting clients.

 * Log file permissions

diff --git a/debian/patches/systemd-debian b/debian/patches/systemd-debian
index 144bd76..304bde9 100644
--- a/debian/patches/systemd-debian
+++ b/debian/patches/systemd-debian
@@ -10,8 +10,8 @@
  Type=forking
 -ExecStart=@bindir@/speech-dispatcher -d
 +User=speech-dispatcher
-+PIDFile=/var/run/speech-dispatcher/speech-dispatcher.pid
-+ExecStart=@bindir@/speech-dispatcher -d --pid-file
/var/run/speech-dispatcher/speech-dispatcher.pid
++PIDFile=/run/speech-dispatcher/speech-dispatcher.pid
++ExecStart=@bindir@/speech-dispatcher -d --pid-file
/run/speech-dispatcher/speech-dispatcher.pid
  ExecReload=/bin/kill -HUP $MAINPID

  [Install]
diff --git a/debian/rules b/debian/rules
index ee0727a..9664bc7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -17,7 +17,7 @@ override_dh_auto_configure:
 sed < config/modules/$$i.in > config/modules/$$i -e
"s/\$$DEB_HOST_MULTIARCH/$(DEB_HOST_MULTIARCH)/" ; \
 done
 dh_auto_configure --
--with-module-bindir=\$${prefix}/lib/speech-dispatcher-modules \
- pidpath=/var/run/speech-dispatcher/ $(NAS)
+ pidpath=/run/speech-dispatcher/ $(NAS)

 override_dh_auto_install:
 dh_auto_install --destdir=debian/tmp
diff --git a/debian/speech-dispatcher.init b/debian/speech-dispatcher.init
index 2529727..2a2306b 100644
--- a/debian/speech-dispatcher.init
+++ b/debian/speech-dispatcher.init
@@ -14,7 +14,7 @@

 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/bin/speech-dispatcher
-PIDFILE=/var/run/speech-dispatcher/speech-dispatcher.pid
+PIDFILE=/run/speech-dispatcher/speech-dispatcher.pid
 NAME=speech-dispatcher
 DESC='Speech Dispatcher'
 USER=speech-dispatcher
diff --git a/debian/speech-dispatcher.postinst
b/debian/speech-dispatcher.postinst
index aa09513..b70f398 100644
--- a/debian/speech-dispatcher.postinst
+++ b/debian/speech-dispatcher.postinst
@@ -2,7 +2,7 @@
 set -e

 USER_NAME=speech-dispatcher
-HOME_DIR=/var/run/speech-dispatcher
+HOME_DIR=/run/speech-dispatcher

 if ! id -u $USER_NAME >/dev/null 2>&1; then
   adduser --quiet --system --ingroup audio \
@@ -10,8 +10,8 @@ if ! id -u $USER_NAME >/dev/null 2>&1; then
   --shell /bin/false --disabled-login  \
   --gecos 'Speech Dispatcher' $USER_NAME
 elif ! test -d $HOME_DIR; then
-  if test -d /var/run/speechd; then
-mv /var/run/speechd $HOME_DIR
+  if test -d /run/speechd; then
+mv /run/speechd $HOME_DIR
   else
 mkdir $HOME_DIR
   fi
diff --git a/debian/speech-dispatcher.postrm b/debian/speech-dispatcher.postrm
index 495d909..ffae30f 100644
--- a/debian/speech-dispatcher.postrm
+++ b/debian/speech-dispatcher.postrm
@@ -9,7 +9,7 @@ if test "$1" = "remove"; then
   if id -u $USER_NAME >/dev/null 2>&1; then
 deluser --quiet $USER_NAME
   fi
-  rm -rf /var/run/speech-dispatcher
+  rm -rf /run/speech-dispatcher
 fi

 if test "$1" = "purge"; then
diff --git a/debian/speech-dispatcher.tmpfile b/debian/speech-dispatcher.tmpfile
index c08af80..6c7f499 100644
--- a/debian/speech-dispatcher.tmpfile
+++ b/debian/speech-dispatcher.tmpfile
@@ -1,5 +1,5 @@
-d /var/run/speech-dispatcher0750 speech-dispatcher audio -
-d /var/run/speech-dispatcher/.cache0750 speech-dispatcher audio -
-L /var/run/speech-dispatcher/.speech-dispatcher-
speech-dispatcher audio - /var/run/speech-dispatcher
-L /var/run/speech-dispatcher/.cache/speech-dispatcher-
speech-dispatcher audio - /var/run/speech-dispatcher
-L /var/run/speech-dispatcher/log-speech-dispatcher
audio - /var/log/speech-dispatcher
+d /run/speech-dispatcher0750 speech-dispatcher audio -
+d /run/speech-dispatcher/.cache0750 speech-dispatcher audio -
+L /run/speech-dispatcher/.speech-dispatcher-
speech-dispatcher audio - /run/speech-dispatcher
+L /run/speech-dispatcher/.cache/speech-dispatcher-
speech-dispatcher audio - /run/speech-dispatcher
+L /run/speech-dispatcher/log-speech-dispatcher

Bug#944257: [External] Bug#944257: Confirmed, possible duplicate

[Mark Pearson]

Hi Daniel,

I'll ask internally if we have one of these - I don't have one myself. It's 
supposed to be a certified system so hopefully our team has one and can look at 
what is happening. 
If you're able to track down when the issue was introduced let me know.

Actually - if you get a chance post something on the Lenovo linux forum too 
(https://forums.lenovo.com/t5/Linux-Operating-Systems/ct-p/lx_en) - it just 
helps it get a bit of extra visibility

Thx
Mark



> -Original Message-
> From: Daniel M. 
> Sent: Saturday, December 7, 2019 9:39 AM
> To: 944...@bugs.debian.org
> Subject: [External] Bug#944257: Confirmed, possible duplicate
> 
> Hi,
> 
> I have exactly the same behavior on my lenovo E460 laptop. No suspend
> and shutdown working since upgrade to linux 5.x.
> 
> I don't know how to get more attention to this. Can we raise the
> severity or flag it?
> 
> Some more info in my earlier report #939170. Maybe even duplicate?
> 
> Cheers,
> Daniel

Bug#944867: ntpdate -d -q

[Oleg Broytman]

The output of ntpdate -d -q ru.pool.ntp.org:

 7 Dec 19:08:04 ntpdate[18566]: ntpdate 4.2.8p12@1.3728-o (1)
Looking for host ru.pool.ntp.org and service ntp
host found : 188.44.104.135
transmit(188.44.104.135)
receive(188.44.104.135)
transmit(89.221.207.113)
receive(89.221.207.113)
transmit(195.112.113.253)
receive(195.112.113.253)
transmit(89.109.251.23)
receive(89.109.251.23)

server 188.44.104.135, port 123
stratum 2, precision -24, leap 00, trust 000
refid [89.109.251.24], root delay 0.058853, root dispersion 0.036026
transmitted 1, in filter 1
reference time:e1964739.db2bb732  Sat, Dec  7 2019 18:43:53.856
originate timestamp: e1964bcc.8e43322e  Sat, Dec  7 2019 19:03:24.555
transmit timestamp:  e1964ce4.c9b0b07b  Sat, Dec  7 2019 19:08:04.787
delay 0.07706, dispersion 0.0
offset -280.258032

server 89.221.207.113, port 123
stratum 2, precision -20, leap 00, trust 000
refid [192.36.143.151], root delay 0.013077, root dispersion 0.035568
transmitted 1, in filter 1
reference time:e196499c.0ae07cf1  Sat, Dec  7 2019 18:54:04.042
originate timestamp: e1964bcc.bd1ac24b  Sat, Dec  7 2019 19:03:24.738
transmit timestamp:  e1964ce4.fcd0e99b  Sat, Dec  7 2019 19:08:04.987
delay 0.04192, dispersion 0.0
offset -280.257222

server 195.112.113.253, port 123
stratum 1, precision -23, leap 00, trust 000
refid [GPS], root delay 0.00, root dispersion 0.001038
transmitted 1, in filter 1
reference time:e1964bc9.4608d8e2  Sat, Dec  7 2019 19:03:21.273
originate timestamp: e1964bcc.eec55e97  Sat, Dec  7 2019 19:03:24.932
transmit timestamp:  e1964ce5.300cac2d  Sat, Dec  7 2019 19:08:05.187
delay 0.03308, dispersion 0.0
offset -280.258742

server 89.109.251.23, port 123
stratum 1, precision -18, leap 00, trust 000
refid [MRS], root delay 0.00, root dispersion 0.000122
transmitted 1, in filter 1
reference time:e1964bcd.0965648d  Sat, Dec  7 2019 19:03:25.036
originate timestamp: e1964bcd.21d33031  Sat, Dec  7 2019 19:03:25.132
transmit timestamp:  e1964ce5.633a3aa8  Sat, Dec  7 2019 19:08:05.387
delay 0.03116, dispersion 0.0
offset -280.258582

 7 Dec 19:08:05 ntpdate[18566]: step time server 89.109.251.23 offset 
-280.258582 sec

AFAIU adjtimex.c expects "filter offset:" and there is no "filter
offset:" in the output.

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.