Bug#703226: can I reuse the name patchwork for another ITP ?

[Carsten Schoenert]

Hello Paolo,

On Wed, Apr 11, 2018 at 06:33:44PM +0200, Paolo Greppi wrote:
> Hi,
> 
> I was wondering whether the RFP for patchwork (a console or web based
> patch tracking system) can be closed.

no, even if no one is working an packaging the sense of such open
reports is simply to show that there are some people that had an
interest in the past to package this software. And this is mostly
helpful for people who possible want to step in or need to find other
packages which might conflict with their packages or package name, like
here in your case.
Normaly RFPs are moving to an ITP and closed by a later upload.

> The bug has seen no activity for 2.5 years.
> 
> The interest of this for Debian is probably lower now than it was 5
> years ago, as now we have salsa, which has merge requests (similar to
> github's pull requests).

The intention of patchwork is completely different to Salsa, GitHub,
GitLab and similar.
Patchwork a kind of standard in the development of the kernel sub
modules and a lot ob big IT company using this in their development like
IBM and Intel. So I don't see in detail a dedicated interest for the
Debian project itself and we package software mostly for users. I don't
know of any teams or maintainers which might use patchwork in their
workflow, but I wouldn't be surprised if this is already happen.

> Merge requests are easier to use than command-line patches and should
> lower the barrier for contributors (that was one of the reason for the
> switch from alioth cgit to salsa).

That's for sure true, but there are also downsides. Reviewing changes
isn't always easier (at least in my eyes) and need always a network
connection. 

> Besides the future of alioth mailing lists is uncertain ATM:
> https://wiki.debian.org/Alioth#Mailing_lists
> 
> I am asking because I was planning to use the name patchwork for
> something else:
> https://github.com/ssbc/patchwork

Given the age that patchwork now has (initial commit 2008 vs 2015 for
ssbc-patchwork) and the completely different use cases I personally
would hereby suggesting to choose a different source and binary name for
the patchwork software for Secure Scuttlebutt.

Why not use ssb-patchwork or ssbc-patchwork as name? I'd prefer the
former name.

Regards
Carsten

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

This fix (or testing it) might be blocked by bug #895587.

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895587: openjdk-10: exclude element-list from being compressed

[Tiago Daitx]

Please consider the attached patch to fix this issue.

On Fri, Apr 13, 2018 at 1:51 AM, Tiago Stürmer Daitx
 wrote:
> Package: openjdk-10
> Version: 10~46-5
> Severity: important
>
> Dear Maintainer,
>
> The file element-list has replaced package-list in the javadoc api
> directory is now used by the javadoc binary. As it is not currently
> excluded when calling dh_compress it will be gzip and that causes
> javadoc to fail to recognize the /usr/share/doc/openjdk-10-jre-headless/api/
> directory. This causes quite a few packages to FTBFS, the most proeminent
> being gradle and groovy.
>
> thanks
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru openjdk-10-10~46/debian/changelog openjdk-10-10~46/debian/changelog
--- openjdk-10-10~46/debian/changelog	2018-04-02 12:39:54.0 -0300
+++ openjdk-10-10~46/debian/changelog	2018-04-13 01:42:02.0 -0300
@@ -1,3 +1,11 @@
+openjdk-10 (10~46-5) UNRELEASED; urgency=medium
+
+  * debian/rules: do not compress the element-list api docs as javadoc expects
+this file to be uncompressed when using '-link' or '-linkoffline'.
+(Closes: #895587)
+
+ -- Tiago Stürmer Daitx   Fri, 13 Apr 2018 04:42:02 +
+
 openjdk-10 (10~46-4) unstable; urgency=medium
 
   * Fix installation of japanese manual pages.
diff -Nru openjdk-10-10~46/debian/rules openjdk-10-10~46/debian/rules
--- openjdk-10-10~46/debian/rules	2018-04-02 12:25:57.0 -0300
+++ openjdk-10-10~46/debian/rules	2018-04-13 01:41:44.0 -0300
@@ -1789,7 +1789,7 @@
 	-dh_icons -i $(nodocs) || dh_iconcache -i $(nodocs)
 #	dh_installdebconf -i $(nodocs)
 	dh_link -i $(nodocs)
-	dh_compress -i $(nodocs) -Xexamples -Xdemo -Xpackage-list
+	dh_compress -i $(nodocs) -Xexamples -Xdemo -Xpackage-list -Xelement-list
 	dh_fixperms -i $(nodocs)
 	dh_installdeb -i $(nodocs)
 	dh_gencontrol -i $(nodocs) -- $(control_vars)

Bug#895587: openjdk-10: exclude element-list from being compressed

[Tiago Stürmer Daitx]

Package: openjdk-10
Version: 10~46-5
Severity: important

Dear Maintainer,

The file element-list has replaced package-list in the javadoc api
directory is now used by the javadoc binary. As it is not currently
excluded when calling dh_compress it will be gzip and that causes
javadoc to fail to recognize the /usr/share/doc/openjdk-10-jre-headless/api/
directory. This causes quite a few packages to FTBFS, the most proeminent
being gradle and groovy.

thanks

-- System Information:
Debian Release: buster/sid
  APT prefers bionic
  APT policy: (500, 'bionic'), (400, 'bionic-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#895586: RFS: goldendict/1.5.0~rc2+git20180412+ds-1

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: un...@debian.org

  Dear mentors, Dmitry,

  I've prepared a new snapshot for package "goldendict" and I 
am looking for a sponsor for my package "goldendict".

  I am also looking for a DD to set up a git project on Salsa 
(https://salsa.debian.org/debian/goldendict). Please also set 
myself (hosiet-guest) as "Master" role after that so that I 
could continue working on the packaging repo.

 * Package name: goldendict
   Version : 1.5.0~rc2+git20180412+ds-1
   Upstream Author : Abs62 
 * URL : goldendict.org
 * License : GPL-3+
   Section : utils

  It builds those binary packages:

goldendict - feature-rich dictionary lookup program

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

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

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

dget -x https://mentors.debian.net/debian/pool/main/g/
goldendict/goldendict_1.5.0~rc2+git20180412+ds-1.dsc

  Legacy git packaging repository:

https://anonscm.debian.org/git/collab-maint/
goldendict.git

  Changes since the last upload:

 goldendict (1.5.0~rc2+git20180412+ds-1) unstable; 
urgency=medium
 .
   [ Boyuan Yang ]
   * New upstream snapshot.
   * Bump Standards-Version to 4.1.4. (no changes needed)
   * Bump debhelper compat to v11.
   * d/control: Add new qtmultimedia5-dev build-dependency.


  Regards,
   Boyuan Yang

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

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

> 1) libcommons-lang3-java must be rebuild using openjdk-9 with docs and
> tests disabled
Then install the resulting deb binary.

> 2) rebuild with openjdk-10, keep doc and tests disabled
Or maybe with just tests disabled, I might have run with docs disabled
just to get a binary a bit faster. Tests must be disabled because for
some reason surefire seems to embed those classes into it's own jars
instead of using them from libcommons-lang3-java (otherwise installing
the deb binary from step #1 should have fixed it). And then, again,
install the resulting deb binary.

> 3) rebuild surefire with the new libcommons-lang3-java
It might also require the tests to be disabled IIRC. And then install
the deb binary.

> 4) rebuild libcommons-lang3-java with openjdk-10 with tests and docs enabled 
> (just to be sure it works)

surefire needs to be rebuild after uploading the deb binary from step #4.

Bug#895583: libcommons-lang3-java FTBFS due to unsupported locale type

[Tiago Daitx]

A debdiff with the fix has been provided in bug #895234 [1].

thanks

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

On Fri, Apr 13, 2018 at 12:32 AM, Tiago Stürmer Daitx
 wrote:
> Package: libcommons-lang3-java
> Version: 3.5-1
> Severity: normal
>
> Dear Maintainer,
>
> With bug #895234 [1] fixed, libcommons-lang3-java will FTBFS as bellow:
>
> [INFO] Running org.apache.commons.lang3.LocaleUtilsTest
> [ERROR] Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 
> 0.007 s <<< FAILURE! - in org.apache.commons.lang3.LocaleUtilsTest
> [ERROR] testParseAllLocales(org.apache.commons.lang3.LocaleUtilsTest)  Time 
> elapsed: 0.004 s  <<< ERROR!
> java.lang.IllegalArgumentException: Invalid locale format: ji_001
> at 
> org.apache.commons.lang3.LocaleUtilsTest.testParseAllLocales(LocaleUtilsTest.java:578)
>
> Which has been fixed upstream by LANG-1312 [2]. The patch provided in
> the bug report applies cleanly.
>
> A debdiff will be provided shortly.
>
>
> References:
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895234
> [2] https://issues.apache.org/jira/browse/LANG-1312
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers bionic
>   APT policy: (500, 'bionic'), (400, 'bionic-proposed')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.15.0-13-generic (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libcommons-lang3-java depends on:
> ii  libcommons-parent-java  43-1
>
> libcommons-lang3-java recommends no packages.
>
> Versions of packages libcommons-lang3-java suggests:
> pn  libcommons-lang3-java-doc  
>
> -- no debconf information



-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

Bug#895234: libcommons-lang3-java: update for OpenJDK 10 and OpenJDK 11

[Tiago Daitx]

On Sun, 8 Apr 2018 19:03:14 +0200 Matthias Klose  wrote:
> Package: src:libcommons-lang3-java
> Version: 3.5-1
> Severity: important
> Tags: patch sid buster
>
> Please either apply the following patches for 10 and 11, or update to the
> upstream 3.6 release, and only apply the latter patch for 11 (which will be in
> 3.7 upstream).
>
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=commitdiff_plain;h=a618b844c5a261ced37385ab3947de6e215d46f7
>
> https://git-wip-us.apache.org/repos/asf?p=commons-lang.git;a=patch;h=50ce8c44e1601acffa39f5568f0fc140aade0564
>

After applying the openjdk-10 patch libcommons-lang3-java will FTBFS
due to a NullPointerException in the surefire plugin:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
(default-test) on project commons-lang3: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
failed.: NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
(default-test) on project commons-lang3: Execution default-test of
goal org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test
failed.
at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:213)

at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-test of goal
org.apache.maven.plugins:maven-surefire-plugin:2.20.1:test failed.
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:145)

at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
Caused by: java.lang.NullPointerException
at 
org.apache.maven.surefire.shade.org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast
(SystemUtils.java:1626)


and then another FTBFS due to a failing locale test as reported in bug #895583.

The current bug also affects libmaven-javadoc-plugin-java.

In order to get the build working some additional steps are required
due to the circular runtime dependency between libcommons-lang3-java,
libmaven-javadoc-plugin-java (doc generation), and libsurefire-java
(tests):
1) libcommons-lang3-java must be rebuild using openjdk-9 with docs and
tests disabled
2) rebuild with openjdk-10, keep doc and tests disabled
3) rebuild surefire with the new libcommons-lang3-java
4) rebuild libcommons-lang3-java with openjdk-10

I believe it is easier to do a binary upload after the last step than
trying to get the builds to do that correctly. Note that it can't be
rebuild with openjdk-8 in step #1 due to a "Method
flip()Ljava/nio/ByteBuffer" error in bnd.

Hopefully I described all the required steps above without missing any
- I got sidetracked checking the openjdk-8 failure and testing the fix
in a few other packages, so it took me a while to remember everything
I had to run and install.

Please consider the attached debdiff as it fixes both this bug as well
as bug #895583.

