Bug#940906: make autopkgtest working

[Graham Inggs]

Control: severity -1 serious

Hi Carsten

On Sun, 8 Dec 2019 at 13:15, Carsten Schoenert  wrote:
> Any objections on this issue?
> This report is now opened for almost 3 months and prevents me from
> building the KiCad packages for backports, thats a bit unfortunate.

This bug is RC, feel free to prepare an NMU.
Even better, join Debian Science and team upload. :-)

Regards
Graham

Bug#946504: plplot: please force a lower optimization level on ppc64el

[Gianfranco Costamagna]

Source: plplot
Version: 5.15.0+dfsg-9
Severity: normal

Hello, looks like gcc compiler has some sort of bug (but the bug might be in 
the code), that makes the testsuite during build segfault if a -O3 is provided 
by the compiler.

This isn't a big deal for Debian users, because their gcc optimization level on 
ppc64el is -O2, but an user might have
a different level while rebulding it, so I think it might be worth forcing a 
lower value or fixing the bug.

"Patch" is following:

--- plplot-5.15.0+dfsg/debian/rules 2019-11-30 19:16:24.0 +0100
+++ plplot-5.15.0+dfsg/debian/rules 2019-12-10 00:02:22.0 +0100
@@ -8,7 +8,12 @@
 
 DEB_BUILD_MAINT_OPTIONS   := hardening=+all
 DPKG_EXPORT_BUILDFLAGS:= 1
+ifeq ($(DEB_HOST_ARCH), ppc64el)
+DEB_CFLAGS_MAINT_APPEND   := -fvisibility=hidden -O2
+else
 DEB_CFLAGS_MAINT_APPEND   := -fvisibility=hidden
+endif
+
 DEB_FFLAGS_MAINT_APPEND   := -fvisibility=hidden
 # Don't add -fvisibility=hidden to CXXFLAGS for now as this breaks the
 # octave bindings.


There are probably better ways to inject that flag...

if you want to have an example of a failure:
https://launchpad.net/ubuntu/+source/plplot/5.15.0+dfsg-8/+build/18212633

thanks for having a look

Gianfranco

Bug#946463: sysdig: specific filter produces "BUG: unable to handle kernel NULL pointer dereference at..."

[Vincas Dargis]

I've tried simple filter "evt.res=ENOACCESS", and it crashed once I've
started `cat` and hit "ctrl+c" on it. Crash on signal?

I fail to get valid kern.log entries during these crashes with my
local machine or virtual box, only that original server crash saved
normal kern.log lines with some crash info...

Bug#946475: Patch is merged upstream

[Anthony Bourguignon]

Hi,

The patch has been merged upstream :
  
https://github.com/systemd/systemd/commit/dd1b315d22148fd82b936c25fe155684654431c9

Thanks a lot for your work

Bug#939552: libvirt: New upstream version (5.10)

[Jonathan Rubenstein]

Control: retitle -1 libvirt: New upstream version (5.10)

Libvirt has since released 5.10 on December 2nd.

https://www.libvirt.org/news.html#v5.10.0

Bug#946347: Thunderbird: After dist-upgrade thunderbird thinks it is too old.

[Robert Pommrich]

Hello Carsten,

Please be so kind to carefully and completely, before you make wild assumptions.

I didn't use a pre-built version before, instead I used the packaged version as 
stated in my initial message. 

A very similar problem is described in

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

for Firefox.

Please read this bug report, hopefully you can draw some knowledge from that.

I assume, that the buster versions are build before the stretch versions which 
makes the stretch versions being a little bit higher.

Thank you for your efforts. 

Best regards,
Robert

PS: Unfortunately, the provided link didn't help me much.



 Original Message 
From: Carsten Schoenert 
Sent: 9 December 2019 22:09:01 CET
To: Robert Pommrich 
Cc: 946...@bugs.debian.org
Subject: Re: Bug#946347: Thunderbird: After dist-upgrade thunderbird thinks it 
is too old.

Control: severity -1 normal

Hello Robert,

On Sat, Dec 07, 2019 at 05:25:22PM +0100, Robert Pommrich wrote:
> After a dist-upgrade from stretch to buster with thunderbird installed
> in version 68.2.2-1~deb9u1 and being upgraded to version
> 68.2.2-1~deb10u1 thunderbird shows a message at the start:
> 
> "A newer version of Thunderbird may have made changes to your profile which 
> are no longer
> compatible with this older version.
> Use this profile only with that newer version, or create a new profile for 
> this installation of
> Thunderbird. Creating a new profile requires setting up your accounts, 
> calendars and add-ond again."
> 
> This is strange and should not happen, as the version of Thunderbird
> is practically the same.

this usaly happen if users have used some pre-built version from
Mozilla. Seeing this message isn't something you can blame the
Thunderbird package from Debian as you have used non packaged software
on your own.

https://support.mozilla.org/en-US/kb/unable-launch-older-version-profile

Please adjust your local profile settings by reading the ressource I've
linked above.

Regards
Carsten

Bug#946400: plplot: please build the Ada binding with gnat-9

[Rafael Laboissière]

Thanks for your detailed reply, Nicolas.

I must admit that my knowledge of ADA is almost inexistant.  I even do 
not knew what ALI means, until I looked at the documentation.


I do not have time to plunge deeper into this issue now.  I have already 
committed all the patches that you submitted in the presetn bug report 
[1–8]. I will make a new release to unstable containing this changes, 
because I think that they improve the Debian packaging.


I will then apply the patch that changes libplplotada1 ⇒ 2 and upload the 
new version to experimental, as you suggested.


Best,

Rafael

[1] https://salsa.debian.org/science-team/plplot/commit/8e1f9be7 Improve 
transmission of configuration variables
[2] https://salsa.debian.org/science-team/plplot/commit/b23103c8 Compile Ada 
with hardening flags
[3] https://salsa.debian.org/science-team/plplot/commit/1cec9ebc Enable all 
linker checks
[4] https://salsa.debian.org/science-team/plplot/commit/bd0d7e5c Import 
specific dpkg makefile snippets instead of default.mk
[5] https://salsa.debian.org/science-team/plplot/commit/27a1a2b0 Drop HOME 
unused variable from debian/rules
[6] https://salsa.debian.org/science-team/plplot/commit/f93b7cb6 Remove the 
workaround preventing compression of examples
[7] https://salsa.debian.org/science-team/plplot/commit/410c23ab Delegate 
temporary directory to autopkgtests
[8] https://salsa.debian.org/science-team/plplot/commit/365cd6cc Drop an 
explicit dependency in tests/control

* Nicolas Boulenguez  [2019-12-09 21:49]:

I ignore if this compiler change breaks the plplot-ada ABI. If so, 
libplplotada4.deb should be renamed to libplplotada5.deb, and CMake 
should be told that plplotada_SOVERSION=5.

Could you please suggest a way to test for the ABI breakage ?


The new compiler may implement the same high-level structure with a 
new bit construct, or change the calling convention, or… 
I am not sure how to check this.


However, the Ada libraries almost always require an ALI bump (see 
below) when the libgnat sources are modfied, so I tend to stay on the 
safe side and increment the SO too, unless GCC guarantees that the ABI 
of the previous major release is preserved (I've only seen this once).


At any rate, I think that bumping the SOVERSION like this must be done 
upstream, don't you think?  I am not sure it is a good idea to have the 
Debian packaging messing with this.


It is always possible that a security update requires a change in the 
profile of an existing function (or the implementation), so there is 
no way to avoid divergence of the SOversion (or the ALIversion) in 
general. I try to keep the ordering compatible with upstream 
SOversions, at least when upstream manages the SOversions.


I have also another question regarding the package naming.  I see that you 
introduced, in commit 95d5fc9 [1], the change in naming of libplplot-ada-dev 
to libplplotada1-dev.  Is there any specific reason you have chosen the 
number "1"?  Would it not be better to have both packages in sync, like 
libplplotadaN and libplplotadaN-dev?


This is explained in the Debian policy for Ada [1]. The SO version (in 
the library package name) and the ALI version (in the -dev package 
name, specific to the Debian packaging) have no reason to be in sync, 
allthough practically we try to update both at the same time when 
possible to spare a passage through the NEW queue.


[1] 
https://people.debian.org/~lbrenta/debian-ada-policy.html#No-coexistence-allowed

Bug#946503: librostlab-doc FTCBFS: sphinx dependency unsatisfiable

[Helmut Grohne]

Source: librostlab
Version: 1.0.20-8
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

librostlab fails to cross build from source, because its sphinx-common
build dependency is not satisfiable. We observe that sphinx is only used
for building the documentation, which is nicely split to an arch:all
package. Thus sphinx should be irrelevant to cross building. To get
there, we need to move it to Build-Depends-Indep. The attached patch
moves most dependencies to Build-Depends-Indep or Build-Depends-Arch.
Please consider applying it.

Helmut
diff --minimal -Nru librostlab-1.0.20/debian/changelog 
librostlab-1.0.20/debian/changelog
--- librostlab-1.0.20/debian/changelog  2018-09-20 11:06:29.0 +0200
+++ librostlab-1.0.20/debian/changelog  2019-12-10 05:19:05.0 +0100
@@ -1,3 +1,10 @@
+librostlab (1.0.20-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Demote Build-Depends to -Arch and -Indep. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 10 Dec 2019 05:19:05 +0100
+
 librostlab (1.0.20-8) unstable; urgency=medium
 
   * Drop unneeded get-orig-source target
diff --minimal -Nru librostlab-1.0.20/debian/control 
librostlab-1.0.20/debian/control
--- librostlab-1.0.20/debian/control2018-09-20 11:06:29.0 +0200
+++ librostlab-1.0.20/debian/control2019-12-10 05:19:04.0 +0100
@@ -5,13 +5,15 @@
 Section: science
 Priority: optional
 Build-Depends: debhelper (>= 11~),
+   dh-linktree,
+Build-Depends-Arch:
d-shlibs,
+Build-Depends-Indep:
doxygen,
graphviz,
texlive-latex-recommended,
texlive-fonts-recommended,
texlive-latex-extra,
-   dh-linktree,
sphinx-common
 Standards-Version: 4.2.1
 Vcs-Browser: https://salsa.debian.org/med-team/librostlab
diff --minimal -Nru librostlab-1.0.20/debian/rules 
librostlab-1.0.20/debian/rules
--- librostlab-1.0.20/debian/rules  2018-09-20 11:06:29.0 +0200
+++ librostlab-1.0.20/debian/rules  2019-12-10 05:19:05.0 +0100
@@ -8,13 +8,12 @@
dh $@ --with linktree
 
 override_dh_auto_configure:
-   dh_auto_configure -- --enable-doxygen-dot --enable-doxygen-pdf
+   dh_auto_configure -- $(if $(filter librostlab-doc,$(shell 
dh_listpackages)),--enable-doxygen-dot --enable-doxygen-pdf)
 
-override_dh_auto_build:
-   dh_auto_build
+override_dh_auto_build-indep:
$(MAKE) -C lib doxygen-doc
 
-override_dh_install:
+override_dh_install-arch:
dh_install
d-shlibmove --commit \
--multiarch \

Bug#946502: mark hyphen-ru Multi-Arch: foreign

[Helmut Grohne]

Source: hyphen-ru
Version: 20030310-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:fbless

fbless fails to satisfy its cross Build-Depends, because its dependency
on hyphen-ru is not satisfiable. In general, Architecture: all packages
can never satisfy cross Build-Depends unless marked Multi-Arch: foreign
or annotated :native. In this case, the foreign marking is reasonable,
because hyphen-ru is effectively a data package providing
architecture-independent data. Its dependencies are already marked
Multi-Arch: foreign and it entirely lacks maintainer scripts that could
induce architecture-dependent behaviour. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru hyphen-ru-20030310/debian/changelog 
hyphen-ru-20030310/debian/changelog
--- hyphen-ru-20030310/debian/changelog 2013-05-18 18:16:00.0 +0200
+++ hyphen-ru-20030310/debian/changelog 2019-12-10 05:12:11.0 +0100
@@ -1,3 +1,10 @@
+hyphen-ru (20030310-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark hyphen-ru Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 10 Dec 2019 05:12:11 +0100
+
 hyphen-ru (20030310-1) unstable; urgency=low
 
   * Initial release (closes: #707554).
diff --minimal -Nru hyphen-ru-20030310/debian/control 
hyphen-ru-20030310/debian/control
--- hyphen-ru-20030310/debian/control   2013-05-18 18:06:49.0 +0200
+++ hyphen-ru-20030310/debian/control   2019-12-10 05:11:55.0 +0100
@@ -10,6 +10,7 @@
 
 Package: hyphen-ru
 Architecture: all
+Multi-Arch: foreign
 Depends: dictionaries-common (>= 0.10) | openoffice.org-updatedicts, 
${misc:Depends}
 Recommends: libreoffice-writer | openoffice.org-writer
 Replaces: openoffice.org-hyphenation-ru

Bug#946501: libmotif-dev et al -- cannot install

[gomsb]

Package: libmotif-dev

Version: 2.3.8-2



Have successfully installed buster on an HP tower box

- cannot install libmotif-dev or others

debg3a(0)$ uname -a
Linux debg3a 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) x86_64 
GNU/Linux

/apt/get/sources.list
deb http://deb.debian.org/debian/ buster  main non-free contrib
deb-src http://deb.debian.org/debian/ buster  main non-free contrib
deb http://security.debian.org/debian-security buster/updates main contrib 
non-free
deb-src http://security.debian.org/debian-security buster/updates main contrib 
non-free

 - tried ftp in source.list ... and got nowhere

apt-get install libmotif-dev | tee -a libmotif-dev
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libmotif-dev

apt-get install libmotif-dev:amd64 | tee -a libmotif-dev:amd64
Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
  rename sgml-base tcpd xml-core
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  freetype2-doc javascript-common libdpkg-perl libexpat1-dev
  libfile-fcntllock-perl libfontconfig1-dev libfreetype6-dev libjs-jquery
  libmrm4 libpng-dev libpng-tools libuil4 libxft-dev libxrender-dev pkg-config
  uil uuid-dev zlib1g-dev
Suggested packages:
  debian-keyring patch git bzr dpkg-dev
The following NEW packages will be installed:
  freetype2  ...   libmotif-dev libmrm4  ...

After this operation, 25.1 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://deb.debian.org/debian buster/main amd64 libmrm4 amd64 2.3.8-2 
[88.9 kB]
Get:2 http://deb.debian.org/debian buster/main amd64 libuil4 amd64 2.3.8-2 [159 
kB]
Get:3 http://deb.debian.org/debian buster/main amd64 libjs-jquery all 
3.3.1~dfsg-3 [332 kB]
Err:4 http://deb.debian.org/debian buster/main amd64 freetype2-doc all 2.9.1-3
  404  Not Found [IP: 199.232.8.204 80]
Get:5 http://deb.debian.org/debian buster/main amd64 javascript-common all 11 
[6,120 B]
Get:6 http://deb.debian.org/debian buster/main amd64 libdpkg-perl all 1.19.7 
[1,414 kB]
Err:7 http://deb.debian.org/debian buster/main amd64 libexpat1-dev amd64 2.2.6-2
  404  Not Found [IP: 199.232.8.204 80]
Get:8 http://deb.debian.org/debian buster/main amd64 libfile-fcntllock-perl 
amd64 0.22-3+b5 [35.4 kB]
Get:9 http://deb.debian.org/debian buster/main amd64 zlib1g-dev amd64 
1:1.2.11.dfsg-1 [214 kB]
Get:10 http://deb.debian.org/debian buster/main amd64 libpng-dev amd64 1.6.36-6 
[300 kB]
Err:11 http://deb.debian.org/debian buster/main amd64 libfreetype6-dev amd64 
2.9.1-3
  404  Not Found [IP: 199.232.8.204 80]
Get:12 http://deb.debian.org/debian buster/main amd64 uuid-dev amd64 2.33.1-0.1 
[93.6 kB]
Get:13 http://deb.debian.org/debian buster/main amd64 pkg-config amd64 0.29-6 
[63.5 kB]
Get:14 http://deb.debian.org/debian buster/main amd64 libfontconfig1-dev amd64 
2.13.1-2 [966 kB]
Get:15 http://deb.debian.org/debian buster/main amd64 libxrender-dev amd64 
1:0.9.10-1 [40.8 kB]
Get:16 http://deb.debian.org/debian buster/main amd64 libxft-dev amd64 2.3.2-2 
[68.7 kB]
Get:17 http://deb.debian.org/debian buster/main amd64 uil amd64 2.3.8-2 [38.5 
kB]
Get:18 http://deb.debian.org/debian buster/main amd64 libmotif-dev amd64 
2.3.8-2 [2,475 kB]
Get:19 http://deb.debian.org/debian buster/main amd64 libpng-tools amd64 
1.6.36-6 [140 kB]
Fetched 6,435 kB in 6s (1,102 kB/s)
E: Failed to fetch 
http://deb.debian.org/debian/pool/main/f/freetype/freetype2-doc_2.9.1-3_all.deb 
 404  Not Found [IP: 199.232.8.204 80]
E: Failed to fetch 
http://deb.debian.org/debian/pool/main/e/expat/libexpat1-dev_2.2.6-2_amd64.deb  
404  Not Found [IP: 199.232.8.204 80]
E: Failed to fetch 
http://deb.debian.org/debian/pool/main/f/freetype/libfreetype6-dev_2.9.1-3_amd64.deb
  404  Not Found [IP: 199.232.8.204 80]
E: Unable to fetch some archives, maybe run apt-get update or try with 
--fix-missing?
 -
debg3a(0)$ dpkg -l libmotif* 
+++-===---=
ii  libmotif-common 2.3.8-2  all  Motif - common files
un  libmotif3 (no description available)
un  libmotif4 (no description available)

 - no sign of libmotif-dev*  -- although Get: 18 above made a pass at it

debg3a(3)$ dpkg -l libmrm*  --  ok
ii  libmrm4:amd64  2.3.8-2  amd64Motif - MRM ...  -  ok
debg3a(3)$ dpkg -l libuil*
dpkg-query: no packages found matching libuil*- ??
debg3a(1)$ dpkg -l libpng*
ii  libpng16-16:amd64 1.6.36-6 amd64PNG library  - ok
debg3a(1)$ dpkg -l libmotif-dev*
dpkg-query: no packages found matching libmotif-dev*
debg3a(1)$ dpkg -l libmotif-dev
dpkg-query: no packages found matching libmotif-dev


Any suggestions?

Eventually want to install lesstif from Sourceforge - a great windows program
(as was the original Motif) - 

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

[Changwoo Ryu]

Control: retitle -1 Document that bugscripts run in "C" locale

2019년 12월 8일 (일) 오전 5:39, Nis Martensen 님이 작성:
>
> 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)

I'm convinced. Adding documentation about it would be good.

Thanks.

Bug#946233: Non-deterministic build depending on presence of cmake

[Drew Parsons]

Source: pygalmesh
Followup-For: Bug #946233

I checked with Nico upstream, cmake is not intended for building
pygalmesh for python module deployment.  He's set up the cmake scripts
as a convenience for testing during development.
https://github.com/nschloe/pygalmesh/issues/56


That fact that you've got a cmake-dependent build is a different
problem.  The build is supposed to be controlled by dh --buildsystem
in debian/rules.  It's currently set to --buildsystem=pybuild for
python module building.  The cmake build can be triggered by changing 
that to

--buildsystem=cmake.

But that cmake build should not be happening by accident depending
merely on the availability of cmake.  Obviously I've got cmake
installed, but the pygalmesh proceeds with the pybuild build not a
cmake build.

It looks as if your system has some weird configuration that overrides
the --buildsystem setting in debian/rules and always enforces
--buildsystem=cmake.  Are there any DH_ environment variables that
might do this?  I don't know of any, but the build is certainly not
supposed to use cmake automatically simply because it's installed.

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

