Bug#847453: new upstream (1.11.8-rbsec)

[Daniel Baumann]

retitle 847453 new upstream (1.11.11-rbsec)
thanks

Hi,

any news/eta? do you need help?

Regards,
Daniel

Bug#889915: libfaad2 in Wheezy contains patches for some security bugs. They were not backported to Jessie.

[Fabian Greffrath]

tags 889915 +security +jessie
thanks

Forwarding this to the security team.

Mikulas Patocka wrote:
> Package: libfaad2
> Version: 2.7-8
> Severity: normal
>
> Dear Maintainer,
>
> Libfaad2 in Wheezy contains some security patches. But the patches were
> not
> backported to Jessie.
>
>
>
> -- System Information:
> Debian Release: 8.10
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: i386 (i586)
>
> Kernel: Linux 4.14.16 (PREEMPT)
> Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>
> Versions of packages libfaad2 depends on:
> ii  libc6  2.19-18+deb8u10
> ii  multiarch-support  2.19-18+deb8u10
>
> libfaad2 recommends no packages.
>
> libfaad2 suggests no packages.
>
> -- no debconf information
>
> ___
> pkg-multimedia-maintainers mailing list
> pkg-multimedia-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
>
>

Bug#888985: [pkg-go] Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

[Michael Stapelberg]

On Fri, Feb 9, 2018 at 2:09 AM, Pete Heist  wrote:

>
> On Feb 7, 2018, at 10:03 AM, Michael Stapelberg 
> wrote:
>
> Thanks for contributing this package.
>
> The resulting binary package irtt_0.9-1_amd64.deb contains both a binary
> and Go source code. This is a bit unusual: in Debian, we only package Go
> source code to build other Go programs (not for developers). Hence, we
> usually provide either a binary package with programs or an arch:all
> package with Go source. It’s fine to have a source package which provides
> both, but please separate the source from the binaries. Have a look at
> https://anonscm.debian.org/cgit/collab-maint/codesearch.git/ for an
> example of this pattern.
>
> Further, please address the following lintian warnings:
>
> P: irtt source: package-uses-old-debhelper-compat-version 10
> P: irtt source: insecure-copyright-format-uri http://www.debian.org/doc/
> packaging-manuals/copyright-format/1.0/
> I: irtt source: out-of-date-standards-version 3.9.8 (released 2016-04-06)
> (current is 4.1.3)
> I: irtt source: testsuite-autopkgtest-missing
> W: irtt: priority-extra-is-replaced-by-priority-optional
>
>
> I’m on Debian sid and closer now, with a binary only package (using
> dh_auto_install -- --no-source). There’s still some lintian confusion. When
> I run it, I get:
>
> $ cat /etc/debian_version
> buster/sid
> $ lintian --version
> Lintian v2.5.74
> $ lintian irtt_0.9+git20180209.9cda776-1_amd64.changes
> P: irtt source: debian-watch-does-not-check-gpg-signature
> P: irtt: no-upstream-changelog
>
> From the original warnings you sent I know I’ve fixed all except "I: irtt
> source: testsuite-autopkgtest-missing”, but a) I’m not seeing that
> warning and b) I’m seeing two others. So my questions are:
>
> 1) What are your expectations for 'testsuite-autopkgtest-missing', and
> why am I not seeing it? There are no unit tests to run.
>

Did you apply the ~/.lintianrc I provided? Not doing so would explain the
difference. autopkgtest is helpful even if it only compiles the package in
question. Why are there no unit tests for your code? :)


>
> 2) Do you care about 'debian-watch-does-not-check-gpg-signature' and
> 'no-upstream-changelog’? I do not sign the upstream, and the changes are in
> README.md, in case those should be split out...
>

They’re not important for the time being. Of course, if you could start
signing upstream and provide a separate changelog file, that would be great.

Thanks!


>
> Thanks!
> Pete
>
>
> ___
> Pkg-go-maintainers mailing list
> pkg-go-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-go-maintainers
>



-- 
Best regards,
Michael

Bug#889951: ITP: nanopb/0.3.9 -- Protocol Buffers with small code size

[Lumin]

Package:wnpp
Severity: wishlist
Owner: lumin 

* Package name: nanopb
  Version : 0.5.0
  Upstream Author : Petteri Aimonen 
* URL : https://jpa.kapsi.fi/nanopb/
* URL : https://github.com/nanopb/nanopb
* License : zlib/libpng
  Programming Lang: c
  Description : Protocol Buffers with small code size

This library is a PyTorch dependency.

-- 
Best,

Bug#889850: closed by tony mancill <tmanc...@debian.org> (Bug#889850: fixed in gpodder 3.10.0-4)

[Dimitri Chausson]

Hello Tony, Thomas,

nice if the package has been updated ! Good work.
@Thomas: For your information: as it seems, installing python3-cairo is not 
sufficient. The program can now be launched, but the view is not complete 
(meaning there are missing podcasts) and there is the following message 
repeated in the terminal:
===
TypeError: Couldn't find foreign struct converter for 'cairo.Context'
1518159014.524267 [gpodder.log] ERROR: Uncaught exception: TypeError: Couldn't 
find foreign struct converter for 'cairo.Context'
===

Best regards, and thanks for the great work
---
Dimitri 
On Fri, 09 Feb 2018 04:24:04 +
"Debian Bug Tracking System"  wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the gpodder package:
> 
> #889850: gpodder fails to launch -- ModuleNotFoundError: No module named 
> 'cairo'
> 
> It has been closed by tony mancill .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact tony mancill 
>  by
> replying to this email.
> 
> 
> -- 
> 889850: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889850
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems

Bug#889950: ITP: gloo/0.5.0 -- Collective communications library for machine learning

[Lumin]

Package:wnpp
Severity: wishlist
Owner: lumin 

* Package name: gloo
  Version : 0.5.0
  Upstream Author : facebook
* URL : https://github.com/facebookincubator/gloo
* License : BSD-3-Clause
  Programming Lang: c++
  Description : Collective communications library for machine learning

This library is a PyTorch dependency.

-- 
Best,

Bug#888811: dnscrypt-proxy: upstream gone, new package

[Brian Clinkenbeard]

Source: dnscrypt-proxy
Followup-For: Bug #11

A stable release of 2.0.0 is now here: 
https://github.com/jedisct1/dnscrypt-proxy/releases/tag/2.0.0

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

Kernel: Linux 4.13.0-1-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: sysvinit (via /sbin/init)

Bug#882141: closed by Scott Kitterman <sc...@kitterman.com> (Bug#882141: fixed in postfix 3.2.4-1)

[Scott Kitterman]

On Wed, 7 Feb 2018 15:11:15 +0100 Bastian Blank  wrote:
> Control: reopen -1
> Control: found -1 3.2.5-1
> 
> On Fri, Dec 15, 2017 at 06:24:06AM +, Debian Bug Tracking System wrote:
> >* Rewrite debian/postfix-instance-generator to avoid use of postmulti
> >  to fix failures when inet_interfaces != all Closes: #882141
> 
> It now uses postconf -h multi_instance_directories.  Why do you think
> this would work better?
> 
> | # postconf -h multi_instance_directories
> | postconf: fatal: parameter inet_interfaces: no local interface found for 
1.2.3.4

Because I don't get that error when I try to replicate the condition.

$ systemctl status postfix@-.service
● postfix@-.service - Postfix Mail Transport Agent (instance -)
   Loaded: loaded (/lib/systemd/system/postfix@.service; disabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Fri 2018-02-09 01:28:59 EST; 17s 
ago
 Docs: man:postfix(1)
  Process: 3710 ExecStop=/usr/sbin/postmulti -i - -p stop (code=exited, 
status=0/SUCCESS)
  Process: 3783 ExecStart=/usr/sbin/postmulti -i - -p start (code=exited, 
status=1/FAILURE)
  Process: 3728 ExecStartPre=/usr/lib/postfix/configure-instance.sh - 
(code=exited, status=0/SUCCESS)

Feb 09 01:28:57 relay02 systemd[1]: Starting Postfix Mail Transport Agent 
(instance -)...
Feb 09 01:28:58 relay02 postmulti[3783]: fatal: parameter inet_interfaces: no 
local interface found for 1.2.3.4
Feb 09 01:28:59 relay02 systemd[1]: postfix@-.service: Control process exited, 
code=exited status=1
Feb 09 01:28:59 relay02 systemd[1]: Failed to start Postfix Mail Transport 
Agent (instance -).
Feb 09 01:28:59 relay02 systemd[1]: postfix@-.service: Unit entered failed 
state.
Feb 09 01:28:59 relay02 systemd[1]: postfix@-.service: Failed with result 
'exit-code'.
postconf multi_instance_directories
multi_instance_directories =

Not sure how to replicate the error you're having.

Scott K

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

[Maxime Werlen]

Hi Paul,

Thanks for your time reviewing this package.
I've tried to fix as much issues as I'm capable.


Here is a list of changes I've applied on the new package :

   - Binary package renamed to python3-minidb
   - Switched to github orig.tar.gz to be consistent with debian/watch
   - Switched from setup-tools to distutils as declared build dependency
   - Added file example.py in minidb.example to be deployed by
   dh_installexamples
   - Changed debian/* licence to ISC (same as source package)
   - Cleaned Licence text in debian/copyright
   - Wraped-and-sorted debian directory
   - Wraped and fixed debian/watch
   - Added an upstream/metadata file
   - Removed trailing spaces in debian/* files
   - Updated URL to use secured ones
   - Removed section from debian/control binary package (to avoid
   duplication with source package)
   - Upgraded debian/compat to 11
   - Added AutoPkgTest stanza


I've some more work to do but not in the packaging project :

   - File a bug against gpodder to depends upon minidb package
   - Ask upstream to sign minidb releases
   - Discuss with upstream about others check-all-the-things warnings


Best Regards,

Maxime

2018-01-21 6:25 GMT+01:00 Paul Wise :

> Control: owner -1 !
> Control: tags -1 + moreinfo
>
> I intend to sponsor this because the urlwatch RFS needs it.
>
> On Fri, Jan 19, 2018 at 4:42 AM, Maxime Werlen wrote:
>
> > I am looking for a sponsor for my package "minidb"
>
> In future, I'd recommend using the BTS block command when filing an RFS
> that depends on another RFS.
>
> https://www.debian.org/Bugs/server-control#block
>
> You can use this syntax when mailing submit@ or existing bugs (-1 means
> the bug you are mailing or submitting):
>
> Control: block 887659 by -1
>
> These issues block the upload of minidb to Debian:
>
> Since minidb only includes a Python 3 module, you need to rename the
> binary package to python3-minidb. The source package can stay the same.
>
> The orig.tar.gz you uploaded to Debian mentors is different to the one
> that the debian/watch file downloads. You can use diffoscope to see the
> differences, but it looks like you used the one from pip? That is
> missing example.py but has a new PKG-INFO file.
>
> It would be nice to fix these issues at some point:
>
> Upstream is using distutils but debian/control has python3-setuptools.
> The package still builds because python3-distutils is installed anyway.
>
> Please include example.py from the github tar.gz as an example in the
> binary package, using dh_installexamples.
>
> Once minidb is accepted, please file a bug against gpodder asking the
> maintainer to depend on minidb instead of using the internal copy.
>
> I suggest licensing the debian/ directory under the same license as
> upstream, so that they can include any patches or other info from
> Debian with zero friction.
>
> Please remove the comment characters, the ASCII minidb logo and the
> Copyright line from the ISC license in debian/copyright.
>
> Please remove the commented-out Vcs-* fields from debian/control unless
> you intend to use them, please note that alioth has been replaced by
> salsa.debian.org.
>
> I like to wrap and sort the debian/ directory:
>
> wrap-and-sort --short-indent --wrap-always --sort-binary-packages
> --trailing-comma
>
> I like to wrap debian/watch to separate fields.
>
> uscan fails unless I delete the filenamemangle:
>
> $ uscan --verbose --download-current-version --destdir .
> ...
> Could not read .//thp/minidb/archive/minidb-2.0.2.tar.gz: No such file or
> directory at /usr/bin/mk-origtargz line 397.
> uscan: error: mk-origtargz --package minidb --version 2.0.2 --rename
> --compression gzip --directory . --copyright-file debian/copyright
> .//thp/minidb/archive/minidb-2.0.2.tar.gz subprocess returned exit status
> 2
>
> Please add some upstream metadata:
>
> https://wiki.debian.org/UpstreamMetadata
>
> Please ask upstream to sign their commits and tarballs with OpenPGP:
>
> https://mikegerwitz.com/papers/git-horror-story
> https://wiki.debian.org/Creating%20signed%20GitHub%20releases
>
> Automatic checks:
>
> lintian
>
> I: minidb source: binary-control-field-duplicates-source field "section"
> in package minidb
> P: minidb source: file-contains-trailing-whitespace debian/changelog
> (line 3)
> P: minidb source: file-contains-trailing-whitespace debian/control (line
> 4)
> P: minidb source: package-uses-old-debhelper-compat-version 10
> P: minidb source: insecure-copyright-format-uri
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> I: minidb source: testsuite-autopkgtest-missing
> P: minidb source: debian-watch-may-check-gpg-signature
> P: minidb: no-upstream-changelog
> I: minidb: extended-description-is-probably-too-short
>
> check-all-the-things
>
> $ env PERL5OPT=-m-lib=. duck
> I: debian/copyright:1: URL: http://www.debian.org/doc/pack
> aging-manuals/copyright-format/1.0/: INFORMATION (Certainty:possible)
>URL schema changed from 

Bug#887659: RFS: urlwatch/2.7-1 [ITA]

[Maxime Werlen]

Hi Paul,

Thanks for your time reviewing my packages.
I've tried to fix as much issues as I'm capable.

Here is a list of changes I've applied to the new package :
* Added missing build-dependencies
* Wrapped-and-sorted debian directory files
* Simplified debian/clean
* Upgraded debian/compat to level 11
* Switched to https on every compatible url
* Corrected typo on upstream copyright years
* Removed unused patch (example_path.diff)
* Created a projet on salsa.debian.org and changed repo URL
* Fixed and wrapped debian/watch
* Changed license keyword to BSD-3-clause
* Added a patch to strip Dependencies section from README.md
* Removed trailing whitespaces
* Added upstreamMetadata file
* Add a NEWS.Debian about migrating from the legacy hooks to the new
class-based filter system.
* Build now works with a pbuilder chroot
* Added a patch to fix setuptools warning about unknown option (accepted
upstream)
* Added some tests
* Updated changelog

I've some more work to do but not in the packaging project :
* File a bug against gpodder to use python3-minidb package instead of a
local copy
* Ask upstream to sign their commits and tarballs
* Alert upstream about XDG_CONFIG_HOME used for cache (instead of
XDG_CACHE_HOME)
* Ask upstream to give a warning when the legacy hooks are being used.

Best Regards,

Maxime

2018-01-20 11:54 GMT+01:00 Paul Wise :

> Control: owner -1 !
> Control: tags -1 + moreinfo
>
> I intend to sponsor this.
>
> On Thu, 18 Jan 2018 21:42:33 +0100 Maxime Werlen wrote:
>
> > I am looking for a sponsor for my package "urlwatch"
>
> These issues block the upload of this package:
>
> The package FTBFS in a clean chroot, you need to package minidb and
> build-depend on python3-minidb, python3-setuptools, python3-keyring,
> python3-appdirs and python3-requests.
>
> https://wiki.debian.org/pbuilder
>
> It would be nice to fix these issues at some point:
>
> When you package minidb, if possible, please also make a python-minidb
> package so that you can report a bug against gpodder to get it to use
> the system minidb as it currently includes a minidb copy.
>
> I would suggest stripping the DEPENDENCIES section from README.md in
> the installed binary package since users of the binary package will
> already automatically get the dependencies installed.
>
> I would suggest adding a NEWS.Debian about migrating from the legacy
> hooks to the new class-based filter system.
>
> debian/copyright has an incorrect copyright year for the upstream code,
>  upstream mentions 2016 but debian/copyright has 2018.
>
> debian/copyright should have BSD-3-Clause rather than BSD-3-Clause.
>
> debian/clean can probably be reduced to one line:
>
> lib/urlwatch.egg-info/
>
> I like to wrap and sort the debian directory:
>
> wrap-and-sort --short-indent --wrap-always --sort-binary-packages
> --trailing-comma
>
> I like to wrap debian/watch to separate fields:
>
> version=3
> opts="filenamemangle=s/(\d[\d\.]*)\.tar\.gz/urlwatch-$1.tar.gz/" \
> https://github.com/thp/urlwatch/releases \
> (?:.*/)?v?(\d[\d\.]*)\.tar\.gz
>
> uscan fails unless I delete the debian/watch opts:
>
> $ uscan --verbose --download-current-version --destdir .
> ...
> uscan info: Executing internal command:
>mk-origtargz --package urlwatch --version 2.7 --rename --compression
> gzip --directory . --copyright-file debian/copyright
> .//thp/urlwatch/archive/urlwatch-2.7.tar.gz
> Could not read .//thp/urlwatch/archive/urlwatch-2.7.tar.gz: No such file
> or directory at /usr/bin/mk-origtargz line 397.
> uscan: error: mk-origtargz --package urlwatch --version 2.7 --rename
> --compression gzip --directory . --copyright-file debian/copyright
> .//thp/urlwatch/archive/urlwatch-2.7.tar.gz subprocess returned exit
> status 2
>
> Please add some upstream metadata:
>
> https://wiki.debian.org/UpstreamMetadata
>
> Please ask upstream to sign their commits and tarballs with OpenPGP:
>
> https://mikegerwitz.com/papers/git-horror-story
> https://wiki.debian.org/Creating%20signed%20GitHub%20releases
>
> Upstream should give a warning when the legacy hooks are being used.
>
> Upstream is storing a cache file in the xdg config directory, I suggest
> that they probably need to read the specs and fix the code/docs:
>
> https://specifications.freedesktop.org/basedir-spec/basedir-
> spec-latest.html
>
> examples_path.diff is still present in the source package but is not
> present in the series file. IMO it should either get deleted or still
> be present in the series file, possibly commented out and with a reason
> for being disabled in a comment before that.
>
> Automatic checks:
>
> lintian
>
> P: urlwatch source: file-contains-trailing-whitespace debian/changelog
> (line 5)
> P: urlwatch source: file-contains-trailing-whitespace debian/control
> (line 5)
> P: urlwatch source: file-contains-trailing-whitespace debian/control
> (line 21)
> P: urlwatch source: file-contains-trailing-whitespace debian/rules (line
> 7)
> P: urlwatch source: 