thanks
Tiago
diff -Nru libcommons-lang3-java-3.5/debian/changelog libcommons-lang3-java-3.5/debian/changelog
--- libcommons-lang3-java-3.5/debian/changelog	2016-10-20 15:08:15.0 -0200
+++ libcommons-lang3-java-3.5/debian/changelog	2018-04-12 10:14:49.0 -0300
@@ -1,3 +1,16 @@
+libcommons-lang3-java (3.5-2) UNRELEASED; urgency=medium
+
+  * debian/patches/fix-openjdk-10-nullpointer-lang-1365.diff: calls to
+org.apache.commons.lang3.SystemUtils.isJavaVersionAtLeast cause
+NullPointerException when running under openjdk-10 which in turn causes
+other packages to FTBFS with the message "Execution default-cli of goal
+groupId:artifactId:version:jar failed.: NullPointerException -> [Help 1]".
+(Closes: #895234)
+  * debian/patches/fix-numeric-3-area-code-support-lang-1312.diff: pull
+upstream fix for numeric-3 area code support. (Closes: #895583)
+
+ -- Tiago Stürmer Daitx   Thu, 12 Apr 2018 13:14:49 +
+
 libcommons-lang3-java (3.5-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff
--- libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	1969-12-31 21:00:00.0 -0300
+++ libcommons-lang3-java-3.5/debian/patches/fix-numeric-3-area-code-support-lang-1312.diff	2018-04-12 10:14:49.0 -0300
@@ -0,0 +1,65 @@
+Description: Fix UN M.49 numeric-3 area code support.
+ LocaleUtils#toLocale does not support language followed by UN M.49 numeric-3
+ area code. 
+Author: pascalschumacher 
+Origin: upstream, https://github.com/apache/commons-lang/pull/239
+Bug: https://issues.apache.org/jira/browse/LANG-1312
+Bug-Debian: https://bug.debian.org/

Bug#895584: ITP: ell -- Embedded Linux library

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: ell
  Version : 0.4
  Upstream Author : Intel Corporation
* URL : https://01.org/ell
* License : LGPL-2.1
  Programming Lang: C
  Description : Embedded Linux library

The Embedded Linux* Library (ELL) provides core, low-level
functionality for system daemons. It typically has no dependencies
other than the Linux kernel, C standard library, and libdl
(for dynamic linking). While ELL is designed to be efficient and
compact enough for use on embedded Linux platforms, it is not
limited to resource-constrained systems.

Bug#895583: libcommons-lang3-java FTBFS due to unsupported locale type

[Tiago Stürmer Daitx]

Package: libcommons-lang3-java
Version: 3.5-1
Severity: normal

Dear Maintainer,

With bug #895234 [1] fixed, libcommons-lang3-java will FTBFS as bellow:

[INFO] Running org.apache.commons.lang3.LocaleUtilsTest
[ERROR] Tests run: 15, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.007 
s <<< FAILURE! - in org.apache.commons.lang3.LocaleUtilsTest
[ERROR] testParseAllLocales(org.apache.commons.lang3.LocaleUtilsTest)  Time 
elapsed: 0.004 s  <<< ERROR!
java.lang.IllegalArgumentException: Invalid locale format: ji_001
at 
org.apache.commons.lang3.LocaleUtilsTest.testParseAllLocales(LocaleUtilsTest.java:578)

Which has been fixed upstream by LANG-1312 [2]. The patch provided in
the bug report applies cleanly.

A debdiff will be provided shortly.


References:
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895234
[2] https://issues.apache.org/jira/browse/LANG-1312

-- System Information:
Debian Release: buster/sid
  APT prefers bionic
  APT policy: (500, 'bionic'), (400, 'bionic-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libcommons-lang3-java depends on:
ii  libcommons-parent-java  43-1

libcommons-lang3-java recommends no packages.

Versions of packages libcommons-lang3-java suggests:
pn  libcommons-lang3-java-doc  

-- no debconf information

Bug#891288: tiff: CVE-2018-7456: null pointer dereference

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

The issue was fixed upstream via 
https://gitlab.com/libtiff/libtiff/commit/be4c85b16e8801a16eec25e80eb9f3dd6a96731b

Regards,
Salvatore

Bug#466407: Automated way to get suite names

[Nye Liu]

It has now been 10 years.

I will work on this if someone can suggest a way to deterministically
map stable/testing to suite names.

Bug#895582: Use existing Debian packages for javascript and fonts files instead of including them

[ju]

Package: sphinx-bootstrap-theme
Version: 0.4.13-1

Building the package gives between others the lintian warnings:

embedded-javascript-library
duplicate-font-file

When this packages is included in any other package, it will also have
inherit these warnings.

Apart of lintian warnings, there're 2 versions of bootstrap included in
the package.

What is more, the size of the package increase a lot due to the unneeded
extra files.

Best,
ju.

Bug#895581: python3-fontconfig: Package seems to offer only limited access to the Fontconfig API. Suggest replacing it.

[Lawrence D'Oliveiro]

Package: python3-fontconfig
Severity: wishlist

Dear Maintainer,

The existing package offers only limited access to the Fontconfig API.
Might I suggest replacing it with my own wrapper
, which offers more complete
coverage at only a fraction of the source size?


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

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_NZ.utf8), LANGUAGE=en_NZ:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_NZ.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-fontconfig depends on:
ii  libc6   2.27-2
ii  libfontconfig1  2.12.6-0.1
ii  python3 3.6.4-1

python3-fontconfig recommends no packages.

python3-fontconfig suggests no packages.

Bug#895361: debirf: a system fails to boot: corrupted rootfs.cxz

[Daniel Kahn Gillmor]

On Thu 2018-04-12 13:28:34 +0200, Tzafrir Cohen wrote:
> Update: a new version of the patch. It now works and supports all
> compressors supported by busybox (I tried bzip2, gzip, lzma, lzop and
> xz). lzma and xz fail. Others work.

thanks for this work, Tzafrir!  I'd be willing to incorporate this as a
workaround, but i'm also always leery of introducing new control knobs
in any software (we have to educate the users that they're there -- and
we have to maintain the knobs!)

I'd feel more comfortable incorporating this workaround as a temporary
workaround if i knew that busybox was aiming to fix this.  have you
reported the problem to busybox upstream?

 --dkg


signature.asc
Description: PGP signature

Bug#895580: RFS: peek/1.3.1-1 [ITP] -- Simple animated GIF screen recorder with GUI

[Boyuan Yang]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "peek"

 * Package name: peek
   Version : 1.3.1-1
   Upstream Author : Philipp Wolfer 
 * URL : https://github.com/phw/peek
 * License : GPL-3+
   Section : graphics

  It builds those binary packages:

peek  - Simple animated GIF screen recorder with GUI

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

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


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

dget -x https://mentors.debian.net/debian/pool/main/p/peek/peek_1.3.1-1.dsc

  Salsa packaging repository:

https://salsa.debian.org/hosiet-guest/peek.git

  Changes since the last upload:

 peek (1.3.1-1) unstable; urgency=medium
 .
   * Initial release. Closes: #855666

--
  Regards,
  Boyuan Yang

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

Bug#895579: jenkins.debian.org: reproducible: ready to re-deploy odxu4c

[Vagrant Cascadian]

Package: jenkins.debian.org
Severity: normal

Finally found the time to reinstall odxu4c-armhf-rb.debian.net.

Hostname and ssh port (2233) are the same. I *think* all or most of the
the configuration is still in git, so just needs to be re-deployed.

New ssh key fingerprints:

  256 SHA256:sW744ScGvFoq9BCN5RexnA5M5GNU/fnc0RaIeyUQpjE root@odxu4c (ED25519)
  2048 SHA256:fFOIWNNxO3cW0tg5Yqkd0zgoL5lMe4OJD133KkiWOhQ root@odxu4c (RSA)


Or the full public keys:

  ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBEFPge/3eGASKg3WDV1t2i6FKbuxLoirjIHKJY2mN8hYEqHG1we63U0ojT39NXe4LDZPx7aWWvPCpYoBqbXReOQ=
 root@odxu4c
  ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCcgNfdqH4Bqg1xdS1ENi8wM3sCMPIiBPQSS5l3Xylo5o4Vp5+zdFKJD0Jf4gG84k429gw4nAnXrNXmWQHSHnIr7B24hA8fY+A64tnSFcFV6Q4MAklVCWCmrTDh3M2d6SE32QdosCsALfU8sQ+PsBVN4k6AS32R2Sx6+UN8GV3KL2Cdm9NzFTJbNQmjB18NR+2i/wB2ubnHfs6YFiLuPm+n3aJ6kidwoxMqQdNY+zxJ5XEjCa3cNr/+WxQHLR3xkTrvueh8VLPbwjHcBfT+eIhAHgTkaA/iV/BunzVSD+1CKWfGeSHkK4WdgE8uQKqupjJ08QHv3tNXX4J2p+fToryd
 root@odxu4c


Keep on reproducibly building!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#895578: kakoune: Please update to official release v2018.04.13

[Timothy Allen]

Package: kakoune
Version: 0~2016.12.20.1.3a6167ae-1
Severity: wishlist

After many years of continuous, undifferentiated development, Kakoune
has started tagging particular snapshots as stable releases. It would
be great to have a more up-to-date version of Kakoune in Debian!

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

Kernel: Linux 4.14.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages kakoune depends on:
ii  libboost-regex1.62.0  1.62.0+dfsg-5
ii  libc6 2.27-3
ii  libgcc1   1:8-20180402-1
ii  libncursesw5  6.1-1
ii  libstdc++68-20180402-1
ii  libtinfo5 6.1-1

kakoune recommends no packages.

kakoune suggests no packages.

-- no debconf information

Bug#879619: Autopkgtest for ncbi-tools6

[Aaron M. Ucko]

Liubov Chuprikova  writes:

> On Thu, 12 Apr 2018 at 17:30 Aaron M. Ucko  wrote:
>
>>
>> That said, you did catch a bug in taxblast; I'll push a fix this
>> evening.  (The binary will still require a network connection, just
>> actually be able to use it now).
>>
>
> Ok, thank you!

Fix pushed, no problem.  I'd also be happy to sponsor the upload if
you'd like.

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#895429: nvidia-kernel-dkms: doesn't build with linux 4.16 from experimental (missing symbol swiotlb_map_sg_attrs)

[Luca Boccassi]

Control: tags -1 pending

On Thu, 2018-04-12 at 03:03 +0200, Jiri Palecek wrote:
> On 4/11/18 4:07 PM, Luca Boccassi wrote:
> > On Wed, 11 Apr 2018 14:57:56 +0200 Jiri Palecek 
> > wrote:
> > > Package: nvidia-kernel-dkms
> > > Version: 390.42-1
> > > Severity: normal
> > >   
> > 
> > 390.48 has been in unstable and testing for a while, have you tried
> > with it?
> > 
> 
> In unstable, not testing. Anyway, I just tried it and it's just the
> same.
> 
> Regards
> 
>  Jiri Palecek

Ok, patch tested and committed to SVN, will be available with the next
upload.

-- 
Kind regards,
Luca Boccassi

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

Bug#895474: Fontconfig errors

[brian m. carlson]

On Thu, Apr 12, 2018 at 07:08:23PM +0200, Emilio Pozuelo Monfort wrote:
> On 12/04/18 04:01, brian m. carlson wrote:
> > I've also seen these errors, except that they're showing up in my tmux
> > panes, which is significantly more annoying than .xsession-errors.  This
> > is probably because vim-gtk3 (gvim) links to libfontconfig1.
> > 
> > libfontconfig definitely shouldn't be producing errors to stdout or
> > stderr unless specifically requested by the calling application.
> 
> Have you restarted your applications? AFAICS this is caused by old 
> libfontconfig
> reading the new conf files. If you restart them the warnings should go away.
> 
> (I know this isn't an ideal solution)

No, I haven't.  I upgraded from within my tmux session and suddenly all
my panes had junk in them.  I don't normally log out or reboot except
for kernel updates.

I would appreciate it if you'd work with upstream to get them to remove
the code that prints these messages.  There's no legitimate reason for a
shared library to print anything unless explicitly requested by the
calling application .

This would be less of an issue if fontconfig didn't reload config files
in existing processes.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Bug#895247: libgnomecanvas: Intent to Adopt

[Simon McVittie]

On Thu, 12 Apr 2018 at 23:32:45 +0300, Adrian Bunk wrote:
> On Thu, Apr 12, 2018 at 06:09:32PM +0100, Simon McVittie wrote:
> > particularly if you plan to modify things that are annoying to do via
> > a patch series, like the build system.
> 
> I do not see any reason for changing something like the build system.

Perhaps I was overestimating how much is needed to make it work with the
current (i.e. 2015) gnome-common package. It seems to have been part of
the mass-bug-filing for uses of deprecated or removed macros, but maybe
it only used the deprecated macros and not the removed ones.

> > Because these packages mention "gnome" in their names, it would be great
> > if you could reduce confusion by modifying their Description to clarify
> > that they are no longer considered to be part of (current) GNOME.
> 
> Makes sense (similar to e.g. #887783).

Yes, and more recently #895348. We haven't historically been very good
at making packages that are no longer part of GNOME self-documenting
(updating Description fields, moving deprecated libraries to oldlibs,
etc.) because people tend to prioritize the (current) key packages,
so I'm trying to catch up on several years of Description fixes and
oldlibs overrides at the moment.

smcv

Bug#803621: [xserver-xorg-legacy]

[Antonio Russo]

Control: close -1

This log entry doesn't appear any more.

Bug#751421: [ipython]

[Antonio Russo]

Control: close -1

The file in this bug report no longer exists in the package, so this is 
completely resolved.

Bug#895397: josm: fails to start

[Patrick Noll]

Following was tried and no change:
update-java-alternatives -s java-1.9.0-openjdk-amd64
JAVA_OPTS="-Djosm.home=${HOME}/.josm-new-home" josm
uninstalling openjdk-8
running josm with root

Tried and was moderately successful:
running josm using openjdk-8 : splash screen showed, plugins updated, main 
screen shows, osm downloader would still fail

Tried and Successful:
Download josm-tested.jar from josm website and run it from ~/Downloads using 
openjdk-9


Pat


​Sent with ProtonMail Secure Email.​

‐‐‐ Original Message ‐‐‐

On April 10, 2018 11:55 PM, Bas Couwenberg  wrote:

> Control: severity -1 important
> 
> Control: tags -1 moreinfo unreproducible
> 
> On 2018-04-11 08:09, patrick noll wrote:
> 
> > JOSM fails when trying to launch from menu or cli and returns pop up
> > 
> > with following info:
> 
> I cannot reproduce this issue, josm works as expected on my system.
> 
> Ensure that you have configured openjdk-9 as the default:
> 
> update-java-alternatives -s java-1.9.0-openjdk-amd64
> 
> If the issue persists try starting josm with a clean profile:
> 
> JAVA_OPTS="-Djosm.home=${HOME}/.josm-new-home" josm
> 
> If that works, there is probably a plugin, setting or other file in your
> 
> JOSM directory that breaks the new version.
> 
> Kind Regards,
> 
> Bas

Bug#895246: gconf: Intent to Adopt

[Simon McVittie]

On Thu, 12 Apr 2018 at 23:12:44 +0300, Adrian Bunk wrote:
> On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> > - src:orbit2 (orphaned library needed by gconf)
> > - src:libidl (orphaned library needed by orbit2)
> 
> Where does gconf depend on these?

I thought it did, but that was incorrect. The protocol it uses behind the
scenes was switched from CORBA to D-Bus before upstream maintenance ended.

If someone (you or otherwise) wants to keep libgnome, libgnomeui or
libbonobo* alive, *that* is the dependency tree that would require
orbit2 and libidl (the "Network Object Model" part of the original
expansion of the GNOME acronym).

smcv

Bug#895564: CVE-2017-2896 CVE-2017-2897 CVE-2017-2919

[Dirk Eddelbuettel]

Further update. I took some files from the new (in-progress, unfinished it
seems) upstream of libxls at https://github.com/evanmiller/libxls/, and got
some advice from the libxls maintainer.

He also put new issue tickets up, one per CVE:
https://github.com/evanmiller/libxls/issues

And that builds.  It does not pass all unit tests (R / CRAN packages tend to
have lots of those) but 'almost': 4 fail, 348 pass.

We could release this, methinks.  What is your recommendation (and it has
been years since I last had to do a security release so help is as always
appreciated).

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#895464: dnss FTBFS: FAIL: TestEndToEnd

[Alberto Bertogli]

On Wed, Apr 11, 2018 at 10:29:32PM +0300, Adrian Bunk wrote:

Source: dnss
Version: 0.0~git20170810.0.860d2af1-1
Severity: serious

Some recent change in unstable makes dnss FTBFS:

https://tests.reproducible-builds.org/debian/history/dnss.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/dnss.html

...
=== RUN   TestEndToEnd
--- FAIL: TestEndToEnd (0.00s)
dnss_test.go:107: error parsing zone: dns: missing TTL with no previous value: 
"A" at line: 1:13


Thanks for letting me know about this.

This was fixed on 2017-10-03 by commit befaea2, I'm surprised it did not 
come up earlier.


https://blitiri.com.ar/git/r/dnss/c/befaea21c4632c7c4fd9988065ccde39d271573e/


I've been making some changes to dnss lately and wanted to advance the 
Debian package soon, so another option is to wait ~a couple of days and 
just make a more up to date package that includes that fix.


Thanks,
Alberto

Bug#895224: pdf-presenter-console: [regression] after upgrading to GStreamer 1.14.0, fails to play movies

[Francesco Poli]

Control: forwarded -1 https://github.com/pdfpc/pdfpc/issues/339


On Thu, 12 Apr 2018 16:16:33 +0100 Barak A. Pearlmutter wrote:

> Okay,

Barak, thanks a lot for following up on my bug report.
This is really appreciated.

> I've opened an upstream issue for this.

Thanks a lot for this, I am adding the forwarded URI to the bug log.

> 
> I'm in the process of building a new package with the latest upstream
> development branch merged, it will be 4.1-3, if you could install and
> test this

I see that it is already in sid, I have just installed it from there.

Unfortunately, I still the same lack of movie playing capability.
The messages printed on the terminal are very similar to the ones
produced by pdf-presenter-console/4.1-2 (see the attached text file).

[...]
> It also might be helpful if you let us know if you're running under
> Wayland; this is an easy way to check.
> 
> $ printenv | egrep WAY
> WAYLAND_DISPLAY=wayland-0

  $ printenv | egrep WAY

No output is generated, and indeed I am running under a "normal" X
session.


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

(pdfpc:8845): GLib-GObject-CRITICAL **: 23:50:16.101: g_object_get: assertion 
'G_IS_OBJECT (object)' failed

(pdfpc:8845): GStreamer-CRITICAL **: 23:50:16.176: gst_element_link_pads_full: 
assertion 'GST_IS_ELEMENT (dest)' failed

(pdfpc:8845): Gtk-CRITICAL **: 23:50:16.176: gtk_widget_add_events: assertion 
'GTK_IS_WIDGET (widget)' failed

(pdfpc:8845): GLib-GObject-WARNING **: 23:50:16.176: invalid (NULL) pointer 
instance

(pdfpc:8845): GLib-GObject-CRITICAL **: 23:50:16.176: g_signal_connect_object: 
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(pdfpc:8845): GLib-GObject-WARNING **: 23:50:16.176: invalid (NULL) pointer 
instance

(pdfpc:8845): GLib-GObject-CRITICAL **: 23:50:16.176: g_signal_connect_object: 
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(pdfpc:8845): GLib-GObject-WARNING **: 23:50:16.176: invalid (NULL) pointer 
instance

(pdfpc:8845): GLib-GObject-CRITICAL **: 23:50:16.176: g_signal_connect_object: 
assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(pdfpc:8845): GLib-GObject-CRITICAL **: 23:50:16.176: g_object_set: assertion 
'G_IS_OBJECT (object)' failed

** (pdfpc:8845): CRITICAL **: 23:50:16.176: pdfpc_view_video_add_video: 
assertion 'video != NULL' failed

(pdfpc:8845): Gtk-CRITICAL **: 23:50:16.526: gtk_widget_set_opacity: assertion 
'GTK_IS_WIDGET (widget)' failed
Gstreamer error Internal data stream error.
Gstreamer error Internal data stream error.

(pdfpc:8845): Gtk-CRITICAL **: 23:50:17.232: gtk_widget_set_opacity: assertion 
'GTK_IS_WIDGET (widget)' failed

(pdfpc:8845): Gtk-CRITICAL **: 23:50:21.460: gtk_widget_get_parent: assertion 
'GTK_IS_WIDGET (widget)' failed

** (pdfpc:8845): CRITICAL **: 23:50:21.460: pdfpc_view_video_remove_video: 
assertion 'self != NULL' failed



pgp7uvyhEam84.pgp
Description: PGP signature

Bug#895574: lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf

[Chris Lamb]

tags 895574 + moreinfo
thanks

Hi Jeremy,

Thanks for the report!

> armhf is a bit different than the other Ubuntu architectures because
> it uses a different kind of virtualization

I suspect the underlying problem is that we are not detecting
profiling information on armhf correctly. The relevant code is:

  
https://salsa.debian.org/lintian/lintian/blob/master/checks/binaries.pm#L192-207

I have attached the "readelf -WltdVs" output of "basic.c" compiled
on the harris.debian.org porterbox.

Whilst I see a "GLIBC_" section, I do see an mcount:

117:  0 FUNCGLOBAL DEFAULT  UND __gnu_mcount_nc@@GLIBC_2.8

Can someone with some ELF knowledge chime in here? :)


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
There are 30 section headers, starting at offset 0x1cc8:

Section Headers:
  [Nr] Name
   TypeAddr OffSize   ES   Lk Inf Al
   Flags
  [ 0] 
   NULL 00 00 00   0   0  0
   []: 
  [ 1] .interp
   PROGBITS00010154 000154 19 00   0   0  1
   [0002]: ALLOC
  [ 2] .note.ABI-tag
   NOTE00010170 000170 20 00   0   0  4
   [0002]: ALLOC
  [ 3] .note.gnu.build-id
   NOTE00010190 000190 24 00   0   0  4
   [0002]: ALLOC
  [ 4] .gnu.hash
   GNU_HASH000101b4 0001b4 60 04   5   0  4
   [0002]: ALLOC
  [ 5] .dynsym
   DYNSYM  00010214 000214 f0 10   6   1  4
   [0002]: ALLOC
  [ 6] .dynstr
   STRTAB  00010304 000304 c2 00   0   0  1
   [0002]: ALLOC
  [ 7] .gnu.version
   VERSYM  000103c6 0003c6 1e 02   5   0  2
   [0002]: ALLOC
  [ 8] .gnu.version_r
   VERNEED 000103e4 0003e4 30 00   6   1  4
   [0002]: ALLOC
  [ 9] .rel.dyn
   REL 00010414 000414 08 08   5   0  4
   [0002]: ALLOC
  [10] .rel.plt
   REL 0001041c 00041c 38 08   5  22  4
   [0042]: ALLOC, INFO LINK
  [11] .init
   PROGBITS00010454 000454 0c 00   0   0  4
   [0006]: ALLOC, EXEC
  [12] .plt
   PROGBITS00010460 000460 6c 04   0   0  4
   [0006]: ALLOC, EXEC
  [13] .text
   PROGBITS000104d0 0004d0 0001d8 00   0   0  8
   [0006]: ALLOC, EXEC
  [14] .fini
   PROGBITS000106a8 0006a8 08 00   0   0  4
   [0006]: ALLOC, EXEC
  [15] .rodata
   PROGBITS000106b0 0006b0 11 00   0   0  4
   [0002]: ALLOC
  [16] .ARM.exidx
   ARM_EXIDX   000106c4 0006c4 08 00  13   0  4
   [0082]: ALLOC, LINK ORDER
  [17] .eh_frame
   PROGBITS000106cc 0006cc 04 00   0   0  4
   [0002]: ALLOC
  [18] .init_array
   INIT_ARRAY  00020f04 000f04 04 04   0   0  4
   [0003]: WRITE, ALLOC
  [19] .fini_array
   FINI_ARRAY  00020f08 000f08 04 04   0   0  4
   [0003]: WRITE, ALLOC
  [20] .jcr
   PROGBITS00020f0c 000f0c 04 00   0   0  4
   [0003]: WRITE, ALLOC
  [21] .dynamic
   DYNAMIC 00020f10 000f10 f0 08   6   0  4
   [0003]: WRITE, ALLOC
  [22] .got
   PROGBITS00021000 001000 48 04   0   0  4
   [0003]: WRITE, ALLOC
  [23] .data
   PROGBITS00021048 001048 08 00   0   0  4
   [0003]: WRITE, ALLOC
  [24] .bss
   NOBITS  00021050 001050 08 00   0   0  4
   [0003]: WRITE, ALLOC
  [25] .comment
   PROGBITS 001050 2d 01   0   0  1
   [0030]: MERGE, STRINGS
  [26] .ARM.attributes
   ARM_ATTRIBUTES   00107d 33 00   0   0  1
   []: 
  [27] .symtab
   SYMTAB   0010b0 000780 10  28  92  4
   []: 
  [28] .strtab
   STRTAB   001830 00038e 00   0   0  1
   []: 
  [29] .shstrtab
   STRTAB   001bbe 00010a 00   0   0  1
   []: 

Elf file type is EXEC (Executable file)
Entry point 0x104d1
There are 9 program headers, starting at offset 52

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  EXIDX  0x0006c4 0x000106c4 0x000106c4 0x8 0x8 R   0x4
  PHDR   0x34 0x00010034 0x00010034 0x00120 0x00120 R E 0x4
  INTERP 0x000154 0x00010154 0x00010154 0x00019 0x00019 R   0x1
  [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
  LOAD   0x00 0x0001 0x0001 0x006d0 0x006d0 R E 0x1
  LOAD   0x000f04 0x00020f04 0x00020f04 0x0014c 0x00154 RW  0x1
  DYNAMIC0x000f10 0x00020f10 0x00020f10 0x000f0 0x000f0 RW  0x4
  NOTE   0x000170 0x00010170 0x00010170 0x00044 0x00044 R   0x4
  GNU_STACK  0x00 0x 0x 0x0 0x0 RW  0x10
  GNU_RELRO  0x000f04 0x00020f04 0x00020f04 0x000fc 

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[peter green]

tags 893515 +patch
thanks


I am currently doing a final build with the changes, assuming it suceeds I will 
upload it to Raspbian and post a
debdiff to this bug.

debdiff can be found at 
http://debdiffs.raspbian.org/main/d/digikam/digikam_5.7.0-2+rpi1.debdiff

Bug#895577: libdbusmenu: Please add ia64 and riscv64 to the list of ports without valgrind

[Adrian Bunk]

Source: libdbusmenu
Version: 16.04.1+17.04.20170109.1-5
Severity: normal

Please add ia64 and riscv64 to the list of ports without valgrind,
neither port is likely to have valgrind soon.

Thanks in advance

Bug#895575: Register of interest

[Daniele Adriana Goulart Lopes]

I would like to participate in this list.

Bug#513967:

[Jonas Smedegaard]

Excerpts from Vasyl Vavrychuk's message of april 12, 2018 11:01 pm:

licensecheck seems not checking at the end by default because for
https://raw.githubusercontent.com/lua/lua/master/lua.h I get

licensecheck lua.h
lua.h: UNKNOWN


Oh.  Looks like the --tail option is broken. :-/

I normally use --lines 0 (and testsuite is incomplete), so didn't notice 
this myself.



Maybe described feature is needed for reporter of this bug. Also if we 
want to have fully automated way to licensecheck of all Debian 
packages than we need it.


It is (slower but) more reliable to use "--lines 0".


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

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


pgpazNBQLtbAt.pgp
Description: PGP signature

Bug#895573: lintian: please add spelling check: “toogle” (toggle)

[Chris Lamb]

tags 895573 + pending
thanks

Hi Thorsten,

Thanks for the report. :)  Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/9cf4619805c169dd6730ce7d176c2c55e4d1b6af

  data/spelling/corrections | 1 +
  debian/changelog  | 4 
  2 files changed, 5 insertions(+)


Regards,

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

Bug#895553: sphinx: please make the set object description reproducible

[Chris Lamb]

Hi,

> sphinx: please make the set object description reproducible

Please note that I have now updated the patch on my pull request to
address some test failures and rebase it against the latest version
(which may make it suitable for experimental).


Best wishes,

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

Bug#895576: haskell-uulib: FTBFS with GHC 8.2

[Clint Adams]

Source: haskell-uulib
Version: 0.9.20-5
Severity: serious

Doesn't build with GHC 8.2.

Bug#895550: Cannot enable systemd units in a chroot

[Enrico Zini]

On Thu, Apr 12, 2018 at 10:33:38PM +0200, Enrico Zini wrote:

> On the other hand, is-enabled works without /proc, so it looks like
> ansible's systemd module is running systemd in ways that can't work
> inside a chroot:
> 
> # ls -la /proc
> total 8
> drwxr-xr-x  2 root root 4096 Feb 23 23:23 .
> drwxr-xr-x 21 root root 4096 Apr 11 14:02 ..
> # systemctl is-enabled systemd-networkd
> disabled

I had a look with strace, and ansible is trying to run systemd commands
that would not work in a chroot:

$ sudo strace -f -o trace ansible-playbook -v -i inventory.ini chroot.yaml
$ grep execve.\\+systemctl trace
2386  execve("/bin/systemctl", ["/bin/systemctl", "show", 
"systemd-networkd.service"], 0x556a1d6423a0 /* 20 vars */ 
2387  execve("/bin/systemctl", ["/bin/systemctl"], 0x556a1d6423a0 /* 20 vars */ 


Only enable/disable/is_enabled/mask/unmask are supposed to work, as far
as I understand.



Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#876415: Bugfix release v1.2.1

[Nicholas D Steeves]

Control: fixed -1 kdeconnect/1.3.0-1


signature.asc
Description: PGP signature

Bug#895575: Register of interest

[foz]

I would like to register here, my wish to have this list.




signature.asc
Description: OpenPGP digital signature

Bug#895575: lists.debian.org: Request for a new mailing list: debian-mulheres (debian-woman for Portuguese speakers)

[Helen Koike]

Package: lists.debian.org
Severity: wishlist

Dear Maintainer,

Name:
-
debian-mulheres


Rationale:
-
The following women present at the MiniDebConf at Curitiba Brazil:
* Helen Koike 
* Foz 
* Renata (rsip22) 
* Ana Mendes 
would like to create a version of debian women list for Portuguese
speakers to promote diversity in Debian (mainly in Brazil) and to remove
a possible language barrier for newcomers.
FYI: Mulheres means women in Portuguese


Short description:
-
Debian women for Portuguese speakers


Long description:
-
Debian users and developers who wish to involve more women,
trans, non-binary and gender non-conforming in the Debian project. For
discussion and sharing of ideas as well as project collaboration in
Portuguese.


Category

Miscellaneous Debian


Subscription Policy
---
Open


Post Policy
---
Open


Web Archive
---
Yes


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

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

Bug#513967:

[Vasyl Vavrychuk]

licensecheck seems not checking at the end by default because for
https://raw.githubusercontent.com/lua/lua/master/lua.h I get

licensecheck lua.h
lua.h: UNKNOWN

Maybe described feature is needed for reporter of this bug. Also if we
want to have fully automated way to licensecheck of all Debian
packages than we need it.


On Thu, Apr 12, 2018 at 5:56 PM, Jonas Smedegaard  wrote:
> Excerpts from Vasyl Vavrychuk's message of april 12, 2018 9:54 am:
>>
>> How about licensecheck detects pattern "See Copyright Notice at the end of
>> this file" and goes LICENSECHECK_PARSELINES from the end to look for a
>> license.
>
>
> Heh - that's a clever idea.
>
> I worry it might be too clever, though: It would complicate processing by
> needing to backtrack and rescan based on output of scanning.  Not very
> complicated but I would prefer to keep processing logic simple if possible.
>
> Also, is it really needed? codesearch.debian.org has only ~100 hits for that
> pattern, and I believe licensecheck already by default checks at the end
> too.
>
> Could you perhaps point at some real live examples where you believe this
> kind of mechanism would be useful?
>
>
> Thanks,
>
> - Jonas
> --
> * Jonas Smedegaard - idealist & Internet-arkitekt
> * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
> [x] quote me freely  [ ] ask before reusing  [ ] keep private

Bug#895574: lintian: binary-compiled-with-profiling-enabled test fails on Ubuntu's armhf

[Jeremy Bicha]

Source: lintian
Version: 2.5.81

Ubuntu runs its autopkgtests for all of its supported architectures.
One of lintian's tests (binary-compiled-with-profiling-enabled) fails
when the autopkgtest is run on armhf.

armhf is a bit different than the other Ubuntu architectures because
it uses a different kind of virtualization (sorry I don't remember the
details); not sure if that's relevant here or not.

You can see the test failures at
http://autopkgtest.ubuntu.com/packages/l/lintian/bionic/armhf

I'm letting you know that this issue prevents Ubuntu from being able
to automatically sync lintian, but instead we need to maintain a
manual diff. See http://ubuntudiff.debian.net/?query=-FPackage+lintian

Thanks,
Jeremy Bicha

Bug#895571: transition: http-parser

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> Go ahead.

Thanks for the swift response, much appreciated. Now uploaded to
unstable.

Christoph


signature.asc
Description: PGP signature

Bug#895573: lintian: please add spelling check: “toogle” (toggle)

[Thorsten Glaser]

Package: lintian
Version: 2.5.81
Severity: wishlist

Hi,

I’ve just seen a patch doing s/Toogle/Toggle/ in a package,
and lintian doesn’t check for “toogle” currently, so I thought
to report in case it might get added ;-)

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

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.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.30-8
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1
ii  dpkg  1.19.0.5
ii  file  1:5.32-2
ii  gettext   0.19.8.1-6
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.99-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-5
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.73-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.3-2
ii  patchutils0.3.4-2
ii  perl  5.26.1-5
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

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

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-8
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
pn  libtext-template-perl  

-- no debconf information

Bug#890791: Progress?

[Wesley W. Terpstra]

Has there been any progress on this issue?

I maintain a package with an explicit Architecture list and I wanted
to port it to my new riscv64 system, but I can't upload the new source
package to unstable because it mentions riscv64 in the control file.
It's quite frustrating that backporting this to dak is blocking
packages from adding support to source which could otherwise be
compiled by the debian-ports infrastructure...

Thanks for looking into this

Bug#895247: libgnomecanvas: Intent to Adopt

[Adrian Bunk]

On Thu, Apr 12, 2018 at 06:09:32PM +0100, Simon McVittie wrote:
> On Thu, 12 Apr 2018 at 15:03:11 +0200, Gert Wollny wrote:
> > Hi Adrian, 
> 
> (Adrian won't have seen this unless he's subscribed to the bug or
> package, because bug submitters don't normally get copies of bug mail
> in the Debian BTS; adding him to Cc.)

Thanks.

> > as the maintainer of amide[1], a package that depends on libgnomecanvas
> > I was also already thinking about adopting this package and libart-
> > lgpl. In other words I'd happily join to co-maintain these two
> > packages. 

I am not a huge fan of co-maintaining low-effort packages,[1]
either you or me maintaining a package would be fine for me.

> Do you (either or both of you) also intend to adopt the language bindings
> src:libgnomecanvasmm2.6 (in theory currently maintained by Deng Xiyue,
> most recent maintainer upload 2009)?

Good point, I haven't yet looked at these.

> Everything I said below "My concern about keeping packages like gconf"
> in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895246#10 applies
> equally here. If, having considered that, you still want to adopt these
> libraries, I don't think anyone will stop you.

Thanks.

> Both libgnomecanvas and libgnomecanvasmm are listed as "archived"
> in GNOME git, so they have no upstream maintainer. If you adopt them,
> you will be the closest thing there is to their upstream maintainer;
> it might be a good idea to start a new upstream project (forked from
> the archived GNOME source code) that other distributions can share,
> particularly if you plan to modify things that are annoying to do via
> a patch series, like the build system.

I do not see any reason for changing something like the build system.

Looking at the currently applied patches and the BTS, libgnomecanvas
in buster might apply up to 5 one-line patches to the upstream sources.

> Because these packages mention "gnome" in their names, it would be great
> if you could reduce confusion by modifying their Description to clarify
> that they are no longer considered to be part of (current) GNOME.

Makes sense (similar to e.g. #887783).

>...
> smcv

cu
Adrian

[1] it often just makes it harder to discover that all people are MIA

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#895550: Cannot enable systemd units in a chroot

[Enrico Zini]

On Thu, Apr 12, 2018 at 10:19:44PM +0200, Enrico Zini wrote:

> I found that systemctl wants /proc to be mounted in order to detect it's
> running in a chroot:
> 
>   # systemctl
>   Failed to connect to bus: No such file or directory
>   # mount -t proc none /proc
>   # systemctl
>   Running in chroot, ignoring request.
> 
> I wonder if it's supposed to do that, or if it's a bug in systemctl.

On the other hand, is-enabled works without /proc, so it looks like
ansible's systemd module is running systemd in ways that can't work
inside a chroot:

# ls -la /proc
total 8
drwxr-xr-x  2 root root 4096 Feb 23 23:23 .
drwxr-xr-x 21 root root 4096 Apr 11 14:02 ..
# systemctl is-enabled systemd-networkd
disabled


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Aurelien Jarno]

On 2018-04-12 19:41, Holger Levsen wrote:
> control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy 
> no-change-except-d/changelog-uploads"
> # I hope this is correct, realistic and accurate ;)
> # if not, please fixup?
> #thanks

That can't be done on the wanna-build side, uploads to the archive needs
to be signed. Time to reassign this bug to ftp.debian.org?

Aurelien

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


signature.asc
Description: PGP signature

Bug#895550: Cannot enable systemd units in a chroot

[Enrico Zini]

On Thu, Apr 12, 2018 at 03:36:55PM +0200, Enrico Zini wrote:


> TASK [systemd : enable systemd-networkd]
> ***
> fatal: [./chroot]: FAILED! => {"changed": false, "cmd": "/bin/systemctl", 
> "msg": "Failed to connect to bus: No such file or directory", "rc": 1, 
> "stderr": "Failed to connect to bus: No such file or directory\n", 
> "stderr_lines": ["Failed to connect to bus: No such file or directory"], 
> "stdout": "", "stdout_lines": []}
>   to retry, use: --limit 
> @/home/enrico/lavori/truelite/system/live/chroot.retry

I found that systemctl wants /proc to be mounted in order to detect it's
running in a chroot:

  # systemctl
  Failed to connect to bus: No such file or directory
  # mount -t proc none /proc
  # systemctl
  Running in chroot, ignoring request.

I wonder if it's supposed to do that, or if it's a bug in systemctl.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Bug#836266: dirmngr: Please disable "use-tor" by default.

[Phil Morrell]

Package: parcimonie
Version: 0.10.2-4
Followup-For: Bug #836266

I want to add my 2c to this bug report, sharing the same user
frustrations as anarcat above. I don't know if any more recent tooling
versions (be that parcimonie, dirmngr, gnupg, torsocks) have improved
the situation, as it's not in stretch-backports.

In the absence of a longer term solution, parcimonie should respect user
edits to dirmngr.conf i.e. I don't have a massive objection to it adding
use-tor initially, but if I've removed it (perhaps temporarily to
receive a single key without tor errors), then don't get into an editing
war with me. I'm even happy if this disables parcimonie until I put it
back (with a log window message).

When I see the parcimonie log error:

Failed to fetch key 6ACBAD6A729326258CF725C6E7519C8D747F00DC: gpg: 
keyserver receive failed: No data
 at /usr/share/perl5/App/Parcimonie/Daemon.pm line 350.

I now run this to fix the tor connections:

systemctl --user restart dirmngr.socket

I realise this is a dirmngr issue, but it's also a parcimonie issue as a
"privacy-friendly helper to refresh a GnuPG keyring" which is likely to
be run by people like me trying to get into best practices. You said
above you're unsure "what to do with this bug report", at the very least
I'd like it documented in the man-page (if my workaround above is
correct in the general case). Ideally in the short to medium term,
parcimonie could detect a series of sequential (likely) tor-related
errors and explicitly write this in the logs, perhaps with the socket
restart recommendation, perhaps lengthening the sleep to e.g. 2hrs so it
can be fixed in user scale time.

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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages parcimonie depends on:
ii  dirmngr  2.1.18-8~deb9u1
ii  gnupg2.1.18-8~deb9u1
ii  gnupg2   2.1.18-8~deb9u1
ii  libclone-perl0.38-2+b1
ii  libconfig-general-perl   2.63-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-which-perl   1.21-1
ii  libgnupg-interface-perl  0.52-9
ii  libipc-system-simple-perl1.25-3
ii  liblist-moreutils-perl   0.416-1+b1
ii  libmoo-perl  2.002005-1
ii  libmoox-late-perl0.015-2
ii  libmoox-options-perl 4.023-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.100-1
ii  libtime-duration-parse-perl  0.13-1
ii  libtry-tiny-perl 0.28-1
ii  libtype-tiny-perl1.05-1
ii  libtypes-path-tiny-perl  0.005-1
ii  perl 5.24.1-3+deb9u2
ii  torsocks 2.2.0-1+deb9u1

Versions of packages parcimonie recommends:
pn  gnupg-curl  
ii  libglib-perl3:1.324-1
ii  libgtk3-perl0.030-1
ii  liblocale-gettext-perl  1.07-3+b1
ii  libnet-dbus-glib-perl   0.33.0-2+b1
ii  libnet-dbus-perl1.1.0-4+b1
ii  libpango-perl   1.227-1+b1
ii  libtime-duration-perl   1.20-1
ii  tor 0.2.9.14-1

parcimonie suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

On Thu, Apr 12, 2018 at 10:09:44PM +0200, Emilio Pozuelo Monfort wrote:
> On 12/04/18 21:41, Holger Levsen wrote:
> > control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy 
> > no-change-except-d/changelog-uploads"
> > # I hope this is correct, realistic and accurate ;)
> > # if not, please fixup?
> > #thanks
> Removing binNMUs would be a problem whenever we need to do a large amount of
> rebuilds on just one architecture, e.g. due to a toolchain bug, a baseline 
> bump,
> or other reasons.

sure, hence the word "easy" in the bug title.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#895246: gconf: Intent to Adopt

[Adrian Bunk]

On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> (I don't speak for the GNOME team, or for Josselin, who is officially
> this package's maintainer; please don't assume I do.)
> 
> On Sun, 08 Apr 2018 at 22:19:43 +0300, Adrian Bunk wrote:
> > I hereby declare my intent to adopt gconf.
> 
> Thank you for offering to take over this package. Do you also intend
> to adopt these related packages?
> 
> - src:gconf-editor (which depends on gconf and is useless without it;
>   currently maintained by the GNOME team)

Makes sense.

> - src:orbit2 (orphaned library needed by gconf)
> - src:libidl (orphaned library needed by orbit2)

Where does gconf depend on these?

> - various language bindings for gconf

Good point, I haven't yet looked at these.

>...
> Do you use software that relies on gconf yourself/are you able to test it?

Yes.

>...
> For contributors: every time a package that hasn't had upstream
> development for a few years fails to build during a transition, or
> needs fixes for a new architecture, or has RC bugs that someone looks
> at during a BSP, it takes a little bit more of several contributors'
> time and attention

There have been 2 port bringups already this year so far (ia64, riscv64),
and a bigger amount of contributors' time and attention is actually 
wasted for these in cases like #876592 or #887868 where the maintainer
didn't apply a simple FTBFS fix for months.

> (even if the only attention it gets is to look at the
> package, realise it hasn't changed significantly in a decade, and decide
> to prioritize something different). Software that depends on gconf isn't
> *directly* an indication of something terribly bad, but it's reasonably
> well correlated with the dependent software also being unmaintained or
> undermaintained upstream. Each individual package blocking a transition,
> and each individual RC bug, doesn't necessarily take much time and
> attention, but it adds up over time, and I'm concerned that the long
> tail of GNOME-2-based packages might be collectively and cumulatively
> taking more time and attention than it deserves.
>...

The worst-possible outcome is when you force reverse dependencies to 
bundle copies of the libraries, like glademm in aeskulap.

>...
> If we had bikesheds, PPAs or an equivalent of Ubuntu universe, I'd
> suggest moving unmaintained/undermaintained packages to one of those
> to indicate that users shouldn't have the same quality expectations,
> but we don't currently have that facility.

I will begin to take your suggestion seriously after you have managed
to enforce that for ITPs - whatever quality expectations we have should
be enforced there already, usually software does not suddenly become
low-quality after it was shipped in half a dozen Debian releases.

> If, bearing all that in mind, you still think Debian is better with
> gconf than without it, then I'm not going to try to prevent you from
> maintaining it. (Again, I don't speak for the GNOME team.)

Thanks.

> smcv
>...

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Emilio Pozuelo Monfort]

On 12/04/18 21:41, Holger Levsen wrote:
> control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy 
> no-change-except-d/changelog-uploads"
> # I hope this is correct, realistic and accurate ;)
> # if not, please fixup?
> #thanks

Removing binNMUs would be a problem whenever we need to do a large amount of
rebuilds on just one architecture, e.g. due to a toolchain bug, a baseline bump,
or other reasons.

Emilio

Bug#895564: CVE-2017-2896 CVE-2017-2897 CVE-2017-2919

[Dirk Eddelbuettel]

I am in contact with upstream for readxl; upstream for readxl is trying to
get hold off a new (tentative) upstream for libxls.  I will follow-up here as
I learn more.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#895571: transition: http-parser

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 12/04/18 21:41, Christoph Biedl wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello release team,
> 
> the http-parser library saw another soname bump, so I'm hereby asking
> for a transition.
> 
> The new version 2.8.1-1~exp1 was uploaded to experimental a few days
> ago, rebuild for the dependencies as below was successful:
> 
> jabberd22.6.1-3
> libgit2 0.26.0+dfsg.1-1.1
> nodejs  (*)
> ocserv  0.11.9-1
> purple-matrix   0.0.0+git20180325-1
> ruby-http-parser.rb 0.6.0-4
> sssd1.16.1-1
> tang6-1
> tcpflow 1.4.5+repack1-4
> 
> (*) This was tested by the nodejs maintainer, build logs are here:
> https://buildd.debian.org/status/fetch.php?pkg=nodejs=amd64=8.11.1~dfsg-1=1523420093=0
> 
> Ben file (as created by reportbug):
> 
> title = "http-parser";
> is_affected = .depends ~ "libhttp-parser2.7.1" | .depends ~ 
> "libhttp-parser2.8";
> is_good = .depends ~ "libhttp-parser2.8";
> is_bad = .depends ~ "libhttp-parser2.7.1";
> 
> 
> If you need more information, just drop a line.

Go ahead.

Emilio

Bug#895572: mupdf-tools: mutool fails with "Cannot convert between incompatible pixmaps"

[Stefan Monnier]

Package: mupdf-tools
Version: 1.12.0+ds1-1
Severity: normal

Dear Maintainer,

Recently, Emacs's doc-view-mode started failing for me in some cases.
After tracking down the origin of the problem, it seems to be due to
a problem in `mutool`.
I can reproduce it with:

mutool draw -o foo.png foo.pdf 1

with the attached PDF file, which gives me:

page foo.pdf 1error: Cannot convert between incompatible pixmaps
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation

even though both `evince` and `mupdf` display it just fine.


Stefan


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.14.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mupdf-tools depends on:
ii  libc62.27-3
ii  libfreetype6 2.8.1-2
ii  libharfbuzz0b1.7.2-1
ii  libjbig2dec0 0.13-6
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libopenjp2-7 2.3.0-1
ii  zlib1g   1:1.2.8.dfsg-5

mupdf-tools recommends no packages.

mupdf-tools suggests no packages.

-- no debconf information


foo.pdf
Description: Adobe PDF document

Bug#836266: dirmngr: Please disable "use-tor" by default.

[Phil Morrell]

Package: parcimonie
Version: 0.10.2-4
Followup-For: Bug #836266

words



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

Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages parcimonie depends on:
ii  dirmngr  2.1.18-8~deb9u1
ii  gnupg2.1.18-8~deb9u1
ii  gnupg2   2.1.18-8~deb9u1
ii  libclone-perl0.38-2+b1
ii  libconfig-general-perl   2.63-1
ii  libfile-homedir-perl 1.00-1
ii  libfile-which-perl   1.21-1
ii  libgnupg-interface-perl  0.52-9
ii  libipc-system-simple-perl1.25-3
ii  liblist-moreutils-perl   0.416-1+b1
ii  libmoo-perl  2.002005-1
ii  libmoox-late-perl0.015-2
ii  libmoox-options-perl 4.023-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.100-1
ii  libtime-duration-parse-perl  0.13-1
ii  libtry-tiny-perl 0.28-1
ii  libtype-tiny-perl1.05-1
ii  libtypes-path-tiny-perl  0.005-1
ii  perl 5.24.1-3+deb9u2
ii  torsocks 2.2.0-1+deb9u1

Versions of packages parcimonie recommends:
pn  gnupg-curl  
ii  libglib-perl3:1.324-1
ii  libgtk3-perl0.030-1
ii  liblocale-gettext-perl  1.07-3+b1
ii  libnet-dbus-glib-perl   0.33.0-2+b1
ii  libnet-dbus-perl1.1.0-4+b1
ii  libpango-perl   1.227-1+b1
ii  libtime-duration-perl   1.20-1
ii  tor 0.2.9.14-1

parcimonie suggests no packages.

-- no debconf information

Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)

[Mattia Rizzolo]

Hi Daniel,

On Thu, Apr 12, 2018 at 03:23:47PM -0400, Daniel Kahn Gillmor wrote:
> Thanks for wrap-and-sort!  It's great to have nice canonicalized-form
> debian packaging.

You should also check out cme :)

> Using wrap-and-sort with -ast provides the simplest, cleanest diffs as
> things change, while still producing an easy-to-read debian/control.

I agree, that's also the one I love the most ^^

> I think these three options (--wrap-always, --short-indent,
> --trailing-comma) should be the default.

I'd like to converge togethre with cme, so I'm CCing its maintainer to
see whether he has an opinion.  If so I'd clone the bug so he can do it
as well.
(TTBOMK cme doesn't allow configuring this detail, it only does the
equivalent of plain `wrap-and-sort` in this regard).

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Holger Levsen]

control: retitle -1 "buildd.d.o: binNMUs should be replaced by easy 
no-change-except-d/changelog-uploads"
# I hope this is correct, realistic and accurate ;)
# if not, please fixup?
#thanks

-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#895571: transition: http-parser

[Christoph Biedl]

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

Hello release team,

the http-parser library saw another soname bump, so I'm hereby asking
for a transition.

The new version 2.8.1-1~exp1 was uploaded to experimental a few days
ago, rebuild for the dependencies as below was successful:

jabberd22.6.1-3
libgit2 0.26.0+dfsg.1-1.1
nodejs  (*)
ocserv  0.11.9-1
purple-matrix   0.0.0+git20180325-1
ruby-http-parser.rb 0.6.0-4
sssd1.16.1-1
tang6-1
tcpflow 1.4.5+repack1-4

(*) This was tested by the nodejs maintainer, build logs are here:
https://buildd.debian.org/status/fetch.php?pkg=nodejs=amd64=8.11.1~dfsg-1=1523420093=0

Ben file (as created by reportbug):

title = "http-parser";
is_affected = .depends ~ "libhttp-parser2.7.1" | .depends ~ "libhttp-parser2.8";
is_good = .depends ~ "libhttp-parser2.8";
is_bad = .depends ~ "libhttp-parser2.7.1";


If you need more information, just drop a line.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#860534: radeon 0000:00:10.0: ring 0 stalled for more than 10240msec

[Mathieu Malaterre]

I am seeing somewhat identical error message in dmesg from my Mac Mini
G4 (ppc) system with ATI:

[  268.132457] [drm] radeon kernel modesetting enabled.
[  268.132645] bus: 'pci': add driver radeon
[  268.132735] bus: 'pci': driver_probe_device: matched device
:00:10.0 with driver radeon
[  268.132743] bus: 'pci': really_probe: probing driver radeon with
device :00:10.0
[  268.132761] devices_kset: Moving :00:10.0 to end of list
[  268.132773] checking generic (9c008000 5a000) vs hw (9800 800)
[  268.132775] fb: switching to radeondrmfb from OFfb ATY,RockHo
[  268.133198] Console: switching to colour dummy device 80x25
[  268.133225] device: 'fb0': device_unregister
[  268.133391] PM: Removing info for No Bus:fb0
[  268.133485] device: 'fb0': device_create_release
[  268.133512]  MM calling offb_destroy
[  268.133535] device: 'vtcon1': device_unregister
[  268.133576] PM: Removing info for No Bus:vtcon1
[  268.133608] device: 'vtcon1': device_create_release
[  268.134018] radeon :00:10.0: enabling device (0006 -> 0007)
[  268.134110] device: 'renderD128': device_add
[  268.134187] PM: Adding info for No Bus:renderD128
[  268.141775] device: 'card0': device_add
[  268.141857] PM: Adding info for No Bus:card0
[  268.142033] [drm] initializing kernel modesetting (RV280
0x1002:0x5962 0x1002:0x5962 0x01).
[  268.142061] MM dma_set_coherent_maskfailure
[  268.142213] radeon :00:10.0: Invalid PCI ROM header signature:
expecting 0xaa55, got 0x
[  268.142253] radeon :00:10.0: Invalid PCI ROM header signature:
expecting 0xaa55, got 0x
[  268.142670] [drm:radeon_get_bios [radeon]] *ERROR* Unable to locate
a BIOS ROM
[  268.142764] [drm] Using device-tree clock info
[  268.142805] agpgart-uninorth :00:0b.0: putting AGP V2 device into 4x mode
[  268.142818] radeon :00:10.0: putting AGP V2 device into 4x mode
[  268.142863] radeon :00:10.0: GTT: 256M 0x - 0x0FFF
[  268.142872] [drm] Generation 2 PCI interface, using max accessible memory
[  268.142885] radeon :00:10.0: VRAM: 128M 0x9800 -
0x9FFF (32M used)
[  268.146575] [drm] Detected VRAM RAM=128M, BAR=128M
[  268.146604] [drm] RAM width 64bits DDR
[  268.146853] [TTM] Zone  kernel: Available graphics memory: 255078 kiB
[  268.146868] [TTM] Initializing pool allocator
[  268.146998] [drm] radeon: 32M of VRAM memory ready
[  268.147014] [drm] radeon: 256M of GTT memory ready.
[  268.147685] radeon :00:10.0: WB disabled
[  268.147710] radeon :00:10.0: fence driver on ring 0 use gpu
addr 0x and cpu addr 0x29fa7e44
[  268.147736] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[  268.147745] [drm] Driver supports precise vblank timestamp query.
[  268.147793] [drm] radeon: irq initialized.
[  268.147830] [drm] Loading R200 Microcode
[  268.181869] [drm] radeon: ring at 0x1000
[  268.181927] [drm] ring test succeeded in 0 usecs
[  268.183520] [drm] ib test succeeded in 0 usecs
[  268.183839] device: 'i2c-0': device_add
[  268.183882] bus: 'i2c': add device i2c-0
[  268.183925] PM: Adding info for i2c:i2c-0
[  268.183951] device: 'i2c-0': device_add
[  268.184014] PM: Adding info for No Bus:i2c-0
[  268.184252] device: 'i2c-1': device_add
[  268.184287] bus: 'i2c': add device i2c-1
[  268.184321] PM: Adding info for i2c:i2c-1
[  268.184337] device: 'i2c-1': device_add
[  268.184393] PM: Adding info for No Bus:i2c-1
[  268.184542] device: 'i2c-2': device_add
[  268.184568] bus: 'i2c': add device i2c-2
[  268.184609] PM: Adding info for i2c:i2c-2
[  268.184626] device: 'i2c-2': device_add
[  268.184680] PM: Adding info for No Bus:i2c-2
[  268.184809] device: 'i2c-3': device_add
[  268.184831] bus: 'i2c': add device i2c-3
[  268.184868] PM: Adding info for i2c:i2c-3
[  268.184884] device: 'i2c-3': device_add
[  268.184954] PM: Adding info for No Bus:i2c-3
[  268.185217] [drm] Connector Table: 7 (mini internal tmds)
[  268.185256] [drm] No TMDS info found in BIOS
[  268.185275] [drm] No TV DAC info found in BIOS
[  268.185316] device: 'card0-DVI-I-1': device_add
[  268.185388] PM: Adding info for No Bus:card0-DVI-I-1
[  268.185496] device: 'card0-SVIDEO-1': device_add
[  268.185577] PM: Adding info for No Bus:card0-SVIDEO-1
[  268.185644] [drm] Radeon Display Connectors
[  268.185657] [drm] Connector 0:
[  268.185664] [drm]   DVI-I-1
[  268.185671] [drm]   HPD1
[  268.185680] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
[  268.185689] [drm]   Encoders:
[  268.185697] [drm] DFP1: INTERNAL_TMDS1
[  268.185706] [drm] CRT2: INTERNAL_DAC2
[  268.185714] [drm] Connector 1:
[  268.185720] [drm]   SVIDEO-1
[  268.185727] [drm]   Encoders:
[  268.185734] [drm] TV1: INTERNAL_DAC2
[  268.233654] [drm] fb mappable at 0x9804
[  268.233688] [drm] vram apper at 0x9800
[  268.233696] [drm] size 1572864
[  268.233704] [drm] fb depth is 16
[  268.233711] [drm]pitch is 2048
[  268.242378] device: 'fb0': device_add
[  

Bug#895570: devscripts: wrap-and-sort should default to -ast (--wrap-always, --short-indent, --trailing-comma)

[Daniel Kahn Gillmor]

Package: devscripts
Version: 2.18.1
Severity: wishlist

Thanks for wrap-and-sort!  It's great to have nice canonicalized-form
debian packaging.

Using wrap-and-sort with -ast provides the simplest, cleanest diffs as
things change, while still producing an easy-to-read debian/control.

I think these three options (--wrap-always, --short-indent,
--trailing-comma) should be the default.  (this might mean adding
inverted options for the people who really insist on using
wrap-and-sort in some other way).

  --dkg

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBSIGN_KEYID=0EE5BE979282D80B9F7540F1CCD2ED94D21739E9

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

Kernel: Linux 4.15.0-2-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)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.0.5
ii  libc6 2.27-3
ii  libfile-homedir-perl  1.002-1
ii  perl  5.26.1-5
ii  python3   3.6.4-1
ii  sensible-utils0.0.12

Versions of packages devscripts recommends:
ii  apt 1.6~beta1
ii  at  3.1.20-3.1
ii  curl7.58.0-2
ii  dctrl-tools 2.24-2+b1
ii  debian-keyring  2018.03.24
ii  dput-ng [dput]  1.18
ii  dupload 2.9.1
ii  equivs  2.1.0
ii  fakeroot1.22-2
ii  file1:5.32-2
ii  gnupg   2.2.5-1
ii  gnupg2  2.2.5-1
ii  libdistro-info-perl 0.18
ii  libdpkg-perl1.19.0.5
ii  libencode-locale-perl   1.05-1
pn  libgit-wrapper-perl 
pn  liblist-compare-perl
ii  liblwp-protocol-https-perl  6.07-2
pn  libsoap-lite-perl   
ii  liburi-perl 1.73-1
ii  libwww-perl 6.33-1
pn  licensecheck
ii  lintian 2.5.81
ii  man-db  2.8.2-1
ii  patch   2.7.6-2
ii  patchutils  0.3.4-2
ii  python3-apt 1.6.0~rc2
ii  python3-debian  0.1.32
ii  python3-magic   2:0.4.15-1
ii  python3-requests2.18.4-2
pn  python3-unidiff 
pn  python3-xdg 
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wdiff   1.2.2-2
ii  wget1.19.4-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
pn  adequate   
ii  autopkgtest5.2
pn  bls-standalone 
ii  build-essential12.4
pn  check-all-the-things   
pn  cvs-buildpackage   
ii  devscripts-el  36.4
ii  diffoscope 93
pn  disorderfs 
pn  dose-extra 
pn  duck   
ii  faketime   0.9.7-2
pn  gnuplot
ii  gpgv   2.2.5-1
ii  gpgv2  2.2.5-1
ii  heirloom-mailx [mailx] 12.5-4
pn  how-can-i-help 
pn  libauthen-sasl-perl
pn  libfile-desktopentry-perl  
pn  libnet-smtps-perl  
pn  libterm-size-perl  
ii  libtimedate-perl   2.3000-2
pn  libyaml-syck-perl  
ii  mailutils [mailx]  1:3.4-1
ii  mozilla-devscripts 0.47
pn  mutt   
ii  openssh-client [ssh-client]1:7.7p1-2
pn  piuparts   
ii  postgresql-client-10 [postgresql-client]   10.3-2
ii  postgresql-client-9.5 [postgresql-client]  9.5.4-3
ii  postgresql-client-9.6 [postgresql-client]  9.6.5-1
ii  quilt  0.63-8.2
pn  ratt   
ii  reprotest  0.7.7
ii  svn-buildpackage   0.8.6
ii  w3m0.5.3-36

-- no debconf information

Bug#895569: python3-proselint: autopkgtest fails since python3.6 dropped depends on python3-distutils

[Paul Gevers]

Source: python3-proselint
Version: 0.8.0-2
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: progression

Since the upload of python3.6 version 3.6.5~rc1-2, it doesn't depend on
python3-distutils anymore. python3-distutils depends on python3-lib2to3
which provides the Python module under the same name. Your autopkgtest¹
fails since than with loads of errors like the following:

==
ERROR: Failure: ModuleNotFoundError (No module named 'lib2to3')
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/failure.py", line 39, in runTest
raise self.exc_val.with_traceback(self.tb)
  File "/usr/lib/python3/dist-packages/nose/loader.py", line 417, in
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 47, in
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python3/dist-packages/nose/importer.py", line 94, in
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/usr/lib/python3.6/imp.py", line 235, in load_module
return load_source(name, filename, file)
  File "/usr/lib/python3.6/imp.py", line 172, in load_source
module = _load(spec)
  File "", line 684, in _load
  File "", line 665, in _load_unlocked
  File "", line 678, in exec_module
  File "", line 219, in
_call_with_frames_removed
  File
"/tmp/autopkgtest-lxc.svp7xre8/downtmp/autopkgtest_tmp/tests/test_weasel_words_very.py",
line 4, in 
from .check import Check
  File
"/tmp/autopkgtest-lxc.svp7xre8/downtmp/autopkgtest_tmp/tests/check.py",
line 3, in 
from past.builtins import basestring
  File "/usr/lib/python3/dist-packages/past/__init__.py", line 88, in

from past.translation import install_hooks as autotranslate
  File "/usr/lib/python3/dist-packages/past/translation/__init__.py",
line 41, in 
from lib2to3.pgen2.parse import ParseError
ModuleNotFoundError: No module named 'lib2to3'

I don't know if this is an issue of the test (adding the dependency on
python3-lib2to3 there can (probably) fix the issue) or if the
dependencies of your package need updating.