Kernel: Linux 5.3.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)

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

Bug#946500: ibus-cangjie: Cannot run ibus-setup-cangjie

[Changwoo Ryu]

Package: ibus-cangjie
Version: 2.4-3
Severity: important

ibus-setup-cangjie just finished with a Python exception:

$ /usr/bin/ibus-setup-cangjie cangjie
Traceback (most recent call last):
  File "/usr/bin/ibus-setup-cangjie", line 42, in 
from ibus_cangjie.setup import Setup
  File "/usr/lib/python3/dist-packages/ibus_cangjie/setup.py", line 23, in

gi.require_version('Gio','3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 121, in
require_version
(namespace, loaded_version))
ValueError: Namespace Gio is already loaded with version 2.0

$ /usr/bin/ibus-setup-cangjie quick
Traceback (most recent call last):
  File "/usr/bin/ibus-setup-cangjie", line 42, in 
from ibus_cangjie.setup import Setup
  File "/usr/lib/python3/dist-packages/ibus_cangjie/setup.py", line 23, in

gi.require_version('Gio','3.0')
  File "/usr/lib/python3/dist-packages/gi/__init__.py", line 121, in
require_version
(namespace, loaded_version))
ValueError: Namespace Gio is already loaded with version 2.0



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

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

Versions of packages ibus-cangjie depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.34.0-1
ii  gir1.2-ibus-1.0  1.5.21-4
ii  ibus 1.5.21-4
ii  python3  3.7.5-3
ii  python3-gi   3.34.0-3
ii  python3-pycangjie1.3-1+b1

ibus-cangjie recommends no packages.

ibus-cangjie suggests no packages.

-- no debconf information

Bug#33486: Lintian now checks mailcap files

[Felix Lechner]

Control: fixed -1 lintian/2.42.0

Charles,

Thank you helping bring to this long-standing issue to a resolution.
The bug was fixed with this commit:


https://salsa.debian.org/lintian/lintian/commit/6a07df2e4c8c9f6b2b12ef39d22b2a68f5c5a326

Raphael, sorry to close your bug. I did not see your ownership until
after I pushed the commits.

Kind regards,
Felix Lechner

Bug#946499: eog crashes with 'BadAlloc (insufficient resources for operation)' on large image

[scott092707]

Package: eog
Version: 3.34.1-1
Severity: important

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Scott Jacobs 
To: Debian Bug Tracking System 
Subject: eog crashes with 'BadAlloc (insufficient resources for operation)' on 
large image
Bcc: Scott Jacobs 
Message-ID: 
<157594733072.4153.8536409629457292126.reportbug@ASUS-PRIME-B350M-A-CSM>
X-Mailer: reportbug 7.5.3
Date: Mon, 09 Dec 2019 22:08:50 -0500
X-Debbugs-Cc: scott092...@aol.com

Dear Maintainer,

On trying to open a large image (identify reports "JPEG 44351x3013
44351x3013+0+0 8-bit sRGB 18.7524MiB 0.000u 0:00.000"), the window opens, and 
then
closes.  When run from the terminal, eog crashes with:

(eog:3197): Gdk-ERROR **: 21:21:44.635: The program 'eog' received an X Window
System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 1991 error_code 11 request_code 130 (MIT-SHM) minor_code 5)
..."

The rest of the eog error message suggested how best to run under the debugger,
so here is the text of the run:


scott@ASUS-PRIME-B350M-A-CSM:~$ GDK_SYNCHRONIZE gdb --args eog
/data/scott/Photos/Unreviewed/20191015_Trip_Michaelsberg/Pan5/TKDD1446-54_RL.jpg
bash: GDK_SYNCHRONIZE: command not found
scott@ASUS-PRIME-B350M-A-CSM:~$ GDK_SYNCHRONIZE=1 gdb --args eog
/data/scott/Photos/Unreviewed/20191015_Trip_Michaelsberg/Pan5/TKDD1446-54_RL.jpg
GNU gdb (Debian 8.3.1-1) 8.3.1
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from eog...
Reading symbols from /usr/lib/debug/.build-
id/5f/7bc6fae2d0db1b144e2b30cdf905dd5e36c1b8.debug...
(gdb) break gdk_x_error()
Function "gdk_x_error()" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (gdk_x_error()) pending.
(gdb) run
Starting program: /usr/bin/eog
/data/scott/Photos/Unreviewed/20191015_Trip_Michaelsberg/Pan5/TKDD1446-54_RL.jpg
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7208d700 (LWP 3902)]
[New Thread 0x7188c700 (LWP 3903)]
[New Thread 0x7108b700 (LWP 3904)]
[New Thread 0x7fffe3fff700 (LWP 3905)]
[New Thread 0x7fffe37fe700 (LWP 3906)]
[New Thread 0x7fffe2ffd700 (LWP 3907)]
[Thread 0x7fffe2ffd700 (LWP 3907) exited]

(eog:3898): Gdk-ERROR **: 21:40:47.313: The program 'eog' received an X Window
System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 3687 error_code 11 request_code 130 (MIT-SHM) minor_code 5)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

Thread 1 "eog" received signal SIGTRAP, Trace/breakpoint trap.
0x77c3ddb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
(gdb) backtrace
#0  0x77c3ddb5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#1  0x77c406bc in g_log_writer_default () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x77c3e9e7 in g_log_structured_array () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#3  0x77c3f400 in g_log_structured_standard () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#4  0x7723060a in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
#5  0x7723d443 in ?? () from /lib/x86_64-linux-gnu/libgdk-3.so.0
#6  0x7641c14b in _XError () from /lib/x86_64-linux-gnu/libX11.so.6
#7  0x76418f77 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#8  0x76419015 in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#9  0x76419f6d in _XReply () from /lib/x86_64-linux-gnu/libX11.so.6
#10 0x7641581d in XSync () from /lib/x86_64-linux-gnu/libX11.so.6
#11 0x764158bb in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#12 0x7641caaf in ?? () from /lib/x86_64-linux-gnu/libX11.so.6
#13 0x753abe81 in XShmCreatePixmap () from /lib/x86_64-linux-
gnu/libXext.so.6
#14 0x7714fd73 in ?? () from 

Bug#946497: zfs-dkms: fails to build module for 5.3.0-3-amd64

[Petter Reinholdtsen]

[Andreas Beckmann]
> during a test with piuparts I noticed your package failed to install.

Thank you for the heads up.  Looking at the attached log, I see gcc-9 is
installed, and thus the error message is very strange:

>   Building initial module for 5.3.0-3-amd64
>   configure: error: in `/var/lib/dkms/zfs/0.8.2/build':
>   configure: error: no acceptable C compiler found in $PATH
>   See `config.log' for more details

Can gcc be broken?  Or is it dkms?  Or something else?

I notice
https://ci.debian.net/packages/z/zfs-linux/testing/amd64/ >
passed 2019-12-06 13:15:16 UTC.  Is the test insufficient to discover
this problem, or did something change in the mean time?

-- 
Happy hacking
Petter Reinholdtsen

Bug#946498: python3-certifi: Update to upstream version

[Emmanuel Arias]

Package: python3-certifi
Version: 2018.8.24-1
Severity: wishlist

Dear Maintainer,

Please  update to last upstream version elasticsearch-curator need
version >= 2019.9.11.

Cheers,

Bug#945375: gnome-control-center: Segmentation fault when selecting display on secondary GPU.

[Bernhard Übelacker]

Control: tags -1 + patch upstream fixed-upstream


Hello Mladen Mijatov, dear Maintainer,
the first frames would be translated by addr2line to following [1].

This looks like the crash is caused by an invalid pointer pself/self
in function cc_display_mode_dbus_is_supported_scale [112].
This pointer is retrieved by cc_display_monitor_get_mode in [399].

That led me to this upstream bug [2] which got
already fixed in [3]. Either of the upstream tags 3.34.2 or 3.35.2
contains that patch.

Kind regards,
Bernhard



[1]
  #apt install systemd-coredump gnome binutils gdb gnome-control-center-dbgsym 
libglib2.0-0-dbgsym libgtk-3-0-dbgsym
  cat backtrace.txt | tr '()[]' ' ' | while read -ra line; do
  if [[ ${line[1]:0:1} == "+" ]] ; then
  if [[ ${line[0]:0:1} == "/" ]] ; then
  F=${line[0]};
  else
  F=$(which ${line[0]});
  fi;
  echo ${line[2]} at $(addr2line --exe=$F  ${line[1]}) from ${line[0]} 
${line[1]};
  else
  echo ${line[2]} in ${line[1]} from ${line[0]};
  fi;
  done

  0x56214d26c2de at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-config-dbus.c:112 from 
gnome-control-center +0xa82de
  0x56214d26c425 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-config-dbus.c:1217 from 
gnome-control-center +0xa8425
  0x56214d269206 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-settings.c:399 from 
gnome-control-center +0xa5206
  0x56214d269b73 in cc_display_settings_set_selected_output+0x13 from 
gnome-control-center
  0x56214d262970 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-panel.c:733 from 
gnome-control-center +0x9e970
  0x56214d263780 at 
./obj-x86_64-linux-gnu/../panels/display/cc-display-panel.c:546 from 
gnome-control-center +0x9f780
  0x7fb21bc370e6 at ../../../gobject/gclosure.c:294 from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 +0x140e6
  ...

[2] https://gitlab.gnome.org/GNOME/gnome-control-center/issues/675
[3] 
https://gitlab.gnome.org/GNOME/gnome-control-center/commit/0fa4d11477076c9d06af218795cd8c6194fa5dff

[112]  
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-config-dbus.c/#L112
[1217] 
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-config-dbus.c/#L1217
[399]  
https://sources.debian.org/src/gnome-control-center/1:3.34.1-1/panels/display/cc-display-settings.c/#L399

Bug#946400: plplot: please build the Ada binding with gnat-9

[Nicolas Boulenguez]

> > I ignore if this compiler change breaks the plplot-ada ABI. If so,
> > libplplotada4.deb should be renamed to libplplotada5.deb, and CMake
> > should be told that plplotada_SOVERSION=5.
> Could you please suggest a way to test for the ABI breakage ?

The new compiler may implement the same high-level structure with a
new bit construct, or change the calling convention, or…
I am not sure how to check this.

However, the Ada libraries almost always require an ALI bump (see
below) when the libgnat sources are modfied, so I tend to stay on the
safe side and increment the SO too, unless GCC guarantees that the ABI
of the previous major release is preserved (I've only seen this once).

> At any rate, I think that bumping the SOVERSION like this must be done
> upstream, don't you think?  I am not sure it is a good idea to have the
> Debian packaging messing with this.

It is always possible that a security update requires a change in the
profile of an existing function (or the implementation), so there is
no way to avoid divergence of the SOversion (or the ALIversion) in
general. I try to keep the ordering compatible with upstream
SOversions, at least when upstream manages the SOversions.

> I have also another question regarding the package naming.  I see that you
> introduced, in commit 95d5fc9 [1], the change in naming of libplplot-ada-dev
> to libplplotada1-dev.  Is there any specific reason you have chosen the
> number "1"?  Would it not be better to have both packages in sync, like
> libplplotadaN and libplplotadaN-dev?

This is explained in the Debian policy for Ada [1]. The SO version (in
the library package name) and the ALI version (in the -dev package
name, specific to the Debian packaging) have no reason to be in sync,
allthough practically we try to update both at the same time when
possible to spare a passage through the NEW queue.

[1] 
https://people.debian.org/~lbrenta/debian-ada-policy.html#No-coexistence-allowed

Bug#930128: tint: Error creating /var/games/tint.scores

[Asher Gordon]

Package: tint
Version: 0.05+b1
Followup-For: Bug #930128

Hi,

I've looked into this a bit more, and I've found commit a05fa0e30c (in
the Debian git repository [1]). This commit references #769296, which I
will now quote:

Ernest Adrogué  writes:

> As long as the player is in group "games" making tint.scores
> group-writeable should be enough to fix the problem.  No need to setgid
> the tint executable.

The maintainer (Ricardo Mones) documented this solution in
/usr/share/doc/tint/README.Debian. However, I think this solution is
inferior to making the binary setgid "games" for a couple reasons:

  a) Most games in Debian use the setgid method. I don't see why TINT
 should be any different.

  b) If a user is part of the "games" group, that user may tamper with
 the score file. If the binary is setgid "games", users may only
 write to the score file through TINT itself.

Looking at the moon buggy package, I believe the following patch should
make the binary setgid "games" (I tested it out on my machine and it
works):

From 085c8eb8e021c271c1c57311decc638d53276459 Mon Sep 17 00:00:00 2001
From: Asher Gordon 
Date: Mon, 9 Dec 2019 19:13:37 -0500
Subject: [PATCH] Install binary as setgid games.

Users now no longer have to be part of the group "games" to save
highscores.

Also remove README.Debian since it is no longer relevant.
---
 debian/README.Debian | 12 
 debian/rules | 13 +
 2 files changed, 13 insertions(+), 12 deletions(-)
 delete mode 100644 debian/README.Debian

diff --git a/debian/README.Debian b/debian/README.Debian
deleted file mode 100644
index 2ccdf2b..000
--- a/debian/README.Debian
+++ /dev/null
@@ -1,12 +0,0 @@
-
-TINT Is Not Tetris for Debian
--
-
-  Users which are allowed to update the scores file must be added to the
-  "games" group, otherwise an error message is printed after entering
-  your name: "Error creating /var/games/tint.scores"
-
-  Simplest method is running "adduser  games" as root. User
-  session must also be restarted to make this change effective.
-
- -- Ricardo Mones   Sat, 26 Jan 2019 13:59:03 +0100
diff --git a/debian/rules b/debian/rules
index 2d33f6a..45e9016 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,4 +1,17 @@
 #!/usr/bin/make -f
 
+PACKAGE = tint
+
+# setgid games to access highscore files
+INSTALL_GAME = install -p -o root -g games -m 2755
+
 %:
 	dh $@
+
+override_dh_install:
+	dh_install -X usr/games/$(PACKAGE)
+	# setgid games
+	$(INSTALL_GAME) $(PACKAGE) debian/$(PACKAGE)/usr/games/
+
+override_dh_fixperms:
+	dh_fixperms -X usr/games/$(PACKAGE)
-- 
2.24.0


Note that I have also removed README.Debian in the above patch because
it is no longer relevant.


Thanks,
Asher