Bug#888952: nvidia-driver and opencl

[Hiromasa YOSHIMOTO]

I comfirm that setuid(0) fixes my issue! Thank you for your advise.
I made a small patch of the workaround for nvidia-modprobe.
Please check the attached file.

The configuration in /etc/modprobe.d/nvidia.conf requires
to fork /bin/sh with root privilege because it contains some shell commands.
So, I think this issue affects to most of users.

Regards,
Hiromasa YOSHIMOTO
--- nvidia-modprobe-384.111.orig/modprobe-utils/nvidia-modprobe-utils.c
+++ nvidia-modprobe-384.111/modprobe-utils/nvidia-modprobe-utils.c
@@ -374,6 +374,10 @@ static int modprobe_helper(const int pri
  */
 silence_current_process();
 
+	/* Workaround for debian's /etc/modprobe.d/nvidia.conf configuration. 
+	 * See Bug#888952 for details */
+	setuid(0);
+
 execle(modprobe_path, "modprobe",
module_name, NULL, envp);
 

Bug#884130: Botan2 update?

[Adam Majer]

On 02/08/2018 07:01 PM, László Böszörményi (GCS) wrote:

  It's already packaged[1] and uploaded. Every new package (source or
binary) needs FTP Master approval first. It needs their time, I don't
know when it will happen. Hopefully soon, I'm waiting for a month
already.



I'm not sure if linking with OpenSSL is still a problem (from license 
standpoint). The last Botan wasn't linked with OpenSSL because of license.


Thank you for packaging. :D

- Adam

Bug#889850: gpodder fails to launch -- ModuleNotFoundError: No module named 'cairo'

[tony mancill]

On Wed, Feb 07, 2018 at 10:24:04PM +0100, Dimitri Chausson wrote:
> Package: gpodder
> Version: 3.10.0-3
> Severity: normal
> 
> Dear Maintainer,
> 
> After a usual package update routine, I cannot launch gpodder anymore. A call
> from the command line gives the following output:

Hello Dimitri,

This is, as Thomas suggested, due to a missing dependency on
python3-cairo.  I have uploaded 3.10.0-4 to address. 

Thank you for the bug report!
tony


signature.asc
Description: PGP signature

Bug#889949: ITP: golang-github-opencontainers-runtime-spec -- OCI Runtime Specification

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: golang-github-opencontainers-runtime-spec
  Version : 1.0.1+git20171211.8.b2d941e-1
  Upstream Author : Open Container Initiative
