Bug#864745: Update on base.pm jessie point release

[Cyril Brulebois]

Hi Dominic,

Dominic Hargreaves  (2017-07-04):
> 1) this commit is identical to those now in upstream release candidates.
> 2) This has now been filed as #867164 (sorry that this was missing before)

Thanks for the update, much appreciated.

I have to say that giving you a green light to update perl in stable with this
kind of fix makes me a little nervous, sorry. :(

> 3) this particular bug doesn't strictly apply to stretch/sid, but we plan
>to fix it in sid at least for consistency and to fix the minor remaining
>security bug (see #867170)

I'm not sure how we feel about similar-yet-kind-of-different bugs in
other suites (as in: not sure whether fixing those would be considered
a hard requirement before an update in (old)stable).


KiBi.


signature.asc
Description: Digital signature

Bug#867231: stretch-pu: package openstack-debian-images/1.19

[Cyril Brulebois]

Hi,

Just a few additions below.

Adam D. Barratt  (2017-07-04):
> Control: tags -1 + moreinfo
> 
> On Wed, 2017-07-05 at 00:40 +0200, Thomas Goirand wrote:
> > Steve found out that the OpenStack images do not include the security
> > update repositories by default in Stretch (though it's ok for Wheezy
> > and Jessie). This was fixed in version 1.20 of openstack-debian-images
> > which I uploaded to sid. It's this commit:
> > 
> > https://anonscm.debian.org/cgit/openstack/openstack-debian-images.git/commit/?id=2a78166a6c4ee5ee2b25dc5ed37323f761337bbd
> > 
> > It's not as bad as it sounds though, because as soon as you boot the
> > image, cloud-init manages the sources.list and add the security
> > repositories, then performs an update. Though I still believe this
> > deserves a fix ASAP anyway.

I'm a little surprised how something that “isn't as bad as it sounds”
needs to get a fix “ASAP” anyway.

> > Would it be ok to just get version 1.20 into the next point release?
> > Or should I prepare the exact same change in a 1.19+deb9u1 version
> > (which IMO would be missleading)?

What would be misleading exactly? An update in stable following the
versioning scheme that's been in place for several releases?

> We can't "just get" a package from unstable into a point release. It
> needs reuploading via proposed-updates, whether as 1.19+deb9u1 or
> 1.20~deb9u1. I fail to see why this package should be different from
> every other in that respect.

Ditto.

> As usual, please provide a debdiff of the proposed source package,
> built and tested on stable, so that it can be confirmed.

Yeah, following the usual procedure, that has existed for years, *will*
save everyone time. Please do that.


KiBi.


signature.asc
Description: Digital signature

Bug#867135: ejabberd install fails with NO_NEW_PRIVILEGES exit code

[Philipp Huebner]

Hi

> http://git.deb.at/w/pkg/ejabberd.git/blob/refs/heads/stretch:/debian/README.Debian#l154
>   "PrivateDevices=\n" is, afaik, wrong and should be deleted.  same for
>   line 156, "NoNewPrivileges=\n"

I'm sure I had a good reason for writing that, maybe it was needed for
an older version of systemd in Jessie.

As soon as I find the time I'll try to reproduce this whole issue on a
fresh installation of Stretch and prepare an updated ejabberd package
for Stretch.

Thank you for your bugreport!

Regards,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature

Bug#866516: stretch-pu: package unrar-nonfree/1:5.3.2-1+deb9u1

[Cyril Brulebois]

Control: tag -1 pending

Hi Felix,

Felix Geyer  (2017-07-04):
> Uploaded, thanks!

Now flagged for acceptance, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#866517: jessie-pu: package unrar-nonfree/1:5.2.7-0.1+deb8u1

[Cyril Brulebois]

Control: tag -1 pending

Felix Geyer  (2017-07-04):
> Uploaded, thanks!

And now flagged for acceptance; thanks.

(Spotted the addition of '#' in changelog ;p -- but failed to spot the
typo on “parameters” while reviewing, sorry. Ditto for the stretch-pu
request.)


KiBi.


signature.asc
Description: Digital signature

Bug#862327: jessie-pu: package apt-cacher/1.7.10+deb8u1

[Cyril Brulebois]

Control: tag -1 pending

Hi,

Cyril Brulebois  (2017-06-27):
> Mark Hindley  (2017-05-11):
> > I would like approval to update apt-cacher in jessie by backporting the fix 
> > for
> > #786661.This ensures that /var/run/apt-cacher is created in the initscript 
> > when
> > operating under inetd.
> 
> This looks good to me, feel free to upload; thanks.

Flagged for acceptance, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#867091: stretch-pu: package gnome-settings-daemon/3.22.2-2

[Cyril Brulebois]

Control: tag -1 confirmed

Hi,

Laurent Bigonville  (2017-07-03):
> Today I discovered that gnome-settings-daemon was not remembering the
> numlock state between the different sessions due to a debian specific
> patch.
> 
> This is particularly a problem for people using wayland.
> 
> Upstream has this enabled for years, but due to an old bug (around 2012)
> this feature was disabled. This bug is fixed today.
> 
> The attached debdiff reset the remember-numlock-state dconf key back to
> the upstream value.
> 
> This should IMHO be fixed in stable.

This looks good to me, feel free to upload. We'll need the package in
unstable to migrate to testing before accepting your update from
stretch-new though.

Worth fixing in jessie while we're at it? If you want to do so, please
file a separate jessie-pu bug report.

Thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#867244: vecmath: Broken homepage URL

[Petter Reinholdtsen]

Package: vecmath
Version: 1.5.2-5

The homepage URL to vecmath no longer work.  I have no idea where the
new upstream home is.

PS: I would be glad if someone could remove me from the uploader list,
as I am no longer involved in the maintainence.

--
Happy hacking
Petter Reinholdtsen

Bug#867118: stretch-pu: package 3dchess/0.8.1-19+b1

[Cyril Brulebois]

Control: tag -1 confirmed

Hi Markus,

Markus Koschany  (2017-07-04):
> I would like to fix the 100 % CPU consumption bug in 3dchess. [1]
> Please find attached the debdiff for Stretch.

This looks good to me, feel free to upload; thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#867119: jessie-pu: package 3dchess/0.8.1-18

[Cyril Brulebois]

Control: tag -1 confirmed

Markus Koschany  (2017-07-04):
> I would like to fix the 100 % CPU consumption bug in 3dchess. [1]
> Please find attached the debdiff for Jessie.

Hi Markus,

This looks good to me, feel free to upload; thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#867159: stretch-pu: package pdns-recursor/4.0.4-1

[Cyril Brulebois]

Control: tag -1 confirmed

Christian Hofstaedtler  (2017-07-04):
> pdns-recursor has an embedded copy of the DNS root (".") zone public
> signing key ("KSK"), for DNSSEC verification purposes. ICANN has
> created a new key and expects it to use starting from October 11,
> 2017, in place of the old key.
> 
> This update adds the new key to the trusted set. If users do not get
> this update, DNSSEC validation will fail for them starting on Oct.
> 11, until they manually update the configuration.
> 
> The same fix is already in unstable (as 4.0.4-2).

Hi Christian,

This looks good to me, feel free to upload.

Are we getting an update for jessie as well? (If so, let's track this in
a separate bug report please.)

Thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#865303: also crashing on ubuntu 32 bits with latest kernel

[Olivier Tilloy]

In ubuntu we are seeing the x86 build of libreoffice fail (crash) on a
couple of unit tests. The latest ubuntu kernel update (4.4.0-83.106 on
16.04) fixed the crash for x86-64 builds, but x86 builds are still
affected.

Bug#867168: Re : Re : Re : Bug#867168: debsecan: Unable to upgrade because of numpy

[nicolas . patrois]

Le 04/07/2017 21:36:33, Florian Weimer a écrit :

> Is this file installed by a Debian package (dpkg -S
> /usr/share/pyshared/io.py)?

No:
> dpkg -S /usr/lib/python2.7/dist-packages/io.py
dpkg-query: aucun chemin ne correspond à /usr/lib/python2.7/dist-
packages/io.py

> I'm really sorry, but this really isn't something that I can fix on
> the debsecan side.  It looks like your Python installation is broken.

It seems but I did not play havoc with Python, I’m even not using pip.

nicolas patrois : pts noir asocial
-- 
RÉALISME

M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des 
humains ? Un cerveau plus gros ?
P : Non... Une carte bleue suffirait...

Bug#866335: Python3.6 plans​ for Buster

[Scott Kitterman]

On Wednesday, June 28, 2017 11:19:37 PM Scott Kitterman wrote:
> On Friday, June 23, 2017 02:09:34 PM Scott Kitterman wrote:
> > On Saturday, June 17, 2017 04:20:27 AM Scott Kitterman wrote:
...
> > > As a reminder (and for anyone new) we'll do the transition to python3.6
> > > in three stages:
> > >  - Add python3.6 as supported and rebuild all binary extensions to
> > >  support
...
> > Unless I've missed something, I've not heard back from anyone indicating
> > significant issues that would warrant not taking the first step in this
> > plan (I'm aware astropy may have some problems, but that's it).
> > 
> > My plan is to ask the release team for a transition tracker and start the
> > first part of this in Unstable once they've agreed.  If anyone thinks this
> > is premature, please let me know.
> 
> Unless I brown bagged the upload somehow, this is started now.
> 
> https://release.debian.org/transitions/html/python3.6.html

Status update:

Python3-defaults with python3.5 and python3.6 as supported versions is in 
Buster, but python3.6 for the entire ecosystem is not.

All binNMUs have been scheduled and the one arch:all sourceful upload that's 
needed is complete.  According to the release team's tracker the transition is 
85% complete.  There are roughly five classes of things in the remaining 15%:

1.  Builds for leaf packages that are scheduled, but not complete.  Nothing 
needs to be done for these.  The slow architectures will catch up eventually.

2.  Packages which are RC buggy because they can't currently be built on some 
(or all archs) for reasons unrelated to python3.6.  It would be good to NMU to 
fix these if people have time, but they might not be the best use of Python 
packaging oriented people's time.
#866536 jpy FTBFS on mips/mipsel: 1 Python unit test(s) failed. Installation 
is likely broken.
#839760 xcffib: FTBFS on big-endian architectures: assert reply.value. 
to_atoms() == (wm_delete_window, )
#839314 xcffib: FTBFS: xcffibgen: Invalid bitCase: QName {qName = 
"required_start_align", qURI = Nothing, qPrefix = Nothing}
#866543 xcffib: FTBFS after switch to having python3.6 supported
#867018 python-pysam FTBFS with libhts-dev 1.4.1-2
#813083 pyviennacl: FTBFS: src/ viennacl/vector.h:225:34: error: no matches 
converting function ‘project’ to type ‘class viennacl::vector ...
#854195 yt FTBFS on armel/armhf: testsuite MemoryErrors
#867197 yt: FTBFS on ppc64el: test failure
#864443 pytables: ftbfs on armhf
#867028 uvloop FTBFS on armel/armhf: Test_UV_UnixSSL. 
test_create_unix_server_ssl_1 fails

3.  Packages which now FTBFS due to adding python3.6.
#866575 libapache2-mod-wsgi-py3: Impossible depends when built with more then 
one supported python3 version
#862380 khmer: FTBFS with Python 3.6
#862805 protobuf: tests fail with Python 3.6
#866694 pythonmagick: FTBFS with python3.6 as a supported python3
#866696 python-pyeclib: FTBFS on mips64el due to test failures after rebuild 
with python3.6
#865224 uwsgi: ftbfs with multiple supported python3 versions
#866547 python-biomaj3: FTBFS with python3.6 as a supported version
#864327 shiboken: extend test skipping hack to python 3.6

4.  Packages which declare build-depends on python3-all-dev but do not build 
for all python3 verions or don't set their dependencies correctly.
#866412 cinnamon-screensaver: Excessive and hard coded depends complicate 
python3 transition
#866504 django-compat: Excessive build-depends complicate python3 transition 
(maybe rm is the best solution here)
#866555 gpgme1.0: Build for all python3 versions or change build-dep
#866514 ngs.sdk: Excessive build-depends complicate python3 transition
#866700 pcp: Only builds for default python3 version
#866528 python-biotools: Inappropriate use of arch:any vice arch:all
#799635 python-characteristic: Uses python3-all-dev build-dep when python3-all 
is all that's needed
#866533 python-dictobj: Package is arch any when it should be arch all
#867010 python-cassandra-river: Please build for all supported python3 
versions
#800709 gcc-python-plugin: Should build-dep on python3-dev vice all-dev
#867243 python3-astroml: Missing python3 interpreter depends

5.  Things needing further research/work:
python-pbr, nuitka, and pyopenssl are all packages with arch:all content that 
need access to Python.h.  Is there a way to have them not show up as part of 
transition?
Some packages that depend on python3-all-dev, but don't end up depending on 
python3 (<< python3.7) after binNMU still need investigation: eccodes, grib-
api, python-escript, lasagne, sunpy
pycuda (contrib) needs binary upload to rebuild, not autobuilt

Note: because shiboken FTBFS, pyside has not been binNMUed.

Many of these packages are team maintained.  Please jump in and help out where 
you can.  

Scott K

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

Bug#867243: python3-astroml: Missing python3 interpreter depends

[Scott Kitterman]

Package: python3-astroml
Version: 0.2.2-3
Severity: serious
Tags: patch
Justification: Policy 3.5

Python3-astroml is using the python substitution variable for interpreter
depends (easy typo).  See the attached debdiff.  As missing depends are a
policy shall violation, this is a serious bug.  Trivial fix is attached.

Please let me know if you do not want me to NMU.

Scott K
diff -Nru astroml-addons-0.2.2/debian/changelog astroml-addons-0.2.2/debian/changelog
--- astroml-addons-0.2.2/debian/changelog	2016-05-09 16:20:06.0 -0400
+++ astroml-addons-0.2.2/debian/changelog	2017-07-05 00:07:55.0 -0400
@@ -1,3 +1,11 @@
+astroml-addons (0.2.2-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Correct substitution variable for python3 binary so correct python3
+interpreter depends are provided
+
+ -- Scott Kitterman   Wed, 05 Jul 2017 00:07:11 -0400
+
 astroml-addons (0.2.2-3) unstable; urgency=low
 
   * Create Python 3 package
diff -Nru astroml-addons-0.2.2/debian/control astroml-addons-0.2.2/debian/control
--- astroml-addons-0.2.2/debian/control	2016-05-09 16:17:07.0 -0400
+++ astroml-addons-0.2.2/debian/control	2017-07-05 00:08:11.0 -0400
@@ -36,7 +36,7 @@
 
 Package: python3-astroml-addons
 Architecture: any
-Depends: ${misc:Depends}, ${python:Depends}, ${shlibs:Depends}, python3-astroml
+Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}, python3-astroml
 Description: Python 3 Machine Learning library for astronomy (performance addons)
  AstroML is a Python module for machine learning and data mining built on
  numpy, scipy, scikit-learn, and matplotlib. It contains a growing library of

Bug#867242: toolz: autopkgtest broken in 0.8.2-1

[Steve Langasek]

Source: toolz
Version: 0.8.2-1
Severity: important

Dear Diane et al.,

The upload of toolz 0.8.2-1 regressed the autopkgtest in this package, as
shown at .  The test
is now broken as follows:

=== FAILURES ===
___ test_curried_exceptions 

def test_curried_exceptions():
# This tests a global curried object that isn't defined in 
toolz.functoolz
>   merge = pickle.loads(pickle.dumps(toolz.curried.exceptions.merge))
E   AttributeError: module 'toolz.curried' has no attribute 'exceptions'

/usr/lib/python3/dist-packages/toolz/tests/test_serialization.py:65: 
AttributeError
= 1 failed, 174 passed in 1.02 seconds =
adt-run [03:24:50]: test command1: ---]
adt-run [03:24:50]: test command1:  - - - - - - - - - - results - - - - - - - - 
- -
command1 FAIL non-zero exit status 1

While this did not prevent the package's inclusion in the Debian release,
regressed autopkgtests are considered a release blocker for Ubuntu.  Since
previous versions of toolz had working autopkgtests, 0.8.2 will not be
included in Ubuntu releases until this is resolved.

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


signature.asc
Description: PGP signature

Bug#856699: cinnamon: recommends gksu which is deprecated

[Jeremy Bicha]

Control: forwarded -1 https://github.com/linuxmint/Cinnamon/issues/6674

I filed an upstream bug for you.

Thanks,
Jeremy

Bug#864428: RFS: bitfield/0.6.3-1 [ITP #864358]

[Andrew Donnellan]

Hi Vitalie

On 5 July 2017 at 11:55,   wrote:
> Hi, Andrew.
>
>> Obviously you've come first and taken the name
>
> Well, it's not so obvious to me. It looks like it is me, and not the author 
> of the other package, who created the name conflict. The software that you 
> intend to package dates back to 2006 (files in the tarball) or 2009 (commits 
> in the git repo), so it definitely predates mine. When I started my project, 
> I did not know about any other software that would have the same name, be 
> under active development/usage, offer a similar functionality etc. Mea culpa. 
> Had I known about your package, I would (and should) have chosen a different 
> name. I guess, the best thing I can do now is rename my package.
>
>> I guess I'll have to figure out what my package should be called, but just 
>> giving you a
>> heads up that there might be a somewhat similarly named package soon.
>
> I recognize the .. hm ... primogeniture of your package. Please feel free to 
> use the original name.
>
>> If you have any thoughts on what name I should pick to be least
>> confusing, I'd love to know - I'm currently thinking
>> "bitfield-decoder" or something along those lines.
>
> I'm thinking about renaming my ITP and RFS bugs to clear the way for your 
> package, but frankly speaking, I am new to Debian's BTS and have yet to 
> figure out how to go about it.

I don't know, "bitfield" is a pretty generic term and there's probably
a dozen other projects out there by that name. This project is just a
fairly obscure python script that's very much in maintenance mode now,
whereas your library is clearly under active development. I'm inclined
to think that naming priority deserves to go to the project with more
future potential :)

Unless you really really want to come up with a new name, I'm inclined
to submit mine under the name "bitfield-decoder".

-- 
Andrew Donnellan
http://andrew.donnellan.id.au and...@donnellan.id.au

Bug#867241: libatomic-ops: Please add support for arm64ilp32 architecture

[Wookey]

Source: libatomic-ops
Version: 7.4.4-3
Severity: wishlist
Tags: upstream patch

libatomic-ops FTBFS on arm64ilp32 arch. This trival patch fixes that.

It might be better to refactor the code to check for ILP32 on all
64-bit arches that support it rather than this per-arch fix, but I
don't know enough about the codebase to be sure if that is a good
idea. This is a safe, minimal patch.
diff -u libatomic-ops-7.4.4/debian/changelog libatomic-ops-7.4.4/debian/changelog
--- libatomic-ops-7.4.4.orig/src/atomic_ops/sysdeps/standard_ao_double_t.h
+++ libatomic-ops-7.4.4/src/atomic_ops/sysdeps/standard_ao_double_t.h
@@ -32,7 +32,7 @@
   typedef __m128 double_ptr_storage;
 #elif defined(_WIN32) && !defined(__GNUC__)
   typedef unsigned __int64 double_ptr_storage;
-#elif defined(__aarch64__)
+#elif defined(__aarch64__) && !defined(__ILP32__)
   typedef unsigned __int128 double_ptr_storage;
 #else
   typedef unsigned long long double_ptr_storage;

Bug#867239: python-moinmoin: hitcounts pages crash with LookupError: unknown error handler name 'fallback:iso-8859-1'

[Paul Wise]

Package: python-moinmoin
Version: 1.9.8-1+deb8u1
Severity: important
Control: affects -1 wiki.debian.org, python-moinmoin
X-Debbugs-CC: shirish शिरीष , w...@debian.org

shirish शिरीष reported a bug to w...@debian.org:

On Tue, 2017-07-04 at 23:04 +0530, shirish शिरीष wrote:

> was trying to access
> https://wiki.debian.org/ShirishAgarwal?action=info=1 when I
> was hit with
> 
> Internal Server Error

Traceback below, it looks like a MoinMoin bug or a Werkzeug bug.
Werkzeug is meant to offer fallback decoding options but it seems that
in the MoinMoin context they do not work for some reason.

https://web.archive.org/web/20150315091159/http://werkzeug.pocoo.org/docs/0.9/unicode/#error-handling

mod_wsgi (pid=6004): Exception occurred processing WSGI script 
'/srv/wiki.debian.org/bin/moin.wsgi'.
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/werkzeug/wsgi.py", line 588, in 
__call__
return self.app(environ, start_response)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 264, in 
__call__
response = run(context)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 89, in run
response = dispatch(request, context, action_name)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 137, in 
dispatch
response = handle_action(context, pagename, action_name)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 203, in 
handle_action
handler(context.page.page_name, context)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/action/info.py", line 371, in 
execute
request.write(hitcounts.linkto(pagename, request, 'page=' + 
wikiutil.url_quote(pagename)))
  File "/usr/lib/python2.7/dist-packages/MoinMoin/stats/hitcounts.py", line 32, 
in linkto
return text(pagename, request, params)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/stats/hitcounts.py", line 
154, in text
days, views, edits = get_data(pagename, request, filterpage)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/stats/hitcounts.py", line 88, 
in get_data
for event in log.reverse():
  File "/usr/lib/python2.7/dist-packages/MoinMoin/logfile/__init__.py", line 
116, in reverse
result = self.previous()
  File "/usr/lib/python2.7/dist-packages/MoinMoin/logfile/__init__.py", line 
323, in previous
result = self.__previous()
  File "/usr/lib/python2.7/dist-packages/MoinMoin/logfile/__init__.py", line 
312, in __previous
return self.parser(self.__buffer.lines[self.__rel_index])
  File "/usr/lib/python2.7/dist-packages/MoinMoin/logfile/eventlog.py", line 
67, in parser
return long(time_usecs), eventtype, wikiutil.parseQueryString(kvpairs)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wikiutil.py", line 132, in 
parseQueryString
decode_keys=False, include_empty=False)
  File "/usr/lib/python2.7/dist-packages/werkzeug/urls.py", line 644, in 
url_decode
include_empty, errors))
  File "/usr/lib/python2.7/dist-packages/werkzeug/datastructures.py", line 373, 
in __init__
for key, value in mapping or ():
  File "/usr/lib/python2.7/dist-packages/werkzeug/urls.py", line 703, in 
_url_decode_impl
yield key, url_unquote_plus(value, charset, errors)
  File "/usr/lib/python2.7/dist-packages/werkzeug/urls.py", line 478, in 
url_unquote_plus
return url_unquote(s, charset, errors)
  File "/usr/lib/python2.7/dist-packages/werkzeug/urls.py", line 457, in 
url_unquote
rv = rv.decode(charset, errors)
  File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
LookupError: unknown error handler name 'fallback:iso-8859-1'

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#867240: openssl: Please add support for arm64ilp32 architecture

[Wookey]

Package: openssl
Version: 1.1.0f-3
Severity: wishlist
Tags: patch


This package FTBFS on arm64ilp32. The package has upstream support
already. It just needs the correct debian target conf information adding. 
"debian-arm64ilp32" => {
 inherit_from => [ "linux-arm64ilp32", "debian" ],
 },

A patch is attached.
diff -ur openssl-1.1.0f.orig/debian/patches/debian-targets.patch openssl-1.1.0f/debian/patches/debian-targets.patch
--- openssl-1.1.0f.orig/debian/patches/debian-targets.patch	2017-07-05 01:59:23.544491508 +
+++ openssl-1.1.0f/debian/patches/debian-targets.patch	2017-07-05 02:10:22.429206874 +
@@ -4,7 +4,7 @@
 
 --- /dev/null
 +++ b/Configurations/20-debian.conf
-@@ -0,0 +1,137 @@
+@@ -0,0 +1,140 @@
 +my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . "-Wa,--noexecstack -Wall";
 +$debian_cflags =~ s/\n/ /g;
 +my $debian_ldflags = `dpkg-buildflags --get LDFLAGS`;
@@ -30,6 +30,9 @@
 +	"debian-arm64" => {
 +		inherit_from => [ "linux-aarch64", "debian" ],
 +	},
++	"debian-arm64ilp32" => {
++		inherit_from => [ "linux-arm64ilp32", "debian" ],
++	},
 +	"debian-armel" => {
 +		inherit_from => [ "linux-armv4", "debian" ],
 +	},

Bug#867238: ITP: ocaml-sedlex -- Unicode-friendly lexer generator for OCaml

[Andy Li]

Package: wnpp
Severity: wishlist
Owner: Andy Li 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

* Package name: ocaml-sedlex
  Version : 1.99.3
  Upstream Author : Alain Frisch 
* URL : https://github.com/alainfrisch/sedlex
* License : MIT
  Programming Lang: OCaml
  Description : Unicode-friendly lexer generator for OCaml

sedlex is a lexer generator for OCaml, similar to ocamllex, but supporting
Unicode. Contrary to ocamllex, lexer specifications for sedlex are embedded in
regular OCaml source files.

This is a dependency of the next version of Haxe (v4.0.0).
I　will co-maintain it with the Debian OCaml Maintainers team.




-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJZXE7JAAoJENYPsCrEEWxpKzgH/0vBxrZWmS0OAEJr1biFzLae
pieuhg1hGljApr38xMhABoOOOaDVp4dRh3hEXfKoTFRqYVLb5TfzuvJ4sYLMPNYK
CPkkUK4DeufeaQUBobmgSy9SUO7ckTt05SsaIsVsxjyIoMPaVQt3vUMQKEMHBHAq
H3CRZfflQ2Auky9QEP61griJvKt4srSE1Dwpr1vlGMr6iYFhu/fi4Sl9zdNik9BV
EBdArgO/mDhZUmIixHwKY01TmjWPwByarSlkObnzb4CpUgEnGpybc+N8LbM5DFw7
L/eOONKXZf4ixZCipKwHQ66NbcW/NlIvNNUaSKNeDI64Cc2HWm9vSQ59S5Q2KC0=
=ZxkU
-END PGP SIGNATURE-

Bug#864428: RFS: bitfield/0.6.3-1 [ITP #864358]

[vitalie]

Hi, Andrew.

> Obviously you've come first and taken the name

Well, it's not so obvious to me. It looks like it is me, and not the author of 
the other package, who created the name conflict. The software that you intend 
to package dates back to 2006 (files in the tarball) or 2009 (commits in the 
git repo), so it definitely predates mine. When I started my project, I did not 
know about any other software that would have the same name, be under active 
development/usage, offer a similar functionality etc. Mea culpa. Had I known 
about your package, I would (and should) have chosen a different name. I guess, 
the best thing I can do now is rename my package.

> I guess I'll have to figure out what my package should be called, but just 
> giving you a
> heads up that there might be a somewhat similarly named package soon.

I recognize the .. hm ... primogeniture of your package. Please feel free to 
use the original name.

> If you have any thoughts on what name I should pick to be least
> confusing, I'd love to know - I'm currently thinking
> "bitfield-decoder" or something along those lines.

I'm thinking about renaming my ITP and RFS bugs to clear the way for your 
package, but frankly speaking, I am new to Debian's BTS and have yet to figure 
out how to go about it.

Best regards,

Vitalie Ciubotaru

Bug#865882: lintian: Why is debian-rules-parses-dpkg-parsechangelog a wishlist?

[Guillem Jover]

Hi!

On Tue, 2017-07-04 at 18:02:00 +, Niels Thykier wrote:
> Guillem Jover:
> > Ah, I think it would be nice to explain something along these lines
> > in the tag. I was rather confused by why the Makefile fragment was
> > recommended over a simple already correct call.
> > 
> > I'm also aware of few people who have a problem with the fragment as
> > an interface. So having lintian emit tags over those and stating that
> > they should be switched to the fragment might annoy people.
> 
> Even with all the optimizations we have made in Debian (well, mostly
> you), the "simple correct call" would still cause #793404 to a much
> higher degree than the Makefile fragment that uses careful lazy
> evaluation, wouldn't it?

Ah very good point, certainly! :) Ok, then if this is also reflected
in the tag description, I'm fine, and if people are annoyed they can
just override it or something.

Thanks,
Guillem

Bug#867237: rakudo lost readline support.

[Charles Plessy]

Package: rakudo
Version: 2017.06-1
Severity: minor

Dear rakudo maintainers,

in Jessie's version of the REPL, it is possible to edit the current
line and recall the previous lines using the arrow keys.  This does
not seem to be possible anymore with the versions in Stretch and Sid,
which give the following messages when entering the REPL.

You may want to `zef install Readline` or `zef install Linenoise` or use rlwrap 
for a line editor

The `zef` program does not seem to be distributed in Debian.

I there an easy way to re-enable readline support in perl6 ?

Have a nice day,

--
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid

[Breno Leitao]

Hi Ryan,

On Mon, Jul 03, 2017 at 03:39:35PM -0700, Ryan Tandy wrote:
> Hi debian-powerpc,
>
> Would a ppc64(el) porter be able to help me look at #866122? I have
> requested a porterbox account but it's not gone through yet, and I am unable
> to reproduce the issue at all in a qemu VM.

You can also request a VM on the minicloud at
http://openpower.ic.unicamp.br/minicloud/ if you wish. They are usually
quick on creating accounts.

> The openldap test suite is failing on ppc64 and ppc64el in stretch and
> unstable: the slapd-mtread helper program segfaults (exit 139) in a certain
> test case.
>
> It looks like the builds tend to succeed on jessie's kernel and fail on
> stretch's kernel:

In fact, this problem seems to reproduce once in a while, thus, I would
not trust that it might be related to the kernel/gcc combination at this
very beginning. I am suspecting that it might be related to the amount
of threads created and the order, but I do not have a conclusion yet.
Still investigating.

>  apt-get build-dep openldap
>  apt-get source openldap
>  cd openldap-*/
>  DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -T build
>  cd debian/build/tests
>  ./run -b bdb test060-mt-hot

Nice. I was able to reproduce it and debug it further. The problem seems
to be related to a invalid branch/jump, the the next address is not
memory mapped, thus the segfault. The new address is completely random,
and definitely is wrong. The link register (LR), which is register that
shows the return of the branch (similar to call() on amd64) is always
constant when ALSR is disabled. Other than that, I also saw a stack
corruption, which caused the backtrace to be completely bogus.

Anyway, myself and a colleague are still investigating this problem. I will keep
you informed of the progress of this issue.

Thanks,
Breno

Bug#592834: Grub messages during upgrade

[alsauser]

On Thu, 09 Mar 2017 19:57:36 +0800 Steve M  wrote:
> Last couple of upgrades have seen similar results to the below:
> 
> Generating grub configuration file ...
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9473: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9473: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9486: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9486: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9499: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9499: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9512: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9512: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9572: 
> /usr/sbin/grub-probe
> File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9572: 
> /usr/sbin/grub-probe

I am experiencing the exact same messages.  Brand new Debian Stretch install, 
root file system installed on LVM volume.  Messages occur during subsequent 
apt-get install of mdadm package from "official" Debian 9.0.0 BluRay DVD (the 
apt-get install was performed immediately after a successful shutdown and 
reboot).  Same "pairs" of Parent PIDS: 1308,1308, 1338,1338, 1368,1368, 
1398,1398, then 1563, etc.

Bug#867135: ejabberd install fails with NO_NEW_PRIVILEGES exit code

[ozzloy]

hi,
i do have erlang-p1-pam installed, and i do still have the default config in
/etc/ejabberd/ejabberd.yml
i'm not sure how i'm supposed to edit the file during the
 apt-get install process.  maybe that's not what's being suggested.

thanks for the link!  i finally got ejabberd to cleanly install.
the process wasn't quite as described in the readme though.

* super short summary
  to get a clean install of ejabberd, the file
  /etc/systemd/system/ejabberd.service.d/override.conf
  should have the contents:

[Service]
PrivateDevices=false
NoNewPrivileges=false

  _before_ issuing 'apt-get install ejabberd'.

  i think either the install process should just do it automatically,
  or it should not try to start ejabberd and instead tell the user
  that they need to modify that file and how to start ejabberd once
  they have.

  that's what i think, but i wouldn't be surprised if i was wrong.

  short aside:

http://git.deb.at/w/pkg/ejabberd.git/blob/refs/heads/stretch:/debian/README.Debian#l154
  "PrivateDevices=\n" is, afaik, wrong and should be deleted.  same for
  line 156, "NoNewPrivileges=\n"

* summary of actions shown below
  - uninstall ejabberd, remove config files in /etc/systemd/system
  - attempt install ejabberd with no config files, it fails
  - show systemctl and journalctl after failed install
  - systemctl edit ejabberd.service as suggested by

http://git.deb.at/w/pkg/ejabberd.git/blob/refs/heads/stretch:/debian/README.Debian#l153
  - systemctl daemon-reload as suggested by README.Debian
  - systemctl status after daemon-reload shows ejabberd process active
- lines 2 and 4 are broken, output has complaint about not being
  able to parse boolean

http://git.deb.at/w/pkg/ejabberd.git/blob/refs/heads/stretch:/debian/README.Debian#l154
  and

http://git.deb.at/w/pkg/ejabberd.git/blob/refs/heads/stretch:/debian/README.Debian#l156
  - journalctl complains about non-parsed booleans too
  - remove ejabberd again and leave systemd config
  - reinstall ejabberd with
/etc/systemd/system/ejabberd.service.d/override.conf
in place before starting apt-get install

* long version of actions, along with output

ozzloy% 
ozzloy% 
ozzloy% # uninstall ejabberd, remove config files in /etc/systemd/system
ozzloy% sudo apt-get --autoremove remove -y ejabberd
[sudo] password for ozzloy:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
  ejabberd erlang-odbc
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 6,648 kB disk space will be freed.
(Reading database ... 228172 files and directories currently installed.)
Removing ejabberd (16.09-4) ...

The ejabberd database has been backed up to
/var/backups/ejabberd-2017-07-04T14:52:54.uj8Nma/ejabberd-database.

Removing erlang-odbc (1:19.2.1+dfsg-2) ...
Processing triggers for man-db (2.7.6.1-2) ...
ozzloy%
ozzloy%
ozzloy% ls -l /etc/systemd/system/ejabberd.service
lrwxrwxrwx 1 root root 9 Jul  4 14:53 /etc/systemd/system/ejabberd.service
-> /dev/null
ozzloy%
ozzloy%
ozzloy% sudo rm -rf /etc/systemd/system/ejabberd.service{,.d}
ozzloy%
ozzloy% 
ozzloy% 
ozzloy% # attempt install ejabberd with no config files, it fails
ozzloy% sudo apt-get install -y ejabberd
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  erlang-odbc
Suggested packages:
  apparmor apparmor-utils libunix-syslog-perl yamllint ejabberd-contrib
  erlang-luerl erlang-p1-oauth2 erlang-p1-sqlite3 erlang-redis-client erlang
  erlang-manpages erlang-doc
The following NEW packages will be installed:
  ejabberd erlang-odbc
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/3,896 kB of archives.
After this operation, 6,648 kB of additional disk space will be used.
Preconfiguring packages ...
Selecting previously unselected package erlang-odbc.
(Reading database ... 227821 files and directories currently installed.)
Preparing to unpack .../erlang-odbc_1%3a19.2.1+dfsg-2_amd64.deb ...
Unpacking erlang-odbc (1:19.2.1+dfsg-2) ...
Selecting previously unselected package ejabberd.
Preparing to unpack .../ejabberd_16.09-4_amd64.deb ...
Unpacking ejabberd (16.09-4) ...
Processing triggers for systemd (232-25) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up erlang-odbc (1:19.2.1+dfsg-2) ...
Setting up ejabberd (16.09-4) ...
Job for ejabberd.service failed because the control process exited with
error code.
See "systemctl status ejabberd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript ejabberd, action "restart" failed.
● ejabberd.service - A distributed, fault-tolerant Jabber/XMPP server
   Loaded: loaded 

Bug#867207: xdmx: crashes after (TimerForce+0x10)

[Michel Dänzer]

On 05/07/17 03:16 AM, ptizoom wrote:
> Package: xdmx
> Version: 2:1.19.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I have nothing better to try xdmx, but hey, this package seem to be obsolete.
> 
> here I have produced 2 setups with same sort of crash...
> 
> 
> -on a master machine in an kde desktop I create an Xnested window: 
> 
>  Xnest :14 &
>  
> -then on master still same kdeterminal I run:
>  
>   startx -- /usr/bin/Xdmx :10 -display :14
> 
> which crashes with ...
>  (II) dmx: Generation: 1
>  (II) dmx: DMX version:1.2.20070424 (DMX Project)
>  (II) dmx: DMX Build OS:   Linux 3.16.0-4-amd64 x86_64 (Debian)
>  (II) dmx: DMX Build Compiler: gcc 6.3.0
>  (II) dmx: DMX Execution OS:   Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.25-1 
> (2017-05-02)
>  (II) dmx: DMX Execution Host: master
>  (II) dmx: MAXSCREENS: 16
>  (II) dmx: Using configuration from command line
>  (II) dmx: Added :14 at 0 0
>  (II) dmx[o0/:14]: Name of display: :14
>  (II) dmx[o0/:14]: Version number:  11.0
>  (II) dmx[o0/:14]: Vendor string:   The X.Org Foundation
>  (II) dmx[o0/:14]: Vendor release:  11903000
>  (II) dmx[o0/:14]: Dimensions:  320x200 pixels
>  (II) dmx[o0/:14]: 2 depths on screen 0:  1,24
>  (II) dmx[o0/:14]: Depth of root window:  24 planes (24)
>  (II) dmx[o0/:14]: Number of colormaps:   1 min, 1 max
>  (II) dmx[o0/:14]: Options: backing-store no, save-unders no
>  (II) dmx[o0/:14]: Window Manager running: no
>  (II) dmx[o0/:14]: 320x200+0+0 on 320x200 at depth=24, bpp=32
>  (II) dmx[o0/:14]: 0x20 TrueColor   24b 11b/rgb 256 0xff 0xff00 0x00ff *
>  (II) dmx[o0/:14]: 0x21 DirectColor 24b 11b/rgb 256 0xff 0xff00 0x00ff
>  (II) dmx[o0/:14]: DPMS not supported
>  (EE) 
>  (EE) Backtrace:
>  (EE) 0: /usr/bin/Xdmx (xorg_backtrace+0x4a) [0x5619e528402a]
>  (EE) 1: /usr/bin/Xdmx (0x5619e5118000+0x16fdd9) [0x5619e5287dd9]
>  (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff65bb7+0x110c0) 
> [0x7ff65bb810c0]
>  (EE) 3: /usr/bin/Xdmx (TimerForce+0x10) [0x5619e5281ad0]
>  (EE) 4: /usr/bin/Xdmx (0x5619e5118000+0x41be1) [0x5619e5159be1]
>  (EE) 5: /usr/bin/Xdmx (0x5619e5118000+0x337a5) [0x5619e514b7a5]
>  (EE) 6: /usr/bin/Xdmx (0x5619e5118000+0x40b07) [0x5619e5158b07]
>  (EE) 7: /usr/bin/Xdmx (0x5619e5118000+0x40f75) [0x5619e5158f75]
>  (EE) 8: /usr/bin/Xdmx (AddScreen+0xd7) [0x5619e524d787]
>  (EE) 9: /usr/bin/Xdmx (InitOutput+0x40f) [0x5619e51534df]
>  (EE) 10: /usr/bin/Xdmx (0x5619e5118000+0x1392e6) [0x5619e52512e6]
>  (EE) 11: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf1) 
> [0x7ff65b7f12b1]
>  (EE) 12: /usr/bin/Xdmx (_start+0x2a) [0x5619e51471aa]
>  (EE) 
>  (EE) Segmentation fault at address 0x0

