Bug#838904: Autobuilding mdk-doc (non-free)

[Philipp Kern]

Hi,

On 11/12/2016 12:15 PM, Peter Pentchev wrote:
> First of all, thanks for all your work on Debian, and even on
> the non-strictly-Debian parts of it!
> 
> As per the Developers Reference, I'm leaving a note here that IMHO my
> mdk-doc non-free package can be built automatically.  It's only non-free
> because of an invariant documentation section; there is no problem
> whatsoever with the distribution of either the source or the built
> binary packages.
> 
> Now, since this is the first time I'm doing this - should I wait for
> an acknowledgement before I (or my sponsors) upload the next version of
> mdk-doc with XS-Autobuild set to "yes"?  Just to be safe, I guess I'll
> wait for a couple of days :)

I have whitelisted the package now. Generally you can upload with the
flag but it won't take effect until the whitelist entry has been added.

Kind regards and cheers
Philipp Kern





signature.asc
Description: OpenPGP digital signature

Bug#844394: pgcli: crash at startup: pkg_resources.ContextualVersionConflict: (sqlparse 0.2.2

[Adam Borowski]

Package: pgcli
Version: 1.1.0-1
Severity: grave
Justification: renders package unusable

Upon start, pgcli dies with:
.--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 658, in 
_build_master
ws.require(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 966, in 
require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 857, in 
resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (sqlparse 0.2.2 
(/usr/lib/python3/dist-packages), Requirement.parse('sqlparse==0.1.18'), 
{'pgcli'})

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/pgcli", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2994, 
in 
@_call_aside
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2980, 
in _call_aside
f(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3007, 
in _initialize_master_working_set
working_set = WorkingSet._build_master()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 660, in 
_build_master
return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 673, in 
_build_from_requirements
dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 852, in 
resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'sqlparse==0.1.18' distribution was not 
found and is required by pgcli
`


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing')
Architecture: armhf (armv7l)

Kernel: Linux 3.8.13.30 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pgcli depends on:
ii  python3-click   6.6-1
ii  python3-configobj   5.0.6-2
ii  python3-humanize0.5.1-2
ii  python3-pgspecial   1.6.0-1
ii  python3-prompt-toolkit  1.0.9-1
ii  python3-psycopg22.6.2-1
ii  python3-pygments2.1.3+dfsg-1
ii  python3-setproctitle1.1.10-1
ii  python3-sqlparse0.2.2-1
ii  python3-wcwidth 0.1.7+dfsg1-1
pn  python3:any 

pgcli recommends no packages.

pgcli suggests no packages.

-- no debconf information

Bug#844393: blhc still uses dpkg architecture triplets

[Johannes Schauer]

Package: blhc
Version: 0.07-0.1
Severity: grave
Justification: renders package unusable

Hi,

recently, dpkg switched from the triplettable to architecture
quadruplets. When now trying to run blhc with the new libdpkg-perl, one
will get:

Undefined subroutine ::Arch::debarch_to_debtriplet called at /usr/bin/blhc 
line 1032.

please adjust blhc to the new dpkg release.

Thanks!

cheers, josch

Bug#841560: Could anybody please check the issue in python-skbio

[Andreas Tille]

Hi Kevin or others,

could anybody check the issue in the skbio test suite?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#844389: npm2deb: properly install files if files section is not present in package.json

[Jérémy Lal]

2016-11-15 7:38 GMT+01:00 Shanavas M :
> Package: npm2deb
> Version: 0.2.6-1
> Severity: normal
>
> Dear Maintainer,
>
> If files section is missing in package.json include everything excluding files
> ignored by .npmignore and .gitignore
>
> https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package
>
> bugs like #844333 can be avoided

The right way to do it is to use the `fstream-npm` module.
However, npm2deb must make sure the maintainer WILL look inside debian/install,
or else a lot of garbage is going to be installed.

Jérémy

Bug#800891: Please adjust the licensing of afex

[Andreas Tille]

Hi Henrik,

please have a look at the bug report about license violation in the
Debian bug tracker:

   https://bugs.debian.org/800891

Due to this license violation we can not distribute afex in the next
Debian release which we would really like to.  Would you mind switching
to GPL-2 which would simply solve the issue?

Thanks for considering

Andreas.

-- 
http://fam-tille.de

Bug#835185: #835185: mysql-workbench: Segfault when opening connection

[Dmitry Smirnov]

On Tuesday, 15 November 2016 6:34:58 AM AEDT Rene Engelhard wrote:
> Just did. Indeed mysql-workbench from sid works with sids
> libmysqlcppconnv5. Maybe you shouuld add a explicit libmysqlcppconn7v5 (>=
> 1.1.7-3) dependency, though to go sure.

Will do. It will only take a re-build or -dev dependency version bump...


> > Maybe i should try libreoffice-mysql-connecor, too.
> 
> LO doesn't without a rebuilt, but it seems it does after a rebuild...
> 
> I will for sure add a dependency as above.

Don't do it manually. Just re-build against mysql-connector-c++ 1.1.7-4
where I've fixed shlibs for tighter versioning. Properly versioned dependency 
will be generated automatically.

-- 
Best wishes,
 Dmitry Smirnov.

---

If you focus your mind on the freedom and community that you can build
by staying firm, you will find the strength to do it. "Stand for
something, or you will fall for nothing."
-- Richard Stallman


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

Bug#844392: vlc refuses to install with debian backports enabled

[Arcademan]

Source: vlc
Version: 2.2.4-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
 Trying to install vlc with debian jessie backports installed  led to unmet 
dependencies
   
 OS: Debian 8.6 (Jessie) with Backports Enabled

Error:

 Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 vlc : Depends: libgles1-mesa (>= 7.8.1) but it is not going to be installed or
libgles1
   Depends: libgles2-mesa (>= 7.8.1) but it is not going to be installed or
libgles2
E: Unable to correct problems, you have held broken packages.


*** End of the template - remove these template lines ***


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

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#844391: ITP: node-magic-string -- Modify strings, generate sourcemaps

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-magic-string
  Version : 0.16.0
  Upstream Author : Rich Harris
* URL : https://github.com/Rich-Harris/magic-string
* License : Expat
  Programming Lang: JavaScript
  Description : Modify strings, generate sourcemaps
This package makes it possible to update a source map of a lightly modified
 source code.
.
Node.js is an event-based server-side JavaScript engine.


I plan to package it within the Debian Javascript Maintainers repository:

Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-magic-string.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-javascript/node-magic-string.git


Cheers,

Snark on #debian-js

Bug#828263: cfengine3: FTBFS with openssl 1.1.0

[Petter Reinholdtsen]

[Antonio Radici]
> the version in experimental builds fine with 1.1.0, I'll upload it to
> unstable tonight.

Thank you.  Would you be willing to provide a backport of the package
for jessie?

-- 
Happy hacking
Petter Reinholdtsen

Bug#844148: acl2: FTBFS: certification failed directory

[Stepan Golosunov]

14.11.2016 в 11:24:04 -0500 Camm Maguire написал(а):
> Neither ACL2 nor underlying gcl makes any use of threads or locks, but

Note that the failing memoize-tests.lisp creates some sort of threads
and mentions lock contention in comments.

> > **CERTIFICATION FAILED** for 
> > /<>/books/system/hons-check/memoize-tests.lisp
> > 
> > /<>/books/build/make_cert:106: recipe for target 
> > 'system/hons-check/memoize-tests.cert' failed
> > make[2]: *** [system/hons-check/memoize-tests.cert] Error 1

Bug#784269: Problems with item delivery, n.5747269

[FedEx SmartPost]

Hello,
We could not deliver your item. Shipment Label is attached to email.
Bethanne Hariston - Area Manager FedEx , CA
Yours trully


FedEx.doc
Description: MS-Word document

Bug#844068: synapse: Unable to connect to Zeitgeist

[Mario Geiger]

Dear Maintainer,

The problem solved by itself Oo !?

:-)

Bug#843988: stunnel4 segfaults (client mode)

[Peter Pentchev]

On Mon, Nov 14, 2016 at 11:13:14PM +0100, Sebastian Andrzej Siewior wrote:
> On 2016-11-14 22:43:16 [+0100], gregor herrmann wrote:
> > Control: tag -1 + patch
> > 
> > On Mon, 14 Nov 2016 22:07:12 +0100, Sebastian Andrzej Siewior wrote:
> > 
> > > On 2016-11-14 00:17:31 [+0100], gregor herrmann wrote:
> > > > Thanks, but nope, still the same:
> > > What about this one?
> > 
> > Yay, this looks good!
> > 
> > Built, installed, started, and it's still running after several
> > fetchnews runs. Thanks!
> 
> Thank you for the confirmation. And now please explain why it works with
> openssl 1.0.2. It should have exploded the same way…

Well, the cleanup handling has changed a bit from OpenSSL 1.0 to 1.1,
although stunnel's cleanup routines do seem to have been updated;
maybe something was missed there.

Thanks A LOT for the analysis and this patch!  I'll take a look now, see
if there's something else, and forward it upstream.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#844390: ITP: node-sourcemap-codec -- Encode/decode sourcemap mappings

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-sourcemap-codec
  Version : 1.3.0
  Upstream Author : Rich Harris
* URL : https://github.com/Rich-Harris/sourcemap-codec
* License : Expat
  Programming Lang: JavaScript
  Description : Encode/decode sourcemap mappings
This package makes generating sourcemap mappings easier,
since that is a difficult task : the format uses variable-length
quantities and uses relative offsets, so it can't be done by chunks.
.
Node.js is an event-based server-side JavaScript engine.


I plan to package it within the Debian Javascript Maintainers repository:

Vcs-Git: 
https://anonscm.debian.org/git/pkg-javascript/node-sourcemap-codec.git
Vcs-Browser: 
https://anonscm.debian.org/cgit/pkg-javascript/node-sourcemap-codec.git


Cheers,

Snark on #debian-js

Bug#844364: bug on rsyslogd

[Thomas Fragstein]

Hi,


thanks for you answer.

Over month I seen that the logfiles on the second block (all files) will 
not rotated.


I have seen that the files was scanned from the logrotated ( 
/var/lib/logrotate/status ) and a manual logrotate with


(logrotate -v /etc/logrotate.conf) wite down that not file must be 
rotated. only remove the sharedscripts command has helped.


But I understand what the command do and normalize i will say it has 
nothing to do with my issue.



So i have try it with the tag and the logroted will rotate all files now.

In this case I will not exactly understand what was the problem and you 
can close the bugreport.



regards

Thomas

Bug#844389: npm2deb: properly install files if files section is not present in package.json

[Shanavas M]

Package: npm2deb
Version: 0.2.6-1
Severity: normal

Dear Maintainer,

If files section is missing in package.json include everything excluding files
ignored by .npmignore and .gitignore

https://docs.npmjs.com/misc/developers#keeping-files-out-of-your-package

bugs like #844333 can be avoided

Bug#844382: libdrm-amdgpu1: OpenCL Producer/Reader Invalid Record

[Michel Dänzer]

On 15/11/16 12:57 PM, Marc Jeffrey Driftmeyer wrote:
> Package: libdrm-amdgpu1
> Version: 2.4.71-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Testing Blender OpenCL with the RX 480 8GB and checking the status of it via 
> clinfo revealed the following error in building libdrm-amdgpu1
> 
> === CL_PROGRAM_BUILD_LOG ===
> Invalid record (Producer: 'LLVM3.9.0' Reader: 'LLVM 3.8.1')  Preferred work 
> group size multiple  Invalid record (Producer: 'LLVM3.9.0' 
> Reader: 'LLVM 3.8.1')
>   Preferred / native vector sizes 

This has nothing to do with libdrm-amdgpu1. It's an issue between
blender, mesa-opencl-icd, libclc-amdgcn and libllvm3.8/9.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Bug#692200: sound-juicer: Cannot read audio CD

[Marco Steinacher]

I also had the problem that sound-juicer could not mount/access the
audio CD.  I'm running Debian jessie with Xfce.

The following workaround worked for me:

 1. Installed the missing 'gvfs-backends' package manually.

 2. Mounting the audio CD with the command 'gvfs-mount cdda://sr0' (as
normal user) prior to running sound-juicer.


Marco

Bug#844388: ITP: node-vlq -- Variable-length quantity mapper for Node.js

[Julien Puydt]

Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-CC: pkg-javascript-de...@lists.alioth.debian.org

* Package name: node-vlq
  Version : 0.2.0
  Upstream Author : Rich Harris
* URL : https://github.com/Rich-Harris/vlq
* License : Expat
  Programming Lang: JavaScript
  Description : Variable-length quantity mapper for Node.js
 Generate and decode base64 variable-length quantity mappings for
 source maps and other uses
 .
 Node.js is an event-based server-side JavaScript engine.


I plan to package it within the Debian Javascript Maintainers repository:

Vcs-Git: https://anonscm.debian.org/git/pkg-javascript/node-vlq.git
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-javascript/node-vlq.git

Cheers,

Snark on #debian-js

Bug#813285: We could not deliver your parcel, #8799932

[FedEx International MailService]

Hello,
We could not deliver your parcel. Please, open email attachment to print 
shipment label.
Harrie Davey - Area Manager FedEx , CA
Yours sincerely


FedEx.doc
Description: MS-Word document

Bug#844373: ros-image-common: FTBFS (incompatible build-dependencies)

[Steve M. Robbins]

On Tuesday, November 15, 2016 1:02:10 AM CST Santiago Vila wrote:
> Package: librospack-dev,libgtest-dev,src:ros-image-common
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build ros-image-common in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> 
>  [...]
> Unpacking librospack-dev (2.3.1-1+b1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-dJJuDK/111-librospack-dev_2.3.1-1+b1_amd64.deb
> (--unpack): trying to overwrite '/usr/include/gtest/gtest-death-test.h',
> which is also in package libgtest-dev:amd64 1.7.0-4 dpkg-deb: error:
> subprocess paste was killed by signal (Broken pipe)

I think it should be clear that /usr/include/gtest is owned by libgtest-dev, 
so I'll reassign the bug to librospack-dev.

Best case: librospack-dev can use Debian's libgtest-dev.  If not, then please 
place the files somewhere else.

> OTOH, if one of the packages librospack-dev or libgtest-dev should not
> contain the file, then please reassign to the package at fault and
> also send an "affects" command to the control address, so that we can
> still see that this bug affects src:ros-image-common in its BTS web page.
> 
> Sorry that I can't tell for sure which one of those cases is the truth,
> I just detected this problem by trying to build ros-image-common.
> 
> Thanks.



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

Bug#811096: Re-open the bug (libpam-poldi: missing pam configuration)

[NIIBE Yutaka]

reopen 811096
thanks

In 0.4.2+git20161107.16912be-1, I closed this bug by offering the
config, but it resulted bad configuration.  It's:

 Part of /etc/pam.d/common-auth
# here are the per-package modules (the "Primary" block)
auth[success=2 default=ignore]  pam_unix.so nullok_secure
auth[success=1 default=ignore]  pam_poldi.so


I think that this is pretty bad configuration for Poldi.  It should
not be in common-auth.

Please note that Poldi is somehow experimental.  Even though it's
a PAM module, the code was not written carefully assuming the code
may be used with privileged mode.

The authentication by Poldi should be only allowed to specific
service(s) and remote services should not be allowed.

I think that it's good to leave as administrator task to configure
Poldi so that some local services enables Poldi but requiring local
and secure TTY.

I'll remove configuration in updated package.
-- 

Bug#840094: blends-dev: Does not recognize multiline dependencies

[Andreas Tille]

Hi,

I just want to announce that I'll be de-facto offline today and
tomorrow.  So I can not do further testing of the "Use of uninitialized
value" testing.

Kind regards

  Andreas.

On Fri, Nov 11, 2016 at 12:52:46PM +0100, Andreas Tille wrote:
> Hi,
> 
> On Fri, Nov 11, 2016 at 11:50:12AM +0100, Petter Reinholdtsen wrote:
> > [Ole Streicher]
> > > OK, I committed another version, with backslashes everywhere. Adjusted
> > > tool is attached.
> > 
> > Very good.  This one look like it should still work, and fixes a few
> > mistakes in the process.  Thank you very much.
> 
> +1
> 
> I double checked here Debian Edu looks fine.  Since there was another
> code change I repeated my checks for Debian Med and Debian Science.
> While Debian Med is OK for Debian Science I get in a make dist lots of
> lines like:
>  
> ...
> Hit http://ftp.debian.org testing InRelease
> Get:1 http://ftp.debian.org testing/main amd64 Packages/DiffIndex [27.9 kB]
> Get:2 http://ftp.debian.org testing/main Translation-en/DiffIndex [27.9 kB]
> Get:3 http://ftp.debian.org testing/main Translation-de/DiffIndex [27.8 kB]
> Fetched 83.6 kB in 1s (83.2 kB/s)
> Reading package lists... Done
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 28.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 28.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 28.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 28.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 72.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 72.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 72.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 72.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 248.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 248.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 145.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 145.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 145.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 145.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 104.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 104.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 108.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 108.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 108.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 108.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 77.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 568,  line 77.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 77.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 77.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 62.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 62.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 598,  line 24.
> Use of uninitialized value $_ in pattern match (m//) at 
> /usr/share/blends-dev/blend-gen-control line 609,  line 24.
> ...
> 
> 
> The result looks OK, but the output is suspicious.  I've checked with
> blends-dev=0.6.94 and here this output does not occure.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Bug#844387: ITP: pytest-expect -- py.test plugin to store test expectations

[Diane Trout]

Package: wnpp
Severity: wishlist
Owner: Diane Trout 

* Package name: pytest-expect
  Version : 1.1.0
  Upstream Author : Geoffrey Sneddon 
* URL : https://github.com/gsnedders/pytest-expect
* License : Expat
  Programming Lang: Python
  Description : py.test plugin to store test expectations

A py.test plugin that stores test expectations by saving the set of failing
tests, allowing them to be marked as xfail when running them in future. The
tests expectations are stored such that they can be distributed alongside the
tests. However, note that test expectations can only be reliably shared between
Python 2 and Python 3 if they only use ASCII characters in their node ids: this
likely isn’t a limitation if tests are using the normal Python format, as
Python 2 only allows ASCII characters in identifiers.


This package is a dependency for running the tests for the currently existing
Debian package python-html5lib. As html5lib is a build-dep for python-pip,
getting this fixed is pretty important.

This should be managed through the Debian Python modules team.

Bug#844364: bug on rsyslogd

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

Am 14.11.2016 um 21:32 schrieb Thomas Fragstein:
> Package: rsyslog
> 
> The original rsyslog package will bring a default logrotate config file.
> 
> Its separated in two blocks. In the second block is a additional key
> "sharedscripts" included. it causes the logrotate daemon will not rotate
> the couple on logfiles.
> 

I don't see a bug here. Can you elaborate?
The sharedscripts statement is there, so rsyslog is only restarted once,
after all files have been rotated (see the logrotate man page).
Otherwise it would have to be restarted multiple times. I don't see how
that could affect files not being rotated at all. So this looks all
correct to me.
There is obviously the unlikely possibility that logrotate has a bug.

Needless to say, the log files are rotated just fine here.
So I need more details what actually is going wrong for you, i.e. which
files are not rotated? What does logrotate report (if you turn on debug
mode), timestamps of affected files etc.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#835185: #835185: mysql-workbench: Segfault when opening connection

[Rene Engelhard]

fixed 835185 1.1.7-3
thanks

Hi,

On Mon, Nov 14, 2016 at 01:36:14PM +0100, Rene Engelhard wrote:
> > mysql-connector-c++ v1.1.7 linked with MariaDB libraries (as well as M-W) 
> > to 
> > unstable. It should address all the problems...
> 
> Did you try it on i386 yourself? Does it work?

Just did. Indeed mysql-workbench from sid works with sids libmysqlcppconnv5.
Maybe you shouuld add a explicit libmysqlcppconn7v5 (>= 1.1.7-3) dependency,
though to go sure.

> Maybe i should try libreoffice-mysql-connecor, too.

LO doesn't without a rebuilt, but it seems it does after a rebuild...

I will for sure add a dependency as above.

Regards,
 
Rene

Bug#844386: Ships unnecessary, explicit trigger for liburfkill-glib0

[Michael Biebl]

Source: urfkill
Version: 0.5.0-5
Severity: minor

Hi,

in 0.5.0-5 you added an explicit trigger
debian/liburfkill-glib0.triggers for ldconfig.

This is not necessary. dh_makeshlibs will generate one automatically for
you, so you can safely drop debian/liburfkill-glib0.triggers.

You can check this after a successful build. You'll have a file

$ cat debian/liburfkill-glib0/DEBIAN/triggers
# Triggers added by dh_makeshlibs
activate-noawait ldconfig



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

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

Bug#844381: mysql-workbench: Application crashes whenever it tries to connect to any database

[Dmitry Smirnov]

On Monday, 14 November 2016 10:36:19 PM AEDT JWM wrote:
> After installing the newly uploaded mysql-workbench 6.3.6+dfsg-1, whenever
> I try to connect to any database, the application crashes with:
> [..]
> Versions of packages mysql-workbench depends on:
> ii  libmysqlcppconn7v5  1.1.4+really1.1.3-1

The problem is weak dependency on libmysqlcppconn7v5 -- please update this 
library to the latest version from "unstable" and it will fix the problem.

I'll tighten dependency with next upload...

-- 
Regards,
 Dmitry Smirnov.

---

I believe in only one thing: liberty; but I do not believe in liberty
enough to want to force it upon anyone.
-- H. L. Mencken


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

Bug#844341: moin: CVE-2016-7148: XSS in AttachFile view (multifile related)

[Paul Wise]

On Mon, 14 Nov 2016 16:47:37 +0100 Salvatore Bonaccorso wrote:

> [1] http://hg.moinmo.in/moin/1.9/rev/eceb70c41ecc

I've tested this patch on the Debian wiki and it definitely fixes it.

If your wiki admins are active it is pretty unlikely to be able to get
past their review of RecentChanges though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#844385: evolution: Hangs on startup: Saving User interface state

[Russell Stuart]

Package: evolution
Version: 3.22.2-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Copy of upstream bug report https://bugzilla.gnome.org/show_bug.cgi?id=774448:

  Version: Debian evolution_3.22.2-1_amd64

  Evolution hangs sometimes on startup.  I suspect it starts successfully
  if there is no email to fetch, and always hangs if there is email to fetch.

  Screen shot in the hung state attached as "evolution-hung.png".

  It is not completely hung.  File --> Quit prompts with "Close Evolution with
  Pending Background Operations?" after a wile, and "Close Immediately" does
  just that.  Whether it restarts without hanging is a lottery, but my guess
  is if it has finished collecting email it is successful.

  Screen short with ie asking to exit with Pending Background Operations is
  attached as: "evolution-pending.png".

  It will from time to time hang in an identical fashion during normal
  operation.

Utterly unrelated: when searching for a duplicate while filing I lose
patience before getting to the end of 480 bugs.  Many of those 480 bugs
are for versions of Debian that are no longer supported.  It would be
really helpful if you did a bit of triaging.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution depends on:
ii  dbus   1.10.12-1
ii  evolution-common   3.22.2-1
ii  evolution-data-server  3.22.2-1
ii  libc6  2.24-5
ii  libcamel-1.2-593.22.2-1
ii  libclutter-gtk-1.0-0   1.8.2-1
ii  libecal-1.2-19 3.22.2-1
ii  libedataserver-1.2-22  3.22.2-1
ii  libevolution   3.22.2-1
ii  libglib2.0-0   2.50.2-1
ii  libgtk-3-0 3.22.2-1
ii  libical2   2.0.0-0.5+b1
ii  libicu57   57.1-4
ii  libnotify4 0.7.7-1
ii  libsoup2.4-1   2.56.0-1
ii  libwebkit2gtk-4.0-37   2.14.2-1
ii  libxml22.9.4+dfsg1-2.1
ii  psmisc 22.21-2.1+b1

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-8
ii  evolution-plugins  3.22.2-1
ii  yelp   3.22.0-1

Versions of packages evolution suggests:
pn  evolution-ews   
pn  evolution-plugins-experimental  
ii  gnupg   2.1.15-4
ii  network-manager 1.4.2-2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYKo0UAAoJEKzUn4heVFJuHBsQALKYFsG+aX1GAuPBe7HM3oeK
DdPND/LMJTwctUTYalmzV0DDTb6zPdTVsXH8H3epp/8hNEDcxqT/HOkJf6Ge74K+
7CFdxybsZGU2Kp6JJxzR00vbJWmsTesq0pIQelzDrlPHDqCzhA+Edhm8BQXrt+bc
IbcthkOnAXTQPE4qO2lvtvjbRUpwbhLq2nQFQ6CpwWc2BHAjLufQvIMli1GGsi1p
EuSUSVtZsCGLmIsD4rF6YT/o2ZgCtB6kQSmhE3hC1qBYNXBci4kpA/aeR4g2HPX+
YJiRWhV8I1UexVAZOhOpJtrbEL+eJ4LzK7NCRX5xhihiSekOFTubhQ846VKnCYA3
VFRPfj1xaYJhWMj1sHakHSFF5Uhn7QloqJVWkRjyRBVsVczzt+ZmaR9n4iQBjZQx
yb+YVTROgOwLMNwn8hEDKtcI7JSG8I1XZIQmnp3mZRgL9JkNlfg4YsyvKUlNum2x
Tl35h59Z/ZMQi50hLr01oiidfcfHCFhqTE4bSiR//io26zoehkS6oID4DgR3bhYn
GiUj/oSeEiR/0A4BA4NuKKYtXyPtuUXVG68RdDLuB107JsSAeI2iXPWzPOF45qAZ
glrJg+UIvrKK9fbrdLYeYBGGLi0NtpSu3KE/caN9wPhf+KVtMlqyrrt53icaNpFB
xhscbg8L0XGaOtYh5P8K
=g9tb
-END PGP SIGNATURE-

Bug#844384: RM: 0ad [arm64] -- ROM; FTBFS on specific archs

[Vincent Cheng]

Package: ftp.debian.org
Severity: normal

Please remove 0ad on arm64. It's unlikely to be fixed by upstream
since it's caused by 3rd-party code (spidermonkey/mozjs), and time
could be better spent elsewhere since there are likely zero users of
the package on arm64 anyways.

Regards,
Vincent

Bug#844383: php-gearman: New version is missing /usr/lib/php/20151012/gearman.so

[JWM]

Package: php-gearman
Version: 1.1.2-96-ge77f981+1.1.2+-3
Severity: grave
Justification: renders package unusable

Dear Maintainer,

According to tracker.debian.org, php-gearman version php-gearman
1.1.2-96-ge77f981+1.1.2+-3 migrated to testing today.

The new package renders any gearman-using php application unusable, due to the
missing /usr/lib/php/20151012/gearman.so file.

The following warning is issued whenever I try to launch php's built-in web
server:

PHP Warning:  PHP Startup: Unable to load dynamic library
'/usr/lib/php/20151012/gearman.so' - /usr/lib/php/20151012/gearman.so: cannot
open shared object file: No such file or directory in Unknown on line 0

That warning is echoed by the Cron Daemon.

--
John




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

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

Versions of packages php-gearman depends on:
ii  php-common   1:46
ii  php7.0-cli [phpapi-20151012] 7.0.12-1
ii  php7.0-phpdbg [phpapi-20151012]  7.0.12-1

php-gearman recommends no packages.

Versions of packages php-gearman suggests:
pn  gearman-server  

-- no debconf information

Bug#840039: ITA: httpbin -- HTTP request and response service

[Luis Alfredo da Silva]

retitle 840039 ITA: httpbin — HTTP request and response service
thanks

Bug#844382: libdrm-amdgpu1: OpenCL Producer/Reader Invalid Record

[Marc Jeffrey Driftmeyer]

Package: libdrm-amdgpu1
Version: 2.4.71-1
Severity: normal

Dear Maintainer,

Testing Blender OpenCL with the RX 480 8GB and checking the status of it via 
clinfo revealed the following error in building libdrm-amdgpu1

=== CL_PROGRAM_BUILD_LOG ===
Invalid record (Producer: 'LLVM3.9.0' Reader: 'LLVM 3.8.1')  Preferred work 
group size multiple  Invalid record (Producer: 'LLVM3.9.0' Reader: 
'LLVM 3.8.1')
  Preferred / native vector sizes 

This imbalance prevents using the GPU with its GPGPU capabilities. Rebuild 
against LLVM 3.9.0 for both Producer/Reader and it will be resolved.

I haven't checked if this is an upstream error and fixed in libdrm 2.8 but I 
hope this is rectifiable.

Sincerely,

Marc J. Driftmeyer


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

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

Versions of packages libdrm-amdgpu1 depends on:
ii  libc62.24-5
ii  libdrm2  2.4.71-1

libdrm-amdgpu1 recommends no packages.

libdrm-amdgpu1 suggests no packages.

-- no debconf information

Bug#844381: mysql-workbench: Application crashes whenever it tries to connect to any database

[JWM]

Package: mysql-workbench
Version: 6.3.6+dfsg-1
Severity: normal

Dear Maintainer,

Dear Maintainer,

After installing the newly uploaded mysql-workbench 6.3.6+dfsg-1, whenever I
try to connect to any database, the application crashes with:

mysql-workbench-bin: /usr/include/boost/variant/detail/forced_return.hpp:39: T
boost::detail::variant::forced_return() [with T = const sql::SQLString*]:
Assertion `false' failed.
Aborted


Similarly, although models open properly, whenever I try to synchronize them
with a database, the application crashes again with:

** (mysql-workbench-bin:16268): WARNING **: invalid source position for
vertical gradient
mysql-workbench-bin: /usr/include/boost/variant/detail/forced_return.hpp:39: T
boost::detail::variant::forced_return() [with T = const sql::SQLString*]:
Assertion `false' failed.
Aborted

--
John



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

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

Versions of packages mysql-workbench depends on:
ii  libatkmm-1.6-1v52.24.2-2
ii  libc6   2.24-5
ii  libcairo2   1.14.6-1.1
ii  libcairomm-1.0-1v5  1.12.0-1+b1
ii  libctemplate3   2.3-3
ii  libgcc1 1:6.2.0-10
ii  libgdal20 [gdal-abi-2-1-2]  2.1.2+dfsg-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libgl1-mesa-glx [libgl1]12.0.3-3
ii  libglib2.0-02.50.2-1
ii  libglibmm-2.4-1v5   2.50.0-1
ii  libgnome-keyring0   3.12.0-1+b1
ii  libgtk2.0-0 2.24.31-1
ii  libgtkmm-2.4-1v51:2.24.5-1
ii  libmariadbclient18  10.0.28-1
ii  libmysqlcppconn7v5  1.1.4+really1.1.3-1
ii  libodbc12.3.1-5+b1
ii  libpango-1.0-0  1.40.3-3
ii  libpangocairo-1.0-0 1.40.3-3
ii  libpangomm-1.4-1v5  2.40.1-3
ii  libpcre32:8.39-2
ii  libpcrecpp0v5   2:8.39-2
ii  libpython2.72.7.12-3+b1
ii  libsigc++-2.0-0v5   2.10.0-1
ii  libstdc++6  6.2.0-10
ii  libtinyxml2.6.2v5   2.6.2-4
ii  libuuid12.29-1
ii  libvsqlitepp3v5 0.3.13-4
ii  libx11-62:1.6.3-1
ii  libxml2 2.9.4+dfsg1-2.1
ii  libzip4 1.1.2-1.1
ii  mysql-workbench-data6.3.6+dfsg-1
ii  python-mysql.connector  2.1.3-1
ii  python-paramiko 2.0.0-1
ii  python-pexpect  4.2.0-1
ii  python-pyodbc   3.0.10-2
ii  python-pysqlite22.7.0-1
ii  python2.7   2.7.12-3+b1
pn  python:any  

Versions of packages mysql-workbench recommends:
ii  mariadb-client-10.0 [virtual-mysql-client]  10.0.28-1
ii  mysql-utilities 1.6.3-1
ii  ttf-bitstream-vera  1.10-8

Versions of packages mysql-workbench suggests:
ii  gnome-keyring  3.20.0-3

-- no debconf information

Bug#844380: konsole segmentation fault after close splitted view

[Josue Ortega]

Package: konsole
Version: 4:16.08.2-2
Severity: important

Dear Maintainer,

After close splitted view all konsole instances running terminate
unexpectedly with segmentation fault.
I can reproduce this behavior splitting and closing tabs multiple times
in a row  ("ctrl + )" and "(ctrl + Shift + O)"), I know doing this in a
row is not a common use but it happens even if closing the splitted view
after a while.

Currently I can reproduce this in two different installations.

Here is the gdb backtrace:

Starting program: /usr/bin/konsole
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe4554700 (LWP 5981)]
[New Thread 0x7fffe393e700 (LWP 5982)]
Default profile name: "Intérprete de órdenes"

Thread 1 "konsole" received signal SIGSEGV, Segmentation fault.
0x744b044c in QObject::~QObject() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
(gdb) bt
#0  0x744b044c in QObject::~QObject() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x74ff6be9 in QActionGroup::~QActionGroup() () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#2  0x75c7c800 in KSelectAction::~KSelectAction() () from 
/usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5
#3  0x75c7c939 in KSelectAction::~KSelectAction() () from 
/usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5
#4  0x744a7501 in QObjectPrivate::deleteChildren() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x744b087f in QObject::~QObject() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x74ff30a9 in QAction::~QAction() () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x7504422d in QWidgetAction::~QWidgetAction() () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x75c7c821 in KSelectAction::~KSelectAction() () from 
/usr/lib/x86_64-linux-gnu/libKF5WidgetsAddons.so.5
#9  0x765e00a9 in KCodecAction::~KCodecAction() () from 
/usr/lib/x86_64-linux-gnu/libKF5ConfigWidgets.so.5
#10 0x744a7501 in QObjectPrivate::deleteChildren() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x744b087f in QObject::~QObject() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x77568c99 in Konsole::SessionController::~SessionController() () 
from /usr/lib/x86_64-linux-gnu/libkonsoleprivate.so.16
#13 0x77568cd9 in Konsole::SessionController::~SessionController() () 
from /usr/lib/x86_64-linux-gnu/libkonsoleprivate.so.16
#14 0x744a9bc0 in QObject::event(QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x74ff9b2c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x750012e1 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x7447d0e0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x7447f86d in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#19 0x744d1313 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#20 0x7fffeee437f7 in g_main_dispatch (context=0x7fffdc0016f0) at 
././glib/gmain.c:3203
#21 g_main_context_dispatch (context=context@entry=0x7fffdc0016f0) at 
././glib/gmain.c:3856
#22 0x7fffeee43a60 in g_main_context_iterate 
(context=context@entry=0x7fffdc0016f0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ././glib/gmain.c:3929
#23 0x7fffeee43b0c in g_main_context_iteration (context=0x7fffdc0016f0, 
may_block=1) at ././glib/gmain.c:3990
#24 0x744d171f in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#25 0x7447b0ca in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#26 0x7448383c in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x77bbacd8 in kdemain (argc=, argv=) 
at ./src/main.cpp:173
#28 0x778152b1 in __libc_start_main (main=0x4780 , 
argc=1, argv=0x7fffe298, init=, fini=, 
rtld_fini=, stack_end=0x7fffe288) at ../csu/libc-start.c:291
#29 0x47ba in _start ()


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

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

Versions of packages konsole depends on:
ii  kio   5.27.0-2
ii  konsole-kpart 4:16.08.2-2
ii  libc6 2.24-5
ii  libkf5completion5 5.27.0-1
ii  libkf5configcore5 5.27.0-1
ii  libkf5configgui5  5.27.0-1
ii  libkf5configwidgets5  5.27.0-1
ii  libkf5coreaddons5 5.27.0-1
ii  

Bug#843776: dpkg-buildpackage should set LC_COLLATE=C.UTF-8

[Guillem Jover]

Hi!

On Wed, 2016-11-09 at 13:43:21 +, Ian Jackson wrote:
> Package: dpkg-dev
> Version: 1.18.12

> Many package build rules, dh rules, etc., rely on shell globbing.
> This shell globbing needs to be predictable.
> 
> The output of a package build ought not to depend on the locale at
> all, really.  (This is one of the things that the reproducible builds
> people are trying to ensure.)  But we don't want to set LC_MESSAGES,
> at least, because we want people to be able to debug builds in their
> native language, as far as possible.
>
> It is difficult to imagine a situation where a honouring a user's
> LC_COLLATE during a package build would be beneficial.

Agreed.

> In practice, nonstandard LC_COLLATE values can break perfectly
> sensible looking build code.  For example, chiark-utils 5.0.0+exp1
> FTBFS in current stretch when LC_COLLATE=fr_CH.UTF-8 because of this:
>   $ touch 11 pp qq
>   $ LC_COLLATE=fr_CH.UTF-8 bash -c 'echo [!A-Z]*[!~]'
>   11
>   $
> (Interestingly, many of these FTBFS problems will be hidden if /bin/sh
> is dash, because dash does not honour locales for globbing.  This is
> clearly legal according to the spec, and probably a good decision.)
> 
> In principle this bug might be fixable by asking (almost) every
> package to set LC_COLLATE in debian/rules.  But ISTM that it would be
> much better to fix this in dpkg-buildpackage.

That would be certainly easier, but this is yet again another instance
of dpkg-buildpackage not being considered the canonical entry point
for building packages, debian/rules is. So as long as that's the case
I'm very hesitant to set yet another variable that should in principle
be set explicitly by the package itself. I know, this probably implies
lots of changes, but given past resistence on this topic, I'd rather
not go down the same path. :(

(See the NOTES section in dpkg-buildpackage(1).)

And playing devil's advocate here, arguably some of those are also
probably upstream issues that would better be fixed there. :)

> I suggest that dpkg-buildpackage should do as follows:
> 
>  * Unconditionally set one of the following
>LC_COLLATE=C.UTF-8
>LC_COLLATE=C
>Colin Watson tells me that C.UTF-8 has been in libc since
>approximately squeeze.  C is theoretically UB (!) for high-bit
>set octets but in practice works just fine (and it would be
>intolerable if it didn't).

Doing that in the packages might be fine as they can assume a Debian
distribution, but probably not for dpkg itself, as it runs on systems
were C.UTF-8 cannot be assumed to be available, and it's probably not
even supported at all!

>  * Check the effective LC_COLLATE using locale(1), and produce
>a warning if the result is not m/^C(?=\.|$)/.  (This is useful
>because some misguided user might set LC_ALL.)

Hmm, so in a way this looks nice, because it can be implemented right
away in dpkg-buildpackage regardless of the system supporting C.UTF-8
locales. But then if the conclusion is that packages need to sort this
out by themselves, it feels out of place to emit such warnings, as I
don't see why the users should not be able to select non C collation.

> In the meantime the reproducible builds folks may want to consider
> explicitly setting LC_COLLATE to something sane in their 2nd build.

I guess that depends on whether we still want to make packages
self-contained and buildable correctly just with debian/rules or
not. :)

Thanks,
Guillem

Bug#844379: ITP: django-simple-redis-admin -- Django admin panel add-on to view and delete Redis keys

[Scott Kitterman]

Package: wnpp
Severity: wishlist
Owner: Scott Kitterman 

* Package name: django-simple-redis-admin
  Version : 1.4.0
  Upstream Author : Nicholas Serra 
* URL : https://github.com/nicholasserra/django-simple-redis-admin
* License : BSD
  Programming Lang: Python
  Description : Django admin panel add-on to view and delete Redis keys

 `django-simple-redis-admin` is an addition to your Django admin panel that
 allows you to view and delete your Redis keys.
 .
 This package does not use models, so no database tables need to be created.
 Just add to INSTALLED_APPS and go.  Users must have is_superuser == True to
 view the Redis admin. No django admin logs are created with this package.

I intend to maintian this within the Debian Python Modules Team.  The upstream
tarball is weak on licensing information, but has committed a pull request I
submitted to get it clarified.  The Debian package will carry that as a patch
until the next upstream release.

Bug#840516: doesn't work with django 1.10

[Joey Hess]

I suppose this is the problem that this bug report is about:

root@ia-bak:/usr/local/propellor# graphite-manage 
Traceback (most recent call last):
  File "/usr/bin/graphite-manage", line 15, in 
execute_from_command_line(sys.argv)
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 367, in execute_from_command_line
utility.execute()
  File "/usr/lib/python2.7/dist-packages/django/core/management/__init__.py", 
line 341, in execute
django.setup()
  File "/usr/lib/python2.7/dist-packages/django/__init__.py", line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/lib/python2.7/dist-packages/django/apps/registry.py", line 108, in 
populate
app_config.import_models(all_models)
  File "/usr/lib/python2.7/dist-packages/django/apps/config.py", line 199, in 
import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/python2.7/dist-packages/graphite/events/models.py", line 6, in 

from tagging.managers import ModelTaggedItemManager
  File "/usr/lib/python2.7/dist-packages/tagging/managers.py", line 8, in 

from tagging.models import Tag, TaggedItem
  File "/usr/lib/python2.7/dist-packages/tagging/models.py", line 10, in 

from django.contrib.contenttypes import generic
ImportError: cannot import name generic

Downgrading python-django to 1.9.8 and python-django-tagging to 0.4 did clear
this up.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#844375: mu4e: can no longer store org-mode links

[Norbert Preining]

tags 844375 + fixed-upstream
thanks

Hi Olaf,

> As of this morning's upgrade of org-mode to 9.0, org-mu4e no longer

Yes, this is known and fixed in upstream.

Can you try the attached patch and see if that helps? (Sorry, not using
org mode and mu4e, so I cannot really test it).

If the patch works I can make an intermediate release with this fixed,
but I really would like to see an upstream release ;-)

Thanks

Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13
diff --git a/mu4e/org-mu4e.el b/mu4e/org-mu4e.el
index cbb1697..4691614 100644
--- a/mu4e/org-mu4e.el
+++ b/mu4e/org-mu4e.el
@@ -117,16 +117,14 @@ Example usage:
 :description (funcall org-mu4e-link-desc-func msg))
 link
 
-(org-add-link-type "mu4e" 'org-mu4e-open)
-(add-hook 'org-store-link-functions 'org-mu4e-store-link)
-
 ;; org-add-link-type is obsolete as of org-mode 9.
 ;; Instead we will use the org-link-set-parameters method
 (if (fboundp 'org-link-set-parameters)
 (org-link-set-parameters "mu4e"
 			 :follow #'org-mu4e-open
-			 :store #'org-mu4e-store-link))
-
+			 :store #'org-mu4e-store-link)
+  (org-add-link-type "mu4e" 'org-mu4e-open)
+  (add-hook 'org-store-link-functions 'org-mu4e-store-link))
 
 (defun org-mu4e-open (path)
   "Open the mu4e message (for paths starting with 'msgid:') or run

Bug#844377: fai-client: Please allow installing packages with apt's -t option

[Afif Elghraoui]

Package: fai-client
Version: 5.2
Severity: wishlist

The FAI guide says the following about pulling in packages from a
non-default release:

~~~
If you like to install packages from another release than the default, you
can append the release name to the package name like in
openoffice.org/etch-backports. You can also specify a certain version like
apt=0.3.1
~~~

However, it is often necessary to get a package and at least some of its
available dependencies from backports, and it is not practical to have
to track and specify each one to allow the minimum required version to
be pulled in. In such cases, there is a significant difference between

  aptitude -t jessie-backports install 

and

  aptitude install /jessie-backports


Would it be possible to add an option similar to how there is
aptitude-r, or a
way to add options to the package installation command line that would allow
users to specify them for a certain set of packages?

Many thanks and regards
Afif

-- 
Afif Elghraoui
Laboratory for Pathogenesis of Clinical Drug Resistance and Persistence
San Diego State University
Alvarado Medical Center
6367 Alvarado Court, Suite 206
San Diego, CA 92120
p. 858-222-0454
http://tuberculosis.sdsu.edu

Bug#844376: caja-actions: Uses deprecated libunique3

[Michael Biebl]

Source: caja-actions
Version: 1.8.1-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libunique3-removal

Hi,

your package caja-actions declares a build-dependency on
libunique-3.0-dev or has a dependency on libunique-3.0-0.

The libunique3 library is in maintenance mode and its usage is strongly
discouraged [1].  Our plan is to remove libunique3 from the archive so
it is not released with stretch.

Applications should use the GtkApplication class provided by GTK+ 3.0.
Under [2] you will find a porting guide for migrating from using Unique
to GApplication or GtkApplication.


On behalf of the Debian GNOME team,

Michael Biebl

[1] https://wiki.gnome.org/Attic/LibUnique
[2]
https://developer.gnome.org/gtk3/3.20/gtk-migrating-unique-GtkApplication.html



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

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

Bug#844375: mu4e: can no longer store org-mode links

[Olaf Meeuwissen]

Package: mu4e
Version: 0.9.16-1
Severity: normal

Dear Maintainer,

As of this morning's upgrade of org-mode to 9.0, org-mu4e no longer
works.  Whenever I try to store a link I get

  No method for storing a link from this buffer

This happens in the header as well as in the message view.

The org-mu4e.el code mentions it assumes 8.x so this is probably
something for upstream.

Seeing that I rely quite heavily on this functionality, I was tempted to
make this a Severity: important ...

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mu4e depends on:
ii  dpkg1.18.10
ii  emacsen-common  2.0.8
ii  maildir-utils   0.9.16-1+b1

mu4e recommends no packages.

mu4e suggests no packages.

-- no debconf information

Hope this helps,
-- 
Olaf Meeuwissen, LPIC-2   FLOSS Engineer -- EPSON AVASYS CORPORATION
   Free Software Foundation Associate Member since 2004-01-27
Support Free Software  https://my.fsf.org/donate
Join the Free Software Foundationhttps://my.fsf.org/join

Bug#732056: Info received (netperf: Patch does not work if using systemd)

[Nye Liu]

Disregard, I spelled "no" as "NO" in /etc/default/netperf

Note: it is case sensitive :)

Bug#732056: netperf: Patch does not work if using systemd

[Nye Liu]

Package: netperf
Version: 2.6.0-2
Followup-For: Bug #732056

The recommended patch does not work if running systemd.

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

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

Versions of packages netperf depends on:
ii  libc6  2.24-1

netperf recommends no packages.

netperf suggests no packages.

-- Configuration Files:
/etc/default/netperf changed [not included]
/etc/init.d/netperf changed [not included]

-- no debconf information

Bug#838683: [Debian-science-sagemath] widgetsnbextension situation

[Ximin Luo]

Ximin Luo:
> Ximin Luo:
>> To install it yourself "the upstream way" completely from source (i.e. what 
>> we need to put in d/rules), see
>>
>> https://github.com/ipython/ipywidgets/blob/5.2.2/docs/source/dev_install.md
>>
> 
> I can confirm that the upstream instructions do work to regenerate 
> widgetsnbextension/static/extension.js from 
> https://pypi.python.org/pypi/widgetsnbextension/1.2.6
> 
> However we're going to have a hard time recreating it in Debian. I went 
> through this file and saw the "real dependencies". scriptjs seems to not be 
> needed, but the others are.
> 
> There are 56 modules (0-55) that webpack concatenates together, they are:
> 
> [..]

I just realised you can do this:

~/widgetsnbextension-1.2.6/widgetsnbextension/static$ python -m json.tool 
extension.js.map | less -S
{
"file": "extension.js",
"mappings": ";;AACA;;AAEA;AACA;;AAEA;AACA;AACA;;AAEA;AACA;AACA,u[..]
"names": [],
"sourceRoot": "",
"sources": [
"webpack:///webpack/bootstrap f5345dd1af7cf96a8788",
"webpack:///./src/extension.js",
"webpack:///./src/manager.js",
"webpack:///./~/underscore/underscore.js",
"webpack:///./~/backbone/backbone.js",
"webpack:///./~/jquery/dist/jquery.js",
"webpack:///./~/jupyter-js-widgets/src/index.js",
"webpack:///./~/jupyter-js-widgets/src/jquery.js",
"webpack:///./~/jquery-ui/jquery-ui.js",
"webpack:///./~/bootstrap/dist/js/npm.js",
"webpack:///./~/bootstrap/js/transition.js",
"webpack:///./~/bootstrap/js/alert.js",
"webpack:///./~/bootstrap/js/button.js",
"webpack:///./~/bootstrap/js/carousel.js",
[..]
"webpack:///./~/jupyter-js-widgets/css/widgets.min.css",
"webpack:///./~/css-loader/lib/css-base.js",
"webpack:///./~/style-loader/addStyles.js"
],
"sourcesContent": [
" \t// The module cache\n \tvar installedModules = {};\n\n \t// [..]
"// Copyright (c) Jupyter Development Team.\n// Distributed unde[..]
"// Copyright (c) Jupyter Development Team.\n// Distributed unde[..]
[..]
"exports = module.exports = require(\"./../../css-loader/lib/css[..]
"/*\r\n\tMIT License http://www.opensource.org/licenses/mit-lice[..]
"/*\r\n\tMIT License http://www.opensource.org/licenses/mit-lice[..]
],
"version": 3
}

Perhaps we can use this information to regenerate extension.js without using 
webpack itself. Julien, have you seen anything approximating this approach 
before?

I will probably need help getting this done by Dec 5 (to have a chance of this 
passing NEW). We might be able to get away with putting

webpack/bootstrap (the top part of extension.js)
process/browser.js
css-loader/lib/css-base.js
style-loader/addStyles.js

in debian/missing-sources/ since they are small, but we will have to package 
d3-format and html2canvas "properly". d3-format looks fairly easy but 
html2canvas is more annoying and will need browserify; only browserify-lite is 
in Debian.

Then after we have all the files listed above (in "sources"), it's just a 
matter of hacking up a sed script or something to reconstruct extension.js from 
them. That shouldn't be too hard.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#838683: [Debian-science-sagemath] widgetsnbextension situation

[Ximin Luo]

Ximin Luo:
> Julien Puydt:
>> Can you remind us what the list of necessary javascript looks like?
> 
> See
> 
> https://github.com/ipython/ipywidgets/blob/5.2.2/jupyter-js-widgets/package.json
> https://github.com/ipython/ipywidgets/blob/5.2.2/widgetsnbextension/package.json
> 
> I looked through the dependencies, if I remember right Debian has all of them 
> except:
> 
> "d3-format": "^0.5.1",
> "scriptjs": "^2.5.8",
> "html2canvas": "^0.5.0-beta4",
> 
> I did not yet look at the devDependencies.
> 
> To install it yourself "the upstream way" completely from source (i.e. what 
> we need to put in d/rules), see
> 
> https://github.com/ipython/ipywidgets/blob/5.2.2/docs/source/dev_install.md
> 

I can confirm that the upstream instructions do work to regenerate 
widgetsnbextension/static/extension.js from 
https://pypi.python.org/pypi/widgetsnbextension/1.2.6

However we're going to have a hard time recreating it in Debian. I went through 
this file and saw the "real dependencies". scriptjs seems to not be needed, but 
the others are.

There are 56 modules (0-55) that webpack concatenates together, they are:

External:
2: underscore
3: backbone 1.3.3
4: jquery
7: jquery-ui
8: commonjs/grunt magic, easy to recreate manually
9-20: bootstrap 3.3.6 (transition, alert, button, carousel, collapse, dropdown, 
modal, tooltip, popover, scrollspy, tab, affix; all in Debian as v3.3.7)
24: backbone 1.2.0, LOL
25: node-semver
*26: stub file from node-process, "shim for using process in browser"
*38: d3format
*45: html2canvas
52: possibly node-style-loader, not sure
*54: node-css-loader
*55: node-style-loader

*not in Debian

Local, part of juypter-js-widgets / nbwidgetsextension:
0: local code
1: local code
5: local code
6: local code
21-23: -- local code 
27: jupyter-js-widgets's package.json
28-37: local code
39-44: local code
46-48: local code
49: widgetsnbextension's package.json
50, 51: local code
53: local code, minified version of widgets.css

> widgetsnbextension@1.2.0 build /home/infinity0/ipywidgets/widgetsnbextension
> webpack

Hash: eba3724d55e00a80e9ec
Version: webpack 1.13.3
Time: 2533ms
   Asset Size  Chunks Chunk Names
extension.js  1.44 MB   0  [emitted]  main
extension.js.map  1.75 MB   0  [emitted]  main
   [0] ./src/extension.js 3.02 kB {0} [built]
   [1] ./src/manager.js 26.2 kB {0} [built]
  [46] ./src/progress-modal.js 3.23 kB {0} [built]
  [47] ./src/save_state.js 1.11 kB {0} [built]
  [48] ./src/embed_widgets.js 2.01 kB {0} [built]
  [50] ./src/widgetarea.js 5.1 kB {0} [built]
  [51] ./src/widget_output.js 2.28 kB {0} [built]
+ 49 hidden modules

There is also ipywidgets.git/jupyter-js-widgets/dist/embed.js which is 74 
modules, which I haven't yet analysed. We don't strictly need that for 
widgetsnbextension; for SageMath we could just omit the jupyter-js-widgets 
binary package.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#844374: cmake: FTBFS on hurd-i386: undefined reference to `uv_fs_event_init'

[Samuel Thibault]

Samuel Thibault, on Tue 15 Nov 2016 02:09:59 +0100, wrote:
> Could you consider applying the attached patch in the meanwhile, so that
> packages built with cmake are not all blocked by this issue?

Oops, sorry, in the meanwhile I had worked on another patch, here is the
proper patch file.

Samuel
--- debian/rules.original   2016-11-14 23:38:09.0 +
+++ debian/rules2016-11-14 23:38:11.0 +
@@ -35,6 +35,9 @@
 ifeq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
$(call $(flag_action),BUILD_QtDialog,ON,"Build Qt GUI")
 endif
+ifeq ($(DEB_HOST_ARCH_OS),hurd)
+   $(call $(flag_action),CMAKE_USE_LIBUV,0,"Do not use libuv")
+endif
 #  $(call $(flag_action),BUILD_DOCUMENTATION,ON)
 
 $(BUILD_FLAGS_FILE): flag_action := set_build_flag

Bug#844374: cmake: FTBFS on hurd-i386: undefined reference to `uv_fs_event_init'

[Samuel Thibault]

Package: cmake
Version: 3.7.0-1
Severity: important
Tags: patch

Hello,

It seems the newer version of cmake uses libuv, but that is not ported
to GNU/Hurd yet, it needs some work.

Could you consider applying the attached patch in the meanwhile, so that
packages built with cmake are not all blocked by this issue?

Samuel

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

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

Versions of packages cmake depends on:
ii  cmake-data3.6.2-2
ii  dpkg  1.18.10
ii  libarchive13  3.2.1-5
ii  libc6 2.24-5
ii  libcurl3  7.50.1-1
ii  libexpat1 2.2.0-1
ii  libgcc1   1:7-20161112-1
ii  libjsoncpp1   1.7.4-3
ii  libstdc++67-20161112-1
ii  procps2:3.3.12-2
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages cmake recommends:
ii  gcc   4:6.1.1-1
ii  make  4.1-9

Versions of packages cmake suggests:
pn  codeblocks   
pn  eclipse  
pn  ninja-build  

-- no debconf information

-- 
Samuel
Anyone who thinks UNIX is intuitive should be forced to write 5000 lines of 
code using nothing but vi or emacs. ACK!
(Discussion in comp.os.linux.misc on the intuitiveness of commands, especially
Emacs.)
commit 89d914869bb0802d6148fdb4c2bac83ec1fe15c0
Author: Richard Braun 
Date:   Tue Nov 8 17:36:27 2016 +0100

Fix experimental_vm_allocate_contiguous to wire down pages early

diff --git a/vm/vm_user.c b/vm/vm_user.c
index 597d7a3..403c7ee 100644
--- a/vm/vm_user.c
+++ b/vm/vm_user.c
@@ -509,6 +509,7 @@ kern_return_t 
experimental_vm_allocate_contiguous(host_priv, map, result_vaddr,
 */
pages[i].busy = FALSE;
vm_page_insert([i], object, vm_page_ptoa(i));
+   vm_page_wire([i]);
}
 
vm_page_unlock_queues();

Bug#844373: ros-image-common: FTBFS (incompatible build-dependencies)

[Santiago Vila]

Package: librospack-dev,libgtest-dev,src:ros-image-common
Severity: serious

Dear maintainer:

I tried to build ros-image-common in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
Unpacking librospack-dev (2.3.1-1+b1) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-dJJuDK/111-librospack-dev_2.3.1-1+b1_amd64.deb (--unpack):
 trying to overwrite '/usr/include/gtest/gtest-death-test.h', which is also in 
package libgtest-dev:amd64 1.7.0-4
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


(I can provide a full build log if required).

Please do agree on which package is to blame for this...

I see that both librospack-dev and libgtest-dev contain gtest-death-test.h.

If it's ok that they both contain such file, they should conflict at
each other (bug in those packages), but then ros-image-common would
continue to be unbuildable anyway (bug still in ros-image-common).

OTOH, if one of the packages librospack-dev or libgtest-dev should not
contain the file, then please reassign to the package at fault and
also send an "affects" command to the control address, so that we can
still see that this bug affects src:ros-image-common in its BTS web page.

Sorry that I can't tell for sure which one of those cases is the truth,
I just detected this problem by trying to build ros-image-common.

Thanks.

Bug#838282: ITP: gssproxy -- A privilege separation daemon for GSSAPI

[Robbie Harwood]

Package: wnpp
Followup-For: Bug #838282
Owner: Robbie Harwood 
Control: retitle -1 ITP: gssproxy -- A privilege separation daemon for GSSAPI

* Package name: gssproxy
  Version : 0.5.1
  Upstream Author : The GSS-PROXY contributors
* URL : https://fedorahosted.org/gss-proxy/
* License : MIT
  Programming Lang: C
  Description : A privilege separation daemon for GSSAPI

gssproxy (https://fedorahosted.org/gss-proxy/) is an abstraction layer
(typically an application) between a GSS client and the credentials being
used.

In addition to the NFS use case Sven mentions, gssproxy will be useful to
freeIPA.

I am an upstream maintainer for this project.

Bug#783596: resolvconf /e/n/i dns-* option only works in last of homonymous iface def'ns

[Chris Francy]

Hi, Sorry to be a bother, but it seems like my suggestion got
overlooked for this issue.  Perhaps because the bug is flagged as
wontfix?  My suggestion would permit you to have resolveconf
configuration for one interface, not be overwritten by interfaces with
no resolveconf configuration.  Am I missing something obvious reason
why a patch like this shouldn't be applied?

---
 debian/resolvconf.000resolvconf.if-up | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/resolvconf.000resolvconf.if-up
b/debian/resolvconf.000resolvconf.if-up
index f799371..d4b47d0 100755
--- a/debian/resolvconf.000resolvconf.if-up
+++ b/debian/resolvconf.000resolvconf.if-up
@@ -43,5 +43,8 @@ for OPT in $IF_DNS_NAMESERVER ; do
 done
 IFS="$STANDARD_IFS"

+# if we don't  have any options, don't do anything.
+test -n "$R" || exit 0
+
 echo -n "$R" | /sbin/resolvconf -a "${IFACE}.${ADDRFAM}" || :
-- 

Thanks for reviewing this.

Chris Francy

Bug#792622: missing licenses in debian/copyright

[Samuel Thibault]

Control: tags -1 + pending

Hello,

Kalle Olavi Niemitalo, on Sun 06 Nov 2016 21:06:48 +0200, wrote:
> Here is what I have so far.

It seems I never received that mail for some reason :/

> See "License: UNKNOWN-OSF" and "License: UNKNOWN-Berkeley"
> for some newly found problems.

Well, these should be fixed upstream actually.

>  Building Debian binary packages does not read the file.

Let's not try to distinguish these, it looks to me like it brings
more overhead than good.  Of course, if we have some files which pose
problem, such notice can be useful to to know that perhaps we could
simply drop them from upstream even.

> It might be good to merge the paragraphs that list the same
> licenses and the same copyright holders but different years.

Yes, please.  I'd even say merge copyright holders.  I personally really
don't want to maintain unmerged lists of holders and years, I don't see
the point of doing it for Debian: what Debian cares about is licences,
and crediting the people is good, but the detailed credit is not
important enough to spend time on it.

For now, I'll upload a very simplified version of your findings with a
newer upstream snapshot, which I believe will cover ftp-master's main
concerns: no GPL-2 / GPL-3 conflict any more, and doc/, pcmcia/, and
xen/ licences.

Samuel

Bug#844372: Installing/updating to syslog-ng 3.8.1-5 broken in Debian Testing

[VDR User]

Package: syslog-ng
Version: 3.8.1-5

I tried upgrading syslog-ng and it failed. I then tried installing it
cleanly on a different box and that failed as well. Both systems are
running Debian Testing, stable kernels 4.8.6 and 4.8.7, libc 2.24-5.

It seems this problem has happened before with an earlier version as well:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833283

$ sudo apt-get install syslog-ng
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libbson-1.0-0 libdbi1 libesmtp6 libevtlog0 libhiredis0.13 libivykis0
libmongoc-1.0-0 libnet1 libprotobuf-c1 librabbitmq4 libriemann-client0
libyajl2
  syslog-ng-core syslog-ng-mod-add-contextual-data syslog-ng-mod-amqp
syslog-ng-mod-geoip syslog-ng-mod-graphite syslog-ng-mod-journal
syslog-ng-mod-json
  syslog-ng-mod-mongodb syslog-ng-mod-python syslog-ng-mod-redis
syslog-ng-mod-riemann syslog-ng-mod-smtp syslog-ng-mod-sql
syslog-ng-mod-stomp
Suggested packages:
  rabbitmq-server graphite-web mongodb-server libdbd-mysql
libdbd-pgsql libdbd-sqlite3 activemq
The following NEW packages will be installed:
  libbson-1.0-0 libdbi1 libesmtp6 libevtlog0 libhiredis0.13 libivykis0
libmongoc-1.0-0 libnet1 libprotobuf-c1 librabbitmq4 libriemann-client0
libyajl2
  syslog-ng syslog-ng-core syslog-ng-mod-add-contextual-data
syslog-ng-mod-amqp syslog-ng-mod-geoip syslog-ng-mod-graphite
syslog-ng-mod-journal
  syslog-ng-mod-json syslog-ng-mod-mongodb syslog-ng-mod-python
syslog-ng-mod-redis syslog-ng-mod-riemann syslog-ng-mod-smtp
syslog-ng-mod-sql
  syslog-ng-mod-stomp
0 upgraded, 27 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,556 kB of archives.
After this operation, 4,750 kB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://mirrors.accretive-networks.net/debian testing/main i386
libnet1 i386 1.1.6+dfsg-3 [61.8 kB]
Get:2 http://mirrors.accretive-networks.net/debian testing/main i386
libyajl2 i386 2.1.0-2 [24.2 kB]
Get:3 http://mirrors.accretive-networks.net/debian testing/main i386
libevtlog0 i386 0.2.12-7 [12.0 kB]
Get:4 http://mirrors.accretive-networks.net/debian testing/main i386
libivykis0 i386 0.36.2-1 [25.9 kB]
Get:5 http://mirrors.accretive-networks.net/debian testing/main i386
libbson-1.0-0 i386 1.4.2-1 [56.5 kB]
Get:6 http://mirrors.accretive-networks.net/debian testing/main i386
libdbi1 i386 0.9.0-4 [34.1 kB]
Get:7 http://mirrors.accretive-networks.net/debian testing/main i386
libesmtp6 i386 1.0.6-4+b1 [60.0 kB]
Get:8 http://mirrors.accretive-networks.net/debian testing/main i386
libhiredis0.13 i386 0.13.3-2 [30.1 kB]
Get:9 http://mirrors.accretive-networks.net/debian testing/main i386
libmongoc-1.0-0 i386 1.4.1-1 [135 kB]
Get:10 http://mirrors.accretive-networks.net/debian testing/main i386
libprotobuf-c1 i386 1.2.1-1+b1 [25.8 kB]
Get:11 http://mirrors.accretive-networks.net/debian testing/main i386
librabbitmq4 i386 0.8.0-1 [42.4 kB]
Get:12 http://mirrors.accretive-networks.net/debian testing/main i386
libriemann-client0 i386 1.9.1-1 [20.7 kB]
Get:13 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-journal i386 3.8.1-5 [40.3 kB]
Get:14 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-core i386 3.8.1-5 [478 kB]
Get:15 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-sql i386 3.8.1-5 [45.1 kB]
Get:16 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-mongodb i386 3.8.1-5 [43.0 kB]
Get:17 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-json i386 3.8.1-5 [38.9 kB]
Get:18 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng all 3.8.1-5 [26.1 kB]
Get:19 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-add-contextual-data i386 3.8.1-5 [37.7 kB]
Get:20 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-amqp i386 3.8.1-5 [47.9 kB]
Get:21 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-geoip i386 3.8.1-5 [34.4 kB]
Get:22 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-graphite i386 3.8.1-5 [29.9 kB]
Get:23 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-python i386 3.8.1-5 [52.4 kB]
Get:24 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-redis i386 3.8.1-5 [36.0 kB]
Get:25 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-riemann i386 3.8.1-5 [39.0 kB]
Get:26 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-smtp i386 3.8.1-5 [39.0 kB]
Get:27 http://mirrors.accretive-networks.net/debian testing/main i386
syslog-ng-mod-stomp i386 3.8.1-5 [40.2 kB]
Fetched 1,556 kB in 0s (1,644 kB/s)
Selecting previously unselected package libnet1:i386.
(Reading database ... 175439 files and directories currently installed.)
Preparing to unpack 

Bug#840073: Bug: #840073 Patch to fix upgrade from jessie to stretch/testing

[Adam Borowski]

On Tue, Nov 08, 2016 at 07:14:12PM +0100, Svante Signell wrote:
> Hi,
> 
> looking at the problem and setting up piuparts, and using a local repository, 
> I
> think the problem with upgrade from jessie to stretch/sid is solved with the
> attached patch.
> 
> The following has been tested:
>  * upgrade from stretch (0.21-3) to sid (0.21-4)
>  * upgrade from jessie (0.13.1-4) to sid (0.21-4)
>  * upgrade from kessie (0.13.1-4) to stretch/testing (0.21-4)
> piuparts logs are available on request.
> 
> I need somebody doing an upload of the new package, of course modifying the
> changelog accordingly: Adam/Benda?

I'm uncomfortable applying patches I don't fully understand, but as Benda
is still busy, I guess I need to if the package is supposed to be in shape
for stretch -- the freeze is close.

> +++ openrc-0.21/debian/openrc.preinst 2016-11-08 18:24:06.579859726 +0100
> @@ -0,0 +1,27 @@
> +# Remove a no-longer used conffile

> +case "$1" in
> +install|upgrade)
> +if dpkg --compare-versions "$2" le "$LASTVERSION"; then
> +rm_conffile openrc "/etc/pkg/conf.1"
> +rm_conffile openrc "/etc/pkg/conf.2"
> +fi
> +esac

You failed to fill in the placeholders: $LASTVERSION is "", /etc/pkg/conf.1
and /etc/pkg/conf.2 don't exist.  Thus, /etc/init.d/transit doesn't get
removed -- your tests succeeded only because leaving a dangling but owned
conffile isn't a fatal error.


Meow!
-- 
A true bird-watcher waves his tail while doing so.

Bug#842815: closed by Andreas Tille <ti...@debian.org> (Bug#842815: fixed in libsis-jhdf5-java 14.12.6-1)

[Gilles Filippini]

On Mon, 14 Nov 2016 22:15:18 +0100 Gilles Filippini  wrote:
> Control: reopen -1
> 
> Andreas Tille a écrit le 14/11/2016 à 21:15 :
> > Hi Gilles,
> > 
> > On Mon, Nov 14, 2016 at 07:32:04PM +0100, Gilles Filippini wrote:
> >> Debian Bug Tracking System a écrit le 14/11/2016 à 16:09 :
> >>> This is an automatic notification regarding your Bug report
> >>> which was filed against the src:libsis-jhdf5-java package:
> >>>
> >>> #842815: libsis-jhdf5-java: Please support HDF5 1.10
> >>>
> >>> It has been closed by Andreas Tille .
> >>>
> >>> 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 Andreas Tille 
> >>>  by
> >>> replying to this email.
> >>
> >> Thank you for this upload. Have you tested the build against hdf5-1.10
> >> in experimental?
> > 
> > Hmmm, sorry, no - I just made sure that the *sid* pbuilder environment
> > is instaling hdf5-1.10.
> 
> Ah. The fact that HDF5 1.8.16 builds libhdf5-10 might be confusing. HDF5
> 1.10 builds libhdf5-100 and is still in experimental.
> 
> > If this is not sufficient please reopen ...
> > and please give some helping hint if the package might not build
> > properly.  Otherwise I have no idea what to do - patches are very
> > welcome.
> 
> There are at least 3 majors changes brought by HDF5 1.10:
> 1- The widely used hid_t datatype is now uint64_t (instead of int)
> 2- The java wrapper library is now part of the HDF5 source tree
> 3- HDF5Exception is now a checked exception.
> 
> (2) and (3) might be worked out with a new upload of hdf5, to ship the
> java wrapper library packages, patched to define HDF5Exception as an
> unchecked exception. I'd rather wait after the transition.
> 
> (1) Involves patching libsis-jhdf5-java.

I've spent some time trying to figure it out, and I'm afraid this is a
huge task I can't afford working on.

> The best option would be a new upstream release. Do you know their
> schedule wrt HDF5 1.10?

If there is a risk that libsis-jhdf5-java won't be ready for stretch,
then we could easily avoid the fastqc removal by disabling the fast5
file format support. It should be easy enough for anyone to convert
fast5 files to fastq using e.g. poretools.
What do you think?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#840618: closed by Samuel Thibault <sthiba...@debian.org> (Bug#840618: fixed in at-spi2-core 2.22.0-3)

[Samuel Thibault]

Control: tags -1 + pending
Hello,

Iain Lane, on Mon 14 Nov 2016 17:06:18 +, wrote:
> On Tue, Nov 01, 2016 at 12:06:06AM +, Debian Bug Tracking System wrote:
> >* patches/register-client-early: Register at-spi-bus-launcher early, to
> >  avoid deadlock with gnome-session (Closes: Bug#840618).
> 
> Doesn't this patch break registering with the session? Now you call
> register_client before sm_proxy is set - how is that supposed to work?

Ah, sorry, I misread the upstream commit that introduced the bug, and
put the registration a bit too early indeed.

> I don't know what the initial problem was - why was the bus launcher failing 
> to
> register with gnome-session?

See the story on

https://lists.linuxfoundation.org/pipermail/accessibility-atspi/2016-October/000714.html

Basically at-spi-bus-launcher is waiting, before registering itself, for
an event that gnome-session will emit only after at-spi-bus-launcher has
registered... Upstream hasn't answered so far.

Samuel

Bug#844195: contributors.debian.org: Data export API

[Ben Finney]

On 13-Nov-2016, Enrico Zini wrote:

> To get some contributor data, for example for the perl team, log into alioth
> and run: dc-tool --mine 
> /srv/home/users/tincho/python-debiancontributors/pkg-perl.conf > file.json

According to the ‘dc-tool(1)’ manual page, that command says to “mine”
some data using the specified configuration file.

When I run it on Alioth, it crashes:

=
$ dc-tool --mine /srv/home/users/tincho/python-debiancontributors/pkg-perl.conf 
> file.json
Traceback (most recent call last):
  File "/usr/bin/dc-tool", line 90, in 
miner.scan()
  File "/usr/lib/python2.7/dist-packages/debiancontributors/datamine.py", line 
141, in scan
for ident, begin, until, url in s["scanner"].scan():
  File "/usr/lib/python2.7/dist-packages/debiancontributors/scanners/git.py", 
line 91, in scan
for line in stream_command_stdout(cmd):
  File 
"/usr/lib/python2.7/dist-packages/debiancontributors/scanners/utils/proc.py", 
line 100, in stream_command_stdout
raise RuntimeError("{} exited with status {}: {}".format(cmd[0], result, 
lines.stderr.getvalue().strip()))
RuntimeError: git exited with status 128: fatal: bad default revision 'HEAD'
=

-- 
 \ “Experience is that marvelous thing that enables you to |
  `\   recognize a mistake when you make it again.” —Franklin P. Jones |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#828236: Bug#844160: openssl 1.1 and apache2

[Russ Allbery]

Stefan Fritsch  writes:

> I must admit that I did not think of php when doing that change, sorry. 

> On the other hand, shibboleth-sp2 also build-depends on apache2-dev and there 
> have been some indications that shibboleth won't be switching to openssl 1.1 
> for stretch. See https://lists.debian.org/debian-release/2016/11/msg00024.html

It turns out that Shibboleth will be okay if Apache goes to 1.1.  The
Shibboleth code that goes into Apache is isolated from the OpenSSL use
inside Shibboleth, so we can keep building Shibboleth against 1.0 and
Apache can go to 1.1 and all the pieces are happy.  (The OpenSSL work is
done in a separate daemon, shibd, that the Apache module talks to.)

(Not that this solves all the problems, but just FYI.)

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

Bug#843510: linux-image-4.8.0-rc8-amd64-unsigned: Task timeout when workstation is connected

[Ben Hutchings]

[Please reply to all.]

On Mon, 2016-11-14 at 23:33 +0100, Alexandre Russo wrote:
> Hello,
> It seems i don't have the problem with linux-image-4.9.0-rc3-amd64-
> unsigned

But has it also been fixed in 4.8.5-1?  Or 4.8.7-1, which is going into
unstable today?

Ben.

> Thank you 
> Alexandre
> Le dimanche 13 novembre 2016 à 03:44 +, Ben Hutchings a écrit :
> > Control: tag -1 moreinfo
> > 
> > On Mon, 2016-11-07 at 09:51 +0100, Alexandre wrote:
> > > Package: src:linux
> > > Version: 4.8~rc8-1~exp1
> > > Severity: grave
> > > Justification: renders package unusable
> > 
> > [...]
> > 
> > Please re-test with the current version 4.8.5-1.
> > 
> > Ben.
-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.



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

Bug#844122: linux: allow disabling linux-source-$ver build via config

[Luca Boccassi]

On Sat, 2016-11-12 at 23:01 +0100, Bastian Blank wrote:
> On Sat, Nov 12, 2016 at 06:18:47PM +, Luca Boccassi wrote:
> > Building linux-source-X.Y takes about ~10 minutes, and in the context
> > of a continuous integration build where the result is tested and then
> > discarded it is only a waste of time.
> 
> Could you explain a bit more what you are doing?  Compressing the debug
> packages needs way more time already.
> 
> Regards,
> Bastian

Hi,

Yes indeed, and the debug packages can be disabled already. That's ~10
minutes per build. Also most of the other packages can already be
disabled, just not the source one.

Being able to disable the source allows us to shave ~5 additional
minutes per build. As I wrote it's in the context of a CI system that
builds kernel many times per day as we work on it.

I thought it could be a useful option for others as well so I'm sharing
it, in case it could be.

-- 
Kind regards,
Luca Boccassi


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

Bug#844371: chicken: New upstream version

[Ivan Raikov]

Source: chicken
Version: 4.10.0
Severity: normal

Version 4.11.0 of the CHICKEN system has beem available for some time:


http://code.call-cc.org/releases/4.11.0/NEWS

Please consider packaging this version, as it contains some important changes
in the runtime representation. Thanks!



-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500,
'xenial-backports'), (500, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#840999: calibre: New Upstream Release

[Martin Pitt]

Control: tag -1 pending

Hello Ritesh,

Ritesh Raj Sarraf [2016-10-16 23:58 +0530]:
> The version of calibre in Debian is showing a little bit of its age.
> Please find attached a patch, which should update it to 2.70.0.

Thanks! To avoid these long blocks in the future, I converted the
packaging from bzr to git-buildpackage and put it on collab-maint:

  https://anonscm.debian.org/cgit/collab-maint/calibre.git

I applied your patch (split in two, for the Datejs download URL),
works fine! I'm not sure if the "don't build in parallel on MIPS"
patch is really obsolete, but let's give it a try. If it still fails,
I'll reapply the patch ported to the current upstream version (still
the same code, just in a different file now).

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Bug#754248: [Python-modules-team] Bug#754248: python-virtualenv: Error when attempting to create a python2.6 virtualenv

[Arthur de Jong]

On Mon, 2016-11-14 at 10:28 -0500, Barry Warsaw wrote:
> On Nov 13, 2016, at 10:14 PM, Arthur de Jong wrote:
> > I just ran into this today and I can confirm that the above fix
> > allows me to move forward with a Python 2.6 virtualenv. Can you fix
> > this for unstable?
> 
> Yes, I'll upload this fix to unstable momentarily.

Thanks.

Just managed to get everything working with the python2.6 from wheezy :)

-- 
-- arthur - art...@arthurdejong.org - https://arthurdejong.org/ --


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

Bug#844370: beignet-opencl-icd: New upstream bugfix version 1.2.1

[Achim Schaefer]

Package: beignet-opencl-icd
Version: 1.2.0-3
Severity: normal
Tags: upstream

Dear Maintainer,

there is a new upstream bugfix version availble.

Please package the new vrsion.

-- Package-specific info:
Graphics hardware:
Providers: number : 1
Provider 0: id: 0x47 cap: 0xf, Source Output, Sink Output, Source Offload, Sink 
Offload crtcs: 3 outputs: 5 associated providers: 0 name:modesetting
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Extended renderer info (GLX_MESA_query_renderer):
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Desktop 
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v3/4th 
Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06)

Processor:
Architecture:  x86_64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):4
On-line CPU(s) list:   0-3
Thread(s) per core:1
Core(s) per socket:4
Socket(s): 1
NUMA node(s):  1
Vendor ID: GenuineIntel
CPU family:6
Model: 60
Model name:Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Stepping:  3
CPU MHz:   3199.951
CPU max MHz:   3600.
CPU min MHz:   800.
BogoMIPS:  5986.40
Virtualization:VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache:  256K
L3 cache:  6144K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est 
tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt 
tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm epb tpr_shadow vnmi 
flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid 
rtm xsaveopt dtherm ida arat pln pts

OpenCL library:
un  libopencl-1.1-1 
un  libopencl-1.2-1 
un  libopencl-2.0-1 
un  libopencl-2.1-1 
un  libopencl1  
un  nvidia-libopencl1-dev   
ii  ocl-icd-libopencl1:amd642.2.9-2
ii  ocl-icd-libopencl1:i386 2.2.9-2
ii  beignet-opencl-icd:amd641.2.0-3
un  opencl-icd  
/usr/lib/x86_64-linux-gnu/beignet//libcl.so

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

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

Versions of packages beignet-opencl-icd depends on:
ii  libc6  2.24-5
ii  libdrm-intel1  2.4.71-1
ii  libdrm22.4.71-1
ii  libgcc11:6.2.0-13
ii  libllvm3.8 1:3.8.1-16
ii  libstdc++6 6.2.0-13
ii  libx11-6   2:1.6.3-1
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.2-1

beignet-opencl-icd recommends no packages.

beignet-opencl-icd suggests no packages.

-- no debconf information

Bug#833997: atop: process accounting does not work

[Martin Steigerwald]

Hello Gerlof.

Am Samstag, 12. November 2016, 14:18:02 CET schrieb Gerlof Langeveld:
> Hi Martin,
> 
> Thanks for the system call traces!
> I analyzed them in the meantime and have some questions (see end of the
> mail).

Answers below:

> On 11/09/2016 09:37 AM, Martin Steigerwald wrote:
> > Hi Gerlof.
> > 
> > Very busy week, so feel free to ask for further information, but please
> > understand that I may only report back next week.
> > 
> > Am Samstag, 29. Oktober 2016, 10:26:38 CET schrieben Sie:
> >>> Hi Marc, hi Gerlof (on CC).
> >>> 
> >>> Am Mittwoch, 26. Oktober 2016, 10:44:30 CEST schrieb Marc Haber:
>  On Wed, Oct 26, 2016 at 10:31:54AM +0200, Martin Steigerwald wrote:
> > merkaba:~> systemctl status atopacct
> > ● atopacct.service - Atop process accounting daemon
> > 
> >  Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
> >  vendor
> >  preset: enabled) Active: active (running) since Mi 2016-10-26
> >  10:21:29
> >  CEST; 5min ago>
> >  
> >Docs: man:atopacctd(8)
> > 
> > Process: 31802 ExecStart=/usr/sbin/atopacctd (code=exited,
> > status=0/SUCCESS)>
> >
> >Main PID: 31804 (atopacctd)
> >
> >   Tasks: 1 (limit: 4915)
> >  
> >  CGroup: /system.slice/atopacct.service
> >  
> >  └─31804 /usr/sbin/atopacctd
> > 
> > Okt 26 10:21:29 merkaba atopacctd[31804]: Version: 2.2-4 - 2016/10/14
> > 23:17:04   Okt 26 10:21:29 merkaba
> > systemd[1]: Starting Atop process accounting daemon... Okt 26 10:21:29
> > merkaba atopacctd[31804]: accounting to /run/pacct_source Okt 26
> > 10:21:29
> > merkaba systemd[1]: Started Atop process accounting daemon.
> > 
> > 
> > Yet no procacct warning in atop.
>  
>  I'm running out of ideas. Can you strace atop and see where it fails?
> >>> 
> >>> After your answering your question below I think it is still atopacctd
> >>> having>
> >>> 
> >>> issues:
> > But accounting seems to work:
> > 
> > merkaba:~> find /run/pacct_source -ls
> > 
> > 1297627 44 -rw---   1 root root44928 Okt 26
> > 10:28
> > /run/pacct_source
>  
>  How about the files in /run/pacct_shadow.d/? These are the ones an
>  atop process tries to read.
>  
>  I have:
>  -rw-r--r--  1 root root 21184 Oct 26 00:46 00.paf
>  -rw-r--r--  1 root root 7 Oct 26 00:00 current
>  
>  and the paf file is growing.
> >>> 
> >>> There is the issue:
> >>> 
> >>> merkaba:~> ls -l /run/pacct_source
> >>> -rw--- 1 root root 1174656 Okt 27 22:46 /run/pacct_source
> >>> merkaba:~> ls -l /run/pacct_shadow.d
> >>> insgesamt 4
> >>> -rw-r--r-- 1 root root 0 Okt 27 06:53 00.paf
> >>> -rw-r--r-- 1 root root 7 Okt 27 06:53 current
> >>> 
> >>> The pacct_source file grows, but the paf file does not.
> >>> 
> >>> merkaba:~> ps aux | grep "[a]top"
> >>> root  1573  0.0  0.0   418484 ?S<   06:53   0:00
> >>> /usr/sbin/
> >>> atopacctd
> >>> root  1904  0.0  0.0  27500 10492 ?S >>> /usr/bin/atop -a -R -w /var/log/atop/atop_20161027 600
> >>> 
> >>> merkaba:~> LANG=C systemctl status atopacct
> >>> * atopacct.service - Atop process accounting daemon
> >>> 
> >>>  Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
> >>>  vendor
> >>> 
> >>> preset: enabled)
> >>> 
> >>>  Active: active (running) since Thu 2016-10-27 06:53:31 CEST; 15h
> >>>  ago
> >>>  
> >>>Docs: man:atopacctd(8)
> >>>
> >>>Main PID: 1573 (atopacctd)
> >>>
> >>>   Tasks: 1 (limit: 4915)
> >>>  
> >>>  CGroup: /system.slice/atopacct.service
> >>>  
> >>>  `-1573 /usr/sbin/atopacctd
> >>> 
> >>> Oct 27 06:53:31 merkaba systemd[1]: Starting Atop process accounting
> >>> daemon... Oct 27 06:53:31 merkaba atopacctd[1573]: Version: 2.2-4 -
> >>> 2016/10/14 23:17:04 
> >>> Oct 27 06:53:31 merkaba atopacctd[1573]: accounting to /run/pacct_source
> >>> Oct 27 06:53:31 merkaba systemd[1]: Started Atop process accounting
> >>> daemon.
> >>> 
> >>> 
> >>> Hmmm, but atopacctd actually accounts to /run/pacct_source? Is that a
> >>> configuration mismatch?
> >>> 
> >>> Okay, from strace atop opens the paf file and so… reads from a zero byte
> >>> file.
> >>> 
> >>> 25046 open("/run/pacct_shadow.d/current", O_RDONLY) = 3
> >>> 25046 open("/run/pacct_shadow.d/00.paf", O_RDONLY) = 3
> >>> 
> >>> I attach the complete output of strace -e file -f -o /tmp/atop.strace
> >>> atop.
> >>> 
> >>> from manpage of atopacctd:
> >>>  The directory /run is used as the default topdirectory.   Below
> >>>  this  top-directory, the source file pacct_source is created to
> >>>  which the kernel writes the process accounting records.
> >>>  Furthermore, the 

Bug#844148: acl2: FTBFS: certification failed directory

[Aurelien Jarno]

On 2016-11-14 22:53, Aurelien Jarno wrote:
> control: reassign 844148 acl2
> 
> On 2016-11-14 11:24, Camm Maguire wrote:
> > reassign 844148 glibc
> > thanks
> > 
> > Greetings, and thanks so much for your report!
> > 
> > Neither ACL2 nor underlying gcl makes any use of threads or locks, but
> > does rely on standard libc calls, which are known to turn on code in TSX
> > environments that still have bugs.  GCL does make use of setjmp/longjmp
> > and volatile declarations which might appear similar but in no way are
> > cpu specific.
> 
> Sorry but that's not a reason for reassigning the bug to the glibc
> package. The same way I can say that the GNU libc doesn't have bugs in
> the TSX code, so I am just reassigning the bug back to acl2.

Additional note: the non TSX machine has 2 cores, while the TSX
machine has 64 cores. This might be a parallel building issue.

Aurelien

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

Bug#843988: stunnel4 segfaults (client mode)

[gregor herrmann]

On Mon, 14 Nov 2016 23:13:14 +0100, Sebastian Andrzej Siewior wrote:

> > Built, installed, started, and it's still running after several
> > fetchnews runs. Thanks!
> Thank you for the confirmation. And now please explain why it works with
> openssl 1.0.2. It should have exploded the same way…

Sorry, no idea either …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Flying Pickets: I Feel For You


signature.asc
Description: Digital Signature

Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software

[Gianfranco Costamagna]

Hi,

>No, it's fine. I am still not 100% sure what happened here though, could you 
>explain?  :)



dget -u mentors.dsc

dpkg-buildpackage -S -d
dput ftp-master ../hylafax_*source.changes

not sure what I can explain, maybe I can just say that we can exclude:
1) the fact that another upload was already in deferred (AFAIK dak checks the 
same version,
but you can upload in deferred many lower or higher versions)
2) some sort of problem with that particular package