* URL : https://github.com/opencontainers/runtime-spec
* License : Apache-2.0
  Programming Lang: Go
  Description : OCI Runtime Specification

 Open Container Initiative Runtime Specification The Open Container
 Initiative (https://www.opencontainers.org) develops specifications for
 standards on Operating System process and application containers.

- why is this package useful/relevant?

It is a dependency of containerd from version 0.2.9.

- how do you plan to maintain it?

I plan to maintain it within the golang packaging team.

Bug#889948: ITP: runtime-spec -- OCI Runtime Specification

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: runtime-spec
  Version : 1.0.1+git20171211.8.b2d941e-1
  Upstream Author : Open Container Initiative
* URL : https://github.com/opencontainers/runtime-spec
* License : Apache-2.0
  Programming Lang: Go
  Description : OCI Runtime Specification

 Open Container Initiative Runtime Specification The Open Container
 Initiative (https://www.opencontainers.org) develops specifications for
 standards on Operating System process and application containers.

- why is this package useful/relevant?

It is a dependency of containerd from version 0.2.9.

- how do you plan to maintain it?

I plan to maintain it within the golang packaging team.

Bug#886944: python3-regex: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[Sandro Tosi]

Hello Nicholas,

On Tue, Feb 6, 2018 at 10:15 PM, Nicholas D Steeves  wrote:
>
> Hi Sandro,
>
> Would you like a patch for current_version-new_revision or for
> new_upstream_version-1?  I assumed the latter, and send two patches
> also assuming that you'd squash them.  Of course I'd be happy to
> squash them myself and rewrite the messages.  Whatever you prefer :-)

i would prefer a single patch for current_version-new_revision (small
upload to fix the issue) - i'll then prepare a new upstream release
soon after.

Thanks,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#889947: ITP: golang-github-containerd-go-runc -- runc bindings for Go

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: golang-github-containerd-go-runc
  Version : 0.0~git20180125.0.4f6e87a-1
  Upstream Author : containerd
* URL : https://github.com/containerd/go-runc
* License : Apache-2.0
  Programming Lang: Go
  Description : runc bindings for Go

 This is a package for consuming the runc binary in your Go applications. It
 tries to expose all the settings and features of the runc CLI. If there is
 something missing then add it, its opensource!

- why is this package useful/relevant?

It is a dependency of containerd from version 0.2.9.

- how do you plan to maintain it?

I plan to maintain it within the golang packaging team.

Bug#889946: src:python-coverage: Build binary package for Jython environment

[Ben Finney]

Control: block -1 by 889945

On 09-Feb-2018, Ben Finney wrote:

> Please build a binary package, perhaps named ‘jython-coverage’, for
> the Coverage library in the Jython runtime environment.

The upstream build system requires Setuptools in the Python
environment. To build for Jython, we need a Debian package of
Setuptools for Jython.

-- 
 \ “The truth is the most valuable thing we have. Let us economize |
  `\ it.” —Mark Twain, _Following the Equator_ |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#889946: src:python-coverage: Build binary package for Jython environment

[Ben Finney]

Source: python-coverage
Severity: wishlist

The upstream Coverage.py library supports the Jython environment.

Please build a binary package, perhaps named ‘jython-coverage’, for
the Coverage library in the Jython runtime environment.

-- 
 \“Conscience is the inner voice that warns us somebody is |
  `\   looking.” —Henry L. Mencken |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#889945: src:python-setuptools: build package for Jython environment

[Ben Finney]

Source: python-setuptools
Severity: wishlist

The Setuptools build system supports the Jython environment since
around 0.6.10.

Please build a binary package, perhaps named ‘jython-setuptools’, for
the Jython environment in Debian.

-- 
 \   “All progress has resulted from people who took unpopular |
  `\  positions.” —Adlai Stevenson |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#889944: ITP: golang-github-containerd-console -- console package for Go

[Arnaud Rebillout]

Package: wnpp
Severity: wishlist
Owner: Arnaud Rebillout 

* Package name: golang-github-containerd-console
  Version : 0.0~git20170925.0.84eeaae-1
  Upstream Author : containerd
* URL : https://github.com/containerd/console
* License : Apache-2.0
  Programming Lang: Go
  Description : console package for Go

Golang package for dealing with consoles. Light on deps and a simple API.

- why is this package useful/relevant?

It is a dependency of containerd from version 0.2.9,

- how do you plan to maintain it?

I plan to maintain it within the golang packaging team.

Bug#840014: webcheckout: missing URL sanitization

[Paul Wise]

On Thu, 2018-02-08 at 21:44 +0100, Jakub Wilk wrote:

> It's hard to tell whether they agree, because disabling git-remote-ext 
> by default is not documented AFAICT. See bug #867699.

Thanks for the pointer.

> Users might need to re-enable git-remote-ext for their own purposes, so 
> this needs to be fixed in webcheckout.

How would you suggest doing that?

 * Blacklist ext::
 * Whitelist good remote protocols

How should it handle the bad remotes?

* Fail with "potentially unsafe git remote"
* Fail with "potentially unsafe git URL, may execute code: ext::*"
* Fail with "potentially unsafe git URL, may execute code:
 git clone ext::*"

> webcheckout is also susceptible to option injection, but I couldn't find 
> a way to exploit it for anything nefarious.

I made a patch for that locally, but I wanted the commit to link to the
canonical document about option injection but I cannot find a link.
IIRC it includes how to get RCE with tar/cpio/etc option injection.
Do you remember where that can be found?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#889820: debian-policy: 12.5, relaxed requirement for copyright location

[Javier Serrano Polo]

//X-Debbugs-CC:

-doc suffix cannot be used, e.g. acl2-doc. I am going with -doc-minimal
and Outdates, which is softer than Breaks. I will return when support is
ready.


smime.p7s
Description: S/MIME cryptographic signature

Bug#889866: nagstamon: crashes under openbox: python tracebacks, SIGSEGV

[Paul Wise]

Control: tags -1 + fixed-upstream

On Thu, 2018-02-08 at 12:44 +0100, Moritz Schlarb wrote:

> this is also reported upstream and there is some work in progress

Upstream seems to have closed it:

https://github.com/HenriWahl/Nagstamon/issues/357#issuecomment-316995737

> A workaround would be to install e.g. "notification-daemon"

Hmm, I have that installed, looks like it doesn't get auto-started.

I also wonder if this bug in notification-daemon is related:

https://bugs.debian.org/887506

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#888985: [pkg-go] RFS: irtt/0.9-1 [ITP] (#888985)

[Pete Heist]

> On Feb 7, 2018, at 10:03 AM, Michael Stapelberg  wrote:
> 
> Thanks for contributing this package.
> 
> The resulting binary package irtt_0.9-1_amd64.deb contains both a binary and 
> Go source code. This is a bit unusual: in Debian, we only package Go source 
> code to build other Go programs (not for developers). Hence, we usually 
> provide either a binary package with programs or an arch:all package with Go 
> source. It’s fine to have a source package which provides both, but please 
> separate the source from the binaries. Have a look at 
> https://anonscm.debian.org/cgit/collab-maint/codesearch.git/ 
>  for an example 
> of this pattern.
> 
> Further, please address the following lintian warnings:
> 
> P: irtt source: package-uses-old-debhelper-compat-version 10
> P: irtt source: insecure-copyright-format-uri 
> http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 
> 
> I: irtt source: out-of-date-standards-version 3.9.8 (released 2016-04-06) 
> (current is 4.1.3)
> I: irtt source: testsuite-autopkgtest-missing
> W: irtt: priority-extra-is-replaced-by-priority-optional

I’m on Debian sid and closer now, with a binary only package (using 
dh_auto_install -- --no-source). There’s still some lintian confusion. When I 
run it, I get:

$ cat /etc/debian_version 
buster/sid
$ lintian --version
Lintian v2.5.74
$ lintian irtt_0.9+git20180209.9cda776-1_amd64.changes
P: irtt source: debian-watch-does-not-check-gpg-signature
P: irtt: no-upstream-changelog

From the original warnings you sent I know I’ve fixed all except "I: irtt 
source: testsuite-autopkgtest-missing”, but a) I’m not seeing that warning and 
b) I’m seeing two others. So my questions are:

1) What are your expectations for 'testsuite-autopkgtest-missing', and why am I 
not seeing it? There are no unit tests to run.

2) Do you care about 'debian-watch-does-not-check-gpg-signature' and 
'no-upstream-changelog’? I do not sign the upstream, and the changes are in 
README.md, in case those should be split out...

Thanks!
Pete

Bug#889751: [pkg-gnupg-maint] Bug#889751: scdaemon: BAD PIN since 2.2.4-2 upgrade

[Daniel Kahn Gillmor]

Control: severity 889751 serious

Hi Corsac--

On Wed 2018-02-07 11:28:42 +0100, Yves-Alexis Perez wrote:
> On Tue, 2018-02-06 at 20:42 +0100, Yves-Alexis Perez wrote:
>
>> since the recent 2.2.4-2 upgrade, when trying to use my smartcard (auth
>> key for SSH for example), I get:
>> 
>> févr. 06 20:37:35 scapa gpg-agent[1793]: scdaemon[26257]: verify CHV2 
>> failed: Bad PIN
>> févr. 06 20:37:35 scapa gpg-agent[1793]: scdaemon[26257]: app_auth failed: 
>> Bad PIN
>> févr. 06 20:37:35 scapa gpg-agent[1793]: smartcard signing failed: Bad PIN
>> 
>> even though I'm sure it's the right PIN.

ugh, i'm sorry to hear this.

>> At that point I'm a little reluctant in doing another try because it's
>> the last one before I need to get my admin PIN.
>
> Downgrading scdaemon, gpg-agent and gpgconf to 2.2.4-1 fixes the problem. If
> you need more information, please ask.

I think the main likely culprit is 
debian/patches/scd-Support-KDF-Data-Object-of-OpenPGPcard-V3.3.patch,
which was cherry-picked from upstream.

Can you give more detail about what specific smartcard you have?

can you try rebuilding with that patch removed and testing that?  If
you'd prefer i upload something to experimental for you to try without
having to rebuild, let me know and i'll do that.

> I've raised the severity to important, but actually I don't think scdaemon
> should migrate to testing as-is, so I'd be inclined to raise again to RC
> severity.

This e-mail raises the severity to serious, so it should prevent
migration until we've got this sorted out.

  --dkg


signature.asc
Description: PGP signature

Bug#835542: [bbb0643] Fix for Bug#835542 committed to git

[Manoj Srivastava]

tags 835542 + pending
thanks
Hi,

 The following change has been committed for this bug by
 Manoj Srivastava  on the branch 
 master at Thu, 8 Feb 2018 16:50:37 -0800.

 The fix will be in the next upload. 
=
[master]: New upstream version, with bug fixes.

Bug fix: "comparison between signed and unsigned integer expressions",
thanks to Frank Heckenbach. This should be fixed now. (Closes: #835542).

Bug fix: "Please update homepage in package description", thanks to
Tim Ruehsen (Closes: #851675).

Bug fix: "Should Suggest: flex-doc", thanks to Yuri DElia (Closes: 
#856956).

Signed-off-by: Manoj Srivastava 
=

Bug#889892: mpv: fix for CVE-2018-6360 breaks youtube playlists

[Luciano Bello]

On 2018-02-08 09:01, James Cowgill wrote:
> I think the attached patch will fix this (which I have also just
> uploaded to unstable).

Uploaded. Thanks!

/luciano



signature.asc
Description: OpenPGP digital signature

Bug#889943: logrotate does not correctly process %V (week number) in dateext

[Steffen Scheib]

Package: logrotate
Version: 3.8.7-1+b1
Severity: normal

Dear Maintainer,

logrotate does not seem to process %V (week number), when added in dateext.
See the following output:

---
rotating pattern: /var/log/nginx/*.log  forced from command line (52 rotations)
empty log files are rotated, old logs are removed
considering log /var/log/nginx/access.log
  log needs rotating
considering log /var/log/nginx/error.log
  log needs rotating
rotating log /var/log/nginx/access.log, log->rotateCount is 52
Converted ' _%Y_%V' -> '_%Y_%%V'
dateext suffix '_2018_%V'
glob pattern '_[0-9][0-9][0-9][0-9]_%V'
compressing log with: /usr/bin/lzop
destination /var/log/nginx/access.log_2018_%V already exists, skipping rotation
rotating log /var/log/nginx/error.log, log->rotateCount is 52
Converted ' _%Y_%V' -> '_%Y_%%V'
dateext suffix '_2018_%V'
glob pattern '_[0-9][0-9][0-9][0-9]_%V'
compressing log with: /usr/bin/lzop
destination /var/log/nginx/error.log_2018_%V already exists, skipping rotation
---

Logroate for nginx is configured as follows (vim /etc/logrotate.d/nginx)
/var/log/nginx/*.log {
  weekly
  missingok
  rotate 52
  compress
  delaycompress
  create 0640 www-data adm
  sharedscripts
  prerotate
if [ -d /etc/logrotate.d/httpd-prerotate ]; then \
run-parts /etc/logrotate.d/httpd-prerotate; \
fi \
  endscript
  postrotate
invoke-rc.d nginx rotate >/dev/null 2>&1
  endscript
  dateext
  dateformat _%Y_%V
  compresscmd /usr/bin/lzop
  compressoptions -U -9
  compressext .lzo
}

I was expecting logrotate to be able interpret any dateformats, which are 
specified in man date - in this case the weeknumber.


-- Package-specific info:
Contents of /etc/logrotate.d
total 40
-rw-r--r-- 1 root root 406 Feb  9 00:42 apt
-rw-r--r-- 1 root root 197 Feb  9 00:42 aptitude
-rw-r--r-- 1 root root 237 Feb  9 00:41 emby-server
-rw-r--r-- 1 root root 378 Feb  9 00:42 fail2ban
-rw-r--r-- 1 root root 203 Feb  9 00:43 iptables
-rw-r--r-- 1 root root 440 Feb  9 00:48 nginx
-rw-r--r-- 1 root root 351 Dec 26 17:25 nginx.dpkg-dist
-rw-r--r-- 1 root root 209 Feb  6 18:08 plexdrive
-rw-r--r-- 1 root root 308 Feb  4 19:03 ramdisks
-rw-r--r-- 1 root root 729 Feb  4 19:02 rsyslog


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

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

Versions of packages logrotate depends on:
ii  base-passwd 3.5.37
ii  cron [cron-daemon]  3.0pl1-127+deb8u1
ii  libacl1 2.2.52-2
ii  libc6   2.19-18+deb8u10
ii  libpopt01.16-10
ii  libselinux1 2.3-2

Versions of packages logrotate recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2

logrotate suggests no packages.

-- Configuration Files:
/etc/logrotate.conf changed:
daily
rotate 30
create
compress
include /etc/logrotate.d
/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 12
dateext
dateformat _%Y-%m
}
/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 12
dateext
dateformat _%Y-%m
}


-- no debconf information

Bug#889732: libconfig-model-dpkg-perl: Does not recognize Salsa platform in Vcs field

[gregor herrmann]

On Thu, 08 Feb 2018 20:36:39 +0100, Dominique Dumont wrote:

> > Warning in 'control source Vcs-Browser' value
> > 'https://salsa.debian.org/blahblah-team/blah.git': URL is not the canonical 
> > one for repositories hosted on Alioth.
> I wonder what is the best solution here. 
> cme issues a warning is the vcs browser URL does not point to 
> anonscm.debian.org. This host currently redirects to alioth. IIRC, it will  
> point to salsa once the transition is done.

No, TTBOMK it won't. (So much for generic hostnames.)
There's a rewriter [0] in place, but anonscm.debian.org won't go
anywhere, AFAIK.
 
> What can we do in the meantime with cme ?
> - accepts both salsa and anonscm ? (this is a change that would need to be 
> reverted once alioth to salsa transition is done)
> - remove the check until the transition is done, so no warning is emitted
> - do nothing (may be update the doc)

Maybe accept alioth/anonscm and salsa for now, and remove the former
once it's shut down.
Or just switch to salsa. Or don't do nothing now and switch to salsa
once alioth is history.


Cheers,
gregor


[0] https://salsa.debian.org/salsa/AliothRewriter 

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


signature.asc
Description: Digital Signature

Bug#835542: [c363677] Fix for Bug#835542 committed to git

[Manoj Srivastava]

tags 835542 + pending
thanks
Hi,

 The following change has been committed for this bug by
 Manoj Srivastava  on the branch 
 master at Thu, 8 Feb 2018 15:41:28 -0800.

 The fix will be in the next upload. 
=
[master]: New upstream version, with bug fixes.

Bug fix: "comparison between signed and unsigned integer expressions",
thanks to Frank Heckenbach. This should be fixed now. (Closes: #835542).

Bug fix: "Please update homepage in package description", thanks to
Tim Ruehsen (Closes: #851675).

Bug fix: "Should Suggest: flex-doc", thanks to Yuri DElia (Closes: 
#856956).

Signed-off-by: Manoj Srivastava 
=

Bug#889942: ITP: ignition-fuel-tools -- Classes and tools for interacting with Ignition Fuel

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-fuel-tools
  Version : 1.0.0
  Upstream Author : Open Robotics 
* URL : https://ignitionrobotics.org/libs/fuel_tools
* License : Apache 2
  Programming Lang: C++
  Description : Classes and tools for interacting with Ignition Fuel Servers

Ignition Fuel Tools is composed by a client library and command line
tools for interacting with Ignition Fuel servers. These servers host and
manage different 3D robotics models.

Bug#494060: htop: Feature Request: All CPUs display split across left/right

[Tim Connors]

On Thu, 8 Feb 2018, Steve Cotton wrote:

> On Thu, Aug 07, 2008 at 10:37:48AM +1000, Tim Connors wrote:
> > Package: htop
> > Version: 0.7-1
> > Severity: wishlist
> >
> > It would be nice if there was an option with "All CPUs" that could let
> > it split horizontally between the left and right displays (even CPUs
> > on left, odd on right) in order to minimise wasted blank space in that
> > area at the top.  As it is, I define all my CPUs manually, split
> > across the left and right displays, but this falls down when I want to
> > run htop on a machine with fewer (see bug #494057) or more CPUs.
>
> Hi Tim,
>
> This wishlist request is still open in Debian's BTS, but AFAICS it was
> implemented in version 1.0 (and packaged as Debian version 1.0-1). Is
> there anything left to do?

Ah, cool, indeed that works.

Yes, please close.

-- 
Tim Connors

Bug#889941: xul-ext-treestyletab: please package xul-treestyletab 2.4.11 for firefox 57 or later

[shirish शिरीष]

Package: xul-ext-treestyletab
Version: 0.19.2017061601-1
Severity: normal
Followup-For: Bug #881812

Dear Maintainer,

xul-treestyletab was just updated few hours back, please see if you
are able to package the new version. It needs to done for firefox 57.0
and later. The new version could remain in either unstable or
experimental till another 6 months or whenever a new ESR version of
firefox would launch. Figures takes a year or so.

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

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

Versions of packages xul-ext-treestyletab depends on:
ii  firefox  58.0.1-1
ii  firefox-esr  52.6.0esr-2

xul-ext-treestyletab recommends no packages.

xul-ext-treestyletab suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#878757: [PKG-Openstack-devel] Bug#878757: Openvswitch must started before networking servise

[Thomas Goirand]

On 02/04/2018 09:34 PM, Michael Biebl wrote:
> On Mon, 16 Oct 2017 20:28:26 +0700 Fedor Goncharov  wrote:
>> Package: openvswitch-switch
>> Version: 2.6.2~pre+git20161223-3
>> Priority: critical
>>
>> The Openvswitch daemon must be started before the network.service. 
>> Because when the initiation of the network started interfaces from the 
>> options should exist, or if you try to configure openvswitch in 
>> /etc/network/interfaces, then the ovs daemon must be running to execute 
>> commands.
>> Please create a systemd configuration with the option "Before: 
>> networking.service" for a stable version of debian.
> 
> That seems like the wrong thing to do.
> networking.service is specific to ifupdown (auto). We do have several
> other network configuration systems. I hope this was not actually
> applied as a fix? The changelog is unfortunately unclear in that regard:
> 
>   * Added 2 debian/*.service files (Closes: #878757, #771507).
> 
> Thomas, can you please post the complete change that was actually applied.
> 
> 
> Michael

Michael,

Here's the commit:

https://salsa.debian.org/openstack-team/third-party/openvswitch/commit/650fce2f45aac5a46e1cec6ea48dffce0b095c23

I very much would appreciate any comment / suggestion you would make.
Even better if you can send us a patch (or a merge request in Salsa). I
have to admit that the interaction between the .service file and the
ifupdown hook is a bit hard to understand for me, so I took what was in
Ubuntu, and it seemed to work as expected for me.

Cheers,

Thomas Goirand (zigo)

Bug#889940: stretch-pu: package miniupnpd/1.8.20140523-4.1 fix for CVE-2017-1000494

[Thomas Goirand]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Dear release team,

I'd like to push for an update of miniupnpd in Stretch, in order to fix
CVE-2017-1000494. The security team decided to go without a DSA.

Attached is the debdiff for the fix.

Also, please let me know if my .changes must include the .orig.tar.gz,
if it must, I'll rebuild with --force-orig-source. I'm sorry for I
never remember when it should or not... :(

I've uploaded the built package there if you want to have a look:
http://sid.gplhost.com/stretch-proposed-updates/miniupnpd/

Cheers,

Thomas Goirand (zigo)
diff -Nru miniupnpd-1.8.20140523/debian/changelog 
miniupnpd-1.8.20140523/debian/changelog
--- miniupnpd-1.8.20140523/debian/changelog 2017-01-13 12:52:51.0 
+0100
+++ miniupnpd-1.8.20140523/debian/changelog 2018-02-07 12:18:50.0 
+0100
@@ -1,3 +1,9 @@
+miniupnpd (1.8.20140523-4.1+deb9u1) stretch; urgency=medium
+
+  * Apply patch from upstream for CVE-2017-1000494 (Closes: #887129).
+
+ -- Thomas Goirand   Wed, 07 Feb 2018 12:18:50 +0100
+
 miniupnpd (1.8.20140523-4.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru miniupnpd-1.8.20140523/debian/patches/CVE-2017-1000494.patch 
miniupnpd-1.8.20140523/debian/patches/CVE-2017-1000494.patch
--- miniupnpd-1.8.20140523/debian/patches/CVE-2017-1000494.patch
1970-01-01 01:00:00.0 +0100
+++ miniupnpd-1.8.20140523/debian/patches/CVE-2017-1000494.patch
2018-02-07 12:18:43.0 +0100
@@ -0,0 +1,35 @@
+Description: fix for CVE-2017-1000494
+ This patch was backported by upstream.
+Author: Thomas Bernard 
+Forwarded: not-needed
+Bug-Debian: https://bugs.debian.org/887129
+Last-Update: 2018-02-07
+
+diff -ru miniupnpd-1.8.20140523.orig/minixml.c miniupnpd-1.8.20140523/minixml.c
+--- miniupnpd-1.8.20140523.orig/minixml.c  2014-02-05 17:29:33.0 
+0100
 miniupnpd-1.8.20140523/minixml.c   2018-02-02 16:46:19.115527000 +0100
+@@ -161,7 +161,8 @@
+   if (p->xml >= p->xmlend)
+   return;
+   }
+-  if(memcmp(p->xml, " */
++  if((p->xmlend >= (p->xml + (9 + 3))) && 
(memcmp(p->xml, 

Bug#889938: separate scapy from scapy3k

[Daniel Kahn Gillmor]

Package: src:scapy3k
Version: 0.23-1
Severity: normal
Control: clone -1 -2
Control: affects -1 + src:scapy
Control: reassign -2 src:scapy
Control: affects -2 + src:scapy3k

in debian, we have python-scapy and python3-scapy packages from
different upstream sources:

python-scapy comes from https://github.com/secdev/scapy/

python3-scapy comes from https://github.com/phaethon/scapy/

it appears that the phaethon source is a fork of the secdev source.
the phaethon module is now being renamed to scapy3k.

the secdev source (the original "upstream") appears to support python3
on its master branch (at least as of version v2.4.0rc4).

I think in debian in the future, python-scapy and python3-scapy should
both be derived from the secdev sources.

The phaethon sources should be shipped as python3-scapy3k.

Regards,

--dkg

-- 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.14.0-3-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 python3-scapy depends on:
ii  libjs-sphinxdoc  1.6.6-2
ii  python3  3.6.4-1
ii  python3.63.6.4-3
ii  tcpdump  4.9.2-2

python3-scapy recommends no packages.

Versions of packages python3-scapy suggests:
ii  ipython35.5.0-1
ii  python3-matplotlib  2.1.1-2

-- no debconf information

Bug#886517: More info

[Raphaël Halimi]

Hi,

I just stumbled upon this bug while installing munin-node on a Stretch
machine.

It seems due to the fact that the "time" package used to be Priority:
standard, whereas in Stretch it's now Priority: optional.

"time" is also a shell keyword in bash (but not in dash), and this one
doesn't understand the "-f" option. So, despite the fact that the plugin
uses /bin/bash in its shebang, it does indeed need the real "time"
binary from the "time" package.

The plugin could also be patched to throw an error at some point if the
"$time_bin" variable is empty, but it would be much easier (and useful)
to just add the dependency.

Regards,

-- 
Raphaël Halimi



signature.asc
Description: OpenPGP digital signature

Bug#889937: transition: libminiupnpc

[Thomas Goirand]

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

Dear release team,

libminiupnpc16 is now in Experimental. I tried rebuilding all reverse
dependencies, which are:

* 0ad
* bitcoin
* classified-ads
* dogecoin
* dolphin-emu
* eiskaltdcpp
* i2pd
* litecoin
* megaglest
* sushi
* swift-im
* transmission
* warzone2100

Out of this, eiskaltdcpp and bitcoin failed to build for apparently
unrelated issues, and for the 3rd one swift-im, I filed a bug:
https://bugs.debian.org/889062

2 reverse dependencies seemed to have libminiupnpc upgrade issues,
and I fied bugs against them:

sushi-1.4.0+git20160822+dfsg https://bugs.debian.org/889055
warzone2100 3.2.1-2: https://bugs.debian.org/889059

I do have proposed patches from upstream, which basically means
doing this:

#if defined(MINIUPNPC_API_VERSION) && (MINIUPNPC_API_VERSION >= 14)
  miniupnpc_dev = upnpDiscover(3000, NULL, NULL, 0, 0, 2, ); /* use 
default TTL of 2 */
#elif defined(MINIUPNPC_API_VERSION) && (MINIUPNPC_API_VERSION >= 8)
  miniupnpc_dev = upnpDiscover(3000, NULL, NULL, 0, 0, );
#elif defined(MINIUPNPC_API_VERSION) && (MINIUPNPC_API_VERSION >= 3)
  miniupnpc_dev = upnpDiscover(3000, NULL, NULL, 0);
#else
  miniupnpc_dev = upnpDiscover(3000, NULL, NULL);
#endif

which seems fairly easy to fix in both sushi and warzone2100, and both
of which has been documented in the bug reports by upstream.

Therefore, I think it's time to request for a transition slot. Please
let me know when I can upload miniupnpc to Sid.

Cheers,

Thomas Goirand (zigo)

Ben file:

title = "libminiupnpc";
is_affected = .depends ~ "libminiupnpc10" | .depends ~ "libminiupnpc16";
is_good = .depends ~ "libminiupnpc16";
is_bad = .depends ~ "libminiupnpc10";

Bug#795593: systemsettings: Also happens with Alt+F1 Activate Application Launcher, but it also implicitly maps the Win key

[Vivia Nikolaidou]

Package: systemsettings
Version: 4:5.10.5-2
Followup-For: Bug #795593

Dear Maintainer,

I have this with the Alt+F1 shortcut to Activate Application Launcher. However, 
what I actually care about is the Left Win button. For some reason, the Left 
Win button is also set to Activate Application Launcher even though 
systemsettings claims it's Alt+F1. I go to systemsettings, set Activate 
Application Launcher to None, then the Left Win key is also free for me to use 
as Compose. I have tried setting it to a couple of other values apart from 
Alt+F1 and they also seem to hijack my Left Win key without asking me.

-- 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.14.0-3-amd64 (SMP w/20 CPU cores)
Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.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 systemsettings depends on:
pn  kio   
ii  libc6 2.26-6
pn  libkf5auth5   
pn  libkf5completion5 
pn  libkf5configcore5 
pn  libkf5configgui5  
pn  libkf5configwidgets5  
ii  libkf5coreaddons5 5.37.0-3
pn  libkf5dbusaddons5 
pn  libkf5i18n5   
pn  libkf5iconthemes5 
pn  libkf5itemviews5  
pn  libkf5kcmutils5   
pn  libkf5khtml5  
pn  libkf5kiowidgets5 
pn  libkf5service-bin 
pn  libkf5service5
pn  libkf5widgetsaddons5  
pn  libkf5windowsystem5   
pn  libkf5xmlgui5 
ii  libqt5core5a  5.9.2+dfsg-7
ii  libqt5dbus5   5.9.2+dfsg-7
ii  libqt5gui55.9.2+dfsg-7
ii  libqt5widgets55.9.2+dfsg-7
ii  libstdc++67.3.0-1
pn  qml-module-org-kde-kirigami2  
pn  qml-module-qtquick-controls   
pn  qml-module-qtquick-layouts
pn  qml-module-qtquick2   

systemsettings recommends no packages.

systemsettings suggests no packages.

-- no debconf information

Bug#889640: lintian: init.d-script-possible-missing-stop should special-case runlevel S scripts

[Chris Lamb]

tags 820770 - moreinfo
tags 820770 + wontfix
tags 889640 + wontfix
forcemerge 820770 889640
thanks

Hi Ron,

> I chatted with Felipe on IRC, and lintian is still right :)  So feel free
> to close/merge this one now too.

Thanks for following up. Hopefully I've got the control@ incantation
right above...


Best wishes,

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

Bug#807044: Okular scales down A4 to A5 on printing

[Michael Weghorn]

On 2018-02-08 18:25, Marc Haber wrote:
> On Thu, Jan 18, 2018 at 03:26:35PM +0100, Michael Weghorn wrote:
>> Thanks, Marc, for retesting and the quick reply.
> 
> You're welcome. I apologize for adding more confusion to this, but I
> cannot reproduce this any more in current sid.
> 
> I guess it's fine to close the issue for okular 4:17.08.3-3 then.
> 

Thanks for the update. and nice to hear you're no longer having the
problem. I'm closing this then as you suggested.

Regards,
  Michael


PS: Interestingly, a very similar issue hast just recently been reported
upstream: https://bugs.kde.org/show_bug.cgi?id=389953

Bug#889935: RM: pnetcdf [armel armhf i386 mips mipsel powerpc] -- NBS; no longer built on 32bit architectures

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal


pnetcdf (1.9.0-2) unstable; urgency=medium

  * Only build on 64-bit archs. Needed as MPI_OFFSET must now be 8 bytes,
and the same size as size_t. Closes: #889115

 -- Alastair McKinstry   Thu, 08 Feb 2018 11:40:19 +

Bug#820770: Bug#889640: lintian: init.d-script-possible-missing-stop misfire on rcS scripts

[Ron]

On Tue, Feb 06, 2018 at 05:50:28PM +1030, Ron wrote:
> On Tue, Feb 06, 2018 at 03:32:55AM +0530, Chris Lamb wrote:
> > tags 820770 + moreinfo
> > thanks
> > 
> > 
> > Hi Ron and Felipe,
> > 
> > Hm, are #820770 and #889640 the same issue? If so, we should either
> > close them both or reopen both of them.
> 
> Yes, that was exactly my line of thinking when I first saw this warning,
> before discovering that in practice /etc/rc1.d/S01killprocs is going to
> stop it anyway before switching to rcS and restarting it again.  And
> that is exactly what the extended lintian warning was trying to explain
> (and probably successfully would have if the system I first saw it on
> had initscripts installed which provides that script).
> 
> These two should definitely be merged, but I'd welcome Felipe reviewing
> the conclusions I came to here https://bugs.debian.org/889640#15 just
> in case I did miss something we ought to do other than just close this
> now.

I chatted with Felipe on IRC, and lintian is still right :)  So feel free
to close/merge this one now too.

Thanks for the awesome job you've been doing working through the lintian
backlog in the BTS!


  Cheers,
  Ron

Bug#889934: salt-common needs Breaks on package versions without Python 3 support

[Adrian Bunk]

Package: salt-common
Version: 2017.7.2+dfsg1-1
Severity: serious
Control: block -1 by 889927 889928 889929 889932 889933

salt-common will need Breaks for at least the following packages:
- salt-formula-ceilometer
- salt-formula-cinder
- salt-formula-glance
- salt-formula-keystone
- salt-formula-kubernetes

Bug#889933: salt-formula-glance: FTBFS and Debci failure with salt 2017.7.2

[Adrian Bunk]

Source: salt-formula-glance
Version: 2016.12.1-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/s/salt-formula-glance/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/salt-formula-glance.html

...
   dh_auto_test
make -j15 test
make[1]: Entering directory '/build/1st/salt-formula-glance-2016.12.1'
[ ! -d tests ] || (cd tests; ./run_tests.sh)
/usr/bin/salt-call
[WARNING ] Failed to open log file, do you have permission to write to 
/var/log/salt/minion?
[ERROR   ] Rendering exception occurred: Jinja variable 'dict object' has no 
attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:glance.server' failed: Jinja variable 'dict 
object' has no attribute 'iteritems'
local:
- Rendering SLS 'base:glance.server' failed: Jinja variable 'dict object' 
has no attribute 'iteritems'
[ERROR] Execution of glance.cluster failed
[ERROR] Execution failed
Makefile:22: recipe for target 'test' failed
make[1]: *** [test] Error 1

Bug#889932: salt-formula-kubernetes: FTBFS and Debci failure with salt 2017.7.2

[Adrian Bunk]

Source: salt-formula-kubernetes
Version: 2016.12.1-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/s/salt-formula-kubernetes/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/salt-formula-kubernetes.html

...
   dh_auto_test
make -j15 test
make[1]: Entering directory '/build/1st/salt-formula-kubernetes-2016.12.1'
[ ! -d tests ] || (cd tests; ./run_tests.sh)
/usr/bin/salt-call
[ERROR   ] Rendering exception occurred: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:kubernetes.master.controller' failed: Jinja 
variable 'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[ERROR   ] Rendering exception occurred: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:kubernetes.master.setup' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
local:
- Rendering SLS 'base:kubernetes.master.controller' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
- Rendering SLS 'base:kubernetes.master.setup' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[ERROR] Execution of kubernetes.master_cluster failed
[ERROR] Execution failed
Makefile:22: recipe for target 'test' failed
make[1]: *** [test] Error 1

Bug#889931: python-cartopy FTBFS with proj 5.0.0

[Bas Couwenberg]

Source: python-cartopy
Version: 0.14.2+dfsg1-2
Severity: important
Tags: upstream
User: debian-...@lists.debian.org
Usertags: proj-5.0

Dear Maintainer,

Your package FTBFS due to missing compatibility with Proj 5.0.0:

 ==
 FAIL: cartopy.tests.crs.test_mercator.test_central_longitude
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
   File 
"/build/python-cartopy-0.14.2+dfsg1/.pybuild/pythonX.Y_2.7/build/cartopy/tests/crs/test_mercator.py",
 line 72, in test_central_longitude
 [-20037508, -15496570, 20037508, 18764656], decimal=0)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 563, in 
assert_almost_equal
 return assert_array_almost_equal(actual, desired, decimal, err_msg)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 962, in 
assert_array_almost_equal
 precision=decimal)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 778, in 
assert_array_compare
 raise AssertionError(msg)
 AssertionError: 
 Arrays are not almost equal to 0 decimals
 
 (mismatch 25.0%)
  x: array([-20037508., -15496571., -20037508.,  18764656.])
  y: array([-20037508, -15496570,  20037508,  18764656])
 
 ==
 FAIL: cartopy.tests.crs.test_robinson.test_transform_point
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
   File 
"/build/python-cartopy-0.14.2+dfsg1/.pybuild/pythonX.Y_2.7/build/cartopy/tests/crs/test_robinson.py",
 line 49, in test_transform_point
 assert_arr_almost_eq(result, (2376187.27182751, 7275317.81573085), _TOL)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 962, in 
assert_array_almost_equal
 precision=decimal)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 778, in 
assert_array_compare
 raise AssertionError(msg)
 AssertionError: 
 Arrays are not almost equal to 7 decimals
 
 (mismatch 100.0%)
  x: array([ 2376187.2757334,  7275317.7120387])
  y: array([ 2376187.2718275,  7275317.8157309])
 
 ==
 FAIL: cartopy.tests.crs.test_robinson.test_transform_points
 --
 Traceback (most recent call last):
   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
 self.test(*self.arg)
   File 
"/build/python-cartopy-0.14.2+dfsg1/.pybuild/pythonX.Y_2.7/build/cartopy/tests/crs/test_robinson.py",
 line 66, in test_transform_points
 [[2376187.27182751, 7275317.81573085, 0]], _TOL)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 962, in 
assert_array_almost_equal
 precision=decimal)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 778, in 
assert_array_compare
 raise AssertionError(msg)
 AssertionError: 
 Arrays are not almost equal to 7 decimals
 
 (mismatch 66.67%)
  x: array([[ 2376187.2757334,  7275317.7120387,0.   ]])
  y: array([[ 2376187.2718275,  7275317.8157309,0.   ]])
 
 ==
 FAIL: test_default (cartopy.tests.crs.test_transverse_mercator.TestOSNI)
 --
 Traceback (most recent call last):
   File 
"/build/python-cartopy-0.14.2+dfsg1/.pybuild/pythonX.Y_2.7/build/cartopy/tests/crs/test_transverse_mercator.py",
 line 104, in test_default
 386984.15347340))
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 962, in 
assert_array_almost_equal
 precision=decimal)
   File "/usr/lib/python2.7/dist-packages/numpy/testing/utils.py", line 778, in 
assert_array_compare
 raise AssertionError(msg)
 AssertionError: 
 Arrays are not almost equal to 6 decimals
 
 (mismatch 100.0%)
  x: array([ 275614.267627,  386984.20643 ])
  y: array([ 275614.871056,  386984.153473])
 
 --

The full build log is attached.

The severity of this issue will be increased to serious when the Proj
5.0 transition starts.

Kind Regards,

Bas
dpkg-checkbuilddeps: error: Unmet build dependencies: python-pyshp 
python-shapely (>= 1.5.6) python3-all-dev python3-nose python3-pyshp 
python3-shapely (>= 1.5.6)
W: Unmet build-dependency in source
dh clean --with python2,python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   debian/rules override_dh_auto_clean
make[1]: Entering directory '/home/bas/tmp/debian/python-cartopy-0.14.2+dfsg1'
dh_auto_clean || true
I: 

Bug#889929: salt-formula-keyston: FTBFS and Debci failure with salt 2017.7.2

[Adrian Bunk]

Source: salt-formula-keystone
Version: 2016.12.1-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/s/salt-formula-keystone/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/salt-formula-keystone.html

...
   dh_auto_test
make -j15 test
make[1]: Entering directory '/build/1st/salt-formula-keystone-2016.12.1'
[ ! -d tests ] || (cd tests; ./run_tests.sh)
/usr/bin/salt-call
[ERROR   ] Rendering exception occurred: Jinja variable 'dict object' has no 
attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:keystone.server' failed: Jinja variable 'dict 
object' has no attribute 'iteritems'
local:
- Rendering SLS 'base:keystone.server' failed: Jinja variable 'dict object' 
has no attribute 'iteritems'
[ERROR] Execution of keystone.cluster failed
[ERROR] Execution failed
Makefile:22: recipe for target 'test' failed
make[1]: *** [test] Error 1

Bug#889930: Plot viewer doesn't work properly

[Louis-Philippe Véronneau]

Package: octave
Severity: important

Hi!

Using octave 4.2.1-5, I can't make the plot viewer window work properly.

When generating a plot using the plot() function, the plot viewer window
pops-up, but nothing is shown inside the window.

Fortunately, the window buttons still work and I'm able to save the plot
as a PDF.

Once I save the plot, the plot shows up correctly, but the window
buttons like Pan, Z+ or Z- don't work.

If I overlay another program on top of the plot viewer, the plot
disappears once again.

Don't hesitate to ask for more info if you are not able to reproduce
this bug!

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#889928: salt-formula-cinder: FTBFS and Debci failure with salt 2017.7.2

[Adrian Bunk]

Source: salt-formula-cinder
Version: 2016.12.1-1
Severity: serious

https://ci.debian.net/packages/s/salt-formula-cinder/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/salt-formula-cinder.html

...
   dh_auto_test
make -j15 test
make[1]: Entering directory '/build/1st/salt-formula-cinder-2016.12.1'
[ ! -d tests ] || (cd tests; ./run_tests.sh)
/usr/bin/salt-call
[WARNING ] Failed to open log file, do you have permission to write to 
/var/log/salt/minion?
[ERROR   ] Rendering exception occurred: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:cinder.controller' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[ERROR   ] Rendering exception occurred: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:cinder.volume' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
local:
- Rendering SLS 'base:cinder.controller' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
- Rendering SLS 'base:cinder.volume' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[ERROR] Execution of cinder.ceph_single failed
[ERROR] Execution failed
Makefile:22: recipe for target 'test' failed
make[1]: *** [test] Error 1

Bug#889927: salt-formula-ceilometer: FTBFS and Debci failure with salt 2017.7.2

[Adrian Bunk]

Source: salt-formula-ceilometer
Version: 2016.12.1-1
Severity: serious
Tags: buster sid

https://ci.debian.net/packages/s/salt-formula-ceilometer/unstable/amd64/
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/salt-formula-ceilometer.html

...
   dh_auto_test
make -j15 test
make[1]: Entering directory '/build/1st/salt-formula-ceilometer-2016.12.1'
[ ! -d tests ] || (cd tests; ./run_tests.sh)
/usr/bin/salt-call
[ERROR   ] Rendering exception occurred: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[CRITICAL] Rendering SLS 'base:ceilometer.agent' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
local:
- Rendering SLS 'base:ceilometer.agent' failed: Jinja variable 
'salt.utils.odict.OrderedDict object' has no attribute 'iteritems'
[ERROR] Execution of ceilometer.agent_cluster failed
[ERROR] Execution failed
Makefile:22: recipe for target 'test' failed
make[1]: *** [test] Error 1

Bug#889924: [Aptitude-devel] Bug#889924: [aptitude] Feature request - For changelog download command, can acceptable Origins be configurable? Devuan

[OmegaPhil]

On 08/02/18 20:29, Axel Beckert wrote:
> Control: tag -1 + confirmed
> 
> Hi,
> 
> OmegaPhil wrote:
>> I use aptitude as a Devuan user, but with vanilla aptitude it is not
>> possible to download changelogs for packages due to the hardcoded origin
>> check in generic/apt/pkg_changelog.cc:check_valid_origin:
>>
>> https://sources.debian.org/src/aptitude/0.8.10-6/src/generic/apt/pkg_changelog.cc/#L691
>>
>> Please can the whitelist be user-configurable?
> 
> We should at least make this more flexible. Not sure, what's the best
> way.
> 
> There are though plans to further shrink the diff to Ubuntu by making
> more stuff vendor-dependent.
> 
> And currently Ubuntu patches exactly these lines of code (plus more
> related lines):
> https://patches.ubuntu.com/a/aptitude/aptitude_0.8.10-6ubuntu1.patch

Thanks for getting back so quickly - ah, that figures. I have an awful
hack locally
(https://git.devuan.org/devuan/devuan-project/uploads/15e61354c9588024eabc0a6fc4a3faaa/allow-devuan-repo-changelog-source-v2.patch
, now it has to fall back to the Label to check in the Devuan case).


>> For reference currently the recommended Devuan repo has no Origin
>> specified (it used to),
> 
> That's a really bad decision. Why have they done it? They don't gain
> anything from it except breaking their infrastructure and annoying
> their users.
> 
>> but talking on IRC it sounds like they will fix this if aptitude is
>> changed to allow non-Debian repos as a valid source.
> 
> Huh? That sounds a lot like extortion. If it was meant like that, they
> won't get any farther — neither here nor anywhere else.
> 
> Regards, Axel (running Debian Unstable with sysvinit or openrc)


Yes, they didn't think it was a notable issue. Devuan is also very busy
getting Ascii out the door, so its probably just down to being too busy.
Thank you for what you have said though - good evidence for me :)




signature.asc
Description: OpenPGP digital signature

Bug#889924: [Aptitude-devel] Bug#889924: [aptitude] Feature request - For changelog download command, can acceptable Origins be configurable? Devuan

[Irrwahn]

On Thu, 8 Feb 2018 21:29:01 +0100 Axel Beckert  wrote:
> Control: tag -1 + confirmed
> 
> Hi,
> 
> OmegaPhil wrote:
[...]
> > For reference currently the recommended Devuan repo has no Origin
> > specified (it used to),
> 
> That's a really bad decision. Why have they done it? They don't gain
> anything from it except breaking their infrastructure and annoying
> their users.
> 
> > but talking on IRC it sounds like they will fix this if aptitude is
> > changed to allow non-Debian repos as a valid source.

For the record, I believe that this is a slight misunderstanding or 
at the very least an exaggeration based solely on one hasty reply by 
a single developer.
 
> Huh? That sounds a lot like extortion. If it was meant like that, they
> won't get any farther — neither here nor anywhere else.

See above. Please, do not read too much into it!

Best regards
Irrwahn
-- 
Sapere aude!

Bug#840014: webcheckout: missing URL sanitization

[Jakub Wilk]

* Paul Wise , 2018-02-07, 16:59:

 $ webcheckout /path/to/badgit.html
 git clone ext::sh -c cowsay% pwned% >% /dev/tty


I consider this particular attack to be a bug in git and the git 
authors seem to agree with me because it is blocked in sid.


It's hard to tell whether they agree, because disabling git-remote-ext 
by default is not documented AFAICT. See bug #867699.


Users might need to re-enable git-remote-ext for their own purposes, so 
this needs to be fixed in webcheckout.


webcheckout is also susceptible to option injection, but I couldn't find 
a way to exploit it for anything nefarious.


--
Jakub Wilk

Bug#884173: SIGSEGV since 63.0.3239.84-1 w/ non-built-in extensions

[Michael Meskes]

I'm seeing the same issue with the latest sid version 64.0.3282.11 and by
accident found a way to create the problem repeatably. I had my chromium
started but not used at all when I upgraded my wlan router's firmware (from
Firefox). During reboot of said router chromium crashed and didn't start again
until I ran it once with disabled extensions. After that all was well, until I
reboot the router again, which brought the problem up again. I don't see any
extension on my system that needs the wlan, except of course for internet
access.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber: michael at xmpp dot meskes dot org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

Bug#889924: [Aptitude-devel] Bug#889924: [aptitude] Feature request - For changelog download command, can acceptable Origins be configurable? Devuan

[Axel Beckert]

Control: tag -1 + confirmed

Hi,

OmegaPhil wrote:
> I use aptitude as a Devuan user, but with vanilla aptitude it is not
> possible to download changelogs for packages due to the hardcoded origin
> check in generic/apt/pkg_changelog.cc:check_valid_origin:
> 
> https://sources.debian.org/src/aptitude/0.8.10-6/src/generic/apt/pkg_changelog.cc/#L691
> 
> Please can the whitelist be user-configurable?

We should at least make this more flexible. Not sure, what's the best
way.

There are though plans to further shrink the diff to Ubuntu by making
more stuff vendor-dependent.

And currently Ubuntu patches exactly these lines of code (plus more
related lines):
https://patches.ubuntu.com/a/aptitude/aptitude_0.8.10-6ubuntu1.patch

> For reference currently the recommended Devuan repo has no Origin
> specified (it used to),

That's a really bad decision. Why have they done it? They don't gain
anything from it except breaking their infrastructure and annoying
their users.

> but talking on IRC it sounds like they will fix this if aptitude is
> changed to allow non-Debian repos as a valid source.

Huh? That sounds a lot like extortion. If it was meant like that, they
won't get any farther — neither here nor anywhere else.

Regards, Axel (running Debian Unstable with sysvinit or openrc)
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#860089: [Pkg-kde-extras] Bug#860089: kmymoney: Warns about missing canberra-gtk-module

[Pino Toscano]

Hi,

sorry for the late reply.

In data martedì 11 aprile 2017 12:25:06 CET, Eliot Blennerhassett ha scritto:
> Package: kmymoney
> Version: 4.8.0-2+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> When starting an error message appears on the console.
> about missing canberra-gtk-module.

What is the exact message you get?  Without it, it is hard to determine
what is going on, and whether it is actually a problem or just a
note/warning about a functionality.

> Resolved by installing libcanberra-gtk-module.
> 
> Conclude that kmymoney or one of its dependencies should depend on this 
> module.
> 
> Note that the same error shows up from "firefox-esr" package.  Perhaps there 
> is
> a common lib...

kmymoney does not require canberra nor any of its modules, so I'm not
keen of adding a dependency when actually not needed.

Thanks,
-- 
Pino Toscano

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

Bug#889925: valac is unusable for cross-compilation

[Helmut Grohne]

Source: vala
Version: 0.38.7-1
User: helm...@debian.org
Usertags: rebootstrap

valac is presently unusable for cross-compilation. There are a number of
issues and unfortunately, this isn't going to be fixable easily.

The first issue you bump into is that executing valac gives an "Exec
format error". This is typical for build tools being installed from the
host architecture. As it happens, valac is implicitly marked Multi-Arch:
no, so it is installed for the build architecture. The simple fix for
this is to mark it Multi-Arch: foreign. Unfortunately, that is not
correct.

valac runs gcc and pkg-config. Both of these tools have
architecture-dependent behaviour and valac inherits that
architecture-dependence. Thus marking it Multi-Arch: foreign is wrong.
The typical solution to this problem is to encode the architecture into
the program name. On amd64, you can call gcc as x86_64-linux-gnu-gcc and
you can call x86_64-linux-gnu-pkg-config. However, these later
invocations also work for cross compilation. So what we need here is
adding the architecture to the valac command name.

In the simplest case, we could do:

ln -s valac .../usr/bin/${DEB_HOST_GNU_TYPE}-valac

Unfortunately, that won't fix any cross compilation issues. What we'd
want here is to have a valac executable for the build architecture
running the tools for another architecture. Thus I propose adding the
following shell script to the valac binary package:

#!/bin/sh
exec valac "--cc=${CC:-@DEB_HOST_GNU_TYPE@-gcc}" 
"--pkg-config=${PKG_CONFIG:-@DEB_HOST_GNU_TYPE@-pkg-config}" "$@"

You'd interpolate @DEB_HOST_GNU_TYPE@ at package build time and install
it as /usr/bin/${DEB_HOST_GNU_TYPE}-valac. It'd run valac with the
appropriate compiler and pkg-config for the prefix it was installed as.

Now that still doesn't fix the "Exec format error". So we'd also need a
new binary package (probably called "valac-bin"), move /usr/bin/valac to
that new package, add a dependency from valac to the new package and
mark the new package Multi-Arch: foreign. That's not fully correct as
valac is still architecture-dependent, but anyone wanting a particular
architecture's behaviour can and should simply run
${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
appears to work fairly well. Consumers need to add this prefix of course
and I sent a patch for AM_PROG_VALAC (#889920) already.

Implementation plan:
 * Create a new binary package valac-bin.
 * Move /usr/bin/valac to valac-bin (add Breaks/Replaces).
 * Add a valac-bin (= ${binary:Version}) to valac's Depends.
 * The description of valac-bin should say something like "don't install
   this package directly use valac instead". It should make clear that
   valac-bin is an implementation detail.
 * Mark valac-bin Multi-Arch: foreign.
 * Add the above script as /usr/bin/${DEB_HOST_GNU_TYPE}-valac to the
   valac binary package.

Do you agree with that approach? Can you help implement it?

Helmut

Bug#885868: liferea: feed items all have same font face instead of bold for unread items only

[Tomas Janousek]

Hi,

On Sat, Dec 30, 2017 at 06:42:37PM +0200, Sicelo A. Mhlongo wrote:
> With liferea 1.12, all the feed items have the same appearance, which makes it
> difficult to know which items are unread. The only workaround is to use
> Ctrl+N on the keyboard, which can be tedious if you have a lot of feeds.

Maybe this?
https://github.com/lwindolf/liferea/commit/cc07a549363a5c2adc90568d5d4be2a9c8e1b40b#diff-985984759b07971848c6109514b1288fR503

(In my setup, not only is it not bold, but fonts looked very ugly, and
"ultralight" seems like a viable explanation. I just downgraded back to the
version currently in stable and intended to give it another chance in a year,
but now that I think I have the culprit, maybe I'll get to it sooner.)

-- 
Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

Bug#867699: fatal: transport 'ext' not allowed

[Jakub Wilk]

* Ian Jackson , 2017-07-08, 18:30:
if this change was done for security reasons, why has it not been done 
in stretch ?


This change was introduced in this commit:
https://github.com/git/git/commit/f1762d772e9b415a3163abf5f217fc3b71a3b40e

The commit message doesn't mention any security implications. In fact, 
it doesn't even explicitly say that it changes the default behavior. :-/


I suspect it was meant to be hardening, rather than a security fix.

See #840014 for a bug that was mitigated thanks to this change.
Other security bugs that could be exploited via git-remote-ext:
https://github.com/sociomantic-tsunami/git-hub/issues/197
https://github.com/seveas/git-spindle/issues/154

--
Jakub Wilk

Bug#889924: [aptitude] Feature request - For changelog download command, can acceptable Origins be configurable? Devuan

[OmegaPhil]

Package: aptitude
Version: 0.8.7-1
Severity: wishlist

I use aptitude as a Devuan user, but with vanilla aptitude it is not
possible to download changelogs for packages due to the hardcoded origin
check in generic/apt/pkg_changelog.cc:check_valid_origin:

https://sources.debian.org/src/aptitude/0.8.10-6/src/generic/apt/pkg_changelog.cc/#L691

Please can the whitelist be user-configurable?

For reference currently the recommended Devuan repo has no Origin
specified (it used to), but talking on IRC it sounds like they will fix
this if aptitude is changed to allow non-Debian repos as a valid source.

If being user-configurable is too much, presumably just more hardcoding
to allow 'Devuan' variants of what is already present?

Thanks



signature.asc
Description: OpenPGP digital signature

Bug#889823: python-coverage: Add pypy-coverage

[Ben Finney]

Control: tags -1 + confirmed patch
Control: retitle -1 python-coverage: Build for PyPy interpreter

I will incorporate the changes and make a new release adding a PyPy
build.

-- 
 \  “[I]t is impossible for anyone to begin to learn that which he |
  `\thinks he already knows.” —Epictetus, _Discourses_ |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#888174: ruby-whitequark-parser: FTBFS on ruby2.5: Update test_current for 2.5.0

[Miguel Landaeta]

owner 888174 !
tags 888174 + confirmed pending
thanks

I'll upload 2.4.0.2 very soon with a fix for this.

-- 
Miguel Landaeta, nomadium at debian.org
secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key.
"Faith means not wanting to know what is true." -- Nietzsche


signature.asc
Description: PGP signature

Bug#889923: ITP: golang-github-go-errors-errors -- errors with stacktraces for go

[rajudev]

Package: wnpp
Severity: wishlist
Owner: Raju Devidas 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org


* Package name: golang-github-go-errors-errors
  Version : 1.0.0-1
  Upstream Author : Conrad Irwin 
* URL : https://github.com/go-errors/errors
* License : Expat
  Programming Lang: Go
  Description : errors with stacktraces for go

 Package errors adds stacktrace support to errors in go.
 .
 This is particularly useful when you want to understand the state of
 execution when an error was returned unexpectedly.
 .
 It provides the type *Error which implements the standard golang error
 interface, so you can use this library interchangeably with code that is
 expecting a normal error return.

Bug#889839: [Pkg-libvirt-maintainers] Bug#889839: libvirt: CVE-2018-6764

[Salvatore Bonaccorso]

Hi Guido

On Thu, Feb 08, 2018 at 07:28:17PM +0100, Guido Günther wrote:
> Hi Salvatore,
> On Wed, Feb 07, 2018 at 07:15:50PM +0100, Salvatore Bonaccorso wrote:
> > Source: libvirt
> > Version: 4.0.0-1
> > Severity: important
> > Tags: patch security upstream
> > 
> > Hi Guido,
> > 
> > the following vulnerability was published for libvirt.
> > 
> > CVE-2018-6764[0]:
> > |guest could inject executable code via libnss_dns.so loaded by
> > |libvirt_lxc before init
> > 
> > Commit is at [1]. I see the 1ce929603ba8ebc3b0dc4ff39df9619c87723f42
> > commit upstream introduced the inclusion of hostname in the initial
> > log message. But the hostname getting is already present before that
> > commit, can you pin point which is the arliest version including the
> > issue?
> 
> At least 1.3.1 onward are affected (but I think that's it). Given the
> little use of libvirt-lxc and the fact that you need apparmor/selinux
> for a safe container anyway fixing this via a point release will be

Alright, I marked it no-dsa. To be on 'safe side" I marked as well
no-dsa the jessie Version. I prefer until proven against that the
issue is not present in jessie, to have it marked "affected". We can
correct it if it turns out the hostname gettings there are really not
a problem.

Thanks a lot for your great work!

Salvatore

Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so

[Holger Levsen]

On Thu, Feb 08, 2018 at 03:04:22PM +0100, Petter Reinholdtsen wrote:
> [Clint Adams]
> > objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH

$ objdump -p /usr/lib/ghc/bin/ghc-pkg | grep RUNPATH
   RUNPATH
   
$ORIGIN/../terminfo-0.4.0.2:$ORIGIN/../ghc-boot-8.0.2:$ORIGIN/../ghc-boot-th-8.0.2:$ORIGIN/../Cabal-1.24.2.0:$ORIGIN/../process-1.4.3.0:$ORIGIN/../pretty-1.1.3.3:$ORIGIN/../directory-1.3.0.0:$ORIGIN/../unix-2.7.2.1:$ORIGIN/../time-1.6.0.1:$ORIGIN/../filepath-1.4.1.1:$ORIGIN/../binary-0.8.3.0:$ORIGIN/../containers-0.5.7.1:$ORIGIN/../bytestring-0.10.8.1:$ORIGIN/../deepseq-1.4.2.0:$ORIGIN/../array-0.5.1.1:$ORIGIN/../base-4.9.1.0:$ORIGIN/../integer-gmp-1.0.0.1:$ORIGIN/../ghc-prim-0.5.0.0:$ORIGIN/../rts

is what I get. Do you need any more info? I still see this...


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#889922: libgeo-proj4-perl: FTBFS with proj 5.0.0

[Bas Couwenberg]

Source: libgeo-proj4-perl
Version: 1.09-1
Severity: important
Tags: upstream
User: debian-...@lists.debian.org
Usertags: proj-5.0
Control: forwarded -1 https://github.com/markov2/perl5-Geo-Proj4/issues/1

Dear Maintainer,

Your package FTBFS due to missing compatibility with Proj 5.0.0:

 x86_64-linux-gnu-gcc -c  -I./include -I. -D_REENTRANT -D_GNU_SOURCE -DDEBIAN 
-fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fwrapv 
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -g -O2 
-fdebug-prefix-map=/build/libgeo-proj4-perl-1.09=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2   
-DVERSION=\"1.09\" -DXS_VERSION=\"1.09\" -fPIC 
"-I/usr/lib/x86_64-linux-gnu/perl/5.26/CORE"   Proj4.c
 In file included from Proj4.xs:7:0:
 /usr/include/projects.h:161:40: error: conflicting types for 'UV'
  typedef struct { double u, v; }UV;
 ^~
 In file included from Proj4.xs:2:0:
 /usr/lib/x86_64-linux-gnu/perl/5.26/CORE/perl.h:1655:16: note: previous 
declaration of 'UV' was here
  typedef UVTYPE UV;
 ^~

The full build log is attached.

The severity of this issue will be increased to serious when the Proj
5.0 transition starts.

Kind Regards,

Bas
dpkg-source: info: applying 00-conf_ccflags.patch
dh clean --parallel
   dh_testdir -O--parallel
   dh_auto_clean -O--parallel
   dh_clean -O--parallel
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building libgeo-proj4-perl using existing 
./libgeo-proj4-perl_1.09.orig.tar.gz
dpkg-source: info: building libgeo-proj4-perl in 
libgeo-proj4-perl_1.09-2.debian.tar.xz
dpkg-source: info: building libgeo-proj4-perl in libgeo-proj4-perl_1.09-2.dsc
I: Generated dsc will be overwritten by build result; not generating 
changes file
dpkg-source: info: unapplying 00-conf_ccflags.patch
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.22679
I: forking: cp -al /var/cache/pbuilder/base-sid+rebuild.cow 
/var/cache/pbuilder/build/cow.22679
I: removed stale ilistfile /var/cache/pbuilder/build/cow.22679/.ilist
I: forking: chroot /var/cache/pbuilder/build/cow.22679 
cowdancer-ilistcreate /.ilist 'find . -xdev -path ./home -prune -o \( \( -type 
l -o -type f \) -a -links +1 -print0 \) | xargs -0 stat --format '%d %i ''
I: Invoking pbuilder
I: forking: pbuilder build --debbuildopts  --debbuildopts  --buildplace 
/var/cache/pbuilder/build/cow.22679 --buildresult /home/bas/git/pkg-grass 
--no-targz --internal-chrootexec 'chroot /var/cache/pbuilder/build/cow.22679 
cow-shell' /home/bas/git/pkg-grass/libgeo-proj4-perl_1.09-2.dsc
I: Running in no-targz mode
I: using fakeroot in build.
I: pbuilder: network access will be disabled during build
I: Current time: Thu Feb  8 20:35:22 CET 2018
I: pbuilder-time-stamp: 1518118522
I: copying local configuration
I: mounting /proc filesystem
I: mounting /sys filesystem
I: creating /{dev,run}/shm
I: mounting /dev/pts filesystem
I: redirecting /dev/ptmx to /dev/pts/ptmx
I: policy-rc.d already exists
I: Obtaining the cached apt archive contents
I: Copying source file
I: copying [/home/bas/git/pkg-grass/libgeo-proj4-perl_1.09-2.dsc]
I: copying [/home/bas/git/pkg-grass/libgeo-proj4-perl_1.09.orig.tar.gz]
I: copying 
[/home/bas/git/pkg-grass/libgeo-proj4-perl_1.09-2.debian.tar.xz]
I: Extracting source
dpkg-source: warning: extracting unsigned source package 
(libgeo-proj4-perl_1.09-2.dsc)
dpkg-source: info: extracting libgeo-proj4-perl in libgeo-proj4-perl-1.09
dpkg-source: info: unpacking libgeo-proj4-perl_1.09.orig.tar.gz
dpkg-source: info: unpacking libgeo-proj4-perl_1.09-2.debian.tar.xz
dpkg-source: info: applying 00-conf_ccflags.patch
I: Installing the build-deps
 -> Attempting to satisfy build-dependencies
 -> Creating pbuilder-satisfydepends-dummy package