Paul

¹ https://ci.debian.net/packages/p/python3-proselint/unstable/amd64/







signature.asc
Description: OpenPGP digital signature

Bug#895564: CVE-2017-2896 CVE-2017-2897 CVE-2017-2919

[Dirk Eddelbuettel]

On 12 April 2018 at 20:42, Moritz Muehlenhoff wrote:
| Package: r-cran-readxl
| Severity: grave
| Tags: security
| 
| r-cran-readxl bundles libxls which is affected by a number of security 
vulnerabilities:
| 
| https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0426
| https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0404
| https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0403

Dang. It looks like readxl upstream (https://github.com/tidyverse/readxl) may
not even be aware.

Is there are newer libxls you are aware of?  I don't see anything at the
sourceforge site either :-/

Dirk


-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#895404: NFS server stops accepting mount request / mounted NFS directories became inaccessible on client

[Sergio Gelato]

control: severity -1 normal
control: tags -1 + moreinfo

Dear reporter,

I'm sorry to hear that you have lost data. However, it doesn't seem very
constructive to make a bug release-critical without providing enough detail
to make a fix possible. NFS is a complex network protocol, and the root cause
of unexpected behaviour isn't always obvious at first glance.

First of all, has this bug been filed against the right package? The nfsd
processes are actually kernel threads (that's one reason "kill -9" doesn't
work on them), the corresponding package is the kernel image.

How many clients are accessing that NFS server when the problem occurs?
I see that you have RPCNFSDCOUNT=8 but the address range for allowed
clients is a /27. If you have 30 clients all trying to write at the same
time, some of them are going to have to wait until a server thread becomes
available. "server not responding, still trying" is a common symptom of
this. Have you tried tuning the server? You can adjust the thread count
without a reboot.

I don't see sec=krb5p in your /etc/exports, so NFS traffic on the wire
is probably unencrypted. Have you looked at it with tcpdump or a similar
tool, particularly when the problem occurs? For example it would be nice
to know whether that "Connection timed out" you get from mount.nfs is for
the portmapper (unlikely), for mountd, or for nfsd itself. (strace may
also tell you some of this.)

Are you familiar with rpcdebug? If client traffic is coming in but the
server isn't replying, you could set debugging flags and look at kernel
log output.

Other available debugging tools include the kernel's event tracing
subsystem, as well as nfsstat, nfsiostat and mountstats from package
nfs-common. (The last two are client-side, so maybe not so useful
if your problem really is at the server end.)

I can't help you much more than this: my own environment is NFSv4-only
(and I feel no urge to look back) while yours is anything but. But if
you manage to pinpoint more precisely what's wrong, someone else may
be able to provide better hints (or you may figure it out yourself).

Bug#895568: CVE-2017-11592

[Moritz Muehlenhoff]

Package: exiv2
Version: 0.26-1
Severity: important
Tags: security

This was assigned CVE-2017-11592: https://github.com/Exiv2/exiv2/issues/56

Only experimental is affected, the affected code isn't around for older 
releases.

Cheers,
Moritz

Bug#895564: CVE-2017-2896 CVE-2017-2897 CVE-2017-2919

[Moritz Muehlenhoff]

retitle 895564 CVE-2017-2896 CVE-2017-2897 CVE-2017-2919 CVE-2017-12111 
CVE-2017-12110
thanks

On Thu, Apr 12, 2018 at 08:42:20PM +0200, Moritz Muehlenhoff wrote:
> Package: r-cran-readxl
> Severity: grave
> Tags: security
> 
> r-cran-readxl bundles libxls which is affected by a number of security 
> vulnerabilities:
> 
> https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0426
> https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0404
> https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0403

Also:
https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0462
https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0463
 
Cheers,
Moritz

Bug#895567: restrictedpython: autopkgtest fails since python3.6 dropped depends on python3-distutils

[Paul Gevers]

Source: restrictedpython
Version: 4.0~b2-1
Severity: normal
User: ci-t...@tracker.debian.org
Usertags: progression

Since the upload of python3.6 version 3.6.5~rc1-2, it doesn't depend on
python3-distutils anymore. Your autopkgtest¹ fails since than with the
following error:
  File "", line 1, in 
ImportError: cannot import name 'sysconfig'

I don't know if this is an issue of the test (adding the dependency
there can fix the issue) or if the dependencies of your package need
updating.