lets see what can be a problem
1) you have some issues with your key (I would exclude this, because you 
already uploaded something else)
2) you uploaded something different than me:
I did a source upload, you did an amd64 one.
You have that buildinfo file, maybe dak is not handling it correctly?
https://ftp-master.debian.org/deferred/

if you want to debug it further I can dcut it and let you try another time, or 
do a source only upload.

otherwise in 15 hours it will reach unstable.

G.

Bug#843988: stunnel4 segfaults (client mode)

[Sebastian Andrzej Siewior]

On 2016-11-14 22:43:16 [+0100], gregor herrmann wrote:
> Control: tag -1 + patch
> 
> On Mon, 14 Nov 2016 22:07:12 +0100, Sebastian Andrzej Siewior wrote:
> 
> > On 2016-11-14 00:17:31 [+0100], gregor herrmann wrote:
> > > Thanks, but nope, still the same:
> > What about this one?
> 
> Yay, this looks good!
> 
> Built, installed, started, and it's still running after several
> fetchnews runs. Thanks!

Thank you for the confirmation. And now please explain why it works with
openssl 1.0.2. It should have exploded the same way…

> Cheers,
> gregor
> 

Sebastian

Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software

[Chris Lamb]

No, it's fine. I am still not 100% sure what happened here though, could you 
explain?  :)