Package: pbuilder-satisfydepends-dummy
Version: 0.invalid.0
Architecture: amd64
Maintainer: Debian Pbuilder Team 
Description: Dummy package to satisfy dependencies with aptitude - created by 
pbuilder
 This package was created automatically by pbuilder to satisfy the
 build-dependencies of the package being currently built.
Depends: debhelper (>= 9), perl, proj-bin, libproj-dev
dpkg-deb: building package 'pbuilder-satisfydepends-dummy' in 
'/tmp/satisfydepends-aptitude/pbuilder-satisfydepends-dummy.deb'.
Selecting previously unselected package pbuilder-satisfydepends-dummy.
(Reading database ... 14302 files and directories currently installed.)
Preparing to unpack .../pbuilder-satisfydepends-dummy.deb ...
Unpacking pbuilder-satisfydepends-dummy (0.invalid.0) ...
dpkg: 

Bug#889921: increasing libassuan build-depends

[Daniel Baumann]

Package: gnupg2
Version: 2.2.4-2
Severity: wishlist

Hi,

thanks for maintaining gnupg in debian.

when doing a local backport to stretch, i found that (when building
arch-indep only), libassuan-mingw-w64-dev stays at the stretch version
rather than >= 2.5.0 because only the build-depends on libassuan-dev is
versioned, the build-depends-indep on libassuan-mingw-w64-dev is
unversioned.