Paul

¹ https://ci.debian.net/packages/r/restrictedpython/unstable/amd64/





signature.asc
Description: OpenPGP digital signature

Bug#895488: RFP: libghc-rate-limit -- A basic library for rate-limiting IO actions

[Antoine Beaupré]

Control: forwarded -1 https://github.com/acw/rate-limit/issues/3

On 2018-04-12 11:16:08, Sean Whitton wrote:
> Could you ask upstream to submit their package to stackage, please?
> That significantly reduces the Debian maintainance burden.

Done.

https://github.com/acw/rate-limit/issues/3

A.

-- 
We must shift America from a needs- to a desires-culture. People must
be trained to desire, to want new things, even before the old have
been entirely consumed. Man's desires must overshadow his needs.
 - Paul Mazur, Lehman Brothers

Bug#895566: nghttp2: CVE-2018-1000168: Denial of service due to NULL pointer dereference

[Salvatore Bonaccorso]

Source: nghttp2
Version: 0.6.4-2
Severity: important
Tags: patch security upstream

Hi,

The following vulnerability was published for nghttp2.

CVE-2018-1000168[0]:
Denial of service due to NULL pointer dereference

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000168
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000168
[1] 
https://github.com/nghttp2/nghttp2/commit/b1bd6035e884b3d83748914a3b5f2a8e52a78a2f
[2] http://www.openwall.com/lists/oss-security/2018/04/12/4

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#895564: CVE-2017-2896 CVE-2017-2897 CVE-2017-2919