—lamby 

Gianfranco Costamagna wrote:

> Hi Chris,
> 
>
> 
> >lets see my test :)
> 
> it seems to have worked, let me know if I have to leave it or
> you want me to cancel it
> (I signed the version on mentors)
> 
> G.


Regards,

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

Bug#844035: RFS: hylafax/3:6.0.6-7 [RC] -- Flexible client/server fax software

[Gianfranco Costamagna]

Hi Chris,



>lets see my test :)

it seems to have worked, let me know if I have to leave it or
you want me to cancel it
(I signed the version on mentors)

G.

Bug#844369: libelfin: FTBFS everywhere

[Emilio Pozuelo Monfort]

Source: libelfin
Version: 0.2-2
Severity: serious

Your package built nowhere:

https://buildd.debian.org/status/package.php?p=libelfin

The previous version didn't build anywhere either, so I'm surprised
this was uploaded to sid without fixing that first...

https://buildd.debian.org/status/logs.php?pkg=libelfin=0.2-1=experimental

Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Bug#843000: refind: fails to install on NVMe

[Tianon Gravi]

On 4 November 2016 at 02:34, Bjørn Mork  wrote:
> + /bin/efibootmgr -c -l '\EFI\refind\refind_x64.efi' -L 'rEFInd Boot Manager' 
> -d /dev/nvme0n1 -p 1