Looks like
https://cgit.freedesktop.org/xorg/xserver/commit/?id=21eda7464d0e13ac6558edaf6531c3d3251e05df
should fix this.


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

Bug#867104: wanna-build issue with src:perl versioned Provides

[Guillem Jover]

Hi!

On Tue, 2017-07-04 at 23:30:37 +0300, Niko Tyni wrote:
> On Tue, Jul 04, 2017 at 10:18:08PM +0200, Ralf Treinen wrote:
> > On Tue, Jul 04, 2017 at 10:29:35PM +0300, Niko Tyni wrote:
> > > On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote:
> > > 
> > > > thanks for having figured that out. I tend to believe that dose is right
> > > > in this case. Since it is not possible to install at the same
> > > > time two different versions of the same real package, the same should
> > > > IMHO hold when one is real and the other virtual. Why should this be
> > > > possible?

Because it follows the same principle that you can have installed both
the real package and various virtual packages providing that one. This
just takes this further and gives it version(s) too.

> > > Well, dpkg and apt allow it for starters.

Yes.

> > > The idea with the perl packages is that the src:perl binary packages
> > > offer an older "stable" version of some modules while a newer version is
> > > packaged separately and gets installed earlier on the Perl search path
> > > (so it overrides the src:perl version when installed.)
> > > 
> > > This has been the case for ages with the src:perl packages Providing
> > > an unversioned virtual package. The change here is that the virtual
> > > package is now versioned, which would simplify lots of dependencies
> > > that currently read like (for instance)
> > 
> > So, that means that something like
> > 
> > Depends: p (=1), p (=2)
> > 
> > suddenly becomes satisfiable (when there is one real package p and
> > one virtual package)? Would you also allow to have the packages p
> > and q installed at the same time, in the following situation:
> > 
> > Package: p
> > Version: 1
> > Provides: v (=1)
> > 
> > Package: q
> > Version: 1
> > Provides: v (=2)

Yes, this is correct.

If this is not desirable, one could always Conflicts/Breaks on the
virtual package from within each provider for example.

> > If yes this seems to me a quite drastic change of the meaning of 
> > package relations. Has this been discussed somewhere?

Not in recent times, no, the bug requesting versioned provides was a
bit aged. But the semantics are IMO the obvious ones, and I'm actually
a bit surprised they are surprising! :)

The fact that you can concoct strange or invalid relationships does not
mean one has to do it. You could also for example Depends and Conflicts
on the same package and similar.

> Not that I know of. I've been just going by what works with dpkg and
> apt. If this is something that has only been made possible accidentally,
> I'll of course back up the src:perl changes.

This was pretty much intentional. And the usage in perl seems completely
as this was implemented for.

Thanks,
Guillem

Bug#747047: unetbootin: Raising severity to serious for packages recommending gksu

[Jeremy Bicha]

Control: severity -1 serious
Control: tags -1 +sid +buster
Control: user pkg-gnome-maintain...@lists.alioth.debian.org
Control: usertag +oldlibs +gksu

For the next major stable release of Debian (codenamed "buster"), the
Debian GNOME team plans to default to GNOME on Wayland where gksu does
not work. We do not intend to release "buster" with gksu. Therefore, I
am raising the severity of this issue to serious.

Please drop unetbootin's dependency on gksu because the Debian GNOME
team plans to remove gksu from Debian soon.


On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#856699: cinnamon: Raising severity to serious for packages recommending gksu

[Jeremy Bicha]

Control: severity -1 serious
Control: tags -1 -stretch +buster

For the next major stable release of Debian (codenamed "buster"), the
Debian GNOME team plans to default to GNOME on Wayland where gksu does
not work. We do not intend to release "buster" with gksu. Therefore, I
am raising the severity of this issue to serious.

Please drop cinnamon's recommends on gksu because the Debian GNOME
team plans to remove gksu from Debian soon.


On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#822593: Raising severity to serious for packages depending on gksu

[Jeremy Bicha]

Control: severity -1 serious
Controls: tags -1 -stretch +buster

For the next major stable release of Debian (codenamed "buster"), the
Debian GNOME team plans to default to GNOME on Wayland where gksu does
not work. We do not intend to release "buster" with gksu. Therefore, I
am raising the severity of this issue to serious.

Please drop the dependency on gksu because the Debian GNOME team plans
to remove gksu from Debian soon.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#822595: Raising severity to serious for packages depending on gksu

[Jeremy Bicha]

Control: severity -1 serious
Control: tags -1 -stretch +buster

For the next major stable release of Debian (codenamed "buster"), the
Debian GNOME team plans to default to GNOME on Wayland where gksu does
not work. We do not intend to release "buster" with gksu. Therefore, I
am raising the severity of this issue to serious.

Please drop the dependency on gksu because the Debian GNOME team plans
to remove gksu from Debian soon.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#790222: wxwidgets3.0: depends on libwebkitgtk-1.0-0 which is deprecated

[Olly Betts]

On Sat, Jul 01, 2017 at 08:23:08PM -0400, Jeremy Bicha wrote:
> On Fri, Jun 30, 2017 at 8:47 PM, Olly Betts  wrote:
> > It seems the only rdep needing the webkit integration is boinc, so
> > dropping support would not cause widespread pain - if it gets to the
> > stage where wxwidgets3.0 is blocking removal of webkitgtk, I suggest
> > we just drop the dependency and the libwxgtk-webview3.0-0v5, etc
> > packages and get boinc to update not to use them.
> 
> Wouldn't libwxgtk-webview3.0-0v5 need to be renamed anyway? So maybe
> it's ok to drop it and later you can reintroduce it with the new name
> when you're ready to do your transition.

If there's an ABI change, it'll need renaming.  It's not clear to me if
there will be one without further investigation.

Either way, dropping it would affect boinc in unstable while it's gone,
which is really more of a concern than a trip through NEW.  I don't know
what boinc does with webview, so I'm not sure if removing it renders
boinc almost useless or if it only affects some minor features, but
previously Gianfranco seemed unkeen on dropping it.  I've CCed him.

Cheers,
Olly

Bug#867236: gksu: Unsuitable for release in buster

[Jeremy Bicha]

Package: gksu
Version: 2.0.2-9
Severity: serious
Usertags: oldlibs gksu
Tags: sid buster

gksu has been deprecated for years. The intent of gksu is to allow
running apps with elevated privileges but the way to do that is for
the app developer to use PolicyKit to request elevated privileges for
the specific actions that need done instead of for the whole app to
run as root.

For the next major stable release of Debian (codenamed Buster), the
Debian GNOME team plans to default to GNOME on Wayland where gksu does
not even work.

Therefore, the Debian GNOME team intends to either remove gksu or
replace it with a non-functional warning message. gksu is unmaintained
(last upload 2014) and is a security vulnerability.

On behalf of the Debian GNOME team,
Jeremy

Bug#867235: avr-libc: Fails to find iom328pb.h

[Paul "LeoNerd" Evans]

Package: avr-libc
Version: 1:2.0.0+Atmel3.5.4-1
Severity: normal
Tags: patch

Attempting to build a program for the new ATmega328PB, it seems the
device-specific IO file is not found:

avr-gcc -std=gnu99 -Wall -Os -DF_CPU=1600 -mmcu=atmega328pb -flto 
-ffunction-sections ...
In file included from src/test.c:1:0:
/usr/lib/avr/include/avr/io.h:623:6: warning: #warning "device type not 
defined" [-Wcpp]
 #warning "device type not defined"
  ^

I do have the required iom328pb.h file though:

-rw-r--r-- 1 root root 27K Jul 22  2016 /usr/lib/avr/include/avr/iom328pb.h

Further, I see that iom328pb.h isn't listed in the big long section of
#ifdef-guarded #includes in the main io.h. I see there is an attempted
generic fallback section based on value of __AVR_DEV_LIB_NAME__ but it
seems for whatever reason that isn't kicking in today.

If I simply add the required 2 lines (by copying the 328P example), my
code will compile fine. Attached is my patch.


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages avr-libc depends on:
ii  binutils-avr  2.26.20160125+Atmel3.5.3-1
ii  gcc-avr   1:4.9.2+Atmel3.5.4-1

avr-libc recommends no packages.

avr-libc suggests no packages.

-- no debconf information
--- /usr/lib/avr/include/avr/io.h.orig	2017-07-05 00:48:35.739212601 +0100
+++ /usr/lib/avr/include/avr/io.h	2017-07-05 00:47:21.191361651 +0100
@@ -270,6 +270,8 @@
 #  include   
 #elif defined (__AVR_ATmega328P__)
 #  include 
+#elif (defined __AVR_ATmega328PB__)
+#  include 
 #elif (defined __AVR_ATmega328__)
 #include 
 #elif defined (__AVR_ATmega329__)

Bug#866996: kde-style-breeze: [fixed upstream] dark themes lowlight active tab instead of highlighting

[Nicholas D Steeves]

Control: affects -1 kwin-style-breeze
Control: tags -1 patch

Attached are patches for the Debian packaging.  I've have tested them
with both light and dark themes and can confirm that it closes this
bug.

Also, I've marked this bug as also affecting kwin-style-breeze because
this patch has another very welcome effect!  It fixes annoying
behaviour where the active window title bar is lowlighted and all
inactive windows are highlighted; I can imagine would be really
annoying for people who do window management with a mouse rather than
keyboard.