P.S. I am going to attempt to add a patch tag to this bug (since I added
a patch), but I don't know if I have permission to do so, so it may not
work (I've never tried before).


Footnotes: 
[1]  https://salsa.debian.org/games-team/tint.git


-- 
: The following (relative to AutoSplit 1.03) attempts to please everyone
: and perhaps pleases no one:

I think that's way cool.
-- Larry Wall in <199709292015.naa09...@wall.org>

GPG fingerprint: 38F3 975C D173 4037 B397  8095 D4C9 C4FC 5460 8E68


signature.asc
Description: PGP signature

Bug#946497: zfs-dkms: fails to build module for 5.3.0-3-amd64

[Andreas Beckmann]

Package: zfs-dkms
Version: 0.8.2-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up zfs-dkms (0.8.2-3) ...
  Loading new zfs-0.8.2 DKMS files...
  It is likely that 4.9.0-9-amd64 belongs to a chroot's host
  Building for 5.3.0-3-amd64
  Building initial module for 5.3.0-3-amd64
  configure: error: in `/var/lib/dkms/zfs/0.8.2/build':
  configure: error: no acceptable C compiler found in $PATH
  See `config.log' for more details
  Error! Bad return status for module build on kernel: 5.3.0-3-amd64 (x86_64)
  Consult /var/lib/dkms/zfs/0.8.2/build/make.log for more information.
  dpkg: error processing package zfs-dkms (--configure):
   installed zfs-dkms package post-installation script subprocess returned 
error exit status 10
  Processing triggers for libc-bin (2.29-5) ...
  Errors were encountered while processing:
   zfs-dkms

/var/lib/dkms/zfs/0.8.2/build/make.log contains:

DKMS make.log for zfs-0.8.2 for kernel 5.3.0-3-amd64 (x86_64)
Tue Dec 10 00:50:52 UTC 2019
make: *** No targets specified and no makefile found.  Stop.


cheers,

Andreas


zfs-dkms_0.8.2-3.log.gz
Description: application/gzip

Bug#946495: RFP: mcrouter -- a memcached protocol router for scaling memcached deployments

[Dean Hamstead]

Package: wnpp
Severity: wishlist

* Package name: mcrouter
  Version : 41
  Upstream Author : Facebook, Inc
* URL : https://github.com/facebook/mcrouter
* License : MIT
  Programming Lang: C++
  Description : A memcached protocol router for scaling memcached 
deployments

Mcrouter is a memcached protocol router for scaling memcached 
(http://memcached.org/) deployments. It's a core component of cache 
infrastructure at Facebook and Instagram where mcrouter handles almost 5 
billion requests per second at peak.

---

It seems the wikimedia people have debian packaging at 
https://github.com/wikimedia/operations-debs-mcrouter

And the 'packaging' branch seems to have their ubuntu packaging 
https://github.com/facebook/mcrouter/tree/packaging

Both of which may make packaging easier

Bug#946496: libsdl2: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libsdl2
Version: 2.0.10+dfsg1-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 libsdl2 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 libsdl2-2.0.10+dfsg1/debian/tests/build 
libsdl2-2.0.10+dfsg1/debian/tests/build
--- libsdl2-2.0.10+dfsg1/debian/tests/build 2019-09-19 22:01:14.0 
-0700
+++ libsdl2-2.0.10+dfsg1/debian/tests/build 2019-12-09 15:33:44.0 
-0800
@@ -16,6 +16,13 @@
 
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cd $WORKDIR
 cat < use-sdl.c
 #undef NDEBUG
@@ -53,10 +60,10 @@
 
 case "$tool" in
 (pkg-config)
-gcc $cflags -o use-${tool}-${mode} use-sdl.c `pkg-config $pcflags 
--cflags --libs sdl2`
+${CROSS_COMPILE}gcc $cflags -o use-${tool}-${mode} use-sdl.c 
`${CROSS_COMPILE}pkg-config $pcflags --cflags --libs sdl2`
 ;;
 (sdl2-config)
-gcc $cflags -o use-${tool}-${mode} use-sdl.c `sdl2-config --cflags 
$scflags`
+${CROSS_COMPILE}gcc $cflags -o use-${tool}-${mode} use-sdl.c 
`sdl2-config --cflags $scflags`
 ;;
 (*)
 exit 1
diff -Nru libsdl2-2.0.10+dfsg1/debian/tests/build-all 
libsdl2-2.0.10+dfsg1/debian/tests/build-all
--- libsdl2-2.0.10+dfsg1/debian/tests/build-all 2019-09-19 22:01:14.0 
-0700
+++ libsdl2-2.0.10+dfsg1/debian/tests/build-all 2019-12-09 16:21:37.0 
-0800
@@ -9,7 +9,19 @@
 
 WORKDIR=$(mktemp -d)
 trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM
+
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+cat < "$WORKDIR/toolchain.cmake"
+set(CMAKE_C_COMPILER $DEB_HOST_GNU_TYPE-gcc)
+set(CMAKE_CXX_COMPILER $DEB_HOST_GNU_TYPE-g++)
+set(PKG_CONFIG_EXECUTABLE $DEB_HOST_GNU_TYPE-pkg-config)
+EOF
+CCFILE=-DCMAKE_TOOLCHAIN_FILE="$WORKDIR/toolchain.cmake"
+else
+CCFILE=
+fi
+
 cp -R * $WORKDIR
 cd $WORKDIR
 mkdir build && cd build
-cmake .. -DSDL_TEST=ON && make && make test
+cmake .. "$CCFILE" -DSDL_TEST=ON && make && make test

Bug#946494: cpl-plugin-kmos-calib: download location no longer available ?

[Andreas Beckmann]

Package: cpl-plugin-kmos-calib
Version: 2.1.0+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

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

  Setting up cpl-plugin-kmos-calib (2.1.0+dfsg-1) ...
  --2019-12-09 20:55:08--  
ftp://ftp.eso.org/pub/dfs/pipelines/kmos/kmos-kit-2.1.0.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.54, 134.171.42.53
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.54|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/kmos ... done.
  ==> SIZE kmos-kit-2.1.0.tar.gz ... done.
  
  ==> PASV ... done.==> RETR kmos-kit-2.1.0.tar.gz ... 
  No such file 'kmos-kit-2.1.0.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  --2019-12-09 20:55:08--  
ftp://ftp.eso.org/pub/dfs/pipelines/kmos/kmos-kit-2.1.0-1.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.53, 134.171.42.54
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.53|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/kmos ... done.
  ==> SIZE kmos-kit-2.1.0-1.tar.gz ... done.
  
  ==> PASV ... done.==> RETR kmos-kit-2.1.0-1.tar.gz ... 
  No such file 'kmos-kit-2.1.0-1.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  --2019-12-09 20:55:09--  
ftp://ftp.eso.org/pub/dfs/pipelines/kmos/kmos-kit-2.1.0-2.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.53, 134.171.42.54
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.53|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/kmos ... done.
  ==> SIZE kmos-kit-2.1.0-2.tar.gz ... done.
  
  ==> PASV ... done.==> RETR kmos-kit-2.1.0-2.tar.gz ... 
  No such file 'kmos-kit-2.1.0-2.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  --2019-12-09 20:55:09--  
ftp://ftp.eso.org/pub/dfs/pipelines/kmos/kmos-kit-2.1.0-3.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.54, 134.171.42.53
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.54|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/kmos ... done.
  ==> SIZE kmos-kit-2.1.0-3.tar.gz ... done.
  
  ==> PASV ... done.==> RETR kmos-kit-2.1.0-3.tar.gz ... 
  No such file 'kmos-kit-2.1.0-3.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  --2019-12-09 20:55:09--  
ftp://ftp.eso.org/pub/dfs/pipelines/kmos/kmos-kit-2.1.0-4.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.53, 134.171.42.54
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.53|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/kmos ... done.
  ==> SIZE kmos-kit-2.1.0-4.tar.gz ... done.
  
  ==> PASV ... done.==> RETR kmos-kit-2.1.0-4.tar.gz ... 
  No such file 'kmos-kit-2.1.0-4.tar.gz'.
  
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  
  gzip: stdin: unexpected end of file
  tar: Child returned status 1
  tar: Error is not recoverable: exiting now
  --2019-12-09 20:55:10--  
ftp://ftp.eso.org/pub/dfs/pipelines/kmos/kmos-kit-2.1.0-5.tar.gz
 => '-'
  Resolving ftp.eso.org (ftp.eso.org)... 134.171.42.54, 134.171.42.53
  Connecting to ftp.eso.org (ftp.eso.org)|134.171.42.54|:21... connected.
  Logging in as anonymous ... Logged in!
  ==> SYST ... done.==> PWD ... done.
  ==> TYPE I ... done.  ==> CWD (1) /pub/dfs/pipelines/kmos ... done.
  ==> SIZE kmos-kit-2.1.0-5.tar.gz ... done.
  
  ==> PASV ... done.==> RETR kmos-kit-2.1.0-5.tar.gz ... 
  No such file 'kmos-kit-2.1.0-5.tar.gz'.
  
  
  gzip: stdin: unexpected end of 

Bug#946493: libmtp9: MTP communication broken in Debian Buster

[damien]

Package: libmtp9
Version: 1.1.16-2
Severity: important

File exchange between a host and a usb connected Music player(s) no longer 
works on Debian Buster.
Exact same Music player(s) (hardware+firmware) do work/sync with no issues on 
Debian 'Jessie' and 'Stretch' as of right now. 

Music player(s) tested: Sony NWZ-S544 and no-name Chinese made generic MP3 
player.
Protocol used: MTP

Please sonsider bringing back MTP-type communication with a usb mounted music 
players in Debian Buster.

Damien

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

Kernel: Linux 4.19.0-6-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 libmtp9 depends on:
ii  libc6  2.28-10
ii  libgcrypt201.8.4-5
ii  libmtp-common  1.1.16-2
ii  libusb-1.0-0   2:1.0.22-2

Versions of packages libmtp9 recommends:
ii  libmtp-runtime  1.1.16-2
ii  udev241-7~deb10u2

libmtp9 suggests no packages.

-- no debconf information

Bug#946492: vdjtools: broken symlink: /usr/share/java/vdjtools.jar -> vdjtools-1.2.1+git20190311.jar

[Andreas Beckmann]

Package: vdjtools
Version: 1.2.1+git20190311-1
Severity: normal
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

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

1m19.7s ERROR: FAIL: Broken symlinks:
  /usr/share/java/vdjtools.jar -> vdjtools-1.2.1+git20190311.jar (vdjtools)

But libvdjtools-java ships /usr/share/java/vdjtools-1.2.1.jar instead.


cheers,

Andreas


vdjtools_1.2.1+git20190311-1.log.gz
Description: application/gzip

Bug#944603: Attempt to print checks crashes gnucash

[Bernhard Übelacker]

Hello local10,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.

catchsegv gnome-control-center

Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of the crash.

Kind regards,
Bernhard

Bug#945375: gnome-control-center: Segmentation fault when selecting display on secondary GPU.

[Bernhard Übelacker]

Hello Mladen Mijatov,
if you still get this crash, maybe if you start it like below
there would be more information about the crash.

catchsegv gnome-control-center

Alternatively you could install systemd-coredump and look
at the end of 'journalctl --no-pager' if there is some debug
information of the crash.

Kind regards,
Bernhard

Bug#946491: unattended-upgrades: 100% of at least one CPU core consumed until killed daily via debian

[colin williams]

Package: unattended-upgrades
Version: 1.15
Severity: normal

Dear Maintainer,


   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?



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

Kernel: Linux 4.19.0-4-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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.73
ii  lsb-base   11.1.0
ii  lsb-release11.1.0
ii  python33.7.3-1
ii  python3-apt1.8.4+b1
ii  python3-dbus   1.2.14-1
ii  python3-distro-info0.22
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-29
ii  cron [cron-daemon]  3.0pl1-135
ii  systemd-sysv243-8

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1+b1
ii  exim4-daemon-light [mail-transport-agent]  4.92-5
pn  needrestart
ii  powermgmt-base 1.36
ii  python3-gi 3.34.0-3

-- debconf information:
  unattended-upgrades/enable_auto_updates: true
  unattended-upgrades/origins_pattern: 
"origin=Debian,codename=${distro_codename},label=Debian-Security";

Bug#629161: Please provide groff backport for lintian.d.o

[Felix Lechner]

Control: severity -1 wishlist
Control: block -1 by 867123
Control: retitle -1 groff: Please provide stable-backport
Control: reassign -1 groff

Hi Colin,

After consulting with Guillem, I wonder if you could provide a stable
backport of groff? As I am sure you are aware, that is what we run on
lintian.d.o. You previously offered as much here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629161#52

Guillem's primary concern seems to revolve around #867123 (update OS
macros). He has been using a self-help of sorts:


https://gitlab.freedesktop.org/libbsd/libbsd/commit/99320b9168ffb0112def1a712e8d59441d1b46d9

We would only require the groff backport after #867123 is fixed. That
bug now blocks the one in front of us.

Please assign this bug back to Lintian if you feel an error was made.

Kind regards
Felix Lechner

Bug#946490: json-glib: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: json-glib
Version: 1.4.4-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 json-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 json-glib-1.4.4/debian/tests/build json-glib-1.4.4/debian/tests/build
--- json-glib-1.4.4/debian/tests/build  2018-12-27 07:15:42.0 -0800
+++ json-glib-1.4.4/debian/tests/build  2019-12-09 13:24:44.0 -0800
@@ -5,6 +5,12 @@
 exec 2>&1
 set -x
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cd "${AUTOPKGTEST_TMP:-"${ADTTMP}"}"
 
 cat > trivial.c <

Bug#946489: RM: sozi -- RoQA; depends on pygtk2, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove sozi. It depends on pygtk2, which is going away
and hasn't seen a maintainer upload since 2012.

Cheers,
Moritz

Bug#946405: nextcloud-desktop: Nextcloud desktop client crash when trying to enter login/password

[Bernhard Übelacker]

Hello Ludovic,
I tried to collect some more information from your crash dump.
With debug symbols this backtrace should look like below.

I guess you are running a nvidia graphics card
with the nouveau drivers?

As a workaround it may work if you start the client
from a terminal by following:

export LIBGL_ALWAYS_SOFTWARE=1
nextcloud

Or maybe this:

export QT_XCB_FORCE_SOFTWARE_OPENGL=1
nextcloud


Maybe you can confirm my findings, and forward the output of
following commands to this bug:

lspci | grep VGA
glxinfo | grep -i -E "GLX_MESA_query_renderer.:" -A5


Kind regards,
Bernhard



  From submitter  |
Reconstructed
 #0  0x7fe16d9b6bde  | 0x7f1811853bde 

 #1  0x7fe16d9b6cf0  | 0x7f1811853cf0 

 #2  0x7fe16d9b7327  | 0x7f1811854327 

 #3  0x7fe166ea4840  | 0x7f180ad41840 
<__restore_rt+0>: mov$0xf,%rax
 #4  0x7fe152142a8c  | 0x7f17f754ca8c 
in list_del at ../src/util/list.h:91
 #5  0x7fe152142c87  | 0x7f17f754cc87 
in nouveau_fence_update at ../src/gallium/drivers/nouveau/nouveau_fence.c:128
 #6  0x7fe152142f83  | 0x7f17f754cf83 
in nouveau_fence_wait at ../src/gallium/drivers/nouveau/nouveau_fence.c:219
 #7  0x7fe1523cf490  | 0x7f17f77d9490 
in st_finish (st=st@entry=0x562393326c90) at 
../src/mesa/state_tracker/st_cb_flush.c:69
 #8  0x7fe1523cf4e0  | 0x7f17f77d94e0 
in st_glFinish (ctx=) at 
../src/mesa/state_tracker/st_cb_flush.c:104
 #9  0x7fe166a5f156  | 0x7f180a8fc156 
in QQuickWidgetPrivate::render (this=0x562392ccb0b0, needsSync=) 
at qquickwidget.cpp:295
 #10 0x7fe166a5f2b6  | 0x7f180a8fc2b6 
in QQuickWidgetPrivate::renderSceneGraph (this=0x562392ccb0b0) at 
qquickwidget.cpp:339
 #11 0x7fe1675e509b QObject::event()  | 0x7f180b48209b 
in QObject::event (this=this@entry=0x5623930a2130, e=e@entry=0x7ffcf1848bb0) at 
kernel/qobject.cpp:1232
 #12 0x7fe167f7496b QWidget::event()  | 0x7f180be1196b 
in QWidget::event (this=this@entry=0x5623930a2130, 
event=event@entry=0x7ffcf1848bb0) at kernel/qwidget.cpp:9353
 #13 0x7fe166a62e5d QQuickWidget::event() | 0x7f180a8ffe5d 
in QQuickWidget::event (this=0x5623930a2130, e=0x7ffcf1848bb0) at 
qquickwidget.cpp:1525
 #14 0x7fe17207cb50  | 0x7f1815f19b50 
in QtWebEngineCore::RenderWidgetHostViewQtDelegateWidget::event(QEvent*) () 
from /lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5
 #15 0x7fe167f364c1 QApplicationPrivate::notify_helper()  | 0x7f180bdd34c1 
in QApplicationPrivate::notify_helper (this=this@entry=0x562392919dd0, 
receiver=receiver@entry=0x5623930a2130, e=e@entry=0x7ffcf1848bb0) at 
kernel/qapplication.cpp:3726
 #16 0x7fe167f3d970 QApplication::notify()| 0x7f180bdda970 
in QApplication::notify (this=0x7ffcf1848ef0, receiver=0x5623930a2130, 
e=0x7ffcf1848bb0) at kernel/qapplication.cpp:3485
 #17 0x7fe1675bb4f9 QCoreApplication::notifyInternal2()   | 0x7f180b4584f9 
in QCoreApplication::notifyInternal2 (receiver=0x5623930a2130, 
event=event@entry=0x7ffcf1848bb0) at 
../../include/QtCore/5.11.3/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307
  | 0x7f180b4a8ba8 
in QCoreApplication::sendEvent (event=0x7ffcf1848bb0, receiver=) 
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234
  | 0x7f180b4a8ba8 
in QTimerInfoList::activateTimers (this=0x562392954560) at 
kernel/qtimerinfo_unix.cpp:643
  | 0x7f180b4a943c 
in timerSourceDispatch (source=) at 
kernel/qeventdispatcher_glib.cpp:182
  | 0x7f180b4a943c 
in idleTimerSourceDispatch (source=) at 
kernel/qeventdispatcher_glib.cpp:229
 #18 0x7fe16760bba8 QTimerInfoList::activateTimers()  | 0x7f180b4a8ba8 
in QTimerInfoList::activateTimers (this=0x562392954560) at 
kernel/qtimerinfo_unix.cpp:643
 #19 0x7fe16760c404  | 0x7f180b4a9404 
in timerSourceDispatch (source=) at 
kernel/qeventdispatcher_glib.cpp:182
 #20 0x7fe166ab9f2e g_main_context_dispatch   | 0x7f180a956f2e 
in g_main_dispatch (context=0x7f17f8004ff0) at ../../../glib/gmain.c:3182
  | 0x7f180a956f2e 
in g_main_context_dispatch (context=context@entry=0x7f17f8004ff0) at 
../../../glib/gmain.c:3847
 #21 0x7fe166aba1c8  | 0x7f180a9571c8 
in g_main_context_iterate 

Bug#946488: RM: magicor -- RoQA; depends on pygtk2, dead upstream, unmaintained

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove magicor. It's dead upstream and depends on pygtk2, which is going 
away and
hasn't seen an upload in over eight years.

Cheers,
Moritz

Bug#946487: libgomp-plugin-nvptx1: please suggest libcuda1 | libcuda1-any

[Andreas Beckmann]

Package: libgomp-plugin-nvptx1
Version: 9.2.1-21
Severity: normal

Hi,

libgomp-plugin-nvptx1 currently comes with 
  Suggests: libcuda1
Please update that to
  Suggests: libcuda1 | libcuda1-any
to include the virtual package provided by all libcuda1 variants in
non-free.
Or if you prefer to have an existing real package as first
alternative on ppc64el use
  Suggests: libcuda1 [amd64] | libnvidia-tesla-cuda1 [amd64 ppc64el] | 
libcuda1-any
Let this change propagate to gcc-10 in experimental, too.

Thanks

Andreas

PS: in sid/amd64
Package libcuda1-any is a virtual package provided by:
  libnvidia-tesla-cuda1 418.87.01-2
  libnvidia-legacy-390xx-cuda1 390.132-1
  libnvidia-legacy-340xx-cuda1 340.107-7
  libnvidia-legacy-304xx-cuda1 304.137-7
  libcuda1 430.64-1

Bug#946486: [kbibtex] Wrong field ending leads to file corruption when using biblatex

[Antonio Marcos López Alonso]

Package: kbibtex
Version: 0.8.1-1+b1
kbibtex misplaces double-quotation ending in title and subtitle fields when 
filling them 
after selecting BibLaTeX as bibliography system (I haven't tried others 
though). Steps:

1) Setup kbibtex to use BibLaTex.
2) Create a "New element": journal article, whatever.
3) Fill either Title or Subtitle boxes.
4) Change to Source tab and see how ending double quotes are misplaced leading 
to a 
corrupt biblatex file:
title = "{My long title"} instead of title = "{My long title}"

This causes biblatex file corruption when keeping on filling fields in other 
tabs' boxes (you 
can track this inspecting Source tab as you enter new data). A workaround is to 
manually 
correct the ending in Source tab and then entering data should behave the right 
way, at 
least until you create another "New element".

Regards,
Antonio

Bug#946484: internetarchive: DistributionNotFound: The 'backports.csv' distribution was not found

[Antoine Beaupré]

On 2019-12-09 22:51:16, Jakub Wilk wrote:
> Package: internetarchive
> Version: 1.8.5-1
> Severity: grave
>
> The ia command doesn't work at all:
>
>$ ia help
>Traceback (most recent call last):
>  File "/usr/bin/ia", line 6, in 
>from pkg_resources import load_entry_point
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3250, in 
>@_call_aside
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3234, in _call_aside
>f(*args, **kwargs)
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3263, in _initialize_master_working_set
>working_set = WorkingSet._build_master()
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 583, in _build_master
>ws.require(__requires__)
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 900, in require
>needed = self.resolve(parse_requirements(requirements))
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 786, in resolve
>raise DistributionNotFound(req, requirers)
>pkg_resources.DistributionNotFound: The 'backports.csv' distribution was 
> not found and is required by internetarchive

This is strange. The requirements seem to be wrong:

'backports.csv < 1.07;python_version<"2.7"',
'backports.csv < 1.07;python_version<"3.4"',
'backports.csv;python_version>="2.7"',
'backports.csv;python_version>="3.4"',

the latter two lines say we need the backport in python 3.4 and above,
which is non-sensical: we *don't* need the backport then...

I'll see what i can do.

a.

-- 
It will be a great day when our schools get all the money they need
and the air force has to hold a bake sale to buy a bomber.
- Unknown

Bug#946485: kbibtex: misplaced ending double-quotes when creating biblatex records

[Antonio Marcos López Alonso]

Package: kbibtex
Version: 0.8.1-1+b1
Severity: normal

Dear maintainer:

kbibtex misplaces double-quotation ending in title and subtitle fields when
filling them after selecting BibLaTeX as bibliography system (I haven't tried
others though). Steps:

1) Setup kbibtex to use BibLaTex.
2) Create a "New element": journal article, whatever.
3) Fill either Title or Subtitle boxes.
4) Change to Source tab and see how ending double quotes are misplaced leading
to a corrupt biblatex file:
title = "{My long title"} instead of title = "{My long title}"

This causes biblatex file corruption when keeping on filling fields in other
tabs' boxes (you can track this inspecting Source tab as you enter new data). A
workaround is to manually correct the ending in Source tab and then entering
data should behave the right way, at least until you create another "New
element".

Regards,
Antonio



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

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

Versions of packages kbibtex depends on:
ii  kbibtex-data   0.8.1-1
ii  kio5.54.1-1
ii  libc6  2.28-10
ii  libicu63   63.1-6
ii  libkf5completion5  5.54.0-1
ii  libkf5configcore5  5.54.0-1+deb10u1
ii  libkf5configgui5   5.54.0-1+deb10u1
ii  libkf5configwidgets5   5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5iconthemes5  5.54.0-1
ii  libkf5itemviews5   5.54.0-1
ii  libkf5jobwidgets5  5.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5parts5   5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libkf5textwidgets5 5.54.0-1
ii  libkf5widgetsaddons5   5.54.0-1
ii  libkf5xmlgui5  5.54.0-1
ii  libpoppler-qt5-1   0.71.0-5
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u1
ii  libqt5dbus55.11.3+dfsg1-1+deb10u1
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u1
ii  libqt5network5 5.11.3+dfsg1-1+deb10u1
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u1
ii  libqt5xml5 5.11.3+dfsg1-1+deb10u1
ii  libqt5xmlpatterns5 5.11.3-2
ii  libstdc++6 8.3.0-6

Versions of packages kbibtex recommends:
ii  biber 2.12-2
ii  texlive-bibtex-extra  2018.20190227-2

Versions of packages kbibtex suggests:
ii  bibtex2html 1.99-2
ii  latex2rtf   2.3.16-1
ii  texlive-latex-base  2018.20190227-2