[Moritz Muehlenhoff]

Package: r-cran-readxl
Severity: grave
Tags: security

r-cran-readxl bundles libxls which is affected by a number of security 
vulnerabilities:

https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0426
https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0404
https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0403

Cheers,
Moritz

Bug#895488: RFP: libghc-rate-limit -- A basic library for rate-limiting IO actions

[Sean Whitton]

Hello Antoine,

On Wed, Apr 11 2018, Antoine Beaupre wrote:

> * Package name: libghc-rate-limit
>   Version : 1.4.0
>   Upstream Author : Adam Wick 
> * URL : https://hackage.haskell.org/package/rate-limit
> * License : BSD-3-Clause
>   Programming Lang: Haskell
>   Description : A basic library for rate-limiting IO actions
>
> In many cases, it is useful, necessary, or simply nice to limit how
> frequently you perform some action. For example, you may want to limit
> how often your program makes a request of some web site. This library
> is intended as a general-purpose mechanism for rate-limiting IO
> actions.

Could you ask upstream to submit their package to stackage, please?
That significantly reduces the Debian maintainance burden.

> --
>
> According to Clint, this will be required for the new taffybar package
> (#895264).
>
> I do not plan on maintaining this, and hope someone will magically
> step up to do so. :) But I would certainly use the resulting taffybar,
> which I'm pretty excited about...