Cheers,
Nicholas
From 1a215d224f280e5ee374455d496296c9cb062993 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 4 Jul 2017 19:43:51 -0400
Subject: [PATCH 1/2] Import upstream patch that fixes highlighting of active
 tab (Closes: #866996)

---
 ...e-Shadow-instead-of-QPalette-Text-to-dark.patch | 22 ++
 debian/patches/series  |  1 +
 2 files changed, 23 insertions(+)
 create mode 100644 debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch b/debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
new file mode 100644
index 000..3dc2ce6
--- /dev/null
+++ b/debian/patches/0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
@@ -0,0 +1,22 @@
+From: Hugo Pereira Da Costa 
+Date: Tue, 21 Feb 2017 10:30:18 +0100
+Subject: Use QPalette::Shadow instead of QPalette::Text to darken inactive
+ tabs BUG:373088
+
+---
+ kstyle/breezestyle.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kstyle/breezestyle.cpp b/kstyle/breezestyle.cpp
+index d3f6d46..b687c3f 100644
+--- a/kstyle/breezestyle.cpp
 b/kstyle/breezestyle.cpp
+@@ -5549,7 +5549,7 @@ namespace Breeze
+ 
+ } else {
+ 
+-const QColor normal( _helper->alphaColor( palette.color( QPalette::WindowText ), 0.2 ) );
++const QColor normal( _helper->alphaColor( palette.color( QPalette::Shadow ), 0.2 ) );
+ const QColor hover( _helper->alphaColor( _helper->hoverColor( palette ), 0.2 ) );
+ if( animated ) color = KColorUtils::mix( normal, hover, opacity );
+ else if( mouseOver ) color = hover;
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..0d04457
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Use-QPalette-Shadow-instead-of-QPalette-Text-to-dark.patch
-- 
2.11.0

From a773e69bd8fd98595d99e354739fe65ef3c7a69f Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves 
Date: Tue, 4 Jul 2017 19:45:42 -0400
Subject: [PATCH 2/2] Update changelog

---
 debian/changelog | 8 
 1 file changed, 8 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a0df2f7..5885074 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+breeze (4:5.8.5-2+debu9u1) UNRELEASED; urgency=medium
+
+  [ Nicholas D Steeves ]
+  * Import upstream patch that fixes highlighting of active tab. (Closes:
+#866996)
+
+ -- Nicholas D Steeves   Tue, 04 Jul 2017 19:44:41 -0400
+
 breeze (4:5.8.5-2) unstable; urgency=medium
 
   * Release to unstable.
-- 
2.11.0



signature.asc
Description: Digital signature

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

[Sascha Steinbiss]

Hi Michael,

> I have a fix checked in as part of the 2.1-1 release, but it is blocked
> on me uploading a python3 version of sphinx-guzzle

Ah I see -- thanks, won't pursue this anymore then :)

Cheers
Sascha

> Pe 4 iul. 2017 23:12, "Sascha Steinbiss"  > a scris:
> 
> Hi all,
> 
> >> I've applied this patch to get the build working now that Python
> 3.6 is a
> >> supported version in Ubuntu. I admit I don't entirely understand
> why it is
> >> necessary! Maybe you do? :)
> >>
> > Now that python3.6 is supported in Debian, khmer FTBFS:
> >
> >
> 
> https://buildd.debian.org/status/fetch.php?pkg=khmer=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0
> 
> 
> 
> Does anyone know more about this issue? Otherwise I'd be inclined to
> simply apply the patch in BTS to get the bug fixed...
> 
> Kind regards
> Sascha
> 

Bug#867234: Missing man page

[Benjamin Barenblat]

Package: haskell-stack
Version: 1.1.2-8
Severity: important
Tags: upstream
Forwarded: https://github.com/commercialhaskell/stack/issues/2308

`stack` ought to have a man page.

Bug#867233: ITP: golang-github-google-go-github -- Go library for accessing the GitHub API

[Patrick O'Doherty]

Package: wnpp
Severity: wishlist
Owner: Patrick O'Doherty 

* Package name: golang-github-google-go-github
  Version : 0.0~git20170604.0.7a51fb9-1
  Upstream Author : Google
* URL : https://github.com/google/go-github
* License : BSD-3-Clause 
  Programming Lang: Go
  Description : Go library for accessing the GitHub API
 go-github go-github is a Go client library for accessing the GitHub API
 (https://developer.github.com/v3/).

Bug#867231: stretch-pu: package openstack-debian-images/1.19

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Wed, 2017-07-05 at 00:40 +0200, Thomas Goirand wrote:
> Steve found out that the OpenStack images do not include the security
> update repositories by default in Stretch (though it's ok for Wheezy
> and Jessie). This was fixed in version 1.20 of openstack-debian-images
> which I uploaded to sid. It's this commit:
> 
> https://anonscm.debian.org/cgit/openstack/openstack-debian-images.git/commit/?id=2a78166a6c4ee5ee2b25dc5ed37323f761337bbd
> 
> It's not as bad as it sounds though, because as soon as you boot the
> image, cloud-init manages the sources.list and add the security
> repositories, then performs an update. Though I still believe this
> deserves a fix ASAP anyway.
> 
> Would it be ok to just get version 1.20 into the next point release?
> Or should I prepare the exact same change in a 1.19+deb9u1 version
> (which IMO would be missleading)?

We can't "just get" a package from unstable into a point release. It
needs reuploading via proposed-updates, whether as 1.19+deb9u1 or
1.20~deb9u1. I fail to see why this package should be different from
every other in that respect.

As usual, please provide a debdiff of the proposed source package, built
and tested on stable, so that it can be confirmed.

Regards,

Adam

Bug#867188: glx-alternative-nvidia: libEGL.so and libEGL.so.1 point to different libraries

[Luca Boccassi]

On Tue, 2017-07-04 at 21:36 +0600, Aleksandr Mezin wrote:
> Package: glx-alternative-nvidia
> Version: 0.7.4
> Severity: normal
> 
> Dear Maintainer,
> 
> On my system /usr/lib/x86_64-linux-gnu/libEGL.so and /usr/lib/x86_64-
> linux-
> gnu/libEGL.so.1 point to different libraries:
> /usr/lib/x86_64-linux-gnu/libEGL.so -> /etc/alternatives/glx--
> libEGL.so-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-
> gnu/libEGL.so
> /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> /etc/alternatives/glx--
> libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-
> gnu/nvidia/libEGL.so.1
> 
> The same is true for libGL:
> /etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> /usr/lib/mesa-
> diverted/x86_64-linux-gnu/libGL.so
> /etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu ->
> /usr/lib/x86_64-linux-
> gnu/nvidia/libGL.so.1
> 
> and libGLESv2:
> /etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu ->
> /usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
> /etc/alternatives/glx--libGLESv2.so-x86_64-linux-gnu ->
> /usr/lib/mesa-
> diverted/x86_64-linux-gnu/libGLESv2.so
> 
> So applications that try to dlopen() libEGL.so, libGL.so, or
> libGLESv2.so load
> wrong library and fall back to slow softpipe.
> 
> update-glx is in "automatic" mode, 0 = /usr/lib/nvidia:
> 
> $ sudo update-glx --config glx
> There are 3 choices for the alternative glx (providing /usr/lib/glx).
> 
>   SelectionPath   Priority   Status
> 
> * 0/usr/lib/nvidia 100   auto mode
>   1/usr/lib/mesa-diverted  5 manual mode
>   2/usr/lib/nvidia 100   manual mode
>   3/usr/lib/nvidia/bumblebee   95manual mode

Hi,

This is intended IIRC.

That's because application should build and link against the Mesa
libraries, not the NVIDIA ones.

Applications that manually dlopen() should load the versioned SO as
well, as if/when the ABI compatibility breaks the application is likely
going to break too.

Kind regards,
Luca Boccassi

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

Bug#867232: debian-installer: Does not ask for network mirror when installing from DLBD image

[M. Buecher]

Package: debian-installer
Version: Debian 9.0.0 Stretch DLBD #1
Severity: important
Tags: d-i

Dear Maintainer,

when installing Debian from a DLBD image, then debian-installer does not
ask if a network mirror should be used, leaving /etc/apt/sources.list only
populated with the security repository and missing the standard and
stretch-update repositories.

I would expect to be asked for a network error, as it is when using a DVD
image, so that the normal and stretch-update repositories are correctly
set up in /etc/apt/sources.list.

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

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

Bug#867231: stretch-pu: package openstack-debian-images/1.19

[Thomas Goirand]

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

Dear release team,

Steve found out that the OpenStack images do not include the security
update repositories by default in Stretch (though it's ok for Wheezy
and Jessie). This was fixed in version 1.20 of openstack-debian-images
which I uploaded to sid. It's this commit:

https://anonscm.debian.org/cgit/openstack/openstack-debian-images.git/commit/?id=2a78166a6c4ee5ee2b25dc5ed37323f761337bbd

It's not as bad as it sounds though, because as soon as you boot the
image, cloud-init manages the sources.list and add the security
repositories, then performs an update. Though I still believe this
deserves a fix ASAP anyway.

Would it be ok to just get version 1.20 into the next point release?
Or should I prepare the exact same change in a 1.19+deb9u1 version
(which IMO would be missleading)?

Cheers,

Thomas Goirand (zigo)

Bug#865588: [Python-modules-team] Bug#865588: djangorestframework FTBFS with Django 1.11: ERROR collecting tests/test_fields.py

[Brian May]

Currently getting this error building the latest version - as in the
Debian git package.

Possibly this is because we depend on a package that needs updating -
mostly likely mkdocs or jinja2 - but wonder which one?  Maybe we should
just update both anyway.

# Build the HTML documentation.
mkdir /<>/docs.debian
LC_ALL=C.UTF-8 PYTHONPATH=/usr/share/mkdocs/themes mkdocs build && mv site 
docs.debian/html
INFO-  Building documentation to directory: /<>/site 
Traceback (most recent call last):
  File "/usr/bin/mkdocs", line 9, in 
load_entry_point('mkdocs==0.15.3', 'console_scripts', 'mkdocs')()
  File "/usr/lib/python3/dist-packages/click/core.py", line 716, in __call__
return self.main(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/click/core.py", line 696, in main
rv = self.invoke(ctx)
  File "/usr/lib/python3/dist-packages/click/core.py", line 1060, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/lib/python3/dist-packages/click/core.py", line 889, in invoke
return ctx.invoke(self.callback, **ctx.params)
  File "/usr/lib/python3/dist-packages/click/core.py", line 534, in invoke
return callback(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/mkdocs/__main__.py", line 137, in 
build_command
), clean_site_dir=clean)
  File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 290, in 
build
build_pages(config)
  File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 234, in 
build_pages
build_template('404.html', env, config, site_navigation)
  File "/usr/lib/python3/dist-packages/mkdocs/commands/build.py", line 149, in 
build_template
output_content = template.render(context)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 1008, in 
render
return self.environment.handle_exception(exc_info, True)
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 780, in 
handle_exception
reraise(exc_type, exc_value, tb)
  File "/usr/lib/python3/dist-packages/jinja2/_compat.py", line 37, in reraise
raise value.with_traceback(tb)
  File "/<>/docs_theme/404.html", line 1, in top-level template 
code
{% extends "main.html" %}
  File "/<>/docs_theme/main.html", line 7, in top-level template 
code
{% if page.title %}{{ page.title }} - {% endif %}{{ config.site_name 
}}
  File "/usr/lib/python3/dist-packages/jinja2/environment.py", line 430, in 
getattr
return getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'page' is undefined

-- 
Brian May 

Bug#865937: [Python-modules-team] Bug#865937: python-django-extensions FTBFS: ValueError: expected only letters, got u''

[Brian May]

Adrian Bunk  writes:

> python-django-extensions FTBFS with the new python-babel:
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-django-extensions.html

I have reproduced this failure in python-django-extensions 1.8.0 and
forwarded it upstream:

https://github.com/django-extensions/django-extensions/issues/1072
-- 
Brian May 

Bug#864482: LXQt Locale Configuration alows selection of non-existent en_DE locale

[Alf Gaida]

Control: reassign #864482 lxqt-config
Control: forwarded #864482 https://github.com/lxde/lxqt/issues/1320

Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[Emmanuel Bourg]

Le 4/07/2017 à 20:21, Markus Koschany a écrit :

> I understand what you intend to say. Even if UTF-8 was the default,
> libidw-java would require an override with ISO-8859-1 encoding. However
> we are talking about the general case. What is more likely that a Java
> project contains an UTF-8 encoded character or ISO-8859-1 character in
> 2017?

UTF-8 is certainly more prevalent in 2017, but the packages lacking a
build system and thus using jh_build are often old projects more likely
to have ASCII or ISO-8859-1 encoded source files.


> I hope tony will read this and find some better arguments
> because he is also in favor of UTF-8. :)

I wish I could find the right argument to spare you the trouble of
updating old packages for nothing, but if you think it's better go for
it. That would still be an opportunity to refresh old packages, migrate
them to Git, etc.


> By the way how are people supposed to override the JH_JAVAC_OPTS
> variable. I just tried
> 
> export JH_JAVAC_OPTS="-encoding UTF-8" in libidw-java but this doesn't
> really seem to work.

You are right, I misread the jh_build code sorry. The jh_build options
are either specified with the JH_BUILD_ARGS variable for the CDBS
packages (never used according to codesearch.debian.net), or by adding
the --javacopts option to dh_auto_build for DH packages (used by
osgi-core, libcds-moc-java and rdp-readseq to set the encoding).


> To be honest I didn't expect that much resistance against using UTF-8.

I'm not against UTF-8, I use and recommend UTF-8 everyday, whenever
possible. But here it isn't about using UTF-8, it is about selecting a
default encoding expected by the compiler to parse the source files. I'm
just arguing that the best choice is the one that works out of the box
for a majority of javahelper based packages. Changing the default in
javahelper will do nothing to spread the use of UTF-8.

Bug#867229: CVE-2017-0647

[Moritz Muehlenhoff]

Package: android-libziparchive
Severity: important
Tags: security

CVE-2017-0647 from the recent Android bulletin seems to affect
android-platform-system-core?

It refers to
https://android.googlesource.com/platform/system/core/+/3d6a43155c702bce0e7e2a93a67247b5ce3946a5

Cheers,
Moritz

Bug#836368: retitle 836368 ITA: pev -- text-based tool to analyze PE files

[Petter Reinholdtsen]

[Petter Reinholdtsen]
> Upstream did make a new release.  Any hope to get the new version of
> pev into Debian?

I imported versions 0.60 - 0.80 into
https://anonscm.debian.org/cgit/collab-maint/pev.git > and brushed
up the build rules a bit.

Not quite sure what to do with the remaining lintian issues:

E: pev source: source-is-missing src/lib/libfuzzy/edit_dist.o
E: pev source: source-is-missing src/lib/libfuzzy/fuzzy.o
W: pev: package-name-doesnt-match-sonames libpe1
W: pev: non-dev-pkg-with-shlib-symlink usr/lib/libpe.so.1.0 usr/lib/libpe.so

The first two are already solved in the upstream git repository.
Creating a library package out of pev seem like a bad idea.  Is there
some better idea?

-- 
Happy hacking
Petter Reinholdtsen

Bug#867227: [pkg-ntp-maintainers] Bug#867227: ntpdc no longer works

[Bernhard Schmidt]

Control: tags -1 + moreinfo

On 04.07.2017 23:21, Anton Ivanov wrote:

Hi,

> Package: ntp
> Version: 1:4.2.8p10+dfsg-3
> Severity: important
> 
> Dear Maintainer,
> 
> It is no longer possible to query the ntpd state. ntpdc fails to work.

Upstream says (man ntpdc)

DESCRIPTION
 ntpdc is deprecated.  Please use ntpq(1) instead - it can do
 everything ntpdc used to do, and it does so using a much more sane
 interface.

Please try to use ntpq.

Best Regards,
Bernhard

Bug#866950: fontconfig: upgrade radically changes font-rendering - hotfix and possible lead

[The Wanderer]

On 2017-07-03 at 20:13, Tomasz Nitecki wrote:

> Ok, so just two quick additions:
> 
> 1. Correct local.conf location for the system wide configuration is 
> /etc/fonts/local.conf
> 
> 2. You can use Terry`s configuration [A] as it is cleaner (with
> proper xml structure) and works just as well.

Terry's configuration actually does something slightly different,
though. Your snippet turns on full font hinting; his not only does that,
it also disables autohinting. (That can be omitted by cutting out part
of his config, which is superior in abstract terms, but using it
verbatim will have that result.)

Some people may want to do both, others may only want to do one, and
still others may want to do something different from both. Depending on
exactly what font settings you had in place prior to the upgrade, that
may require different configuration snippets.

The information so far present in this bug mainly just points to where
the configuration changes to revert the behavior need to be made and
what format they need to be in, with hints about what settings are
supported by the software. A comprehensive listing of possibly relevant
configuration options for this is almost certainly out of scope.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Bug#867230: octave-image: possible unnecessary dependency on imagemagick

[Mike Miller]

Package: octave-image
Version: 2.6.1-2
Severity: minor

I suspect the Depends: imagemagick is outdated and no longer necessary.
>From what I can tell, octave-image used to contain image functions that
called the "convert" command line utility directly. That no longer seems
to be the case. The Build-Depends does not contain imagemagick, and the
full test suite runs without it.

Does anyone know whether functions in this package still require the
imagemagick command line interface to be installed?

If it can be removed, Description making reference to ImageMagick should
also be updated / revised.

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

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

Versions of packages octave-image depends on:
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libc62.24-12
ii  libgcc1  1:7.1.0-7
pn  liboctave3v5 
ii  liboctave4   4.2.1-2
ii  libstdc++6   7.1.0-7
ii  octave   4.2.1-2

octave-image recommends no packages.

octave-image suggests no packages.

Bug#867228: lxqt-metapackages binary-all FTBFS: the Suggests field contains an arch-specific dependency but the package is architecture all

[Adrian Bunk]

Source: lxqt-metapackages
Version: 17
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=lxqt-metapackages=all=17=1499203543=0

...
   dh_installdeb -i
   dh_gencontrol -i
dpkg-gencontrol: error: the Suggests field contains an arch-specific dependency 
but the package is architecture all
dh_gencontrol: dpkg-gencontrol -plxqt-core -ldebian/changelog 
-Tdebian/lxqt-core.substvars -Pdebian/lxqt-core returned exit code 255
dh_gencontrol: Aborting due to earlier error
debian/rules:4: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 25

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

[Michael Crusoe]

I have a fix checked in as part of the 2.1-1 release, but it is blocked on
me uploading a python3 version of sphinx-guzzle

Pe 4 iul. 2017 23:12, "Sascha Steinbiss"  a scris:

> Hi all,
>
> >> I've applied this patch to get the build working now that Python 3.6 is
> a
> >> supported version in Ubuntu. I admit I don't entirely understand why it
> is
> >> necessary! Maybe you do? :)
> >>
> > Now that python3.6 is supported in Debian, khmer FTBFS:
> >
> > https://buildd.debian.org/status/fetch.php?pkg=khmer;
> arch=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0
>
> Does anyone know more about this issue? Otherwise I'd be inclined to
> simply apply the patch in BTS to get the bug fixed...
>
> Kind regards
> Sascha
>

Bug#867226: aptitude seems dependency problems when there are none

[Nikolaus Rath]

Package: aptitude
Version: 0.8.7-1
Severity: normal

According to apt, there are no dependency problems on my system:

# apt install -f
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libbasicusageenvironment0 libchromaprint0 libdvbpsi9 libfreerdp-cache1.1
  libfreerdp-client1.1 libfreerdp-codec1.1 libfreerdp-common1.1.0 
libfreerdp-core1.1
  libfreerdp-crypto1.1 libfreerdp-gdi1.1 libfreerdp-locale1.1 
libfreerdp-primitives1.1
  libfreerdp-rail1.1 libfreerdp-utils1.1 libgroupsock1 libjsoncpp0 
liblivemedia23
  libmusicbrainz5-1 libnm-glib-vpn1 libnm-gtk-common libnm-gtk0 libsctp1
  libspice-client-gtk-3.0-4 libstreams0 libusageenvironment1 libvncclient0 
libvncserver0
  libvte-common libvte9 libwebpdemux1 libwebpmux1 libwine-gecko-2.21 
libwinpr-crt0.1
  libwinpr-crypto0.1 libwinpr-dsparse0.1 libwinpr-environment0.1 
libwinpr-file0.1
  libwinpr-handle0.1 libwinpr-heap0.1 libwinpr-input0.1 libwinpr-interlocked0.1
  libwinpr-library0.1 libwinpr-path0.1 libwinpr-pool0.1 libwinpr-registry0.1
  libwinpr-rpc0.1 libwinpr-sspi0.1 libwinpr-synch0.1 libwinpr-sysinfo0.1 
libwinpr-thread0.1
  libwinpr-utils0.1 libxcb-composite0 nautilus-data python-colorama 
python-distlib
  python-html5lib python-webencodings vlc-nox vorbis-tools
Use 'apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

However, according to aptitude, there is something seriously wrong:

$ aptitude
# Select Actions -> Cancel pending actions
# Select Actions -> Quit

$ aptitude install

# aptitude install
The following NEW packages will be installed:
  alsa-utils android-tools-adb{b} ant ant-optional aspectj binfmt-support 
btrfs-tools 
  bzip2-doc bzr bzr-builddeb{b} cups-pk-helper cvs cython dbus-java-bin 
default-jdk{b} 
  dia dia-common dia-libs dia-shapes dict distro-info eclipse-cdt 
eclipse-cdt-jni 
  eclipse-jdt eclipse-pde eclipse-platform{b} eclipse-platform-data{b} 
eclipse-rcp{b} 
  fastjar finger gawk gdebi-core gimmix{b} gir1.2-notify-0.7 
gir1.2-packagekitglib-1.0 
  gnome-terminal{b} growisofs gtk2-engines hdfview{b} hgsubversion iceweasel 
jarwrapper 
  java-wrappers junit junit4 ktimetracker libapache-pom-java libapr1 
libaprutil1 
  libasm3-java libasm4-java libaspectj-java libb-hooks-op-check-perl 
  libbareword-filehandles-perl libbcprov-java libbonoboui2-0{b} 
libbonoboui2-common 
  libbz2-dev libcapture-tiny-perl libcglib3-java libclass-method-modifiers-perl 
  libclass-methodmaker-perl libclass-xsaccessor-perl libcommons-beanutils-java 
  libcommons-cli-java libcommons-codec-java libcommons-collections3-java 
  libcommons-compress-java libcommons-dbcp-java libcommons-digester-java 
  libcommons-httpclient-java libcommons-lang-java libcommons-lang3-java 
  libcommons-logging-java libcommons-parent-java libcommons-pool-java 
libdata-perl-perl 
  libdb-java libdb-je-java libdb5.3-java libdb5.3-java-jni libdbus-java 
  libdevel-caller-perl libdevel-globaldestruction-perl libdevel-lexalias-perl 
  libdnsjava-java libeasymock-java{b} libecj-java libequinox-osgi-java 
  libfelix-bundlerepository-java libfelix-framework-java 
libfelix-gogo-command-java 
  libfelix-gogo-runtime-java libfelix-gogo-shell-java libfelix-main-java 
  libfelix-osgi-obr-java libfelix-shell-java libfelix-utils-java 
libfile-libmagic-perl 
  libgd-perl libgeronimo-jpa-2.0-spec-java libgeronimo-osgi-support-java 
  libglib2.0-bin{b} libgnomeui-0{b} libgnomeui-common libgnupg-interface-perl 
  libgpod-common{b} libgssapi3-heimdal libgtksourceview2.0-0 
libgtksourceview2.0-common 
  libhamcrest-java libhdf4-0 libheimntlm0-heimdal libhttpclient-java 
libhttpcore-java 
  libhttpmime-java libice-dev libicu4j-4.4-java libicu4j-java 
libimport-into-perl 
  libindirect-perl libjcalendar-java libjgoodies-common-java 
libjgoodies-forms-java 
  libjgraph-java libjhdf4-java libjhdf4-jni{b} libjhdf5-java libjhdf5-jni{b} 
  libjline-java libjmdns-java libjna-java libjna-jni libjs-codemirror 
  libjs-jquery-metadata libjs-jquery-tablesorter libjs-twitter-bootstrap 
libjsch-java 
  libjson-simple-java libjtidy-java libjzlib-java libkcalcore4{b} 
libkdc2-heimdal 
  libkxml2-java liblaf-widget-java liblexical-sealrequirehints-perl 
liblog4j1.2-java 
  liblucene2-java libmaa3 libmac-widgets-java libmatthew-debug-java 
  libmodule-runtime-perl libmoo-perl libmoox-handlesvia-perl libmoox-late-perl 
libmpd1 
  libmultidimensional-perl libnet-idn-encode-perl libnxml0 libobjenesis-java 
  libosgi-compendium-java libosgi-core-java{b} libosgi-foundation-ee-java 
  libpackagekit-glib2-18 libpadwalker-perl libparams-classify-perl 
libpoppler-qt5-1 
  libpthread-stubs0-dev libqt5sql5-sqlite librecode0 libregexp-java 
  libreoffice-help-en-us librole-tiny-perl libserf-1-1 libservlet3.0-java 
libsm-dev 
  libstrictures-perl libsub-exporter-progressive-perl libsvn-perl libsvn1 
  libswt-cairo-gtk-3-jni libswt-glx-gtk-3-jni 

Bug#867227: ntpdc no longer works

[Anton Ivanov]

Package: ntp
Version: 1:4.2.8p10+dfsg-3
Severity: important

Dear Maintainer,

It is no longer possible to query the ntpd state. ntpdc fails to work.


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

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

Versions of packages ntp depends on:
ii  adduser3.115
ii  dpkg   1.18.24
ii  libc6  2.24-11+deb9u1
ii  libcap21:2.25-1
ii  libedit2   3.1-20160903-3
ii  libopts25  1:5.18.12-3
ii  libssl1.1  1.1.0f-3
ii  lsb-base   9.20161125
ii  netbase5.4

Versions of packages ntp recommends:
ii  perl  5.24.1-3

Versions of packages ntp suggests:
pn  ntp-doc  

-- Configuration Files:
/etc/ntp.conf changed [not included]

-- no debconf information

Bug#867225: liblockfile: Vcs-* fields doesn't point to debian packaging repo

[Andreas Henriksson]

Source: liblockfile
Version: 0.1.1-3
Severity: minor

Dear Maintainer,

While looking into another issue I noticed that the git repo
referenced from liblockfile package debian/control Vcs-* fields
doesn't seem to contain the debian packaging repo, but rather
the upstream (only) repository.

The Vcs-* fields are supposed to point to Debian stuff, not upstream
though. See https://wiki.debian.org/UpstreamMetadata for how to
add references to upstream resources instead.

As you seem to be both debian maintainer and upstream it might be
convenient for you to use the same repo for both debian and upstream
work and just use branches. In such case I'd recommend looking at
http://dep.debian.net/deps/dep14/ and introduce a debian/unstable
branch with debian packaging files. If you don't want to carry that
branch in that repo then simply drop the Vcs-* fields.

Regards,
Andreas Henriksson

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

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

Bug#867224: liblockfile1: drop hard-coded pre-depends on multiarch-support

[Andreas Henriksson]

Package: liblockfile1
Version: 1.14-1+b1
Severity: normal
Tags: patch

Dear Maintainer,

Please fix lintian error pre-depends-directly-on-multiarch-support
either by following the advice in
https://lintian.debian.org/tags/pre-depends-directly-on-multiarch-support.html
or simply dropping the "Pre-Depends: multiarch-support" line which is
obsolete (the variale mentioned in the above url will nowadays expand
to empty as multiarch-support package is deprecated).

Trivial patch attached.

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

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

Versions of packages liblockfile1 depends on:
ii  libc6  2.24-12
ii  liblockfile-bin1.14-1+b1
pn  multiarch-support  

liblockfile1 recommends no packages.

liblockfile1 suggests no packages.

-- no debconf information
diff -uriNp liblockfile-1.14.orig/debian/control liblockfile-1.14/debian/control
--- liblockfile-1.14.orig/debian/control	2017-01-05 14:23:09.0 +0100
+++ liblockfile-1.14/debian/control	2017-07-04 23:31:22.918725468 +0200
@@ -13,7 +13,6 @@ Section: libs
 Priority: standard
 Architecture: any
 Multi-Arch: same
-Pre-Depends: multiarch-support
 Depends: ${shlibs:Depends}, ${misc:Depends}, liblockfile-bin (>=${binary:Version})
 Description: NFS-safe locking library
  Liblockfile is a shared library with NFS-safe locking functions.

Bug#867223: libclamunrar: CVE-2012-6706: arbitrary memory write

[Felix Geyer]

Source: libclamunrar
Version: 0.99-0+deb7u1
Severity: grave
Tags: security
Justification: user security hole

CVE-2012-6706 also affects libclamunrar. See #865461 for the original bug 
report against
unrar-nonfree.

Upstream fix:
https://github.com/vrtadmin/clamav-devel/commit/d4699442bce76574573dc564e7f2177d679b88bd

Felix

Bug#867212: octave: Octave function strncmp is case insensitive

[Mike Miller]

Control: forwarded -1 https://savannah.gnu.org/bugs/?51384
Control: tags -1 + confirmed

On Tue, Jul 04, 2017 at 21:56:20 +0200, Thierry Rascle wrote:
> Octave function strncmp performs a case insensitive string comparison,
> like strncmpi. strncmp should do a case sensitive string comparison.
> 
> This issue seems to affect recent versions of Octave. The version in
> Debian Stable is not affected.

Thank you for discovering this regression in Octave 4.2. I have gone
ahead and filed a report upstream [1] with your patch.

Your patch looks correct to me. This should be applied to the upstream
stable branch soon along with a test case.

[1]: https://savannah.gnu.org/bugs/?51384

-- 
mike

Bug#867222: pdf-presenter-console: [regression] movies are expanded full screen, cover the presentation, and never disappear

[Francesco Poli (wintermute)]

Package: pdf-presenter-console
Version: 4.0.7-1
Severity: important

Hello!

As soon as I upgraded to pdf-presenter-console/4.0.7-1, I began
experiencing a really really bad regression regarding movie playback.

Suppose to have a PDF presentation (created with LaTeX and Beamer)
that includes movies incorporated with the following LaTeX code:

  
\newcommand{\includeavi}[2]{\movie[loop]{\includegraphics[#1]{figs/#2}}{#2.avi}}
  [...]
  \includeavi{width=0.73\textwidth}{mymovie}

When pdf-presenter-console/4.0.7-1 shows the presentation, something
awkward happens, as soon as the page incorporating the movie is reached:
the movie is expanded full screen and covers the actual presentation
page. The movie may be played, but there seems to be no way to make it
disappear again. Hitting [space] or [PageUp] or [PageDown] seems to
have no effect on the presentation screen. On the presenter console,
the preview of the next slide changes, hence I assume that the other
slides of the presentation are actually shown, but they are masked
by the expanded movie!

In conclusion there seems to be no way to correctly show a presentation
incorporating movies...

pdf-presenter-console/4.0.6-1 works as expected.

Could you please forward my bug report upstream?

Thanks for your time.
Bye!



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

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

Versions of packages pdf-presenter-console depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-12
ii  libcairo-gobject2   1.14.8-1
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libgee-0.8-20.18.1-1
ii  libglib2.0-02.52.3-1
ii  libgstreamer-plugins-base1.0-0  1.12.1-1
ii  libgstreamer1.0-0   1.12.1-1
ii  libgtk-3-0  3.22.16-1
ii  libpango-1.0-0  1.40.5-1
ii  libpangocairo-1.0-0 1.40.5-1
ii  libpoppler-glib80.48.0-2
ii  libx11-62:1.6.4-3

pdf-presenter-console recommends no packages.

pdf-presenter-console suggests no packages.

-- no debconf information

Bug#864804: CVE-2017-9604: Send Later with Delay bypasses OpenPGP

[Moritz Muehlenhoff]

On Sat, Jun 17, 2017 at 11:00:26AM +0200, Sandro Knauß wrote:
> Hey,
> 
> I backported the patch for jessie. I attached a debdiff and waiting for your 
> response to upload.

Hi Sandro,
sorry for the late reply, I was on afk myself.

This is fairly obscure feature with IMO little practical impact and this
doesn't warrant a DSA on it's own. This can either be fixed via a point
update [1] or we can fix this along when there's a more severe kdepim
vulnerarability in the future.

Cheers,
Moritz

[1] 
https://www.debian.org/doc/manuals/developers-reference/ch05.html#upload-stable

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

[Sascha Steinbiss]

Hi all,

>> I've applied this patch to get the build working now that Python 3.6 is a
>> supported version in Ubuntu. I admit I don't entirely understand why it is
>> necessary! Maybe you do? :)
>>
> Now that python3.6 is supported in Debian, khmer FTBFS:
> 
> https://buildd.debian.org/status/fetch.php?pkg=khmer=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0

Does anyone know more about this issue? Otherwise I'd be inclined to
simply apply the patch in BTS to get the bug fixed...

Kind regards
Sascha

Bug#865085: [Debichem-devel] Bug#865085: avogadro: doesn't display molecules

[Michael Banck]

Hi,

On Mon, Jun 19, 2017 at 05:04:09PM +1000, Stuart Prescott wrote:
> Package: avogadro
> Version: 1.2.0-1+b1
> Severity: serious
> Justification: package is useless
> 
> Dear Maintainer,
> 
> Avogadro in stretch appears to be unable to display any molecules. It only
> displays the background colour fill. Picking any molecule should be enough
> to reproduce this:
> 
> $ avogadro /usr/share/avogadro/fragments/alkanes/hexane.cml
> 
> or
> 
> $ avogadro
> 
>File → Import → Fetch by chemical name → hexane
> 
> The debug view shows that avogadro has imported the right number of atoms
> and bonds, but nothing is displayed no matter what settings are chosen for
> the viewer.
> 
> (checked across 3 computers including one on which avogadro had never been
> installed before just in case it was a local config problem. Old discussions
> on the avogadro development lists around such problems frequently implicate
> compositing, but I this under Xvfb and various WMs and is, in any case, a
> regression since jessie.)

This has also been filed in Ubuntu and upstream:

https://bugs.launchpad.net/ubuntu/+source/avogadro/+bug/1640171
https://sourceforge.net/p/avogadro/bugs/783/

It seems to be an issue with out eigen3 patch, there's since been a
different commit upstream, and Khanh-Dang Nguyen Thu Lam confirmed this:

22:39  compilation just done
22:39  it works :)
22:40  i did: "apt-get source avogadro", replaced
debian/patches/eigen3.patch by 43af3c117b0b3220b15c2fe2895b94bbd83d3a60,
then compiled it

https://github.com/cryos/avogadro/commit/43af3c117b0b3220b15c2fe2895b94bbd83d3a60
is the relevant changeset.


Michael

Bug#845624: lxqt: Touchpad features

[Alf Gaida]

Control: reassign #845624 lxqt-config

Bug#867203: apt-listbugs: suggests the required debianutils package

[Francesco Poli]

Control: tags -1 - moreinfo


On Tue, 4 Jul 2017 20:42:43 +0200 Manolo Díaz wrote:

[...]
> Hello Francesco,
> 
> I'm not a Debian expert, but as you say debianutils isn't optional on
> every healthy Debian box and it seems pointless to suggest it. I agree
> with you in that it would be better to drop it from the Suggests field.

Fine, I will do so soonish...
Bye and thanks again for raising the issue.


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


pgpSaXVFitcja.pgp
Description: PGP signature

Bug#867221: xfce4-session: /xfce.desktop should point to xfce4-session

[Martin Monperrus]

Package: xfce4-session
Version: 4.12.1-5
Severity: normal

Dear Maintainer,

/usr/share/xsessions/xfce.session contains "Exec=startxfce4"

On my system, this fails to start an XFCE session with the error message
"/usr/bin/startxfce4: X server already running on" (common error on the web)

Indeed, starting X is handled by the DM itself, not by XFCE (lightdm in my
case).

I've changed it to "Exec=xfce4-session" and it works perfectly now.

What about changing "Exec=startxfce4" by "Exec=xfce4-session"?



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

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

Versions of packages xfce4-session depends on:
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-12
ii  libcairo2  1.14.8-1
ii  libdbus-1-31.10.18-1
ii  libdbus-glib-1-2   0.108-2
ii  libfontconfig1 2.12.3-0.1
ii  libfreetype6   2.6.3-3.2
ii  libgdk-pixbuf2.0-0 2.36.5-2
ii  libglib2.0-0   2.52.3-1
ii  libgtk2.0-02.24.31-2
ii  libice62:1.0.9-2
ii  libpango-1.0-0 1.40.5-1
ii  libpangocairo-1.0-01.40.5-1
ii  libpangoft2-1.0-0  1.40.5-1
ii  libpolkit-gobject-1-0  0.105-18
ii  libsm6 2:1.2.2-1+b3
ii  libwnck22  2.30.7-5.1
ii  libx11-6   2:1.6.4-3
ii  libxfce4ui-1-0 4.12.1-2
ii  libxfce4util7  4.12.1-3
ii  libxfconf-0-2  4.12.1-1
ii  xfce4-settings 4.12.1-1
ii  xfconf 4.12.1-1

Versions of packages xfce4-session recommends:
ii  dbus-x11   1.10.18-1
ii  libpam-systemd 233-9
ii  light-locker   1.7.0-4
ii  systemd-sysv   233-9
pn  upower 
ii  x11-xserver-utils  7.7+7+b1
ii  xfdesktop4 4.12.3-4
ii  xfwm4  4.12.4-1

Versions of packages xfce4-session suggests:
pn  fortunes-mod  
ii  pm-utils  1.4.1-17
ii  sudo  1.8.20p2-1

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/xsessions/xfce.desktop (from xfce4-session 
package)

Bug#866769: keepassx fails to clear KDE clipboard history, leaving passwords visible

[Henrik Størner]

Hi Felix,

On 04-07-2017 21:39, Felix Geyer wrote:

Hi,

On 03.07.2017 03:42, Reinhard Tartler wrote:

Control: tag -1 +help +upstream
Control: severity -1 important

Thank you very much for your bug report, Henrik.

On 07/01/2017 11:22 AM, Henrik Størner wrote:



keepassx 2.0.3-1 (in Debian "stretch") fails to clear the clipboard history 
after a password has been copied to the clipboard.

The keepassx security settings has "Clear clipboard after 10 seconds" enabled.

To reproduce,
- select an entry with a stored password in the keepassx database
- press ctrl-C to copy the password to the clipboard
- after 10 seconds (default setting), the password should disappear from the 
clipboard history
- click on the clipboard icon in the panel, the password is visible

This is using the KDE Desktop installation, and hence the KDE clipboard.

The KDE clipboard has a setting to prevent the clipboard from being emptied, 
but this setting does not change the behaviour.


KeePassX clears the clipboard by using the Qt QClipboard API.

If another application (KDE Clipboard manager or anything else) resets the 
clipboard again, there
is nothing KeePassX can do to prevent it.


I don't understand your comment. The problem is that KeePassX does *not* 
clear the clipboard, not that something else resets the clipboard.


If KeePassX uses the Qt API to clear the clipboard, then the problem 
might be in Qt. Either that, or the behaviour of KeePassX+Qt is not as 
one would expect.


But I am 99% sure that this behaviour is different from what happened 
with keepassx 0.4.3 from Debian 8 (jessie). I will get a test system 
setup later this week to verify this, and also try the old keepassx tool 
on Stretch.



Regards,
Henrik

Bug#866187: add torrc.d configuration directory

[Patrick Schleizer]

Peter Palfrader:
> I'm tempted to stop shipping upstream's torrc as /etc/tor/torrc.  It's
> full of options that most users should never set, and shipping an almost
> empty one is much nicer.
> 
> I suspect that approximately the only thing it ought to have is the
> include line.

I was too afraid to suggest such as drastic change, but I like the idea
very much.

Bug#863496: debian-handbook: add a wireless configuration section

[Matthew Donnelly]

Thanks! Here is the patch. Let me know if I need to change anything.
734a735,1077
> 
>   Wireless Client Configuration
> 
>   Wireless Fidelity (WiFi) enable a Debian machine to connect
>   to a wireless access point (AP) such as a router. In Debian, there
>   are two ways of connecting to an AP. The first is manual configuration.
>   While manually configuring a wireless interface involves more work and
>   resets after every reboot, it works on all Linux distributions and
>   is important to know when troubleshooting wireless issues. Manually
>   configuring a wireless client can be broken into three steps:
>   ensure the wireless interface is detected and functional, connect
>   and authenticate to the AP, and obtain an IP address.
>   
> 
>   In order for a wireless device to be detected by Debian, the
>   kernel must have support for the device and the correct firmware
>   needs to be installed. To determine if the wireless interface is
>   detected, run lsusb for a usb based wireless adapter or lspci for
>   a pci based wireless adapter.
>   
>   
>   
>   Example lsusb output
>   
> root@~-> lsusb
> ...
> Bus 001 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
> ...
>   
>   
> 
>   The wireless interface should be listed in the output of ip addr.
>   
>   Example ip addr output
>   
> root@~-> ip addr
> 1: wlan0: BROADCAST,MULTICAST mtu 1500 qdisc mq state DOWN group default qlen 1000
> link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
>   
>   
> 
>   If your wireless device is not listed in either lsusb/lspci
>   or ip addr, then the device is not being detected by the kernel.
>   Most likely, the kernel does not have support compiled in for the 
>   wireless device. To enable support, you will need to compile a custom
>   kernel. In the kernel configuration menu, go to Device Drivers -> 
>   Network Device Support -> Wirless LAN and enable the drivers needed
>   for your wireless device. There may also be wireless drivers in
>   Device Drivers -> Staging Drivers.  Some wireless chipsets
>   (such as for the RT5370 device in the example output) require closed
>   source firmware. To install this firmware, enable the non-free
>   repository in /etc/apt/sources.list, run apt-get update, and install
>   the firmware required. For the specific RT5370 chipset in the example,
>   the firmware-ralink package is needed. To find information about your
>   specific wireless chipset, see https://wiki.debian.org/WiFi.
>   
> 
>   Now that the wireless interface is detected by the kernel,
>   it can be connected to an AP. As an example, "wlan0" will be the
>   wireless interface name, "AP" will be the name of the AP to connect
>   to, "qwert" will be the password for the WEP AP and "password"
>   will be the password for the WPA AP. Adjust accordingly.
>   
> 
>   Set the wireless interface up
>   
>  Set interface up
>  
> root@~-> ip link set wlan0 up
>  
>   
> 
>   An AP can require one of three authentication methods: open,
>   WEP, and WPA. Open authentication require no authentication at all; 
>   any client within range can connect to an open AP. 
>   WEP encryption is obsolete and can be broken in a matter of minutes. 
>   While WEP should never be used to secure an AP, it is included here 
>   for completeness. WPA is the prefered method of authentication for an AP. 
>   
>  
>   
>  For open authentication
>  
> root@~-> iwconfig wlan0 essid AP
>  
>   
> 
>   
>  For WEP authentication
>  
> root@~-> iwconfig wlan0 essid AP key s:qwert
>  
>   
> 
>   
>  For WPA authentication
>  
> root@~-> #Generate a configuration with
> root@~-> wpa_passphrase AP password > /etc/wpa_supplicant.conf
> root@~-> #Connect to the access point with
> root@~-> wpa_supplicant -B -D wext -i wlan0 -c /etc/wpa_supplicant.conf
> root@~-> #This may generate some warnings that can be ignored for now.
>  
>   
> 
>   The wireless interface now needs to obtain an ip address.
>   
>  For a static IP address
>  
> root@~-> #Replace 192.168.1.2 with the desired ip address
> root@~-> #and /24 with the required netmask.
> root@~-> ip addr add 192.168.1.2/24 dev wlan0
>  
>   
>   
>  For a DHCP IP address
>  
> root@~-> dhcpcd wlan0
>  
>   
> 
>   The client is now connected to the AP. However, the kernel has
>   not been configured to use this as the default route. To make the
>   wireless interface the default, execute
>   
>   
>  Set default route
>  
> root@~-> #Replace 192.168.1.1 with the IP address of 

Bug#866513: Bug#866306: haveged fails to start on some amd64 nodes

[intrigeri]

Mattia Rizzolo:
> Well, I wanted to try this, but when I went to just try a simple restart
> of hanvengd, it just started.  Now all the amd64 nodes are running
> havengd seemingly without any issue

Interesting. So I suspect haveged starts before *something* it needs
at boot time. Sorry, no time to investigate right now.

Cheers,
-- 
intrigeri

Bug#866517: jessie-pu: package unrar-nonfree/1:5.2.7-0.1+deb8u1

[Felix Geyer]

Hi KiBi,

On 02.07.2017 23:27, Cyril Brulebois wrote:
> Control: tag -1 confirmed
> 
> Hi,
> 
> Felix Geyer  (2017-06-29):
>> I'd like to fix CVE-2012-6706 in jessie, see #865461 for details.
>> debdiff is attached.
>>
>> The same request for stretch is at #866516
> 
> Looks good to me as well, feel free to upload; thanks.

Uploaded, thanks!

Felix

Bug#866516: stretch-pu: package unrar-nonfree/1:5.3.2-1+deb9u1

[Felix Geyer]

Hi KiBi,

On 02.07.2017 23:25, Cyril Brulebois wrote:
> Control: tag -1 confirmed
> 
> Hi Felix,
> 
> Felix Geyer  (2017-06-29):
>> I'd like to fix CVE-2012-6706 in stretch, see #865461 for details.
>> debdiff is attached.
> 
> This looks good to me, feel free to upload; thanks.

Uploaded, thanks!

>> +--- unrar-nonfree-5.3.2.orig/unpack.hpp
>>  unrar-nonfree-5.3.2/unpack.hpp
>> +@@ -13,6 +13,12 @@
>> + // from two data blocks.
>> + #define MAX3_UNPACK_FILTERS  8192
>> + 
>> ++// Limit maximum number of channels in RAR3 delta filter to some reasonable
>> ++// value to prevent too slow processing of corrupt archives with invalid
>> ++// channels number. Must be equal or larger than v3_MAX_FILTER_CHANNELS.
>> ++// No need to provide it for RAR5, which uses only 5 bits to store 
>> channels.
>> ++#define MAX3_UNPACK_CHANNELS  1024
>> ++
>> + // Write data in 4 MB or smaller blocks. Must not exceed PACK_MAX_WRITE,
>> + // so we keep number of buffered filter in unpacker reasonable.
>> + #define UNPACK_MAX_WRITE 0x40
> 
> (Funny to see a new definition for MAX3_UNPACK_CHANNELS but not for the
> hardcoded 128. But I suppose this might be an artefact of backporting
> the fix from a new upstream. Not a huge deal anyway.)

It's the same in the upstream 5.5.5 code. Incidentally there is also no 
MAX_FILTER_CHANNELS
constant defined ...

Felix

Bug#867104: wanna-build issue with src:perl versioned Provides

[Niko Tyni]

(Taking the debian-dpkg list in the loop and hence overquoting.)

On Tue, Jul 04, 2017 at 10:18:08PM +0200, Ralf Treinen wrote:
> On Tue, Jul 04, 2017 at 10:29:35PM +0300, Niko Tyni wrote:
> > On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote:
> > 
> > > thanks for having figured that out. I tend to believe that dose is right
> > > in this case. Since it is not possible to install at the same
> > > time two different versions of the same real package, the same should
> > > IMHO hold when one is real and the other virtual. Why should this be
> > > possible?
> > 
> > Well, dpkg and apt allow it for starters.
> > 
> > The idea with the perl packages is that the src:perl binary packages
> > offer an older "stable" version of some modules while a newer version is
> > packaged separately and gets installed earlier on the Perl search path
> > (so it overrides the src:perl version when installed.)
> > 
> > This has been the case for ages with the src:perl packages Providing
> > an unversioned virtual package. The change here is that the virtual
> > package is now versioned, which would simplify lots of dependencies
> > that currently read like (for instance)
> 
> So, that means that something like
> 
> Depends: p (=1), p (=2)
> 
> suddenly becomes satisfiable (when there is one real package p and
> one virtual package)? Would you also allow to have the packages p
> and q installed at the same time, in the following situation:
> 
> Package: p
> Version: 1
> Provides: v (=1)
> 
> Package: q
> Version: 1
> Provides: v (=2)
> 
> If yes this seems to me a quite drastic change of the meaning of 
> package relations. Has this been discussed somewhere?

Not that I know of. I've been just going by what works with dpkg and
apt. If this is something that has only been made possible accidentally,
I'll of course back up the src:perl changes.

@debian-dpkg: could you please comment.
-- 
Niko Tyni   nt...@debian.org

Bug#867220: unifont-bin: "Priority: extra" should be "Priority: optional"

[Paul Hardy]

Package: unifont-bin
Version: 1:10.0.01-1
Severity: normal

--

There is no more "extra" priority in Debian.  The unifont-bin
"Priority" field should be updated to "optional" to match the package
override.

This will be fixed in the next Unifont upload.

Thanks,


Paul Hardy

Bug#867219: O: usbmuxd -- USB multiplexor daemon for iPhone and iPod Touch devices

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of usbmuxd has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/usbmuxd


Package: usbmuxd
Binary: usbmuxd, usbmuxd-dbg
Version: 1.0.8+git20140527.e72f2f7-2
Maintainer: gtkpod Maintainers 
Uploaders: Julien Lavergne 
Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, libusb-1.0-0-dev 
(>= 1.0.3) [linux-any], libusb2-dev (>= 8.0-4) [kfreebsd-any], libplist-dev (>= 
0.15), libimobiledevice-dev (>= 1.1.6)
Architecture: linux-any kfreebsd-any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 6517a27d9055dcd8d9404875fef0650b 2323 usbmuxd_1.0.8+git20140527.e72f2f7-2.dsc
 449dc67128193e63d276f19858aa7aba 47116 
usbmuxd_1.0.8+git20140527.e72f2f7.orig.tar.xz
 32fca66500d92fb78939bcdace614c1c 6032 
usbmuxd_1.0.8+git20140527.e72f2f7-2.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/usbmuxd.git
Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/usbmuxd.git
Checksums-Sha256:
 118aa0904824ac2bb777b02267ec140f8d027bc91ec76c66a486ec89b65dc13d 2323 
usbmuxd_1.0.8+git20140527.e72f2f7-2.dsc
 bbb831412ae008c4c4e6e4a265314d1a795c8663477078bf9afb7e81b46e4f10 47116 
usbmuxd_1.0.8+git20140527.e72f2f7.orig.tar.xz
 89f8b26140a75719699a61e09151adc1ca33ed2f707d560ca69702b07b78592b 6032 
usbmuxd_1.0.8+git20140527.e72f2f7-2.debian.tar.xz
Homepage: http://marcansoft.com/blog/iphonelinux/usbmuxd/
Package-List: 
 usbmuxd deb utils optional arch=linux-any,kfreebsd-any
 usbmuxd-dbg deb debug extra arch=linux-any,kfreebsd-any
Directory: pool/main/u/usbmuxd
Priority: source
Section: utils

Package: usbmuxd
Binary: usbmuxd, usbmuxd-dbg
Version: 1.1.0-2
Maintainer: gtkpod Maintainers 
Uploaders: Julien Lavergne 
Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, libusb-1.0-0-dev 
(>= 1.0.3) [linux-any], udev [linux-any], systemd [linux-any], libusb2-dev (>= 
8.0-4) [kfreebsd-any], libplist-dev (>= 0.15), libimobiledevice-dev (>= 1.1.6)
Architecture: linux-any kfreebsd-any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 1ec620bd18f430ea2434a0c5cf23ca4e 2228 usbmuxd_1.1.0-2.dsc
 34361c59320cb0b1f9ebcd2798ee1b39 321897 usbmuxd_1.1.0.orig.tar.bz2
 6edd0ba97ce2c2a54422d6d4cf5e4ec7 4788 usbmuxd_1.1.0-2.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/usbmuxd.git
Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/usbmuxd.git
Checksums-Sha256:
 7aeb7b160315ddadebac50774fbb83c76d35b2a7283ba6fdc6518d5ba1415a07 2228 
usbmuxd_1.1.0-2.dsc
 3e8948b4fe4250ee5c4bd41ccd1b83c09b8a6f5518a7d131a66fd38bd461b42d 321897 
usbmuxd_1.1.0.orig.tar.bz2
 c804d37200082ae6e2d10f1190ee96346ec636e1c64c431d178bd59f5217bc8b 4788 
usbmuxd_1.1.0-2.debian.tar.xz
Homepage: http://marcansoft.com/blog/iphonelinux/usbmuxd/
Package-List: 
 usbmuxd deb utils optional arch=linux-any,kfreebsd-any
 usbmuxd-dbg deb debug extra arch=linux-any,kfreebsd-any
Directory: pool/main/u/usbmuxd
Priority: source
Section: utils

Package: usbmuxd
Source: usbmuxd (1.1.0-2)
Version: 1.1.0-2+b2
Installed-Size: 102
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libc6 (>= 2.14), libimobiledevice6 (>= 1.1.5), libplist3 (>= 1.11), 
libusb-1.0-0 (>= 2:1.0.8), adduser
Description-en: USB multiplexor daemon for iPhone and iPod Touch devices
 usbmuxd, the USB multiplexor daemon, is in charge of coordinating
 access to iPhone and iPod Touch services over USB. Synchronization and
 management applications for the iPhone and iPod Touch need this daemon
 to communicate with such devices concurrently.
 .
 This package includes udev rules to start the daemon when a supported
 device is plugged in, and stop it when all devices are removed.
Description-md5: 4e458ee34e3d22d40bde533e8147603f
Homepage: http://marcansoft.com/blog/iphonelinux/usbmuxd/
Tag: hardware::embedded, hardware::usb, implemented-in::c, interface::daemon,
 role::program, use::synchronizing
Section: utils
Priority: optional
Filename: pool/main/u/usbmuxd/usbmuxd_1.1.0-2+b2_amd64.deb
Size: 35480
MD5sum: 5f742926906bf815e0fc8f27d873e66c
SHA256: 66eb9078fbe0c332b78815c307680438bcbb4569cfe540e8872611626b8b4304

Package: usbmuxd-dbg
Source: usbmuxd (1.1.0-2)
Version: 1.1.0-2+b2
Installed-Size: 95
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: usbmuxd (= 1.1.0-2+b2)
Description-en: USB multiplexor daemon for iPhone and iPod Touch devices - debug
 usbmuxd, the USB multiplexor daemon, is in charge of coordinating
 access to iPhone and iPod Touch 

Bug#867218: O: libusbmuxd -- USB multiplexor daemon for iPhone and iPod Touch devices

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of libusbmuxd has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/libusbmuxd


Package: libusbmuxd
Binary: libusbmuxd-dev, libusbmuxd4, libusbmuxd-tools, libusbmuxd4-dbg
Version: 1.0.10-3
Maintainer: gtkpod Maintainers 
Uploaders: Chow Loong Jin 
Build-Depends: debhelper (>= 9.0.0), dh-autoreconf, pkg-config, libplist-dev 
(>= 1.11)
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 3245b1799064c3e680f609519faa15e5 2198 libusbmuxd_1.0.10-3.dsc
 e5351ff6f6eedcb50701e02d91cc480c 292649 libusbmuxd_1.0.10.orig.tar.bz2
 4bcdd5a85e4b1f49ed928c27bd8cbb62 3728 libusbmuxd_1.0.10-3.debian.tar.xz
Vcs-Browser: 
http://git.debian.org/?p=pkg-gtkpod/packages/libusbmuxd.git;a=summary
Vcs-Git: git://git.debian.org/pkg-gtkpod/packages/libusbmuxd.git
Checksums-Sha256:
 d4494b6460a71e2e32a2c3a905f61a3dc070da1065a30176629012a21d0727ee 2198 
libusbmuxd_1.0.10-3.dsc
 1aa21391265d2284ac3ccb7cf278126d10d354878589905b35e8102104fec9f2 292649 
libusbmuxd_1.0.10.orig.tar.bz2
 c31a9fde86fe2e06eda5a78a60e67bed9ae67dba3653e5ebe1f616287e23530f 3728 
libusbmuxd_1.0.10-3.debian.tar.xz
Homepage: http://marcansoft.com/blog/iphonelinux/usbmuxd/
Package-List: 
 libusbmuxd-dev deb libdevel optional arch=any
 libusbmuxd-tools deb utils optional arch=any
 libusbmuxd4 deb libs optional arch=any
 libusbmuxd4-dbg deb debug extra arch=any
Directory: pool/main/libu/libusbmuxd
Priority: optional
Section: misc

Package: libusbmuxd
Binary: libusbmuxd-dev, libusbmuxd4, libusbmuxd-tools, libusbmuxd4-dbg
Version: 1.0.10-3
Maintainer: gtkpod Maintainers 
Uploaders: Chow Loong Jin 
Build-Depends: debhelper (>= 9.0.0), dh-autoreconf, pkg-config, libplist-dev 
(>= 1.11)
Architecture: any
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 3245b1799064c3e680f609519faa15e5 2198 libusbmuxd_1.0.10-3.dsc
 e5351ff6f6eedcb50701e02d91cc480c 292649 libusbmuxd_1.0.10.orig.tar.bz2
 4bcdd5a85e4b1f49ed928c27bd8cbb62 3728 libusbmuxd_1.0.10-3.debian.tar.xz
Vcs-Browser: 
http://git.debian.org/?p=pkg-gtkpod/packages/libusbmuxd.git;a=summary
Vcs-Git: git://git.debian.org/pkg-gtkpod/packages/libusbmuxd.git
Checksums-Sha256:
 d4494b6460a71e2e32a2c3a905f61a3dc070da1065a30176629012a21d0727ee 2198 
libusbmuxd_1.0.10-3.dsc
 1aa21391265d2284ac3ccb7cf278126d10d354878589905b35e8102104fec9f2 292649 
libusbmuxd_1.0.10.orig.tar.bz2
 c31a9fde86fe2e06eda5a78a60e67bed9ae67dba3653e5ebe1f616287e23530f 3728 
libusbmuxd_1.0.10-3.debian.tar.xz
Homepage: http://marcansoft.com/blog/iphonelinux/usbmuxd/
Package-List: 
 libusbmuxd-dev deb libdevel optional arch=any
 libusbmuxd-tools deb utils optional arch=any
 libusbmuxd4 deb libs optional arch=any
 libusbmuxd4-dbg deb debug extra arch=any
Directory: pool/main/libu/libusbmuxd
Priority: extra
Section: misc

Package: libusbmuxd-dev
Source: libusbmuxd (1.0.10-3)
Version: 1.0.10-3+b1
Installed-Size: 85
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libusbmuxd4 (= 1.0.10-3+b1)
Description-en: USB multiplexor daemon for iPhone and iPod Touch devices - devel
 usbmuxd, the USB multiplexor daemon, is in charge of coordinating
 access to iPhone and iPod Touch services over USB. Synchronization and
 management applications for the iPhone and iPod Touch need this daemon
 to communicate with such devices concurrently.
 .
 This package contains the development files.
Description-md5: 9f61258d5ec2de1b9f68ed3c9cc3de94
Multi-Arch: same
Homepage: http://marcansoft.com/blog/iphonelinux/usbmuxd/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/libu/libusbmuxd/libusbmuxd-dev_1.0.10-3+b1_amd64.deb
Size: 18346
MD5sum: dfb7ceb68e3672f40382d7dde3ce3383
SHA256: 861d27814878561f5142e024788bf12e512664337cd8a188a3286a0df67813c9

Package: libusbmuxd4
Source: libusbmuxd (1.0.10-3)
Version: 1.0.10-3+b1
Installed-Size: 51
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libc6 (>= 2.15), libplist3 (>= 1.11)
Breaks: usbmuxd (<< 1.0.8-3+)
Description-en: USB multiplexor daemon for iPhone and iPod Touch devices - 
library
 usbmuxd, the USB multiplexor daemon, is in charge of coordinating
 access to iPhone and iPod Touch services over USB. Synchronization and
 management applications for the iPhone and iPod Touch need this daemon
 to communicate with such devices concurrently.
 .
 This package contains the shared library.
Description-md5: a758250e6a9071eca15221f3c421e4fa
Multi-Arch: same
Homepage: 

Bug#867216: O: libimobiledevice -- Library for communicating with the iPhone and iPod Touch

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of libimobiledevice has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/libimobiledevice


Package: libimobiledevice
Binary: libimobiledevice6, libimobiledevice-dev, libimobiledevice6-dbg, 
python-imobiledevice, libimobiledevice-utils, libimobiledevice-doc
Version: 1.2.0+dfsg-3.1
Maintainer: gtkpod Maintainers 
Uploaders: Julien Lavergne 
Build-Depends: debhelper (>= 9), dh-python, libgnutls28-dev, libgcrypt20-dev, 
libusb-1.0-0-dev (>= 1.0.3) [linux-any], libglib2.0-dev (>= 2.14.1), 
libplist-dev (>= 1.11), libplist++-dev (>= 1.11), python-all-dev (>= 2.6.6-3~), 
cython (>= 0.17.0), libusbmuxd-dev (>= 1.0.9), libtasn1-6-dev (>= 1.1), 
libreadline-dev, python-plist (>= 1.8-2~), dh-autoreconf
Architecture: any all
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 925b73d93a511815eb752f8154abd3c4 2782 libimobiledevice_1.2.0+dfsg-3.1.dsc
 c61c9b5710a65de64624da0302a22e9b 605446 
libimobiledevice_1.2.0+dfsg.orig.tar.bz2
 8c84aa85903c4fce0be65728f0c20345 14668 
libimobiledevice_1.2.0+dfsg-3.1.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/libimobiledevice.git
Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/libimobiledevice.git
Checksums-Sha256:
 cf7debc5ea75d9586a4af547672348d8b1dd19ef3737cc3708272c6a513f0802 2782 
libimobiledevice_1.2.0+dfsg-3.1.dsc
 6b792802c515e537509272549e269675d11d23eb6c6179f87d7212fc27587dd7 605446 
libimobiledevice_1.2.0+dfsg.orig.tar.bz2
 a38d5b79fcbde163ef54bbd2971b000e2e7377befcbea2841ec0d7720a20cc9d 14668 
libimobiledevice_1.2.0+dfsg-3.1.debian.tar.xz
Homepage: http://libimobiledevice.org/
Package-List: 
 libimobiledevice-dev deb libdevel optional arch=any
 libimobiledevice-doc deb doc optional arch=all
 libimobiledevice-utils deb utils optional arch=any
 libimobiledevice6 deb libs optional arch=any
 libimobiledevice6-dbg deb debug extra arch=any
 python-imobiledevice deb python optional arch=any
Directory: pool/main/libi/libimobiledevice
Priority: source
Section: libs

Package: libimobiledevice6
Source: libimobiledevice
Version: 1.2.0+dfsg-3.1
Installed-Size: 181
Maintainer: gtkpod Maintainers 
Architecture: amd64
Replaces: libimobiledevice0, libimobiledevice1, libiphone0
Depends: libc6 (>= 2.14), libgcrypt20 (>= 1.7.0), libgnutls30 (>= 3.5.6), 
libplist3 (>= 1.11), libtasn1-6 (>= 4.5), libusbmuxd4 (>= 1.0.10)
Recommends: usbmuxd
Suggests: libusbmuxd-tools
Conflicts: libiphone0
Description-en: Library for communicating with the iPhone and iPod Touch
 libimobiledevice is a library that talks the native Apple USB protocols that
 the iPhone and iPod Touch use. Unlike other projects, libimobiledevice does
 not depend on using any existing libraries from Apple.
Description-md5: b63dfdd75baa933b181ba059d3cb96a2
Multi-Arch: same
Homepage: http://libimobiledevice.org/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: 
pool/main/libi/libimobiledevice/libimobiledevice6_1.2.0+dfsg-3.1_amd64.deb
Size: 64534
MD5sum: 2b36ea31bcd2afc6361b0277a1c4cb64
SHA256: b5d0ca00124ace5e2a05b15ede86f1db591366c7a19d0ac07df253d3a1894758

Package: libimobiledevice-dev
Source: libimobiledevice
Version: 1.2.0+dfsg-3.1
Installed-Size: 498
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libimobiledevice6 (= 1.2.0+dfsg-3.1), libglib2.0-dev, libplist-dev, 
libusbmuxd-dev, libgnutls28-dev, libgcrypt20-dev, libtasn1-6-dev
Description-en: Library for communicating with iPhone and iPod Touch devices
 libimobiledevice is a library that talks the native Apple USB protocols that
 the iPhone and iPod Touch use. Unlike other projects, libimobiledevice does
 not depend on using any existing libraries from Apple.
 .
 This package contains the development files.
Description-md5: fd9a20c2b440f01ec4b9eb965aa42e9a
Multi-Arch: foreign
Homepage: http://libimobiledevice.org/
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: 
pool/main/libi/libimobiledevice/libimobiledevice-dev_1.2.0+dfsg-3.1_amd64.deb
Size: 83970
MD5sum: 2a5c75c4cfdbbeb3e989a0bd3c469cc6
SHA256: 33b7fbb3422c1016b05ebb8ca5d3df464f8a56d46fcec2fddff2a19248d4d323

Package: libimobiledevice6-dbg
Source: libimobiledevice
Version: 1.2.0+dfsg-3.1
Installed-Size: 1211
Maintainer: gtkpod Maintainers 
Architecture: amd64
Replaces: libimobiledevice0-dbg, libimobiledevice1-dbg, libimobiledevice2-dbg, 
libimobiledevice3-dbg
Depends: libimobiledevice6 (= 1.2.0+dfsg-3.1)
Conflicts: libimobiledevice0-dbg, 

Bug#867217: O: libplist -- Library for handling Apple binary and XML property lists

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of libplist has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/libplist


Package: libplist
Binary: libplist3, libplist++3v5, libplist-dev, libplist++-dev, libplist-dbg, 
python-plist, libplist-utils, libplist-doc
Version: 1.12+git+1+e37ca00-0.3
Maintainer: gtkpod Maintainers 
Uploaders: Julien Lavergne 
Build-Depends: debhelper (>= 9.20120417~), dpkg-dev (>= 1.16.1), dh-autoreconf, 
dh-python, pkg-config, libxml2-dev, cython, python-all-dev (>= 2.6.6-3~), 
doxygen, chrpath
Architecture: any all
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 b896e68d455f3af10ab1fbb82f3c779c 2740 libplist_1.12+git+1+e37ca00-0.3.dsc
 7715473abb463eba9687b0c024933df2 160736 libplist_1.12+git+1+e37ca00.orig.tar.gz
 79c84edbd2727be7c4882134fa6d3f45 11240 
libplist_1.12+git+1+e37ca00-0.3.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/libplist.git
Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/libplist.git -b debian
Checksums-Sha256:
 c94e711c4982f0718ab5cc81516f30ccbaa414f083a53451c5668503880844cd 2740 
libplist_1.12+git+1+e37ca00-0.3.dsc
 676f970b325b6bee68648551c066260bed99aa510f620f9488dbe060d4244695 160736 
libplist_1.12+git+1+e37ca00.orig.tar.gz
 af381c17239984eae57269d929bed0fe53887ef0a4f101f4ed8f4bdfdcbfad45 11240 
libplist_1.12+git+1+e37ca00-0.3.debian.tar.xz
Homepage: http://www.libimobiledevice.org/
Package-List: 
 libplist++-dev deb libdevel optional arch=any
 libplist++3v5 deb libs optional arch=any
 libplist-dbg deb debug extra arch=any
 libplist-dev deb libdevel optional arch=any
 libplist-doc deb doc optional arch=all
 libplist-utils deb utils optional arch=any
 libplist3 deb libs optional arch=any
 python-plist deb python optional arch=any
Directory: pool/main/libp/libplist
Priority: source
Section: libs

Package: libplist3
Source: libplist
Version: 2.0.0-1
Installed-Size: 83
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libc6 (>= 2.14)
Description-en: Library for handling Apple binary and XML property lists
 libplist is a library for reading and writing the Apple binary and XML
 property lists format. It's part of the libimobiledevice stack, providing
 access to iDevices (iPod, iPhone, iPad ...).
Description-md5: 025ff093cbf9bf08e17d0248380c6438
Multi-Arch: same
Homepage: http://www.libimobiledevice.org/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libp/libplist/libplist3_2.0.0-1_amd64.deb
Size: 34980
MD5sum: d15825e33514b44e582a1ce9a1fb15b4
SHA256: cb43b64ee3f8d018bbc4cad8726669a0e65e0cdbaf6f648859172b33e9e4f855

Package: libplist3
Source: libplist
Version: 1.12+git+1+e37ca00-0.3
Installed-Size: 86
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libc6 (>= 2.14)
Description-en: Library for handling Apple binary and XML property lists
 libplist is a library for reading and writing the Apple binary and XML
 property lists format. It's part of the libimobiledevice stack, providing
 access to iDevices (iPod, iPhone, iPad ...).
Description-md5: 025ff093cbf9bf08e17d0248380c6438
Multi-Arch: same
Homepage: http://www.libimobiledevice.org/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libp/libplist/libplist3_1.12+git+1+e37ca00-0.3_amd64.deb
Size: 34574
MD5sum: 7be8dc347ff5b3a6cca6768e5adeb9e4
SHA256: 951ad19cad187819778b45f0ecf33deab69cd02d86dad7bca58e778211da0d8f

Package: libplist++3v5
Source: libplist
Version: 2.0.0-1
Installed-Size: 94
Maintainer: gtkpod Maintainers 
Architecture: amd64
Replaces: libplist++3
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libplist3 (>= 1.11), libstdc++6 
(>= 5.2)
Conflicts: libplist++3
Description-en: Library for handling Apple binary and XML property lists
 libplist is a library for reading and writing the Apple binary and XML
 property lists format. It's part of the libimobiledevice stack, providing
 access to iDevices (iPod, iPhone, iPad ...).
 .
 This library is the C++ implementation of the libplist API.
Description-md5: 5a7ac9d5c114b33899ffd81af3b81f44
Multi-Arch: same
Homepage: http://www.libimobiledevice.org/
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libp/libplist/libplist++3v5_2.0.0-1_amd64.deb
Size: 26368
MD5sum: 9a9ea24307242f6a2b55e1f801dc29ff
SHA256: 18d74351a76fe5738d4b744049c10a26c46c0a4f73c54e675200a97822ea8cc9

Package: libplist++3v5
Source: libplist
Version: 1.12+git+1+e37ca00-0.3
Installed-Size: 94
Maintainer: gtkpod Maintainers 

Bug#867104: wanna-build issue with src:perl versioned Provides

[Ralf Treinen]

On Tue, Jul 04, 2017 at 10:29:35PM +0300, Niko Tyni wrote:
> (dropped some cc's)
> 
> On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote:
> 
> > thanks for having figured that out. I tend to believe that dose is right
> > in this case. Since it is not possible to install at the same
> > time two different versions of the same real package, the same should
> > IMHO hold when one is real and the other virtual. Why should this be
> > possible?
> 
> Well, dpkg and apt allow it for starters.
> 
> The idea with the perl packages is that the src:perl binary packages
> offer an older "stable" version of some modules while a newer version is
> packaged separately and gets installed earlier on the Perl search path
> (so it overrides the src:perl version when installed.)
> 
> This has been the case for ages with the src:perl packages Providing
> an unversioned virtual package. The change here is that the virtual
> package is now versioned, which would simplify lots of dependencies
> that currently read like (for instance)

So, that means that something like

Depends: p (=1), p (=2)

suddenly becomes satisfiable (when there is one real package p and
one virtual package)? Would you also allow to have the packages p
and q installed at the same time, in the following situation:

Package: p
Version: 1
Provides: v (=1)

Package: q
Version: 1
Provides: v (=2)

If yes this seems to me a quite drastic change of the meaning of 
package relations. Has this been discussed somewhere?

-Ralf.

Bug#867215: O: libgpod -- libgpod is a library meant to abstract access to an iPod's content

[Adrian Bunk]

Package: wnpp
Severity: normal

The current maintainer of libgpod has orphaned this package.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
http://www.debian.org/devel/wnpp/index.html#howto-o
for detailed instructions how to adopt a package properly.

More information about this package:

http://tracker.debian.org/pkg/libgpod


Package: libgpod
Binary: libgpod-nogtk-dev, libgpod4-nogtk, libgpod-dev, libgpod4, 
libgpod-common, libgpod-doc, python-gpod, libgpod-cil, libgpod-cil-dev
Version: 0.8.3-8.2
Maintainer: gtkpod Maintainers 
Uploaders: Chow Loong Jin 
Build-Depends: debhelper (>= 9), dh-autoreconf, dh-python, autotools-dev, 
intltool, pkg-config, libglib2.0-dev (>= 2.16), libgdk-pixbuf2.0-dev, 
libxml2-dev, libsgutils2-dev, libsqlite3-dev, libplist-dev, libusb-1.0-0-dev, 
libimobiledevice-dev, zlib1g-dev, swig, python-all-dev (>= 2.6.6-3~), 
python-mutagen, python-gobject-dev, chrpath, gtk-doc-tools, docbook-xml, 
xsltproc, cli-common-dev (>= 0.5.7) [amd64 armel armhf arm64 i386 mipsel 
kfreebsd-amd64 kfreebsd-i386 ppc64 ppc64el s390x], mono-devel (>= 2.4.3) [amd64 
armel armhf arm64 i386 mipsel kfreebsd-amd64 kfreebsd-i386 ppc64 ppc64el 
s390x], libgtk2.0-cil-dev (>= 2.12) [amd64 armel armhf arm64 i386 mipsel 
kfreebsd-amd64 kfreebsd-i386 ppc64 ppc64el s390x], libglib2.0-cil-dev (>= 2.12) 
[amd64 armel armhf arm64 i386 mipsel kfreebsd-amd64 kfreebsd-i386 ppc64 ppc64el 
s390x]
Architecture: any all
Standards-Version: 3.9.6
Format: 3.0 (quilt)
Files:
 2bb598d1d2e27851d5db00cb6a3d5665 3359 libgpod_0.8.3-8.2.dsc
 f8a0b7a34e768e33a708e8dd172bd6f8 801903 libgpod_0.8.3.orig.tar.bz2
 7d3621a1df948d6425ca8544c37479e8 16420 libgpod_0.8.3-8.2.debian.tar.xz
Vcs-Browser: http://git.debian.org/?p=pkg-gtkpod/packages/libgpod.git
Vcs-Git: git://git.debian.org/git/pkg-gtkpod/packages/libgpod.git
Checksums-Sha256:
 d13315f8f18d0870ad82ec17d02771cf7ce0eb7044134a928c307c1b23ecfa43 3359 
libgpod_0.8.3-8.2.dsc
 638a7959d04e95f1e62abad02bd33702e4e8dfef98485ac7d9d50395c37e955d 801903 
libgpod_0.8.3.orig.tar.bz2
 3835f9e91ff5ecb321ee5eb70c3cb8015ca1268483f25706cae07dd4723714a6 16420 
libgpod_0.8.3-8.2.debian.tar.xz
Homepage: http://www.gtkpod.org/wiki/Libgpod
Package-List: 
 libgpod-cil deb cli-mono optional 
arch=amd64,armel,armhf,arm64,i386,mipsel,kfreebsd-amd64,kfreebsd-i386,ppc64,ppc64el,s390x
 libgpod-cil-dev deb cli-mono optional 
arch=amd64,armel,armhf,arm64,i386,mipsel,kfreebsd-amd64,kfreebsd-i386,ppc64,ppc64el,s390x
 libgpod-common deb libs optional arch=any
 libgpod-dev deb libdevel optional arch=any
 libgpod-doc deb doc optional arch=all
 libgpod-nogtk-dev deb oldlibs extra arch=any
 libgpod4 deb libs optional arch=any
 libgpod4-nogtk deb oldlibs extra arch=any
 python-gpod deb python optional arch=any
Directory: pool/main/libg/libgpod
Priority: source
Section: libs

Package: libgpod-nogtk-dev
Source: libgpod
Version: 0.8.3-8.2
Installed-Size: 66
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libgpod-dev (= 0.8.3-8.2)
Description-en: development files for libgpod - transitional package
 libgpod is a library meant to abstract access to an iPod's content. It
 provides an easy to use API to retrieve the list of files and playlist
 stored on an iPod, to modify them and to save them back to the iPod.
 .
 This transitional package ensures that libgpod-nogtk-dev is replaced
 by libgpod-dev on upgrade.
Description-md5: 500e8d7ee98e4a70b43089f96032381d
Homepage: http://www.gtkpod.org/wiki/Libgpod
Tag: devel::library, role::devel-lib
Section: libdevel
Priority: optional
Filename: pool/main/libg/libgpod/libgpod-nogtk-dev_0.8.3-8.2_amd64.deb
Size: 52024
MD5sum: 2b98f94a3a732f3c6921b17e6505ec12
SHA256: b2b31012a402ca4f93338774910a78caee54ad2db3614e83b6a780de5c65b2a5

Package: libgpod4-nogtk
Source: libgpod
Version: 0.8.3-8.2
Installed-Size: 62
Maintainer: gtkpod Maintainers 
Architecture: amd64
Depends: libgpod4 (= 0.8.3-8.2)
Description-en: library to read and write songs to an iPod - transitional 
package
 libgpod is a library meant to abstract access to an iPod's content. It
 provides an easy to use API to retrieve the list of files and playlist
 stored on an iPod, to modify them and to save them back to the iPod.
 .
 This transitional package ensures that libgpod4-nogtk is replaced
 by libgpod4 on upgrade.
Description-md5: aecc8842ffe168b03988fc11469fe3e1
Multi-Arch: same
Homepage: http://www.gtkpod.org/wiki/Libgpod
Tag: role::shared-lib
Section: libs
Priority: optional
Filename: pool/main/libg/libgpod/libgpod4-nogtk_0.8.3-8.2_amd64.deb
Size: 51868
MD5sum: 9ac03349cc7dbf205139da2e1f15df30
SHA256: ad1cd360501210ca603ee2992fd99b0bbca5ff034e0a540a9e6034671fb637a6

Package: libgpod-dev
Source: libgpod
Version: 0.8.3-8.2

Bug#867106: wine-development: build-depends unicode-data (< 10.0) but 10.0.0-1 is to be installed

[Jens Reyer]

I'm just catching up, and am not working on Wine yet.  So  just fyi
recently there was a patchset at WineHQ for Unicode 10:

https://www.winehq.org/pipermail/wine-patches/2017-July/163321.html
https://www.winehq.org/pipermail/wine-patches/2017-July/163322.html

That one got rejected, but I assume it at least made Wine build again.


Alternatively, I wonder if it is acceptable to temporarily embed the
Unicode 9 files in our source packages.  (I'm quite sure that WineHQ
will update to 10 soon, definitely in time for buster.)

Bug#867209: libreoffice: Letter wizard can't find wizardi templates

[Sebastian Andrzej Siewior]

On 2017-07-04 21:59:17 [+0200], Rene Engelhard wrote:
> > -- System Information:
> > Debian Release: buster/sid
> >   APT prefers unstable
> >   APT policy: (500, 'unstable')
> 
> How did you get this version on your system if you don't have experimental
> in your sources.list?

I have it commented out (and enable it when needed to save apt-get update
time). I enabled it after reportbug pointed out that there is newish
libreoffice in exp.

Thx for looking into it.

> Regards,
> 
> Rene

Sebastian

Bug#867214: git-buildpackage: Strange format of commit message added by import-orig

[Robert Luberda]

Package: git-buildpackage
Version: 0.8.17
Severity: normal

Hi,

gbp import-orig stared producing merge commit messages like 
this one:


Updated version 20170702 from 'upstream/20170702'

with Debian dir 43f841d7950f0587745d57c8c87fd79e1aed60dd


which I don't really like for the three following reasons:

1. The commit message uses a really bizzare format of:
   
A description of the change split for some

reason in the middle of a sentence

instead of:
   
Short summary of the change

More detailed description possibly consisting of several
lines or even paragraphs with each sentence ended with 
a trailing dot.

2. I am not native speaker, and maybe that's why I have an impression
that a small word "to" is missing in "Updated version 20170702". But to
be honest I can't really see the need of duplicating the version number
in the same line. Prevously the version was mentioned once in the summary, 
and once in the long description, what IMHO looked much better:

Merge tag 'upstream/20161007'

Upstream version 20161007

3. The commit message uses past tense ("Updated"), where previously infinitive
was used (e.g. "Merge").



It would be nice if all those three items could be fixed. In my opinion
something like this:

Merge tag 'upstream/20170702'

Update to upstream version 20170702
with Debian dir 43f841d7950f0587745d57c8c87fd79e1aed60dd.

would but better, but as I wrote I am not a native.

Regards,
robert
  

Bug#866964: Fwd: mpi_set_secure leads to heap corruption

[Mark Wooding]

NIIBE Yutaka  writes:

> Thank you for forwarding the bug report.
> 
> Fixed both for master and LIBGCRYPT-1-7-BRANCH.

Thanks.

> Yes.  While the patch is right, I followed the suggestion for less
> surprise.

Fair enough.

> While there is the API, I don't know the real use case.  So, I did
> search:
> 
> https://codesearch.debian.net/search?q=mpi_set_flag.*GCRYMPI_FLAG_SECURE
> 
> and seccure-0.5_1 has use cases.  Since all use cases are
> gcry_mpi_scan then gcry_mpi_set_flag, I think that those cases are
> safe for heap corruption.

Alas not.  I found this bug because seccure-0.5_1 broke on amd64 (and I
couldn't mount my backup disks again until I fixed it).  What happened
is that `gcry_mpi_scan' returned a bignum with alloced = 5 and nlimbs =
4; zeroizing the limb vector clobbered the secure-memory pool structure
in a way I didn't investigate too carefully, but the result was that
`mb_get_new' thought that the pool was full and `gcry_malloc_secure'
failed.  As far as I can make out, `seccure-decrypt' can't decrypt
anything at all on amd64.

-- [mdw]

Bug#820927: Tray icon looks ugly here too

[Alf]

I have a very dark panel in XFCE and xfce4-pulseaudio-plugin 0.2.4
(Debian Stretch) looks really ugly with the almost white background sqare.
I also tried to edit the svg-icons supplied with he package in
/usr/share/icons/hicolor/scalable/status/audio-volume-??-symbolic.svg
without any success.
My whisch: background transparent and color of volume indicator
selectable/reversible.
Seems to be hard coded :-(

Bug#867209: libreoffice: Letter wizard can't find wizardi templates

[Rene Engelhard]

tag 867209 + confirmed
found 867209 1:5.4.0~beta2-1
thanks

Hi,

On Tue, Jul 04, 2017 at 09:48:22PM +0200, Sebastian Andrzej Siewior wrote:
> I clickety clack
> File -> Wizards -> Letter
> 
> and nothing happens. Except for the console where I read:
> 
> Traceback (most recent call last):
>   File 
> "/usr/lib/libreoffice/program/wizards/letter/LetterWizardDialogImpl.py",
> line 87, in startWizard
> self.initializePaths()
>   File "/usr/lib/libreoffice/program/wizards/ui/WizardDialog.py", line 139, in
> initializePaths
> raise Exception("could not find wizard templates")
> Exception: could not find wizard templates

Yeah, I know. Also saw this when testing...

Interestingly, the paths between Debian and upstream DO NOT
differ wrt wizards and templates and upstream it works...

> but I expected the almighty wizard instead. I set the severity to normal
> despite the fact that I can't write any letters.

Yeah, it's important at last. You can reuse old letters ;)

Regards,

Rene
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')

How did you get this version on your system if you don't have experimental
in your sources.list?

Regards,

Rene

Bug#867213: syslog-ng-incubator: FTBFS: error: unknown type name 'SBGString'

[Niko Tyni]

Package: syslog-ng-incubator
Version: 0.5.0-4
Severity: serious
Tags: sid buster
Control: block 866389 with -1

This package fails to build on current sid/amd64.

>From the build log:

  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog 
-I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua 
-I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c 
../../modules/lua/lua-dest.c  -fPIC -DPIC -o 
modules/lua/.libs/modules_lua_liblua_la-lua-dest.o
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog 
-I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua 
-I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c 
../../modules/lua/lua-plugin.c  -fPIC -DPIC -o 
modules/lua/.libs/modules_lua_liblua_la-lua-plugin.o
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog 
-I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua 
-I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c 
../../modules/lua/lua-parser.c  -fPIC -DPIC -o 
modules/lua/.libs/modules_lua_liblua_la-lua-parser.o
  ../../modules/lua/lua-dest.c: In function 'lua_dd_queue':
  ../../modules/lua/lua-dest.c:145:3: error: unknown type name 'SBGString'
 SBGString *str = sb_gstring_acquire();
 ^
  [...]
  Makefile:1839: recipe for target 
'modules/lua/modules_lua_liblua_la-lua-dest.lo' failed
  make[2]: *** [modules/lua/modules_lua_liblua_la-lua-dest.lo] Error 1
  make[2]: *** Waiting for unfinished jobs
  libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/lua5.2 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/eventlog 
-I/usr/include/syslog-ng -I/usr/include/eventlog -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I../../modules/lua 
-I./modules/lua -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -c 
modules/lua/lua-grammar.c -o modules/lua/modules_lua_liblua_la-lua-grammar.o 
>/dev/null 2>&1
  make[2]: Leaving directory '/<>/debian/build-tree'
  Makefile:1188: recipe for target 'all' failed
  make[1]: *** [all] Error 2
  
-- 
Niko Tyni   nt...@debian.org

Bug#867211: thunar: freeze when content of a folder changes rapidly

[Markus Hentsch]

Package: thunar
Version: 1.6.11-1
Severity: important

Dear Maintainer,

Thunar is freezing when the content of a folder that is being displayed in a 
Thunar window is being updated rapidly, e.g. while compiling software within 
that folder. If Thunar is running in daemon mode, all of its windows will 
freeze, otherwise only the windows that are displaying the folder in question.


Steps to reproduce:

1. use "apt-get source thunar" to download and extract Thunar's source package
2. navigate into the resulting "thunar-1.6.11" directory that contains the 
source
3. keep the Thunar window open and open up a terminal within that directory
4. use "debuild -us -uc" to rebuild the Thunar package


Expected outcome:

The Thunar window should show the correct content of the "thunar-1.6.11" folder 
and react correctly to user input.


Actual outcome:

After a few view updates (files getting created rearranged in the folder) 
during the "debuild" process, the Thunar window will freeze eventually. It 
stops updating the view and becomes totally unresponsive, not reacting to any 
user input. If Thunar was running in daemon mode all Thunar windows are frozen 
and Thunar needs to be killed.


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

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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-1
ii  exo-utils   0.10.7-1
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11+deb9u1
ii  libcairo2   1.14.8-1
ii  libdbus-1-3 1.10.18-1
ii  libdbus-glib-1-20.108-2
ii  libexo-1-0  0.10.7-1
ii  libgdk-pixbuf2.0-0  2.36.5-2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libgudev-1.0-0  230-3
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-2
ii  libpango-1.0-0  1.40.5-1
ii  libsm6  2:1.2.2-1+b3
ii  libthunarx-2-0  1.6.11-1
ii  libxfce4ui-1-0  4.12.1-2
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.8-1
ii  thunar-data 1.6.11-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.10.18-1
ii  gvfs  1.30.4-1
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libpangocairo-1.0-0   1.40.5-1
ii  libpangoft2-1.0-0 1.40.5-1
ii  thunar-volman 0.8.1-2
ii  tumbler   0.1.31-2+b3
ii  xdg-user-dirs 0.15-2+b1
ii  xfce4-panel   4.12.1-2

Versions of packages thunar suggests:
pn  thunar-archive-plugin 
ii  thunar-media-tags-plugin  0.2.1-1+b2

-- no debconf information

Bug#867212: octave: Octave function strncmp is case insensitive

[Thierry Rascle]

Package: octave
Version: 4.2.1-2
Severity: normal
Tags: patch upstream

Dear Maintainer,

Octave function strncmp performs a case insensitive string comparison,
like strncmpi. strncmp should do a case sensitive string comparison.

This issue seems to affect recent versions of Octave. The version in
Debian Stable is not affected.

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

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

Versions of packages octave depends on:
ii  libamd21:4.5.5-1
ii  libarpack2 3.5.0-1
ii  libasound2 1.1.3-5
ii  libblas3 [libblas.so.3]3.7.0-2
ii  libbz2-1.0 1.0.6-8.1
ii  libc6  2.24-12
ii  libcamd2   1:4.5.5-1
ii  libccolamd21:4.5.5-1
ii  libcholmod31:4.5.5-1
ii  libcolamd2 1:4.5.5-1
ii  libcxsparse3   1:4.5.5-1
ii  libfftw3-double3   3.3.6p2-1
ii  libfftw3-single3   3.3.6p2-1
ii  libfltk-gl1.3  1.3.4-4
ii  libfltk1.3 1.3.4-4
ii  libfreetype6   2.8-0.2
ii  libgcc11:7.1.0-8
ii  libgl1-mesa-glx [libgl1]   17.1.3-2
ii  libglpk40  4.62-1
ii  libglu1-mesa [libglu1] 9.0.0-2.1
ii  libgomp1   7.1.0-8
ii  liblapack3 [liblapack.so.3]3.7.0-2
ii  liboctave4 4.2.1-2
ii  libopenblas-base [liblapack.so.3]  0.2.19-3
ii  libosmesa6 17.1.3-2
ii  libportaudio2  19.6.0-1
ii  libqhull7  2015.2-2
ii  libqrupdate1   1.1.2-2
ii  libqscintilla2-12v52.9.3+dfsg-4+b1
ii  libqt4-network 4:4.8.7+dfsg-11
ii  libqt4-opengl  4:4.8.7+dfsg-11
ii  libqtcore4 4:4.8.7+dfsg-11
ii  libqtgui4  4:4.8.7+dfsg-11
ii  libsndfile11.0.28-2
ii  libstdc++6 7.1.0-8
ii  libsuitesparseconfig4  1:4.5.5-1
ii  libumfpack51:4.5.5-1
ii  libx11-6   2:1.6.4-3
ii  octave-common  4.2.1-2
ii  texinfo6.4.0.dfsg.1-1
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages octave recommends:
ii  default-jre-headless  2:1.8-59
ii  gnuplot-x11   5.0.5+dfsg1-7
ii  libopenblas-base  0.2.19-3
ii  octave-info   4.2.1-2
ii  pstoedit  3.70-3+b2

Versions of packages octave suggests:
pn  octave-doc  
pn  octave-htmldoc  

-- no debconf information
--- a/liboctave/util/oct-string.cc
+++ b/liboctave/util/oct-string.cc
@@ -147,7 +147,7 @@
  const typename T::size_type n)
 {
   return (numel (str_a) >= n && numel (str_b) >= n
-  && str_data_cmpi (str_a.data (), str_b.data (), n));
+  && str_data_cmp (str_a.data (), str_b.data (), n));
 }
 
 template
@@ -156,7 +156,7 @@
  const typename T::size_type n)
 {
   return (numel (str_a) >= n && strlen (str_b) >= n
-  && str_data_cmpi (str_a.data (), str_b, n));
+  && str_data_cmp (str_a.data (), str_b, n));
 }
 
 

Bug#867209: libreoffice: Letter wizard can't find wizardi templates

[Sebastian Andrzej Siewior]

Package: libreoffice
Version: 1:5.4.0~rc1-1
Severity: normal

I clickety clack
File -> Wizards -> Letter

and nothing happens. Except for the console where I read:

Traceback (most recent call last):
  File "/usr/lib/libreoffice/program/wizards/letter/LetterWizardDialogImpl.py",
line 87, in startWizard
self.initializePaths()
  File "/usr/lib/libreoffice/program/wizards/ui/WizardDialog.py", line 139, in
initializePaths
raise Exception("could not find wizard templates")
Exception: could not find wizard templates

but I expected the almighty wizard instead. I set the severity to normal
despite the fact that I can't write any letters.

Sebastian

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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:5.4.0~rc1-1
ii  libreoffice-base   1:5.4.0~rc1-1
ii  libreoffice-calc   1:5.4.0~rc1-1
ii  libreoffice-core   1:5.4.0~rc1-1
ii  libreoffice-draw   1:5.4.0~rc1-1
ii  libreoffice-impress1:5.4.0~rc1-1
ii  libreoffice-math   1:5.4.0~rc1-1
ii  libreoffice-report-builder-bin 1:5.4.0~rc1-1
ii  libreoffice-writer 1:5.4.0~rc1-1
ii  python3-uno1:5.4.0~rc1-1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-1
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-linuxlibertine5.3.0-2
ii  fonts-open-sans 1.11-1
ii  fonts-sil-gentium-basic 1.1-7
ii  libreoffice-java-common 1:5.4.0~rc1-1
ii  libreoffice-librelogo   1:5.3.4-1
ii  libreoffice-nlpsolver   0.9+LibO5.3.4-1
ii  libreoffice-ogltrans1:5.4.0~rc1-1
ii  libreoffice-report-builder  1:5.4.0~rc1-1
ii  libreoffice-script-provider-bsh 1:5.4.0~rc1-1
ii  libreoffice-script-provider-js  1:5.4.0~rc1-1
ii  libreoffice-script-provider-python  1:5.4.0~rc1-1
ii  libreoffice-sdbc-postgresql 1:5.4.0~rc1-1
ii  libreoffice-wiki-publisher  1.2.0+LibO5.3.4-1

Versions of packages libreoffice suggests:
pn  cups-bsd
ii  default-jre [java6-runtime] 2:1.8-59
ii  firefox 54.0-1
ii  gstreamer1.0-libav  1.12.1-1
ii  gstreamer1.0-plugins-bad1.12.1-1
ii  gstreamer1.0-plugins-base   1.12.1-1
ii  gstreamer1.0-plugins-good   1.12.1-1
pn  gstreamer1.0-plugins-ugly   
ii  hunspell-en-us [hunspell-dictionary]20070829-7
pn  hyphen-hyphenation-patterns 
ii  icedove 1:52.2.1-3
ii  iceweasel   52.2.0esr-1
ii  imagemagick 8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-11
ii  libgl1-mesa-glx [libgl1]17.1.4-1
pn  libreoffice-gnome | libreoffice-kde 
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.25-4.1
ii  libxrender1 1:0.9.10-1
pn  myspell-dictionary  
pn  mythes-thesaurus
pn  openclipart2-libreoffice | openclipart-libreoffice  
ii  openjdk-8-jre [java6-runtime]   8u131-b11-2
pn  pstoedit
ii  thunderbird [icedove]   1:52.2.1-3
ii  unixodbc2.3.4-1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.12.3-0.1
ii  fonts-opensymbol  2:102.10+LibO5.3.4-1
ii  libboost-date-time1.62.0  1.62.0+dfsg-4+b1
ii  libc6 2.24-12
ii  libcairo2 1.14.10-1
ii  libclucene-contribs1v52.3.3.4+dfsg-1
ii  libclucene-core1v52.3.3.4+dfsg-1
ii  libcmis-0.5-5v5   0.5.1+git20160603-3+b1
ii  libcups2  2.2.3-2
ii  libcurl3-gnutls   7.52.1-5
ii  libdbus-1-3   1.10.20-1
ii  libdbus-glib-1-2  

Bug#866693: nmu: jpy_0.8-5

[Emilio Pozuelo Monfort]

On 01/07/17 04:28, Andreas Beckmann wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu jpy_0.8-5 . ANY . unstable . -m "Rebuild with debhelper 10.6.1"
> 
> That package seems to be affected by #866572, too.

Is it? Can point out why? I can't find any weird files on the amd64 or arm64
python-jpy binaries.

Cheers,
Emilio

Bug#867210: libtext-mecab-perl: FTBFS: test failures: Failed to create mecab instance

[Niko Tyni]

Package: libtext-mecab-perl
Version: 0.20016-1
Severity: serious
Tags: sid buster
Control: block 866389 with -1
X-Debbugs-Cc: Hideki Yamane 

This package fails to build on current sid/amd64.

This is probably related to #867173 / #866389 (mecab-jumandic-utf8
regression in sid) but I haven't verified that. Copying Hideki-san to
let him know.

>From the build log:

  t/node/02_api.t .. 
  1..2
  ok 1 - use Text::MeCab;
  ok 2 - Text::MeCab::Node->can(...)
  ok
  Failed to create mecab instance at /<>/blib/lib/Text/MeCab.pm 
line 64.
  # Tests were run but no plan was declared and done_testing() was not seen.
  # Looks like your test exited with 2 just after 1.
  [...]
  Test Summary Report
  ---
  t/node/03_clone.t  (Wstat: 512 Tests: 1 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
  t/node/04_clone_free.t (Wstat: 512 Tests: 1 Failed: 0)
Non-zero exit status: 2
  t/node/05_format.t (Wstat: 512 Tests: 1 Failed: 0)
Non-zero exit status: 2
  t/tagger/03_basic.t(Wstat: 512 Tests: 1 Failed: 0)
Non-zero exit status: 2
  Files=10, Tests=66,  1 wallclock secs ( 0.05 usr  0.01 sys +  0.26 cusr  0.01 
csys =  0.33 CPU)
  Result: FAIL

-- 
Niko Tyni   nt...@debian.org

Bug#866797: transition: gdal

[Emilio Pozuelo Monfort]

Control: forwarded -1 
https://release.debian.org/transitions/html/gdal-2.1.2.html

On 01/07/17 21:17, Bas Couwenberg wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> For the Debian GIS team I'd like to transition to GDAL 2.2.1.
> 
> Like the previous transition to GDAL 2.1.2 (#842288), there is no SONAME
> bump, only the virtual ABI package changed to account for the C++ symbol
> changes.
> 
> All reverse dependencies rebuilt successfully with GDAL 2.2.1 from
> experimental as summarized below, except rasterio & vtk6.
> 
> rasterio cannot be built yet because python-numpy hasn't been built with
> Python 3.6 yet as part of the python3-defaults transition (#866335).
> rasterio built successfully with Python 3.5 and GDAL 2.2.1~rc1, so this
> will likely be resolved with the rebuild of python-numpy.
> 
> vtk6 FTBFS due to missing build dependencies: texlive-math-extra.
> The recent texlive-extra source packages no longer build with binary
> package. Dropping the build dependency was sufficient to build vtk6
> successfully with GDAL 2.2.1. The patch has been submitted in #866723.
> 
> A new revision of qgis has been uploaded to unstable which includes the
> changes from 2.14.16 (currently in NEW) for GDAL 2.2 support, which
> allow the package the build successfully with GDAL 2.2.1 too.
> 
> 
> libgdal-grass doesn't need a binNMU as the 2.2.1 version will be
> uploaded to unstable instead. liblas likewise doesn't need a binNMU,
> the version is experimental will be moved to unstable instead.
> 
> Please also binNMU mapnik in experimental as part of the transition.

Let's wait a bit for this, I want the octave transition to finish
first (and to make sure the python3.6 one won't be a problem). In
the meantime you can get vtk6 fixed and qgis accepted.

Cheers,
Emilio

Bug#867201: postgrey: crashes with "FATAL: Can't call method "network" on an undefined value at /usr/sbin/postgrey line 204."

[Julien Cristau]

Control: severity -1 normal

On Tue, Jul  4, 2017 at 19:27:09 +0200, Julien Cristau wrote:

> Source: postgrey
> Version: 1.36-3
> Severity: grave
> User: debian-ad...@lists.debian.org
> Usertags: needed-by-DSA-Team
> X-Debbugs-Cc: debian-ad...@lists.debian.org
> 
> After upgrading one of our mail relays to stretch, postgrey regularly
> crashes with the error is $subject.
> 
> This might or might not be fixed upstream with
> https://github.com/schweikert/postgrey/commit/95a2cd8f7f132aae8c62e9706dd9459afca84a5c
> which changed the relevant code and among other things added checks for
> NetAddr::IP->new returning undef.
> 
Turns out this was most likely due to the recently-added ipv6 support in
postgrey [0], and our exim config [1] using the ${mask:...} operator,
which would return addresses such as
"2a02.1600......" [2].  NetAddr::IP would then
parse that as an ipv4 address and fail, and postgrey doesn't check for
that condition.

[0] 
https://github.com/schweikert/postgrey/commit/629f636058fd4ca05c275ca0f67d7797595933df
[1] 
https://anonscm.debian.org/git/mirror/dsa-puppet.git/tree/modules/exim/templates/eximconf.erb?id=88abaebd66a09e3ef1114422142732ef7559a5de#n785
[2] 
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-string_expansions.html

Cheers,
Julien

Bug#866769: keepassx fails to clear KDE clipboard history, leaving passwords visible

[Felix Geyer]

Hi,

On 03.07.2017 03:42, Reinhard Tartler wrote:
> Control: tag -1 +help +upstream
> Control: severity -1 important
> 
> Thank you very much for your bug report, Henrik.
> 
> On 07/01/2017 11:22 AM, Henrik Størner wrote:
> 
>>
>> keepassx 2.0.3-1 (in Debian "stretch") fails to clear the clipboard history 
>> after a password has been copied to the clipboard.
>>
>> The keepassx security settings has "Clear clipboard after 10 seconds" 
>> enabled.
>>
>> To reproduce,
>> - select an entry with a stored password in the keepassx database
>> - press ctrl-C to copy the password to the clipboard
>> - after 10 seconds (default setting), the password should disappear from the 
>> clipboard history
>> - click on the clipboard icon in the panel, the password is visible
>>
>> This is using the KDE Desktop installation, and hence the KDE clipboard.
>>
>> The KDE clipboard has a setting to prevent the clipboard from being emptied, 
>> but this setting does not change the behaviour.

KeePassX clears the clipboard by using the Qt QClipboard API.

If another application (KDE Clipboard manager or anything else) resets the 
clipboard again, there
is nothing KeePassX can do to prevent it.

Cheers,
Felix

Bug#867168: Re : Re : Bug#867168: debsecan: Unable to upgrade because of numpy

[Florian Weimer]

* nicolas patrois:

> Le 04/07/2017 21:00:23, Florian Weimer a écrit :
>
>> Can you attach the contents of this file?  This is very odd.
>
> Here it is.
> It’s a symlink to /usr/share/pyshared/io.py.
>> ll /usr/lib/python2.7/dist-packages/io.py
> lrwxrwxrwx 1 root root 25 avril 26  2011 /usr/lib/python2.7/dist-
> packages/io.py -> /usr/share/pyshared/io.py
>> ll /usr/share/pyshared/io.py 
> -rw-r--r-- 1 root root 39506 nov.  27  2007 /usr/share/pyshared/io.py

Is this file installed by a Debian package (dpkg -S
/usr/share/pyshared/io.py)?

I'm really sorry, but this really isn't something that I can fix on
the debsecan side.  It looks like your Python installation is broken.

Bug#867104: wanna-build issue with src:perl versioned Provides

[Niko Tyni]

(dropped some cc's)

On Tue, Jul 04, 2017 at 09:09:37PM +0200, Ralf Treinen wrote:

> thanks for having figured that out. I tend to believe that dose is right
> in this case. Since it is not possible to install at the same
> time two different versions of the same real package, the same should
> IMHO hold when one is real and the other virtual. Why should this be
> possible?

Well, dpkg and apt allow it for starters.

The idea with the perl packages is that the src:perl binary packages
offer an older "stable" version of some modules while a newer version is
packaged separately and gets installed earlier on the Perl search path
(so it overrides the src:perl version when installed.)

This has been the case for ages with the src:perl packages Providing
an unversioned virtual package. The change here is that the virtual
package is now versioned, which would simplify lots of dependencies
that currently read like (for instance)

  perl (>= 5.16.1) | libscalar-list-utils-perl (>= 1:1.24)

-- 
Niko Tyni   nt...@debian.org