I just tested this on a friend's machine which has NVMe and uses
rEFInd and we had to change the "-d" value to be "/dev/nvme0n1p1"
(full path to the partition itself) for the entry to be created
correctly (otherwise "efibootmgr -v" afterwards shows
"HD(1,0,000...000,0x0,0x0)/File(...)" instead of the correct
"HD(1,GPT,xxx...xxx,0x800,0x20)/File(...)", which we got after
adjusting the "-d" path).

Rod, any ideas for why that might be the case (and how it might be
handled properly in "refind-install")? :/


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#822062: hugin: "Align" causes assert "(argtype & (wxFormatStringSpecifier::value)) == … in wx/strvararg.h(456)

[linuxproc...@free.fr]

Package: hugin
Version: 2016.2.0~rc2+dfsg-2
Followup-For: Bug #822062

Dear Maintainer,

I can confirm that the problem described in #822062 still exists (I got exactly
the same use case / same result).
I also cannot use hugin whitout this functionality.

Regards



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages hugin depends on:
ii  enblend   4.2-2
ii  enfuse4.2-2
ii  hugin-tools   2016.2.0~rc2+dfsg-2
ii  libc6 2.24-5
ii  libexiv2-14   0.25-3
ii  libfftw3-double3  3.3.5-1
ii  libgcc1   1:6.2.0-10
ii  libgl1-mesa-glx [libgl1]  12.0.3-3
ii  libglew2.02.0.0-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgomp1  6.2.0-10
ii  libimage-exiftool-perl10.25-1
ii  liblcms2-22.7-1
ii  libpano13-3   2.9.19+dfsg-2+b1
ii  libsqlite3-0  3.15.0-1
ii  libstdc++66.2.0-10
ii  libtiff5  4.0.6-3
ii  libvigraimpex61.10.0+git20160211.167be93+dfsg-2+b1
ii  libwxbase3.0-0v5  3.0.2+dfsg-2
ii  libwxgtk3.0-0v5   3.0.2+dfsg-2
ii  make  4.1-9