All GHC libs are team-maintained.  We just do them all together.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#894232: piuparts: deprecate --keep-tmpdir after buster in favor of --keep-env

[Holger Levsen]

control: tags -1 pending
thanks

Hi Agustin,

On Tue, Apr 10, 2018 at 04:57:02PM -0300, Agustin Henze wrote:
> > So we first now need to do the above code changes and then deprecate
> > --keep-env after the buster release.
> Please find the patch attached

thanks a lot, merged & will deploy now :)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#851786: Terminal emulator command arguments ignored in Preferences -> Advanced

[Andriy Grytsenko]

control: tag -1 jessie
control: fixed -1 1.2.5-1

Thank you for reporting this, although I'm not sure if it's still
reasonable to backport it into Jessie at this point.

Bug#895379: [Piuparts-devel] Bug#895379: [piuparts] Create /dev/null if it doesn't exist ASAP

[Holger Levsen]

control: tags -1 pending
thanks

On Tue, Apr 10, 2018 at 05:05:01PM -0300, Agustin Henze wrote:
> Hi holger, I've moved the creation of ${ENV}/dev/null ASAP, because in some
> environments it is created as a regular file and then `apt-get update` hangs
> forever.

thanks, merged, will deploy to piuparts.d.o soon.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#895380: [Piuparts-devel] Bug#895380: [piuparts] Create ${ENV}/dev/ptmx path if it doesn't exist