it would be nice if you could change it to:

  libassuan-mingw-w64-dev (>= 2.5.0)

to ease backporting to stretch.

Regards,
Daniel

Bug#886150: [Pkg-dpdk-devel] Bug#886150: Please enable OpenSSL crypto driver

[Dmitry Eremin-Solenikov]

Hello,

2018-02-08 18:38 GMT+03:00 Luca Boccassi :
> Thank you very much for providing test commands and checking the 1.0
> support.
>
> We'll be uploading DPDK 18.02 to Debian experimental shortly after it
> will release in a few days, and it will have the OpenSSL PMD enabled
> there, so that it can be tested for a while.
>
> Then, after Ubuntu 18.04 freezes and stops importing from unstable (too
> late to add such new features now), we can enable it in sid and testing
> as well.
>
> Hope this sounds like a good plan for you.

Yes, this sounds good enough. In the mean time I will be able to test our
software against DPDK from experimental.

-- 
With best wishes
Dmitry

Bug#889732: libconfig-model-dpkg-perl: Does not recognize Salsa platform in Vcs field

[Dominique Dumont]

Hello team

On Tue, 06 Feb 2018 21:57:19 +0800 Boyuan Yang <073p...@gmail.com> wrote:
> When the check encounters Vcs-* fields with salsa.debian.org,
> it will (wrongly) report warnings, like:
> 
> Warning in 'control source Vcs-Browser' value
> 'https://salsa.debian.org/blahblah-team/blah.git': URL is not the canonical 
> one for repositories hosted on Alioth.