-- no debconf information

Bug#946482: hwloc-contrib: support building for ppc64el

[Samuel Thibault]

Hello,

Andreas Beckmann, le lun. 09 déc. 2019 22:23:06 +0100, a ecrit:
> please enable building hwloc-contrib on ppc64el, too. With the packaged
> tesla drivers this could be useful for some people.
> Neither do I plan to upload ppc64el binaries (my ppc64el 'machine' is a
> qemu chroot) nor do I expect you to do that. But it would be nice to
> have the package ready for people that want to build them locally.

Ok.

> The libcuda1 dependency was only needed for ancient nvidia-cuda-dev.
> And it is unsatisfiable on ppc64el.

Right :)

> While thinking about it, libxnvctrl-dev and libxnvctrl0 are in main at
> least since jessie, so you could move these parts to the hwloc package
> in main, too. (Don't forget Breaks+Replaces ...)

Oh, right, that seems to be so since version 340.24-1.

> Given the special nature of the hwloc/hwloc-contrib source packages,
> the attached patch should only serve to give some ideas.

Actually contrib is just a branch in the same repository, so I could
just apply your patch :)

Thanks!
Samuel

Bug#895420:

[Aurélien COUDERC]

Le lundi 9 décembre 2019, 22:21:15 CET Aurélien COUDERC a écrit :
> Hi Vivek,

Please ignore my last email sent to the wrong bug number…


Happy hacking !
--
Aurélien

Bug#946484: internetarchive: DistributionNotFound: The 'backports.csv' distribution was not found

[Jakub Wilk]

Package: internetarchive
Version: 1.8.5-1
Severity: grave

The ia command doesn't work at all:

  $ ia help
  Traceback (most recent call last):
File "/usr/bin/ia", line 6, in 
  from pkg_resources import load_entry_point
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3250, in 

  @_call_aside
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3234, 
in _call_aside
  f(*args, **kwargs)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3263, 
in _initialize_master_working_set
  working_set = WorkingSet._build_master()
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 583, 
in _build_master
  ws.require(__requires__)
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 900, 
in require
  needed = self.resolve(parse_requirements(requirements))
File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 786, 
in resolve
  raise DistributionNotFound(req, requirers)
  pkg_resources.DistributionNotFound: The 'backports.csv' distribution was not 
found and is required by internetarchive


-- System Information:
Architecture: i386

Versions of packages internetarchive depends on:
ii  python3  3.7.5-3
ii  python3-internetarchive  1.8.5-1

--
Jakub Wilk

Bug#946483: python3-clint: SyntaxWarning: "is not" with a literal

[Jakub Wilk]

Package: python3-clint
Version: 0.5.1-2

I saw these warnings on installation:

  /usr/lib/python3/dist-packages/clint/eng.py:44: SyntaxWarning: "is not" with a literal. 
Did you mean "!="?
elif left is not 0:
  /usr/lib/python3/dist-packages/clint/textui/prompt.py:68: SyntaxWarning: "is not" with 
a literal. Did you mean "!="?
if prompt[-1] is not ' ':


-- System Information:
Architecture: i386

Versions of packages python3-clint depends on:
ii  python3-args  0.1.0-3
ii  python3   3.7.5-3

--
Jakub Wilk

Bug#894500: (no subject)

[Leandro Lucarella]

Hi Aurélien,

The problems with the panel seem to be fixed (I don't remember if I did 
something to fix it, like removing the configuration and re-creating the 
panels, that might have happened).

The WIN key still doesn't show the application menu now, but I'm using i3 
as WM, so it might be because of that. I don't remember how thing were 
when I switched.

If nobody else complained about this, I guess it can be closed, at least 
from my side I'm fine with it.

Thanks for following up!

-- 
Leandro Lucarella (Luca)
https://llucax.com

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

Bug#946433: jpylyzer: diff for NMU version 1.18.0-3.2

[Sandro Tosi]

Control: tags 946433 + patch


Dear maintainer,

I've prepared an NMU for jpylyzer (versioned as 1.18.0-3.2). The diff
is attached to this message.

Regards.

diff -Nru jpylyzer-1.18.0/debian/changelog jpylyzer-1.18.0/debian/changelog
--- jpylyzer-1.18.0/debian/changelog	2019-11-29 00:30:33.0 -0500
+++ jpylyzer-1.18.0/debian/changelog	2019-12-09 16:30:35.0 -0500
@@ -1,3 +1,10 @@
+jpylyzer (1.18.0-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add Breaks+Replaces: python-jpylyzer (<< 1.18.0-3.1); Closes: #946433
+
+ -- Sandro Tosi   Mon, 09 Dec 2019 16:30:35 -0500
+
 jpylyzer (1.18.0-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru jpylyzer-1.18.0/debian/control jpylyzer-1.18.0/debian/control
--- jpylyzer-1.18.0/debian/control	2019-11-29 00:27:15.0 -0500
+++ jpylyzer-1.18.0/debian/control	2019-12-09 16:30:03.0 -0500
@@ -31,6 +31,8 @@
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends}
 Suggests: pirl-image-tools
+Breaks: python-jpylyzer (<< 1.18.0-3.1)
+Replaces: python-jpylyzer (<< 1.18.0-3.1)
 Description: JP2 (JPEG 2000 Part 1) validator and properties extractor
  Validator and feature extractor for JP2 (JPEG 2000 Part 1 - ISO/IEC 15444-1)
  images. Jpylyzer was specifically created to check that a JP2 file really

Bug#946390: Proposed fix for dict-freedict-spa-deu

[Sebastian Humenda]

Hi Hannes

Thanks for your enthusiasm to fix this.

Hannes Müller schrieb am 09.12.2019, 21:03 +0100:
>I found related syntax problems in spa-deu/spa-deu.tei and fixed them
>with attached patch. The dictd file spa-deu.index now looks fine.

This patch still shows issues:
 
>+-  | modista
>++  |modista


It should be `modista`. Since it seems that spa-deu.tei is broken
anyway, it is probably better to fix its importer script. We import it from
the Ding format and the importer is currently in a rather bad shape. Any
chance you would like to look into it :)? We could still patch it downstream,
but I feel this is not the best solution.

>I also scanned all other dictionaries for the same problem but found no
>other candidates. I try to provide also a related upstream patch.

Thanks for this.

Sebastian


signature.asc
Description: PGP signature

Bug#919218: non-transition: libqt5gui5-gles

[Graham Inggs]

Hi Dmitry

On Sun, 1 Dec 2019 at 10:35, Dmitry Shachnev  wrote:
> That is because after rebuild /usr/games/2048-qt is no longer linked against
> libQt5Gui.so.5 at all.
...
> So it is probably a side-effect of build system changes in Qt 5.12. Now it
> passes the path to library (e.g. /usr/lib/x86_64-linux-gnu/libQt5Gui.so)
> instead of -lQt5Gui, so the linker ignores that if the library is unused.

My guess is gcc 9 defaulting to linking with --as-needed.
For the record, I binNMU'd 2048-qt on armel and armhf as well to drop
the dependency.
It was the only package I saw like this.

On Mon, 9 Dec 2019 at 22:49, Dmitry Shachnev  wrote:
> Thanks a lot for doing the binNMUs!

You are welcome!

> Now the tracker is mostly green, and I think no further binNMUs are needed.

If I missed something, or if something needs to be given back, please
let me know.
There were a number of FTBFS, I haven't been through them yet to see
which need bugs filed.  Is this something you plan to do?

I don't know the answers to your questions below, hopefully someone else does!

Regards
Graham


> However I have a question: package libqt5quick5 currently has Depends:
> libqt5gui5 (>= 5.1.0), libqt5gui5 (>= 5.12.5) | libqt5gui5-gles (>= 5.12.5)
>
> The tracker currently marks src:qtdeclarative-opensource-src which contains
> that package as good. However, this means that the package can *not* be
> installed with libqt5gui5-gles, because the first dependency does not allow
> it. Do you know if there is a way to express the following in ben:
>
> “All dependencies on libqt5gui5 should have an alternative dependency of
> libqt5gui5-gles”?
>
> I can get what I want with grep-dctrl [1], but if there was a way to have the
> same on transition tracker, it would be better. Also, maybe there is a way
> to ignore armel/armhf?
>
> If there is no such way, I think we can close this bug and the tracker too.

Bug#946482: hwloc-contrib: support building for ppc64el

[Andreas Beckmann]

Source: hwloc-contrib
Version: 2.1.0+dfsg-2
Severity: wishlist

Hi Samuel,

please enable building hwloc-contrib on ppc64el, too. With the packaged
tesla drivers this could be useful for some people.
Neither do I plan to upload ppc64el binaries (my ppc64el 'machine' is a
qemu chroot) nor do I expect you to do that. But it would be nice to
have the package ready for people that want to build them locally.

The libcuda1 dependency was only needed for ancient nvidia-cuda-dev.
And it is unsatisfiable on ppc64el.

While thinking about it, libxnvctrl-dev and libxnvctrl0 are in main at
least since jessie, so you could move these parts to the hwloc package
in main, too. (Don't forget Breaks+Replaces ...)

Given the special nature of the hwloc/hwloc-contrib source packages,
the attached patch should only serve to give some ideas.

Andreas
diff -Nru hwloc-contrib-2.1.0+dfsg/debian/changelog 
hwloc-contrib-2.1.0+dfsg/debian/changelog
--- hwloc-contrib-2.1.0+dfsg/debian/changelog   2019-11-26 14:27:34.0 
+0100
+++ hwloc-contrib-2.1.0+dfsg/debian/changelog   2019-12-09 17:52:19.0 
+0100
@@ -1,3 +1,9 @@
+hwloc-contrib (2.1.0+dfsg-3) UNRELEASED; urgency=medium
+
+  * hwloc-contrib can be built on ppc64el, too.
+
+ -- Andreas Beckmann   Mon, 09 Dec 2019 17:52:19 +0100
+
 hwloc-contrib (2.1.0+dfsg-2) unstable; urgency=medium
 
   * Upload to unstable.
diff -Nru hwloc-contrib-2.1.0+dfsg/debian/control 
hwloc-contrib-2.1.0+dfsg/debian/control
--- hwloc-contrib-2.1.0+dfsg/debian/control 2019-11-26 14:27:34.0 
+0100
+++ hwloc-contrib-2.1.0+dfsg/debian/control 2019-12-09 17:52:19.0 
+0100
@@ -3,7 +3,7 @@
 Maintainer: Samuel Thibault 
 Build-Depends: debhelper (>= 9), libltdl-dev,
   valgrind [amd64 arm64 armhf i386 mips mipsel powerpc ppc64el s390x mips64el 
ppc64],
-  libx11-dev, libxext-dev, nvidia-cuda-dev, libcuda1, libxnvctrl-dev,
+  libx11-dev, libxext-dev, nvidia-cuda-dev, libxnvctrl-dev,
   libpciaccess-dev, libudev-dev [linux-any], pkg-config,
   libibverbs-dev [linux-any],
   ocl-icd-opencl-dev [!hurd-i386] | opencl-dev, opencl-headers,
@@ -18,7 +18,7 @@
 Vcs-Browser: https://github.com/open-mpi/hwloc-debian/tree/contrib
 
 Package: libhwloc-contrib-plugins
-Architecture: amd64
+Architecture: amd64 ppc64el
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, libhwloc15 (>= 
${source:Upstream-Version}~), libhwloc15 (<< ${source:Upstream-Version}A)
 Description: Hierarchical view of the machine - contrib plugins

Bug#946347: Thunderbird: After dist-upgrade thunderbird thinks it is too old.

[Carsten Schoenert]

Control: severity -1 normal

Hello Robert,

On Sat, Dec 07, 2019 at 05:25:22PM +0100, Robert Pommrich wrote:
> After a dist-upgrade from stretch to buster with thunderbird installed
> in version 68.2.2-1~deb9u1 and being upgraded to version
> 68.2.2-1~deb10u1 thunderbird shows a message at the start:
> 
> "A newer version of Thunderbird may have made changes to your profile which 
> are no longer
> compatible with this older version.
> Use this profile only with that newer version, or create a new profile for 
> this installation of
> Thunderbird. Creating a new profile requires setting up your accounts, 
> calendars and add-ond again."
> 
> This is strange and should not happen, as the version of Thunderbird
> is practically the same.

this usaly happen if users have used some pre-built version from
Mozilla. Seeing this message isn't something you can blame the
Thunderbird package from Debian as you have used non packaged software
on your own.

https://support.mozilla.org/en-US/kb/unable-launch-older-version-profile

Please adjust your local profile settings by reading the ressource I've
linked above.

Regards
Carsten

Bug#945618:

[thomasw]

I did some more testing on this bug this afternoon because I discovered that 
powertop can generate an HTML report that I can view after assistive tech is 
re-enabled. What I found is that for some reason, speech dispatcher is 
preventing the package from entering low power savings like pc2 through pc10 
after this commit. If aI disable Orca speech and then run killall 
/usr/bin/speech-dispatcher, the low power package states start working again. 
If I just disable Orca speech, the package states do not work. If I run VLC 
playing music with speech dispatcher not running, the package states work so it 
doesn't appear to be an issue caused by all apps playing through pulse.

Bug#919218: non-transition: libqt5gui5-gles

[Dmitry Shachnev]

Hi Graham and all,

On Sun, Dec 01, 2019 at 09:27:58AM +0200, Graham Inggs wrote:
> I started with a binNMU of 2048-qt [1] on its own.
>
> It didn't have the effect on the tracker that I was expecting [2].
> Would you please check the binaries and let me know if I should
> continue with the rest?
>
> Does the tracker need some adjustment?

Thanks a lot for doing the binNMUs!

Now the tracker is mostly green, and I think no further binNMUs are needed.

However I have a question: package libqt5quick5 currently has Depends:
libqt5gui5 (>= 5.1.0), libqt5gui5 (>= 5.12.5) | libqt5gui5-gles (>= 5.12.5)

The tracker currently marks src:qtdeclarative-opensource-src which contains
that package as good. However, this means that the package can *not* be
installed with libqt5gui5-gles, because the first dependency does not allow
it. Do you know if there is a way to express the following in ben:

“All dependencies on libqt5gui5 should have an alternative dependency of
libqt5gui5-gles”?

I can get what I want with grep-dctrl [1], but if there was a way to have the
same on transition tracker, it would be better. Also, maybe there is a way
to ignore armel/armhf?

If there is no such way, I think we can close this bug and the tracker too.

[1]: grep-dctrl -n -sPackage -FDepends -e 'libqt5gui5[[:space:]]*(\(>= 
5\.[0-9.]*\))?,' \
 