hugin recommends no packages.

hugin suggests no packages.

-- no debconf information

Bug#844271: confirmed

[Lance Lassetter]

setting ssl_protocols = !SSLv3 in dovecot.conf worked as a temporary
solution, thanks Mr. Sprickerhof!

Lance

Bug#844148: acl2: FTBFS: certification failed directory

[Aurelien Jarno]

control: reassign 844148 acl2

On 2016-11-14 11:24, Camm Maguire wrote:
> reassign 844148 glibc
> thanks
> 
> Greetings, and thanks so much for your report!
> 
> Neither ACL2 nor underlying gcl makes any use of threads or locks, but
> does rely on standard libc calls, which are known to turn on code in TSX
> environments that still have bugs.  GCL does make use of setjmp/longjmp
> and volatile declarations which might appear similar but in no way are
> cpu specific.

Sorry but that's not a reason for reassigning the bug to the glibc
package. The same way I can say that the GNU libc doesn't have bugs in
the TSX code, so I am just reassigning the bug back to acl2.

Aurelien

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

Bug#844357: fracplanet FTPFS on mips*: libQtOpenGL.so: undefined reference to `glLoadMatrixd'

[Emilio Pozuelo Monfort]

On 14/11/16 20:08, Adrian Bunk wrote:
> Package: fracplanet
> Version: 0.4.0-5
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=fracplanet=sid
> 
> g++ -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wl,-z,relro -Wl,-O1 -o fracplanet 
> obj/common.o obj/control.o obj/control_about.o obj/control_render.o 
> obj/control_save.o obj/control_terrain.o obj/dialog_documentation.o 
> obj/fracplanet.o obj/fracplanet_main.o obj/geometry.o obj/image.o 
> obj/license.o obj/matrix33.o obj/matrix34.o obj/noise.o 
> obj/parameters_cloud.o obj/parameters_noise.o obj/parameters_object.o 
> obj/parameters_render.o obj/parameters_save.o obj/parameters_terrain.o 
> obj/progress.o obj/random.o obj/rgb.o obj/scan.o obj/spinbox.o obj/triangle.o 
> obj/triangle_edge.o obj/triangle_mesh.o obj/triangle_mesh_cloud.o 
> obj/triangle_mesh_terrain.o obj/triangle_mesh_viewer.o 
> obj/triangle_mesh_viewer_display.o obj/vertex.o obj/xyz.o 
> obj/moc_control_about.o obj/moc_control_render.o obj/moc_control_save.o 
> obj/moc_control_terrain.o obj/moc_dialog_documentation.o 
> obj/moc_fracplanet_main.o obj/moc_triangle_mesh_viewer.o obj/moc_triang
>  le_mesh_viewer_display.o-L/usr/lib/mips-linux-gnu -L/usr/X11R6/lib 
> -lboost_program_options -lGLU -lQtOpenGL -lQtGui -lQtCore -lGL -lpthread 
> /usr/lib/mips-linux-gnu/libQtOpenGL.so: undefined reference to `glLoadMatrixd'
> 
> 
> Michael Biebl mentioned #844227 on IRC, are these bugs coincidence,
> or is there something that broke/changed in Mesa on mips* recently?

There is most likely something broken in mesa or lower in the stack. Please
don't open bugs for this build failure (which is affecting several packages)
until that is investigated.

Emilio

Bug#844315: tzdata version breaks dist-upgrade leaving version from oldstable security installed

[Aurelien Jarno]

reassign 844315 general
retitle 844315 updates appear in wheezy-security before jessie
affects 844315 tzdata
thanks

On 2016-11-14 12:54, Marcel Meckel wrote:
> Package: tzdata
> Version: 2016i-0+deb7u1
> Severity: critical
> 
> Upgrading a fully updated wheezy system (incl. security repo) to
> jessie (incl. security repo) results in tzdata not being updated
> because the version in wheezy-security is newer than in jessie.
> 
> Package tzdata on amd64
> 
>   wheezy:  2016d-0+deb7u1
>   wheezy-security: 2016i-0+deb7u1
> 
>   jessie:  2016f-0+deb8u1
>   jessie-updates:  2016i-0+deb8u1
>   jessie-proposed-updates: 2016i-0+deb8u1
> 
> Using only the main repo + security repo results in tzdata not being
> updates since wheezy-securities '2016i-0+deb7u1' is higher than
> jessies '2016f-0+deb8u1'.

Nothing can be done at the tzdata level, except maybe stopping providing
updates to wheezy users. I am therefore reassigning the bug to the
"general" package. Also there are probably more than tzdata affected.

Note however that you are supposed to use jessie-updates on a jessie
system. This is actually enabled by default in debian-installer.

Aurelien

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

Bug#844368: pyparsing: version 2.1.10 makes sphinxcontrib-doxylink FTBFS

[Ghislain Antony Vaillant]

Source: pyparsing
Version: 2.1.10+dfsg1-1
Severity: important

Dear Maintainer,

Since the update of pyparsing to 2.1.10, the sphinxcontrib-doxylink
package now FTBFS and is affected by an RC bug [1].

The failure occurs in the testsuite. The latter used to pass fine with
2.1.9 [2] but now fails with 2.1.10 [3]. The errors are all of the form:

```
 Traceback (most recent call last):
 >   File "/<>/tests/test_parser.py", line 98, in
 >   test_numbers_for_defaults
 > self.assertEqual(parsing.normalise(arglist[0]), arglist[1])
 >   File "/<>/sphinxcontrib/doxylink/parsing.py", line
 >   116, in normalise
 > argument_string_list.append(''.join((arg.qualifier,' ')))
 > TypeError: sequence item 0: expected string, ParseResults found