[Holger Levsen]

control: tags -1 + pending
thanks

Hi Agustin,

On Tue, Apr 10, 2018 at 05:07:38PM -0300, Agustin Henze wrote:
> Hi holger, piuparts just check if it is a link but when you export a chroot
> from a docker container, this path doesn't exists.

thanks for the patch, merged to master, will deploy on piuparts.d.o once
I merged the other patches from you!


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#894771: python3-testtools: Missing runtime dependency on python3-distutils

[Paul Gevers]

user ci-t...@tracker.debian.org
usertag 894771 progression
thanks

The reason for this issue is that since the upload of python3.6 version
3.6.5~rc1-2, it doesn't depend on python3-distutils anymore. Also your
autopkgtest¹ fails since than with the following error:

  File "/usr/lib/python3.6/runpy.py", line 183, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/usr/lib/python3.6/runpy.py", line 109, in _get_module_details
__import__(pkg_name)
  File
"/tmp/autopkgtest-lxc.tzt7pzhx/downtmp/build.a0d/src/testtools/__init__.py",
line 113, in 
from testtools.distutilscmd import (
  File
"/tmp/autopkgtest-lxc.tzt7pzhx/downtmp/build.a0d/src/testtools/distutilscmd.py",
line 7, in 
from distutils.core import Command
ModuleNotFoundError: No module named 'distutils.core'

There are rumors that one shouldn't use distutils as a runtime
dependency and one should use sysconfig instead.

Paul

¹ https://ci.debian.net/packages/p/python-testtools/unstable/amd64/



signature.asc
Description: OpenPGP digital signature

Bug#889968: RFS: inotify-tools/3.14-4

[Sean Whitton]

Hello,

On Thu, Apr 12 2018, Gianfranco Costamagna wrote:

> I'm worried about the disappear of "debian-changes" patch, is it
> somewhere else? should I get a new orig tarball?  I don't want my
> upload to make something disappear from the patch queue, due to my
> lack of dgit procedures.

It's because the patch was merged upstream.

> Please tell me the commands to get the source in the right way(TM) and
> then I'll look/sponsor if the patch has to disappear for some ways.
> other things LGTM, the package builds in my pbuilder, and probably in
> ppas too.

Please try typing `origtargz`.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#870787: liboss4-salsa*: please add six snd_{midi,seq}_* functions

[Thorsten Glaser]

retitle 870787 liboss4-salsa*: please add six snd_{midi,seq}_* functions
affects 870787 src:portmidi
thanks

Hello again,

we also need the following symbols in oss-salsa:

• snd_midi_event_encode_byte
• snd_midi_event_free
• snd_midi_event_new
• snd_seq_delete_port
• snd_seq_disconnect_from

These are required to build src:portmidi, which is a new
dependency of src:musescore, and thus extending the scope
of this bugreport instead of creating a new one. Just to
remind, we also need this:

• snd_seq_event_length

Please d̲o̲ provide this!


Small side note: perhaps, given enough functions in oss-salsa,
portaudio19 could also use it, achieving feature parity. (Which
is why I Cc’d its maintainers as well.)

Thanks in advance,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D

Bug#878572: Bug#895511: exactimage FTBFS with libevas-dev 1.20.7

[Sven Eckelmann]

On Donnerstag, 12. April 2018 19:21:14 CEST Andreas Metzler wrote:
> So I do not expect efl to change back, re-introducing an optional
> unfavoured API.

This sounded differently in October 2017 [1]. But ok, please close the 
libevas-dev bug (#878572). We will most likely drop exactimage from Debian.

Kind regards,
Sven

[1] https://sourceforge.net/p/enlightenment/mailman/message/36077810/

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

Bug#878572: Bug#895511: exactimage FTBFS with libevas-dev 1.20.7

[Ross Vandegrift]

On Thu, Apr 12, 2018 at 10:38:55AM +0200, Sven Eckelmann wrote:
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exactimage.html
> 
> Thanks for bringing this up again. This is a long standing bug in 
> libevas-dev. 
> Increasing the severity for the libevas-dev bug now because they have 
> uploaded 
> the problematic version to unstable without fixing it.

Hi Sven - 

(Thought I sent this info along already, but I don't see it in BTS.
Very sorry for letting this slip through the cracks.)

exactimage uses headers that accidentally exposed internal EFL data
structures.  Later that caused ABI/API compatability problems.  Upstream
decided to fix this by no longer shipping the engine headers.  According
to them, they had been optional functionality.

Upstream is unclear on whether or not exactimage can be fixed with EFL
1.20.  It sounds like the only external project to have used the engines
directly.  Their suggestion is to port to ecore-evas.  I don't have the
knowledge to help here, but Cedric from EFL offered help.

Unfortunately, it's not as simple as shipping the headers in Debian.  I
tried that, but the bits used by exactimage have since moved around, and
some of the structures have changed.  We'd need to diverge significantly
from upstream, and Pkg-E doesn't have the resources or expertise to
maintain a distro-specific fork.

Ross


signature.asc
Description: PGP signature

Bug#895563: thunderbird: AppArmor denies device enumeration

[Vincas Dargis]

Package: thunderbird
Version: 1:60.0~b2-1
Severity: normal
Tags: upstream
User: pkg-apparmor-t...@lists.alioth.debian.org

Dear Maintainer,

AppArmor profile denies access to paths like
`/sys/devices/pci:00/:00:02.0/{vendor,device,uevent,...}`:

```
type=AVC msg=audit(1523552674.105:410): apparmor="DENIED"
operation="open" profile="thunderbird"
name="/sys/devices/pci:00/:00:02.0/vendor" pid=11430
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
type=AVC msg=audit(1523552771.505:437): apparmor="DENIED"
operation="open" profile="thunderbird"
name="/sys/devices/pci:00/:00:02.0/device" pid=11569
comm="thunderbird" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
```

This can be fixed by including rather new `dri-enumerate` abstraction,
but it is available only in upstream AppArmor maser [0] yet.

I'll propose upstream fix once `dri-enumerate` is shipped.

Thunderbird does seem to work fine even with denies though.

[0]
https://gitlab.com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstractions/dri-enumerate


-- System Information:
Debian Release: buster/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 4.15.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE=lt 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages thunderbird depends on:
ii  debianutils   4.8.4
ii  fontconfig2.13.0-2
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-3
ii  libcairo-gobject2 1.15.10-2
ii  libcairo2 1.15.10-2
ii  libdbus-1-3   1.12.6-2
ii  libdbus-glib-1-2  0.110-2
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-2
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8-20180402-1
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.29-3
ii  libgtk2.0-0   2.24.32-1
ii  libhunspell-1.6-0 1.6.2-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-1
ii  libnss3   2:3.36.1-1
ii  libpango-1.0-01.42.1-1
ii  libpangocairo-1.0-0   1.42.1-1
ii  libpangoft2-1.0-0 1.42.1-1
ii  libsqlite3-0  3.23.1-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68-20180402-1
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-1
ii  libxcb1   1.13-1
ii  libxcomposite11:0.4.4-2
ii  libxcursor1   1:1.1.15-1
ii  libxdamage1   1:1.1.4-3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages thunderbird recommends:
ii  hunspell-ar [hunspell-dictionary] 3.2-1
ii  hunspell-en-gb [hunspell-dictionary]  1:6.0.3-2
ii  hunspell-en-us [hunspell-dictionary]  1:2017.08.24
ii  hunspell-lt [hunspell-dictionary] 1:6.0.3-2
ii  lightning 1:60.0~b2-1

Versions of packages thunderbird suggests:
ii  apparmor  2.12-4
pn  fonts-lyx 
ii  libgssapi-krb5-2  1.16-2

-- Configuration Files:
/etc/apparmor.d/usr.bin.thunderbird changed [not included]

-- no debconf information

Bug#885135: pygtk: Unmaintained, use GObject Introspection instead

[Simon McVittie]

Control: tags -1 + upstream wontfix
Control: user pkg-gnome-maintain...@lists.alioth.debian.org
Control: usertags -1 + unmaintained-upstream

On Sun, 24 Dec 2017 at 09:12:19 -0500, Jeremy Bicha wrote:
> pygtk is unmaintained upstream. It has not had a release since GNOME 3
> was released in 2011.

If someone from outside the GNOME team takes over this package, this
can be dropped down to non-RC at their discretion, but please leave it
open as a warning to potential users of this library.

(I've been opening similarly-tagged Severity: important bugs in various
other unmaintained libraries.)

smcv

Bug#878572: exactimage FTBFS with libevas-dev 1.20.7

[Andreas Metzler]

On 2018-04-12 Sven Eckelmann  wrote:
> On Donnerstag, 12. April 2018 11:08:47 CEST Adrian Bunk wrote:
>> Source: exactimage
>> Version: 1.0.1-1
>> Severity: serious

>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exactimage.html

> Thanks for bringing this up again. This is a long standing bug in
> libevas-dev.  Increasing the severity for the libevas-dev bug now
> because they have uploaded the problematic version to unstable without
> fixing it.

Hello,

efl's upstream last comments on the issue were these:
| Damn... this is... old. The code is using evas engine and X11 directly,
| no ecore, nothing.


| I believe the only real solution we have here is to modify exactimage
| itself. That will require quite some work, but I guess we may even be
| able to use an elm_win to do the job, unless something very special
| needs to be done.

So I do not expect efl to change back, re-introducing an optional
unfavoured API.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#895562: libgnomecanvasmm2.6: unmaintained upstream

[Simon McVittie]

Source: libgnomecanvasmm2.6
Version: 2.26.0-1
Severity: important
Tags: upstream wontfix
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: unmaintained-upstream

libgnomecanvasmm has been unmaintained upstream for several years. It should
not be used in new code, and old code should be migrated away from it.

I don't know whether there is a direct replacement or a porting guide
anywhere.

The git repository has been archived:
https://git.gnome.org/browse/archive/libgnomecanvasmm/

smcv

Bug#895561: libgnomecanvas: unmaintained upstream

[Simon McVittie]

Package: libgnomecanvas
Version: 2.30.3-1.2
Severity: important
Tags: upstream wontfix
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: unmaintained-upstream

libgnomecanvas has been unmaintained upstream for several years. It should
not be used in new code, and old code should be migrated away from it.

I don't know whether there is a direct replacement or a porting guide
anywhere.

The git repository has been archived:
https://git.gnome.org/browse/archive/libgnomecanvas/

Related language bindings:
https://git.gnome.org/browse/archive/libgnomecanvasmm/
https://git.gnome.org/browse/archive/perl-Gnome2-Canvas/

smcv

Bug#895247: libgnomecanvas: Intent to Adopt

[Simon McVittie]

On Thu, 12 Apr 2018 at 15:03:11 +0200, Gert Wollny wrote:
> Hi Adrian, 

(Adrian won't have seen this unless he's subscribed to the bug or
package, because bug submitters don't normally get copies of bug mail
in the Debian BTS; adding him to Cc.)

> as the maintainer of amide[1], a package that depends on libgnomecanvas
> I was also already thinking about adopting this package and libart-
> lgpl. In other words I'd happily join to co-maintain these two
> packages. 

Do you (either or both of you) also intend to adopt the language bindings
src:libgnomecanvasmm2.6 (in theory currently maintained by Deng Xiyue,
most recent maintainer upload 2009)?

Everything I said below "My concern about keeping packages like gconf"
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895246#10 applies
equally here. If, having considered that, you still want to adopt these
libraries, I don't think anyone will stop you.

Both libgnomecanvas and libgnomecanvasmm are listed as "archived"
in GNOME git, so they have no upstream maintainer. If you adopt them,
you will be the closest thing there is to their upstream maintainer;
it might be a good idea to start a new upstream project (forked from
the archived GNOME source code) that other distributions can share,
particularly if you plan to modify things that are annoying to do via
a patch series, like the build system.

Because these packages mention "gnome" in their names, it would be great
if you could reduce confusion by modifying their Description to clarify
that they are no longer considered to be part of (current) GNOME.

libart-lgpl packaging has been successfully converted from svn to git
and is available from https://salsa.debian.org/gnome-team/libart-lgpl
(a gnome-team Owner or a Salsa sysadmin might be able to move that into a
different namespace for you, leaving a redirect behind). libgnomecanvas
and libgnomecanvasmm2.6 seem to have failed their automatic conversion
from svn (there are repositories in /git/pkg-gnome on Alioth but they are
empty); I think I still have the right incantations in my shell history
on alioth to do a fallback conversion with git-svn, if that would be
helpful to you.

smcv

Bug#895474: Fontconfig errors

[Emilio Pozuelo Monfort]

On 12/04/18 04:01, brian m. carlson wrote:
> I've also seen these errors, except that they're showing up in my tmux
> panes, which is significantly more annoying than .xsession-errors.  This
> is probably because vim-gtk3 (gvim) links to libfontconfig1.
> 
> libfontconfig definitely shouldn't be producing errors to stdout or
> stderr unless specifically requested by the calling application.

Have you restarted your applications? AFAICS this is caused by old libfontconfig
reading the new conf files. If you restart them the warnings should go away.

(I know this isn't an ideal solution)

Emilio

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Laura Arjona Reina]

El 12 de abril de 2018 18:52:56 CEST, Christian PERRIER  
escribió:
>Quoting Laura Arjona Reina (larj...@debian.org):
>> Hi again
>> 
>> El 12/04/18 a las 07:12, Christian PERRIER escribió:
>> 
>> > Doh, I'm now in the salsa mess:
>> > debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git pull
>> > fatal: unable to access
>'https://salsa.debian.org/l10n-team/dl10n.git/': server certificate
>verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt
>CRLfile: none
>> Sorry, my fault, I gave incomplete directions.
>> There is also needed to do the following (in tye.debian.org):
>> 
>> dir=/etc/ssl/ca-debian
>> test -d $dir && git config --local --add http.sslCAInfo
>$dir/ca-certificates.crt
>> 
>> (This is documented in https://wiki.debian.org/ServicesSSL#git )
>
>
>Gracias!
>
>It just worked now and the local copy on tye is now synced again with
>the git repo on salsa.

Merci!
Let's see what happens tomorrow in the next run.

Cheers
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona
Sent with K-9 mail

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Hi again
> 
> El 12/04/18 a las 07:12, Christian PERRIER escribió:
> 
> > Doh, I'm now in the salsa mess:
> > debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git pull
> > fatal: unable to access 'https://salsa.debian.org/l10n-team/dl10n.git/': 
> > server certificate verification failed. CAfile: 
> > /etc/ssl/certs/ca-certificates.crt CRLfile: none
> Sorry, my fault, I gave incomplete directions.
> There is also needed to do the following (in tye.debian.org):
> 
> dir=/etc/ssl/ca-debian
> test -d $dir && git config --local --add http.sslCAInfo 
> $dir/ca-certificates.crt
> 
> (This is documented in https://wiki.debian.org/ServicesSSL#git )


Gracias!

It just worked now and the local copy on tye is now synced again with
the git repo on salsa.




signature.asc
Description: PGP signature

Bug#894602: [dpkg] Strange cron error mails from executing /etc/cron.daily/dpkg

[Dirk Heinrichs]

Am 12.04.2018 um 14:16 schrieb Guillem Jover:

> Do you perhaps have something like unattended-ugrades or something
> similar enabled on all those hosts?

No, I don't. That's one of the packages I uninstall immediately ;-)

Bye...

    Dirk

-- 
Dirk Heinrichs 
GPG Public Key: D01B367761B0F7CE6E6D81AAD5A2E54246986015
Sichere Internetkommunikation: http://www.retroshare.org
Privacy Handbuch: https://www.privacy-handbuch.de




signature.asc
Description: OpenPGP digital signature

Bug#894367: wadc: JRE dependency should be default-jre | java8-runtime

[Adrian Bunk]

On Thu, Apr 12, 2018 at 05:34:24PM +0100, Jonathan Dowland wrote:
> On Thu, Mar 29, 2018 at 04:29:03PM +0300, Adrian Bunk wrote:
> > The JRE dependency is currently:
> >  openjdk-8-jre | java8-runtime
> > 
> > This should instead be:
> >  default-jre | java8-runtime
> 
> I would like to avoid having the dependencies be satisfyable by
> something that does not provide java8-runtime.
> 
> What do you think about a versions depends on default-jre, e.g.
> 
>default-jre (>= 2:1.8) | java8-runtime
> 
> Could you see any problems with this?

It doesn't make a difference in buster or stretch,
which implies there's no problem with it.

> Thanks,

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#895508: closed by Jeremy Bicha <jbi...@debian.org> (Bug#895504: fixed in evolution 3.28.1-2)

[Pascal Obry]

Fixed now indeed.

Thanks for the quick fix.

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://www.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

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

Bug#894367: wadc: JRE dependency should be default-jre | java8-runtime

[Jonathan Dowland]

On Thu, Mar 29, 2018 at 04:29:03PM +0300, Adrian Bunk wrote:

The JRE dependency is currently:
 openjdk-8-jre | java8-runtime

This should instead be:
 default-jre | java8-runtime


I would like to avoid having the dependencies be satisfyable by
something that does not provide java8-runtime.

What do you think about a versions depends on default-jre, e.g.

   default-jre (>= 2:1.8) | java8-runtime

Could you see any problems with this?

Thanks,

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Bug#820129: grub2: Disallow booting unsigned kernels when Secure Boot is enabled

[Luca Boccassi]

On Thu, 2018-04-12 at 15:58 +0100, Steve McIntyre wrote:
> [ Note cc to the d-efi list. SB is finally in progress after last
>   week's sprint! ]
> 
> Very belated, it's time we discussed this.
> 
> On Tue, Apr 05, 2016 at 11:17:24AM -0700, Linn Crosetto wrote:
> > Package: grub2
> > Version: 2.02~beta2-36
> > Severity: wishlist
> > Tags: patch
> > 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> > 
> > The current code in 2.02~beta2-36 will silently fall back to
> > calling
> > ExitBootServices() and booting an unsigned kernel if signature
> > verification
> > fails.
> > 
> > As a part of support for UEFI Secure Boot in Debian (820036) change
> > the boot
> > to fail if signature verification fails.
> > 
> > I have attached a trivial patch for this change. Thanks!
> > 
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v1
> > 
> > iQIcBAEBAgAGBQJXBAE0AAoJEF/3aG7d/FTWDh4P/ja6Qa0JRr2bIDj+I+sihFmJ
> > fIHVItLpMEU5hrKnpkRas7GflntzfpEObqUmzPLTRsrA1WobEyZDfNJUOonvEojR
> > atccbvjShxNJIZFCr+W8mGh23+Xv+4VFVJ9f2jd+2sOlmViGyM88rDLOZN69vwIe
> > 9+GbTY6Ha3PifVDwLXvNH0cNiInt8uPbPnFOKwAcwSqFncyq5mfpCroLIqgfR5Dv
> > ImROn7to4iurho3MOidJ0gRJm17mcPjzQAyX/Wh2asSiUMx2cIVrkfcSqoeb6W3L
> > sXytfIwMf3YzY+eLEpsTZDYhmxrJGMa9uQ+Ryg1ZCQI0uI/n3We7cXnukofcM+Of
> > sAtETJvr8SYrF5J/v7XafbEKXr64jV7wEEk97kDA+YGdw7nR1Y0UeX3W3AJCuOeo
> > /KF75oIKJrYbRLymT701RwjArKD2wXYDTzmvnQKiTBc4sPofnr+nJIUOGvZ8Tn8O
> > D/vI8PZKStsZ4cuABkiHEmA3y6zlVtJEkS+OGktNWrugNBJXGWHs6AHGjIIGenTQ
> > 8FPeNrC01DHf+170iV/0PXGLfJKn037y9JSDaZXuZkAsSrqmQENLKzOv9ee4QSsm
> > UmalPiqKkyeZRQna7ZDK+LwB8yf02applIzsQcFuF/RahZdgLhwl42doC7LgjpYI
> > wN0JD88AfHJAuUtwbpxc
> > =fkO9
> > -END PGP SIGNATURE-
> > > From 52de74c85ef6a9aca426d9de8f188fe92241aff6 Mon Sep 17 00:00:00
> > > 2001
> > 
> > From: Linn Crosetto 
> > Date: Tue, 5 Apr 2016 11:49:05 -0600
> > Subject: [PATCH] Disallow unsigned kernels if UEFI Secure Boot is
> > enabled
> > 
> > If UEFI Secure Boot is enabled and kernel signature verification
> > fails, do not
> > boot the kernel. Before this change, if kernel signature
> > verification failed
> > then GRUB would fall back to calling ExitBootServices() and
> > continuing the
> > boot.
> > 
> > Patch-Name: linuxefi_disable_sb_fallback.patch
> > 
> > Signed-off-by: Linn Crosetto 
> > ---
> > grub-core/loader/i386/linux.c | 8 +++-
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/grub-core/loader/i386/linux.c b/grub-
> > core/loader/i386/linux.c
> > index 2380642..e2e26dd 100644
> > --- a/grub-core/loader/i386/linux.c
> > +++ b/grub-core/loader/i386/linux.c
> > @@ -696,10 +696,8 @@ grub_cmd_linux (grub_command_t cmd
> > __attribute__ ((unused)),
> >   using_linuxefi = 0;
> >   if (grub_efi_secure_boot ())
> > {
> > -  /* Try linuxefi first, which will require a successful
> > signature check
> > -    and then hand over to the kernel without calling
> > ExitBootServices.
> > -    If that fails, however, fall back to calling
> > ExitBootServices
> > -    ourselves and then booting an unsigned kernel.  */
> > +  /* linuxefi requires a successful signature check and then
> > hand over
> > +    to the kernel without calling ExitBootServices. */
> >   grub_dl_t mod;
> >   grub_command_t linuxefi_cmd;
> > 
> > @@ -721,7 +719,7 @@ grub_cmd_linux (grub_command_t cmd
> > __attribute__ ((unused)),
> >   return GRUB_ERR_NONE;
> > }
> >   grub_dprintf ("linux", "linuxefi failed (%d)\n",
> > grub_errno);
> > -     grub_errno = GRUB_ERR_NONE;
> > +     goto fail;
> > }
> > }
> > }
> 
> This looks like one way of doing this. Philipp Hahn is suggesting
> that
> we just don't include the "linux" module in our signed grub
> build. That's simpler, but potentially causes problems elsewhere,
> e.g. "it gets a bit nasty to try and dynamically switch between linux
> and linuxefi in live-build". So, let's discuss - we need to agree our
> policy and decide the best mechanism here. Go...!

The issues I see is that until now pretty much everywhere "linux" is
used in grub.cfg.

This can be solved easily, and indeed Philipp has already done it, for
local installations - the problems arise when building images.

At least in live-build (not sure about debootstrap/live-wrapper?),
users can provide their own grub.cfg. Personally I've never seen anyone
use anything but "linux" in the menuentry (eg: Kali [2]).

So I'd need to do something like this [1] in live-build:

sed -i "s|linux\(\s\+/\w\+/vmlinuz\)|linuxefi\1|" \
binary/boot/grub/grub.cfg
sed -i "s|initrd\(\s\+/\w\+/initrd\)|initrdefi\1|" \
binary/boot/grub/grub.cfg

With the risk of randomly breaking with weird user's grub.cfg :-/

I'd really like to make the process as transparent as possible for
users, as there are already enough hoops to jump through as-is to get
secure boot working.

I have been using the patch from this bug in production for about a
year as an alternative in the 

Bug#894979: ca-certificates-java: SSL error: "the trustAnchors parameter must be non-empty"

[Raphael Hertzog]

retitle -1 ca-certificates-java: does not work with OpenJDK 9, applications 
fail with InvalidAlgorithmParameterException: the trustAnchors parameter must 
be non-empty
severity -1 serious
thanks

Hello,

On Thu, 05 Apr 2018, George B. wrote:
> I am getting an error when connecting to HTTPS from java. Looking around
> the problem always seems to talk about this package, but please
> re-assign if something else is to blame.

I confirm the issue. If you have only OpenJDK 9 installed, then the
/etc/ssl/certs/java/cacerts file generated by the postinst (or the
ca-certificates hook) is not working and will lead to errors like the one
you showed.

Work-around:
$ sudo apt install openjdk-8-jre
$ sudo rm /etc/ssl/certs/java/cacerts
$ sudo update-ca-certificates --fresh

This works because /etc/ca-certificates/update.d/jks-keystore prefers
OpenJDK 8 over OpenJDK 9.

> Testing with the following code (I don't really know any Java and it's
> the first thing I found to test with):
> https://gist.github.com/4ndrej/4547029

This was really useful to debug the issue, thank you! My failing java
application was much bigger and harder to strace.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#895560: s3cmd has a runtime dependency on python3-distutils

[Nishanth Aravamudan]

Package: s3cmd
Version: 2.0.1-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

As reported in Ubuntu, s3cmd on Debian also does not run by default (it
spits an error about distutils.spawn). This is because (I think) python2
had distutils as part of the core, while python3 does not.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/control: add run-time dependency on python3-distutils.
- Upstream has required it in s3cmd since 2007. 
- LP: #1763398


Thanks for considering the patch.

*** /tmp/tmpLFbq1d/s3cmd_2.0.1-1ubuntu1.debdiff
diff -Nru s3cmd-2.0.1/debian/control s3cmd-2.0.1/debian/control
--- s3cmd-2.0.1/debian/control  2017-10-25 23:48:32.0 -0700
+++ s3cmd-2.0.1/debian/control  2018-04-12 09:03:35.0 -0700
@@ -16,7 +16,7 @@
 
 Package: s3cmd
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}
+Depends: ${misc:Depends}, ${python3:Depends}, python3-distutils
 Description: command-line Amazon S3 client
  Command-line tool to upload, retrieve and manage data in Amazon S3 service
  (http://www.amazon.com/s3/), designed for use in scripts. Features:


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

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

-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#895559: ITP: json-editor.js -- JSON Schema based editor

[Joel Cross]

Package: wnpp
Severity: wishlist
Owner: Joel Cross 

* Package name: json-editor.js
  Version : 0.7.28
  Upstream Author : Jeremy Dorn  (http://jeremydorn.com)
* URL : https://github.com/json-editor/json-editor#readme
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Schema based editor

 JSON Editor takes a JSON Schema and uses it to generate an HTML form.
 It has full support for JSON Schema version 3 and 4 and can integrate with
several popular CSS frameworks (bootstrap, foundation, and jQueryUI).

This package is a dependency of swagger-ui (see #895422), which I am also
ITPing.

Bug#877419: pandas FTBFS on !x86/ppc64el: test failures

[Graham Inggs]

Hi

I refreshed and re-enabled Andreas' mark_tests_working_on_intel.patch 
[1] which was disabled in 0.22.0-1.
I additionally marked test_sum_nanops_timedelta and 
test_timedelta_ops_with_missing_values with pytest.mark.intel which were 
failing at least on arm64.


To address a new failure on big-endian architectures, I added a patch 
[2] and forwarded it upstream.


I uploaded 0.22.0-3 including these changes, and as of this writing, 
builds have succeeded on s390x, ppc64el, amd64 and i386.


Regards
Graham


[1] 
https://salsa.debian.org/science-team/pandas/commit/2971b1a4336d54def88857853e24274503b9cf55
[2] 
https://salsa.debian.org/science-team/pandas/commit/27e71d47e891547e3e492b1e25494bf2b4504a49