I wonder what is the best solution here. 

cme issues a warning is the vcs browser URL does not point to 
anonscm.debian.org. This host currently redirects to alioth. IIRC, it will  
point to salsa once the transition is done.

What can we do in the meantime with cme ?

- accepts both salsa and anonscm ? (this is a change that would need to be 
reverted once alioth to salsa transition is done)
- remove the check until the transition is done, so no warning is emitted
- do nothing (may be update the doc)

Thoughts ?

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Bug#888577: Solution

[Thomas Koch]

Your problem is mentioned in the FAQ:
http://linrunner.de/en/tlp/docs/tlp-faq.html#btusb

Bug#889905: [Pkg-xfce-devel] Bug#889905: xfce4-notifyd: privacy-invasive logging of notification content

[Yves-Alexis Perez]

On Thu, 2018-02-08 at 17:05 +0100, Sergio Gelato wrote:
> xfce4-notifyd has bugs (known upstream) in its handling of markup, more
> specifically of unintentional markup   This bug report
> is about the way it logs occurrences of such (non-)markup.

Hi, thanks for the bug report. Can you provide the upstream bug report on
this? I can't reproduce with:

notify-send ' ' on xfce4-notifyd 0.4.1-1 so maybe it's been
fixed meanwhile.
> 
> Here is a (redacted) example of an entry I've seen in my logs due to user
> activity. I don't want, and my users almost certainly don't want me, to see
> this much detail: it's privacy-invasive. I'll filter out these messages
> but feel that they shouldn't be sent to syslog in the first place. Not in so
> much detail, and not for every notification that happens to contain an
> ampersand or a < bracket.

First, it's definitely not xfce4-notifyd sending this to syslog. More likely
it's just output to stdout/stderr and systemd forwards it to journal and the
syslog.
-- 
Yves-Alexis

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

Bug#889920: AM_PROG_VALAC should consider $ac_tool_prefix

[Helmut Grohne]

Package: automake-1.15
Version: 1:1.15.1-3
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

I tried using valac during cross compilation and figured that one
presently gets an "Exec format error", because it is implicitly marked
Multi-Arch: no. So I considered whether it can be marked Multi-Arch:
foreign and I conclude "no", because valac uses gcc and pkg-config and
exposes their architecture-dependent behaviour. Thus we must consider
valac to be a "tool". That means considering $ac_tool_prefix.
AM_PROG_VALAC currently uses AC_PATH_PROG, so it does not consider
$ac_tool_prefix. I think this is a bug and it really should be using
AC_PATH_TOOL here. Please consider applying the attached patch.