```

Since I am no pyparsing expert, I was wondering whether you guys were
familiar with the specific features introduced with 2.1.10 which could
have caused this. I also filed a bug upstream [4] but I am not holding
my breath.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841582
[2] 
https://ci.debian.net/data/packages/unstable/amd64/s/sphinxcontrib-doxylink/20161014_051640.autopkgtest.log.gz
 
[3] 
https://ci.debian.net/data/packages/unstable/amd64/s/sphinxcontrib-doxylink/20161019_142357.autopkgtest.log.gz
[4] 
https://bitbucket.org/birkenfeld/sphinx-contrib/issues/172/doxylink-typeerror-sequence-item-0

Cheers,
Ghis


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (300, 'unstable')
Architecture: amd64 (x86_64)

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

Bug#843988: stunnel4 segfaults (client mode)

[gregor herrmann]

Control: tag -1 + patch

On Mon, 14 Nov 2016 22:07:12 +0100, Sebastian Andrzej Siewior wrote:

> On 2016-11-14 00:17:31 [+0100], gregor herrmann wrote:
> > Thanks, but nope, still the same:
> What about this one?

Yay, this looks good!

Built, installed, started, and it's still running after several
fetchnews runs. Thanks!
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!

[Pierre-Elliott Bécue]

Le vendredi 11 novembre 2016 à 14:39:18+0100, Jan Luca Naumann a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hey Pierre-Elliott,
> 
> my idea is that we package the current development versions and upload
> them to Debian experimental since the development time of 3.1 will
> last some more time according to the Mailman developers...
> 
> If you have no problem I could submit some changes to your repository
> either as pull requests or as direct pushs?

As said, there is two issues.

First, HyperKitty deps are missing, second, mailman relies on python3.4.

If you have some patches to offer let's go for it, what is your github login
please?

-- 
PEB

Bug#843051: release.debian.org: boost1.62 transition

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 14/11/16 21:54, Sebastiaan Couwenberg wrote:
> Please retry the osmium-tool builds that FTBFS with libosmium 2.10.0,
> I've reverted libosmium back to 2.9.0 until upstream has fixed the IdSet
> issues introduced in 2.10.0.
> 
>  dw osmium-tool_1.4.0-2 . amd64 arm64 mips64el ppc64el . -m
> 'libosmium2-dev (>= 2.10.0really2.9.0)'

Done.

> I think the sfcgal builds on mips{,el} need to be retried too where the
> build failed due to:
> 
>  cc1plus: out of memory allocating 5842196 bytes after a total of
> 58634240 bytes

Given back.

> On mips64el there was an undefined reference to `glLoadMatrixd' in
> libosg.so, for which I'm not entirely sure about the fix. I suspect a
> rebuild of openscenegraph may be sufficient.

