Bug#919975: mailman3-web: whoosh python2 and python3 databases are not compatible

[Sampo Sorsa]

Package: mailman3-web
Version: 0+20180916-2~bpo9+1

Dear Maintainer,

After upgrading from earlier python2-based packages, I ran into this problem of 
Whoosh databases between python2 and python3 being incompatible:

$ sudo -u www-data /usr/share/mailman3-web/manage.py update_index_one_list 
exam...@example.com

Indexing XXX emails
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner
self.run()
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 1015, in run
writer.commit(*self.commitargs, **self.commitkwargs)
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 922, in commit
finalsegments = self._merge_segments(mergetype, optimize, merge)
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 827, in 
_merge_segments
return mergetype(self, self.segments)
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 101, in 
MERGE_SMALL
writer.add_reader(reader)
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 710, in 
add_reader
self.add_postings_to_pool(reader, basedoc, docmap)
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 647, in 
add_postings_to_pool
for item in items:
  File "/usr/lib/python3/dist-packages/whoosh/writing.py", line 583, in 
_process_posts
for fieldname, text, docnum, weight, vbytes in items:
  File "/usr/lib/python3/dist-packages/whoosh/reading.py", line 426, in 
iter_postings
m = self.postings(fieldname, btext)
  File "/usr/lib/python3/dist-packages/whoosh/reading.py", line 820, in postings
matcher = FilterMatcher(matcher, deleted, exclude=True)
  File "/usr/lib/python3/dist-packages/whoosh/matching/wrappers.py", line 277, 
in __init__
self._find_next()
  File "/usr/lib/python3/dist-packages/whoosh/matching/wrappers.py", line 302, 
in _find_next
while child.is_active() and child.id() in ids:
  File "/usr/lib/python3/dist-packages/whoosh/codec/whoosh3.py", line 970, in id
self._read_ids()
  File "/usr/lib/python3/dist-packages/whoosh/codec/whoosh3.py", line 1072, in 
_read_ids
self._read_data()
  File "/usr/lib/python3/dist-packages/whoosh/codec/whoosh3.py", line 1067, in 
_read_data
self._data = loads(b)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 4: ordinal 
not in range(128)

The solution is to remove /var/lib/mailman3/web/fulltext_index/ and run:

$ sudo -u www-data /usr/share/mailman3-web/manage.py rebuild_index

This is mostly FYI for other stretch-backports users. As mailman3-web is not in 
stretch, it's probably not worth it to bother handling this when upgrading 
packages.

--
Sampo Sorsa

Bug#910295: dput: FTBFS: tests fail to mock HTTP request

[Thomas Goirand]

On 1/19/19 4:35 AM, Ben Finney wrote:
> [patch]

Hi Ben!

Thanks a lot for your pull request, I did merge it, however, now the
package fails to build, with an error in the test you've added, as per
below. Could you look into it once more?

Cheers,

Thomas Goirand (zigo)


HTTPretty.match_http_address should ignore case of hostname. ... FAILED
[...]

-
1) FAIL: HTTPretty.match_http_address should ignore case of hostname.

   Traceback (most recent call last):
/usr/lib/python2.7/dist-packages/nose/case.py line 197 in runTest
  self.test(*self.arg)
tests/unit/test_httpretty.py line 451 in
test_match_http_address_should_ignore_hostname_case
  assert HTTPretty.match_http_address(match_hostname, 80)
   AssertionError:


-
52 tests run in 0.2 seconds.
1 FAILED (51 tests passed)

Bug#919976: ibus-keyman: fails to install: ibus-keyman.postinst: ps: not found

[Andreas Beckmann]

Package: ibus-keyman
Version: 11.0.103-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Selecting previously unselected package ibus-keyman.
  (Reading database ... 
(Reading database ... 19508 files and directories currently installed.)
  Preparing to unpack .../ibus-keyman_11.0.103-1_i386.deb ...
  Unpacking ibus-keyman (11.0.103-1) ...
  Setting up ibus-keyman (11.0.103-1) ...
  /var/lib/dpkg/info/ibus-keyman.postinst: 1: 
/var/lib/dpkg/info/ibus-keyman.postinst: ps: not found
  dpkg: error processing package ibus-keyman (--configure):
   installed ibus-keyman package post-installation script subprocess returned 
error exit status 127
  Errors were encountered while processing:
   ibus-keyman


cheers,

Andreas


ibus-keyman_11.0.103-1.log.gz
Description: application/gzip

Bug#919677: [git-buildpackage/master] docs: update examples for pristine-tar usage, requiring commit action

[Michael Prokop]

tag 919677 pending
thanks

Date:   Fri Jan 18 15:28:00 2019 +0100
Author: Michael Prokop 
Commit ID: 414292838ac45665e36455a57ff034fddf5a3b7a
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//commit/?id=414292838ac45665e36455a57ff034fddf5a3b7a
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage//patch/?id=414292838ac45665e36455a57ff034fddf5a3b7a

docs: update examples for pristine-tar usage, requiring commit action

Closes: #919677

  

Bug#919824: [Pkg-opencl-devel] Bug#919824: clblas: under pocl-opencl-icd, aborts with !"PIC Level"

[Andreas Beckmann]

please try pocl from experimental which is built against llvm-7

Andreas

Bug#919977: security-tracker: https://security-tracker.debian.org/tracker/data/json returns stale data

[Philipp Hahn]

Package: security-tracker
Severity: important

Dear Maintainer,

the JSON stream of the Debian Security Bug Tracker seems to report stale
data since the beginning of January 2019:

$ curl -I https://security-tracker.debian.org/tracker/data/json
HTTP/2 200
date: Mon, 21 Jan 2019 08:10:06 GMT
...
content-length: 19836218
last-modified: Wed, 02 Jan 2019 19:49:17 GMT
expires: Wed, 02 Jan 2019 20:57:34 GMT

This breaks our process to monitor the Debian Security updates by
processing the DSAs in a machine-readable format.

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

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

Bug#919951: ocaml builder must not be called `dune' or provide /usr/bin/dune

[Philip Hands]

Ian Jackson  writes:

...
>
>  * Declare that no-one is allowed the binary package name
>/usr/bin/dune other than the C++ library dune-common
 ^
I suspect you meant 'dune' there.

BTW I agree (having followed the thread) that the consensus on
debian-devel was that the choice of name was pretty foolish.
Foolishness made less forgivable by the fact that the name change was
prompted by a previous clash, and the new name was very obviously also
going to clash with several easily discoverable software projects.

My opinion is that if any package gets to use /usr/bin/dune, it should
be one of the other ones: As you suggest, most probably the C++ library.
The same goes for the package name.

Stéphane,

  That being the case, I would encourage you to come up with a better
  justification than what I've seen so far[1].  The sooner you do this,
  the more likely is is to have an influence on the outcome.

BTW This is just my opinion, and I'm not trying to swing the view of the
rest of the TC by stating it.  However, I suspect that I'm not alone in
thinking this, so it seems OK to say so early rather than to insist on
trudging through the more usual processes and waste a lot of time.

Cheers, Phil.

[1] It seems the Upstream didn't like the idea of another name change.
Other than that I've not noticed a particular reason for the choice
of name beyond the association between camels and dunes, which seems
pretty weak to me.  Feel free to point out if this is wrong.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#919356: dwarves-dfsg: Copyright/licensing is unclear

[Domenico Andreoli]

Hallo d-l,

  the situation of dwarves-dfsg improved a lot over the weekend, the
only knot left is now the license of hash.h

This file is also present in the kernel [0] with an updated copyright
but still without license.

I received a private email from somebody in the kernel community who
already tried to contact Nadia in the past but did not get any reply.

I need advice on how to handle the package, it is all GPL 2.0 with just
this exception.

I think that pushing it to non-free is formally the right thing but I
actually feel it's not the right thing.

Regards,
Domenico

[0] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/hash.h

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13


signature.asc
Description: PGP signature

Bug#910987: Bug#917025: tracker.debian.org: 0 new commits since last upload

[Christoph Berg]

Control: reassign -1 tracker.debian.org

Re: Mattia Rizzolo 2018-12-21 <20181221211515.gn19...@mapreri.org>
> > Not sure if this is a duplicate of #910987, but I see the problem.
> 
> Not quite.  However, it's not a problem coming from tracker, rather by
> the data source it uses.

It's somewhat related because in both bugs, the wording used by the
tracker is the problem. In #910987, the information is technically
correct, but the wording is a little bit too aggressive in suggesting
that A Upload Is Needed Now.

> > -->8--
> >  action needed
> >  0 new commits since last upload, time to upload? normal
> >  vcswatch reports that this package seems to have a new changelog entry
> >  (version 1:5.25.2-2, distribution unstable) and new commits in its VCS.
> >  You should consider whether it's time to make an upload.
> > 
> >  Here are the relevant commit messages:
> > 
> >  None
> > 
> >  Created: 2018-12-21 Last update: 2018-12-21 15:05
> > -->8---
> > 
> > Latest commit is 727f110b (tagged then, after several minutes,
> > everything was pushed to the public repo _before_ upload to
> > the debian archive was done).

The problem here is that the tracker is interpreting the information
from vcswatch wrongly. The "commits since last tag" information should
only be used when the status is "COMMITS". And even when done
correctly, it should rather be saying "eventually this package should
be uploaded", and not "time to upload?" which seems to suggest that
this should happen "now".

Christoph

Bug#913346: libsane1: Cannot update libsane1

[Gianfranco Costamagna]

 Hello,


>If someone is using unstable, I expect them to be able to resolve
>such issues themselves. unstable isn't a release, it's a development
>version of Debian.

ehm, this bug hit testing too :/
>I don't understand why some users install unstable without understanding>the 
>ramifications of using a development version of Debian.

I honestly never cared about unstable or even experimental, but testing is 
somethingwe should consider with our upgrade paths...
Anyway, revised debdiff attached :)
G.
  

diff
Description: Binary data

Bug#919957: Please check for binaries depending on unused libraries

[Josh Triplett]

On Mon, 21 Jan 2019 08:39:27 +0200 Adrian Bunk  wrote:
> On Sun, Jan 20, 2019 at 03:45:35PM -0800, Josh Triplett wrote:
> > I'd love to see lintian catch issues like this:
> > 
> > $ ldd -u /sbin/badblocks
> > Unused direct dependencies:
> > /lib/x86_64-linux-gnu/libblkid.so.1
> > 
> > Lintian already parses binaries and libraries with objdump, so catching
> > this seems reasonable.
> 
> This does not sound like a good idea to me, since fixing such warnings 
> would result in many ugly (and sometimes not upstreamable) hacks.

In most cases, fixing such warnings would involve either adding
--as-needed or just removing a library from linking for a given program.

- Josh

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Andreas Beckmann]

Package: lintian
Severity: normal

libpython3.7-dev ships /usr/include/python3.7 -> python3.7m

Packages should not install and ship headers in /usr/include/python3.7/
but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
otherwise they will trigger piuparts installs_over_symlink_error.

currently violated by

python-greenlet-dev: /usr/include/python3.7/greenlet/greenlet.h
python3-bsddb3: /usr/include/python3.7/bsddb3/bsddb.h
python3-persistent: /usr/include/python3.7/persistent/cPersistence.h
python3-persistent: /usr/include/python3.7/persistent/ring.h
python3-pygame: /usr/include/python3.7/pygame/_camera.h
python3-pygame: /usr/include/python3.7/pygame/_pygame.h
python3-pygame: /usr/include/python3.7/pygame/_surface.h
python3-pygame: /usr/include/python3.7/pygame/bitmask.h
python3-pygame: /usr/include/python3.7/pygame/camera.h
python3-pygame: /usr/include/python3.7/pygame/fastevents.h
python3-pygame: /usr/include/python3.7/pygame/font.h
python3-pygame: /usr/include/python3.7/pygame/freetype.h
python3-pygame: /usr/include/python3.7/pygame/mask.h
python3-pygame: /usr/include/python3.7/pygame/mixer.h
python3-pygame: /usr/include/python3.7/pygame/pgarrinter.h
python3-pygame: /usr/include/python3.7/pygame/pgbufferproxy.h
python3-pygame: /usr/include/python3.7/pygame/pgcompat.h
python3-pygame: /usr/include/python3.7/pygame/pgopengl.h
python3-pygame: /usr/include/python3.7/pygame/pygame.h
python3-pygame: /usr/include/python3.7/pygame/scrap.h
python3-pygame: /usr/include/python3.7/pygame/surface.h
python3-zope.proxy: /usr/include/python3.7/zope.proxy/proxy.h