/var/lib/apt/lists/deb.debian.org_debian_dists_sid_main_binary-amd64_Packages
 (based on https://lists.debian.org/debian-arm/2018/11/msg00115.html)

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#922246: www/lts: if DLA-1234-1 and DLA-1234-2 exist, only that last one shows up in indexes

[Brian May]

Holger Levsen  writes:

> awesome, merged, thank you! Do you think we can close this bug now?

Fine with me...
-- 
Brian May 

Bug#946481: ipython_5.8.0 and python-3.8 cause TypeError

[Anton Gladky]

Package: ipython
Version: 5.8.0-1
Severity: important
Tags: upstream patch

Dear Maintainer,

ipython is used by yade package as an interactive python frontend.

In the current sid Yade is partly used in inetractive mode.

yade:
===

In [1]: O.dt=1e-4
---
TypeError Traceback (most recent call last)
/usr/lib/python3.8/codeop.py in __call__(self, source, filename, symbol)
131
132 def __call__(self, source, filename, symbol):
--> 133 codeob = compile(source, filename, symbol, self.flags, 1)
134 for feature in _features:
135 if codeob.co_flags & feature.compiler_flag:

TypeError: required field "type_ignores" missing from Module
===

The bug is known and fixed by upstream in the newer versions [1], [2].

The minimal patch, which fixes at least the Yade issue is attached.

Please consider appplying it.


[1] https://github.com/ipython/ipython/issues/11590
[2] https://github.com/ipython/ipython/pull/11593


Thank you

Anton
diff --git a/debian/patches/03_fix_python3.8.patch 
b/debian/patches/03_fix_python3.8.patch
new file mode 100644
index 000..25face6
--- /dev/null
+++ b/debian/patches/03_fix_python3.8.patch
@@ -0,0 +1,16 @@
+Description: Fixes TypeError due to python3.8
+Author: Anton Gladky 
+Upstream: https://github.com/ipython/ipython/issues/11590
+Last-Update: 2019-12-09
+
+--- ipython-5.8.0.orig/IPython/core/interactiveshell.py
 ipython-5.8.0/IPython/core/interactiveshell.py
+@@ -2813,7 +2813,7 @@ class InteractiveShell(SingletonConfigur
+ 
+ try:
+ for i, node in enumerate(to_run_exec):
+-mod = ast.Module([node])
++mod = ast.Module([node], [])
+ code = compiler(mod, cell_name, "exec")
+ if self.run_code(code, result):
+ return True
diff --git a/debian/patches/series b/debian/patches/series
index 0ca629c..232ad59 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-use-setuptools-also-for-the-install-target-so-the-py.patch
 0002-Update-intersphinx-links-for-local-access.patch
+03_fix_python3.8.patch

Bug#946480: lxc: non-root user cannot start a container under cgroupv2 / unified hierarchy

[Ryutaroh Matsumoto]

Package: lxc
Version: 1:3.1.0+really3.0.4-2
Severity: important
Tags: upstream
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: cgroupv2

Control: forwarded -1 https://github.com/lxc/lxc/issues/3221
Control: block 943981 by -1

Dear Maintainer,

Exactly the same as reported by a Fedora 31 user at
https://github.com/lxc/lxc/issues/3221

I believe that this is not a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888647
because libpam-cgfs can do nothing useful under cgroupv2 / unified hierarchy
as discussed at https://github.com/lxc/lxc/issues/3198

Best regards, Ryutaroh

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

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.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 lxc depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.29-2
ii  libgcc11:8.3.0-6
ii  liblxc11:3.1.0+really3.0.4-2
ii  lsb-base   10.2019051400

Versions of packages lxc recommends:
ii  apparmor 2.13.2-10
pn  bridge-utils 
ii  debootstrap  1.0.114
ii  dirmngr  2.2.12-1+deb10u1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  gnupg2.2.12-1+deb10u1
ii  iproute2 4.20.0-2
ii  iptables 1.8.2-4
pn  libpam-cgfs  
pn  lxc-templates
pn  lxcfs
ii  openssl  1.1.1d-0+deb10u1
ii  rsync3.1.3-6
pn  uidmap   

Versions of packages lxc suggests:
ii  btrfs-progs  4.20.1-2
ii  lvm2 2.03.02-3
pn  python3-lxc  

-- debconf information:
  lxc/auto_update_config:

Bug#946479: wiki.debian.org: Unable to reach the "Compatibility List" page from "DebianAMD64"

[Julien-Benjamin]

Package: wiki.debian.org
Severity: normal

Dear Maintainer,

I tried to display the "Compability List" from wiki.debian.org/DebianAMD64,
which led up to an error message:
"
This site can’t be reached.
https://alioth.debian.org/docman/view.php/30192/27/mainboards.html is 
unreachable.
ERR_ADDRESS_UNREACHABLE
" 

Cheers,

JB

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

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

Bug#946478: libvorbis: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libvorbis
Version: 1.3.6-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.

One of the libvorbis tests currently fails in this environment, because it
is a build test that does not invoke the toolchain in a cross-aware manner. 
In addition, all of the tests have a test dependency on pysycache-i18n,
which is an architecture: all package that is not marked Multi-Arch: foreign
which means this dependency can't be satisfied as-is.  However, by tagging
this test dep with :native, the dependency can be satisfied for both
same-arch and cross-arch testing.

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 libvorbis-1.3.6/debian/tests/control 
libvorbis-1.3.6/debian/tests/control
--- libvorbis-1.3.6/debian/tests/control2019-02-24 11:33:46.0 
-0800
+++ libvorbis-1.3.6/debian/tests/control2019-12-09 11:45:30.0 
-0800
@@ -1,2 +1,2 @@
-Depends: @, vorbis-tools, build-essential, pysycache-i18n, sound-icons, 
valgrind
+Depends: @, vorbis-tools, build-essential, pysycache-i18n:native, sound-icons, 
valgrind
 Tests: test-examples test-coupling-segfault
diff -Nru libvorbis-1.3.6/debian/tests/test-examples 
libvorbis-1.3.6/debian/tests/test-examples
--- libvorbis-1.3.6/debian/tests/test-examples  2019-02-25 13:02:32.0 
-0800
+++ libvorbis-1.3.6/debian/tests/test-examples  2019-12-09 12:07:09.0 
-0800
@@ -7,7 +7,11 @@
 
 set -e
 
-CC=gcc
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CC="$DEB_HOST_GNU_TYPE-gcc"
+else
+CC=gcc
+fi
 
 retval=0
 cd $AUTOPKGTEST_TMP

Bug#946415: [Pkg-rust-maintainers] Bug#946415: rust-cargo Build-Depends on librust-crates-io-0.25+default-dev which doesn't exist

[Sylvestre Ledru]

Paul, I do find this bugs valuable on my side. Thanks for filling them!

Sylvestre


Le 09/12/2019 à 00:30, Ximin Luo a écrit :

Hi,

This type of bug is a natural artifact of the way rust crates are structured 
and updated, and the Rust team is continually aware of these types of bugs. 
There is no need to file these types of bugs for packages in unstable as the 
testing migration script will prevent migrations anyway, rendering a RC bug 
report unbeneficial and contributing to more paperwork for the packaging team.

Best,
Ximin

Paul Gevers:

Source: rust-cargo
Version: 0.37.0-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: ftbfs

Dear maintainers,

Your package Build-Depends on librust-crates-io-0.25+default-dev but that
package doesn't exist.

Paul

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

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

Bug#946477: povray FTCBFS: uses AC_RUN_IFELSE

[Helmut Grohne]

Source: povray
Version: 1:3.7.0.8-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

povray fails to cross build from source, because it uses AC_RUN_IFELSE
in a few places. Getting rid of these isn't obvious. It's used for
different things:
 * Checking whether boost thread works. -> AC_LINK_IFELSE suffices here.
 * Determining versions of libraries. -> AC_COMPUTE_INT often works.
 * Determining version of libtiff. -> We can opportunistically use
   PKG_CHECK_MODULES and fall back to the old check on failure.

Together these changes make povray cross buildable. We're not the first
ones attempting to do so. OpenEmbedded has tried earlier:
https://github.com/openembedded/openembedded/blob/master/recipes/povray/povray-3.6.1%2B3.7.0-beta25b/configure-cross-hack.patch
Their patch is not suitable for upstream inclusion, but I think this one
is. Please consider applying it. Doing so would help other distributions
as well.

Helmut
--- povray-3.7.0.8.orig/unix/configure.ac
+++ povray-3.7.0.8/unix/configure.ac
@@ -60,7 +60,6 @@
 m4_include([unix/config/ax_boost_base.m4])
 m4_include([unix/config/ax_boost_thread.m4])
 m4_include([unix/config/ax_test_compiler_flags.m4])
-m4_include([unix/config/ax_check_lib.m4])
 m4_include([unix/config/ax_check_libjpeg.m4])
 m4_include([unix/config/ax_check_libsdl.m4])
 m4_include([unix/config/ax_check_libtiff.m4])
@@ -314,7 +313,7 @@
 do
   LIBS=$SAVED_LIBS
   LIBS="$LIBS $extralib"
-  AC_RUN_IFELSE([
+  AC_LINK_IFELSE([
 AC_LANG_PROGRAM([[
   #include 
 ]],[[
@@ -326,9 +325,7 @@
 AC_MSG_RESULT([yes])
 BOOST_THREAD_LIB="$BOOST_THREAD_LIB $extralib"
 boost_thread_links=1
-  ],,[
-AC_MSG_RESULT([cross-compiling])  # FIXME
-  ])
+  ],)
   if test $boost_thread_links = '1'; then
 break
   fi
@@ -363,7 +360,20 @@
 AC_MSG_ERROR([disabling support for ZLIB requires NON_REDISTRIBUTABLE_BUILD=yes])
   fi
   AC_MSG_RESULT([yes])
-  AX_CHECK_LIB([z], [$required_libz_version], [z], [zlibVersion], [zlib.h], [zlibVersion()], [$with_zlib])
+  if test x"$with_zlib" != x; then
+CPPFLAGS="-I$with_zlib/../include $CPPFLAGS"
+LDFLAGS="-L$with_zlib $LDFLAGS"
+  fi
+  AC_SEARCH_LIBS([deflate],[z],[
+AC_CHECK_HEADER([zlib.h],[
+  AC_MSG_CHECKING([for libz version >= $required_libz_version])
+  AC_COMPUTE_INT([ZLIB_VER_MAJOR],[ZLIB_VER_MAJOR],[#include ])
+  AC_COMPUTE_INT([ZLIB_VER_MINOR],[ZLIB_VER_MINOR],[#include ])
+  AC_COMPUTE_INT([ZLIB_VER_REVISION],[ZLIB_VER_REVISION],[#include ])
+  AX_COMPARE_VERSION([$ZLIB_VER_MAJOR.$ZLIB_VER_MINOR.$ZLIB_VER_REVISION],[ge],[$required_libz_version],[ax_check_lib=ok],[ax_check_lib=bad])
+  AC_MSG_RESULT([$ZLIB_VER_MAJOR.$ZLIB_VER_MINOR.$ZLIB_VER_REVISION, $ax_check_lib])
+],[ax_check_lib="no headers"])
+  ],[ax_check_lib="not found"])
   if test x"$ax_check_lib" != x"ok"; then
 AC_MSG_ERROR([cannot find a suitable ZLIB library])
   else
@@ -382,7 +392,20 @@
 AC_MSG_ERROR([disabling support for PNG requires NON_REDISTRIBUTABLE_BUILD=yes])
   fi
   AC_MSG_RESULT([yes])
-  AX_CHECK_LIB([png], [$required_libpng_version], [png14 png png12 png], [png_get_libpng_ver], [png.h], [png_get_libpng_ver(NULL)], [$with_libpng])
+  if test x"$with_libpng" != x; then
+CPPFLAGS="-I$with_libpng/../include $CPPFLAGS"
+LDFLAGS="-L$with_libpng $LDFLAGS"
+  fi
+  AC_SEARCH_LIBS([png_get_libpng_ver],[png14 png png12 png],[
+AC_CHECK_HEADER([png.h],[
+  AC_MSG_CHECKING([for libpng version >= $required_libpng_version])
+  AC_COMPUTE_INT([PNG_LIBPNG_VER_MAJOR],[PNG_LIBPNG_VER_MAJOR],[#include ])
+  AC_COMPUTE_INT([PNG_LIBPNG_VER_MINOR],[PNG_LIBPNG_VER_MINOR],[#include ])
+  AC_COMPUTE_INT([PNG_LIBPNG_VER_RELEASE],[PNG_LIBPNG_VER_RELEASE],[#include ])
+  AX_COMPARE_VERSION([$PNG_LIBPNG_VER_MAJOR.$PNG_LIBPNG_VER_MINOR.$PNG_LIBPNG_VER_RELEASE],[ge],[$required_libpng_version],[ax_check_lib=ok],[$ax_check_lib=bad])
+  AC_MSG_RESULT([$PNG_LIBPNG_VER_MAJOR.$PNG_LIBPNG_VER_MINOR.$PNG_LIBPNG_VER_RELEASE, $ax_check_lib])
+],[ax_check_lib="no headers"])
+  ],[ax_check_lib="not found"])
   ### FIXME: do not allow for 1.4.x
 	# This doesn't appear to be needed now that we're allowing 1.4 (jh)
   # AC_MSG_CHECKING([for libpng version < 1.4 (not supported at the moment!)])
--- povray-3.7.0.8.orig/unix/config/ax_check_lib.m4
+++ /dev/null
@@ -1,79 +0,0 @@
-# SYNOPSIS
-#
-#   AX_CHECK_LIB(lib, required_version, search_libs, check_function, header, version_function, lib_dir)
-#
-# DESCRIPTION
-#
-#   Check whether a function is found in a set of libraries and compare
-#   the library version to the required one.
-#
-# LAST MODIFICATION
-#
-#   2007-11-08
-#
-# COPYLEFT
-#
-#   Copyright (c) 2006 Nicolas Calimet
-#
-#   Copying and distribution of this file, with or without
-#   modification, are permitted in any medium without royalty provided
-#   the copyright notice and this notice are preserved.
-
-AC_DEFUN([AX_CHECK_LIB],
-[
-  

Bug#946390: Proposed fix for dict-freedict-spa-deu

[Hannes Müller]

Dear Maintainer,

I found related syntax problems in spa-deu/spa-deu.tei and fixed them
with attached patch. The dictd file spa-deu.index now looks fine.

I also scanned all other dictionaries for the same problem but found no
other candidates. I try to provide also a related upstream patch.

Best regards
Hannes
diff -Nru freedict-2018.10.21/debian/changelog freedict-2018.10.21/debian/changelog
--- freedict-2018.10.21/debian/changelog	2019-01-31 13:18:32.0 +0100
+++ freedict-2018.10.21/debian/changelog	2019-12-09 19:42:27.0 +0100
@@ -1,3 +1,11 @@
+freedict (2018.10.21-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix syntax errors in spa-deu/spa-deu.tei which caused incorrect
+entries in dictd file spa-deu.index 
+
+ -- Hannes Müller   Mon, 09 Dec 2019 19:42:27 +0100
+
 freedict (2018.10.21-3) unstable; urgency=medium
 
   * fixing FTBFS by import upstream fixes
diff -Nru freedict-2018.10.21/debian/patches/fix-spa-deu-tei-syntax.patch freedict-2018.10.21/debian/patches/fix-spa-deu-tei-syntax.patch
--- freedict-2018.10.21/debian/patches/fix-spa-deu-tei-syntax.patch	1970-01-01 01:00:00.0 +0100
+++ freedict-2018.10.21/debian/patches/fix-spa-deu-tei-syntax.patch	2019-12-09 19:42:27.0 +0100
@@ -0,0 +1,137 @@
+Index: freedict-2018.10.21/spa-deu/spa-deu.tei
+===
+--- freedict-2018.10.21.orig/spa-deu/spa-deu.tei
 freedict-2018.10.21/spa-deu/spa-deu.tei
+@@ -236869,7 +236869,7 @@
+   
+ 
+   modisto
+-  | modista
++  |modista
+   
+ n
+ f
+@@ -238187,7 +238187,7 @@
+   
+ 
+   monitor
+-  | monitora
++  |monitora
+   
+ n
+ f
+@@ -240077,7 +240077,7 @@
+   
+ 
+   mortal
+-  | mortal
++  |mortal
+   
+ n
+ f
+@@ -241002,7 +241002,7 @@
+   
+ 
+   mozo
+-  | moza
++  |moza
+   
+ n
+ f
+@@ -241024,7 +241024,7 @@
+   
+ 
+   mozo
+-  | moza
++  |moza
+   
+ n
+ f
+@@ -242785,7 +242785,7 @@
+   
+ 
+   musulmán
+-  | musulmana
++  |musulmana
+   
+ n
+ f
+@@ -248738,7 +248738,7 @@
+   
+ 
+   notario
+-  | notaria
++  |notaria
+   
+ n
+ f
+@@ -251861,7 +251861,7 @@
+   
+ 
+   observador
+-  | observadora
++  |observadora
+   
+ n
+ f
+@@ -261575,7 +261575,7 @@
+   
+ 
+   paco
+-  | paca
++  |paca
+   Chile
+   coloq.
+   
+@@ -268810,7 +268810,7 @@
+   
+ 
+   pasajero
+-  | pasajera
++  |pasajera
+   
+ n
+ f
+@@ -270198,7 +270198,7 @@
+   
+ 
+   pastelero
+-  | pastelera
++  |pastelera
+   
+ n
+ f
+@@ -281250,15 +281250,6 @@
+ aber
+   
+ 
+-  
+-  
+-
+-  pero
+-  .
+-  
+-conj
+-  
+-
+ 
+   
+ sondern
+@@ -306970,7 +306961,7 @@
+   
+ 
+   progenitor
+-  | progenitora
++  |progenitora
+   
+ n
+ f
+@@ -306992,7 +306983,7 @@
+   
+ 
+   progenitor
+-  | progenitora
++  |progenitora
+   
+ n
+ f
diff -Nru freedict-2018.10.21/debian/patches/series freedict-2018.10.21/debian/patches/series
--- freedict-2018.10.21/debian/patches/series	2018-10-22 13:51:03.0 +0200
+++ freedict-2018.10.21/debian/patches/series	2019-12-09 19:42:27.0 +0100
@@ -1 +1,2 @@
 show_that_xsltproc_is_active
+fix-spa-deu-tei-syntax.patch

Bug#945443: git-svn fails with "error: git-svn died of signal 11"

[Bernhard Übelacker]

Hello Christian,
if you still see this crash, maybe you could install the
package systemd-coredump.

If then a process crashes again some more information
should be visible at the end of:

journalctl --no-pager

Kind regards,
Bernhard

Bug#946476: debootstrap: Additional debootstrapable image (PureOS Amber) contributed as a merge request in salsa.

[Jeremiah C. Foster]

Package: debootstrap
Version: 1.0.116
Severity: wishlist
Tags: patch

Dear Maintainer,

In PureOS, a Free Software Foundation approved Free Software distro
based on Debian, we use a number of Debian tools. Few are more
important than debootstrap since we use that to build images for our
laptops and phone. If we could add our system definition to
debootstrap in the scripts directory, which this merge request does;
https://salsa.debian.org/installer-team/debootstrap/merge_requests/37
we would be most grateful.

Thank you!

-- System Information:
Distributor ID: PureOS
Description:PureOS
Release:10.0
Codename:   byzantium
Architecture: x86_64

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debootstrap depends on:
ii  wget  1.20.3-1+b2

Versions of packages debootstrap recommends:
ii  arch-test   0.16-2
ii  gnupg   2.2.17-3
ii  pureos-archive-keyring  2016.09

Versions of packages debootstrap suggests:
pn  squid-deb-proxy-client  
pn  ubuntu-archive-keyring  

-- no debconf information

Bug#946470: libreoffice-l10n-de: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

On 09/12/2019 18.37, Rene Engelhard wrote:
> Either asap or next week when rc1 will be there (but either way will be NEW 
> given the previous versions
> are still waiting in NEW since mid-November...)

No need to hurry ... as long as it is fixed once these packages go to sid.

Andreas

Bug#946345: proftpd-dfsg: CVE-2019-19269

[Salvatore Bonaccorso]

Hi Hilmar!

On Mon, Dec 09, 2019 at 08:20:27PM +0100, Hilmar Preuße wrote:
> Am 09.12.2019 um 14:58 teilte Salvatore Bonaccorso mit:
> > On Sun, Dec 08, 2019 at 11:52:31PM +0100, Hilmar Preuße wrote:
> 
> Hi,
> 
> >> Please find attached the debdiff patches for buster and stretch. I did
> >> not test the code at all (except that build runs OK), but the change
> >> seems to be rather trivial to me.
> > 
> > Thsese do not warrant a DSA. Could you fix those issues for an
> > upcoming point release for buster and stretch?
> > 
> 1. Are there instructions how to do that?

Yes, there are some indication on how to proceed here:

https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#special-case-uploads-to-the-stable-and-oldstable-distributions

> 2. Am I able to do that myself w/o being a DD?

Yes defintively, the whole process is doable without beeing a DD, and
if you have upload permissions for a package you then as well can do
an upload (without need of a sponsor).

Regards,
Salvatore

Bug#946415: rust-cargo Build-Depends on librust-crates-io-0.25+default-dev which doesn't exist

[Paul Gevers]

Hi Ximin,

On 09-12-2019 00:30, Ximin Luo wrote:
> This type of bug is a natural artifact of the way rust crates are
structured and updated, and the Rust team is continually aware of these
types of bugs. There is no need to file these types of bugs for packages
in unstable as the testing migration script will prevent migrations
anyway, rendering a RC bug report unbeneficial and contributing to more
paperwork for the packaging team.

I'm member of the release team. Can you please elaborate how this is
supposed to work, because rust is/was involved in several transitions
that I'd like to finish. Because I know rust is "weird", I was holding
off reporting this for quite some time, but in this case I am missing
progress. It's unclear to me how this is supposed to work. Also, are you
saying that the packages would build fine if rebuild in testing? Is this
package "provided" by some other package. Is there better tooling
available than inspecting the Binaries file on a mirror?

Paul

Bug#946345: proftpd-dfsg: CVE-2019-19269

[Hilmar Preuße]

Am 09.12.2019 um 14:58 teilte Salvatore Bonaccorso mit:
> On Sun, Dec 08, 2019 at 11:52:31PM +0100, Hilmar Preuße wrote:

Hi,

>> Please find attached the debdiff patches for buster and stretch. I did
>> not test the code at all (except that build runs OK), but the change
>> seems to be rather trivial to me.
> 
> Thsese do not warrant a DSA. Could you fix those issues for an
> upcoming point release for buster and stretch?
> 
1. Are there instructions how to do that?
2. Am I able to do that myself w/o being a DD?

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



signature.asc
Description: OpenPGP digital signature

Bug#929416: fixed

[sergio]

https://github.com/MaxKellermann/ferm/issues/47#event-2824278109

Fixed now. Please update.

-- 
sergio.

Bug#945489: closed by Sylvestre Ledru (Bug#945489: fixed in llvm-toolchain-9 1:9.0.1~+rc2-1~exp1)

[Sylvestre Ledru]

 Hello,

Le 09/12/2019 à 19:04, Lisandro Damián Nicanor Pérez Meyer a écrit :

Hy Sylvestre!

On 19/12/07 04:15, Debian Bug Tracking System wrote:
[snip]

Format: 1.8
Date: Tue, 03 Dec 2019 07:56:16 +0100
Source: llvm-toolchain-9
Architecture: source
Version: 1:9.0.1~+rc2-1~exp1
Distribution: experimental
Urgency: medium
Maintainer: LLVM Packaging Team 
Changed-By: Sylvestre Ledru 
Closes: 945489
Changes:
  llvm-toolchain-9 (1:9.0.1~+rc2-1~exp1) experimental; urgency=medium
  .
* New snapshot release
* Fix some paths, upstream moved from site-packages
  to dist-packages for python packages
* Move yaml-bench from libclang-common-X.Y-dev to llvm-X.Y-tools where
  it belongs
  See http://lists.llvm.org/pipermail/llvm-dev/2019-December/137337.html
* Add a project in the cmake-test to silent a warning
  (Closes: #945489)

This fix went into experimental and cmake has been stagnant in unstable for more
than 20 days already. Is there any chance to get the fix in unstable soon?
Should we ask the RT to ignore the failure? Maybe do a NMU?


Ignoring looks great.

This is just a warning without any impact

Cheers
S

Bug#946251: Tests are failing since postgresql-common 208

[Finzel, Jeremy]

Noted.  Thanks for the followup.

*Jeremy Finzel*

*Database Administrator Tech Lead*
*M* 630-777-4520





On Sun, Dec 8, 2019 at 6:37 AM Christoph Berg  wrote:

> Re: Sebastien Bacher 2019-12-06 <
> 18cb3ad6-93b1-7044-5edd-023c5ca0a...@debian.org>
> > Package: pglogical-ticker
> > Version: 1.4.0-1
> >
> > The tests are failing since postgresql-common got updated to 208
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ci.debian.net_packages_p_pglogical-2Dticker_unstable_amd64_=DwIBAg=lEzKI_JJakPtcnbAQ6Q5xQ=DqdWOTTF4YJBUfeNWvxJoag6GeBeW-A_9xfI4JO4szc=Ej7hrqzcFenwocJrfQXfEHdsw741gvKUxIY9xqdJsdo=LaUlTIr6CkErrisbvLFHYoQCM2gRcLv5wL1Dj0IFHu4=
> >
> > pg_buildext: error: /usr/lib/postgresql/11/bin/pg_config does not exist
>
> > It looks like the package also needs to be updated for postgresql 12?
>
> The test is failing because the Debian PostgreSQL environment has
> already moved to 12, but this package is still only available for 11,
> so some parts required to test it have already moved to 12.
>
> I'm working on moving pg_config into the dependency cone of
> the postgresql-XX server package so it would be present whenever
> something depending on postgresql-XX would be tested.
>
> The basic issue is that pglogical isn't available for PG12, though.
>
> Christoph
>

Bug#946142: dh-elpa: dh_missing does not know about files installed by dh_elpa

[Daniel Kahn Gillmor]

Control: tags 946142 + patch

On Wed 2019-12-04 03:21:19 -0500, Daniel Kahn Gillmor wrote:
> dh_elpa probably needs to follow the guidance mentioned in "Logging
> helpers and dh_missing" section from the "PROGRAMMING" guide for
> debhelper (10.6.3+).  (in the debhelper package:
> /usr/share/doc/debhelper/PROGRAMMING.gz)

I've sent a patch for this to this bug report, and it's also in salsa
here:

https://salsa.debian.org/emacsen-team/dh-elpa/merge_requests/2

It appears to work for me, but of course i won't complain if people with
more insight and/or skill want to improve it further.

Thanks for maintaining dh_elpa,

   --dkg


signature.asc
Description: PGP signature

Bug#946142: [PATCH] log files for visibility by dh_missing (Closes: #946142)

[Daniel Kahn Gillmor]

These changes are inspired by the recommendations in "Logging helpers
and dh_missing" in /usr/share/doc/debhelper/PROGRAMMING.gz, and
derived from the source of dh_installman and dh_installinfo.

(The weird extraction of the file list from @action is idiosyncratic
to dh_elpa, afaict)

Signed-off-by: Daniel Kahn Gillmor 
---
 dh_elpa | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/dh_elpa b/dh_elpa
index 0d3739d..982ac7b 100755
--- a/dh_elpa
+++ b/dh_elpa
@@ -210,10 +210,11 @@ if ($dh{BYTECOMPILE}) {
 }
 
 PACKAGE:
-foreach my $package (@{$dh{DOPACKAGES}}) {
+foreach my $package (getpackages()) {
 
   my $tmp=tmpdir($package);
   my $file=pkgfile($package,"elpa");
+  my $skip_install = process_pkg($package) ? 0 : 1;
 
   my $varname="ELPA_NAME_${package}";
   my $elpapkg = $ENV{$varname} || $ENV{ELPA_NAME};
@@ -265,7 +266,9 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 push @actions, map { {"src" => $_} } @ARGV;
   }
 
-  next PACKAGE if (scalar(@actions) == 0);
+  log_installed_files($package, map { @{$_->{src}} } @actions);
+
+  next PACKAGE if ($skip_install or (scalar(@actions) == 0));
 
   my $pkg_file;
   my $cwd = getcwd();
-- 
2.24.0

Bug#946475: systemd-networkd is crashing if SendOption is used

[Anthony Bourguignon]

Package: systemd
Version: 244-3
Severity: important
Tags: upstream

Dear Maintainer,

systemd-network added a new option in the 244 version : SendOption.
But currently, using it makes the daemon crash with a segfault. A bug
has been opened upstream :
https://github.com/systemd/systemd/issues/14283 . A PR is ready.

Can you please patch the debian package as it makes this new
feature unusable ?

Thanks

-- Package-specific info:

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

Kernel: Linux 5.3.0-3-amd64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.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 systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-5
ii  libapparmor1 2.13.3-7
ii  libaudit11:2.8.5-2+b1
ii  libblkid12.34-0.1
ii  libc62.29-5
ii  libcap2  1:2.27-1
ii  libcryptsetup12  2:2.2.2-1
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.10-5
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.4-1
ii  libkmod2 26-3
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.2-2
ii  libselinux1  2.9-3+b1
ii  libsystemd0  244-3
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.135
ii  udev 244-3

-- no debconf information

Bug#937727: RM python-enable

[Varun Hiremath]

reassign -1 src:python-enable
retitle -1 python-enable: convert package to Python 3
thanks

Hi Dmitry,

Yes, sorry for the delay but I have finally gotten some time to spend on my
Debian packages. Thanks to you and Scott for taking care of traits,
traitsui and pyface! I plan to work on enable and chaco and update them to
Python 3.

Regards,
Varun

On Mon, Dec 9, 2019 at 2:36 AM Dmitry Shachnev  wrote:

> Hi Varun!
>
> On Sun, Dec 08, 2019 at 10:35:51PM -0500, Scott Talbert wrote:
> > Control: reassign -1 ftp.debian.org
> > Control: retitle -1 RM: python-enable -- RoQA; unmaintained; low popcon;
> blocking py2 removal; no rdeps
>
> I see you started working on python-enable in Git [1]. If you want to
> prevent
> removal of this package, please reassign this bug back to
> src:python-enable.
>
> But the Python 3 package will have to go through the NEW queue anyway, no
> matter if the old package is removed or not.
>
> [1]:
> https://salsa.debian.org/python-team/modules/python-enable/commits/master
>
> --
> Dmitry Shachnev
>

Bug#909740: libsdl2-dev: No longer multi-arch co-installable

[Felix Geyer]

On 08.12.19 14:03, Hugh McMaster wrote:

After reviewing the four proposals, I too prefer the pkg-config solution to
the others. That said, your proposal using the Debian-specific header is
wonderfully simple.

In the longer term, I'm hoping there will be a push at some point to no
longer install sdl2-config, since that will simplify some of the issues
encountered here. Upstream have made it optional to install sdl2-config in
2.0.10.


On a second though I fear having the include files of libsdl2 and libsdl2-*
in different paths will break some build systems.

A random example I quickly found:
https://sources.debian.org/src/neverball/1.6.0+git20180603-2/Makefile/

It calls "sdl2-config --cflags" and then would fail to find SDL_ttf.h (from
the libsdl2-ttf-dev package) in /usr/include/SDL2.

One option would be to add -I/usr/include/SDL2 to sdl2-config or pkg-config
but I'm not sure if that would cover all cases.

Cheers,
Felix

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

[Samuel Thibault]

Hello,

dinar qurbanov, le lun. 09 déc. 2019 21:00:46 +0300, a ecrit:
> "Dinar, could you try the image from
> http://people.debian.org/~sthibault/tmp/mini.iso
> to see whether it helps? "
> 
> i have downloaded it but then become afraid , that malware may be
> there.

You are right to being cautious :)

But you can download through https with

https://people.debian.org/~sthibault/tmp/mini.iso

to make sure that it is coming from the people.debian.org domain,
which only Debian Developers like myself can put data on. And Debian
Developers can already upload anything to the Debian archive, see for
instance your /usr/share/doc/libc6/changelog.Debian.gz to see that you
are already using packages that I have uploaded to Debian. I have signed
this mail, for good measure.

> > "This bug report is unlikely to be actionable unless you specify
> > *exactly* which model of computer you are using.  There are literally
> > hundreds of different touchpad devices out there."
> 
> i was going to write exact laptop model, but i became afraid that this
> information can help somebody to infect my laptop's firmwares.

Not unless they have a way to actually reach your laptop.

> and seems that info is not useful to know out exact touchpad model.

It definitely is! Depending on the laptop brand and manufacture, making
the touchpad work will vary. On my XPS13, it is connected through i2c to
a PCI intel lpss card. On another laptop, exactly the same model of
touchpad could be connected another way, thus requiring another driver.

Samuel


signature.asc
Description: PGP signature

Bug#945489: closed by Sylvestre Ledru (Bug#945489: fixed in llvm-toolchain-9 1:9.0.1~+rc2-1~exp1)

[Lisandro Damián Nicanor Pérez Meyer]

Hy Sylvestre!

On 19/12/07 04:15, Debian Bug Tracking System wrote:
[snip]
> Format: 1.8
> Date: Tue, 03 Dec 2019 07:56:16 +0100
> Source: llvm-toolchain-9
> Architecture: source
> Version: 1:9.0.1~+rc2-1~exp1
> Distribution: experimental
> Urgency: medium
> Maintainer: LLVM Packaging Team 
> Changed-By: Sylvestre Ledru 
> Closes: 945489
> Changes:
>  llvm-toolchain-9 (1:9.0.1~+rc2-1~exp1) experimental; urgency=medium
>  .
>* New snapshot release
>* Fix some paths, upstream moved from site-packages
>  to dist-packages for python packages
>* Move yaml-bench from libclang-common-X.Y-dev to llvm-X.Y-tools where
>  it belongs
>  See http://lists.llvm.org/pipermail/llvm-dev/2019-December/137337.html
>* Add a project in the cmake-test to silent a warning
>  (Closes: #945489)

This fix went into experimental and cmake has been stagnant in unstable for more
than 20 days already. Is there any chance to get the fix in unstable soon?
Should we ask the RT to ignore the failure? Maybe do a NMU?

Thanks, Lisandro.

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

[dinar qurbanov]

"Dinar, could you try the image from
http://people.debian.org/~sthibault/tmp/mini.iso
to see whether it helps? "

i have downloaded it but then become afraid , that malware may be
there. (even if i remove hdd, firmware can be infected). maybe i
will/would do it, when/if i read some amount of information about you.

"This bug report is unlikely to be actionable unless you specify
*exactly* which model of computer you are using.  There are literally
hundreds of different touchpad devices out there."

i was going to write exact laptop model, but i became afraid that this
information can help somebody to infect my laptop's firmwares. and
seems that info is not useful to know out exact touchpad model.

Bug#946470: libreoffice-l10n-de: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Rene Engelhard]

Hi,

On Mon, Dec 09, 2019 at 05:20:49PM +0100, Andreas Beckmann wrote:
> This bug is present in several libreoffice-l10n-?? packages
> and libreoffice-help-common. Maybe also in more packages
> depending on these failing ones since they cannot be tested.

Nah, that script was just ran on -help-* and -l10n-*.

> >From the attached log (scroll to the bottom...):
> 
> 0m25.4s ERROR: FAIL: silently overwrites files via directory symlinks:
>   /usr/share/doc/libreoffice-l10n-de/changelog.Debian.gz 
> (libreoffice-l10n-de) != 
> /usr/share/doc/libreoffice-common/changelog.Debian.gz (libreoffice-common)
> /usr/share/doc/libreoffice-l10n-de -> libreoffice-common
>   /usr/share/doc/libreoffice-l10n-de/copyright (libreoffice-l10n-de) != 
> /usr/share/doc/libreoffice-common/copyright (libreoffice-common)
> /usr/share/doc/libreoffice-l10n-de -> libreoffice-common
> 
> 0m24.7s ERROR: FAIL: silently overwrites files via directory symlinks:
>   /usr/share/doc/libreoffice-help-common/changelog.Debian.gz 
> (libreoffice-help-common) != 
> /usr/share/doc/libreoffice-common/changelog.Debian.gz (libreoffice-common)
> /usr/sare/doc/libreoffice-help-common -> libreoffice-common
>   /usr/share/doc/libreoffice-help-common/copyright (libreoffice-help-common) 
> != /usr/share/doc/libreoffice-common/copyright (libreoffice-common)
> /usr/share/doc/libreoffice-help-common -> libreoffice-common

Hmm, actually this is what was meant with

libreoffice (1:6.4.0~beta1-0reprotest1) experimental; urgency=medium

  * New upstream beta release

  * debian/rules:
- add szl to (LANGPACK)ISOS so that we build a Upper Silesian
  l10n when languages get enabled again
  * debian/*.maintscript: fix
  ^^^

but that only fixed half of the problem, should have used /g (and didn't notice 
the second part also be broken...)

(And that one was because of

  * debian/rules, debian/control.in, debian/*.maintscript:
stop using --link-doc=. a) for -style-* as they cause a circular dependency
(closes: #940303) and b) since it doesn't work anymore with the -core-nogui
alternative

in 1:6.4.0~alpha1-0reprotest1

Will fix and upload.

Either asap or next week when rc1 will be there (but either way will be NEW 
given the previous versions
are still waiting in NEW since mid-November...)

Regards,

Rene

Bug#946413: lintian-brush: Some thoughts on fixers for debian/upstream/metadata

[gregor herrmann]

On Mon, 09 Dec 2019 11:03:40 +, Jelmer Vernooij wrote:

> > - - The perl YAML libraries we use add "---\n" at the top of the file,
> >   which the used Python libraries in lintian-brush apparently don't
> >   do. No idea what is more correct or if it matters at all; I just
> >   noted that the removal of the line adds some noise.
> I've noticed that as well. :-/ The Python YAML library that
> lintian-brush is using claims to support roundtrip loading/dumping of
> YAML files, but that has proven to be only partially true.
> 
> I've committed a fix to have lintian-brush at least preserve the
> directives above each YAML document, which should reduce the size of
> the diff.

Sounds good, thank you.
 
> > - - Sometimes when Contact and Name are removed, all that's left in our
> >   files is "Archive: CPAN" which is no so helpful. In those cases I
> >   just removed debian/upstream/metadata completely. Not sure if 
> > lintian-brush
> >   should do the same or if I should stop removing it or something
> >   else :)
> > - - Similarly, if lintian-brush creates debian/upstream/metadata for a
> >   perl package, it might add "Archive: CPAN" (not that we use it but
> >   the Archive field exists …).
> Agreed, it seems sensible to just remove the file in that case.

Cool, thanks.
 
> > - - The URLs lintian-brush finds in META.{json,yml} sometimes have room
> >   for improvement; in our tools [0] we e.g. fix github URLs to use
> >   https etc. It would be nice if lintian-brush could also learn some
> >   of these tricks.
> This behaviour should be present in newer versions of lintian-brush
> (>= 0.44). Some of the merge requests that you've seen may still have
> non-canonical URLs if they were generated with older versions of
> lintian-brush. I'll trigger a re-run for all perl packages with the
> current version.

Ah, that's great news.

Thanks for all your work on lintian-brush and the Janitor!


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Bob Dylan: Spirit On The Water


signature.asc
Description: Digital Signature

Bug#946474: fluidsynth: Incomplete debian/copyright?

[Chris Lamb]

Source: fluidsynth
Version: 2.0.5-1
Severity: serious
Justication: Policy § 12.5
X-Debbugs-CC: Fabian Greffrath , ftpmas...@debian.org

Hi,

I just ACCEPTed fluidsynth from NEW but noticed it was missing 
attribution in debian/copyright for at least the Creative Commons
documentation...

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

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

Bug#946473: llvm-9-tools: missing Breaks+Replaces: libclang-common-9-dev (<< 1:9.0.1~+rc2)

[Andreas Beckmann]

Package: llvm-9-tools
Version: 1:9.0.1~+rc2-1~exp1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../llvm-9-tools_1%3a9.0.1~+rc2-1~exp1_amd64.deb ...
  Unpacking llvm-9-tools (1:9.0.1~+rc2-1~exp1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/llvm-9-tools_1%3a9.0.1~+rc2-1~exp1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/llvm-9/bin/yaml-bench', which is also in 
package libclang-common-9-dev 1:9.0.0-4
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/llvm-9-tools_1%3a9.0.1~+rc2-1~exp1_amd64.deb


cheers,

Andreas


libclang-common-9-dev=1:9.0.0-4_llvm-9-tools=1:9.0.1~+rc2-1~exp1.log.gz
Description: application/gzip

Bug#946472: libtheora: Please make autopkgtests cross-test-friendly

[Steve Langasek]

Package: libtheora
Version: 1.1.1+dfsg.1-15
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.

One of the libtheora tests currently fails in this environment, because it
is a build test that does not invoke the toolchain in a cross-aware manner. 
In addition, all of the tests have a test dependency on '@', that is, all of
the binary packages from this source; which includes libtheora-doc, which is
currently not usable as a cross-dependency because it's not marked
Multi-Arch: foreign.

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 libtheora-1.1.1+dfsg.1/debian/control 
libtheora-1.1.1+dfsg.1/debian/control
--- libtheora-1.1.1+dfsg.1/debian/control   2019-02-24 13:58:12.0 
-0800
+++ libtheora-1.1.1+dfsg.1/debian/control   2019-12-09 08:31:49.0 
-0800
@@ -50,6 +50,7 @@
 
 Package: libtheora-doc
 Architecture: all
+Multi-Arch: foreign
 Section: doc
 Depends: ${misc:Depends}
 Suggests: libtheora-dev
diff -Nru libtheora-1.1.1+dfsg.1/debian/tests/test-simple-build-link 
libtheora-1.1.1+dfsg.1/debian/tests/test-simple-build-link
--- libtheora-1.1.1+dfsg.1/debian/tests/test-simple-build-link  2019-02-24 
13:35:01.0 -0800
+++ libtheora-1.1.1+dfsg.1/debian/tests/test-simple-build-link  2019-12-09 
08:31:49.0 -0800
@@ -10,6 +10,12 @@
 trap at_exit INT TERM EXIT
 set -x
 
+if [ -n "${DEB_HOST_GNU_TYPE:-}" ]; then
+CROSS_COMPILE="$DEB_HOST_GNU_TYPE-"
+else
+CROSS_COMPILE=
+fi
+
 cd $WORKDIR
 
 if type valgrind >/dev/null 2>&1 ; then
@@ -39,6 +45,6 @@
 }
 EOF
 
-gcc -o test -Wall -Wextra example.c -ltheoradec
+${CROSS_COMPILE}gcc -o test -Wall -Wextra example.c -ltheoradec
 
 ${VALGRIND} ./test

Bug#946471: lintian: Use of uninitialized value $section in numeric eq (==) at /usr/share/lintian/checks/manpages.pm line 387.

[Thorsten Glaser]

Package: lintian
Version: 2.41.0
Severity: minor

Within a directory with the contents from
http://www.mirbsd.org/~tg/Debs/dists/sarge/wtf/Pkgs/mirabilos-support/
when I run: lintian -vIiE mirabilos-support_60_i386.changes
I get the following:

[…]
N: Unpacking packages in group mirabilos-support/60
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
Use of uninitialized value $section in numeric eq (==) at 
/usr/share/lintian/checks/manpages.pm line 387.
N: 
[…]

This happens neither on the .dsc nor on the .deb containing the
manpages (mirabilos-support_60_all.deb), only when doing lintian
on the .changes file.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages lintian depends on:
ii  binutils 2.33.1-5
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-6
ii  gettext  0.19.8.1-10
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.67-1
ii  libberkeleydb-perl   0.62-1+b1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclass-xsaccessor-perl 1.19-3+b3
ii  libclone-perl0.43-2
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libipc-run-perl  20180523.0-2
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmldbm-perl2.05-2
ii  libmoo-perl  2.003006-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-libxml-perl   2.0134+dfsg-1+b1
ii  libyaml-libyaml-perl 0.80+repack-2+b1
ii  man-db   2.9.0-1
ii  patchutils   0.3.4-2
ii  perl [libdigest-sha-perl]5.30.0-9
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
ii  binutils-multiarch 2.33.1-5
ii  libhtml-parser-perl3.72-3+b4
pn  libtext-template-perl  

-- no debconf information

Bug#945618:

[thomasw]

I bisected this. After I see what the change was, its hard to imagine how 
accessibility could have anything to do with this since its i915 related. The 
person I had read the screen in powertop is not really a computer user so maybe 
they accidentally read the wrong numbers to me or I did something else that I 
don't realize that caused me to misdiagnose this. I am meeting up with some 
friends tomorrow who are Linux users so hopewfully I can do much more testing 
then with them reading my screen. I hope this new info is of assistance.

commit d4360736a7c0a6326e3bbdf7d41181f6ed03d9a6
Author: Imre Deak 
Date:   Mon Jul 9 18:24:27 2018 +0300

drm/i915/gen8+: Add RC6 CTX corruption WA

commit 7e34f4e4aad3fd34c02b294a3cf2321adf5b4438 upstream.

In some circumstances the RC6 context can get corrupted. We can detect
this and take the required action, that is disable RC6 and runtime PM.
The HW recovers from the corrupted state after a system suspend/resume
cycle, so detect the recovery and re-enable RC6 and runtime PM.

v2: rebase (Mika)
v3:
- Move intel_suspend_gt_powersave() to the end of the GEM suspend
  sequence.
- Add commit message.
v4:
- Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API
  change.
v5: rebased on gem/gt split (Mika)

Signed-off-by: Imre Deak 
Signed-off-by: Mika Kuoppala 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c 
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 9f8f7f54191f..3f6f42592708 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -36,6 +36,9 @@ static int intel_gt_unpark(struct intel_wakeref *wf)
i915->gt.awake = intel_display_power_get(i915, POWER_DOMAIN_GT_IRQ);
GEM_BUG_ON(!i915->gt.awake);
 
+   if (NEEDS_RC6_CTX_CORRUPTION_WA(i915))
+   intel_uncore_forcewake_get(>uncore, FORCEWAKE_ALL);
+
intel_enable_gt_powersave(i915);
 
i915_update_gfx_val(i915);
@@ -70,6 +73,11 @@ static int intel_gt_park(struct intel_wakeref *wf)
if (INTEL_GEN(i915) >= 6)
gen6_rps_idle(i915);
 
+   if (NEEDS_RC6_CTX_CORRUPTION_WA(i915)) {
+   intel_rc6_ctx_wa_check(i915);
+   intel_uncore_forcewake_put(>uncore, FORCEWAKE_ALL);
+   }
+
GEM_BUG_ON(!wakeref);
intel_display_power_put(i915, POWER_DOMAIN_GT_IRQ, wakeref);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 89efe6ce14d4..b6d51514cf9c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2156,6 +2156,8 @@ static int i915_drm_suspend_late(struct drm_device *dev, 
bool hibernation)
 
i915_gem_suspend_late(dev_priv);
 
+   intel_rc6_ctx_wa_suspend(dev_priv);
+
intel_uncore_suspend(_priv->uncore);
 
intel_power_domains_suspend(dev_priv,
@@ -2372,6 +2374,8 @@ static int i915_drm_resume_early(struct drm_device *dev)
 
intel_power_domains_resume(dev_priv);
 
+   intel_rc6_ctx_wa_resume(dev_priv);
+
intel_gt_sanitize(dev_priv, true);
 
enable_rpm_wakeref_asserts(_priv->runtime_pm);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 08fe13b7769a..a992f0749859 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -696,6 +696,8 @@ struct intel_rps {
 
 struct intel_rc6 {
bool enabled;
+   bool ctx_corrupted;
+   intel_wakeref_t ctx_corrupted_wakeref;
u64 prev_hw_residency[4];
u64 cur_residency[4];
 };
@@ -2288,10 +2290,12 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 /* Early gen2 have a totally busted CS tlb and require pinned batches. */
 #define HAS_BROKEN_CS_TLB(dev_priv)(IS_I830(dev_priv) || 
IS_I845G(dev_priv))
 
+#define NEEDS_RC6_CTX_CORRUPTION_WA(dev_priv)  \
+   (IS_BROADWELL(dev_priv) || IS_GEN(dev_priv, 9))
+
 /* WaRsDisableCoarsePowerGating:skl,cnl */
 #define NEEDS_WaRsDisableCoarsePowerGating(dev_priv) \
-   (IS_CANNONLAKE(dev_priv) || \
-IS_SKL_GT3(dev_priv) || IS_SKL_GT4(dev_priv))
+   (IS_CANNONLAKE(dev_priv) || IS_GEN(dev_priv, 9))
 
 #define HAS_GMBUS_IRQ(dev_priv) (INTEL_GEN(dev_priv) >= 4)
 #define HAS_GMBUS_BURST_READ(dev_priv) (INTEL_GEN(dev_priv) >= 10 || \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index cf00cc592ce6..177a26275811 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -493,6 +493,8 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
 #define   ECOCHK_PPGTT_WT_HSW  (0x2 << 3)
 #define   ECOCHK_PPGTT_WB_HSW  (0x3 << 3)
 
+#define GEN8_RC6_CTX_INFO  _MMIO(0x8504)
+
 #define GAC_ECO_BITS   _MMIO(0x14090)
 #define   ECOBITS_SNB_BIT  (1 << 13)
 #define   ECOBITS_PPGTT_CACHE64B   (3 << 8)
diff --git a/drivers/gpu/drm/i915/intel_pm.c 

Bug#946260: Please enable SPDIF support for Allwinner based systems

[Harald Geyer]

On 06.12.2019 11:55, andreimpope...@gmail.com wrote:

> Would this enable also the S/PDIF or is something else needed
> (CONFIG_SND_SUN4I_SPDIF maybe?)?

Indeed, for S/PDIF on A64 CONFIG_SND_SUN4I_SPDIF is needed.


Based on the name I'm guessing this is not A64 specific, so retitling
the bug accordingly.

However AFAICS debian ships no sun50i-a64 devicetrees where S/PDIF 
is

enabled. You would need a custom DT or an overlay, to make the
debian kernel actually load the module.


Is this still needed or do recent kernels have this already enabled?


AFAICS no a64 based systems yet, but other arm64 allwinner systems.
For example: sun50i-h6-beelink-gs1.dts

HTH,
Harald

--
https://haraldgeyer.at

Bug#946470: libreoffice-l10n-de: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Andreas Beckmann]

Package: libreoffice-l10n-de
Version: 1:6.4.0~beta1-0reprotest1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + libreoffice-l10n-ja libreoffice-l10n-he 
libreoffice-l10n-in libreoffice-l10n-za libreoffice-help-common

Hi,

an upgrade test with piuparts revealed that your package installs files
over existing symlinks and possibly overwrites files owned by other
packages. This usually means an old version of the package shipped a
symlink but that was later replaced by a real (and non-empty)
directory. This kind of overwriting another package's files cannot be
detected by dpkg.

This was observed on the following upgrade paths:

  sid -> experimental

For /usr/share/doc/PACKAGE this may not be problematic as long as both
packages are installed, ship byte-for-byte identical files and are
upgraded in lockstep. But once one of the involved packages gets
removed, the other one will lose its documentation files, too,
including the copyright file, which is a violation of Policy 12.5:
https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information

For other overwritten locations anything interesting may happen.

Note that dpkg intentionally does not replace directories with symlinks
and vice versa, you need the maintainer scripts to do this.
See in particular the end of point 4 in
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-unpack-phase-of-installation-or-upgrade

It is recommended to use the dpkg-maintscript-helper commands
'dir_to_symlink' and 'symlink_to_dir' (available since dpkg 1.17.14)
to perform the conversion, ideally using d/$PACKAGE.maintscript.
See dpkg-maintscript-helper(1) and dh_installdeb(1) for details.


This bug is present in several libreoffice-l10n-?? packages
and libreoffice-help-common. Maybe also in more packages
depending on these failing ones since they cannot be tested.

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

0m25.4s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libreoffice-l10n-de/changelog.Debian.gz (libreoffice-l10n-de) 
!= /usr/share/doc/libreoffice-common/changelog.Debian.gz (libreoffice-common)
/usr/share/doc/libreoffice-l10n-de -> libreoffice-common
  /usr/share/doc/libreoffice-l10n-de/copyright (libreoffice-l10n-de) != 
/usr/share/doc/libreoffice-common/copyright (libreoffice-common)
/usr/share/doc/libreoffice-l10n-de -> libreoffice-common

0m24.7s ERROR: FAIL: silently overwrites files via directory symlinks:
  /usr/share/doc/libreoffice-help-common/changelog.Debian.gz 
(libreoffice-help-common) != 
/usr/share/doc/libreoffice-common/changelog.Debian.gz (libreoffice-common)
/usr/share/doc/libreoffice-help-common -> libreoffice-common
  /usr/share/doc/libreoffice-help-common/copyright (libreoffice-help-common) != 
/usr/share/doc/libreoffice-common/copyright (libreoffice-common)
/usr/share/doc/libreoffice-help-common -> libreoffice-common


cheers,

Andreas


libreoffice-l10n-de_1:6.4.0~beta1-0reprotest1.log.gz
Description: application/gzip

Bug#924128: prokka: creates world writable directory tree /var/lib/prokka/*

[Michael Crusoe]

On Sat, 9 Mar 2019 23:26:01 +0100 Andreas Tille  wrote:
> Control: severity -1 normal
>
> On Sat, Mar 09, 2019 at 08:24:46PM +0100, Andreas Beckmann wrote:
> >
> > during a test with piuparts I noticed your package creates a world
> > writable directory tree.
> >
> > >From the attached log (scroll to the bottom...):
> >
> > 0m49.9s ERROR: Command failed (status=1): ['chroot',
'/srv/piuparts/tmp/tmpLm6y7M',
'tmp/scripts/pre_remove_50_find_bad_permissions']
> >   ERROR: BAD PERMISSIONS
> >   drwxrwxrwx 3 root root  60 Mar  5 02:46 /var/lib/prokka
> >   drwxrwxrwx 4 root root  80 Mar  5 02:46 /var/lib/prokka/db
> >   drwxrwxrwx 2 root root 260 Mar  5 02:46 /var/lib/prokka/db/cm
> >   drwxrwxrwx 2 root root 580 Mar  5 02:46 /var/lib/prokka/db/genus
>
> I actually did some effort to make this dir world writable since users
> *need* to write and update these databases.  Do your have any suggestion
> for a better approach which enables every user to update a common
> database?  I was wondering whether I should create a group prokka and
> making the dir only writable for users belonging to this group.  But for
> a first packaging attempt testing user responses this seemed to be over
> enginering.  There is also some work done at upstream to enable a better
> solution for user writable databases.

Is making a "prokka" group to own this directory the only option?

Bug#946469: initramfs-tools-core: unmkinitrams creates broken binaries

[Jen Bowen]

Package: initramfs-tools-core
Version: 0.135
Severity: normal

Dear Maintainer,

When unmkinitramfs is used on prepended initramfs images, such as the
initrd.img-5.3.0-2-amd64 generated by the linux-image-5.3.0-2-amd64 package,
the symlink at main/lib64/ld-linux-x86-64.so.2 is broken.  This seems to be a
result of the use of the "--no-absolute-filenames" flag with cpio.

If I remove this flag and run unmkinitramfs again, the symlink to the linker is
intact, and it's possible to chroot into the extracted initramfs image and run
binaries in main/bin .

I don't know if it's the intention of unmkinitramfs to create functional
binaries in the extracted images, but it's very helpful in my use case!

Thanks for your assistance.



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

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

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.30-3+b1
ii  cpio 2.13+dfsg-1
ii  e2fsprogs1.45.4-1
ii  klibc-utils  2.0.7-1
ii  kmod 26-3
ii  logsave  1.45.4-1
ii  udev 244-3

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.30.1-4
ii  pigz 2.4-1+b1

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.9-1

-- no debconf information

Bug#946468: ITP: libbio-variation-perl -- BioPerl variation-related functionality

[Michael R. Crusoe]

Package: wnpp
Severity: wishlist

Subject: ITP: libbio-variation-perl -- BioPerl variation-related functionality
Package: wnpp
Owner: Michael R. Crusoe 
Severity: wishlist

* Package name: libbio-variation-perl
  Version : 1.7.4
  Upstream Author : Copyright: Allen Day , Heikki 
Lehvaslaiho 
* URL : https://metacpan.org/release/Bio-Variation
* License : Artistic
  Programming Lang: Perl
  Description : BioPerl variation-related functionality
  The code in this distribution focuses on simple low-dependency variant-related
 functionality for BioPerl.
 .
 Bio::Variation name space contains modules to store sequence variation
 information as differences between the reference sequence and changes
 sequences. Also included are classes to write out and recrete objects
 from EMBL-like flat files and XML. Lastly, there are simple classes to
 calculate values for sequence change objects.

Remark: This package is maintained by Debian Med Team at
   https://salsa.debian.org/med-team/libbio-variation-perl

Bug#944771: GNOME Shell crashes when selecting "About" from top bar menu in Midori

[Bernhard Übelacker]

Hello Andrew,

On Sun, 8 Dec 2019 15:17:45 -0500 Andrew Engelbrecht  wrote:

> I was able to reproduce and to get a backtrace, which I attached to this
> email.

Your backtrace with full debug symbols should read like below [4].
This seems to point to the upstream issue [1].
Unfortunately I could not find any hint of a solution there.
Another occourence seems to be in fedora,
but also without solution [2].

At least it looks like the pointer "observer" contained in your
gnome-shell crash an invalid pointer.

The crash before in midori seems to be in webkitWebViewBaseMakeGLContextCurrent.
In my test VM I never reached that function.


> I tried clearing out the ~/.config/midori/ directory. After doing so, I
> no longer get a crash when selecting the "About" menu option.
> 
> If needed, I can try to recover the bad config from backups, for the
> sake of testing future versions of Midori and GNOME Shell.

Thats maybe up to the maintainer if this is still desired,
as you found already a workaround.

Kind regards,
Bernhard


[1] https://gitlab.gnome.org/GNOME/gnome-shell/issues/365

[2] https://bugzilla.redhat.com/show_bug.cgi?id=1642473

[3]
https://sources.debian.org/src/gnome-shell/3.30.2-11%7Edeb10u1/src/gtkactionobserver.c/#L155
(gdb) list 
150 void
151 gtk_action_observer_action_removed (GtkActionObserver   *observer,
152 GtkActionObservable *observable,
153 const gchar *action_name)
154 {
155   g_return_if_fail (GTK_IS_ACTION_OBSERVER (observer));
156
157   GTK_ACTION_OBSERVER_GET_IFACE (observer)
158 ->action_removed (observer, observable, action_name);
159 }
(gdb) print observer
$2 = (GtkActionObserver *) 0x562a598364c0
(gdb) print/x $rbx
$3 = 0x562a598364c0


[4]
(gdb) bt no-filters
#0  0x7fc15234e9a7 in gtk_action_observer_action_removed at 
../src/gtkactionobserver.c:155
#1  0x7fc15234d206 in gtk_action_muxer_action_removed at 
../src/gtkactionmuxer.c:313
#2  0x7fc15234d26f in gtk_action_muxer_action_removed_from_group at 
../src/gtkactionmuxer.c:326
#3  0x7fc15234dce0 in gtk_action_muxer_remove at ../src/gtkactionmuxer.c:763
#4  0x7fc15234dd28 in gtk_action_muxer_insert at ../src/gtkactionmuxer.c:712
#5  0x7fc1534238a4 in shell_app_update_window_actions at 
../src/shell-app.c:472
#6  0x7fc153432aee in update_focus_app at ../src/shell-window-tracker.c:487
#7  0x7fc1531ecc8d in g_closure_invoke at ../../../gobject/gclosure.c:810
#8  0x7fc153200365 in signal_emit_unlocked_R at 
../../../gobject/gsignal.c:3635
#9  0x7fc1532092be in g_signal_emit_valist at 
../../../gobject/gsignal.c:3391
#10 0x7fc15320997f in g_signal_emit at ../../../gobject/gsignal.c:3447
#11 0x7fc1531f1364 in g_object_dispatch_properties_changed at 
../../../gobject/gobject.c:1088
#12 0x7fc1531f3921 in g_object_notify_by_spec_internal at 
../../../gobject/gobject.c:1181
#13 g_object_notify_by_pspec at ../../../gobject/gobject.c:1291
#14 0x7fc1513258ee in ffi_call_unix64 at ../src/x86/unix64.S:76
#15 0x7fc1513252bf in ffi_call at ../src/x86/ffi64.c:525
#16 0x7fc14f8ccb2d in wl_closure_invoke at ../src/connection.c:1006
#17 0x7fc14f8c95a9 in wl_client_connection_data at 
../src/wayland-server.c:420
#18 0x7fc14f8cab72 in wl_event_loop_dispatch at ../src/event-loop.c:641
#19 0x7fc1526263a7 in wayland_event_source_dispatch at 
wayland/meta-wayland.c:90
#20 0x7fc15310af2e in g_main_dispatch at ../../../glib/gmain.c:3182
#21 g_main_context_dispatch at ../../../glib/gmain.c:3847
#22 0x7fc15310b1c8 in g_main_context_iterate at ../../../glib/gmain.c:3920
#23 0x7fc15310b4c2 in g_main_loop_run at ../../../glib/gmain.c:4116
#24 0x7fc1525ed06c in meta_run at core/main.c:689
#25 0x562a53f1e782 in main at ../src/main.c:501
#26 0x7fc15237a09b in __libc_start_main at ../csu/libc-start.c:308
#27 0x562a53f1e8da in _start

Bug#946467: nmu: debos_1.0.0+git20190123.d6e16be-1 (in buster)

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: de...@packages.debian.org

Please consider:

nmu debos_1.0.0+git20190123.d6e16be-1 . ANY . buster . -m "rebuild with 
fakemachine 0.0~git20181105.9316584-2 (#924392)"

debos is an executable written in Go, which statically links
golang-github-go-debos-fakemachine. It fails to run in a pure buster
system where busybox (as opposed to busybox-static) is installed, because
busybox in buster has gained a dependency on libresolv.so.2, which
debos does not include when generating an initramfs. This was fixed in
g-g-g-d-fakemachine version 0.0~git20181105.9316584-2 (#924392), but the
version of debos in buster was built against 0.0~git20181105.9316584-1
and so does not have that fix.

Minimal steps to reproduce bug and verify fix, in a buster chroot:

(you must be in a directory that is not /tmp; /root is suitable)
# apt install --no-install-recommends debos
# apt build-dep --no-install-recommends debos
# apt install linux-image-amd64
# cat > debos.yaml <  
[ 

Bug#946466: linux-image-5.3.0-2-amd64: segfault when unloading unresponsive b43 module

[Michel Le Bihan]

Package: src:linux
Version: 5.3.9-3
Severity: normal

Hello,

After resuming from hibernation my wireless card became unresponsive. I tried
to fix that by reloading the b43 module, but that caused a segfault. The
segfault is present in the log below.

My other card (TL-WN722N) is also not responding, but at least reloading didn't
cause a segfault.

I didn't have these issues before updating to kernel 5.3.



-- Package-specific info:
** Version:
Linux version 5.3.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.2.1 
20191109 (Debian 9.2.1-19)) #1 SMP Debian 5.3.9-3 (2019-11-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.3.0-2-amd64 
root=UUID=53d5c5df-af2e-4452-825c-2ab652aba91e ro quiet

** Tainted: D (128)
 * Kernel has oopsed before.

** Kernel log:
[11233.715085] usb 1-1: USB disconnect, device number 5
[11233.822810] usb 1-1: ath9k_htc: USB layer deinitialized
[11235.503821] wlan0: authenticate with bc:ee:7b:f4:42:18
[11235.558684] wlan0: send auth to bc:ee:7b:f4:42:18 (try 1/3)
[11235.674896] wlan0: authenticated
[11235.678461] wlan0: associate with bc:ee:7b:f4:42:18 (try 1/3)
[11235.837694] wlan0: RX AssocResp from bc:ee:7b:f4:42:18 (capab=0x411 
status=18 aid=0)
[11235.837702] wlan0: bc:ee:7b:f4:42:18 denied association (code=18)
[11237.187514] wlan0: authenticate with bc:ee:7b:f4:42:18
[11237.246738] wlan0: send auth to bc:ee:7b:f4:42:18 (try 1/3)
[11237.450556] wlan0: send auth to bc:ee:7b:f4:42:18 (try 2/3)
[11237.518121] wlan0: authenticated
[11237.518566] wlan0: associate with bc:ee:7b:f4:42:18 (try 1/3)
[11237.521442] wlan0: RX AssocResp from bc:ee:7b:f4:42:18 (capab=0x411 
status=18 aid=0)
[11237.521450] wlan0: bc:ee:7b:f4:42:18 denied association (code=18)
[11239.279551] wlan0: authenticate with bc:ee:7b:f4:42:18
[11239.334765] wlan0: send auth to bc:ee:7b:f4:42:18 (try 1/3)
[11239.361288] wlan0: authenticated
[11239.362591] wlan0: associate with bc:ee:7b:f4:42:18 (try 1/3)
[11239.364960] wlan0: RX AssocResp from bc:ee:7b:f4:42:18 (capab=0x411 
status=18 aid=0)
[11239.364967] wlan0: bc:ee:7b:f4:42:18 denied association (code=18)
[11241.627463] wlan0: authenticate with bc:ee:7b:f4:42:18
[11241.682872] wlan0: send auth to bc:ee:7b:f4:42:18 (try 1/3)
[11241.818945] wlan0: authenticated
[11241.822716] wlan0: associate with bc:ee:7b:f4:42:18 (try 1/3)
[11241.837706] wlan0: RX AssocResp from bc:ee:7b:f4:42:18 (capab=0x411 
status=18 aid=0)
[11241.837712] wlan0: bc:ee:7b:f4:42:18 denied association (code=18)
[11247.08] stack segment:  [#1] SMP PTI
[11247.011124] CPU: 0 PID: 34841 Comm: modprobe Not tainted 5.3.0-2-amd64 #1 
Debian 5.3.9-3
[11247.011126] Hardware name: Apple Inc. MacBookPro9,2/Mac-6F01561E16C75D06, 
BIOS 224.0.0.0.0 02/14/2019
[11247.011132] RIP: 0010:kfree+0x50/0x210
[11247.011134] Code: 80 48 01 dd 0f 82 c8 01 00 00 48 c7 c0 00 00 00 80 48 2b 
05 d2 c2 cb 00 48 01 c5 48 c1 ed 0c 48 c1 e5 06 48 03 2d b0 c2 cb 00 <48> 8b 45 
08 48 8d 50 ff a8 01 48 0f 45 ea 48 8b 55 08 48 8d 42 ff
[11247.011136] RSP: 0018:a53ac31b3e50 EFLAGS: 00010207
[11247.011138] RAX: 6f5ac000 RBX: 80f1e17208a54ec8 RCX: 820001d8
[11247.011140] RDX: 820001d9 RSI: 0001 RDI: 80f1e17208a54ec8
[11247.011141] RBP: 0203a02cb5229500 R08:  R09: c0f34500
[11247.011142] R10: 90a724e5e490 R11: 0001 R12: c08660ff
[11247.011144] R13:  R14:  R15: 
[11247.011146] FS:  7f0b7faf24c0() GS:90a72700() 
knlGS:
[11247.011147] CS:  0010 DS:  ES:  CR0: 80050033
[11247.011148] CR2: 5586759a32a0 CR3: 000217594004 CR4: 001606f0
[11247.011150] Call Trace:
[11247.011161]  bcma_device_remove+0x1f/0x30 [bcma]
[11247.011167]  device_release_driver_internal+0xd8/0x1b0
[11247.011170]  driver_detach+0x43/0x7e
[11247.011173]  bus_remove_driver+0x55/0xc6
[11247.011185]  b43_exit+0x18/0x9a1 [b43]
[11247.011189]  __x64_sys_delete_module+0x192/0x2d0
[11247.011193]  ? exit_to_usermode_loop+0xb0/0xf0
[11247.011195]  do_syscall_64+0x53/0x140
[11247.011199]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[11247.011202] RIP: 0033:0x7f0b7fc13be7
[11247.011205] Code: 73 01 c3 48 8b 0d a9 e2 0b 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 79 e2 0b 00 f7 d8 64 89 01 48
[11247.011207] RSP: 002b:7ffddba74ca8 EFLAGS: 0206 ORIG_RAX: 
00b0
[11247.011209] RAX: ffda RBX: 561845b77dd0 RCX: 7f0b7fc13be7
[11247.011210] RDX:  RSI: 0800 RDI: 561845b77e38
[11247.011213] RBP: 561845b77dd0 R08:  R09: 
[11247.011215] R10: 7f0b7fc86ac0 R11: 0206 R12: 561845b77e38
[11247.011216] R13:  R14: 561845b77e38 R15: 561845b77dd0
[11247.011219] Modules linked in: macvtap macvlan tap cmac tun ath9k_htc 
ath9k_common ath9k_hw ath ctr 

Bug#946465: librust-rand+alloc-dev: does not find upgrade path from buster to bullseye

[Andreas Beckmann]

Package: librust-rand+alloc-dev
Version: 0.6.4-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'buster'.
It installed fine in 'buster', then the upgrade to 'bullseye' fails.

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

  Starting 2 pkgProblemResolver with broken count: 2
  Investigating (0) librust-rand-core-0.2+alloc-dev:amd64 < 0.2.2-1+b1 @ii mK 
Ib >
  Broken librust-rand-core-0.2+alloc-dev:amd64 Depends on 
librust-rand-core-0.2-dev:amd64 < 0.2.2-1+b1 @ii mR > (= 0.2.2-1+b1)
Considering librust-rand-core-0.2-dev:amd64 3 as a solution to 
librust-rand-core-0.2+alloc-dev:amd64 0
Removing librust-rand-core-0.2+alloc-dev:amd64 rather than change 
librust-rand-core-0.2-dev:amd64
  Investigating (0) librust-rand-core-0.4-dev:amd64 < none -> 0.4.2-1 @un uN Ib 
>
  Broken librust-rand-core-0.4-dev:amd64 Breaks on librust-rand-core-dev:amd64 
< 0.3.0-1 @ii mK > (< 0.4.3-~~)
Considering librust-rand-core-dev:amd64 -1 as a solution to 
librust-rand-core-0.4-dev:amd64 -1
Holding Back librust-rand-core-0.4-dev:amd64 rather than change 
librust-rand-core-dev:amd64
  Investigating (1) librust-rand-pcg-0.1-dev:amd64 < none -> 0.1.2-1+b1 @un uN 
Ib >
  Broken librust-rand-pcg-0.1-dev:amd64 Depends on 
librust-rand-core-0.4+default-dev:amd64 < none @un H >
Considering librust-rand-core-0.4-dev:amd64 -1 as a solution to 
librust-rand-pcg-0.1-dev:amd64 -1
Holding Back librust-rand-pcg-0.1-dev:amd64 rather than change 
librust-rand-core-0.4+default-dev:amd64
  Investigating (2) librust-rand-dev:amd64 < 0.5.5-2 -> 0.6.4-2 @ii umU Ib >
  Broken librust-rand-dev:amd64 Depends on 
librust-rand-pcg-0.1+default-dev:amd64 < none @un H >
Considering librust-rand-pcg-0.1-dev:amd64 -1 as a solution to 
librust-rand-dev:amd64 1
Re-Instated librust-rand-core-0.4-dev:amd64
Re-Instated librust-rand-pcg-0.1-dev:amd64
Re-Instated librust-rand-dev:amd64
  Investigating (2) librust-rand-core-0.4-dev:amd64 < none -> 0.4.2-1 @un uN Ib 
>
  Broken librust-rand-core-0.4-dev:amd64 Breaks on librust-rand-core-dev:amd64 
< 0.3.0-1 @ii mK > (< 0.4.3-~~)
Considering librust-rand-core-dev:amd64 -1 as a solution to 
librust-rand-core-0.4-dev:amd64 -1
Holding Back librust-rand-core-0.4-dev:amd64 rather than change 
librust-rand-core-dev:amd64
  Investigating (3) librust-rand-pcg-0.1-dev:amd64 < none -> 0.1.2-1+b1 @un uN 
Ib >
  Broken librust-rand-pcg-0.1-dev:amd64 Depends on 
librust-rand-core-0.4+default-dev:amd64 < none @un H >
Considering librust-rand-core-0.4-dev:amd64 -1 as a solution to 
librust-rand-pcg-0.1-dev:amd64 -1
Holding Back librust-rand-pcg-0.1-dev:amd64 rather than change 
librust-rand-core-0.4+default-dev:amd64
  Investigating (4) librust-rand-dev:amd64 < 0.5.5-2 -> 0.6.4-2 @ii umU Ib >
  Broken librust-rand-dev:amd64 Depends on 
librust-rand-pcg-0.1+default-dev:amd64 < none @un H >
Considering librust-rand-pcg-0.1-dev:amd64 -1 as a solution to 
librust-rand-dev:amd64 1
Removing librust-rand-dev:amd64 rather than change 
librust-rand-pcg-0.1+default-dev:amd64
  Investigating (5) librust-rand+alloc-dev:amd64 < 0.5.5-2 -> 0.6.4-2 @ii pumU 
Ib >
  Broken librust-rand+alloc-dev:amd64 Depends on librust-rand-dev:amd64 < 
0.5.5-2 | 0.6.4-2 @ii umR > (= 0.6.4-2)
Considering librust-rand-dev:amd64 1 as a solution to 
librust-rand+alloc-dev:amd64 1
  Done
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:
  
  The following packages have unmet dependencies:
   librust-rand+alloc-dev : Depends: librust-rand-dev (= 0.6.4-2)
  E: Unable to correct problems, you have held broken packages.

Similar errors happen in several other rust packages, too,
but this one has the most rdepends.

I can't spot immediately how the correct upgrade path should look like,
there are too many virtual packages involved. And probably this involves
substituting a currently installed package for another one as well.
Fixing this (and similar) bug(s) will probably need some Breaks to be
added to some packages.


cheers,

Andreas


librust-rand+alloc-dev_0.6.4-2.log.gz
Description: application/gzip

Bug#946464: coreutils: please add Homepage field

[Jakub Wilk]

Source: coreutils
Version: 8.30-3
Severity: wishlist

Please add

  Homepage: https://www.gnu.org/software/coreutils/

to debian/control.

--
Jakub Wilk

Bug#894500: (no subject)

[Aurélien COUDERC]

Hi Leandro,

thank you for taking the time to report this bug and help make Debian better !

The bug you raised was while buster was in testing phase, and it may well have 
been a transitional and due to some packages but not others having migrated.

Could you confirm that this issue was later fixed for you ?
If you cannot, I propose we still close this bug because the exact versions of 
the packages where the issue happened to you are not part of any stable 
version.


Happy hacking !
--
Aurélien 

Bug#946463: sysdig: specific filter produces "BUG: unable to handle kernel NULL pointer dereference at..."

[Vincas Dargis]

Package: sysdig
Version: 0.13.0-2
Severity: important

Dear Maintainer,

I've started sysdig with this filter on some remote machine:
`sysdig "evt.category=file and evt.args contains .ttf"`

And it hanged after few seconds. I've reproduced this (though kern.log
has only junk) on my local laptop running same Debian release and kernel
by running command and closing Firefox browser. Had to do cold reset.

This is from kern.log:
```
Dec  9 15:27:47 dl380 kernel: [267690.770499] sysdig_probe: starting capture
Dec  9 15:27:50 dl380 kernel: [267692.915596] BUG: unable to handle kernel NULL 
pointer dereference at 0010
Dec  9 15:27:50 dl380 kernel: [267692.915728] IP: [] 
record_event_consumer.part.4+0x289/0x870 [sysdig_probe]
Dec  9 15:27:50 dl380 kernel: [267692.915861] PGD 0 
Dec  9 15:27:50 dl380 kernel: [267692.915891] 
Dec  9 15:27:50 dl380 kernel: [267692.916061] Oops:  [#1] SMP
Dec  9 15:27:50 dl380 kernel: [267692.916112] Modules linked in: 
sysdig_probe(O) nf_conntrack_netlink nf_conntrack nfnetlink udp_diag 
binfmt_misc tcp_diag inet_diag xt_multiport iptable_filter intel_powerclamp 
kvm_intel kvm iTCO_wdt iTCO_vendor_support amdkfd irqbypass radeon evdev 
intel_cstate ttm intel_uncore drm_kms_helper serio_raw pcspkr hpilo drm sg 
hpwdt i2c_algo_bit button i7core_edac ipmi_si ipmi_msghandler edac_core lpc_ich 
acpi_power_meter mfd_core shpchp pcc_cpufreq coretemp ip_tables x_tables 
autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb glue_helper lrw gf128mul 
ablk_helper cryptd aes_x86_64 mbcache sr_mod cdrom ata_generic hid_generic 
usbhid hid dm_mod sd_mod crc32c_intel psmouse ata_piix ehci_pci uhci_hcd libata 
mptspi ehci_hcd scsi_transport_spi mptscsih hpsa usbcore mptbase usb_common 
scsi_transport_sas bnx2
Dec  9 15:27:50 dl380 kernel: [267692.917532]  scsi_mod thermal
Dec  9 15:27:50 dl380 kernel: [267692.917569] CPU: 10 PID: 26919 Comm: tail 
Tainted: G  IO4.9.0-11-amd64 #1 Debian 4.9.189-3+deb9u2
Dec  9 15:27:50 dl380 kernel: [267692.917713] Hardware name: HP ProLiant DL380 
G6, BIOS P62 08/16/2010
Dec  9 15:27:50 dl380 kernel: [267692.917846] task: 88e1cd950ec0 
task.stack: b54cc88d
Dec  9 15:27:50 dl380 kernel: [267692.917934] RIP: 0010:[]  
[] record_event_consumer.part.4+0x289/0x870 [sysdig_probe]
Dec  9 15:27:50 dl380 kernel: [267692.918099] RSP: 0018:b54cc88d3bc8  
EFLAGS: 00010046
Dec  9 15:27:50 dl380 kernel: [267692.918177] RAX:  RBX: 
d549b3d51950 RCX: b54cc88d3d60
Dec  9 15:27:50 dl380 kernel: [267692.918282] RDX: b54cd03ec592 RSI: 
00e8 RDI: 1592
Dec  9 15:27:50 dl380 kernel: [267692.918386] RBP: b54cc88d3d00 R08: 
b54cc337d000 R09: 00e8
Dec  9 15:27:50 dl380 kernel: [267692.918491] R10: b54cc88d3d10 R11: 
007fff97 R12: 
Dec  9 15:27:50 dl380 kernel: [267692.918595] R13: b54cc3149000 R14: 
007fff81 R15: 1592
Dec  9 15:27:50 dl380 kernel: [267692.918701] FS:  7fd2f2be0480() 
GS:88ded3b4() knlGS:Dec  9 15:32:59 dl380 kernel: [ 
   0.00] microcode: microcode updated early to revision 0x1d, date = 
2018-05-11
```


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

Kernel: Linux 4.9.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sysdig depends on:
ii  libb64-0d1.2-3+b1
ii  libc62.24-11+deb9u4
ii  libcurl3 7.52.1-5+deb9u9
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libjq1   1.5+dfsg-1.3
ii  libjsoncpp1  1.7.4-3
ii  libluajit-5.1-2  2.0.4+dfsg-1+b1
ii  libncurses5  6.0+20161126-1+deb9u2
ii  libssl1.11.1.0l-1~deb9u1
ii  libstdc++6   6.3.0-18+deb9u1
ii  libtinfo56.0+20161126-1+deb9u2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages sysdig recommends:
ii  sysdig-dkms  0.13.0-2

sysdig suggests no packages.

-- no debconf information

Bug#946345: proftpd-dfsg: CVE-2019-19269

[Salvatore Bonaccorso]

Hi Hilmar,

On Sun, Dec 08, 2019 at 11:52:31PM +0100, Hilmar Preuße wrote:
> Am 07.12.2019 um 16:42 teilte Salvatore Bonaccorso mit:
> 
> Hi,
> 
> > The following vulnerability was published for proftpd-dfsg.
> > 
> The uploads to unstable are made.

Thanks! Updated the security-tracker earlier already.

> Please find attached the debdiff patches for buster and stretch. I did
> not test the code at all (except that build runs OK), but the change
> seems to be rather trivial to me.

Thsese do not warrant a DSA. Could you fix those issues for an
upcoming point release for buster and stretch?

Regards,
Salvatore

Bug#946137: nvidia-legacy-340xx-driver: Fails to build with kernel 5.4

[Andreas Beckmann]

On 09/12/2019 08.24, jim_p wrote:
> Thank you for patching the package as I requested. However, I think it would 
> be
> nice to report the real contributor in the changelog, i.e. the user that 
> posted
> the patch on github, and give thim the credit instead of copying the lines for
> ubuntu from 340.107-7 and just changing the kernel version.

I took the patch without further changes from Ubuntu - Alberto had
patched their package in the meantime. That patch was more likely to
apply on top of the other kernel support patches originating from
Ubuntu. I didn't look for a possible origin of the patch.


Andreas

Bug#946462: postgresql-common: autopkgtests should have versioned postgresql deps

[Christoph Berg]

Re: Dimitri John Ledkov 2019-12-09 
<157589727865.175171.11228668415175195788.reportbug@ottawa.168.1.5>
> Does above makes sense at all?

It does, see also #944457.

Christoph

Bug#946462: postgresql-common: autopkgtests should have versioned postgresql deps

[Dimitri John Ledkov]

Package: postgresql-common
Version: 210
Severity: normal

Dear Maintainer,

We are currently in the middle of 11 -> 12 transition, and I have
noticed an oddity which is preventing autopkgtest runs and successful
migration of the new postgresql-common packge in Ubuntu.

cstore-fdw is built against postgresql 11 and fails to build against 12.

The autopkgtest for postgresql-11-cstore-fdw depends on
postgresql-server-dev-all. I think it should depend instead on
postgresql-11, since otherwise the autopkgtest fails with "initdb for
postgresql 11 not found". Given that postgresql-11-cstore-fdw will
only ever work with postgresql-11 it should state so in
debian/tests/control as postgresql-server-dev-all has moved to 12.

Can it be added to do something like debian/tests/control.in ->
control translation, similar to how it is done for debian/control.in
-> control?

That way autopkgtests for postgresql-N extensions will continue to
work whilst we are in the middle of migration to postgresql-(N+1).

Does above makes sense at all?

Regards,

Dimitri.

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

[Wesley]

Besides nearly every extension breaking (all for me, in fact), some
websites are also broken. For example, Riot (the Matrix client) also
fails entirely, making unusable:
https://github.com/vector-im/riot-web/issues/11606

I would suggest that this is important enough to roll back to the
previous package, based on Firefox 70, or at least to offer that version
in the repositories. As it stands I'm completely stuck until a new
version is released, short of using a flatpak or tarball or something.

Bug#946461: Tests are failing

[Sebastien Bacher]

Package: libscout
Version: 2.3.2-2

The autopkgtests are failing since the recent upload
https://ci.debian.net/data/packages/unstable/amd64/libs/libscout/latest-autopkgtest/log.gz

Some issues

* debian/test/control:

The use of "Test-Command" is invalid, it should be "Tests" instead now
that it's a script

* debian/test/run-tests.sh

- the set -x makes it print on stderr which is failing the tests

- "if ! libscout; then" is retuning an error/text on stdout since the
syntax is invalid, the libscout binary expect a -o argument


Unsure what the test is checking by calling the binary with an invalid
syntax? the command seems to just print out the help in that case, is
that useful output?

Cheers,