Those are happening in several packages on mips*, see #844227. I'm not sure
about who is to blame, but I don't think a give back is going to help yet.

Cheers,
Emilio

Bug#832941: RFS: 4pane (debian: to exclusive)

[David Hart]

Dear Sean,

>> >I'd recommend including the upstream code in the git repository, too.
>> >But what you've done is fine -- thanks!
>> 
>> I've now added that too.
>
>I think you misunderstood what I was suggesting.
I'm certain I did ;)

>You've committed the
>tarball to git, but I meant adding the unpacked upstream source.
>
>Unfortunately, your change means that I can't build your package from
>the git repository, so it's hard for me to continue my review.  Please
>consider using gbp-import-dsc(1), or reverting to only having debian/ in
>git if you prefer.

For simplicity, I've just removed the tarball. It can always be done properly
in the future when I understand better what is required.

>Also, the Vcs-* fields still point to the upstream source, not the
>packaging repository.

Does this need to be fixed before you can use the repo. If so, what should I
enter there?
Vcs-Git: https://github.com/dghart/4pane-debian-dir -b master
Vcs-browser: https://github.com/dghart/4pane-debian-dir/tree/master
or something different?

Regards,

David Hart

Bug#844227: FTBFS on mips*, ./.libs/libmutter-cogl.so: undefined reference to `eglQueryString'

[Balint Reczey]

Control: affects -1 kodi

On Mon, 14 Nov 2016 18:47:00 +0100 Michael Biebl  wrote:
> Am 13.11.2016 um 19:43 schrieb Michael Biebl:
> > Am 13.11.2016 um 18:37 schrieb Sven Joachim:
> >> The toolchain has also changed quite a bit in the past four weeks, with
> >> gcc having pie enabled by default and binutils at a bleeding edge
> >> snapshot.  Maybe one of those has triggered the build failure.
> > 
> > That might well be it. Currently mutter still builds fine in stretch.
> > The new binutils should migrate to testing soon.
> > I can then retry the build on a mips porter machine with
> > 2.27.51.20161108-1
> 
> binutils 2.27.51.20161108-1 just migrated to stretch. mutter still
> builds fine in stretch with this version. So I'd say we can cross off
> binutils from the list of suspects.