python-greenlet-dev: /usr/include/python3.6/greenlet/greenlet.h
python3-bsddb3: /usr/include/python3.6/bsddb3/bsddb.h
python3-igraph: /usr/include/python3.6/python-igraph/igraphmodule_api.h
python3-persistent: /usr/include/python3.6/persistent/cPersistence.h
python3-persistent: /usr/include/python3.6/persistent/ring.h
python3-pygame: /usr/include/python3.6/pygame/_camera.h
python3-pygame: /usr/include/python3.6/pygame/_pygame.h
python3-pygame: /usr/include/python3.6/pygame/_surface.h
python3-pygame: /usr/include/python3.6/pygame/bitmask.h
python3-pygame: /usr/include/python3.6/pygame/camera.h
python3-pygame: /usr/include/python3.6/pygame/fastevents.h
python3-pygame: /usr/include/python3.6/pygame/font.h
python3-pygame: /usr/include/python3.6/pygame/freetype.h
python3-pygame: /usr/include/python3.6/pygame/mask.h
python3-pygame: /usr/include/python3.6/pygame/mixer.h
python3-pygame: /usr/include/python3.6/pygame/pgarrinter.h
python3-pygame: /usr/include/python3.6/pygame/pgbufferproxy.h
python3-pygame: /usr/include/python3.6/pygame/pgcompat.h
python3-pygame: /usr/include/python3.6/pygame/pgopengl.h
python3-pygame: /usr/include/python3.6/pygame/pygame.h
python3-pygame: /usr/include/python3.6/pygame/scrap.h
python3-pygame: /usr/include/python3.6/pygame/surface.h
python3-zope.proxy: /usr/include/python3.6/zope.proxy/proxy.h


Andreas

Bug#919980: Ask before upgrading so user doesn't lose data

[積丹尼 Dan Jacobson]

Package: nodm

Got an idea:

As there is a very high chance the user is using nodm at the time he
runs apt-get upgrade etc. thinking ho-hum, just another upgrade of 50 
packages...

and an even higher chance if pidof nodm returns positive,

and a good chance that he was browsing something important, and editing
several files,

so instead of making it like the power went out and restarted,

why not have the update script,

kindly ask the user "Ready to update nodm? First close all your
windows" via dialog(1) etc.

Bug#913346: libsane1: Cannot update libsane1

[John Paul Adrian Glaubitz]

On 1/21/19 9:52 AM, Gianfranco Costamagna wrote:
>>If someone is using unstable, I expect them to be able to resolve
>>such issues themselves. unstable isn't a release, it's a development
>>version of Debian.
> 
> ehm, this bug hit testing too :/

No, it didn't. What makes you think so? The version of sane-backends with
the libsane1 package was never migrated to testing, see:

> https://packages.qa.debian.org/s/sane-backends.html

Quoting the testing migration mail:

> FYI: The status of the sane-backends source package
> in Debian's testing distribution has changed.

>  Previous version: 1.0.25-4.1
>  Current version:  1.0.27-3.1

Testing upgraded from 1.0.25-4.1 to 1.0.27-3.1, the rename happened
in 1.0.27-1~experimental1.

>>I don't understand why some users install unstable without understanding
>>the ramifications of using a development version of Debian.
> 
> I honestly never cared about unstable or even experimental, but testing is 
> something
> we should consider with our upgrade paths...

Yes, but testing is not affected. Again, what makes you think so?

If someone pulled the packages from experimental and installed them
into testing, I expect them to know and understand what they were
doing.

It's not Debian's job to support broken local configurations.

> Anyway, revised debdiff attached :)

Please don't. It was never part of testing so there are not kludges
required. And, again, unstable is not guaranteed to be stable, hence
the name.

If someone can point me to the point in the policy where it says that
upgrades and migrations in unstable need to be smooth and without
such issues, I am happy to revise my point of view.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Chris Lamb]

tags 919979 + moreinfo
severity 919979 wishlist
thanks

Hi Andreas,

> Packages should not install and ship headers in /usr/include/python3.7/
> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),

Why? I'll need such an explanation for the long description. :)


Best wishes,

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

Bug#908862: neutron: FTBFS (failing tests)

[Thomas Goirand]

Santiago Vila :
> This is still happening, both in reproducible-builds and also in my
> own autobuilders. The reproducible-builds logs are available here:
>
>
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/neutron.html
>
> and I've just put my build logs here:
>
> https://people.debian.org/~sanvila/build-logs/neutron/

What's weird, is that it's not the same amount of failures.

> (I'm still using eatmydata, since you said you use it yourself and
> it's supposed to work).

Correct.

> Please take a look at this. Just saying "it works for me" does not
> help.

Here, you're recognizing that there's a pattern, and that we've seen
already a few times that, building works for me, but fails in your
environment. So, quite the opposite, the "it works for me" is important,
and needs to be addressed. We need to figure out what is different in
your environment and mine.

To investigate this, I've just tried building in a porter box, which
normally should be very close (if not identical) to what we have in the
buildd network. What I did was really only download the build
dependencies in the schroot, and run dpkg-buildpackage in the schroot:
so nothing special, really. The build was on barriere.debian.org.

The result is that it works perfectly. I do expect to see the same
result if uploading source only.

One thing I've observed, is that most of the times (or every time?), the
test errors we've seen are in SQLite, with a "table doesn't exist"
error. I have no idea (yet) why it's like that.

> While we are at it, I have yet to see how this is not serious,
> being a FTBFS bug in a supported architecture, but I will be happy to
> skip the discussion about the severity as far as you are really
> willing to solve the problem.

An FTBFS which we would observe everywhere, including in porter boxes
(which are normally the same as the buildds), in all configurations
including the most basic one (like mine), would indeed qualify as an RC
bug. Though if there's an FTBFS only in some specific environments,
which we aren't even able to explain, doesn't look like a good candidate
for an RC bug.

> If you still need a machine to reproduce this, please contact me
> privately.

Unfortunately, last time I tried, I could indeed see the FTBFS, but I
wasn't able to understand why it was happening in your build env and not
the standard one (ie: porter box or my own sbuild setup). As you're
actually paying for the VM to be hosted, I don't dare to ask you to
leave it up, and I'm unsure what to do... :/

I'm open to ideas and I am willing to spend the time to understand, if
you have some clues,
Cheers,

Thomas Goirand (zigo)

Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier

[Samuel Thibault]

Hello,

Robert Schindler, le jeu. 17 janv. 2019 07:48:01 +0100, a ecrit:
> Is attached.

Thanks! Just to make sure, is this while Orca is running?

Samuel

Bug#919981: fonts-mathjax: Ugly formulas in jupyter

[Jan Groenewald]

Package: fonts-mathjax
Version: 2.7.4+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,

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

   * Jupyter notebook mathematics formulas are ugly with bad spacing,
   * short integrals and parenthesis, even some missing mathcal
   * characters.

   * Upgrading to fonts-mathjax from buster fixes (well, improves greatly) the 
rendering/display.

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


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

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

fonts-mathjax depends on no packages.

fonts-mathjax recommends no packages.

Versions of packages fonts-mathjax suggests:
ii  libjs-mathjax  2.7.4+dfsg-1

-- no debconf information

Bug#919983: gyoto: autopkgtest failure on i386

[Graham Inggs]

Source: gyoto
Version: 1.3.0-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the upload of 1.3.0-1, gyoto has been failing its autopkgtests on 
i386 [1] with the following error:


Reading parameter file: 
/tmp/autopkgtest.mHCx9P/build.XrZ/src/doc/examples/example-torusjet.xml

 Copyright (c) 2011-2019 Frédéric Vincent, Thibaut Paumard,
 Odele Straub and Frédéric Lamy.
...

j = 18/32
j = 19/32
j = 20/32In gyoto-mpi-worker.C: Error initializing libgyoto: In 
ThermalBrems: alphanu undefined!

--
Child job 2 terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--
--
mpirun.openmpi detected that one or more processes exited with non-zero 
status, thus causing

the job to be terminated. The first process to do so was:

  Process name: [[32154,2],3]
  Exit code:1
--
autopkgtest [16:14:18]: test gyoto-mpi: ---]
gyoto-mpiFAIL non-zero exit status 1


It is not entirely clear that this is a new failure on i386 as previous 
tests always failed.  Test are now successful on amd64 in Debian [2] and 
all other tested architectures in Ubuntu; amd64, arm64, armhf, ppc64el 
and s390x.


Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/gyoto/disco/i386
[2] https://ci.debian.net/packages/g/gyoto/unstable/amd64/

Bug#919954: blockattack: Starting blockattack causes a segfault

[Markus Koschany]

Hello,

Am 20.01.19 um 23:37 schrieb Nikolas Nyby:
> Package: blockattack
> Version: 2.3.0-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> I started blockattack with no options.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Starting blockattack with the --software-renderer option solves this problem.
> 
>* What was the outcome of this action?
> 
> I get this error when starting blockattack like this:
> 
> $ blockattack
> GetFileContent - File does not exists: configFile
> ALSA lib pcm.c:8424:(snd_pcm_recover) underrun occurred
> Segmentation fault
> 
>* What outcome did you expect instead?
> 
> I expected the program to start.

The game works for me but I use an Intel based graphic chip. Since the
--software-renderer option works for you too, it is likely that this is
an issue with your Nouveau drivers. The GetFileContent warnings are
harmless because those files don't exist at first start and are later
stored in ~/.local/share/blockattack.

The only way to debug this issue is to get a backtrace. See
https://wiki.debian.org/HowToGetABacktrace for further information.
Please also attach a kernel log to the bug report.

dmesg > kernel_log.txt

With those information we could reassign the bug report to
xserver-xorg-video-nouveau. However, since Debian already ships the
latest version of nouveau, I suggest to submit this bug report upstream
as well because it is most likely not Debian specific.

https://nouveau.freedesktop.org/wiki/Bugs/

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919835: mgba; AppStream metadata isn't being used because of its license

[Markus Koschany]

Hello Jeremy,

Am 20.01.19 um 02:45 schrieb Jeremy Bicha:
> Source: mgba
> Version: 0.6.3+dfsg1-2
> X-Debbugs-CC: sergio_...@yahoo.com.br
> 
> The AppStream metadata that was added to the Debian package isn't
> being used because its metadata_license isn't on the short list of
> approved licenses.
> 
> I encourage you to consider relicensing your metadata as CC0-1.0. From
> what I can tell, CC0-1.0 is by far the most popular license for
> AppStream metadata.
> 
> The AppStream metadata for libretro-mgba isn't very useful for
> gnome-games-app without the .libretro file. It would be easier for me
> to help with some of these issues if these projects used
> https://salsa.debian.org . Please let me know if you would like my
> help.

[...]

I think the easiest way to solve this issue is to join the games team
and make your changes. That would reduce the differences between the
Debian and Ubuntu package and save time for everyone. I also think that
creating a Git repository on salsa.debian.org is fine and actually
should have been done much earlier.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#919411: orca: CapsLock isn't disabled though being used as Orca modifier

[Robert Schindler]

Hello,

Samuel Thibault wrote:
> Thanks! Just to make sure, is this while Orca is running?

Yes, it is.

Best regards
Robert


signature.asc
Description: PGP signature

Bug#919984: ITP: r-cran-sys -- Powerful and Reliable Tools for Running System Commands in GNU R

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-sys
  Version : 2.1
  Upstream Author : Jeroen Ooms, Gábor Csárdi
* URL : https://cran.r-project.org/package=sys
* License : MIT
  Programming Lang: GNU R
  Description : Powerful and Reliable Tools for Running System Commands in 
GNU R
 Drop-in replacements for the base system2() function with fine control
 and consistent behavior across platforms. Supports clean interruption,
 timeout, background tasks, and streaming STDIN / STDOUT / STDERR over
 binary or text connections. Arguments on Windows automatically get
 encoded and quoted to work on different locales. On Unix platforms the
 package also provides functions for evaluating expressions inside a
 temporary fork. Such evaluations have no side effects on the main R
 process, and support reliable interrupts and timeouts. This provides the
 basis for a sandboxing mechanism.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-sys
This package is needed to upgrade r-cran-openssl to its latest upstream version.

Bug#919417: orca: Orca reads character by character when holding navigation keys pressed

[Robert Schindler]

Hello,

Just want to add that it behaves as intended in Firefox 64.0.2, but not
in gnome-terminal or gedit.

Best regards
Robert


signature.asc
Description: PGP signature

Bug#889582: Update libmtp package in Debian (new upstream releases)

[Dylan Aïssi]

Hi Alessio,

Le lun. 21 janv. 2019 à 02:23, Alessio Treglia  a écrit :
> On Fri, 18 Jan 2019 at 16:39, Dylan Aïssi  wrote:
> > If you don't have time, I can help you to update the package.
>
> Please go ahead.

Thanks :-)

Last questions:
- Should I do a NMU or co-maint is fine for you?
- Since the old git repo is gone with alioth, I have created a new one
with gbp --debsnap [1], is it ok if I move it to the debian group in
salsa (i.e. [2])?

Best,
Dylan

[1] https://salsa.debian.org/daissi/libmtp
[2] https://salsa.debian.org/debian/libmtp

Bug#919985: jupyter-sphinx-theme: ipywidgets depends on python-jupyter-sphinx-theme which was removed

[Tobias Hansen]

Package: src:jupyter-sphinx-theme
Version: 0.0.6+ds1-4
Severity: normal
Tags: sid buster
Control: block 917705 by -1

Hi Jerome,

ipywidgets depends on python-jupyter-sphinx-theme which is no longer built by 
jupyter-sphinx-theme. I haven't checked if ipywidgets could be changed not to 
depend on it, but I wanted to make you aware that we might have to bring back 
python-jupyter-sphinx-theme.

Best,
Tobias

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

tags #919922 confirmed upstream
severity #919922 important
thanks

Hi Sven,

thanks for spotting this. Strangely, this didn't happen on my test
box, but I can confirm this behavior for my workstation.

I am downgrading this to important though, since I consider the
statistics writing an auxillary feature, and I suspect that the issue
will fix itself next midnight.

What do you think, would it be an acceptable workaround to move the
current day file away in postinst and document that fact?

Greetings
Marc


On Sun, Jan 20, 2019 at 07:17:54PM +0100, Sven Hartge wrote:
> From: Sven Hartge 
> Subject: Bug#919922: Does not start anymore, existing file
>  /var/log/atop/atop_20190120 has incompatible header
> To: Debian Bug Tracking System 
> Reply-To: Sven Hartge , 919...@bugs.debian.org
> Date: Sun, 20 Jan 2019 19:17:54 +0100
> X-Mailer: reportbug 7.5.1
> 
> Package: atop
> Version: 2.4.0-1
> Severity: grave
> 
> Hello!
> 
> After the update tpo 2.4.0-1 atop does not start anymore for me.
> TL;DR: 
> 
> existing file /var/log/atop/atop_20190120 has incompatible header
> (created by version 2.3 - current version 2.4)
> 
> Here the whole debugging session:
> 
> server:~# systemctl start atop; systemctl status atop; sleep 2; systemctl 
> status atop
> ● atop.service - Atop advanced performance monitor
>Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: 
> enabled)
>Active: active (running) since Sun 2019-01-20 19:08:50 CET; 11ms ago
>  Docs: man:atop(1)
>  Main PID: 550488 (atop.daily)
> Tasks: 5 (limit: 4691)
>Memory: 1.5M
>CGroup: /system.slice/atop.service
>├─550488 /bin/bash /usr/share/atop/atop.daily
>├─550491 ps -p 547913
>└─550492 grep atop$
> ● atop.service - Atop advanced performance monitor
>Loaded: loaded (/lib/systemd/system/atop.service; enabled; vendor preset: 
> enabled)
>Active: failed (Result: exit-code) since Sun 2019-01-20 19:08:50 CET; 1s 
> ago
>  Docs: man:atop(1)
>   Process: 550488 ExecStart=/usr/share/atop/atop.daily (code=exited, status=7)
>  Main PID: 550488 (code=exited, status=7)
> 
> As one can see, the unit starts /usr/share/atop/atop.daily but no daemon
> remains at the end.
> 
> Even when running the shell script directly, nothing happens:
> 
> server:~# ps auwwwx | grep [a]top; rm /run/atop.pid; bash -x 
> /usr/share/atop/atop.daily; sleep 5; ps auwwwx | grep [a]top
> user  547330  0.2  0.8  51748 33624 pts/2S+   19:06   0:00 
> /usr/bin/python3 /usr/bin/reportbug atop
> user  549910  0.0  0.0   2512   508 pts/2S+   19:07   0:00 sh -c vim 
> -c :6 '/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa'
> user  549911  0.1  0.1  12340  7324 pts/2S+   19:07   0:00 vim -c :6 
> /tmp/user/1000/reportbug-atop-20190120-547330-uof401oa
> + LOGOPTS=-R
> + LOGINTERVAL=600
> + LOGGENERATIONS=28
> + DEFAULTSFILE=/etc/default/atop
> + '[' -e /etc/default/atop ']'
> + . /etc/default/atop
> + case "$LOGGENERATIONS" in
> ++ date +%Y%m%d
> + CURDAY=20190120
> + LOGPATH=/var/log/atop
> + BINPATH=/usr/bin
> + PIDFILE=/run/atop.pid
> + '[' -e /run/atop.pid ']'
> + sleep 3
> + echo 555663
> + exec /usr/bin/atop -R -w /var/log/atop/atop_20190120 600
> + find /var/log/atop -name 'atop_*' -mtime +28 -exec rm '{}' ';'
> user  547330  0.2  0.8  51748 33624 pts/2S+   19:06   0:00 
> /usr/bin/python3 /usr/bin/reportbug atop
> user  549910  0.0  0.0   2512   508 pts/2S+   19:07   0:00 sh -c vim 
> -c :6 '/tmp/user/1000/reportbug-atop-20190120-547330-uof401oa'
> user  549911  0.1  0.1  12340  7324 pts/2S+   19:07   0:00 vim -c :6 
> /tmp/user/1000/reportbug-atop-20190120-547330-uof401oa
> 
> (You can see the open reportbug where I type this in right now.)
> 
> Running atop directly shows the problem:
> 
> server:~# /usr/bin/atop -R -w /var/log/atop/atop_20190120 600
> existing file /var/log/atop/atop_20190120 has incompatible header
> (created by version 2.3 - current version 2.4)
> 
> Deleting all files in /var/log/atop/ makes it work again.
> 
> Side not: the error message does *not* appear in the journal nor the syslog.
> 
> Grüße,
> Sven.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
> 
> Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
> LANGUAGE=de_DE.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages atop depends on:
> ii  libc62.28-5
> ii  libncurses6  6.1+20181013-1
> ii  libtinfo66.1+20181013-1
> ii  lsb-base 10.2018112800
> ii  zlib1g   1:1.2.11.dfsg-1
> 
> Versions of packages atop recommends:
> ii  cron [cron-daemon]  3.0pl1-130
> 
> atop sugg

Bug#919981: Update bug metadata

[Jonathan Carter]

bts notfound 919981 mathjax/2.7.4+dfsg-1 '# fixing version information'
. found 919981 mathjax/2.7.0-2

thanks

This bug affects version 2.7.0 and seems to be fixed in the 2.7.4
version available in testing.

Bug#919986: ITP: r-cran-askpass -- safe password entry for GNU R, Git, and SSH

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-askpass
  Version : 1.1
  Upstream Author : Jeroen Ooms
* URL : https://cran.r-project.org/package=askpass
* License : MIT
  Programming Lang: GNU R
  Description : safe password entry for GNU R, Git, and SSH
 Cross-platform utilities for prompting the user for credentials or a
 passphrase, for example to authenticate with a server or read a protected key.
 Includes native programs for MacOS and Windows, hence no 'tcltk' is required.
 Password entry can be invoked in two different ways: directly from R via the
 askpass() function, or indirectly as password-entry back-end for 'ssh-agent'
 or 'git-credential' via the SSH_ASKPASS and GIT_ASKPASS environment variables.
 Thereby the user can be prompted for credentials or a passphrase if needed
 when R calls out to git or ssh.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-askpass
This package is needed to upgrade r-cran-openssl to its latest upstream version.

Bug#919987: RM: golang-github-nvveen-gotty -- NPOASR; unused; abandoned upstream

[Arnaud Rebillout]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear release team,

I packaged this library as a build dependency of the docker.io package.
It turns out that we don't use it to build docker.io. It has no reverse
dependency as I know of:

  $ reverse-depends -b golang-github-nvveen-gotty-dev
  No reverse dependencies found
  $ reverse-depends golang-github-nvveen-gotty-dev
  No reverse dependencies found

Plus, it's unmaintained upstream for years. So this is just cruft that
should be removed from the archive.

Last detail, it was never in stable anyway.

Thanks,

  Arnaud

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

Kernel: Linux 4.19.0-1-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)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJTBAEBCgA9FiEE0Kl7ndbut+9n4bYs5yXoeRRgAhYFAlxFn4wfHGFybmF1ZC5y
ZWJpbGxvdXRAY29sbGFib3JhLmNvbQAKCRDnJeh5FGACFizAD/4vo7TJuMUZRU1w
JMusR7UAVCUFNy8yG05+SRJVu1ZDULG2A0OdHDeMcxnLrOcReid8ckiqsXouEY6r
drjbEzbeCmfZro7TAo5Ivb7nTQd9k3oBx17BcFiZTln4DT9Z0qTCWSVZ1LkWDx69
AwkV2CgNr1JJ4HJTs9ZufVQ0lrPyN1xPWPUVtNNH5nWAN6wQRZ5QNFQCy0hcKXfg
RvP2foelbcXfwZ3OAJqv3P3oJiSHypR97OS1x5s7zTJEvjuiB1nMUsMu/HzO01jK
rtxhWs2YKAkOREK71BEVfgo+KiQa3NXnP6YBORhR4mBWcGu5rtgZgwLI299cwrKv
b71LC8w1RLYX+K0u/0JjRcTEKMq9sdIjFcrESZ9GwIKMiPO2je8Pd71xUwHlr+x6
/USWoAnzmYRq6JzakXua7jLi0s/1Esdhks1yFuAaI2qOnFl59YkiIB5dO6XlFG3I
F9QI4YxbDtkg0jdYYloY4MwbnMtraKBcnHMO06/VsLuHsBFC0fW0tsRhBed20+R2
IVCq1ZrcACmlp7Gv6UV9J1xFxKkIzCmDb0XrOqqnVfystc04xkN6GHUuDp8xpZwd
3FRxCERLrKJpond94zF9rc7sno8r8FZkn/tSnfEGaJi0k2A5xBn5NKH2Hg88C7aF
9MQvd5kkV+c9j+OyEuv8a5isIAncOA==
=NJ9v
-END PGP SIGNATURE-

Bug#919988: wrong license

[Thorsten Alteholz]

Package: goo
Version: 0.155-16
Severity: serious
thanks

Hi Aaron,

please change the license of src/samurui/treegoo.* from GPL to LGPL in 
your debian/copyright.


Thanks!
  Thorsten

Bug#919906: ITP: pullimap -- Pull mails from an IMAP mailbox and deliver them via SMTP or LMTP

[Peter Pentchev]

On Sun, Jan 20, 2019 at 05:33:02PM +0100, Guilhem Moulin wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Guilhem Moulin 
> 
> * Package name: pullimap
>   Version : 0.4
>   Upstream Author : Guilhem Moulin 
> * URL : https://git.guilhem.org/interimap/about/
> * License : GPL-3+
>   Programming Lang: Perl
>   Description : Pull mails from an IMAP mailbox and deliver them via SMTP 
> or LMTP
> 
> PullIMAP retrieves messages from an IMAP mailbox and deliver them to an
> SMTP or LMTP transmission channel.  It can also remove old messages after
> a configurable retention period.
> 
> A statefile is used to keep track of the mailbox's UIDVALIDITY and UIDNEXT
> values.  While PullIMAP is running, the statefile is also used to keep
> track of UIDs being delivered, which avoids duplicate deliveries if the
> process is interrupted.
> 
> PullIMAP supports the COMPRESS=DEFLATE extension from [RFC4978].  It is
> enabled by default on servers advertising it, in order to reduce network
> traffic.
> 
> See also https://guilhem.org/man/pullimap.1.html .

Hmm, as a Perl programmer, I do understand the spirit of "there's more
than one way to do it", so please do not take this as an objection of
any kind, but still I feel curious: what are pullimap's advantages over
fetchmail?

G'luck,
Peter

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


signature.asc
Description: PGP signature

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Andreas Beckmann]

Control: tag -1 - moreinfo

On 2019-01-21 10:13, Chris Lamb wrote:
>> Packages should not install and ship headers in /usr/include/python3.7/
>> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
> 
> Why? I'll need such an explanation for the long description. :)

Installing files over symlinks may silently overwrite files from other
packages without dpkg noticing. Also depending on the unpacking order
either a symlink or a directory will be created, the latter resulting in
two separate trees in the filesystem which may break stuff (because some
headers cannot be found in /usr/include/python3.7m/).


Andreas

Bug#918247:

[Kyle Robbertze]

I'm going to test this (or get someone else to if I don't hear back from
DSA soon) on a porter box before I upload to unstable



signature.asc
Description: OpenPGP digital signature

Bug#836896: xen-utils-4.6: xenstore-read does not read from daemon

[Thadeu Lima de Souza Cascardo]

On Sun, Jan 20, 2019 at 07:50:50PM +0100, Hans van Kranenburg wrote:
> tags 836896 + moreinfo
> thanks
> 
> Hi,
> 
> This is about the bug report about xenstore that you filed before in the
> Debian bug tracker, against the Xen packages.
> 
> Your bug report was targeted at a Xen package in a Debian distribution
> older than the current stable (Stretch).
> 

Well, to be fair, when the bug was reported, Jessie was the latest
stable release.

> Can you please help us by confirming that any of the following scenarios
> does apply to your situation?
> 
> * I had this problem a long time ago. It was never solved, but I found a
> workaround, which is ...
> * I had this problem a long time ago, and I solved it by not using Xen
> any more, but by doing ...
> * I still experience this problem, and I'm still using Xen
> 3.2/4.1/4.4/etc. I cannot upgrade to Debian Stretch or Buster because ...
> * I had this problem, and since upgrading to Stretch / Buster / ? it
> seems it was solved, and I forgot to report it again. Please close it,
> thanks.
> * Other: ...
> 

I was just trying to reproduce a kernel bug that happened under xen. In
the process, I found issues trying to use it, did some debugging, and
reported as much information as I could.

> Note that even if you found a solution, it's still very useful to report
> it back to our bug tracker. There might be someone else running into the
> same problem, who can be helped with your information.
> 
> Please note that unless there's a response within a month from now, we
> will close the bug report. If you discover this message later, and this
> case is important to you, then you can try unarchiving the bug and
> replying to it, or reach out to the maintainers email list at
> pkg-xen-devel at lists.alioth.debian.org (no subscription required) and
> post a message.

You don't have to wait a month. Just close and archive it already.

I understand how hard it is to maintain a package like xen on Debian,
and why this automatic triage is needed. I appreciate your time
maintaining such an important software under Debian.

Thanks.
Cascardo.

> 
> Thanks,
> Hans van Kranenburg

Bug#919990: stretch-pu: package chkrootkit/0.50-4+b2

[Moritz Schlarb]

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

As reported in #600109, /etc/cron.daily/chkrootkit contains a regular
expression to filter out dhclient3 and dhcpd3 as false positives from the
packet sniffer test. However, the binaries don't exist anymore, they have been
renamed to dhclient and dhcpd respectively.

I propose to backport the fix to this regex from chkrootkit/0.52-2 in Buster.

Debdiff is attached.

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

Kernel: Linux 4.19.0-1-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/dash
diff -Nru chkrootkit-0.50/debian/changelog chkrootkit-0.50/debian/changelog
--- chkrootkit-0.50/debian/changelog2016-12-27 13:14:43.0 +0100
+++ chkrootkit-0.50/debian/changelog2019-01-21 11:45:44.0 +0100
@@ -1,3 +1,14 @@
+chkrootkit (0.50-4+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport fix for regular expression for filtering out dhcpd and dhclient as
+false positives from the packet sniffer test.
+
+  [ Lorenzo "Palinuro" Faletra ]
+  * Update /etc/cron.daily/chkrootkit (Closes: #600109)
+
+ -- Moritz Schlarb   Mon, 21 Jan 2019 11:45:44 +0100
+
 chkrootkit (0.50-4) unstable; urgency=low
 
   * [132754e] Fix windigo false positive (Closes:#796599)
diff -Nru chkrootkit-0.50/debian/cron.daily chkrootkit-0.50/debian/cron.daily
--- chkrootkit-0.50/debian/cron.daily   2016-12-27 13:14:43.0 +0100
+++ chkrootkit-0.50/debian/cron.daily   2019-01-21 11:44:19.0 +0100
@@ -19,7 +19,7 @@
eval $CHKROOTKIT $RUN_DAILY_OPTS > 
$LOG_DIR/log.today.raw 2>&1
# the sed expression replaces the messages 
about /sbin/dhclient3 /usr/sbin/dhcpd3
# with a message that is the same whatever 
order eth0 and eth1 were scanned
-   sed -r -e 's,eth(0|1)(:[0-9])?: PACKET 
SNIFFER\((/sbin/dhclient3|/usr/sbin/dhcpd3)\[[0-9]+\]\),eth\[0|1\]: PACKET 
SNIFFER\([dhclient3|dhcpd3]{PID}\),' \
+   sed -r -e 's,eth(0|1)(:[0-9])?: PACKET 
SNIFFER\((/sbin/dhclient|/usr/sbin/dhcpd)\[[0-9]+\]\),eth\[0|1\]: PACKET 
SNIFFER\([dhclient|dhcpd]{PID}\),' \
-e 's/(! \w+\s+)[ 0-9]{4}[0-9]/\1#/' 
$LOG_DIR/log.today.raw > $LOG_DIR/log.today
 if [ ! -f $LOG_DIR/log.expected ]; then
echo "ERROR: No file 
$LOG_DIR/log.expected"

Bug#919989: Where is upstream

[Geert Stappers]

Package: rust-dhcp4r

Version: 0.1.0-1


Hello,

Where to find upstream of  rust-dhcp4r?


A websearch did yield https://tracker.debian.org/pkg/rust-dhcp4r

and I hoped to be able to click on Homepage, but is it not stated.


Opening
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/dhcp4r/debian

did not reveal an watch file.  The uscan config could have helped me.


The Debian changelog revealed "crates.io", so found
https://crates.io/crates/dhcp4r

That page has two interresting links:

Documentation:  https://docs.rs/dhcp4r/0.1.0/dhcp4r/

Repository: https://github.com/krolaw/dhcp4r


The git repository seems to be the best candidate for a home page link.


Thank you for uploading dhcp4r to Debian.


Cheers

Geert Stappers

DevOps Engineer

Bug#919979: lintian: check for headers in /usr/include/python3.x/ (instead of python3.xm)

[Chris Lamb]

Hi Andreas,

> On 2019-01-21 10:13, Chris Lamb wrote:
> >> Packages should not install and ship headers in /usr/include/python3.7/
> >> but in /usr/include/python3.7m/ (or /usr/include/python3.7dm/),
> > 
> > Why? I'll need such an explanation for the long description. :)
> 
> Installing files over symlinks may silently overwrite files from other
> packages without dpkg noticing. 
[..]

Sorry, I actually meant why /usr/include/python3.x versus
python3.xm. What is the difference between these two directories?


Regards,

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

Bug#919991: clusterssh: sometimes fails to open sessions with "Interrupted system call"

[Moritz Schlarb]

Package: clusterssh
Version: 4.13.2-2
Severity: important

Hi,

ClusterSSH in Buster sometimes fails to open one or more sessions with:

> Cannot open pipe for reading when talking to linux1 : Interrupted system call
> Use of uninitialized value $win in concatenation (.) or string at
/usr/share/perl5/App/ClusterSSH.pm line 639.
> linux1  session closed

I don't know who exactly is the culprit here, maybe Perl, but if someone gave
me some pointers, I'd be happy to investigate.

Regards,
Moritz



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

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

Versions of packages clusterssh depends on:
ii  libexception-class-perl 1.44-1
ii  libtry-tiny-perl0.30-1
ii  libx11-protocol-other-perl  30-1
ii  libx11-protocol-perl0.56-7
ii  openssh-client  1:7.9p1-5
ii  perl5.28.1-3
ii  perl-tk 1:804.033-2+b3
ii  xterm   342-1

clusterssh recommends no packages.

clusterssh suggests no packages.

-- no debconf information

Bug#887399: stretch-pu: package python-certbot/0.10.2-1

[Julien Cristau]

On Thu, Jan 17, 2019 at 01:48:24PM -0800, Brad Warren wrote:
> I just wanted to make sure this was still on everyone’s radar. The
> change server side where tens of thousands of Debian users will begin
> being unable to renew their certificates is in less than a month.
> 
It is, but the initial uploads used the wrong version numbers and had to
be rejected.  AIUI Harlan should be back this week, hopefully he can get
to this.

Cheers,
Julien

> > On Jan 8, 2019, at 4:24 PM, Harlan Lieberman-Berg  
> > wrote:
> > 
> > Hello Julien, everyone,
> > 
> > I've uploaded the relevant packages for your examination.  The
> > packages uploaded are:
> > 
> > - python-acme_0.28.0-1+deb9u1
> > - python-certbot_0.28.0-1+deb9u1
> > - python-certbot-nginx_0.28.0-1+deb9u1
> > - python-certbot-apache_0.28.0-1+deb9u1
> > - python-josepy_1.1.0-2+deb9u1
> > - parsedatetime_2.1-3+deb9u1
> > 
> > On Sun, Dec 2, 2018 at 7:55 PM Harlan Lieberman-Berg
> >  wrote:
> >> 
> >> On Sun, Dec 2, 2018 at 10:48 AM Julien Cristau  wrote:
> >>> OK, let's do that then.  Sorry for not getting back to this sooner.
> >> 
> >> Sounds good.  I'm preparing the uploads now.
> >> 
> >> It looks like I will need to rebuild the version of
> >> python-parsedatetime in stable to also build the python3 version.  I
> >> could also backport a newer version that builds python3.  Let me know.
> >> 
> >> Sincerely,
> >> --
> >> Harlan Lieberman-Berg
> >> ~hlieberman
> > 
> > 
> > 
> > -- 
> > Harlan Lieberman-Berg
> > ~hlieberman
> > 
> > -- 
> > To unsubscribe, send mail to 887399-unsubscr...@bugs.debian.org.
> > 

Bug#918242: Take over lmms maintanenace

[Javier Serrano Polo]

El dg 20 de 01 de 2019 a les 13:20 +0100, Ross Gammon va escriure:
> Would you like me to remove you from the uploaders list?

Do as you wish, I do not have upload permission.

smime.p7s
Description: S/MIME cryptographic signature

Bug#919992: drbl: Remove/replace ash dependency

[Juan Picca]

Package: drbl
Version: 2.20.11-6
Severity: wishlist

Dear Maintainer,

Your package is the only one that use the package ash as dependency.

If you can change it for the package dash, the functionality remain unchanged
and the dash source package can remove the creation of the ash package.

Also, inspecting the files in drbl package, i can't see the usage of ash/dash
shell; the only one used is bash.

Regards,
Juan Picca

Bug#919659: live-build: building in docker fails with mounting /proc unmount /sys [UPDATE]

[Leszek Lesner]

Hi,

after some debugging I found a solution which works fine for me and 
successfully builds 
Images and ISOs in Docker again. 

Commenting out this line in debootstrap makes it work again:
https://sources.debian.org/src/debootstrap/1.0.114/functions/#L1161

So either the issue is in debootstrap or there needs to be a patch in 
live-build to circumvent 
the issue of unmounting the dockers /proc

Input is welcome as I am unsure on how to procede here (e.g. opening up a bug 
in debootstrap 
or leave it here)

Greetings


-- 
ZevenOS / Neptune Team
https://neptuneos.com
Leszek Lesner 

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 11:20:52 +0100, Marc Haber wrote:
> What do you think, would it be an acceptable workaround to move the
> current day file away in postinst and document that fact?

Are the old files still readable by the new atop?

If not, another (better?) possibility is to ask the user if he
wishes to convert these old files to the new format.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919993: RM: python-astropy-helpers -- ROM; Dropping Python 2

[Ole Streicher]

Package: ftp.debian.org

Please remove the "python-astropy-helpers" source package from unstable.

Upstream will stop supporting the Python 2 package by the end of the
year, and so it should not appear in Buster or later. Python 3 support
is provided by the "astropy-helpers" source package.

All reverse (build) dependencies of python-astropy were removed:


$ dak rm -Rn python-astropy-helpers
Will remove the following packages from unstable:

python-astropy-helpers |2.0.7-1 | source, all

Maintainer: Debian Astro Team


--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Bug#919644: Outdated version of debhelper used for building package

[Julian Dammann]

We investigated the problem further:
The systemd-tmpfiles call in the postinstall script is added by dh_installinit 
(debhelper).
debhelper Version 12 (sid) and Version 12~bpo9+1 (stretch-backports) already 
fixed this using basename, as we initially suggested.
However, apparently packages for stretch are not built using the debhelper 
suite from backports.

Bug#913820: [Pkg-freeipa-devel] Bug#913820: cockpit-389-ds: Debian-packaged JS libs not sufficient to run cockpit-plugin

[Jan Luca Naumann]

Hey,

the fix of this bug is not complete, the installation of the JS-stuff is
still excluded in debian/rules. Could you please take another look into
the bug?

Best regards,
Jan

On Fri, 16 Nov 2018 11:20:44 +0200 Timo Aaltonen 
wrote:
> On 15.11.2018 18.22, Jan Luca Naumann wrote:
> > Package: cockpit-389-ds
> > Version: 1.4.0.18-1
> > Severity: grave
> > Justification: renders package unusable
> > 
> > At the momenent the package cockpit-389-ds applies a patch to use the Debian
> > packaged JS libraries. In contrast to the vendored libraries the Debian 
> > versions
> > do not work with the current version of the cockpit-389-plugin, c.f. the
> > backtrace attached. Removing the Debian-specific patch and installing the
> > vendored JS libs resolves the issue.
> 
> yeah, and all the minified stuff is already in debian/missing-sources,
> so it should be fine to just drop the patch.. Thanks for the bug!
> 
> 
> -- 
> t
> 
> 

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 12:28:40 +0100, Vincent Lefevre wrote:
> On 2019-01-21 11:20:52 +0100, Marc Haber wrote:
> > What do you think, would it be an acceptable workaround to move the
> > current day file away in postinst and document that fact?
> 
> Are the old files still readable by the new atop?

Since there is a new program atopconvert, I suppose that they are not.

> If not, another (better?) possibility is to ask the user if he
> wishes to convert these old files to the new format.

After thinking more about it, I think that the choice should be given
between:

1. Move the atop_* files under /var/log/atop to /var/log/atop.old
   (to be created if it doesn't exist yet).

2. Convert these files to the new format with atopconvert.

3. Both (just in case there would be a bug in atopconvert).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#915355: RFA: fbless -- terminal fiction book reader

[Davor Balder]

Hello Dmitry, 

I can look after this package for some time, if there are no other takers and 
if that is OK with you. 

I should be able to enlist additional assistance in case of major 
issues/changes.

Kind regards, 

Davor

Bug#919924: mercurial: autopkgtest depends on monotone which is not in testing

[Graham Inggs]

Control: tags -1 + patch

I've checked, and the autopkgtest succeeds when monotone is simply
dropped from the test dependencies, as below:


--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,3 @@
 Tests: testsuite
-Depends: @, zip, unzip, netbase, python-subversion, monotone, cvs, bzr, 
tla, gcc, python2.7-dev, less
+Depends: @, zip, unzip, netbase, python-subversion, cvs, bzr, tla, gcc, 
python2.7-dev, less

 Restrictions: allow-stderr

Bug#919994: deltachat-core has unsatisfied hard-coded dependencies on library packages

[Matthias Klose]

Package: src:deltacheck
Version: 0.39.0-1+ds
Severity: serious
Tags: sid buster

deltachat-core has unsatisfied hard-coded dependencies on library packages.

Package: libdeltachat0
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libsasl2-2, libetpan17,
libssl1.0.2, libsqlite3-0
Description: Delta.Chat shared libraries


excuses:
Migrates after: openssl1.0
Too young, only 0 of 5 days old
libdeltachat0/amd64 unsatisfiable Depends: libetpan17
libdeltachat0/arm64 unsatisfiable Depends: libetpan17
libdeltachat0/i386 unsatisfiable Depends: libetpan17
libdeltachat0/mips unsatisfiable Depends: libetpan17
libdeltachat0/ppc64el unsatisfiable Depends: libetpan17
libdeltachat0/s390x unsatisfiable Depends: libetpan17

Bug#919995: fuse-posixovl: posixovl 1.3 is out !

[Thierry]

Package: fuse-posixovl
Version: 1.2.20120215+gitf5bfe35-1
Severity: important

Dear Maintainer,

i noticed that posixovl 1.3 is out for 4 months ! It would be awesome to have it
in buster.

Ciao,
Thierry


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

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

Versions of packages fuse-posixovl depends on:
ii  libc6 2.24-11+deb9u3
ii  libfuse2  2.9.7-1+deb9u2

fuse-posixovl recommends no packages.

fuse-posixovl suggests no packages.

-- no debconf information

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 11:20, Marc Haber wrote:

> I am downgrading this to important though, since I consider the
> statistics writing an auxillary feature, and I suspect that the issue
> will fix itself next midnight.

But until then, the daemon will be non-functional and since there is no
message *why* this is the case, the user/admin is left in the dark.

> What do you think, would it be an acceptable workaround to move the
> current day file away in postinst and document that fact?

I think you can just delete all old statistics files, since they are
useless with the new atop. sysstat does this all the time (after a
debconf prompt).

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#915689: Bug#919893: package shouldn't exist

[Diederik de Haas]

On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
> I’m very much against just saying this package
> “should not exist”

I'm inclined to agree with this as the source (+ features/parameters) for this 
package is substantially different from rng-tools/rng-tools5.

AFAICT the problem started when rng-tools changed substantially by the upload 
which made it (very) similar to rng-tools5 and I think the last line of the 
long description of rng-tools should've been removed as it only applies to the 
'old' implementation (which is now in rng-tools-debian).

I bumped into the 'conversation' because I noticed a lack of conversation/
coordination/progress. I'm thinking of updating https://github.com/debian-pi/
raspbian-ua-netinst/ to buster level and we use(d) the old rng-tools to get 
much better/more entropy on the Raspberry Pi. (I also want to investigate 
whether it'll help with other small SBCs like Pine A64)
I haven't tried yet whether rng-tools5 will work just as well (raspbian-ua-
netinst doesn't use any cmd-line params)

And I also think that the current situation shouldn't end up in a stable 
release.

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

Bug#900918: debian-installer: Please make the generated images reproducible

[Chris Lamb]

Dear Cyril,

Thank you for your review and timely merge.

> That's looking good but I'm seeing new warnings because of gzip's being
> unhappy about the GZIP environment variable.

Interesting. However when you say "new" warnings I don't believe my
patch set actually added/changed this; indeed, it has not changed
since:

   
https://salsa.debian.org/lamby/debian-installer/commit/28b863340cc5fd73fbaac85a3fb89e72e842b15c

… so I'm just checking what you are requesting to be done here.

§

> All gtk files have fontconfig-related cache/uuid changes…
[…]
> FWIW, dropping all fontconfig-related bits (see attached patch)

This is #864082 in src:fontconfig — I've been playing whack-a-mole
with fontconfig over the past 18 months or so and this was a
fairly recent regression.

Are you planning on applying this patch to debian-installer.git?
Naturally, I would prefer if #864082 was applied and in buster, or
otherwise closed again.

§

> The mini.iso has apparently other changes… I'm attaching the diffoscope
> output. Could this be because of missing tweaks to the xorriso calls in
> build/config/x86.cfg?

Possibly. Let me try and reproduce and reload all of that into my
brain and get back to you on this; IIRC there was some pushback
against making it change behaviour only on SOURFE_DATE_EPOCH being
present so — as you imply — a command-line change might be required.

§

> (Including lintian runtime, using pigz on a 8-way machine cuts real time
> from 8m8s to 4m23s.)

TIL pigz; thanks.

> Checking what happens [it] seems successive builds with pigz lead to the
> same results. But those aren't the same as the results generated with
> gzip. I don't suppose this is going to be a particularly huge problem
> though?

Alas, it is a problem in thatfrom the outside nobody will know
whether one built with pigz or gzip and thus it will be unclear how
to reproduce the bit-for-bit identical binary. In other words, there
is currently no ".buildinfo" equivalent here that specifies "I used
Arch^Wpigz, btw" and got a SHA of $foo.

One easy solution would be if that, if SOURCE_DATE_EPOCH is present,
then we force the use of one tool. Although that would regrettably
mean the lowest common denominator (ie. gzip)  which probably isn't
the ideal due to the aforementioned performance gain for using pigz.
Alternatively, we could make pigz a strict build requirement but
that sounds a little antisocial.

Perhaps we need to record the environment after all; again, I will
reload all of this into my head anyway due to mini.iso (^) so this
will be top-of-stack again.


Regards,

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

Bug#919996: gnat ftbfs on kfreebsd

[Matthias Klose]

Package: src:gcc-9
Version: 9-20190120-1
Priority: important

/<>/build/./gcc/xgcc -B/<>/build/./gcc/
-B/usr/x86_64-kfreebsd-gnu/bin/ -B/usr/x86_64-kfreebsd-gnu/lib/ -isystem
/usr/x86_64-kfreebsd-gnu
/include -isystem /usr/x86_64-kfreebsd-gnu/sys-include -isystem
/<>/build/sys-include   -fchecking=1 -c -g -O2   -W -Wall -gnatpg
-nostdinc  -gnatn  s
-osinte.adb -o s-osinte.o
s-osinte.ads:445:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:446:07: warning: formal parameter "protocol" is not referenced
s-osinte.ads:449:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:450:06: warning: formal parameter "protocol" is not referenced
s-osinte.ads:453:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:454:07: warning: formal parameter "prioceiling" is not referenced
s-osinte.ads:457:07: warning: formal parameter "attr" is not referenced
s-osinte.ads:458:07: warning: formal parameter "prioceiling" is not referenced
../gcc-interface/Makefile:299: recipe for target 's-osinte.o' failed
make[8]: *** [s-osinte.o] Error 1
make[8]: Leaving directory '/<>/build/gcc/ada/rts'
gcc-interface/Makefile:622: recipe for target 'gnatlib' failed
make[7]: *** [gnatlib] Error 2
make[7]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:714: recipe for target 'gnatlib-shared-dual' failed
make[6]: *** [gnatlib-shared-dual] Error 2
make[6]: Leaving directory '/<>/build/gcc/ada'
gcc-interface/Makefile:811: recipe for target 'gnatlib-shared' failed
make[5]: *** [gnatlib-shared] Error 2
make[5]: Leaving directory '/<>/build/gcc/ada'
Makefile:104: recipe for target 'gnatlib-shared' failed
make[4]: *** [gnatlib-shared] Error 2
make[4]: Leaving directory '/<>/build/x86_64-kfreebsd-gnu/libada'
Makefile:20374: recipe for target 'all-target-libada' failed
make[3]: *** [all-target-libada] Error 2

Bug#910295: dput: FTBFS: tests fail to mock HTTP request

[Ben Finney]

On 21-Jan-2019, Thomas Goirand wrote:
> Thanks a lot for your pull request, I did merge it, however, now the
> package fails to build, with an error in the test you've added, as per
> below. Could you look into it once more?

Okay. I failed to properly back-port the patch to version 0.9.5 (the
original which I wrote was for the current upstream version, 0.9.6,
where there are some significant implementation differences).

I've made a new merge request to hopefully do it right for 0.9.5
https://salsa.debian.org/openstack-team/python/python-httpretty/merge_requests/2>.

-- 
 \  “Begin with false premises and you risk reaching false |
  `\   conclusions. Begin with falsified premises and you forfeit your |
_o__)  authority.” —Kathryn Schulz, 2015-10-19 |
Ben Finney 

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 01:15:09PM +0100, Sven Hartge wrote:
> I think you can just delete all old statistics files, since they are
> useless with the new atop. sysstat does this all the time (after a
> debconf prompt).

I'd rather go without debconf and gazillions of translations.

Greetings
Marc

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

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 12:28:40PM +0100, Vincent Lefevre wrote:
> On 2019-01-21 11:20:52 +0100, Marc Haber wrote:
> > What do you think, would it be an acceptable workaround to move the
> > current day file away in postinst and document that fact?
> 
> Are the old files still readable by the new atop?

No :-(

Greetings
Marc

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

Bug#919997: ITP: node-domino -- server-side DOM implementation based on Mozilla's dom.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-domino
  Version : 2.1.1
  Upstream Author : Felix Gnass 
* URL : https://github.com/fgnass/domino
* License : BSD-2-clause
  Programming Lang: JavaScript
  Description : server-side DOM implementation based on Mozilla's dom.js

 Domino provides a fast but insecure DOM in Node.js.
 .
 The Document Object Model (DOM)
 is a cross-platform and language-independent
 application programming interface
 that treats an HTML, XHTML, or XML document as a tree structure
 wherein each node is an object representing a part of the document.
 .
 Node.js is an event-based server-side JavaScript engine.

NB! Felix Gnass is the main _author_ only -
and The Mozilla Foundation is the main copyright holder.

This package will be maintained in the Debian JavaScript team

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxFu8YACgkQLHwxRsGg
ASEGXw//crSWPh5JcG2fA1w7nGOfYO9HQbNvHWN0tjP2gn90/aoJbvGMbMldMRAI
584yZVVx/u8UeV9/YW91JnXG1RSIlpZM4puoT+2nfoosAwSmDt0W4oAPycHAQnTs
zjRJrxtt29iBGbxbeWoaNxbf+lQfjrT0pMV0WemC8z+78Qy9Lb1qqZ322RBLTvLx
SLKFK0NpKQRkkmVvOXqwWUdibCqlUoGKXG5ZxeCccFC8P92k0N++/UqYCWNJ9I2F
wl/kKbHclT0olf/j2TLFFEAbE9evBJRDV1RwxKbN2v0nsKhENuhBnkCpp0uCypSI
O9D/bHWyvBSK71IXv89Nxij/FUKWhykc8Ki/OoUUclEgKthUoFLxnLGTrcloMOiI
Ti/QpjA7fd6419Rb11zvKzu59jW9jw82VETuATY+ITvVlCKZcd8qEF1CDWkw4ntX
4b6cHIEDjJUIfKA5iLRpLuH9v+waE28+RN8Gz3ObYKB/B+IG3UGkxhrzToMsIMIk
znzYQMp/lSQuk+KQgEXCVLFfFON29fbXnNOGFxOl9CmvCTAl8UxbsUXab/OpIcEU
btSNM/uGfkGLsFpySz7rGHgfCL6h4sUcuztv2yyKiPYEEefgYTCNBstRXoJIkfeO
gCoB4omVcy2WkI7esnx6+kqTmFNXW7LTlvvzVp+URaKjGxsUUv4=
=kF9I
-END PGP SIGNATURE-

Bug#915689: Bug#919893: package shouldn't exist

[Michael Stone]

On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:

On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:

I’m very much against just saying this package
“should not exist”


I'm inclined to agree with this as the source (+ features/parameters) for this
package is substantially different from rng-tools/rng-tools5.


Yes, but most of those features are obsolescent at best. I'm not clear 
on what functionality is actually being used. (I'm hesitant to remove 
it exactly because I'm not clear on that, but I tend to think that it's 
functionally obsolete.)



coordination/progress. I'm thinking of updating https://github.com/debian-pi/
raspbian-ua-netinst/ to buster level and we use(d) the old rng-tools to get
much better/more entropy on the Raspberry Pi.


In what way?

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 13:15:09 +0100, Sven Hartge wrote:
> I think you can just delete all old statistics files, since they are
> useless with the new atop. sysstat does this all the time (after a
> debconf prompt).

I disagree. They may still be useful to analyze a past problem,
even with the new atop since they can be converted.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Vincent Lefevre]

On 2019-01-21 12:48:59 +0100, Vincent Lefevre wrote:
> On 2019-01-21 12:28:40 +0100, Vincent Lefevre wrote:
> > If not, another (better?) possibility is to ask the user if he
> > wishes to convert these old files to the new format.
> 
> After thinking more about it, I think that the choice should be given
> between:
> 
> 1. Move the atop_* files under /var/log/atop to /var/log/atop.old
>(to be created if it doesn't exist yet).
> 
> 2. Convert these files to the new format with atopconvert.
> 
> 3. Both (just in case there would be a bug in atopconvert).

If too complex, it should be sufficient to announce what will be
done in NEWS.Debian (with apt-listchanges, the user could do a
backup first, and if he doesn't use apt-listchanges, he probably
doesn't care) and choose one of the solutions (not 3, because it
could use too much disk space). Probably 2, as the user probably
won't downgrade and won't have to remove the old files manually.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#919998: ITP: fonts-b612 -- legible font designed to be used on aircraft cockpit screens

[Gürkan Myczko]

Package: wnpp
Severity: wishlist

* Package name: fonts-b612
  Version : 1.003
  Upstream Authors: 2012 AIRBUS 
2012 Laurent Spaggiari 


* URL : https://github.com/polarsys/b612
* License : OFL 1.1
  Description : legible font designed to be used on aircraft cockpit 
screens
 In 2010, Airbus initiated a research collaboration with ENAC and 
Universite
 de Toulouse III on a prospective study to define and validate an 
Aeronautical
 Font: the challenge was to improve the display of information on the 
cockpit
 screens, in particular in terms of legibility and comfort of reading, 
and to

 optimize the overall homogeneity of the cockpit.
 .
 Two years later, Airbus came to find Intactile DESIGN to work on the 
design
 of the eight typographic variants of the font. This one, baptized B612 
in
 reference to the imaginary asteroid of the aviator SaintExupery, 
benefited

 from a complete hinting on all the characters.
 .
 Main characteristics are:
  - Maximize the distance between the forms of the characters
  - Respect the primitives of the different letters
  - Harmonize the forms and their spacing

Package is availabe at http://phd-sid.ethz.ch/debian/fonts-b612/

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 01:42:38PM +0100, Vincent Lefevre wrote:
> If too complex, it should be sufficient to announce what will be
> done in NEWS.Debian (with apt-listchanges, the user could do a
> backup first, and if he doesn't use apt-listchanges, he probably
> doesn't care) and choose one of the solutions (not 3, because it
> could use too much disk space). Probably 2, as the user probably
> won't downgrade and won't have to remove the old files manually.

atopconvert will also back-convert, if I believe the docs.

Yuck, there is so much to do wrong in that postinst. I already hate it.

Greetings
Marc

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

Bug#919999: Fails to build from source in current stretch

[Moritz Muehlenhoff]

Package: ruby2.3
Version: 2.3.3-1+deb9u4
Severity: important

Hi Ruby maintainers,
I tried to rebuild ruby2.3 2.3.3-1+deb9u4 and it fails with the following four 
test
failures:



  1) Failure:
IMAPTest#test_imaps_with_ca_file 
[/build/ruby2.3-2.3.3/.ext/common/openssl/ssl.rb:404]:
Exception raised:
<#>.

  2) Failure:
IMAPTest#test_starttls [/build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:21]:
exceptions on 1 threads:
#:
/build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:589:in `accept': SSL_accept 
returned=1 errno=0 state=unknown state: sslv3 alert certificate expired 
(OpenSSL::SSL::SSLError)
from /build/ruby2.3-2.3.3/test/net/imap/test_imap.rb:589:in `block in 
starttls_test'

  3) Failure:
TestTimeTZ#test_gen_Asia_Tokyo_50 
[/build/ruby2.3-2.3.3/test/ruby/test_time_tz.rb:265]:
TZ=Asia/Tokyo Time.utc(1951, 9, 8, 14, 0, 0).localtime.
<"1951-09-08 23:00:00 +0900"> expected but was
<"1951-09-09 00:00:00 +1000">.

  4) Failure:
TestTimeTZ#test_gen_Asia_Tokyo_54 
[/build/ruby2.3-2.3.3/test/ruby/test_time_tz.rb:301]:
TZ=Asia/Tokyo Time.local(0, 0, 23, 8, 9, 1951, nil, nil, false, nil).
<"1951-09-08 23:00:00 +0900"> expected but was
<"1951-09-08 23:00:00 +1000">.

15942 tests, 2236735 assertions, 4 failures, 0 errors, 81 skips



Failure 3 and 4 sound like something that might be related to the time test 
failures
which were fixed in deb9u3, maybe a different angle?

Failure 1 and 2 are probably just an expired cert.

We don't currently have any open/pending ruby2.3 security issues, but it would 
be nice
if those could be fixed in either the stretch branch in git or for the next 
point release,
so that this doesn't block a future sec update.

Cheers,
Moritz

Bug#915689: Bug#919893: package shouldn't exist

[Diederik de Haas]

On maandag 21 januari 2019 13:34:19 CET Michael Stone wrote:
> On Mon, Jan 21, 2019 at 01:15:13PM +0100, Diederik de Haas wrote:
> >On zondag 20 januari 2019 16:59:11 CET Thorsten Glaser wrote:
> >> I’m very much against just saying this package
> >> “should not exist”
> >
> >I'm inclined to agree with this as the source (+ features/parameters) for
> >this package is substantially different from rng-tools/rng-tools5.
> 
> Yes, but most of those features are obsolescent at best. I'm not clear
> on what functionality is actually being used. (I'm hesitant to remove
> it exactly because I'm not clear on that, but I tend to think that it's
> functionally obsolete.)

I'm not knowledgeable enough to weigh in on that and/or what is best towards 
the future, so I'll leave that up to you.

> >coordination/progress. I'm thinking of updating
> >https://github.com/debian-pi/ raspbian-ua-netinst/ to buster level and we
> >use(d) the old rng-tools to get much better/more entropy on the Raspberry
> >Pi.
> 
> In what way?

Entropy generation for the creation of SSH keys as the netinstaller is mostly 
used in headless situations.
https://github.com/debian-pi/raspbian-ua-netinst/issues/42

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

Bug#919924: mercurial: autopkgtest depends on monotone which is not in testing

[Graham Inggs]

To be clear, dropping the test dependency on monotone does result in the 
following test being skipped:


test-convert-mtn.t
test-convert-mtn.t ... # Test test-convert-mtn.t
# Running sh "/tmp/hgtests.8zWoOH/child253/test-convert-mtn.t.sh"
skipped missing feature: monotone client (>= 1.0)
# Ret was: 80 (test-convert-mtn.t)

Bug#889582: Update libmtp package in Debian (new upstream releases)

[Alessio Treglia]

On Mon, 21 Jan 2019 at 10:12, Dylan Aïssi  wrote:
> - Should I do a NMU or co-maint is fine for you?

Either way is fine.

> - Since the old git repo is gone with alioth, I have created a new one
> with gbp --debsnap [1], is it ok if I move it to the debian group in
> salsa (i.e. [2])?

I'm ok with that.

Thanks


-- 
Alessio Treglia  | www.alessiotreglia.com
Debian Developer | ales...@debian.org
Ubuntu Core Developer|  quadris...@ubuntu.com
0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A

Bug#919196: Debian bug when running unit tests

[Thomas Goirand]

Hi,

Would you have any idea how to resolve this Debian bug?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919196

I'm not sure, but to me, it looks like the unit tests are running in
loop in the ::handshake() method.

Cheers,

Thomas Goirand (zigo)

Bug#907726: Relevant upstream issue

[Christoph Groth]

Here is the (closed) corresponding upstream issue that explains why
upstream intents to keep the current behavior:
https://github.com/pypa/virtualenv/issues/1279

Bug#919906: ITP: pullimap -- Pull mails from an IMAP mailbox and deliver them via SMTP or LMTP

[Guilhem Moulin]

Hi,

On Mon, 21 Jan 2019 at 12:40:47 +0200, Peter Pentchev wrote:
> Hmm, as a Perl programmer, I do understand the spirit of "there's more
> than one way to do it", so please do not take this as an objection of
> any kind, but still I feel curious: what are pullimap's advantages over
> fetchmail?

I switched from fetchmail to getmail4 some years ago because of
fetchmail's relative complexity, and the lack of client state for IMAP:
only UNSEEN messages from the server are downloaded, which makes it
unreliable if the remote IMAP server is used by another client between
fetchmail calls (it won't retrieve new messages read on the other
client).  getmail and pullimap, on the other hand, retrieve all messages
that have not been retrieved in a previous call.

What made me move away from getmail is the lack of IDLE support: a new
process is spawned, retrieves new messages, and then terminates.  This
adds some overhead (especially on high latency links such as over Tor)
as well as extra latency (when new messages are received one needs to
wait for the next getmail run to retrieve them).  On the other hand,
thanks to its IDLE support, pullimap keep the connection open (one
process per mailbox) and downloads new messages immediately.

My use-case for pullimap & interimap is when messages are retrieved from
one or more third-party IMAP accounts (corporate, etc.), then passed
through a local spam filter, and finally replicated to the other devices
(each of which having its own IMAP server), not necessarily in a star
topology.  Thanks to the long-lived connections, IDLE and friends, when
a message is delivered to my work mailbox, it appears on my laptop and
other devices <2s later (spamassassin being the overhead) and I'm
immediately notified.

Other advantages are COMPRESS=DEFLATE and native SOCKS support.  On the
downside, pullimap supports less protocols (only IMAP4rev1 on the
fetching end, only SMTP or LMTP on the receiving end) and processes a
single mailbox per process (but if multiple mailboxes need to be polled
one can start one process for each).

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#836034: mate-session-manager: don't run dbus-launch if XDG_RUNTIME_DIR/bus is available

[Mike Gabriel]

Hi Simon,

On  Di 29 Nov 2016 10:33:37 CET, Simon McVittie wrote:


On Tue, 29 Nov 2016 at 08:39:27 +, Mike Gabriel wrote:

On  Di 30 Aug 2016 11:52:49 CEST, Simon McVittie wrote:
> For the moment, dbus-user-session does make sure DBUS_SESSION_BUS_ADDRESS
> is set, to be nice to packages that don't have this fallback path.
> However, I'd like to avoid requiring that in future, by adapting
> the dbus-launch code in gnome-session and its forks to look for
> XDG_RUNTIME_DIR/bus before trying dbus-launch.
>
> I'll open an upstream bug for gnome-session after doing this MBF. The same
> patch that is used in gnome-session will probably also apply to
> mate-session-manager - based on a glance at the relevant code path, it
> does not appear to have changed since the fork.

I just looked into this and could neither find a gnome-session upstream bug,
nor a patch in gnome-session that address the above.


Sorry, this got rather lost. I'll try to refresh the patch I upstreamed
soon (it has some known issues due to being older than the dbus-user-session
code paths that actually landed).

Downstream: https://bugs.debian.org/835887

Upstream: https://bugzilla.gnome.org/show_bug.cgi?id=694472

What needs to happen, at a minimum, before the patch on the upstream bug
can land: https://bugzilla.gnome.org/show_bug.cgi?id=694472#c8

Regards,
S


Is the above still a valid issue? After some URL reading, noticed that  
gnome-session upstream does not have your patch, yet. Neither has  
gnome-session in Debian.


Are you still on this? In the GNOME upstream issue, you mentioned some  
more work to be done on your patch. Did you get to that by now?


Please update the status of this bug and close it, if it's not valid anymore.

Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgp8w5FE4bpUt.pgp
Description: Digitale PGP-Signatur

Bug#778664: pam_tty_audit bug how to confirm ?

[secucatcher]

hi
i plan to put auditd on several hundred servers to control.

I saw this bug, but i can't confirmed it on debian jessie or stretch, and i was 
thinking
it didn't exist anymore i discover the same case and behavior on ubuntu 18.40.

So now i'm in doubt :)

Jessie, 8.11 version

libpam-modules:amd64 1.1.8-3.1+deb8u2+b1
debconf  1.5.56+deb8u1 
libaudit1:amd64  1:2.4-1+b1 
libc6:amd64  2.19-18+deb8u10 
libdb5.3:amd64   5.3.28-9+deb8u1 
libpam-modules-bin   1.1.8-3.1+deb8u2+b1
libpam0g:amd64   1.1.8-3.1+deb8u2+b1
libselinux1:amd642.3-2   


Stretch, 9.6 version

libpam-modules:amd64 1.1.8-3.6
debconf  1.5.61 
libaudit1:amd64  1:2.6.7-2 
libc6:amd64  2.24-11+deb9u3
 libdb5.3:amd64   5.3.28-12+deb9u1
libpam-modules-bin   1.1.8-3.6 
libpam0g:amd64   1.1.8-3.6 
libselinux1:amd642.6-3+b3

No problems:

Jessie:
Jan 21 14:38:17  su[10664]: Successful su for root by marc
Jan 21 14:38:17  su[10664]: + /dev/pts/1 marc:root
Jan 21 14:38:17  su[10664]: pam_unix(su:session): session opened for user root 
by marc(uid=1003)
Jan 21 14:38:17  su[10664]: pam_tty_audit(su:session): changed status from 0 to 
1

stretch:

Jan 21 14:41:13  su[11588]: Successful su for root by marc
Jan 21 14:41:13  su[11588]: + /dev/pts/2 marc:root
Jan 21 14:41:13  su[11588]: pam_unix(su:session): session opened for user root 
by marc(uid=1001)
Jan 21 14:41:13  su[11588]: pam_systemd(su:session): Cannot create session: 
Already running in a session
Jan 21 14:41:13  su[11588]: pam_tty_audit(su:session): changed status from 0 to 
1

but ubuntu:
Jan 21 14:32:17  sshd[10975]: pam_tty_audit(sshd:session): error setting 
current audit status: Invalid argument
Jan 21 14:32:18  sshd[10975]: error: PAM: pam_open_session(): Cannot 
make/remove an entry for the specified session


So what environement or package create the bug ?
i don't want to have hundred of servers i can't no longer connect on it.
Best regards
thanks

Bug#919727: cmtk FTBFS in unstable, presumablly due to the new dcmtk

[Andreas Tille]

Control: tags -1 help

Hi,

I can confirm that cmtk[1] really fails to build from source and
most probably this is due to changes in dcmtk.  Any help would be
more than welcome.

Kind regards,

   Andreas.


[1] https://salsa.debian.org/neurodebian-team/cmtk

-- 
http://fam-tille.de

Bug#913346: libsane1: Cannot update libsane1

[Jeremy Bicha]

On Mon, Jan 21, 2019 at 4:08 AM John Paul Adrian Glaubitz
 wrote:
> If someone can point me to the point in the policy where it says that
> upgrades and migrations in unstable need to be smooth and without
> such issues, I am happy to revise my point of view.

Respectfully, Debian Policy doesn't cover every single point. I think
the principle that you should be able to smoothly upgrade unstable is
such an undisputed principle that it hasn't needed to be stated in
Policy yet. piuparts is one tool to monitor that we can install,
uninstall, and upgrade packages smoothly. If a package introduces a
regression caught by piuparts, it is prevented from migrating to
Testing: in other words, it is an RC bug.

We can debate whether this bug is Serious or Important or even
something else, but I don't think it's reasonable to debate whether
there is a bug here or not.

You're welcome to ask the Release Team about this bug. I think they
would support my position.

I apologize that I didn't get around to verifying this bug much sooner
and therefore proposing a fix. This bug is really easy to verify, but
to some extent, the more time that goes by, the more likely that
people running unstable have already manually upgraded this package.

I am attaching an updated patch from Ubuntu. Ubuntu will need to carry
this change until Ubuntu 20.04 LTS is released. Then it can be dropped
from both Debian and Ubuntu.

I think it would be better to just upload this fix now, so we don't
have to worry about getting an exception once we hit the next Buster
Freeze milestone for adding a new binary package.

Thanks,
Jeremy Bicha
From c94e6facab754986546cfeca4af927028d182b95 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 21 Jan 2019 08:49:28 -0500
Subject: [PATCH] Add libsane1 transitional package

LP: #1802586
Closes: #913346
---
 debian/control | 21 +
 1 file changed, 21 insertions(+)

diff --git a/debian/control b/debian/control
index 0056910..5231286 100644
--- a/debian/control
+++ b/debian/control
@@ -125,3 +125,24 @@ Description: API development library for scanners [development files]
  .
  This package contains the files needed to build your applications
  using SANE.
+
+Package: libsane1
+Architecture: any
+Multi-Arch: same
+Section: oldlibs
+Depends:
+ libsane (>= ${source:Version}),
+ ${misc:Depends}
+Description: API library for scanners [transitional package]
+ SANE stands for "Scanner Access Now Easy" and is an application
+ programming interface (API) that provides standardized access to any
+ raster image scanner hardware (flatbed scanner, hand-held scanner,
+ video- and still-cameras, frame-grabbers, etc.). The SANE standard is
+ free and its discussion and development are open to everybody. The
+ current source code is written to support several operating systems,
+ including GNU/Linux, OS/2, Win32 and various Unices and is available
+ under the GNU General Public License (commercial applications and
+ backends are welcome, too, however).
+ .
+ This package is here to ensure smooth upgrades. It can be removed when
+ you see fit.
-- 
2.19.1

Bug#920000: Please build nacl with -fPIC and use CFLAGS from dpkg-buildflags

[Laurent Bigonville]

Source: nacl
Version: 20110221-6
Severity: serious

Hi,

Should't nacl be built with -fPIC?

You also might want to follow the *FLAGS set in the environment during
the build.

On fedora they are doing both:

https://src.fedoraproject.org/cgit/rpms/nacl.git/tree/nacl-20110221-dist-flags.patch
https://src.fedoraproject.org/cgit/rpms/nacl.git/tree/nacl.spec#n56

The fact that it's missing -fPIC seems to cause troubles in libssh
(#919956)

See attached patch

Kind regards,

Laurent Bigonville

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
diff -Nru 
nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch 
nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch
--- nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch   
2018-10-22 08:10:48.0 +0200
+++ nacl-20110221/debian/patches/0002-remove-superfluous-compiler-flags.patch   
2019-01-21 13:14:00.0 +0100
@@ -11,35 +11,32 @@
  okcompilers/cpp | 9 +++--
  2 files changed, 6 insertions(+), 12 deletions(-)
 
-diff --git a/okcompilers/c b/okcompilers/c
-index 7218da3..2667f82 100644
 --- a/okcompilers/c
 +++ b/okcompilers/c
-@@ -1,8 +1,5 @@
+@@ -1,8 +1 @@
 -gcc -m64 -O3 -fomit-frame-pointer -funroll-loops
 -gcc -m64 -O -fomit-frame-pointer
 -gcc -m64 -fomit-frame-pointer
 -gcc -m32 -O3 -fomit-frame-pointer -funroll-loops
 -gcc -m32 -O -fomit-frame-pointer
 -gcc -m32 -fomit-frame-pointer
-+gcc -O3 -fomit-frame-pointer -funroll-loops
-+gcc -O -fomit-frame-pointer
-+gcc -fomit-frame-pointer
- spu-gcc -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
- spu-gcc -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
-diff --git a/okcompilers/cpp b/okcompilers/cpp
-index d1b9ae6..35304e4 100644
+-spu-gcc -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
+-spu-gcc -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
++gcc ${CFLAGS}
 --- a/okcompilers/cpp
 +++ b/okcompilers/cpp
-@@ -1,8 +1,5 @@
+@@ -1,8 +1 @@
 -g++ -m64 -O3 -fomit-frame-pointer -funroll-loops
 -g++ -m64 -O -fomit-frame-pointer
 -g++ -m64 -fomit-frame-pointer
 -g++ -m32 -O3 -fomit-frame-pointer -funroll-loops
 -g++ -m32 -O -fomit-frame-pointer
 -g++ -m32 -fomit-frame-pointer
-+g++ -O3 -fomit-frame-pointer -funroll-loops
-+g++ -O -fomit-frame-pointer
-+g++ -fomit-frame-pointer
- spu-g++ -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
- spu-g++ -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
+-spu-g++ -mstdmain -march=cell -O3 -funroll-loops -fomit-frame-pointer 
-Drandom=rand -Dsrandom=srand
+-spu-g++ -mstdmain -march=cell -O -fomit-frame-pointer -Drandom=rand 
-Dsrandom=srand
++g++ ${CFLAGS}
+--- a/okcompilers/archivers
 b/okcompilers/archivers
+@@ -1,2 +1 @@
+ ar
+-ar -X64
diff -Nru nacl-20110221/debian/rules nacl-20110221/debian/rules
--- nacl-20110221/debian/rules  2018-10-22 08:11:09.0 +0200
+++ nacl-20110221/debian/rules  2019-01-21 13:14:00.0 +0100
@@ -2,6 +2,8 @@
 
 #export DH_VERBOSE=1
 
+CFLAGS = $(shell dpkg-buildflags --get CFLAGS)
+
 override_dh_auto_build:
# some quick tests for the status of /sys to help debug failures
-ls /sys
@@ -13,5 +15,15 @@
# DJB "makefile"-ish
./do
 
+override_dh_auto_configure:
+   [ -f okcompilers/c.orig ] || cp okcompilers/c okcompilers/c.orig
+   [ -f okcompilers/cpp.orig ] || cp okcompilers/cpp okcompilers/cpp.orig
+   sed -i 's|$${CFLAGS}|$(CFLAGS) -fPIC|g' okcompilers/c okcompilers/cpp
+
 %:
dh $@
+
+override_dh_auto_clean:
+   mv -f okcompilers/c.orig okcompilers/c || true
+   mv -f okcompilers/cpp.orig okcompilers/cpp || true
+   dh_auto_clean

Bug#919516:

[Andreas Hasenack]

Upstream fixes, located by juliank:

https://github.com/ruby/ruby/commit/f234e6c3d3170f37508e214cdaef78d4b2584e5a
https://github.com/ruby/ruby/commit/1e0b49a293d3792826c67b7e05c5fcbd09c9ea6e

Bug#919599: Processed: Bug #919599 in python-httpretty marked as pending

[Thomas Goirand]

On 1/21/19 8:57 AM, Debian Bug Tracking System wrote:
> Processing control commands:
> 
>> tag -1 pending
> Bug #919599 [python3-httpretty] python3-httpretty: Fails to match hostname 
> with different case
> Added tag(s) pending.
> 

Hi Ben,

Finally, I had to add a bit more .lower() calls in your patch for it to
pass all unit tests (including the one you added). Maybe you can get the
new patch from the Debian package I uploaded, and forward it upstream?

In any case, thanks for your help here.

Cheers,

Thomas Goirand (zigo)

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 13:27, Marc Haber wrote:
> On Mon, Jan 21, 2019 at 01:15:09PM +0100, Sven Hartge wrote:

>> I think you can just delete all old statistics files, since they are
>> useless with the new atop. sysstat does this all the time (after a
>> debconf prompt).
> 
> I'd rather go without debconf and gazillions of translations.

Easiest solution would be to run the rotate script on upgrades from
<2.4.0 before starting the newly installed version. That way the old
files are still there, if one needs them but the new daemon starts with
a clean slate.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#913346: libsane1: Cannot update libsane1

[Gianfranco Costamagna]

 Hello John,

>No, it didn't. What makes you think so? The version of sane-backends with
>the libsane1 package was never migrated to testing, see:

you are right, I'm not sure why I missed this :)
If you want to cancel or reschedule my delayed upload, feel free to do it,I 
still would like to know the maintainer opinion on this.
Ubuntu can carry a delta for one year, or even forever, this is not the 
pointI'm trying to raise here :)

G.
  

Bug#869698: mate-desktop-environment: Not-remote security: On resume desktop with opened documents is exposed to eavesdropper before unlock prompt appear

[Mike Gabriel]

Control: reassing -1 mate-screensaver

On  Di 25 Jul 2017 20:13:14 CEST, Sergio B. wrote:


Package: mate-desktop-environment
Version: 1.16.0+1
Severity: important

Dear Maintainer,

I do not know what package this issue exactly belongs to and I hope you know
that better and can forward this report if needed.
This issue survives for years, it existed in Debian 8 Mate and now I see it
with Debian 9 Mate again. It exists on two different laptops I use one i386
and
another amd64.

When system resumes from suspend2ram or (especially!) suspend2disk state the
first thing I see in graphics is Mate's desktop with all windows and
documents
were opened before I start suspend. A _moment_ later screen fades to black
or
hides desktop and switches to unlock prompt asking for password.
How long that "moment" is? It depends on speed of system, "weight" of
running
applications, amount of used swap, where (RAM/disk) resuming is being done
from. For fast machine with little load this issue may be invisible or
"almost
invisible" taking a second, for slow single core with swapping it happens
desktop is exposed to eavesdropper for dozens of seconds after resuming from
disk and before it is hidden behind password prompt.

Evil russian hackers have enough time to take photocamera and steal all my
secrets about my interference in Mordor's elections! Help! :)


Most likely an issue in mate-screensaver, so reassigining to that package.

Note, that there have been quite some changes in mate-screensaver  
recently (since MATE 1.20.2). Please re-test with that version (from  
Debian testing).


Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpW3FEEwovKf.pgp
Description: Digitale PGP-Signatur

Bug#862413: mate-desktop-environment: Transfer of email attachment from simplescan to sylpheed fails

[Mike Gabriel]

Control: reassing -1 caja-sendto

On  Fr 12 Mai 2017 15:15:52 CEST, Daniel Auth wrote:


Package: mate-desktop-environment
Version: 1.16.0+1
Severity: normal

Dear Maintainer,

I am running debian-stretch, a fresh install, with mate desktop environment.
I use the programs simplescan for scanning and sylpheed as an email client.

I scan a paper with simplescan. Then, in simplescan menubar, I click on
File -> Email. That opens the preferred emailer application (which  
is sylpheed)

with a compose window. The attachment does not appear in the compose window.

Expected behaviour:
Scanned paper appears as an Attachment in mailer's compose window.

I have tracked down the problem so far:

simplescan creates a temporary file, a pdf that should be the  
attachment  (works)

simplescan calls xdg-email, with a parameter defining the attachment (works)
xdg-email calls gvfs-open mailto
sylpheed's compose window opens but does not show the attachment.

Where the problem does not occur:
simplescan + sylpheed + xfce
simplescan + claws-mail + xfce
simplescan + claws-mail + mate

Best wishes,
Daniel Auth


Duplicate of #827901 in caja-sendto? Probably, so reassigning.

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpUkeUi3LtwF.pgp
Description: Digitale PGP-Signatur

Bug#796946: mate-desktop-environment: MATE knows not how to run a binary file

[Mike Gabriel]

Control: reassing -1 caja

On  Mi 26 Aug 2015 03:25:49 CEST, Richard Jasmin wrote:


Package: mate-desktop-environment
Version: 1.8.0+9
Severity: normal
Tags: upstream

If you make a shell script or text file executable you get a dialog asking if
you want to run or open the file.

But what I dont get is what happens on ELF binaries.MATE just simply wants to
"open with" nothing at all or ask me what to "open with". Im no UI  
expert here

but cant we just shell exec with "exec " like "start "
works on windows?

Why should I have to open a shell to run some Linux native binary app? This
makes no sense to me.

Go browse under /usr/bin in the UI and try this one. :-)


Reassigning this one to caja, MATE's file browser.

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgptoafvOi4ky.pgp
Description: Digitale PGP-Signatur

Bug#914160: qcontrol: Job dev-input-by\x2dpath-platform\x2dgpio_keys\x2devent.device/start failed with result 'timeout'

[Ian Campbell]

On Sun, 2019-01-20 at 22:08 +0100, Bernhard Übelacker wrote:
> Dear Maintainer,
> just a confirmation.
> I tested a new Stretch installation and upgraded to current
> Buster/testing and it went through without any issue.
> 
> Thank you very much.

Awesome, thanks for letting me know!

Ian.

> 

Bug#913346: libsane1: Cannot update libsane1

[John Paul Adrian Glaubitz]

On 1/21/19 2:53 PM, Jeremy Bicha wrote:
> Respectfully, Debian Policy doesn't cover every single point. I think
> the principle that you should be able to smoothly upgrade unstable is
> such an undisputed principle that it hasn't needed to be stated in
> Policy yet. piuparts is one tool to monitor that we can install,
> uninstall, and upgrade packages smoothly. If a package introduces a
> regression caught by piuparts, it is prevented from migrating to
> Testing: in other words, it is an RC bug.

There have been so many cases where upgrades were broken in unstable
and users had to fix them manually. You cannot really expect a development
release to be stable at all times. It's simply not possible to avoid
some breakage from time to time in a target which is currently being
developed.

So far, I also haven't seen many reports on this issue. If this was
really so pressing, I'm sure there would have been more reports
than just this single bug report.

> We can debate whether this bug is Serious or Important or even
> something else, but I don't think it's reasonable to debate whether
> there is a bug here or not.

Well, I have a different opinion on that. I do not consider a temporary
issue in unstable a bug affecting anything but developers.

> You're welcome to ask the Release Team about this bug. I think they
> would support my position.

I'm not sure why you are resorting to the Release Team here? What does the
Release Team have to do with unstable which isn't even a release?

> I apologize that I didn't get around to verifying this bug much sooner
> and therefore proposing a fix. This bug is really easy to verify, but
> to some extent, the more time that goes by, the more likely that
> people running unstable have already manually upgraded this package.

I don't think anyone using unstable is still using the old package
as of now. The libsane1 change has already been reverted and most
unstable users are most certainly dist-upgrading their installations
regularly.

> I am attaching an updated patch from Ubuntu. Ubuntu will need to carry
> this change until Ubuntu 20.04 LTS is released. Then it can be dropped
> from both Debian and Ubuntu.

Why is Ubuntu importing packages with RC bugs open? Shouldn't that
be blocked?

> I think it would be better to just upload this fix now, so we don't
> have to worry about getting an exception once we hit the next Buster
> Freeze milestone for adding a new binary package.

The package in question was never part of testing, so there was never
a concern for Buster. I'm not sure why you are arguing with the Buster
release when this the package version in question was never part of
what is going to be Buster in the first place.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[أحمد المحمودي]

On Sat, Jan 19, 2019 at 01:41:58AM +0100, Adam Borowski wrote:
> On Sat, Jan 19, 2019 at 07:47:51AM +0800, Paul Wise wrote:
> > On Fri, Jan 18, 2019 at 11:51 PM Adam Borowski wrote:
> > The most ideal situation would be to leave it off by default but
> > have a command-line option to turn it on.
---end quoted text---

Elinks is only compiled with javascript, but it is disabled by default. 
ie. the user has to switch it on.

Re-uploaded elinks, with libmozjs60-dev | libmozjs-dev (removed obsolete 
libmozjs185-dev)

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 03:10:28PM +0100, Sven Hartge wrote:
> On 21.01.19 13:27, Marc Haber wrote:
> > On Mon, Jan 21, 2019 at 01:15:09PM +0100, Sven Hartge wrote:
> 
> >> I think you can just delete all old statistics files, since they are
> >> useless with the new atop. sysstat does this all the time (after a
> >> debconf prompt).
> > 
> > I'd rather go without debconf and gazillions of translations.
> 
> Easiest solution would be to run the rotate script on upgrades from
> <2.4.0 before starting the newly installed version. That way the old
> files are still there, if one needs them but the new daemon starts with
> a clean slate.

This is no direct rotate script, atop gets restarted at midnight with -w
"$LOGPATH"/atop_"$CURDAY", so just restarting the script won't work.

Take a look at /usr/share/atop/atop.daily.

Greetings
Marc

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

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Marc Haber]

On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:
> I am downgrading this to important though, since I consider the
> statistics writing an auxillary feature, and I suspect that the issue
> will fix itself next midnight.

Can you check whether:
mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
will allow your atop to run again?

Greetings
Marc

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

Bug#919637: RFS: elinks/0.13~20190114-1 [ITA]

[Adam Borowski]

On Mon, Jan 21, 2019 at 03:26:18PM +0100, أحمد المحمودي wrote:
> Re-uploaded elinks, with libmozjs60-dev | libmozjs-dev (removed obsolete 
> libmozjs185-dev)

Alas, it still FTBFSes:

Working on: /<>/doc/manual.xml
xmlto: /<>/doc/manual.xml does not validate (status 3)
xmlto: Fix document syntax or use --skip-validation option
/<>/doc/manual.xml:3993: element link: validity error : IDREF 
attribute linkend references an unknown ID "CONFIG-SCRIPTING-SPIDERMONKEY"
Document /<>/doc/manual.xml does not validate
make[2]: *** [Makefile:201: manual.html-chunked] Error 13


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#872573: Stopping libvirtd.service does not properly stop all (dnsmasq) processes

[Tomas Janousek]

Hi,

On Mon, Sep 11, 2017 at 08:07:45AM +0200, Guido Günther wrote:
> On Fri, Aug 18, 2017 at 08:47:09PM +0200, Michael Biebl wrote:
> > [...]
> > See, how the dnsmasq processes are still running after stopping the
> > service.
> 
> This is itentional since the networks continue to run. Once you stop the
> network the dnsmasq instance goes away too. Otherwise daemon restarts
> would break VM connectivity.

If the networks continue to run, why are they started again? Is there perhaps
a way to detect that the network is already started and skip starting it
again?

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

Bug#920001: unblock: json-c/0.12.1+ds-2

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: k...@debian.org debian-b...@lists.debian.org

Dear Release Team and d-i Team,

As previously mentioned in [1], I made a new upload (QA upload) for json-c
library to clean up various issues. There's no change to the source code, only
updates in packaging instruction.

This package is currently blocked due to block-udeb request. I'm wondering if
we could unblock it so that the package may migrate into Testing soon (or at
least before full Buster freeze).

The new upload builds successfully on all architectures (except kfreebsd-*,
which is still under Needs-Build condition). There's no new regression
according to autopkgtest results. Piuparts test is also ok.

Regards,
Boyuan Yang

[1] https://lists.debian.org/debian-boot/2019/01/msg00146.html


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

Bug#918776: at-spi2-core: Warning "Couldn't register with accessibility bus:" when starting Emacs and other applications

[Peter Hull]

I can't reproduce this on a fresh install. Unless you know any different
this bug can be closed.

On Fri, 18 Jan 2019 at 13:16 Peter Hull  wrote:

> On Fri, Jan 18, 2019 at 12:25 PM Peter Hull  wrote:
> > I can try and
> > re-create a fresh install if that would help?
> I tried a fresh install (still under VirtualBox) and it didn't have
> this problem. So it may be nothing. I'll check my original one later
> when I get back to that machine.
>

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:31, Marc Haber wrote:
> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:

>> I am downgrading this to important though, since I consider the
>> statistics writing an auxillary feature, and I suspect that the issue
>> will fix itself next midnight.
> 
> Can you check whether:
> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
> will allow your atop to run again?

I don't have the old files any more unfortunately, sorry.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature

Bug#920002: mlton build depends on ruby-albino that was removed from unstable

[Adrian Bunk]

Source: mlton
Version: 20130715-3
Severity: serious
Tags: ftbfs buster sid
Control: close -1 20180207-1

mlton build depends on ruby-albino that was removed from unstable.

This bug is already fixed in the version in unstable.

Bug#908796: udev (with sysvinit) fails to find devices at boot

[Trek]

On Mon, 21 Jan 2019 08:36:51 +0100
Trek  wrote:

> and the one in the attach

missed, sorry
attached to this message--- udev.init.orig	2019-01-12 21:49:44.0 +0100
+++ udev.init	2019-01-21 01:54:51.047997585 +0100
@@ -178,7 +178,7 @@
 fi
 
 log_action_begin_msg "Synthesizing the initial hotplug events (subsystems)"
-if udevadm trigger --type=subsystems --action=add; then
+if udevadm trigger --type=subsystems --action=add --wait-daemon; then
 log_action_end_msg $?
 else
 log_action_end_msg $?

Bug#913346: libsane1: Cannot update libsane1

[Jeremy Bicha]

On Mon, Jan 21, 2019 at 9:23 AM John Paul Adrian Glaubitz
 wrote:
> Well, I have a different opinion on that. I do not consider a temporary
> issue in unstable a bug affecting anything but developers.

3 months isn't temporary. While I think Testing is a better fit for
users than Unstable (maybe we agree there), there are huge numbers of
people and writings that argue that users should use Unstable instead
because "Testing has no security guarantees".

> I'm not sure why you are resorting to the Release Team here? What does the
> Release Team have to do with unstable which isn't even a release?

Because you're "appealing to authority" by asking me to prove that
there is a bug here. I think we all agree that the Debian Release Team
can decide what is an RC bug. But I guess you're going to nitpick and
argue that the Release Team has no authority over Unstable and we
shouldn't even consider their opinion then…

> Why is Ubuntu importing packages with RC bugs open? Shouldn't that
> be blocked?

I did block it: Ubuntu itself never had this bug because it was
blocked in the "devel-proposed" section which even developers aren't
supposed to be using.

Let me be more direct here: I don't understand why you are blocking
this bug fix. You don't even have to do the upload yourself: just
apply the patch that has been given and allow Gianfranco to do the
NMU. How does accepting this bugfix hurt anybody?

Thanks,
Jeremy Bicha

Bug#919966: akregator: symbol lookup error: /usr/lib/x86_64-linux-gnu/libKF5NewStuff.so.5: undefined symbol: _ZN7KNSCore6Engine15signalErrorCodeERKNS_9ErrorCodeERK7QStringRK8QVariant

[Bernhard Übelacker]

Hello Francois Marier,
this looks like a duplicate of bug:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919765

Kind regards,
Bernhard

Bug#919922: Does not start anymore, existing file /var/log/atop/atop_20190120 has incompatible header

[Sven Hartge]

On 21.01.19 15:43, Sven Hartge wrote:
> On 21.01.19 15:31, Marc Haber wrote:
>> On Mon, Jan 21, 2019 at 11:20:52AM +0100, Marc Haber wrote:
> 
>>> I am downgrading this to important though, since I consider the
>>> statistics writing an auxillary feature, and I suspect that the issue
>>> will fix itself next midnight.
>>
>> Can you check whether:
>> mv /var/log/atop/atop_$CURDAY /var/log/atop/atop_oldformat
>> atopconvert /var/log/atop/atop_oldformat /var/log/atop/atop_$CURDAY
>> will allow your atop to run again?
> 
> I don't have the old files any more unfortunately, sorry.

But I can temporarily downgrade to the version from testing and then do
the upgrade again.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#920003: xfce4-pulseaudio-plugin: vlc : cannot control correctly play/pause feature in pulseaudio-plugin 0.4.1-1

[ewan.lbc]

Package: xfce4-pulseaudio-plugin
Version: 0.4.1-1
Severity: normal

Dear Maintainer,

I found this bug in debian testing, but I can reproduce it on debian stretch 
by adding pulseaudio-plugin 0.4.1-1.

Trying to use vlc through the pulseaudio-plugin seems to not work as expected 
(maybe it is a bug related to vlc and not pulseaudio-plugin) : 

1) open a media file from thunar  (sometimes it is happening on 
the second time, so reproduce this step more than one time).
2) click on the vlc pause button in pulseaudio plugin.
3) Try to click on the same button (now play button) to play the media file 
again.

Expected result : The vlc play button is clickable and the video starts again
Actual result : The vlc play button is greyed out and you cannot start the 
video from the  pulseaudio-plugin.


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

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

Versions of packages xfce4-pulseaudio-plugin depends on:
ii  libatk1.0-0  2.22.0-1
ii  libc62.28-5
ii  libcairo-gobject21.14.8-1
ii  libcairo21.14.8-1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libdbus-glib-1-2 0.108-2
ii  libfribidi0  1.0.5-3.1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.58.2-3
ii  libgtk-3-0   3.24.2-3
ii  libkeybinder-3.0-0   0.3.1-1
ii  libnotify4   0.7.7-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpulse-mainloop-glib0  10.0-1+deb9u1
ii  libpulse010.0-1+deb9u1
ii  libxfce4panel-2.0-4  4.12.1-2
ii  libxfce4ui-2-0   4.12.1-2
ii  libxfce4util74.12.1-3
ii  libxfconf-0-24.12.1-1

Versions of packages xfce4-pulseaudio-plugin recommends:
ii  pavucontrol  3.0-3.1
ii  pulseaudio   10.0-1+deb9u1

xfce4-pulseaudio-plugin suggests no packages.

-- no debconf information