Helmut
Index: automake-1.15-1.15.1/m4/vala.m4
===
--- automake-1.15-1.15.1.orig/m4/vala.m4
+++ automake-1.15-1.15.1/m4/vala.m4
@@ -19,7 +19,7 @@
 # AM_PROG_VALAC([MINIMUM-VERSION], [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
 # --
 AC_DEFUN([AM_PROG_VALAC],
-  [AC_PATH_PROG([VALAC], [valac], [valac])
+  [AC_PATH_TOOL([VALAC], [valac], [valac])
AS_IF([test "$VALAC" != valac && test -n "$1"],
   [AC_MSG_CHECKING([whether $VALAC is at least version $1])
am__vala_version=`$VALAC --version | sed 's/Vala  *//'`

Bug#889850: gpodder fails to launch -- ModuleNotFoundError: No module named 'cairo'

[Thomas Perl]

Hi,

Did you try installing "python3-cairo”? If that fixes the problem, the 
dependencies need to be updated in the package.

Thanks,
Thomas

> On 07.02.2018, at 22:24, Dimitri Chausson  wrote:
> 
> Package: gpodder
> Version: 3.10.0-3
> Severity: normal
> 
> Dear Maintainer,
> 
> After a usual package update routine, I cannot launch gpodder anymore. A call
> from the command line gives the following output:
> 
> 1518037775.639697 [gpodder.log] ERROR: Uncaught exception: Traceback (most 
> recent call last):
>  File "/usr/bin/gpodder", line 158, in 
>main()
>  File "/usr/bin/gpodder", line 151, in main
>from gpodder.gtkui import main
>  File "/usr/lib/python3/dist-packages/gpodder/gtkui/main.py", line 68, in 
> 
>from gpodder.gtkui.model import Model
>  File "/usr/lib/python3/dist-packages/gpodder/gtkui/model.py", line 38, in 
> 
>from gpodder.gtkui import draw
>  File "/usr/lib/python3/dist-packages/gpodder/gtkui/draw.py", line 37, in 
> 
>import cairo
> ModuleNotFoundError: No module named 'cairo'
> 
> Traceback (most recent call last):
>  File "/usr/bin/gpodder", line 158, in 
>main()
>  File "/usr/bin/gpodder", line 151, in main
>from gpodder.gtkui import main
>  File "/usr/lib/python3/dist-packages/gpodder/gtkui/main.py", line 68, in 
> 
>from gpodder.gtkui.model import Model
>  File "/usr/lib/python3/dist-packages/gpodder/gtkui/model.py", line 38, in 
> 
>from gpodder.gtkui import draw
>  File "/usr/lib/python3/dist-packages/gpodder/gtkui/draw.py", line 37, in 
> 
>import cairo
> ModuleNotFoundError: No module named 'cairo'
> 
> 
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers testing
>  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages gpodder depends on:
> ii  python33.6.4-1
> ii  python3-dbus   1.2.6-1
> ii  python3-gi 3.26.1-2
> ii  python3-mygpoclient1.8-1
> ii  python3-podcastparser  0.6.2-1
> 
> Versions of packages gpodder recommends:
> ii  dbus-user-session [default-dbus-session-bus]  1.12.2-1
> ii  dbus-x11 [dbus-session-bus]   1.12.2-1
> pn  python3-appindicator  
> ii  python3-eyed3 0.8.4-2
> ii  python3-html5lib  0.9-1
> ii  python3-simplejson3.13.2-1
> 
> Versions of packages gpodder suggests:
> pn  gnome-bluetooth | bluez-gnome  
> ii  mplayer4:1.3.0~20171022.svn37997-dmo6
> 
> -- no debconf information

Bug#846302: live-wrapper: use existing vmdebootstrap output

[Fernando Toledo]

On Wed, 30 Nov 2016 00:16:40 + "Iain R. Learmonth" 
wrote:
> Package: live-wrapper
> Severity: wishlist
> 
> Hi,
> 
> Especially during development, it would be really cool if we didn't have to
> wait for vmdebootstrap every build. Let's add an option to use an existing
> built vmdebootstrap output (and to make sure we don't "clean it up"
> afterwards).
> 
> Thanks,
> Iain.
> 
> 
+1

Yes, i think that this option will be very useful too!!
vmboostrap take around 5 / 10 minutes on every build =(

-- 
Fernando Toledo
Dock Sud BBS
http://bbs.docksud.com.ar
telnet://bbs.docksud.com.ar

Bug#889919: ksystemlog: SIGSEGV in QAction::setEnabled

[Nathaniel Morck Beaver]

Package: ksystemlog
Version: 4:16.08.3-1
Severity: normal
Tags: upstream

Dear Maintainer,

Steps to reproduce:

1. Run ksystemlog

2. Click "Kernel log"

3. Ctrl-T to open a new tab.

4. Click X to close window.

5. Get a "Segmentation fault" message and/or core dump.

Reported for version 16.08.3, but also reproducible in Debian sid (17.08.3).

Full backtrace attached. Core dumps available upon request, though they 
are 53M-57M in size.


Sincerely,

Nathaniel Beaver

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 
'stable')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to en_US.UTF-8)

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

Versions of packages ksystemlog depends on:
ii  kio   5.28.0-2
ii  libc6 2.24-11+deb9u1
ii  libkf5archive55.28.0-2
ii  libkf5completion5 5.28.0-1
ii  libkf5configcore5 5.28.0-2
ii  libkf5configgui5  5.28.0-2
ii  libkf5configwidgets5  5.28.0-2
ii  libkf5coreaddons5 5.28.0-2
ii  libkf5i18n5   5.28.0-2
ii  libkf5iconthemes5 5.28.0-2
ii  libkf5itemviews5  5.28.0-1
ii  libkf5kiocore55.28.0-2
ii  libkf5kiowidgets5 5.28.0-2
ii  libkf5service-bin 5.28.0-1
ii  libkf5service55.28.0-1
ii  libkf5textwidgets55.28.0-1
ii  libkf5widgetsaddons5  5.28.0-3
ii  libkf5xmlgui5 5.28.0-1
ii  libqt5core5a  5.7.1+dfsg-3+b1
ii  libqt5gui55.7.1+dfsg-3+b1
ii  libqt5printsupport5   5.7.1+dfsg-3+b1
ii  libqt5widgets55.7.1+dfsg-3+b1
ii  libstdc++66.3.0-18

ksystemlog recommends no packages.

ksystemlog suggests no packages.

-- no debconf information
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/bin/ksystemlog...Reading symbols from 
/usr/lib/debug/.build-id/85/1d723e61f2e0df70add30b9c69b17497a1514e.debug...done.
done.
[New LWP 8620]
[New LWP 8621]
[New LWP 8622]
[New LWP 8624]
[New LWP 8623]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `ksystemlog'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  QAction::setEnabled (this=0x5621eb95d230, b=b@entry=false) at 
kernel/qaction.cpp:1029
1029kernel/qaction.cpp: No such file or directory.
[Current thread is 1 (Thread 0x7fc8e9fa7d40 (LWP 8620))]
No locals.
this = 0x5621eb95d230
b = false
  Id   Target Id Frame 
* 1Thread 0x7fc8e9fa7d40 (LWP 8620) QAction::setEnabled 
(this=0x5621eb95d230, b=b@entry=false) at kernel/qaction.cpp:1029
  2Thread 0x7fc8e779e700 (LWP 8621) 0x7fc8f412e6ad in poll () at 
../sysdeps/unix/syscall-template.S:84
  3Thread 0x7fc8ddb53700 (LWP 8622) 0x7fc8f412e6ad in poll () at 
../sysdeps/unix/syscall-template.S:84
  4Thread 0x7fc8d79c0700 (LWP 8624) 0x7fc8f412e6ad in poll () at 
../sysdeps/unix/syscall-template.S:84
  5Thread 0x7fc8dd352700 (LWP 8623) 0x7fc8f412e6ad in poll () at 
../sysdeps/unix/syscall-template.S:84

Thread 5 (Thread 0x7fc8dd352700 (LWP 8623)):
#0  0x7fc8f412e6ad in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fc8efc7e9f6 in g_main_context_poll (priority=, 
n_fds=2, fds=0x7fc8d00010c0, timeout=, context=0x5621eb144bb0) 
at ././glib/gmain.c:4228
poll_func = 0x7fc8efc8e840 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7fc8d00010c0
#2  0x7fc8efc7e9f6 in g_main_context_iterate (context=0x5621eb144bb0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
././glib/gmain.c:3924
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x7fc8d00010c0
#3  0x7fc8efc7ed82 in g_main_loop_run (loop=0x5621eb144b40) at 
././glib/gmain.c:4125
__func__ = "g_main_loop_run"
#4  0x7fc8dfa3f656 in gdbus_shared_thread_func (user_data=0x5621eb144b80) 
at ././gio/gdbusprivate.c:247
data = 0x5621eb144b80
#5  0x7fc8efca63d5 in g_thread_proxy 

Bug#887828: needrestart: Possible false positive on postifx and wazuh-agent running in LXC container

[Chris]

Hi,

and thanks again for your reply.

On 08.02.2018 16:09, Thomas Liske wrote:
>> [main] #338 uses non-existing /var/ossec/bin/ossec-agentd
>> [main] #338 is not a child
> 
> this is by design of the wazuh-agent and might trigger a false positive
> in needrestart - putting binaries into /var looks something special.

Ah, thats a good and valid point. I think if this is no best practice of
wazuh-agent then i can live with that and handle this special case in my
local needrestart config.

>> [main] #25460 uses non-existing /usr/lib/postfix/sbin/pickup
>> [main] #25460 is a child of #430
> 
> Is your postfix chrooted?

Yes, it seems most processes of postfix are chrooted by default in
Debian Stretch (plain install of Postfix via apt-get install postfix):

/usr/share/postfix/master.cf.dist used/installed by
/var/lib/dpkg/info/postfix/postfix.postinst is e.g. chrooting the
mentioned process:

pickupunix  n   -   y   60  1   pickup

> Could you please post:
> stat /usr/lib/postfix/sbin/pickup

Sure:

  File: /usr/lib/postfix/sbin/pickup
  Size: 14408   Blocks: 32 IO Block: 4096   regular file
Device: 715h/1813d  Inode: 142070  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2018-02-08 01:06:13.281395346 +
Modify: 2017-09-27 04:56:28.0 +
Change: 2018-01-26 14:10:42.474783916 +
 Birth: -

> stat /proc/25460/root/usr/lib/postfix/sbin/pickup

the PIDs have changed here and are now:

[main] #4262 uses non-existing /usr/lib/postfix/sbin/pickup
[main] #4262 is a child of #478

stat: cannot stat '/proc/4262/root/usr/lib/postfix/sbin/pickup': No such
file or directory

and it seems the pickup is at:

  File: /proc/478/root/usr/lib/postfix/sbin/pickup
  Size: 14408   Blocks: 32 IO Block: 4096   regular file
Device: 715h/1813d  Inode: 142070  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2018-02-08 01:06:13.281395346 +
Modify: 2017-09-27 04:56:28.0 +
Change: 2018-01-26 14:10:42.474783916 +
 Birth: -

I've also had a look at the previously mentioned dovecot which seems to
be chrooted as well:

"Login processes (imap-login, pop3-login) are chrooted by default into
an empty non-writable directory."

-> https://wiki.dovecot.org/Chrooting

and indeed the same happening here:

[main] #24776 uses non-existing /usr/lib/dovecot/imap-login
[main] #24776 is a child of #13446

  File: /usr/lib/dovecot/imap-login
  Size: 31336   Blocks: 64 IO Block: 4096   regular file
Device: 70ah/1802d  Inode: 920400  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2018-02-08 13:49:54.190058675 +0100
Modify: 2017-06-30 21:01:28.0 +0200
Change: 2017-08-22 14:24:29.284898620 +0200
 Birth: -


stat: cannot stat '/proc/24776/root/usr/lib/dovecot/imap-login': No such
file or directory


  File: /proc/13446/root/usr/lib/dovecot/imap-login
  Size: 31336   Blocks: 64 IO Block: 4096   regular file
Device: 70ah/1802d  Inode: 920400  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2018-02-08 13:49:54.190058675 +0100
Modify: 2017-06-30 21:01:28.0 +0200
Change: 2017-08-22 14:24:29.284898620 +0200
 Birth: -

> Regards,
> Thomas

Thanks

>> [main] #338 exe => /var/ossec/bin/ossec-agentd
>> [main] #338 is wazuh-agent.service
>> [main] #430 exe => /usr/lib/postfix/sbin/master
>> [main] #430 is postfix@-.service
>>
>>
>> cat /proc/338/cgroup
>> -
>>
>> 12:cpuset:/
>> 11:hugetlb:/
>> 10:perf_event:/
>> 9:blkio:/
>> 8:net_cls,net_prio:/
>> 7:memory:/
>> 6:rdma:/
>> 5:cpu,cpuacct:/
>> 4:freezer:/
>> 3:pids:/system.slice/wazuh-agent.service
>> 2:devices:/system.slice/wazuh-agent.service
>> 1:name=systemd:/system.slice/wazuh-agent.service
>>
>>
>> cat /proc/25460/cgroup
>> --
>>
>> 12:cpuset:/
>> 11:hugetlb:/
>> 10:perf_event:/
>> 9:blkio:/
>> 8:net_cls,net_prio:/
>> 7:memory:/
>> 6:rdma:/
>> 5:cpu,cpuacct:/
>> 4:freezer:/
>> 3:pids:/system.slice/system-postfix.slice/postfix@-.service
>> 2:devices:/system.slice/system-postfix.slice
>> 1:name=systemd:/system.slice/system-postfix.slice/postfix@-.service
>>
>> cat /proc/430/cgroup
>> 
>>
>> 12:cpuset:/
>> 11:hugetlb:/
>> 10:perf_event:/
>> 9:blkio:/
>> 8:net_cls,net_prio:/
>> 7:memory:/
>> 6:rdma:/
>> 5:cpu,cpuacct:/
>> 4:freezer:/
>> 3:pids:/system.slice/system-postfix.slice/postfix@-.service
>> 2:devices:/system.slice/system-postfix.slice
>> 1:name=systemd:/system.slice/system-postfix.slice/postfix@-.service
>>
>>
>> As you have mentioned cgroups i'm also getting the following output from
>> the postfix services within the containers:
>>
>> Jan 28 15:51:51 example systemd[1]: postfix.service: Failed to reset
>> devices.list: Operation not permitted
>> Jan 28 15:51:51 example systemd[1]: postfix.service: Failed to set
>> invocation 

Bug#889918: firefox-esr: Please package documentation

[W. Martin Borgert]

Package: firefox-esr
Version: 52.6.0esr-1~deb9u1
Severity: wishlist

Dear Maintainers,

please package the documentation to Firefox, i.e. the HTML pages that
are or are not displayed, when clicking on Help -> Firefox Help, etc.
When clicking on Help, the locally installed documentation should be
shown.

There are several situations, when one might need this documentation.
E.g. when using Firefox
 - in a restricted Intranet
 - with a slow and/or expensive connection
 - while support.mozilla.org is down
 - when you don't want to expose your IP address to
   support.mozilla.org, but cannot use Tor

It seems, that the documentation pages are CC BY-SA 3.0, which is OK
for Debian.

Bug#889839: [Pkg-libvirt-maintainers] Bug#889839: libvirt: CVE-2018-6764

[Guido Günther]

Hi Salvatore,
On Wed, Feb 07, 2018 at 07:15:50PM +0100, Salvatore Bonaccorso wrote:
> Source: libvirt
> Version: 4.0.0-1
> Severity: important
> Tags: patch security upstream
> 
> Hi Guido,
> 
> the following vulnerability was published for libvirt.
> 
> CVE-2018-6764[0]:
> |guest could inject executable code via libnss_dns.so loaded by
> |libvirt_lxc before init
> 
> Commit is at [1]. I see the 1ce929603ba8ebc3b0dc4ff39df9619c87723f42
> commit upstream introduced the inclusion of hostname in the initial
> log message. But the hostname getting is already present before that
> commit, can you pin point which is the arliest version including the
> issue?

At least 1.3.1 onward are affected (but I think that's it). Given the
little use of libvirt-lxc and the fact that you need apparmor/selinux
for a safe container anyway fixing this via a point release will be
enough.
Cheers,
 -- Guido

Bug#889917: moreutils: ifdata -list should display a list of all interfaces

[Daniel Kahn Gillmor]

Package: moreutils
Version: 0.60-1
Severity: wishlist

currently, ifdata works if you know what interface you're interested
in.  it ought to also be able to give you a list of available
interfaces.  My proposed interface would be "ifdata -list".

 --dkg

-- 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.14.0-3-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 moreutils depends on:
ii  libc62.26-4
ii  libipc-run-perl  0.96-1
ii  perl 5.26.1-4

moreutils recommends no packages.

Versions of packages moreutils suggests:
ii  libtime-duration-perl  1.20-1
ii  libtimedate-perl   2.3000-2

-- no debconf information

Bug#889912: Please do not force chrome-gnome-shell / browser integration

[Jeremy Bicha]

Let me propose that we no longer depend on chrome-gnome-shell at all
from either 'gnome' or 'gnome-core'.

That leaves gnome-shell's Recommends on chrome-gnome-shell. We could
demote it to a Suggests, but as long as GNOME supports the
https://extensions.gnome.org/ service, it is a courtesy to our users
to have that service work out of the box.

Enrico, by the way, Simon McVittie points out that you are welcome to
uninstall 'gnome-core' and just install gnome-session directly if you
want a more minimal GNOME install than the one the Debian GNOME team
recommends for most users.

Thanks,
Jeremy Bicha

Bug#889916: simple-cdd-profiles postinst never prompts for which profiles to install

[Sam Overton]

Package: simple-cdd
Version: 0.6.5
Severity: normal

Dear Maintainer,

I am including multiple profiles in my image, but during installation I am
never prompted for which profile(s) to install, and instead only the
default profile is used.

The install log contains the following:

Feb  6 18:35:32 anna-install: Installing simple-cdd-profiles
Feb  6 18:35:32 apt-install: Queueing package less for later installation
Feb  6 18:35:32 anna[2826]: (process:5107): loading simple-cdd templates...
Feb  6 18:35:32 anna[2826]: (process:5107): asking simple-cdd debconf 
questions...
Feb  6 18:35:32 anna[2826]: (process:5107): loading simple-cdd preseeding files
Feb  6 18:35:32 anna[2826]: (process:5107): profiles:
Feb  6 18:35:32 anna[2826]: (process:5107): Finished with simple-cdd debconf 
preseeding
Feb  6 18:35:32 anna[2826]: (process:5107): Queuing simple-cdd udebs...
Feb  6 18:35:32 anna[2826]: (process:5107):
Feb  6 18:35:32 anna[2826]: (process:5107): Queuing udebs for profile: default
Feb  6 18:35:32 anna[2826]: (process:5107): Finished queueing simple-cdd udebs
Feb  6 18:35:32 anna[2826]: (process:5107): Queuing simple-cdd packages...
Feb  6 18:35:32 anna[2826]: (process:5107):
Feb  6 18:35:32 anna[2826]: (process:5107): Queuing packages for profile: 
default
Feb  6 18:35:32 anna[2826]: (process:5107): Finished queueing simple-cdd 
packages

So, it looks like the simple-cdd-profiles postinst script is running, but
it never prompts for profiles to install.

I am building with the following command:

build-simple-cdd --conf simple-cdd.conf --locale en_GB --keyboard gb

where simple-cdd.conf contains the following:

profiles="gw build"
mirror_components="main non-free"
local_packages="./local-packages/"
export ARCH=amd64
export KERNEL_PARAMS="preseed/file=/cdrom/simple-cdd/default.preseed 
priority=critical"

my ./profiles/ directory contains the following:

$ ls profiles/
build.packages  build.postinst  build.preseed  gw.packages gw.postinst  
gw.preseed

The built ISO contains the following files in /simple-cdd/

/media/cdrom$ ls ./simple-cdd/
build.packages  build.preseed  default.excludes  default.preseed 
gw.packages  gw.preseed
build.postinst  default.downloads  default.packages  default.udebs 
gw.postinst  simple-cdd.templates

And simple-cdd.templates contains the default content:

Template: simple-cdd/profiles
Type: multiselect
Choices: gw, build
Default:
Description: Select profiles
 profiles are a simple description of common system types.
 select all that apply.

The only way that I can get simple-cdd to build an ISO which installs my
profiles is to set auto_profiles="gw build" in the simple-cdd.conf, or to
pass simple-cdd/profiles="gw build" as a kernel start parameter. This does
not achieve the desired behavior as I wish to be able to select the
profiles at install time, not have them hard-coded.


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

Kernel: Linux 4.9.0-5-amd64 (SMP w/6 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 simple-cdd depends on:
ii  dctrl-tools 2.24-2+b1
ii  debian-cd   3.1.20
ii  lsb-release 9.20161125
ii  python3 3.5.3-1
ii  python3-simple-cdd  0.6.5
ii  reprepro5.1.1-1
ii  rsync   3.1.2-1+deb9u1
ii  wget1.18-5+deb9u1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  5.0.1-8+deb9u1

Versions of packages simple-cdd suggests:
pn  qemu-system | qemu-kvm  

-- no debconf information

Bug#884130: Botan2 update?

[GCS]

Hi Adam,

On Thu, Feb 8, 2018 at 10:13 AM, Adam Majer  wrote:
> Thank you for your interest to package Botan2 in Debian. Is there an update
> on this? QtCreator needs this library packaged sooner rather than later.
 It's already packaged[1] and uploaded. Every new package (source or
binary) needs FTP Master approval first. It needs their time, I don't
know when it will happen. Hopefully soon, I'm waiting for a month
already.

Regards,
Laszlo/GCS
[1] https://ftp-master.debian.org/new/botan_2.4.0-1.html

Bug#889915: libfaad2 in Wheezy contains patches for some security bugs. They were not backported to Jessie.

[Mikulas Patocka]

Package: libfaad2
Version: 2.7-8
Severity: normal

Dear Maintainer,

Libfaad2 in Wheezy contains some security patches. But the patches were not
backported to Jessie.



-- System Information:
Debian Release: 8.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i586)

Kernel: Linux 4.14.16 (PREEMPT)
Locale: LANG=cs_CZ, LC_CTYPE=cs_CZ (charmap=ISO-8859-2)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libfaad2 depends on:
ii  libc6  2.19-18+deb8u10
ii  multiarch-support  2.19-18+deb8u10

libfaad2 recommends no packages.

libfaad2 suggests no packages.

-- no debconf information

Bug#858588: lintian: Classification tag for missing systemd units

[Lucas Nussbaum]

On 08/02/18 at 22:43 +0530, Chris Lamb wrote:
> tags 858588 + pending
> thanks
> 
> Okay, after confusing myself even more for a bit, this is now
> pending upload:
> 
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=0848266e444d029c6fa826f1a6d3e8dd2dad0739

Thanks!

- Lucas

Bug#889914: Please allow to remove the firefox browser integration plugin

[Enrico Zini]

Package: gnome-shell
Version: 3.26.2-4
Severity: normal

Hello,

I have just reported #889912, and the same would apply for Firefox.

To complicate matters, the browser integration plugin for firefox is
packaged right with gnome-shell, making it rather hard to remove from
the system:
 
$ dpkg -S /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
gnome-shell: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
 
At least Firefox can be configured to disable the plugin in
about:addons, but that needs to be done for each user.

I really would like a way to not have that plugin in my system, so that
it cannot be accidentally enabled, or at least to have it deactivated
by default.


Enrico


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

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

Versions of packages gnome-shell depends on:
ii  caribou  0.4.21-4
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  evolution-data-server3.26.3-4
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.26.2-2
ii  gir1.2-caribou-1.0   0.4.21-4
ii  gir1.2-freedesktop   1.54.1-4
ii  gir1.2-gcr-3 3.20.0-6
ii  gir1.2-gdesktopenums-3.0 3.24.1-2
ii  gir1.2-gdm-1.0   3.26.2.1-3
ii  gir1.2-geoclue-2.0   2.4.7-1
ii  gir1.2-glib-2.0  1.54.1-4
ii  gir1.2-gnomebluetooth-1.03.26.1-2
ii  gir1.2-gnomedesktop-3.0  3.26.2-4
ii  gir1.2-gtk-3.0   3.22.26-2
ii  gir1.2-gweather-3.0  3.26.1-2
ii  gir1.2-ibus-1.0  1.5.17-3
ii  gir1.2-mutter-1  3.26.2-1
ii  gir1.2-nm-1.01.10.2-4
ii  gir1.2-nma-1.0   1.8.10-2
ii  gir1.2-pango-1.0 1.40.14-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-rsvg-2.0  2.40.20-2
ii  gir1.2-soup-2.4  2.60.3-1
ii  gir1.2-upowerglib-1.00.99.7-2
ii  gjs  1.50.3-2
ii  gnome-backgrounds3.26.2-2
ii  gnome-settings-daemon3.26.2-1
ii  gnome-shell-common   3.26.2-4
ii  gsettings-desktop-schemas3.24.1-2
ii  libasound2   1.1.3-5
ii  libatk-bridge2.0-0   2.26.1-1
ii  libatk1.0-0  2.26.1-3
ii  libc62.26-4
ii  libcairo21.15.8-3
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.26.3-4
ii  libedataserver-1.2-223.26.3-4
ii  libgcr-base-3-1  3.20.0-6
ii  libgdk-pixbuf2.0-0   2.36.11-1
ii  libgirepository-1.0-11.54.1-4
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.50.3-2
ii  libglib2.0-0 2.54.3-2
ii  libglib2.0-bin   2.54.3-2
ii  libgstreamer1.0-01.12.4-1
ii  libgtk-3-0   3.22.26-2
ii  libical3 3.0.1-5
ii  libjson-glib-1.0-0   1.4.2-3
ii  libmutter-1-03.26.2-1
ii  libnm0   1.10.2-4
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpolkit-agent-1-0  0.105-18
ii  libpolkit-gobject-1-00.105-18
ii  libpulse-mainloop-glib0  11.1-4
ii  libpulse011.1-4
ii  libsecret-1-00.18.5-6
ii  libstartup-notification0 0.12-5
ii  libsystemd0  236-3
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  mutter   3.26.2-1
ii  python3  3.6.4-1

Versions of packages gnome-shell recommends:
ii  contain-gnome-shell [chrome-gnome-shell]  1.0
ii  

Bug#889912: Please do not force chrome-gnome-shell / browser integration

[Jeremy Bicha]

On Thu, Feb 8, 2018 at 12:12 PM, Enrico Zini  wrote:
> That the equivs package works so well, makes a pretty good case to me
> that the chrome-gnome-shell should be brought in by a Recommends: rather
> than a Depends:

Thank you for taking the time to file this bug and help make Debian
better. Let me provide a bit of background:

One of GNOME 3's most popular and iconic features since the beginning
has been GNOME Shell Extensions. Traditionally, users have been able
to manage extensions (install, uninstall, change extension settings)
by visiting https://extensions.gnome.org/ via Firefox. GNOME Shell
itself included a Firefox addon to help this work.

But then Google pushed browsers to stop supporting NPAPI extensions.
GNOME Shell's addon will stop working whenever users upgrade past
Firefox 52 ESR (either already if they're using non-ESR builds or in a
few months when Firefox 60 ESR is pushed to everyone).

Therefore, Debian GNOME intentionally installs chrome-gnome-shell in
Debian 9 "Stretch" by default to prevent a regression from reaching
Debian Stable users who expect to be able to use
https://extensions.gnome.org/ like they always have been able to.
(Despite the name, chrome-gnome-shell supports Firefox and other
browsers too.)

However, as of GNOME 3.26, I believe GNOME upstream prefers users to
install and uninstall extensions from the GNOME Software app and
manage them with the GNOME Tweaks app. Since those apps are already
pre-installed for users of the 'gnome' metapackage, I think we can
lower the dependency in Debian Testing now.

Thanks,
Jeremy Bicha

Bug#807044: Okular scales down A4 to A5 on printing

[Marc Haber]

On Thu, Jan 18, 2018 at 03:26:35PM +0100, Michael Weghorn wrote:
> Thanks, Marc, for retesting and the quick reply.

You're welcome. I apologize for adding more confusion to this, but I
cannot reproduce this any more in current sid.

I guess it's fine to close the issue for okular 4:17.08.3-3 then.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#889793: lyx: python errors while building ngspice

[Uoti Urpala]

On Wed, 07 Feb 2018 01:12:57 +0100 Andreas Beckmann  wrote:
>   File "/usr/share/lyx/scripts/TeXFiles.py", line 112
> print(root.replace('\\', '/') + '/' + file, file=out)
> ^
> SyntaxError: invalid syntax

That error is a bit surprising as it's legal Python 3. I guess the
problem was that the Python sources were converted to be Python 3
compatible, but the lyx binary (implemented in C++) starts an explicit
Python binary in a child process rather than relying on shebang lines?
That was not updated to call Python 3, so Python 2 failed when trying
to process the version 3 compatible source.

Bug#889913: alot FTBFS with python-magic 2:0.4.15-1

[Adrian Bunk]

Source: alot
Version: 0.6-2
Severity: serious

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

...
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py test 
running test
Searching for file-magic

Note: Bypassing https://pypi.python.org/simple/file-magic/ (disallowed host; 
see http://bit.ly/2hrImnY for details).

Couldn't find index page for 'file-magic' (maybe misspelled?)
Scanning index of all packages (this may take a while)

Note: Bypassing https://pypi.python.org/simple/ (disallowed host; see 
http://bit.ly/2hrImnY for details).

No local packages or working download links found for file-magic
error: Could not find suitable distribution for Requirement.parse('file-magic')
E: pybuild pybuild:283: test: plugin distutils failed with: exit code=1: 
python2.7 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
debian/rules:10: recipe for target 'build' failed
make: *** [build] Error 25

Bug#889912: Please do not force chrome-gnome-shell / browser integration

[Enrico Zini]

Package: gnome-core
Version: 1:3.22+8
Severity: normal

Hello,

gnome-shell currently encourages users to download extensions off the
internet, and forces a chromium plugin, always enabled by system-wide
/etc/chromium policy, to expose extension information to
extensions.gnome.org. It also exposes a firefox plugin, which I have not
investigated.

Such browser integration is a feature that I do not trust, I do not
need, and I do not want.

Finding myself unable to remove chrome-gnome-shell without breaking
gnome dependencies, I resorted to writing an equivs replacement for
chrome-gnome-shell[1], and my desktop is running perfectly, except that
if I go to extensions.gnome.org I get a message inviting me to install
gnome shell integration, which is appropriate.

That the equivs package works so well, makes a pretty good case to me
that the chrome-gnome-shell should be brought in by a Recommends: rather
than a Depends:


Enrico

[1] http://www.enricozini.org/blog/2018/debian/gnome-without-chrome-gnome-shell/


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

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

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.26.1-3
ii  at-spi2-core  2.26.2-2
ii  baobab3.26.1-2
ii  caribou   0.4.21-4
ii  chromium  62.0.3202.89-1
ii  contain-gnome-shell [chrome-gnome-shell]  1.0
ii  dconf-cli 0.26.1-3
ii  dconf-gsettings-backend   0.26.1-3
ii  eog   3.26.2-3
ii  evince3.26.0-3
ii  evolution-data-server 3.26.3-4
ii  firefox-esr   52.6.0esr-2
ii  fonts-cantarell   0.0.25-4
ii  gdm3  3.26.2.1-3
ii  gedit 3.22.1-3
ii  gkbd-capplet  3.26.0-2
ii  glib-networking   2.54.1-2
ii  gnome-backgrounds 3.26.2-2
ii  gnome-bluetooth   3.26.1-2
ii  gnome-calculator  3.26.0-3+b1
ii  gnome-characters  3.26.2-2
ii  gnome-contacts3.26.1-1
ii  gnome-control-center  1:3.26.2-1
ii  gnome-disk-utility3.26.2-2
ii  gnome-font-viewer 3.26.0-2
ii  gnome-keyring 3.20.1-2
ii  gnome-logs3.26.2-2
ii  gnome-menus   3.13.3-11
ii  gnome-online-accounts 3.26.2-1
ii  gnome-online-miners   3.26.0-2
ii  gnome-session 3.26.1-2
ii  gnome-settings-daemon 3.26.2-1
ii  gnome-shell   3.26.2-4
ii  gnome-shell-extensions3.26.2-3
ii  gnome-software3.26.5-1
ii  gnome-sushi   3.24.0-3
ii  gnome-system-monitor  3.26.0-3
ii  gnome-terminal3.26.2-3
ii  gnome-themes-standard 3.22.3-4
ii  gnome-user-docs   3.26.2.1-1
ii  gnome-user-share  3.18.3-3
ii  gsettings-desktop-schemas 3.24.1-2
ii  gstreamer1.0-packagekit   1.1.7-1
ii  gstreamer1.0-plugins-base 1.12.4-1
ii  gstreamer1.0-plugins-good 1.12.4-1
ii  gstreamer1.0-pulseaudio   1.12.4-1
ii  gvfs-backends 1.34.1-2
ii  gvfs-bin  1.34.1-2
ii  gvfs-fuse 1.34.1-2
ii  libatk-adaptor2.26.1-1
ii  libcanberra-pulse 0.30-6
ii  libpam-gnome-keyring  3.20.1-2
ii  libproxy1-plugin-gsettings0.4.14-4
ii  nautilus  3.26.2-2
ii  pulseaudio11.1-4
ii  sound-theme-freedesktop   0.8-2
ii  system-config-printer-common  1.5.9-3
ii  system-config-printer-udev1.5.9-3
ii  totem 3.26.0-3
ii  tracker   2.0.2-1
ii  vino  3.22.0-2
ii  yelp  3.26.0-2
ii  zenity3.26.0-2

Versions of packages gnome-core recommends:
ii  anacron  

Bug#888952: nvidia-driver and opencl

[Russ Allbery]

Hiromasa YOSHIMOTO  writes:

> I wrote small program to reproduce this issue.
> Could you check and try the attached code?
> The step is:
> $ gcc check.c -lcap -omain
> $ cp main sub   # "sub" corresponds to insmod that
> causes EPERM
> $ sudo chown 0.0 main
> $ sudo chmod u+s main# "main" corresponds to nvidia-modprobe
> $ ./main

> This is what I get:
> ./main  euid: 0 # root privilege
> CAP_SYS_MODULE: 1# has capability
> ./sub  euid: 1000# lost root privilege (1000 is my uid)
> CAP_SYS_MODULE: 0# the cap. is removed.

> Strictly, I use dash as /bin/sh
> but CAP_SYS_MODULE is dropped when system() is used.

I believe dash will drop privileges if euid != uid.  See:

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

The workaround is to call setuid(0) in the parent program before you call
modprobe, or otherwise arrange for euid == uid.

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

Bug#858588: lintian: Classification tag for missing systemd units

[Chris Lamb]

tags 858588 + pending
thanks

Okay, after confusing myself even more for a bit, this is now
pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=0848266e444d029c6fa826f1a6d3e8dd2dad0739


Regards,

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

Bug#889911: picolisp FTBFS on arm64: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `SnxTab' which may bind externally can not be used when making a shared object

[Adrian Bunk]

Source: picolisp
Version: 17.12-2
Severity: serious

Some recent change in unstable makes picolisp FTBFS on arm64:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/arm64/picolisp.html

...
make -C src64 CFLAGS="" LDFLAGS="" arm64.linux picolisp
make[2]: Entering directory '/build/1st/picolisp-17.12/src64'
./mkAsm arm64 ".linux" .s Linux base "" ../lib/map  version.l glob.l main.l 
gc.l apply.l flow.l sym.l subr.l big.l io.l db.l net.l err.l 
sys/arm64.linux.code.l
./mkAsm arm64 ".linux" .s Linux ext T ""  ext.l
./mkAsm arm64 ".linux" .s Linux ht T ""  ht.l
as -o arm64.linux.base.o arm64.linux.base.s
cc -o ../bin/picolisp arm64.linux.base.o -Wl,--no-as-needed -rdynamic -lc -lm 
-ldl 
strip ../bin/picolisp
as -o arm64.linux.ext.o arm64.linux.ext.s
cc -o ../lib/ext arm64.linux.ext.o -shared -export-dynamic
/usr/bin/ld: arm64.linux.ext.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against 
symbol `SnxTab' which may bind externally can not be used when making a shared 
object; recompile with -fPIC
arm64.linux.ext.o: In function `.7':
(.text+0x110): dangerous relocation: unsupported relocation
/usr/bin/ld: arm64.linux.ext.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against 
symbol `Chr64' which may bind externally can not be used when making a shared 
object; recompile with -fPIC
arm64.linux.ext.o: In function `.21':
(.text+0x304): dangerous relocation: unsupported relocation
/usr/bin/ld: arm64.linux.ext.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against 
symbol `Chr64' which may bind externally can not be used when making a shared 
object; recompile with -fPIC
arm64.linux.ext.o: In function `.22':
(.text+0x3c8): dangerous relocation: unsupported relocation
/usr/bin/ld: arm64.linux.ext.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against 
symbol `Chr64' which may bind externally can not be used when making a shared 
object; recompile with -fPIC
arm64.linux.ext.o: In function `chr64A':
(.text+0x61c): dangerous relocation: unsupported relocation
collect2: error: ld returned 1 exit status
Makefile:201: recipe for target '../lib/ext' failed
make[2]: *** [../lib/ext] Error 1

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Tomasz Janowski]

On Thursday, February 8, 2018 5:37:25 PM EST Greg KH wrote:
> On Thu, Feb 08, 2018 at 10:53:20AM -0500, Tomasz Janowski wrote:
> > On Thursday, February 8, 2018 3:43:05 PM EST Greg KH wrote:
> > > On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> > > > Dear USB developers,
> > > > 
> > > > Based on my google research, the problem I experience seems to happen
> > > > with some newer smartphones. My test case is Samsung Galaxy S8
> > > > (SM-950U1).
> > > > I am trying to use USB tethering and everything seems to work as
> > > > expected
> > > > (modules are loaded, Ethernet devices are up and running, dhcp works
> > > > fine). I can connect to the external world using both LTE or wireless
> > > > network on the phone.
> > > > 
> > > > Now, the problem is that the download speeds are terrible, around 64
> > > > KB/s,
> > > > while uploads are fast, the order of 15 MB/s. These speeds do not
> > > > depend
> > > > on the wireless service provider: the results are similar when I
> > > > tether
> > > > wi-fi. The USB Ethernet interface on the Linux host reports a lot of
> > > > receive errors (attached: device_state.txt), while kernel reports bad
> > > > rndis messages (attached: kernel.log.txt).
> > > > 
> > > > Windows 10 works great with the same hardware (same PC and same
> > > > phone),
> > > > with uploads and downloads in the order of 150 Mbit/s, which is
> > > > probably
> > > > as fast as my wireless network can do. But some people reported issues
> > > > with older Windows drivers too. Is possible that some newer version of
> > > > RNDIS protocol is around and Linux hasn't updated its RNDIS module
> > > > yet?
> > > 
> > > Hey, I was _just_ talking to someone at Google about this same issue
> > > yesterday, you beat him sending this same type of report to the mailing
> > > list, nice job :)
> > > 
> > > Yes, this is not good, and we should work to resolve this, but first,
> > > what kernel version are you using?  I think some fixes for the rndis
> > > driver went in recently to 4.15, but it would be good to verify that
> > > this isn't already resolved.
> > 
> > The error messages which I have attached were produced by a precompiled
> > Debian kernel: "Linux version 4.14.0-0.bpo.3-amd64
> > (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian
> > 6.3.0-18)) #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14)".
> > 
> > But I have downloaded the most recent version of the kernel from the
> > official git repository (last commit: Jan 31, 2018) and it had exactly
> > the same problem. Unless a patch was submitted within the last week, the
> > issue is still there.
> > 
> > Should I get the version as of today and test it again?
> 
> If you find a 4.15 tree, that would be great to test, but odds are, the
> issues are still there.
> 
> I'll try to carve out some time to look at this tomorrow, as I have a
> bunch of Android devices to test with, and there's no good reason why
> Windows should be slower than Linux for stuff like this.  We should be
> able to go as fast as the device lets us.  Most likely we are doing
> something "stupid" in the rndis driver somewhere :)
> 
Thanks a lot!

I have tested with kernel downloaded from:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
The version was 4.15.0+, so I guess that was cutting edge kernel as of 
01/31/2018.
Just to clarify, Windows is faster than Linux. 64 KB/s in Linux makes the USB 
tethering not so useful, and if the "PC" is a laptop, one can live with wi-fi 
hotspot, which works fine. Desktop PC must use USB. I also thought that USB has 
a greater potential to deliver better throughput than wifi hotspot.

I have tested another phone, Galaxy J7 Pro (2017 version). That phone uses a 
different hardware, different USB connector, and an older kernel version. J7 
works fine with current Linux kernel, so it is necessary to use as recent 
Android (and possibly hardware) as possible.

Thanks!
Tomasz

Bug#889909: dolibarr: missing dependency on php-pclzip

[Maximilian Stein]

Package: dolibarr
Version: 5.0.4+dfsg3-1
Severity: normal

Dear Maintainer,

On a fresh Debian Stretch I installed Dolibarr from sid for usage in
an nginx+php-fpm environment. Unfortunately, document generation
failed. The PHP logs revealed:

    PHP message: PHP Fatal error:  require_once(): Failed opening
    required '/usr/share/php/pclzip.lib.php'
    (include_path='.:/usr/share/php') in
    /usr/share/dolibarr/htdocs/includes/odtphp/zip/PclZipProxy.php on
    line 3" while reading response header from upstream, client:
    10.1.1.1, server: , request: "POST
    /societe/soc.php?socid=14 HTTP/1.0", upstream:
    "fastcgi://unix:/var/run/php/php7.0-fpm.sock:", host:
    "XXX", referrer:
    "https://XXX/societe/soc.php?socid=14;

Apparently, pclzip was missing, so I installed the package php-pclzip
(2.8.2-4) which has indeed resoled the issue. So, dolibarr should
probably depend on php-pclzip.

Best,
Maximilian

Bug#889910: pam_succeed_if: fields rhost and tty broken

[Martin.Belanger]

Package: libpam0g
Version: 1.1.8-3.6
Severity: important

The fields "rhost" and "tty" do not work because of a bug in the code. The bug 
has been fixed in 2014 in the upstream project. Here's the link for the fix:

https://github.com/linux-pam/linux-pam/commit/5df44a328abe4befc4479e16ce7fd86ff2caedcc

Bug#834423: latex2html: FTBFS with '.' removed from perl's @INC

[Daniel Gildea]

Release latex2html-2018 fixes this bug as well as:

https://bugs.debian.org/144034
https://bugs.debian.org/188024
https://bugs.debian.org/310702
https://bugs.debian.org/612126
https://bugs.debian.org/827187
https://bugs.debian.org/834420

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Greg KH]

On Thu, Feb 08, 2018 at 10:53:20AM -0500, Tomasz Janowski wrote:
> On Thursday, February 8, 2018 3:43:05 PM EST Greg KH wrote:
> > On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> > > Dear USB developers,
> > > 
> > > Based on my google research, the problem I experience seems to happen
> > > with some newer smartphones. My test case is Samsung Galaxy S8 (SM-950U1).
> > > I am trying to use USB tethering and everything seems to work as expected
> > > (modules are loaded, Ethernet devices are up and running, dhcp works
> > > fine). I can connect to the external world using both LTE or wireless
> > > network on the phone.
> > > 
> > > Now, the problem is that the download speeds are terrible, around 64 KB/s,
> > > while uploads are fast, the order of 15 MB/s. These speeds do not depend
> > > on the wireless service provider: the results are similar when I tether
> > > wi-fi. The USB Ethernet interface on the Linux host reports a lot of
> > > receive errors (attached: device_state.txt), while kernel reports bad
> > > rndis messages (attached: kernel.log.txt).
> > > 
> > > Windows 10 works great with the same hardware (same PC and same phone),
> > > with uploads and downloads in the order of 150 Mbit/s, which is probably
> > > as fast as my wireless network can do. But some people reported issues
> > > with older Windows drivers too. Is possible that some newer version of
> > > RNDIS protocol is around and Linux hasn't updated its RNDIS module yet?
> > 
> > Hey, I was _just_ talking to someone at Google about this same issue
> > yesterday, you beat him sending this same type of report to the mailing
> > list, nice job :)
> > 
> > Yes, this is not good, and we should work to resolve this, but first,
> > what kernel version are you using?  I think some fixes for the rndis
> > driver went in recently to 4.15, but it would be good to verify that
> > this isn't already resolved.
> 
> The error messages which I have attached were produced by a precompiled 
> Debian 
> kernel: "Linux version 4.14.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) 
> (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.14.13-1~bpo9+1 
> (2018-01-14)".
> 
> But I have downloaded the most recent version of the kernel from the official 
> git repository (last commit: Jan 31, 2018) and it had exactly the same 
> problem. Unless a patch was submitted within the last week, the issue is 
> still 
> there.
> 
> Should I get the version as of today and test it again?

If you find a 4.15 tree, that would be great to test, but odds are, the
issues are still there.

I'll try to carve out some time to look at this tomorrow, as I have a
bunch of Android devices to test with, and there's no good reason why
Windows should be slower than Linux for stuff like this.  We should be
able to go as fast as the device lets us.  Most likely we are doing
something "stupid" in the rndis driver somewhere :)

thanks,

greg k-h