Also makes kodi FTBFS on mips*:
https://buildd.debian.org/status/fetch.php?pkg=kodi=mipsel=17.0~beta5%2Bdfsg1-2=1479134924
...
LD  kodi.bin
xbmc/windowing/X11/windowing_X11.a(GLContextEGL.o): In function
`CGLContextEGL::Destroy()':
./xbmc/windowing/X11/GLContextEGL.cpp:253: undefined reference to
`eglTerminate'
./xbmc/windowing/X11/GLContextEGL.cpp:255: undefined reference to
`eglTerminate'
xbmc/windowing/X11/windowing_X11.a(GLContextEGL.o): In function
`CGLContextEGL::QueryExtensions()':
./xbmc/windowing/X11/GLContextEGL.cpp:369: undefined reference to
`eglQueryString'
./xbmc/windowing/X11/GLContextEGL.cpp:369: undefined reference to
`eglQueryString'
xbmc/windowing/X11/windowing_X11.a(GLContextEGL.o): In function
`CGLContextEGL::Refresh(bool, int, unsigned long, bool&)':
./xbmc/windowing/X11/GLContextEGL.cpp:159: undefined reference to
`eglTerminate'
./xbmc/windowing/X11/GLContextEGL.cpp:159: undefined reference to
`eglTerminate'
...

Mutter is most likely easier to debug due to linking to way less libs.

Cheers,
Balint

Bug#644912: Unable to deliver your item, #762465378929

[FedEx 2Day A.M.]

Hello,
Courier was unable to deliver the parcel to you. Shipment Label is attached to 
this email.
Wylma Devit - Area Manager FedEx , CA
Thanks and best regards


FedEx.doc
Description: MS-Word document

Bug#828566: Proposed NMU

[Muammar El Khatib]

Dear Sergei,

On Mon, Nov 7, 2016 at 8:48 AM, Sergei Golovan  wrote:
> tags 828566 + patch
> thanks
>
> Hi, Muammar,
>
> I'd like to offer a patch which ports tcltls to the new Openssl 1.1.
> It's already forwarded upstream
> (https://sourceforge.net/p/tls/bugs/66/) though I don't know when it
> (or some other patch) will be accepted. The changes are mostly
> straightforward, the patch retains compatibility with OpenSSL 1.0, and
> the package passes regression tests.
>
> If you don't mind, I could do NMU for this bugfix.
>
> Cheers!

Please go ahead with the NMU. I am sorry for the delay, too much work
right now.

Thank you.

Regards,

-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 71246E4A.
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-

Bug#842815: closed by Andreas Tille <ti...@debian.org> (Bug#842815: fixed in libsis-jhdf5-java 14.12.6-1)

[Gilles Filippini]

Control: reopen -1

Andreas Tille a écrit le 14/11/2016 à 21:15 :
> Hi Gilles,
> 
> On Mon, Nov 14, 2016 at 07:32:04PM +0100, Gilles Filippini wrote:
>> Debian Bug Tracking System a écrit le 14/11/2016 à 16:09 :
>>> This is an automatic notification regarding your Bug report
>>> which was filed against the src:libsis-jhdf5-java package:
>>>
>>> #842815: libsis-jhdf5-java: Please support HDF5 1.10
>>>
>>> It has been closed by Andreas Tille .
>>>
>>> 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 Andreas Tille 
>>>  by
>>> replying to this email.
>>
>> Thank you for this upload. Have you tested the build against hdf5-1.10
>> in experimental?
> 
> Hmmm, sorry, no - I just made sure that the *sid* pbuilder environment
> is instaling hdf5-1.10.

Ah. The fact that HDF5 1.8.16 builds libhdf5-10 might be confusing. HDF5
1.10 builds libhdf5-100 and is still in experimental.

> If this is not sufficient please reopen ...
> and please give some helping hint if the package might not build
> properly.  Otherwise I have no idea what to do - patches are very
> welcome.

There are at least 3 majors changes brought by HDF5 1.10:
1- The widely used hid_t datatype is now uint64_t (instead of int)
2- The java wrapper library is now part of the HDF5 source tree
3- HDF5Exception is now a checked exception.

(2) and (3) might be worked out with a new upload of hdf5, to ship the
java wrapper library packages, patched to define HDF5Exception as an
unchecked exception. I'd rather wait after the transition.

(1) Involves patching libsis-jhdf5-java.

The best option would be a new upstream release. Do you know their
schedule wrt HDF5 1.10?

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#824599: [Pkg-nagios-devel] Bug#824599: monitoring-plugins: examples empty

[Jan Wagner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

tags 824599 + pending
thanks

Hi Matt,

Am 17.05.2016 um 23:38 schrieb Matt Taggart:
> Some of the monitoring-plugins* packages have a 
> /usr/share/doc/monitoring-plugins*/examples symlink to 
> ../monitoring-plugins-common/examples which is empty, I think
> because the last thing in 
> debian/monitoring-plugins-common.examples was removed and it's
> empty. So I guess remove examples from debian/*.links ?

thanks for the notification. It's fixed in the VCS.

Cheers, Jan.
- -- 
Never write mail to , you have been warned!
- -BEGIN GEEK CODE BLOCK-
Version: 3.12
GIT d-- s+: a C+++ UL P+ L+++ E--- W+++ N+++ o++ K++ w--- O M+ V-
PS PE Y++
PGP++ t-- 5 X R tv- b+ DI D+ G++ e++ h r+++ y
- --END GEEK CODE BLOCK--
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYKiiDAAoJEAxwVXtaBlE+O5wQAJYajzoT0XDLCKvLIKnUvrzc
R656HK9z6GDYGIHw7NCFsx2SyoObqftSQzWUv/Eb2XCLSCY/cZXt72jHgvKXs0xs
01wM5lFGLY1dXjzQTAe5ONiYckwKqUW8nZ7muH9atqOseLn6L2DRiqRyX3EST6pD
nPEMlkvmA9yVS5N7vaxV9EASknjNNCP4znVwA7GuJMOAJUk29TTbiFCbsXW7XFIq
iYcpK44yHRSqLWin7Uun0FxABKQ9Abjvt9VjTY3Z3OkYVT6r34imqut2LrbR1RGE
FVmjiIq2Nc0P9YDXx0alYWUeoLfkmoePsUFRijMaZPguz8tCMhDXIjavrArR4KMU
BbOMgLVfhfkRRkwadhN/e8QBPcpl/1wCzkfgeKali/iQXTV+JLieDxxvTxDT1n4o
J8aNyGRmN9pmRNdTRMR1ecH6papf7XQxrSvJF8+G0VwyhVKmJv7HVlX/2nuTtCOt
jwIiADvroarGLtWYFQ6zDDU78dxn/NN7JF0ZIguUaavss/VI3iUU/m+2+iJJ/QOf
bbkAS9/lpuYGlp0LiklZbk3+c8LYvfeIO/YWHsuWU1jKZ+2mEJWhZUbEuwao8zY2
PhE/h3xfqjPEFNPsaJKrOT8eUXz79+OECjAe1OBfmr6qymtSYhdmWzt7By0F6R2v
vPbCEvqG0KWvwVw6b2sN
=QbOJ
-END PGP SIGNATURE-

Bug#844367: Debian local ada patches need an update for GCC 7

[Matthias Klose]

Package: src:gcc-7
Severity: important
Tags: sid buster

The Debian local ada patches need an update for GCC 7.  The
libgnatprj/libgnatvsn patches probably need to be dropped, if they can't be
updated [1].

[1] https://lists.debian.org/debian-ada/2016/10/msg0.html

Bug#843988: stunnel4 segfaults (client mode)

[Sebastian Andrzej Siewior]

On 2016-11-14 00:17:31 [+0100], gregor herrmann wrote:
> Thanks, but nope, still the same:

What about this one?

Sebastian
>From b436cd6527a2a32bd94b67ff10363e45a2f52430 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior 
Date: Mon, 14 Nov 2016 21:03:24 +
Subject: [PATCH] take #2

---
 src/client.c | 22 +-
 src/tls.c|  1 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/src/client.c b/src/client.c
index e2648d26eda3..581ca43a3372 100644
--- a/src/client.c
+++ b/src/client.c
@@ -131,11 +131,31 @@ void client_main(CLI *c) {
 c->fds=NULL;
 str_stats(); /* client thread allocation tracking */
 /* c allocation is detached, so it is safe to call str_stats() */
-if(service_options.next) /* no tls_cleanup() in inetd mode */
+if(service_options.next) { /* no tls_cleanup() in inetd mode */
+	SSL_SESSION *old_session;
+
+	CRYPTO_THREAD_write_lock(stunnel_locks[LOCK_SESSION]);
+		old_session = c->opt->session;
+		c->opt->session = NULL;
+		CRYPTO_THREAD_write_unlock(stunnel_locks[LOCK_SESSION]);
+		if (old_session)
+			SSL_SESSION_free(old_session); /* release the old one */
+
 tls_cleanup();
+	}
 }
 } else
 client_run(c);
+{
+	SSL_SESSION *old_session;
+
+	CRYPTO_THREAD_write_lock(stunnel_locks[LOCK_SESSION]);
+	old_session = c->opt->session;
+	c->opt->session = NULL;
+	CRYPTO_THREAD_write_unlock(stunnel_locks[LOCK_SESSION]);
+	if (old_session)
+		SSL_SESSION_free(old_session); /* release the old one */
+}
 str_free(c);
 }
 
diff --git a/src/tls.c b/src/tls.c
index 3964f9ce6f2d..8b2b18938d74 100644
--- a/src/tls.c
+++ b/src/tls.c
@@ -100,6 +100,7 @@ void tls_cleanup() {
 tls_data=tls_get();
 if(!tls_data)
 return;
+OPENSSL_thread_stop();
 str_cleanup(tls_data);
 str_free(tls_data->id); /* detached allocation */
 tls_set(NULL);
-- 
2.10.2

Bug#828236: Bug#844160: openssl 1.1 and apache2

[Stefan Fritsch]

On Monday, 14 November 2016 05:03:45 CET Ondřej Surý wrote:
> > Looking at mod_ssl_openssl.h and the comment in #828330,
> > I'd suggest the change below to add a dependency on libssl1.0-dev
> > to apache2-dev.
> 
> And that exactly happens meaning that PHP 7.0 can no longer be built
> unless all it's build-depends (including PHP 7.0) and rdepends move to
> libssl1.0-dev as well.
> 
> So a nice deadlock, right? To be honest I would rather have a slightly
> less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go
> than revert all the work I have done.

I must admit that I did not think of php when doing that change, sorry. 

On the other hand, shibboleth-sp2 also build-depends on apache2-dev and there 
have been some indications that shibboleth won't be switching to openssl 1.1 
for stretch. See https://lists.debian.org/debian-release/2016/11/msg00024.html

I agree with Ondřej that this will get very entangled. There will be one big 
dependency-blob that contains most complex packages and can only be 
transitioned together. And a few leaf packages that can be transitioned 
easily. For example, subversion also build-depends on apache, and kde build-
depends on subversion. Though libsvn-dev does not depend on apache2-dev, so 
maybe this is not actually a problem.

> I reviewed the patch Kurt has provided and I don't see any strong reason
> why anything should break.

With Kurt's patch, apache2 crashes on startup with an invalid free. On the 
other hand, the patch from the upstream 2.4.x-openssl-1.1.0-compat branch 
seems to work at first glance and does not cause any regression in the test 
suite. So if we are going to have apache with openssl 1.1, it's going to be 
the upstream patch. 

But we first need to figure out what to do with  shibboleth-sp2 . 

My preference would be to make openssl 1.0 provide libssl-dev again and only 
have a few simple packages opt-in to using libssl1.1-dev.

Cheers,
Stefan

Bug#843051: release.debian.org: boost1.62 transition

[Sebastiaan Couwenberg]

Please retry the osmium-tool builds that FTBFS with libosmium 2.10.0,
I've reverted libosmium back to 2.9.0 until upstream has fixed the IdSet
issues introduced in 2.10.0.

 dw osmium-tool_1.4.0-2 . amd64 arm64 mips64el ppc64el . -m
'libosmium2-dev (>= 2.10.0really2.9.0)'

I think the sfcgal builds on mips{,el} need to be retried too where the
build failed due to:

 cc1plus: out of memory allocating 5842196 bytes after a total of
58634240 bytes

On mips64el there was an undefined reference to `glLoadMatrixd' in
libosg.so, for which I'm not entirely sure about the fix. I suspect a
rebuild of openscenegraph may be sufficient.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#844038: ocamlnet: FTBFS on hurd-i386: PATH_MAX

[Samuel Thibault]

Hello,

Samuel Thibault, on Sat 12 Nov 2016 00:34:48 +0100, wrote:
> The attached patch avoids using by by just reading the symlink
> length, and adjusting the size in case the symlink length increased in
> between through really bad concurrency luck.

Sorry, I should have really tested it, here is a fixed patch.

Samuel
--- ./src/netsys/netsys_c.c.original2016-11-11 23:14:29.0 +
+++ ./src/netsys/netsys_c.c 2016-11-11 23:25:42.0 +
@@ -607,12 +607,32 @@
 CAMLprim value netsys_readlinkat(value dirfd, value path)
 {
 #ifdef HAVE_AT
-  char buffer[PATH_MAX];
-  int len;
-  len = readlinkat(Int_val(dirfd), String_val(path), buffer, sizeof(buffer)-1);
-  if (len == -1) uerror("readlinkat", path);
+  char *buffer;
+  int buflen, len;
+  struct stat sb;
+  value ret;
+  if (lstat(String_val(path), ) != -1) {
+buflen = sb.st_size + 1;
+  }
+  else {
+buflen = 64;
+  }
+  while (1) {
+buffer = malloc(buflen);
+len = readlinkat(Int_val(dirfd), String_val(path), buffer, buflen);
+if (len == -1) {
+  free(buffer);
+  uerror("readlinkat", path);
+}
+if (len < buflen)
+  break;
+free(buffer);
+buflen *= 2;
+  }
   buffer[len] = '\0';
-  return copy_string(buffer);
+  ret = copy_string(buffer);
+  free(buffer);
+  return ret;
 #else
 invalid_argument("Netsys_posix.readlinkat not available");
 #endif

Bug#575547: Shipment delivery problem #95414

[FedEx International MailService]

Hello,
We could not deliver your item. Shipment Label is attached to this email.
Babita Cherebin - Area Manager FedEx , CA
Thank you for choosing FedEx


FedEx.doc
Description: MS-Word document

Bug#844366: libssl1.1: 1.1.0c broke Python

[Antonin Kral]

Package: libssl1.1
Version: 1.1.0c-1
Severity: critical
Tags: upstream
Justification: breaks unrelated software

Hi,

update to 1.1.0c broke Python ssl wrapper. I have first faced the issue
with offlineimap, which would crash with the [Errno 0] Error and the
following stack-trace when trying to refresh OAuth2 token from google:

Traceback:
  File "/usr/share/offlineimap/offlineimap/accounts.py", line 271, in syncrunner
self.__sync()
  File "/usr/share/offlineimap/offlineimap/accounts.py", line 334, in __sync
remoterepos.getfolders()
  File "/usr/share/offlineimap/offlineimap/repository/IMAP.py", line 452, in 
getfolders
imapobj = self.imapserver.acquireconnection()
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 540, in 
acquireconnection
self.__authn_helper(imapobj)
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 406, in 
__authn_helper
if func(imapobj):
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 340, in 
__authn_xoauth2
imapobj.authenticate('XOAUTH2', self.__xoauth2handler)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 705, in authenticate
typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 1692, in 
_simple_command
return self._command_complete(self._command(name, *args), kw)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 1418, in _command
literal = literator(data, rqb)
  File "/usr/lib/python2.7/dist-packages/imaplib2.py", line 2283, in process
ret = self.mech(self.decode(data))
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 239, in 
__xoauth2handler
six.reraise(type(e), type(e)(msg), exc_info()[2])
  File "/usr/share/offlineimap/offlineimap/imapserver.py", line 233, in 
__xoauth2handler
self.oauth2_request_url, urllib.urlencode(params)).read()
  File "/usr/lib/python2.7/socket.py", line 355, in read
data = self._sock.recv(rbufsize)
  File "/usr/lib/python2.7/ssl.py", line 766, in recv
return self.read(buflen)
  File "/usr/lib/python2.7/ssl.py", line 653, in read
v = self._sslobj.read(len)

These seem to be relevant upstream bugs:

  * https://github.com/openssl/openssl/issues/1919 (which was merged to 1903)
  * https://github.com/openssl/openssl/issues/1903

Downgrading to 1.1.0b (by installing libssl1.1_1.1.0b-2_amd64.deb from
snapshots) resolves the issue (and introduces back the vulnerability).

Best,

  Antonin

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libssl1.1 depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-5

libssl1.1 recommends no packages.

libssl1.1 suggests no packages.

-- debconf information excluded

Bug#843642: gnome-terminal: Scrolling with touchpad combines smooth and rough movement

[Egmont Koblinger]

There was no upstream bugreport up until now, however, I've talked to vte's
main developer when I saw the roxterm bug and he had no clue about it
either (neither did I). Mind you, neither of us actually started to deeply
investigate the story.

I've created an upstream bug now:
https://bugzilla.gnome.org/show_bug.cgi?id=774430

Bug#843399: linux-image-3.2.0-4-486 version 3.2.81-2 freezes

[Ben Hutchings]

On Mon, 2016-11-14 at 21:30 +0100, Miroslav Skoric wrote:
> On 11/14/2016 01:00 AM, Ben Hutchings wrote:
> 
> > 
> > Does this system have auditing enabled and does turning that off avoid
> > the problem?
> > 
> > Can you try using netconsole to capture kernel log messages leading up
> > to the freeze?
> > 
> 
> Well, I do not know what was enabled or not. Anyway, I am busy now with 
> some other tasks so I am afraid that I cannot go into the problem again. 
> Will probably stay with the older kernel and wait for the next kernel 
> update. However, you can let me know about turning off auditing and 
> using that netconsole since I am not an expert in that areas ...

If you don't know, then you won't have auditing enabled.

For netconsole:
https://www.kernel.org/doc/Documentation/networking/netconsole.txt

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.


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

Bug#844365: apt: syntax error in man apt.conf - option Acquire::http::Proxy

[Fred Ulisses Maranhão]

Package: apt
Version: 1.0.9.8.3
Severity: minor

Dear Maintainer,

In 'man apt.conf', there is the following paragraph: 

   Acquire::http::Proxy-Auto-Detect can be used to specify an
   external command to discover the http proxy to use. Apt expects
   the command to output the proxy on stdout in the style
   http://proxy:port/. This will override the generic
   Acquire::http::Proxy but not any specific host proxy configuration
   set via Acquire::http::Proxy::$HOST. See the squid-deb-proxy-
   client(1) package for an example implementation that uses avahi.
   This option takes precedence over the legacy option name
   ProxyAutoDetect.

but the syntax in
Acquire::http::Proxy::$HOST
seems wrong. the correct should be:
Acquire::http::Proxy $HOST

I tested the syntax Acquire::http::Proxy::$HOST in a machine with an
apt-cacher-ng installed, and although no error raise, the apt-cacher-ng
is not used. the dir /var/cache/apt-cacher-ng don't change size and files
/var/log/apt-cacher-ng/apt-cacher.log and /var/log/apt-cacher-ng/apt-cacher.err
don't change.

When I used Acquire::http::Proxy $HOST, during an apt-get update and
apt-get install xjig, the dir /var/cache/apt-cacher-ng was writen and
the file tail -f /var/log/apt-cacher-ng/apt-cacher.log changed.

some evidence:
# more /etc/apt/apt.conf.d/02cache
Acquire::http::Proxy "http://localhost:3142/;;

# tail -n 5 /var/log/apt-cacher-ng/apt-cacher.log 
1479155016|O|176471|::1|security.debian.org/pool/updates/main/o/openjdk-7/openjdk-7-jre_7u111-2.6.7-2~deb8u1_amd64.deb
1479155016|I|440180|::1|security.debian.org/pool/updates/main/o/openjdk-7/openjdk-7-jre-headless_7u111-2.6.7-2~deb8u1_amd64.deb
1479155016|O|440122|::1|security.debian.org/pool/updates/main/o/openjdk-7/openjdk-7-jre-headless_7u111-2.6.7-2~deb8u1_amd64.deb
1479155085|I|121247|::1|debrep/pool/main/x/xjig/xjig_2.4-14+b2_amd64.deb
1479155085|O|121273|::1|debrep/pool/main/x/xjig/xjig_2.4-14+b2_amd64.deb

the wrong syntax appears in version 1.3.1 of apt package also.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Never-MarkAuto-Sections:: "oldlibs";
APT::Never-MarkAuto-Sections:: "restricted/oldlibs";
APT::Never-MarkAuto-Sections:: "universe/oldlibs";
APT::Never-MarkAuto-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "1";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension