Bug#895176: tifffile: please set autopkgtests 'allow-stderr' for big-endian architectures

[Steve Langasek]

Package: tifffile
Version: 20170929-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Dear maintainers,

With tifffile 20170929-1, the autopkgtests have been failing when run on
s390x in Ubuntu:

[...]
autopkgtest [03:01:14]: test python-import:  - - - - - - - - - - results - - - 
- - - - - - -
python-importFAIL stderr: 
/usr/lib/python2.7/dist-packages/tifffile.py:6553: UserWarning: 'module' object 
has no attribute 'unpack_ints'
autopkgtest [03:01:14]: test python-import:  - - - - - - - - - - stderr - - - - 
- - - - - -
/usr/lib/python2.7/dist-packages/tifffile.py:6553: UserWarning: 'module' object 
has no attribute 'unpack_ints'
  Functionality might be degraded or be slow.

  warnings.warn("%s%s" % (e, warn))
[...]

  http://autopkgtest.ubuntu.com/packages/t/tifffile/bionic/s390x

This is because the module tries to replace a python implementation of
unpack_ints() with an optimized C implementation at runtime, but the C
implementation is only defined for little-endian architectures.  Thus the
autopkgtest will currently never pass on big-endian architectures, because
by default a test outputting to stderr is considered a failure.

Under the circumstances, I think it's best to simply allow the test to
output to stderr, therefore I've uploaded the attached patch to Ubuntu to
fix this failure there.  Please consider including it in Debian as well.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru tifffile-20170929/debian/tests/control 
tifffile-20170929/debian/tests/control
--- tifffile-20170929/debian/tests/control  2018-02-05 05:02:32.0 
-0800
+++ tifffile-20170929/debian/tests/control  2018-04-07 23:46:53.0 
-0700
@@ -1,2 +1,3 @@
 Tests: python-import
 Depends: @, python, imagemagick
+Restrictions: allow-stderr

Bug#895175: lintian: Argument "Users" isn't numeric in int at ...

[Niels Thykier]

Package: lintian
Version: 2.5.80
Severity: normal

Observed on lindsay.d.o:

"""
N: Processing source package guzzle-sphinx-theme (version 0.7.11-3, arch 
source) ...
C: guzzle-sphinx-theme source (0.7.11-3) [source]: 
rules-requires-root-implicitly
P: guzzle-sphinx-theme source (0.7.11-3) [source]: 
insane-line-length-in-source-file 
guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.js line length is 32090 
cha
racters (>512)
P: guzzle-sphinx-theme source (0.7.11-3) [source]: 
source-contains-prebuilt-javascript-object 
guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.js line length is 
32087 characters (>512)
N: lintian fails to get the hint from debian/missing-sources
O: guzzle-sphinx-theme source (0.7.11-3) [source]: source-is-missing 
guzzle_sphinx_theme/guzzle_sphinx_theme/static/jquery.js line length is 32087 
characters (>512)
P: guzzle-sphinx-theme source (0.7.11-3) [source]: 
source-contains-prebuilt-javascript-object 
guzzle_sphinx_theme/guzzle_sphinx_theme/static/js/bootstrap.min.js
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 1.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 2.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 3.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 4.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 5.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 6.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 7.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 8.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 9.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 10.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 11.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 12.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 13.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 14.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 15.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 16.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 17.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 18.
Argument "Users" isn't numeric in int at 
/srv/lintian.debian.org/lintian/lib/Lintian/Collect/Package.pm line 448, 
<$_[...]> line 19.
[...]
"""
Thanks,
~Niels

Bug#895174: glib2.0 FTBFS: fails to execute ninja

[Helmut Grohne]

Source: glib2.0
Version: 2.56.0-6
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap

glib2.0 FTBFS during dh_auto_clean. Including the full build log:

| dpkg-buildpackage: info: source package glib2.0
| dpkg-buildpackage: info: source version 2.56.0-6
| dpkg-buildpackage: info: source distribution unstable
| dpkg-buildpackage: info: source changed by Simon McVittie 
|  dpkg-source --before-build glib2.0-2.56.0
| dpkg-buildpackage: info: host architecture amd64
|  debian/rules clean
| dh clean --with gnome,python3
|dh_auto_clean
|   LC_ALL=C.UTF-8 ninja clean
| Can't exec "ninja": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 356.
| dh_auto_clean: LC_ALL=C.UTF-8 ninja clean failed to execute: No child 
processes
| dh_auto_clean: LC_ALL=C.UTF-8 ninja clean returned exit code 10
| make: *** [debian/rules:24: clean] Error 2
| dpkg-buildpackage: error: debian/rules clean subprocess returned exit status 2

I guess this is connected to debhelper 11.2 (as the failure surfaced
close to the upload). Since I'm unsure whether this is a debhelper or
glib2.0 problem, I'm filing it with glib2.0 and trust that you know how
to reassign.

Helmut

Bug#826994: [Pkg-zfsonlinux-devel] Bug#826994: Updated Patch for 0.7.6-1

[Aron Xu]

Hi,

This patch modifies upstream source code directly which is undesired.
Would you mind to submit the change upstream?


Regards,
Aron Xu

Bug#890873: lintian: gcc-8-cross-ports makes lintian fork-bomb, consume all memory and fill the disk

[Niels Thykier]

Niels Thykier:
> Chris Lamb:
>> Hi Niels,
>>
> [...]
>>> Thanks, looks good to me with a quick review.
>>
>> I'll give it a whirl!
>>  
>>
>> Best wishes,
>>
> 
> Looking forward to seeing updated results on lintian.debian.org. :)
> 
> Thanks,
> ~Niels
> 

Hi,

I had a look in the logs and it is not clear to me that the blacklist is
working.  Looking for gcc-8-cross-ports I get the following:

> $ grep  gcc-8-cross-ports /srv/lintian.debian.org/logs/sync_state.log*
> /srv/lintian.debian.org/logs/sync_state.log.0:gcc-8-cross-ports/6 is 
> out-of-date: New group (triggered by 
> binary:cpp-8-alpha-linux-gnu/8-20180402-1cross2/i386)
> /srv/lintian.debian.org/logs/sync_state.log.0:Group gcc-8-cross-ports/2 
> dropped: It is not an active group

Looking for "blacklisted" (which should appear in the log if something
is blacked listed), I get nothing:

> $ grep -r blacklisted /srv/lintian.debian.org/logs
> $

I would have expected to at least see:

> Ignoring blacklisted package src:gcc-8-cross-ports

Thanks,
~Niels

Bug#894214: python-debian: Build API documentation

[Stuart Prescott]

Hi again,

> I've experimented with each of these and created the following
> work-in-progress branch to to see what is possible:
> 
> https://salsa.debian.org/python-debian-team/python-debian/merge_requests/3
> 
> and the genearted documentation can be found at
> 
> https://stuart.pages.debian.net/python-debian/

In the absence of objections or other feedback, I'll merge this branch next 
weekend.

> The docstrings aren't great in a lot of places which limits the use of the
> API docs without looking at the code too, but we can aim for continuous
> improvement in that regard. 

I've done some work in folding separated documentation into the code so that 
the docstrings and the genereated docs are more useful.


> The autodoc API documentation needs to learn not
> to pick up some private members that are uninteresting while we need to
> keep others present since they are base classes and the only documentation
> for some subclasses is within those base classes. The input of those with
> more sphinx experience would be great about now!

This problem remains -- some "_hiddden" classes and functions need to be 
included in the API docs to be meaningful at all while others are most 
unwelcome.

Help needed!

> Is it worth putting these files into a new python-debian-doc binary package?

My feeling is that if the apidocs are useful enough to put on a website, they 
are useful enough to put in a package.

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#895008: kicad: can't start pcbnew

[Carsten Schoenert]

Hello Aurelien,

On Sat, Apr 07, 2018 at 11:37:25PM +0200, Aurelien Jacobs wrote:
... 
> I've tested this new build, and I can now start pcbnew including with
> latest version python-wxgtk3.0, so this seems to fix the issue. Thanks !

excellent, thanks for testing, I also experienced no segfaulting issues
any more while starting.

> Now this has uncovered another GTK+3 related issue for me in pcbnew.
> If I enable "Modern Toolset (Accelerated)" in the Preferences menu,
> pcbnew segfaults. It looks like it might be related to using
> wxGLCanvasX11 (ie. calling libGLX and libX11) even though this GTK+3
> build is now using Wayland instead of X11.

Hmm, I've no deeper knowledge about the internals of wayland vs. X11 so
I probably can't help much here.
It's known that pcbnew will crash under Wayland and the Modern Toolset
in some cases. Please note the information on

http://kicad-pcb.org/help/known-system-related-issues/#_wayland

As you got a informative backtrace it mayed be a good idea to add this
to the bug report mentioned on the above linked section. As this is now
a different problem to the original bug report here I'd like close this
report by a upload of this rebuilded version of src:kicad and create
later a new report with the backtrace information from you.

If you could spend some time to dig into this new issue under wayland
I'd really appreciate this!

Back to the origin of this report.
Upstream is planning to release a RC2 of KiCad 5 with a string freeze.
The feature freeze was done with RC1 so only bugfixing will be done on
KiCad. I plan to upload these RC2 related version to unstable to get a
broader base for testing. 
I don't have plans to upload a rebuild for KiCad 4.0.7 in unstable.

Regards
Carsten

Bug#894526: Taking over scikit-learn into Debian Science team maintenance

[Andreas Tille]

Hi Yaroslav and Michael,

as I did in the past with other scientific packages I would like to take
over scikit-learn into Debian Science team maintenance to fix bug
#894526.  As I understood you in those cases you are OK with this as
long as backportability is given.

Please let me know until tomorrow if you do not like it.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#895173: ITP:

[Yanhao Mo]

Package: wnpp
Severity: wishlist
Owner: Yanhao Mo 

* Package name: golang-github-howeyc-fsnotify
  Version : 0.9.0
  Upstream Author : Chris Howey 
* URL : https://github.com/howeyc/fsnotify
* License : BSD-3-Clause
  Programming Lang: golang
  Description : File system notifications for Go

File system notifications library for golang, This is one dependency of
DDE(Deepin Desktop Environment).

Bug#892802: transition: efl

[Andreas Metzler]

On 2018-03-13 Ross Vandegrift  wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition

> Hello,

> I'd like to request a transition for efl from experimental -> unstable.  This
> release takes over a few other source packages.  It also reverses some
> Debian-local ABI & soname deviations from the upstream releases.
[...]

Hello,

it looks like the transition needs some brute force/hint. Both efl and
e17 are valid candidates, but do not propagate. Good somebody please
take a look?

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

Bug#895160: No -c examples, etc.

[Drew Parsons]

On Sun, 2018-04-08 at 06:38 +0800, 積丹尼 Dan Jacobson wrote:
> Package: tzwatch
> 
> > SYNOPSIS
> >   tzwatch [options]
> 
> Maybe say
> 
>tzwatch [-c ...] [-f FORMAT]

Can do.


> > OPTIONS
> >   -c Configure time zones (add or remove).
> 
> *How?* *What?* Give examples!

I'm confused about what you are asking here.  Did you try "tzwatch -c"?
 It seems self-explanatory to me.  Can you explain what is not clear
about it?

Drew

Bug#895171: Acknowledgement (enlightenment: No thunderbird icon with scale 1.4 1.45 1.5)

[sergio]

Same for pavucontrol.


--
sergio.

Bug#895171: Acknowledgement (enlightenment: No thunderbird icon with scale 1.4 1.45 1.5)

[sergio]

Same for pavucontrol.


-- 
sergio

Bug#886082: foxtrotgps: raising severity of gconf dependency bug

[Joshua Judson Rosen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 04/03/2018 02:58 AM, Paul Wise wrote:
> On Sun, 25 Mar 2018 17:24:57 -0400 Jeremy Bicha wrote:
> 
>> I am now raising the severity of this bug.
> 
> I've pinged upstream about creating a new release.

New 1.2.1 release has just landed on , including 
Paul's changes.
-BEGIN PGP SIGNATURE-

iQJJBAEBCgAzFiEExpO49xgVK00TI5rpiU7zwKLAjYsFAlrJomsVHHJvenppbkBn
ZWVrc3BhY2UuY29tAAoJEIlO88CiwI2LrHEQAKfpqppInyLgMkgW7ALWbKnyhKIK
HJckB0CW4wms113VmcUP70T/Pw0rKdN8CbLu1wUvQNQcdKazY5xvH1B1dU+nauJ4
Hm7C9E7k5J4O3VvapdIsc2+AiSb2uEZPG0SEajSzyYBMZYEo8eyWaX/6EDt1l1OL
JjZsa6MNTfVcUfnyFLy4JALUvVJBAU7YZJZRkGZNfYr77K08IKoR3Jk5l75h92j/
DbIXlgV1peObCoEktxMtIAkY1t/92TTnbQ41b16sBOcAhp9gfUwnuXx0Z4z/igvK
opCB/Ce0669gFD9/7v4H+IIzDJqjss3vyPxTAdAaTsxU/tjf4xQXbtD8+/DfFYiM
awbdE/pQajGaIC7/3/LWyZCfS5XK9y81qq8xQylo94QH/zGlVnLVO2i0da3vkwws
CCseAkLN5KaH/6V8i/Kp5K8fSWGQW5MebxThzx/HnZr8IpegMhOv7XajZzqTY2/Z
+fJGhSZBUum8x9cKFmNx+uZv5BqWS5LLbWwHGO/k/7vF0u0b0gqjNARBAmfJHCzW
zwGkg6xv9gRf47tM5I5N3Uomlw3B0PUVt2y6o/1aLmNMI6rRjwXVT1cPzeSsfs6V
Z6mt1JC3ppuuc1NAVN1rM7BsUtAcYgtBSVzDkrwPNvM8UZ5BeRs+E+oPRdUw08+t
foauF8y6oDXoXl+M
=i/sE
-END PGP SIGNATURE-

Bug#895172: fonts-freefont: Please remove me from Uploaders

[Christian Perrier]

Source: fonts-freefont
Severity: minor

As part of my work in a aligning the many packages I have worked on in
the past.and the few which I am still working on, please remove me
from Uploaderes in this package (and, indeed, all other fonts-*
packages where it currently appears..I'll report bugs for each of
them, but that will take time as I'm doing so manually).


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

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

Bug#895171: enlightenment: No thunderbird icon with scale 1.4 1.45 1.5

[sergio]

Package: enlightenment
Version: 0.22.1-3
Severity: normal

Thunderbird has no icon in the Application (or favorite) menu if Settings -> 
Look -> Scaling is set to 1.4, 1.45 or 1.5 

Bug#895170: desktop-file-utils: won't configure because of XDG_DATA_DIRS

[Francois-Rene Rideau]

Package: desktop-file-utils
Version: 0.23-3
Severity: important

Dear Maintainer,

   * What led up to the situation?
I was installing debian in a chroot.
The installation of desktop-file-utils failed at the configuration step.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
dpkg --configure desktop-file-utils would fail without explaining the
reason, except to say that the configuration script failed.

I ran the /var/lib/dpkg/info/desktop-file-utils.postinst script manually
without the -q option to update-desktop-database and found out that it
was complaining about paths from the environment, then used env | grep
to identify the culprit: the environment variable XDG_DATA_DIRS
had an inappropriate value inherited from outside the chroot.
Note that XDG defines several environment variables, and that
system configuration scripts should ignore all such user variables.


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

Kernel: Linux 4.9.86 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages desktop-file-utils depends on:
ii  libc6 2.27-3
ii  libglib2.0-0  2.56.0-4

desktop-file-utils recommends no packages.

desktop-file-utils suggests no packages.

-- no debconf information

Bug#895147: firefox: Safe Browsing updates fail due to insufficient quota on the Google API key

[Francois Marier]

On 2018-04-08 at 06:38:14, Mike Hommey wrote:
> We're using the same API key as the chromium in Debian, so presumably
> the same problem applies to the chromium package.

Yes, presumably the Chromium package has the same problem. I did a quick
check and none of the test entries from http://testsafebrowsing.appspot.com
work. Chromium doesn't have the same debugging capabilities as Firefox
though, so I don't have as much visibility into what's going on.

>  Why should we need a *different* API key?

By "different", I didn't different from the chromium package. I meant,
another API key. Nobody knows the Project ID for the current API key, so I
can't request a quota increase for it.

Once Debian has an API key with a higher quota, I'd certainly suggest that
the chromium package also switch to it. You're right, there's no need to
have two different keys in Debian.

Francois

-- 
https://fmarier.org/

Bug#895169: nmu: dune-grid-glue_2.6~20171108-1

[Andreas Beckmann]

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

nmu dune-grid-glue_2.6~20171108-1 . ANY . experimental . -m "Rebuild against 
libdune-common-2.6.0"

Dependencies are realized via virtual packages for tracking the abi.


Andreas

Bug#895164: Acknowledgement (linux: Power management support for GPD Pocket UMPC systems)

[Jeremy Stanley]

Proposed https://salsa.debian.org/kernel-team/linux/merge_requests/4
for this.
-- 
Jeremy Stanley

Bug#890501: [pkg-go] Bug#890501: prometheus startup fails due to racey PID file implementation in prometheus

[Martín Ferrari]

fixed 890501 2.2.0+ds-1
thanks

Due to some mistake in my workflow, a couple of changelog entries went
missing in 2.2.0+ds-1, and so this bug was never closed. I added the
entries retrospectively, and closing manually the bug now..

-- 
Martín Ferrari (Tincho)

Bug#895168: boot-info-script: remove unused dependency on asciidoc

[Joseph Herlant]

Package: boot-info-script
Version: 1.5.0-2
Severity: wishlist

Dear Maintainer,

It seems that asciidoc has been forgotten to be removed in
https://salsa.debian.org/debian/boot-info-script/commit/c079e0276ef46516399f211613b1240522a742b8

Patch available here:
https://salsa.debian.org/debian/boot-info-script/merge_requests/1

Note: if you choose to re-add a man page later, please do not use
asciidoc as it is deprecated and only supports python 2. You can use
asciidoctor instead for example.

Thanks
Joseph

Bug#895167: bgpdump: move out of asciidoc

[Joseph Herlant]

Package: bgpdump
Version: 1.5.0-2
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks
Joseph

Bug#895166: ben: move out of asciidoc

[Joseph Herlant]

Package: ben
Version: 0.7.7
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks

Bug#895165: awesome-extra: move out of asciidoc

[Joseph Herlant]

Package: awesome-extra
Version: 2017110501
Severity: wishlist

Dear Maintainer,

Asciidoc is currently facing its end of life and I'm working with the different
packages that depend on it to get its EOL go smooth.

There are several alternatives to asciidoc like asciidoctor for
example (which is the replacement recommended by asciidoc developers).

Could you have your package migrated to an alternative system please?

Note: if you move your package to Salsa I'd be happy to work on a
merge request if it helps.

Thanks
Joseph

Bug#895164: linux: Power management support for GPD Pocket UMPC systems

[Jeremy Stanley]

Package: linux
Version: 4.16~rc5-1~exp2
Severity: wishlist

Power management for GPD Pocket UMPC systems requires kernel driver
modules built by setting CONFIG_PWM_LPSS_PLATFORM,
CONFIG_INTEL_INT0002_VGPIO, CONFIG_INTEL_CHT_INT33FE,
CONFIG_TYPEC_FUSB302, CONFIG_BATTERY_MAX17042 and
CONFIG_CHARGER_BQ24190 along with a variety of related dependencies.
These are all supported in current mainline 4.16 release candidates,
they just need to be enabled.

Bug#895159: # doesn't work

[積丹尼 Dan Jacobson]

OK it turns out # won't comment, but instead just creates a mess.
Therefore please also make it comment.
It is really inconvenient not to have any way to add comments.

Bug#888733: hyantesite FTBFS on most architectures: test failures

[Steve Langasek]

Package: hyantesite
Version: 1.3.0-2
Followup-For: Bug #888733
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

Looking into this build failure (which is also reproducible in Ubuntu), I
see that it's a consequence of the packaging changes in -2 causing the
upstream test suite to be run at build for the first time.

If I run dh_auto_test in the previous version of the package, it fails in
the same way.  Thus this is not a regression in the software on these
architectures, only a regression in buildability because the build now
detects that the package is broken.

Attached is a patch that would allow ignoring the test failures on
architectures other than amd64 and armel in the near term, until they are
fixed upstream.

An alternative solution would be to request removal of the broken binaries
from the archive on other architectures, depending on how serious this
breakage is.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru hyantesite-1.3.0/debian/rules hyantesite-1.3.0/debian/rules
--- hyantesite-1.3.0/debian/rules   2018-01-25 03:49:37.0 -0800
+++ hyantesite-1.3.0/debian/rules   2018-04-07 17:22:25.0 -0700
@@ -3,8 +3,19 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+
+ifeq (,$(filter amd64 armel,$(DEB_HOST_ARCH)))
+ALLOW_FAILING_TESTS := true
+else
+ALLOW_FAILING_TESTS := false
+endif
+
 %:
dh $@
 
 override_dh_auto_configure:
dh_auto_configure -- --enable-doc
+
+override_dh_auto_test:
+   dh_auto_test || $(ALLOW_FAILING_TESTS)

Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable

[Scott Talbert]

On Sun, 8 Apr 2018, Norbert Lange wrote:


Maybe it's also worth including a trival wrapper script to set
PYTHONPATH suitably and then exec python.


Is there a good reason why you are making it harder than necessary to
use python-wxgtk4.0 ?


Because wxPython 3.0 already exists for Python 2 as module "wx".  But
wxPython 3.0 doesn't support Python 3 and never will, so there's no
other claimant for module "wx" for Python 3.

wxPython 4.0 is pretty much a from-the-ground-up rebuild and isn't
completely compatible with wxPython 3.0, so switching "import wx" to use
that for Python 2 would not work out well.


its not entirely incompatible either, as right now I only get deprecation
warnings on code that was written for wxPython 3.0.


The code you're running must not use any of the changed APIs.  See here 
for some of the changes:

https://github.com/wxWidgets/Phoenix/blob/master/docs/classic_vs_phoenix.rst


Python 2 is fully supported by Debian during the lifetime of buster,
and there are various reasons why many users are stuck with Python 2
for some more time.


There are, but people sticking with Python 2 are really unlikely to want
to use wxPython 4.0.


Sticking to Python2 is not the reason, no. The argument would be to
use wxPython 4.0,
and have it painlessly run on current systems and with packages
that aren't yet ported to python3.
without wxPython 4.0 on python2, you have to stick to wxPython 3.0,
and either bet on upwards compatibility or test on both libraries.


There really isn't much of a reason to use wxPython 4.0 though, other than 
for Python 3 support.  That's really the only major enhancement over 
wxPython 3.0.  Both wxPython 3.0 and wxPython 4.0 are python bindings for 
wxWidgets 3.0.  wxPython 4.0 just has a slightly different API in some 
cases.



Personally I would prefer a mutual-exlusive installation or
an update-alternatives scheme as sym-linking the wx folder did work for me.


We can't break any existing wxPython 3.0 applications though.  I suppose 
we could do an update-alternatives scheme, but wxPython 3.0 would have the 
higher priority to avoid breaking any applications.  So, it would really 
only be useful if wxPython 4.0 was the only one installed.


Scott

Bug#895163: RM: ttf-freefont -- RoM; RoQA: renamed to fonts-freefont

[Jeremy Bicha]

Package: ftp.debian.org
X-Debbugs-Cc: ttf-freef...@packages.debian.org
Tags: moreinfo

fonts-freefont has provided transitional packages for ttf-freefont's
packages for multiple Debian releases. The transitional packages have
been dropped now, but surprisingly, the ttf-freefont source package
had never been removed.

Please remove ttf-freefont from Debian.

I am adding a blocker but for one package that still Build-Depends on
the old name.

On behalf of the Debian Fonts team,
Jeremy Bicha

Bug#895162: synfigstudio: Update fonts-freefont build-depends

[Jeremy Bicha]

Source: synfigstudio
Version: 1.0.2-1
Severity: serious
Tags: buster sid

fonts-freefont-ttf (or fonts-freefont-otf) has replaced ttf-freefont.
Please update synfigstudio's Build-Depends.

Thanks,
Jeremy Bicha

Bug#895161: snapd: "broken"

[clayton]

Package: snapd
Version: 2.30-5+b1
Severity: important

Running Debian Testing, up to date.
No idea what provoked this exactly, but:

$ snap list
Name Version  Rev   Developer  Notes
core  4206  canonical  broken
skype 23skype  broken

$ snap run skype
error: cannot find installed snap "skype" at revision 23

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

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

Versions of packages snapd depends on:
ii  adduser  3.117
ii  apparmor 2.12-4
ii  ca-certificates  20170717
ii  gnupg2.2.5-1
ii  gnupg1   1.4.22-4
ii  libapparmor1 2.12-4
ii  libc62.27-3
ii  libcap2  1:2.25-1.2
ii  libseccomp2  2.3.1-2.1
ii  libudev1 238-4
ii  openssh-client   1:7.6p1-4
ii  squashfs-tools   1:4.3-6
ii  systemd  238-4

snapd recommends no packages.

snapd suggests no packages.

-- no debconf information

Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable

[Norbert Lange]

2018-04-07 23:28 GMT+02:00 Olly Betts :
> Control: severity -1 normal
>
> On Sat, Apr 07, 2018 at 05:30:19PM +0300, Adrian Bunk wrote:
>> On Fri, Apr 06, 2018 at 11:53:39PM -0400, Scott Talbert wrote:
>> > On Sat, 7 Apr 2018, Norbert Lange wrote:
>> >
>> > > it appears that the files are installed in a subdirectory,
>> > > potentially to avoid confligs with previous versions?
>> > > result is that
>> > >
>> > > import wx fails with
>> > >
>> > > ImportError: No module named wx
>> > >
>> > > I havent found a way to configure the installation
>> >
>> > The purpose of the python-wxgtk4.0 package is primarily for application
>> > developers to use in porting their applications to wxPython 4.0 (Phoenix).
>> > There isn't much of a reason otherwise to use the Python 2 version of
>> > wxPython 4.0.  Instead, you should use python3-wxgtk4.0 with which you can
>> > 'import wx'.
>> >
>> > If you really would like to use the Python 2 version, you can do:
>> >
>> > PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg
>> >  python
>> > import wx
>
> This doesn't appear to be documented in the package, which it really
> should be (probably a brief explanation in the package description, and
> more detail in README.Debian).

The package name alone would imply it serves the same purpose as
python3-wxgtk4.0, python-wxgtk3.0. which is providing the wx module

>
> Maybe it's also worth including a trival wrapper script to set
> PYTHONPATH suitably and then exec python.
>
>> Is there a good reason why you are making it harder than necessary to
>> use python-wxgtk4.0 ?
>
> Because wxPython 3.0 already exists for Python 2 as module "wx".  But
> wxPython 3.0 doesn't support Python 3 and never will, so there's no
> other claimant for module "wx" for Python 3.
>
> wxPython 4.0 is pretty much a from-the-ground-up rebuild and isn't
> completely compatible with wxPython 3.0, so switching "import wx" to use
> that for Python 2 would not work out well.

its not entirely incompatible either, as right now I only get deprecation
warnings on code that was written for wxPython 3.0.

>
> And a lot of packages use wxPython 3.0, so wxPython 4.0 for Python 2
> really needs to be co-installable with wxPython 3.0.

And a few packages like scapy still don't work with Python 3.
Its forcing Python3 vs. forcing wxPython 4.0.

>
> Installing the module as "wx4" or something isn't helpful as that
> doesn't match what upstream does, nor how it's packaged for Python 3.

i agree that this is not viable.

>
> The only reason Scott created this package is to help people maintaining
> a wxPython application who want to migrate it to wxPython 4.0 - that
> involves both porting it from Python 2 to Python 3 and from wxPython 3.0
> to wxPython 4.0.  Rather than having to do both together, with this
> package you can port to Python 2 + wxPython 4.0 as an intermediate step.

this also makes it hard to drop wxPython 3.0, as right now there is
a need to run such apps on current systems.

>
> So I'd say the bug here is really that this isn't clear from the current
> packages.
>
>> Python 2 is fully supported by Debian during the lifetime of buster,
>> and there are various reasons why many users are stuck with Python 2
>> for some more time.
>
> There are, but people sticking with Python 2 are really unlikely to want
> to use wxPython 4.0.

Sticking to Python2 is not the reason, no. The argument would be to
use wxPython 4.0,
and have it painlessly run on current systems and with packages
that aren't yet ported to python3.
without wxPython 4.0 on python2, you have to stick to wxPython 3.0,
and either bet on upwards compatibility or test on both libraries.

Personally I would prefer a mutual-exlusive installation or
an update-alternatives scheme as sym-linking the wx folder did work for me.

Norbert

Bug#874249: unison is broken if not at least one older version also available

[Paul Beardsell]

The whole point of Unison is to allow sync of file trees between different
computers running different versions of an operating systems or even
entirely different operating systems. Because not all systems can have the
one same version of Unison at least one preferably two older good versions
need to be kept. That is supposed to be what the package unison-all is
about! The unison package gives you the latest, the unison-all package
makes Unison useful! In stretch unison-all should include at least 2.40 and
perhaps 2.32. Please!

p...@beardsell.com

Bug#887551: [request-tracker-maintainers] Bug#887551: request-tracker4 depends on libemail-address-perl

[Dominic Hargreaves]

On Wed, Jan 17, 2018 at 09:05:18PM +0100, Pali Rohár wrote:
> Hi! Package request-tracker4 depends on libemail-address-perl which is
> vulnerable to CVE-2015-7686, see bug #868170. libemail-address-perl
> provides perl module Email::Address which is now unmaintained. There is
> a new perl module Email::Address::XS which is API compatible replacement
> for Email::Address and is available in libemail-address-xs-perl. Please
> port request-tracker4 package to use libemail-address-xs-perl. If you need
> help with porting let me know.

Thanks for the heads up. Upstream is going to look at this for the 4.6
cycle. Given that request-tracker4 is far from being the only reverse
dependency at the moment, I don't plan to look at accelerating this,
but I would happily take a working patch into Debian sooner.

Cheers,
Dominic.

Bug#895157: libterm-readline-gnu-perl: warning message when $TERM is unset

[Steve Langasek]

Package: libterm-readline-gnu-perl
Version: 1.35-3
Followup-For: Bug #895157

It appears that this also breaks the 'nama' autopkgtests on some
architectures in Ubuntu's environment, and it's much less straightforward to
work around it with setting TERM there since nama uses autodep8 for its test
generation.  Attached, please find an updated patch which lets
libterm-readline-gnu-perl work without error output when $TERM is unset.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libterm-readline-gnu-perl-1.35/debian/patches/50dumbterm.patch 
libterm-readline-gnu-perl-1.35/debian/patches/50dumbterm.patch
--- libterm-readline-gnu-perl-1.35/debian/patches/50dumbterm.patch  
2018-01-18 14:26:08.0 -0800
+++ libterm-readline-gnu-perl-1.35/debian/patches/50dumbterm.patch  
2018-04-07 15:58:33.0 -0700
@@ -1,9 +1,15 @@
 Description: Do not use Term::ReadLine::Gnu on dumb terminals or emacs
 Origin: https://rt.cpan.org/Public/Bug/Display.html?id=123398
+Author: Hiroo HAYASHI 
+Author: Steve Langasek 
 Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=166987
+Bug-Debian: https://bugs.debian.org/895157
+Last-Modified: 2018-04-07
 
 a/Gnu.pm
-+++ b/Gnu.pm
+Index: libterm-readline-gnu-perl-1.35/Gnu.pm
+===
+--- libterm-readline-gnu-perl-1.35.orig/Gnu.pm
 libterm-readline-gnu-perl-1.35/Gnu.pm
 @@ -80,6 +80,11 @@
  END
  }
@@ -11,7 +17,7 @@
 +# use Term::ReadLine::Stub on a dumb terminal.
 +# https://rt.cpan.org/Ticket/Display.html?id=123398
 +BEGIN {
-+croak "dumb terminal." if($ENV{TERM} =~ /^(dumb|emacs|unknown)$/);
++croak "dumb terminal." if(!exists $ENV{TERM} || $ENV{TERM} =~ 
/^(dumb|emacs|unknown)$/);
 +}
  
  {

Bug#895082: sendmail: Please replace 'c_rehash' with 'openssl rehash'

[Andreas Beckmann]

On 2018-04-07 00:48, Sebastian Andrzej Siewior wrote:
> Should the c_rehash script be mentioned in the source code or script
> of this package but is not used during the build process or in the
> final package then feel free to close the bug saying so.

The only occurrence I could find is in some documentation:

./doc/op/op.me:
...
A better way to do this is to use the
.b c_rehash
command that is part of the OpenSSL distribution
because it handles subject hash collisions
by incrementing the number in the suffix of the filename of the symbolic
link,
e.g.,
.b \&.0
to
.b \&.1 ,
and so on.
...

Should I change that sentence? How?


Andreas

Bug#893043: stretch-pu: package nss-pam-ldapd/0.9.7-2+deb9u1

[Adam D. Barratt]

Control: tags -1 + pending

Hi,

On Tue, 2018-04-03 at 10:23 +0200, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Sat, Mar 31, 2018 at 10:29:07PM +0100, Adam D. Barratt wrote:
> > Control: tags -1 + confirmed
> > 
> > On Thu, 2018-03-15 at 21:49 +0100, Salvatore Bonaccorso wrote:
> > > src:nss-pam-ldapd is affected in stable (and alrady fixed
> > > correspondigly in unstable and testing) by #890508, which under
> > > certian circumstances (like the ones outlined in the bug, pam
> > > stack
> > > configured with pam_ldap, UseDNS=yes in sshd_config, and a remote
> > > hostname which is longer than 64 bytes), can lead to
> > > authentication
> > > failure. That is just one way to trigger the issue. It would be
> > > as
> > > well by any rhost value which matches the problem.
> > > 
> > 
> > Please go ahead.
> 
> Thank you, uploaded.
> 

Flagged for acceptance into p-u; thanks.

Regards,

Adam

Bug#895160: No -c examples, etc.

[積丹尼 Dan Jacobson]

Package: tzwatch
Version: 1.4.4-11
Severity: wishlist
File: /usr/share/man/man1/tzwatch.1.gz

>SYNOPSIS
>   tzwatch [options]

Maybe say

   tzwatch [-c ...] [-f FORMAT]


> DESCRIPTION
>   Tzwatch  displays  the  time in a number of time zones, specified by 
> the user.  The list of time zones (format as TZ variable) is kept in 
> ${HOME}/.tzlist.


Maybe say

   Tzwatch  displays  the  time in a number of time zones, specified
   by the user.  The list of time zones (each with format the same
   as the TZ variable) is kept in ${HOME}/.tzlist.


>The time zone is chosen using tzselect.

The time zone can be chosen using tzselect.

>OPTIONS
>   -c Configure time zones (add or remove).

*How?* *What?* Give examples!

Bug#895159: document fully the twlist file format

[積丹尼 Dan Jacobson]

Package: tzwatch
Version: 1.4.4-11
Severity: wishlist
File: /usr/share/man/man1/tzwatch.1.gz

All there is mentioned is

   ${HOME}/.tzlist could be edited by hand, with a valid value for the TZ 
variable on each line.

Please add a separate TZLIST(5) man page, giving the full format.
E.g., it turns out one can add # comments.

Bug#895158: ITP: typedload -- Python3 module to load and dump data into typed structures

[Salvo Tomaselli]

Package: wnpp
Owner: Salvo Tomaselli 
Severity: wishlist

* Package name: typedload
 Version : 0.9
 Upstream Author : Salvo 'LtWorf' Tomaselli 
* URL : https://github.com/ltworf/typedload#typedload
* License : GPL
 Programming Lang: Python
 Description : Python3 module to load and dump data into typed structures
This module provides an API to load dictionaries and list (usually loaded
from json) into Python's NamedTuples, sets, enums, and various other typed
data structures.
.
It also allows one to dump them from typed data structures to json-like
dictionaries and lists.
.
This allows all the code that uses external data to have the advantages
of using types, and causes all errors with the data to be noticed when it
is loaded, rather than when it is used.


- why is this package useful/relevant?

I found some people on stack overflow and similar, trying to obtain this, and
implementing hacky solutions that only support very very simple types.

This library supports quite a few combinations of types.

- is it a dependency for another package?

Not for now, it's quite new

- do you use it?

yes

- if there are other packages providing similar functionality, how
does it compare?

Not that I know of.


- how do you plan to maintain it?

Github, for both packaging and upstream code. Anyone interested in
co-maintaining
can ask me to give write rights (after sending some good patches, normally)

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#895153: [Pkg-zsh-devel] Bug#895153: zsh-common: /usr/local/share/zsh/site-functions is owned by root:staff

[Axel Beckert]

Hi Sven,

Sven Joachim wrote:
> Your package declares compliance with Debian Policy 4.1.4, claiming that
> "no other changes were required", but this is not actually true.
[...]
> |If "/etc/staff-group-for-usr-local" does not exist, "/usr/local"

Good catch! And thanks for the patch, too!

I though wonder: Do I need a b-d on debhelper >= 11.2~ then?

Because I'd otherwise won't fulfil S-V 4.1.4, or is this pointless,
because soon, even stretch-bpo will have 11.2~… and there won't be any
earlier 11.… debhelper anywhere in Debian.

(There will be probably an debhelper <= 11.2~ in Ubuntu 18.04, though.
But then again, they don't seem to care too much about the Debian
Policy…)

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

Bug#889111: bluez: Causes extreme non-stop CPU usage leading to notebook overheating quickly

[Nobuhiro Iwamatsu]

Hi,

> Package: bluez
> Version: 5.47-1+b1
> Severity: critical
> Justification: breaks the whole system
>
> Hello, I initially reported this as a bug to udev/systemd but it resolved 
> after removing the "bluez" package from my system,
> with no other changes besides that. The original report has all the pertinent 
> information:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889110

As also pointed out at 889110, I think that this is not a problem of
udev or bluez, but
a problem of kenrel.
If you delete or rename /lib/udev/rules.d/97-hid2hci.rules and restart
your sysrtem,
will this problem occur?

Best regards,
  Nobuhiro

-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6

Bug#853778: libdigidoc: Please migrate to openssl1.1 in buster

[Jeremy Bicha]

Control: reopen -1

I didn't read carefully enough.

Thanks,
Jeremy Bicha

Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable

[Olly Betts]

Control: severity -1 normal

On Sat, Apr 07, 2018 at 05:30:19PM +0300, Adrian Bunk wrote:
> On Fri, Apr 06, 2018 at 11:53:39PM -0400, Scott Talbert wrote:
> > On Sat, 7 Apr 2018, Norbert Lange wrote:
> > 
> > > it appears that the files are installed in a subdirectory,
> > > potentially to avoid confligs with previous versions?
> > > result is that
> > > 
> > > import wx fails with
> > > 
> > > ImportError: No module named wx
> > > 
> > > I havent found a way to configure the installation
> > 
> > The purpose of the python-wxgtk4.0 package is primarily for application
> > developers to use in porting their applications to wxPython 4.0 (Phoenix).
> > There isn't much of a reason otherwise to use the Python 2 version of
> > wxPython 4.0.  Instead, you should use python3-wxgtk4.0 with which you can
> > 'import wx'.
> > 
> > If you really would like to use the Python 2 version, you can do:
> > 
> > PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg
> >  python
> > import wx

This doesn't appear to be documented in the package, which it really
should be (probably a brief explanation in the package description, and
more detail in README.Debian).

Maybe it's also worth including a trival wrapper script to set
PYTHONPATH suitably and then exec python.

> Is there a good reason why you are making it harder than necessary to 
> use python-wxgtk4.0 ?

Because wxPython 3.0 already exists for Python 2 as module "wx".  But
wxPython 3.0 doesn't support Python 3 and never will, so there's no
other claimant for module "wx" for Python 3.

wxPython 4.0 is pretty much a from-the-ground-up rebuild and isn't
completely compatible with wxPython 3.0, so switching "import wx" to use
that for Python 2 would not work out well.

And a lot of packages use wxPython 3.0, so wxPython 4.0 for Python 2
really needs to be co-installable with wxPython 3.0.

Installing the module as "wx4" or something isn't helpful as that
doesn't match what upstream does, nor how it's packaged for Python 3.

The only reason Scott created this package is to help people maintaining
a wxPython application who want to migrate it to wxPython 4.0 - that
involves both porting it from Python 2 to Python 3 and from wxPython 3.0
to wxPython 4.0.  Rather than having to do both together, with this
package you can port to Python 2 + wxPython 4.0 as an intermediate step.

So I'd say the bug here is really that this isn't clear from the current
packages.

> Python 2 is fully supported by Debian during the lifetime of buster,
> and there are various reasons why many users are stuck with Python 2
> for some more time.

There are, but people sticking with Python 2 are really unlikely to want
to use wxPython 4.0.

Cheers,
Olly

Bug#895147: firefox: Safe Browsing updates fail due to insufficient quota on the Google API key

[Mike Hommey]

On Sat, Apr 07, 2018 at 11:26:13AM -0700, Francois Marier wrote:
> Package: firefox
> Version: 59.0.2-1
> Severity: important
> Tags: security
> 
> After enabling browser.safebrowsing.debug in about:config, I saw this on my
> terminal:
> 
>   listmanager: 17:45:17 GMT+ (UTC): download error for 
> goog-phish-proto,goog-malware-proto,goog-unwanted-proto,goog-badbinurl-proto,goog-downloadwhite-proto,goog-passwordwhite-proto:
>  429
> 
> "429 Too Many Requests" is given by the Safe Browsing server when API quota
> has been exceeded.
> 
> Note that I started Firefox in the morning (Pacific time) and the API quota
> is already gone. That means that for a good chunk of each day, Debian users
> are essentially running with Safe Browsing disabled.
> 
> Fixing this is simple:
> 
> 1. register for a new Google API key for Safe Browsing on 
> https://developers.google.com/
> 2. email me (franc...@mozilla.com) the Project ID (not the API key)
> 
> Google will be happy to increase the quota to a suitable amount.

We're using the same API key as the chromium in Debian, so presumably
the same problem applies to the chromium package. Why should we need a
*different* API key?

Mike

Bug#895134: libwx-scintilla-perl: needs tighter dependency on Wx build?

[Olly Betts]

On Sat, Apr 07, 2018 at 04:20:48PM +0300, Niko Tyni wrote:
> So to do this properly it looks like we need something to make
> sure the Perl Wx related packages are upgraded in sync. The
> virtual package provided by libalien-wxwidgets-perl (currently
> wxperl-gtk-3-0-4-uni-gcc-3-4) seems like a candidate, but I don't have
> a ready recipe for injecting that.

I'd guess that makes sense, but I don't entirely understand how the
libalien-wxwidgets-perl <-> libwx-perl connection works, or why we need
a chain of binNMUs after each new upstream wxwidgets3.0 release.

Presumably just copying libwx-perl's dependencies related to this
across would work?

> It seems probable that other packages (libwx-glcanvas-perl?) are
> similarly affected, but I haven't looked into that.

I'd expect so.  There don't seem to be any others - at least I don't see
any other -perl packages in the transition tracker:

https://release.debian.org/transitions/html/wxwidgets3.0-gtk3.html

> Olly, explicitly copying you as you're handling this transition (thanks
> for that!). Any thoughts on this?

I added dependencies in my recent libwx-scintilla-perl and
libwx-glcanvas-perl uploads to ensure that a gtk3 version of libwx-perl
was used (and from there down the dependency chain it should be OK).

I didn't try to handle preventing combinations of new libwx-perl with
older libwx-scintilla-perl or libwx-glcanvas-perl though since there was
no evidence that such handling was attempted for previous transitions.

> Setting severity to RC initially and marking as a transition blocker,
> but others should feel free to adjust as appropriate.

It would certainly be good to address this somehow, but mostly because
it will ease future transitions.  I'm not sure this really deserves to
block this one as the libwx*-perl collection is now back in step across
all release archs:

https://buildd.debian.org/status/package.php?p=libalien-wxwidgets-perl+libwx-perl+libwx-scintilla-perl+libwx-glcanvas-perl

Also blocking the transition really just means that the wx gtk2 packages
can't be removed, yet doing that if anything improves the situation.

But that's mostly a theoretical point right now as the full transition
is going to take months.

Cheers,
Olly

Bug#895008: kicad: can't start pcbnew

[Aurelien Jacobs]

On Sat, Apr 07, 2018 at 09:33:08PM +0200, Carsten Schoenert wrote:
> Hi,
> 
> please test a rebuild of KiCad 5.0.05.0.0~rc1+dfsg1+20180318 which is
> using libwxgtk3.0-gtk3-dev to get a proper GTK3 bindings.

I've tested this new build, and I can now start pcbnew including with
latest version python-wxgtk3.0, so this seems to fix the issue. Thanks !

Now this has uncovered another GTK+3 related issue for me in pcbnew.
If I enable "Modern Toolset (Accelerated)" in the Preferences menu,
pcbnew segfaults. It looks like it might be related to using
wxGLCanvasX11 (ie. calling libGLX and libX11) even though this GTK+3
build is now using Wayland instead of X11.

Here is the backtrace I got:

Thread 1 "kicad" received signal SIGSEGV, Segmentation fault.
0x723aac49 in XQueryExtension () from 
/usr/lib/x86_64-linux-gnu/libX11.so.6
(gdb) disassemble $pc-32,$pc+32
Dump of assembler code from 0x723aac29 to 0x723aac69:
   0x723aac29 : sub$0x38,%rsp
   0x723aac2d : mov%fs:0x28,%rax
   0x723aac36 : mov%rax,0x28(%rsp)
   0x723aac3b : xor%eax,%eax
   0x723aac3d : mov0x968(%rdi),%rax
   0x723aac44 : test   %rax,%rax
   0x723aac47 : je 0x723aac4b 

=> 0x723aac49 : callq  *(%rax)
   0x723aac4b : mov$0x8,%edx
   0x723aac50 : mov$0x62,%esi
   0x723aac55 : mov%rbx,%rdi
   0x723aac58 : callq  0x7238db90 
<_XGetRequest@plt>
   0x723aac5d : test   %rbp,%rbp
   0x723aac60 : mov%rax,%r15
   0x723aac63 : je 0x723aad10 

End of assembler dump.
(gdb) bt
#0  0x723aac49 in XQueryExtension () at 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#1  0x7fffef2ea3b2 in  () at /usr/lib/x86_64-linux-gnu/libGLX.so.0
#2  0x7fffef2e6415 in glXQueryVersion () at 
/usr/lib/x86_64-linux-gnu/libGLX.so.0
#3  0x77bcfe95 in wxGLCanvasX11::GetGLXVersion() () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#4  0x77bd0535 in wxGLCanvasX11::ConvertWXAttrsToGL(int const*, int*, 
unsigned long) () at /usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#5  0x77bd0d68 in wxGLCanvasX11::InitXVisualInfo(int const*, 
__GLXFBConfigRec***, XVisualInfo**) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#6  0x77bd1e70 in wxGLCanvas::Create(wxWindow*, int, wxPoint const&, 
wxSize const&, long, wxString const&, int const*, wxPalette const&) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#7  0x77bd2013 in wxGLCanvas::wxGLCanvas(wxWindow*, int, int const*, 
wxPoint const&, wxSize const&, long, wxString const&, wxPalette const&) () at 
/usr/lib/x86_64-linux-gnu/libwx_gtk3u_gl-3.0.so.0
#8  0x7fffd1aedbd9 in HIDPI_GL_CANVAS::HIDPI_GL_CANVAS(wxWindow*, int, int 
const*, wxPoint const&, wxSize const&, long, wxString const&, wxPalette const&) 
(this=0x585c4ea0, parent=, id=, 
attribList=, pos=..., size=..., style=8192, name=..., 
palette=...) at ./common/gal/hidpi_gl_canvas.cpp:38
#9  0x7fffd1b09285 in 
KIGFX::OPENGL_GAL::OPENGL_GAL(KIGFX::GAL_DISPLAY_OPTIONS&, wxWindow*, 
wxEvtHandler*, wxEvtHandler*, wxString const&) (this=0x585c4bb0, 
aDisplayOptions=..., aParent=0x57d7f120, aMouseListener=0x57d7f120, 
aPaintListener=0x57d7f120, aName=...) at 
./common/gal/opengl/opengl_gal.cpp:74
#10 0x7fffd1ae4b84 in 
EDA_DRAW_PANEL_GAL::SwitchBackend(EDA_DRAW_PANEL_GAL::GAL_TYPE) 
(this=this@entry=0x57d7f120, aGalType=EDA_DRAW_PANEL_GAL::GAL_TYPE_OPENGL) 
at ./common/draw_panel_gal.cpp:350
#11 0x7fffd189a01e in 
PCB_DRAW_PANEL_GAL::SwitchBackend(EDA_DRAW_PANEL_GAL::GAL_TYPE) 
(this=0x57d7f120, aGalType=) at 
./pcbnew/pcb_draw_panel_gal.cpp:396
#12 0x7fffd19e997f in 
EDA_DRAW_FRAME::SwitchCanvas(EDA_DRAW_PANEL_GAL::GAL_TYPE) 
(this=0x57d652b0, aCanvasType=EDA_DRAW_PANEL_GAL::GAL_TYPE_OPENGL) at 
./common/draw_frame.cpp:1195
#13 0x7fffd147d249 in PCB_EDIT_FRAME::OnSwitchCanvas(wxCommandEvent&) 
(this=0x57d652b0, aEvent=...) at ./pcbnew/pcb_edit_frame.cpp:1215
#14 0x7654a8ce in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#15 0x7654a9d3 in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) () at /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#16 0x7654ad9b in wxEvtHandler::TryHereOnly(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#17 0x7fffd1a0e1eb in EDA_BASE_FRAME::ProcessEvent(wxEvent&) 
(this=0x57d652b0, aEvent=...) at ./common/eda_base_frame.cpp:191
#18 0x7654ab93 in wxEvtHandler::DoTryChain(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#19 0x7654ae85 in wxEvtHandler::ProcessEvent(wxEvent&) () at 
/usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0
#20 0x76e88c6b in wxWindowBase::TryAfter(wxEvent&) () at 
/usr/lib/x86_64-lin

Bug#871471: Bug#894961: ldap-account-manager: missing dependencies on php-xml and php-zip

[Thorsten Glaser]

Roland Gruber dixit:

>thanks for your report. This was already addressed in 871471.

Perhaps, but would you please also fix it in stable?

Thanks,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

Bug#895145: virt-manager: fails to start networks

[Sam Tab]

I'm having the same problem on sid after upgrading today when libvirt*
packages got upgraded from 4.1.0-2 to 4.2.0-1. 'virsh net-start default '
also failed so I think problem's probably with libvirt libraries.

syslog has messages like this:
Apr  7 21:09:19 ws libvirtd[6210]: 2018-04-07 19:09:19.108+: 6230: info
: libvirt version: 4.2.0, package: 1 (Guido Günther  Fri,
06 Apr 2018 12:33:30 +0200)
Apr  7 21:09:19 ws libvirtd[6210]: 2018-04-07 19:09:19.108+: 6230: info
: hostname: ws
Apr  7 21:09:19 ws libvirtd[6210]: 2018-04-07 19:09:19.108+: 6230:
error : virFirewallValidateBackend:193 : direct firewall backend requested,
but /usr/sbin/iptables is not available: No such file or directory
Apr  7 21:09:19 ws libvirtd[6210]: 2018-04-07 19:09:19.108+: 6230:
error : virFirewallApply:918 : internal error: Failed to initialize a valid
firewall backend
Apr  7 21:09:19 ws libvirtd[6210]: 2018-04-07 19:09:19.108+: 6230:
error : virFirewallApply:918 : internal error: Failed to initialize a valid
firewall backend
Apr  7 21:09:19 ws kernel: [  130.013856] audit: type=1400
audit(1523128159.103:26): apparmor="DENIED" operation="signal"
profile="/usr/sbin/libvirtd" pid=6210 comm="libvirtd" requested_mask="send"
denied_mask="send" signal=hup peer="unconfined"
Apr  7 21:09:19 ws libvirtd[6210]: 2018-04-07 19:09:19.147+: 6230:
error : virFirewallApply:918 : internal error: Failed to initialize a valid
firewall backend

Symlinking iptables, installing dnsmasq and firewalld solved the issue for
me for the moment.

Bug#895153: zsh-common: /usr/local/share/zsh/site-functions is owned by root:staff

[Sven Joachim]

Control: tags -1 + patch

On 2018-04-07 22:36 +0200, Sven Joachim wrote:

> Package: zsh-common
> Version: 5.4.2-4
> Severity: normal
>
> Your package declares compliance with Debian Policy 4.1.4, claiming that
> "no other changes were required", but this is not actually true.
> The upgrading-checklist states
>
> ,
> | 9.1.2
> |If "/etc/staff-group-for-usr-local" does not exist, "/usr/local"
> |and all subdirectories created by packages should have permissions
> |0755 and be owned by "root:root".  If the file exists, the old
> |permissions of 2775 and ownership of root:staff should remain.
> `
>
> The zsh-common postinst script does not respect this policy though,
> using root:staff unconditionally.
>
> ,
> | mkdir -m2775 -p /usr/local/share/zsh/site-functions && chown root:staff \
> |/usr/local/share/zsh/site-functions || true
> `

The attached patch should do the trick, provided zsh gets rebuilt with
debhelper 11.2 (not tested yet).  I left the postrm alone, although I
don't really see why #708106 happened in the first place - the prerm
ought to be enough to remove the directories under /usr/local.

Cheers,
   Sven

>From c82cfa09011bf9d48222f02893dcb1aec403744b Mon Sep 17 00:00:00 2001
From: Sven Joachim 
Date: Sat, 7 Apr 2018 23:05:21 +0200
Subject: [PATCH] Handle /usr/local/share/zsh with dh_usrlocal (Closes:
 #895153)

The upstream Makefile installs the /usr/local/share/zsh/site-functions
directory, so all that is needed is not to delete it later in
debian/rules, after which dh_usrlocal magically handles the rest.
---
 debian/rules   |  1 -
 debian/zsh-common.postinst | 10 --
 debian/zsh-common.prerm| 24 
 3 files changed, 35 deletions(-)
 delete mode 100644 debian/zsh-common.postinst
 delete mode 100644 debian/zsh-common.prerm

diff --git a/debian/rules b/debian/rules
index 021d78014..ba228eed2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -92,7 +92,6 @@ override_dh_auto_install-indep: build-dynamic
 	perl $(CURDIR)/Util/helpfiles Doc/zshbuiltins.1 debian/zsh-common/usr/share/zsh/help
 
 	cd obj && $(MAKE) install.fns DESTDIR=$(CURDIR)/debian/zsh-common
-	rm -r debian/zsh-common/usr/local
 
 	awk '/^#define FPATH_DIR/ { head=$$3;   gsub(/"/,"",head); };\
  /^#define FPATH_SUBDIRS/ { $$1=""; $$2=""; gsub(/[" ]/,""); tail=$$0; } \
diff --git a/debian/zsh-common.postinst b/debian/zsh-common.postinst
deleted file mode 100644
index 601994b03..0
--- a/debian/zsh-common.postinst
+++ /dev/null
@@ -1,10 +0,0 @@
-#!/bin/sh
-
-set -e
-
-mkdir -m2775 -p /usr/local/share/zsh/site-functions && chown root:staff \
-   /usr/local/share/zsh/site-functions || true
-
-#DEBHELPER#
-
-exit 0
diff --git a/debian/zsh-common.prerm b/debian/zsh-common.prerm
deleted file mode 100644
index ffb0622e1..0
--- a/debian/zsh-common.prerm
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-
-set -e
-
-case "$1" in
-(remove|deconfigure)
-rmdir /usr/local/share/zsh/site-functions || true
-rmdir /usr/local/share/zsh || true
-;;
-(upgrade)
-;;
-
-(failed-upgrade)
-;;
-
-(*)
-	echo "prerm called with unknown argument \`$1'" >&2
-	exit 0
-;;
-esac
-
-#DEBHELPER#
-
-exit 0
-- 
2.17.0

Bug#895151: Guitarix update 35.2-2 (stretch) -> 36.1-1 (buster) improvement

[James Cowgill]

Hi,

On 07/04/18 20:41, treb...@tuxfamily.org wrote:
> Package: guitarix
> Version: 36.1-1
> 
> While upgrading from the Stretch package (35.2-2) to the sid/buster one
> (36.1-1), it doesn't update the libgxw0 and libgxwmm0 packages which are
> needed by the Guitarix application.
> 
> Then, the application isn't fully functional since it requires those
> libs to work with, and doesn't have those in the right version, then
> missing the right versionned functions. Hence there are some errors
> while using guitarix.

What are the errors? This bug might be RC but I can't tell if I don't
know what the underlying issue is.

> In d/control, adding to the binary "Package: guitarix" 's "Depends" '
> field the following seems to fix the issue :
> libgxw0 (>= ${source:Version}),
> libgxwmm0 (>= ${source:Version}),
> 
> Please double check before applying.

The correct fix is to generate versioned shlibs files for the libraries
so that the correct dependencies are automatically generated. Overriding
dh_makeshlibs with "dh_makeshlibs -V" is the quick conservative way of
doing this.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#895157: libterm-readline-gnu-perl: warning message when $TERM is unset

[Steve Langasek]

Package: libterm-readline-gnu-perl
Version: 1.35-2
Severity: minor
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic

Dear maintainers,

With the fix for bug #166987 in libterm-readline-gnu-perl 1.35-2, the
shelldap autopkgtest now fails with a warning message on stderr:

[...]
autopkgtest [19:56:24]: test smoke-test: [---
TESTING: shelldap --version
Use of uninitialized value $ENV{"TERM"} in pattern match (m//) at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/Term/ReadLine/Gnu.pm line 86.
autopkgtest [19:56:25]: test smoke-test: ---]
autopkgtest [19:56:25]: test smoke-test:  - - - - - - - - - - results - - - - - 
- - - - -
smoke-test   FAIL stderr: Use of uninitialized value $ENV{"TERM"} in 
pattern match (m//) at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/Term/ReadLine/Gnu.pm line 86.
[...]

  https://ci.debian.net/packages/s/shelldap/unstable/amd64/

shelldap also needs a fix to its autopkgtest regardless because of its own
output on stderr when libterm-readline-gnu-perl is unavailable, which I've
filed as bug #895155; but I think libterm-readline-gnu-perl itself should be
fixed to not spew warnings when $TERM is unset, but instead explicitly croak
on missing $ENV{"TERM"}.

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


signature.asc
Description: PGP signature

Bug#895156: ITP: easyloggingpp -- single-header logging library for C++ applications

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: easyloggingpp
  Version : 9.96.4
  Upstream Author : Muflihun Labs
* URL : https://muflihun.github.io/easyloggingpp/
* License : MIT
  Programming Lang: C++
  Description : single-header logging library for C++ applications

Easylogging++ is a light-weight, high performance logging library for
software written in C++11 and higher. It is highly configurable and
extensible, supports both severity- and verbosity-based logging,
provides crash handling, STL logging, integration with syslog, log
rotation, performance-specific logging for profiling, pointcut-style
extensions of third-party code...


I’m packaging this as a pre-requisite for loggedfs.

Bug#895155: shelldap: autopkgtest fails with TERM=dumb/TERM=unknown

[Steve Langasek]

Package: shelldap
Version: 1.4.0-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch autopkgtest

Dear Salvatore,

Since version 1.35-2, libterm-readline-gnu-perl deliberately refuses to run
when $TERM is set to 'dumb' or 'unknown', on the grounds that readline is a
terminal technology and dumb/unknown indicates there is no properly
configured terminal, so it's better to abort and let callers fall back to
other interfaces (bug #166987).

However, when autopkgtests are run on automated infrastructure, they quite
reasonably run without a terminal; so the shelldap autopkgtest now fails:

autopkgtest [19:56:24]: test smoke-test: [---
TESTING: shelldap --version
Use of uninitialized value $ENV{"TERM"} in pattern match (m//) at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/Term/ReadLine/Gnu.pm line 86.
autopkgtest [19:56:25]: test smoke-test: ---]
autopkgtest [19:56:25]: test smoke-test:  - - - - - - - - - - results - - - - - 
- - - - -
smoke-test   FAIL stderr: Use of uninitialized value $ENV{"TERM"} in 
pattern match (m//) at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/Term/ReadLine/Gnu.pm line 86.
autopkgtest [19:56:25]: test smoke-test:  - - - - - - - - - - stderr - - - - - 
- - - - -
Use of uninitialized value $ENV{"TERM"} in pattern match (m//) at 
/usr/lib/x86_64-linux-gnu/perl5/5.26/Term/ReadLine/Gnu.pm line 86.

  https://ci.debian.net/packages/s/shelldap/unstable/amd64/

The error message here is a bug in libterm-readline-gnu-perl, which should
handle the case of TERM not being set in the environment at all; but even
fixing libterm-readline-gnu-perl, shelldap's autopkgtest would still fail
with:

$ TERM=unknown ./debian/tests/smoke-test  > /dev/null
Term::ReadLine::Gnu not installed.
Continuing, but shelldap is of limited usefulness without it.

$

(this output is on stderr, which is not allowed by default in autopkgtests.)

The simplest solution for shelldap is to set a sensible $TERM in its
autopkgtest before calling.  The attached patch which implements this has
been uploaded to Ubuntu, to fix the bug there.  (Unfortunately autopkgtest
regressions are not considered blockers for release in Debian, but they are
in Ubuntu.)

Please consider including this patch in Debian as well.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru shelldap-1.4.0/debian/tests/smoke-test 
shelldap-1.4.0/debian/tests/smoke-test
--- shelldap-1.4.0/debian/tests/smoke-test  2017-06-17 11:46:43.0 
-0700
+++ shelldap-1.4.0/debian/tests/smoke-test  2018-04-07 13:53:17.0 
-0700
@@ -4,4 +4,4 @@
 
 # --
 echo TESTING: shelldap --version
-shelldap --version | ( ! grep -vE '^shelldap [0-9a-z.+-:~]+$' )
+TERM=xterm shelldap --version | ( ! grep -vE '^shelldap [0-9a-z.+-:~]+$' )

Bug#895154: ffmpeg: FTBFS - make[2]: write error: stdout

[James Cowgill]

Source: ffmpeg
Version: 7:3.4.1-1
Severity: serious
Tags: sid buster

For some reason ffmpeg has started FTBFS with this error:
> TESTvsynth2-zlib
> /<>/tests/fate-run.sh fate-vsynth2-zlib "" "" 
> "/<>/debian/standard" 'enc_dec "rawvideo -s 352x288 -pix_fmt 
> yuv420p " tests/data/vsynth2.yuv avi "-c zlib " rawvideo "-s 352x288 -pix_fmt 
> yuv420p -vsync 0 " -keep ""' '' 
> '/<>/tests/ref/vsynth/vsynth2-zlib' '' '1' '' '' '' '' '' '1' '' 
> '' ''
>  /<>/debian/standard/ffmpeg -nostdin -nostats -cpuflags all -f 
> rawvideo -s 352x288 -pix_fmt yuv420p -threads 1 -idct simple -flags +bitexact 
> -sws_flags +accurate_rnd+bitexact -fflags +bitexact -hwaccel none -threads 1 
> -thread_type frame+slice -i 
> /<>/debian/standard/tests/data/vsynth2.yuv -threads 1 -idct 
> simple -dct fastint -c zlib -flags +bitexact -sws_flags 
> +accurate_rnd+bitexact -fflags +bitexact -f avi -y 
> /<>/debian/standard/tests/data/fate/vsynth2-zlib.avi
>  /<>/debian/standard/ffmpeg -nostdin -nostats -cpuflags all 
> -threads 1 -idct simple -flags +bitexact -sws_flags +accurate_rnd+bitexact 
> -fflags +bitexact -hwaccel none -threads 1 -thread_type frame+slice -i 
> /<>/debian/standard/tests/data/fate/vsynth2-zlib.avi -threads 1 
> -idct simple -dct fastint -s 352x288 -pix_fmt yuv420p -vsync 0 -flags 
> +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -f rawvideo -y 
> /<>/debian/standard/tests/data/fate/vsynth2-zlib.out.rawvideo
> make[2]: Leaving directory '/<>/debian/standard'
> make[2]: write error: stdout
> dh_auto_test: cd debian/standard && make -j4 -O check -k returned exit code 1
> make[1]: *** [debian/rules:231: override_dh_auto_test-arch] Error 25
> make[1]: Leaving directory '/<>'
> make: *** [debian/rules:192: binary] Error 2
> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 
> 2

This can be seen on the reproducible builds first seen 2018-03-15
affecting 3.4 and 3.5 in experimental.

I'm guessing this has something to do with "make -O" which was enabled
recently in debhelper, but I haven't checked.

James



signature.asc
Description: OpenPGP digital signature

Bug#895153: zsh-common: /usr/local/share/zsh/site-functions is owned by root:staff

[Sven Joachim]

Package: zsh-common
Version: 5.4.2-4
Severity: normal

Your package declares compliance with Debian Policy 4.1.4, claiming that
"no other changes were required", but this is not actually true.
The upgrading-checklist states

,
| 9.1.2
|If "/etc/staff-group-for-usr-local" does not exist, "/usr/local"
|and all subdirectories created by packages should have permissions
|0755 and be owned by "root:root".  If the file exists, the old
|permissions of 2775 and ownership of root:staff should remain.
`

The zsh-common postinst script does not respect this policy though,
using root:staff unconditionally.

,
| mkdir -m2775 -p /usr/local/share/zsh/site-functions && chown root:staff \
|/usr/local/share/zsh/site-functions || true
`

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

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


zsh-common depends on no packages.

Versions of packages zsh-common recommends:
ii  zsh  5.4.2-4

Versions of packages zsh-common suggests:
ii  zsh-doc  5.4.2-4

-- no debconf information

Bug#895152: cinnamon-screensaver: cinnamon-screesaver-command only locks the screen the first time it is called

[Luís Picciochi Oliveira]

Package: cinnamon-screensaver
Version: 3.6.1-2
Severity: normal

Dear Maintainer,

Consider the following script:

  var=1
  while true ; do
sleep 3
echo Test number $var
date
cinnamon-screensaver-command -l --away-message "Test number $var"
date
echo 'The screensaver should have started...'
var=$((var+1));
  done

Running this, I would expect to ensure the screen is locked every 3 seconds.
In the case when the screensaver was already locked when `cinnamon-screensaver-
command -l` is called, I would expect the call to be harmless and return
without doing anything.

However, I see the following output:
Test number 1
Sat  7 Apr 20:52:48 WEST 2018
Sat  7 Apr 20:52:49 WEST 2018
The screensaver should have started... # (1)
Test number 2
Sat  7 Apr 20:52:52 WEST 2018 # (2)
Sat  7 Apr 20:53:02 WEST 2018 # (3)
The screensaver should have started...
^C

(1) tells me that cinnamon-screensaver-command was called and returned.
(2) talls me that we entered the second cycle. cinnamon-screensaver-command was
called (we saw "Test number 2" on the lock screen), but then it does not
return.
The timestamp in (3) is only printed after I enter my password at the locked
screen and press Enter. This tells us that the second call only returns after
the lock screen is dismissed.


I can't see a reason for the cinnamon-screensaver-command to return in the
first call but not in the second. This inconsistency makes it hard to script
more complex behaviours.


Possibly related to this, I also observed that if I send the cinnamon-
screensaver-command call to the background, by adding an '&' to the end of the
line:

  cinnamon-screensaver-command -l --away-message "Test number $var" &


...it will be able to call the command up to 9 times. Starting with the 10th,
the script will output a stack trace on all subsequent calls:

Test number 9
Sat  7 Apr 21:02:43 WEST 2018
[8] 31244
Sat  7 Apr 21:02:43 WEST 2018
The screensaver should have started...
Test number 10
Sat  7 Apr 21:02:46 WEST 2018
[9] 31257
Sat  7 Apr 21:02:46 WEST 2018
The screensaver should have started...
Traceback (most recent call last):
  File "/usr/share/cinnamon-screensaver/cinnamon-screensaver-command.py", line
73, in on_client_ready
self.perform_action()
  File "/usr/share/cinnamon-screensaver/cinnamon-screensaver-command.py", line
90, in perform_action
self.client.proxy.call_lock_sync(self.message)
GLib.Error: g-io-error-quark: Timeout was reached (24)
Test number 11
...

After closing the lock screen, killing the script and the pending commands, I
see that all but the first call were hanging in the background.
Why only after the 10th we start seeing tracebacks is also not clear to me.

I believe `cinnamon-screensaver-command -l` should:
 * always return
 * signal any errors with a non-zero return code
 * either lock the screen or do nothing at all if it was already locked.

Note that #895150 is related but more generic than this.

Thanks and best regards,
Luís Picciochi Oliveira



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

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

Versions of packages cinnamon-screensaver depends on:
ii  cinnamon-desktop-data   3.6.2-2
ii  gir1.2-accountsservice-1.0  0.6.45-1
ii  gir1.2-cinnamondesktop-3.0  3.6.2-2
ii  gir1.2-gkbd-3.0 3.26.0-3
ii  gir1.2-glib-2.0 1.56.0-2
ii  gir1.2-gtk-3.0  3.22.29-2
ii  gir1.2-xapp-1.0 1.0.4-2
ii  iso-flags-png-320x240   1.0.1-1
ii  libc6   2.27-3
ii  libcscreensaver03.6.1-2
ii  libglib2.0-02.56.0-4
ii  libgtk-3-0  3.22.29-2
ii  python3 3.6.4-1
ii  python3-gi  3.28.1-1
ii  python3-gi-cairo3.28.1-1
ii  python3-setproctitle1.1.10-1+b1
ii  python3-xapp1.0.1-1
ii  python3-xlib0.20-3

Versions of packages cinnamon-screensaver recommends:
pn  cinnamon-screensaver-x-plugin  

Versions of packages cinnamon-screensaver suggests:
pn  cinnamon-screensaver-webkit-plugin  

-- no debconf information

Bug#895151: Guitarix update 35.2-2 (stretch) -> 36.1-1 (buster) improvement

[trebmuh]

Package: guitarix
Version: 36.1-1

While upgrading from the Stretch package (35.2-2) to the sid/buster one 
(36.1-1), it doesn't update the libgxw0 and libgxwmm0 packages which are 
needed by the Guitarix application.


Then, the application isn't fully functional since it requires those 
libs to work with, and doesn't have those in the right version, then 
missing the right versionned functions. Hence there are some errors 
while using guitarix.


In d/control, adding to the binary "Package: guitarix" 's "Depends" ' 
field the following seems to fix the issue :

libgxw0 (>= ${source:Version}),
libgxwmm0 (>= ${source:Version}),

Please double check before applying.

Hope that helps.
Olivier

Bug#893523: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

On 6 April 2018 at 14:08, Lisandro Damián Nicanor Pérez Meyer
 wrote:
> I'm afraid that I won't be able to start the transition until monday.

Time cleared up during weekend, so I have time for this in my hands. I
think I'm still free to go, but just in case pinging here and on IRC
before proceeding.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Bug#895008: kicad: can't start pcbnew

[Carsten Schoenert]

Hi,

please test a rebuild of KiCad 5.0.05.0.0~rc1+dfsg1+20180318 which is
using libwxgtk3.0-gtk3-dev to get a proper GTK3 bindings.

https://people.debian.org/~tijuca/kicad/

Regards
Carsten

Bug#853035: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

Hi Graham,

> > I'm pretty hardcore on tests being determinstic, so merely increasing
> > the wait time feels especially gross to me. :)
> 
> Would you please explain your objection to timeouts in tests?

Well, we should probably separate the cases of using /timing/ in tests as
part of, say, checking whether something is "fast enough" or an algorithm is
O(n) vs O(n^2) and timing that is essentially relying on the machine not
being under load or is otherwise slow.

I am sure you would agree the former is problematic and not even remotely
determinstic! The latter is borderline, but when you can't rely on test
failures being genuine test failures, you psychologically start to demote
them in your mind in terms of importance and whether you should care about
the,.

> I think it is practical to give up waiting for a response some point.
> Even Debian's buildds give up after 150 minutes.

Mm, as a sanity check for the integrity of the test/build platform, timing
out after X hours or so makes sense and I have no problem with this. It's
just the stuff on the order of Y seconds that is a little bit more difficult
to justify. :)

(Can this test really not reliably detect whether something was killed/
spawned...?)


Best wishes,

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

Bug#890873: lintian: gcc-8-cross-ports makes lintian fork-bomb, consume all memory and fill the disk

[Niels Thykier]

Chris Lamb:
> Hi Niels,
> 
>> I do not remember if you can use $foo->{'bar'} in a string
>> interpolation, but I guess are about to find out. :)
> 
>   $ cat test.pl
>   use strict;
>   my $foo = { 'bar' => 'Yes.' };
>   print "Can we use \$foo->{'bar'} in a string interpolation? 
> $foo->{'bar'}\n";
> 
>   $ perl test.pl
>   Can we use $foo->{'bar'} in a string interpolation? Yes.
> 
> TIL :)
> 

TIWR :)

>> Thanks, looks good to me with a quick review.
> 
> I'll give it a whirl!
>  
> 
> Best wishes,
> 

Looking forward to seeing updated results on lintian.debian.org. :)

Thanks,
~Niels

Bug#889637: [Pkg-mailman-hackers] Bug#889637: mailman: please make the build reproducible

[Uwe Kleine-König]

Hallo Thijs,

On Wed, Feb 07, 2018 at 09:27:06AM +0100, Thijs Kinkhorst wrote:
> On Mon, February 5, 2018 09:50, Chris Lamb wrote:
> > Whilst working on the Reproducible Builds effort [0], we noticed
> > that mailman could not be built reproducibly as it includes
> > a time/timezone/locale-varying timestamp .
> 
> Thanks! Applied and will be part of the next upload.

I looked at mailman.git[1] to debug a problem I have with mailman and
noticed that in commit edea5c2c8b9ac4d3616ed640a70d511ace26c6e5 you
added "92_reproducible_build.patch" to debian/patches/series, but this
file wasn't added. Obviously this makes the package FTBFS.

Best regards
Uwe

[1] https://salsa.debian.org/mailman-team/mailman2.git


signature.asc
Description: PGP signature

Bug#895150: cinnamon-screensaver-command: Crashes and hangs when unable to grab the keyboard/mouse

[Luís Picciochi Oliveira]

Package: cinnamon-screensaver
Version: 3.6.1-2
Severity: important

Dear Maintainer,

I use cinnamon-screensaver-command to automatically lock my screen from a
custom script I created.
I found out that if cinnamon-screensaver-command crashes, it never returns,
making my script unable to proceed.

Here's a way to reproduce the issue:

Run the following in for example, a gnome-terminal:
$ sleep 10 ; echo "locking..." ; cinnamon-screensaver-command -l ; echo "Should
do something else now."

Before you see "locking..." in the console, click "File" in the terminal's
window or some other window.

After the 10 seconds, I notice the window losing focus in what seems to be
cinnamon-screensaver-command trying to lock the screen.

After some more seconds, I get the following stack trace in the terminal:

Traceback (most recent call last):
  File "/usr/share/cinnamon-screensaver/cinnamon-screensaver-command.py", line
73, in on_client_ready
self.perform_action()
  File "/usr/share/cinnamon-screensaver/cinnamon-screensaver-command.py", line
90, in perform_action
self.client.proxy.call_lock_sync(self.message)
GLib.Error: g-io-error-quark: Timeout was reached (24)

The last echo is never printed and you'll have to press Ctrl+C to exit.

I see the following in cinnamon-screensaver's log:

.

couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse

.


Note that this issue is about the behaviour of cinnamon-screensaver-command
after a crash: because it does not return, calling scripts are unable to tell
there was a failure and deal with it (even if by just retrying later).
Can we make cinnamon-screensaver-command return with an error code instead of
hanging in cases like this?

Please see #895149 for the security implications I see on the behaviour for
cinnamon-screensaver that originally triggered this specific crash.


Thanks and best regards,
Luís Picciochi Oliveira



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

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

Versions of packages cinnamon-screensaver depends on:
ii  cinnamon-desktop-data   3.6.2-2
ii  gir1.2-accountsservice-1.0  0.6.45-1
ii  gir1.2-cinnamondesktop-3.0  3.6.2-2
ii  gir1.2-gkbd-3.0 3.26.0-3
ii  gir1.2-glib-2.0 1.56.0-2
ii  gir1.2-gtk-3.0  3.22.29-2
ii  gir1.2-xapp-1.0 1.0.4-2
ii  iso-flags-png-320x240   1.0.1-1
ii  libc6   2.27-3
ii  libcscreensaver03.6.1-2
ii  libglib2.0-02.56.0-4
ii  libgtk-3-0  3.22.29-2
ii  python3 3.6.4-1
ii  python3-gi  3.28.1-1
ii  python3-gi-cairo3.28.1-1
ii  python3-setproctitle1.1.10-1+b1
ii  python3-xapp1.0.1-1
ii  python3-xlib0.20-3

Versions of packages cinnamon-screensaver recommends:
pn  cinnamon-screensaver-x-plugin  

Versions of packages cinnamon-screensaver suggests:
pn  cinnamon-screensaver-webkit-plugin  

-- no debconf information

Bug#892066: ruby-crb-blast FTBFS: test failures

[Adrian Bunk]

On Sun, Mar 04, 2018 at 10:35:15PM +0200, Adrian Bunk wrote:
> Source: ruby-crb-blast
> Version: 0.6.9-1
> Severity: serious
> 
> https://buildd.debian.org/status/fetch.php?pkg=ruby-crb-blast&arch=all&ver=0.6.9-1&stamp=1520009847&raw=0
> 
> ...
> ┌──┐
> │ Run tests for ruby2.3 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/<>/debian/ruby-crb-blast/usr/lib/ruby/vendor_ruby:. 
> GEM_PATH=debian/ruby-crb-blast/usr/share/rubygems-integration/all:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
>  ruby2.3 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby2.3 -w -I"test"  
> "/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/test_test.rb" 
> "test/test_bin.rb" "test/test_test.rb" "test/test_test2.rb" 
> "test/test_test3.rb" -v
> /<>/debian/ruby-crb-blast/usr/lib/ruby/vendor_ruby/crb-blast/crb-blast.rb:348:
>  warning: shadowing outer local variable - name
> /<>/debian/ruby-crb-blast/usr/lib/ruby/vendor_ruby/crb-blast/crb-blast.rb:348:
>  warning: shadowing outer local variable - seq
> /usr/lib/ruby/vendor_ruby/fixwhich.rb:3: warning: assigned but unused 
> variable - e
> /usr/lib/ruby/vendor_ruby/threach.rb:7: warning: `*' interpreted as argument 
> prefix
> /usr/lib/ruby/vendor_ruby/threach.rb:13: warning: shadowing outer local 
> variable - i
> /<>/test/test_test3.rb:28: warning: assigned but unused variable 
> - blaster
> /<>/test/test_test3.rb:44: warning: assigned but unused variable 
> - dbs
> /<>/test/test_test3.rb:45: warning: assigned but unused variable 
> - run
> /<>/test/test_test3.rb:46: warning: assigned but unused variable 
> - load
> Loaded suite /usr/lib/ruby/vendor_ruby/rake/rake_test_loader
> Started
> Test2CRBBlast: 
>   test: crb-blast should add secondary hits. :E
> ===
> Error: test: crb-blast should add secondary hits. (Test2CRBBlast):
>   RuntimeError: BLAST Error:
>   USAGE
> blastn [-h] [-help] [-import_search_strategy filename]
>   [-export_search_strategy filename] [-task task_name] [-db database_name]
>   [-dbsize num_letters] [-gilist filename] [-seqidlist filename]
>   [-negative_gilist filename] [-negative_seqidlist filename]
>   [-entrez_query entrez_query] [-db_soft_mask filtering_algorithm]
>   [-db_hard_mask filtering_algorithm] [-subject subject_input_file]
>   [-subject_loc range] [-query input_file] [-out output_file]
>   [-evalue evalue] [-word_size int_value] [-gapopen open_penalty]
>   [-gapextend extend_penalty] [-perc_identity float_value]
>   [-qcov_hsp_perc float_value] [-max_hsps int_value]
>   [-xdrop_ungap float_value] [-xdrop_gap float_value]
>   [-xdrop_gap_final float_value] [-searchsp int_value]
>   [-sum_stats bool_value] [-penalty penalty] [-reward reward] [-no_greedy]
>   [-min_raw_gapped_score int_value] [-template_type type]
>   [-template_length int_value] [-dust DUST_options]
>   [-filtering_db filtering_database]
>   [-window_masker_taxid window_masker_taxid]
>   [-window_masker_db window_masker_db] [-soft_masking soft_masking]
>   [-ungapped] [-culling_limit int_value] [-best_hit_overhang float_value]
>   [-best_hit_score_edge float_value] [-window_size int_value]
>   [-off_diagonal_range int_value] [-use_index boolean] [-index_name 
> string]
>   [-lcase_masking] [-query_loc range] [-strand strand] [-parse_deflines]
>   [-outfmt format] [-show_gis] [-num_descriptions int_value]
>   [-num_alignments int_value] [-line_length line_length] [-html]
>   [-max_target_seqs num_sequences] [-num_threads int_value] [-remote]
>   [-version]
>   
>   DESCRIPTION
>  Nucleotide-Nucleotide BLAST 2.7.1+

I omitted the relevant part of the log in the following lines:


  Use '-help' to print detailed descriptions of command line arguments
  

  
  Error: Argument "num_threads". Illegal value, expected (>=1 and =<4):  `6'
  Error:  (CArgException::eConstraint) Argument "num_threads". Illegal value, 
expected (>=1 and =<4):  `6'
/<>/debian/ruby-crb-blast/usr/lib/ruby/vendor_ruby/crb-blast/crb-blast.rb:214:in
 `run_blast_with_threads'
/<>/debian/ruby-crb-blast/usr/lib/ruby/vendor_ruby/crb-blast/crb-blast.rb:173:in
 `run_blast'
/<>/test/test_test.rb:14:in `block (2 levels) in 
'
===


cu
Adrian

-- 

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

Bug#859461: xterm: seperate package for resize would be nice

[Uwe Kleine-König]

Hello Julien,

On 03/27/2018 11:16 PM, Julien Cristau wrote:
> Control: tag -1 - patch
> 
> On Fri, Mar 23, 2018 at 14:21:01 +0100, Uwe Kleine-König wrote:
> 
>> Control: tag 859461 + patch
>>
>> Hello,
>>
>> On Mon, Apr 03, 2017 at 01:49:32PM -0600, ben hildred wrote:
>>> Which brings me to my request, split resize into a seprate package and 
>>> depend
>>> on it to preserve existing functionality while allowing headless machines to
>>> install just resize.
>> I could make use of this, too. Here is a patch:
>>
> I'm not convinced this split is a good idea.  But:
> 
>> diff --git a/debian/control b/debian/control
>> index 711d5d9b54f2..50d7217da720 100644
>> --- a/debian/control
>> +++ b/debian/control
>> @@ -141,3 +142,13 @@ Description: X terminal emulator
>>   .
>>   Those interested in using koi8rxterm will likely want to install the
>>   xfonts-cyrillic package as well.
>> +
>> +Package: resize
> 
> This isn't a good package name.  It's too generic.

Fair enough. What do you think about termresize? Should the binary be
renamed then, too? (I'd say no.)

>> +Architecture: any
>> +Multi-Arch: foreign
>> +Depends:
>> + ${shlibs:Depends},
>> + ${misc:Depends},
> 
> As-is, this would break upgrades, as it's missing Breaks/Replaces
> against xterm.

Right you are. I can address this after the naming question is resolved.

Best regards
Uwe



signature.asc
Description: OpenPGP digital signature

Bug#895149: cinnamon-screensaver: Fails to lock the screen if a menu is selected

[Luís Picciochi Oliveira]

Package: cinnamon-screensaver
Version: 3.6.1-2
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

I found that cinnamon-screensaver does not start if a window menu is clicked.
This can be a security problem as users unaware of this can leave their
computer unlocked unwillingly if they clicked a menu before abandoning or
trusting that their computer will be locked.

To reproduce this, just click the "File" menu in a window. For example, gnome-
terminal's "File" menu.

Starting cinnamon-screensaver in a terminal and looking at its log, I see the
following when the screensaver tries to start:



couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab keyboard
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
couldn't grab mouse
Can't fade in screensaver, unable to grab the keyboard

.

If I unselect the "File" menu and wait for the screensaver to trigger again, it
is then able to do it.

I'm reporting this as a security issue but I understand having this exploited
is somewhat unlikely: it would require the attacker to somehow make (or wait
for) the victim to click a menu and ensuring that he leaves his computer
unlocked and unattended without noticing the screen lock was not triggered.

Thanks and best regards,
Luís Picciochi Oliveira



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

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

Versions of packages cinnamon-screensaver depends on:
ii  cinnamon-desktop-data   3.6.2-2
ii  gir1.2-accountsservice-1.0  0.6.45-1
ii  gir1.2-cinnamondesktop-3.0  3.6.2-2
ii  gir1.2-gkbd-3.0 3.26.0-3
ii  gir1.2-glib-2.0 1.56.0-2
ii  gir1.2-gtk-3.0  3.22.29-2
ii  gir1.2-xapp-1.0 1.0.4-2
ii  iso-flags-png-320x240   1.0.1-1
ii  libc6   2.27-3
ii  libcscreensaver03.6.1-2
ii  libglib2.0-02.56.0-4
ii  libgtk-3-0  3.22.29-2
ii  python3 3.6.4-1
ii  python3-gi  3.28.1-1
ii  python3-gi-cairo3.28.1-1
ii  python3-setproctitle1.1.10-1+b1
ii  python3-xapp1.0.1-1
ii  python3-xlib0.20-3

Versions of packages cinnamon-screensaver recommends:
pn  cinnamon-screensaver-x-plugin  

Versions of packages cinnamon-screensaver suggests:
pn  cinnamon-screensaver-webkit-plugin  

-- no debconf information

Bug#895147: firefox: Safe Browsing updates fail due to insufficient quota on the Google API key

[Francois Marier]

Package: firefox
Version: 59.0.2-1
Severity: important
Tags: security

After enabling browser.safebrowsing.debug in about:config, I saw this on my
terminal:

  listmanager: 17:45:17 GMT+ (UTC): download error for 
goog-phish-proto,goog-malware-proto,goog-unwanted-proto,goog-badbinurl-proto,goog-downloadwhite-proto,goog-passwordwhite-proto:
 429

"429 Too Many Requests" is given by the Safe Browsing server when API quota
has been exceeded.

Note that I started Firefox in the morning (Pacific time) and the API quota
is already gone. That means that for a good chunk of each day, Debian users
are essentially running with Safe Browsing disabled.

Fixing this is simple:

1. register for a new Google API key for Safe Browsing on 
https://developers.google.com/
2. email me (franc...@mozilla.com) the Project ID (not the API key)

Google will be happy to increase the quota to a suitable amount.

Francois

-- 
https://fmarier.org/

Bug#895148: nm.debian.org: RT wrong ticket template used for dm_ga

[Mattia Rizzolo]

Package: nm.debian.org

Today I went to approve https://nm.debian.org/process/472 (a dm_ga
proces) and the website provided me with this template:

|Hi
|
|Please create a porter account for Tim Lunn (currently a DM).
|
|  First name:   Tim
|  Middle name:  -
|  Last name:Lunn
|  Key fingerprint:  0E0880479A6F1063372395275B39C0A1153ACABA
|  Current status:   Debian Maintainer
|  Target keyring:   Debian Maintainer, with guest account
|  Username: darkxst
|  Forward email:t...@feathertop.org
|  Details:  https://nm.debian.org/process/472
|
|Tim Lunn has accepted the DMUP in a signed statement.
|
|Details from darkxst
|
|  I recently uploaded librsvg to experimental, it failed to build on a
|  number of arches. I would like to request access to porter boxes so I can
|  investigate and collect more detailed logs (for test failures) to file
|  upstream bug reports.
|  To start with request arch's are arm64, ppc64el and s390x.
|  https://buildd.debian.org/status/package.php?p=librsvg&suite=experimental
|
|
|--
|Thank you,
|
|Mattia Rizzolo (as DAM)

Issues:
* it didn't seem to use the template that I can see in
  public/templates/public/process-ga-rt.html where would more useful
  details:
  - access period
  - hosts/archs
* it has a "Target keyring" that doesn't make sense for this request
* it hardcoded "DAM" in the signature: it should either stick to FD (as
  that's the access level required) or pick either one according to who
  processes the request

OTOH the template at public/templates/public/process-ga-rt.html (other
than hard coding "DAM") lack some info that are in this template, like:
 - current status (ok, it's in the heading, but …)
 - details


I can't imagine what happened that apparently mixed up the templates (?!
I'm probably missing something important..) but probably the duplication
should be avoided.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#890873: lintian: gcc-8-cross-ports makes lintian fork-bomb, consume all memory and fill the disk

[Chris Lamb]

Hi Niels,

> I do not remember if you can use $foo->{'bar'} in a string
> interpolation, but I guess are about to find out. :)

  $ cat test.pl
  use strict;
  my $foo = { 'bar' => 'Yes.' };
  print "Can we use \$foo->{'bar'} in a string interpolation? $foo->{'bar'}\n";

  $ perl test.pl
  Can we use $foo->{'bar'} in a string interpolation? Yes.

TIL :)

> Thanks, looks good to me with a quick review.

I'll give it a whirl!
 

Best wishes,

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

Bug#887666: jh_linkjars: Invalid option: N

[Niels Thykier]

On Thu, 18 Jan 2018 21:48:00 + Niels Thykier  wrote:
> Control: reassign -1 javahelper
> 
> On Thu, 18 Jan 2018 23:41:19 +0200 Adrian Bunk  wrote:
> > Package: debhelper
> > Version: 11.1.2
> > Severity: serious
> > Control: affects -1 javahelper src:zabbix
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/zabbix.html
> > 
> > ...
> >jh_linkjars -O--max-parallel=4 -Nzabbix-frontend-php 
> > -Nzabbix-java-gateway
> > Invalid option: N
> > Usage: jh_linkjars [options] [target] 
> > Options:
> > -h --help: show this text
> > -V --version: show the version
> > -v --verbose: show more information while running
> > -t --transitive: transitively link jars
> > -n --no-act: don't actually do anything, just print the results
> > -u --unlink: remove the links instead of adding them
> > debian/rules:77: recipe for target 'binary' failed
> > make: *** [binary] Error 1
> > 
> > 
> > Works after downgrading to debhelper 11
> > 
> > 
> 
> 
> The -N option is a basic "shared" debhelper option required by any
> dh-like tool added to the debhelper sequence (similar to -p/-s/-i).  The
> solution here is to have javahelper support that option.
> 
> Thanks,
> ~Niels
> 
> 
> 

Hi,

I have written some patches to rewrite most of the javatools helpers
into perl using Debhelper's Dh_Lib[1].  This would fix this problem and
avoid future instances of it.

While the patches do include jh_linkjars, I doubt that the bug will be
fixed until jh_build and jh_depends have also been rewritten.
Therefore, I am not tagging this bug with "patch".

Thanks,
~Niels

[1] The 0001 patch is strictly unrelated but avoids relying (fake)root
when building the package.
>From bf05b0189e84660fae137060931a490ab58d0fa2 Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sat, 7 Apr 2018 14:43:21 +
Subject: [PATCH 1/6] javatools can be built without (fake)root

Signed-off-by: Niels Thykier 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index c127665..6616958 100644
--- a/debian/control
+++ b/debian/control
@@ -12,6 +12,7 @@ Build-Depends:
  libtest-strict-perl,
  markdown,
  perl
+Rules-Requires-Root: no
 Standards-Version: 4.1.3
 Vcs-Git: https://anonscm.debian.org/git/pkg-java/javatools.git
 Vcs-Browser: https://anonscm.debian.org/cgit/pkg-java/javatools.git
-- 
2.16.3

>From 4f6064fa0e380e8b8f50b16e8852987431f1776f Mon Sep 17 00:00:00 2001
From: Niels Thykier 
Date: Sat, 7 Apr 2018 15:05:06 +
Subject: [PATCH 2/6] Rewrite jh_classpath using Debhelper's Dh_Lib

Signed-off-by: Niels Thykier 
---
 debian/javahelper.manpages |   1 -
 debian/rules   |   1 +
 jh_classpath   | 221 +++--
 jh_classpath.1 |  30 --
 t/strict.t |   1 +
 5 files changed, 135 insertions(+), 119 deletions(-)
 delete mode 100644 jh_classpath.1

diff --git a/debian/javahelper.manpages b/debian/javahelper.manpages
index 8527947..6f02dc7 100644
--- a/debian/javahelper.manpages
+++ b/debian/javahelper.manpages
@@ -1,5 +1,4 @@
 jh_build.1
-jh_classpath.1
 jh_depends.1
 jh_exec.1
 jh_installjavadoc.1
diff --git a/debian/rules b/debian/rules
index 703676a..600be8f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,6 +20,7 @@ override_dh_auto_build: jh_lib.sh
 	$(POD2MAN) jh_setupenvironment tmp/jh_setupenvironment.1
 	$(POD2MAN) jh_compilefeatures tmp/jh_compilefeatures.1
 	$(POD2MAN) jh_manifest tmp/jh_manifest.1
+	$(POD2MAN) jh_classpath tmp/jh_classpath.1
 	$(POD2MAN) fetch-eclipse-source.pod tmp/fetch-eclipse-source.1
 	$(POD2MAN) -s 1 jh_clean.pod tmp/jh_clean.1
 	$(POD2MAN) $(MOD_PATH)/Eclipse.pm tmp/Debian::Javahelper::Eclipse.3
diff --git a/jh_classpath b/jh_classpath
index 3024f98..5aa61f2 100755
--- a/jh_classpath
+++ b/jh_classpath
@@ -1,94 +1,139 @@
-#!/bin/bash --
-
-set -e
-
-. /usr/share/javahelper/jh_lib.sh
-
-syntax()
-{
-   echo -e "Usage: jh_classpath [options] [jar(s)]"
-   echo -e "Options:"
-   echo -e "\t-h --help: show this text"
-   echo -e "\t-V --version: show the version"
-   echo -e "\t-i --indep: act on all Arch: all packages"
-   echo -e "\t-a --arch: act on all Arch-specific packages"
-   echo -e "\t-s --same-arch: alias of --arch for compatibility with debhelper"
-   echo -e "\t-p --package=: package to act on (default=all)"
-   echo -e "\t-P --tmpdir=: package directory (default=\$CWD/debian/package)"
-   echo -e "\t-c --classpath=: The classpath to set on the jar(s)"
-   echo -e "\t-v --verbose: show more information while running"
-   echo -e "\t-n --no-act: don't actually do anything, just print the results"
-   exit 1
-}
+#!/usr/bin/perl
 
-ARGS="i indep a arch s same-arch p package P tmpdir v verbose n no-act c classpath" parseargs "$@"
+=head1 NAME
 
-dh_testdir
+jh_classpath - sets classpaths in jar files
 
-VERBOSE="`getarg v verbose`"
-NOACT="`getarg n noact`"
+=cut
 
-if [ "$ARGC" == "0" ]; then
-	# read debian/$package.classpath
-	for p

Bug#895091: openldap: Please replace 'c_rehash' with 'openssl rehash'

[Ryan Tandy]

Control: severity -1 minor
Control: tag -1 = upstream

Hello Sebastian,

On Sat, Apr 07, 2018 at 12:48:23AM +0200, Sebastian Andrzej Siewior wrote:

This package is using the c_rehash command which is part of the
openssl package.


As far as I can tell, c_rehash is only referenced in the documentation, 
not used in code. Therefore I consider this a minor issue and I will 
forward it upstream to update the doc to use the new command.


thanks,
Ryan

Bug#894853: SDL or GTK update

[Jesse Smith]

The issue here, whether using GTK or SDL, is Sopwith uses old versions
of these libraries. SDL 1.2 and GTK 2 (probably). Neither of those
libraries maintain backward compatibility. Both were pretty much
designed to make application developers re-write large chunks of code.

So the way forward is, ideally, to port Sopwith to SDL 2 (the GTK port
was dropped years ago as being basically unmaintainable). The trick is
someone needs to find enough time to learn the newer SDL 2 library and
re-write the Sopwith code to match.

I might end up doing this, but it's way down my priority list at the
moment, especially since the current version still runs okay in most
environments.

In short: the fix is conceptually easy (re-write for SDL 2), it's just
going to be time consuming.

Bug#890873: lintian: gcc-8-cross-ports makes lintian fork-bomb, consume all memory and fill the disk

[Niels Thykier]

Chris Lamb:
> Hi Niels,
> 
>> Thanks for having a look at this.
> 
> Thanks for the review. I've updated my patch here:
> 
>   
> https://gist.githubusercontent.com/lamby/996d85ac0e6ba0a18af2758e79912299/raw
> 
>> I have one design concern; I think the blacklist should be global
>> not per archive.
> 
> ACK, updated.
> 
>> On the more minor side of things, I would have liked to see lintian
>> still record the packages that are blacklisted.
> 
> In lieu of marking them as such on the reports, I've made it spit out log
> messages when it skips something. (For the offending packages, it will at
> least still show "processed with Lintian $very_old_version" so it should
> not be /too/ magic.)
> 
> 
>> We will probably want to map the blacklist into a hashref so we can do
>> O(1) testing to see if a source is blacklisted if the blacklist grows
>> more than a handful of packages.
> 
> I hope this is unnecessary too (!), but I'm a bit stubborn so have
> implemented it regardless.
> 
> Looking forward to your feedback... :)
> 
> 
> Best wishes,
> 

Thanks, looks good to me with a quick review.

I think we should try that variant and see what breaks. :)  Honestly, I
do not remember if you can use $foo->{'bar'} in a string interpolation,
but I guess are about to find out. :)

Thanks,
~Niels

Bug#886040: Sugar GConf removal patches

[Santiago Ruano Rincón]

Control: tags -1 + pending

On Mon, 2 Apr 2018 11:03:46 +1000 James Cameron  wrote:
> G'day,
> 
> Upstream has landed patches for each of these bugs, and a patch for
> src:python-sugar3 that doesn't have a bug yet.
> 
> for src:sugar #886040 cherry-pick from 38b173d ("jarabe, extensions -
> remove GConf compatibility").
…

Thanks!

Included in
https://salsa.debian.org/pkg-sugar-team/sugar/tree/fix-886040

Cheers,

Santiago

Bug#841845: it's /usr/lib/pkgconfig/tesseract.pc again

[Helmut Grohne]

Control: reopen -1
Control: found -1 4.00~git2219-40f43111-1.2

The tesseract.pc file moved to a non-multiarch location again.

Helmut

Bug#895146: blobwars FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: blobwars
Version: 2.00-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

blobwars fails to cross build from source, because it fails finding sdl
as it uses the build architecture pkg-config. After making pkg-config
substitutable, it cross builds successfully as dh_auto_build substitutes
the right pkg-config. Please consider applying the attached patch.

Helmut
Index: blobwars-2.00/Makefile
===
--- blobwars-2.00.orig/Makefile
+++ blobwars-2.00/Makefile
@@ -18,11 +18,12 @@
 MEDAL_SERVER_HOST = www.parallelrealities.co.uk
 MEDAL_SERVER_PORT = 80
 
-CXXFLAGS += `pkg-config --cflags sdl2 SDL2_mixer SDL2_image SDL2_ttf SDL2_net` -DVERSION=$(VERSION) -DRELEASE=$(RELEASE) -DUSEPAK=$(USEPAK)
+PKG_CONFIG ?= pkg-config
+CXXFLAGS += `$(PKG_CONFIG) --cflags sdl2 SDL2_mixer SDL2_image SDL2_ttf SDL2_net` -DVERSION=$(VERSION) -DRELEASE=$(RELEASE) -DUSEPAK=$(USEPAK)
 CXXFLAGS += -DPAKNAME=\"$(PAKNAME)\" -DPAKLOCATION=\"$(DATADIR)\" -DUNIX -DGAMEPLAYMANUAL=\"$(DOCDIR)index.html\" -Wall
 CXXFLAGS += -DLOCALEDIR=\"$(LOCALEDIR)\" -DMEDAL_SERVER_HOST=\"$(MEDAL_SERVER_HOST)\" -DMEDAL_SERVER_PORT=$(MEDAL_SERVER_PORT)
 CXXFLAGS += $(CFLAGS) -O2 -g -flto
-LIBS = `pkg-config --libs sdl2 SDL2_mixer SDL2_image SDL2_ttf SDL2_net` -lz
+LIBS = `$(PKG_CONFIG) --libs sdl2 SDL2_mixer SDL2_image SDL2_ttf SDL2_net` -lz
 PAKLIBS = -lz
 
 OBJS += CAudio.o

Bug#853035: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Graham Inggs]

Hi Chris

On 7 April 2018 at 18:22, Chris Lamb  wrote:
> Well, just to be 100% clear, I don't propose increasing the timeout at
> all: I'm pretty hardcode on tests being determinstic so merely increasing
> the wait time feels especially gross to me. :)

Would you please explain your objection to timeouts in tests?

I think it is practical to give up waiting for a response some point.
Even Debian's buildds give up after 150 minutes.

Regards
Graham

Bug#895145: virt-manager: fails to start networks

[Christoph Anton Mitterer]

Package: virt-manager
Version: 1:1.4.3-1
Severity: important


Hi.

Since the most recent upgrade, when I try to start a network from the GUI:
Error starting network 'main': internal error: Failed to initialize a valid 
firewall backend

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb
callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn
ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/network.py", line 81, in start
self._backend.create()
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 2947, in create
if ret == -1: raise libvirtError ('virNetworkCreate() failed', net=self)
libvirtError: internal error: Failed to initialize a valid firewall backend


Cheers,
Chris


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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  gir1.2-gtk-3.0   3.22.29-3
ii  gir1.2-gtk-vnc-2.0   0.7.2-1
ii  gir1.2-libosinfo-1.0 1.1.0-1
ii  gir1.2-libvirt-glib-1.0  1.0.0-1
ii  gir1.2-vte-2.91  0.52.0-1
ii  librsvg2-common  2.40.20-2
ii  python   2.7.14-4
ii  python-dbus  1.2.6-1
ii  python-gi3.28.1-1
ii  python-gi-cairo  3.28.1-1
ii  python-libvirt   4.0.0-1
ii  python-requests  2.18.4-2
ii  python2.72.7.14-8
ii  virtinst 1:1.4.3-1

Versions of packages virt-manager recommends:
ii  gir1.2-spiceclientglib-2.0  0.34-1.1
ii  gir1.2-spiceclientgtk-3.0   0.34-1.1
ii  libvirt-daemon-system   4.2.0-1

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1  0.18.6-1
ii  gnome-keyring3.28.0.2-1
pn  python-guestfs   
pn  ssh-askpass  
pn  virt-viewer  

-- no debconf information

Bug#890873: lintian: gcc-8-cross-ports makes lintian fork-bomb, consume all memory and fill the disk

[Chris Lamb]

Hi Niels,

> Thanks for having a look at this.

Thanks for the review. I've updated my patch here:

  https://gist.githubusercontent.com/lamby/996d85ac0e6ba0a18af2758e79912299/raw

> I have one design concern; I think the blacklist should be global
> not per archive.

ACK, updated.

> On the more minor side of things, I would have liked to see lintian
> still record the packages that are blacklisted.

In lieu of marking them as such on the reports, I've made it spit out log
messages when it skips something. (For the offending packages, it will at
least still show "processed with Lintian $very_old_version" so it should
not be /too/ magic.)


> We will probably want to map the blacklist into a hashref so we can do
> O(1) testing to see if a source is blacklisted if the blacklist grows
> more than a handful of packages.

I hope this is unnecessary too (!), but I'm a bit stubborn so have
implemented it regardless.

Looking forward to your feedback... :)


Best wishes,

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

Bug#884493: 1.8.0 packaged in git

[hexa-]

Thank you, I've been using this package for a while.

Just a heads up, that Babeld 1.8.1 has been released today.

7 April 2018: babeld-1.8.1

  * Implemented parsing of mandatory sub-TLVs and unicast and unscheduled
Hellos.  This makes this version comply with RFC 6126bis.  However, we
don't send any of these yet, so this version remains compatible with
RFC 6126.
  * Fixed a bug that prevented us from sending requests after we lose
a route.  This makes convergence much faster in some cases, at the
cost of slightly increased traffic.
  * Fixed interface addresses on some kinds of point-to-point links.
  * The keep-unfeasible (-u) option has been removed, this is now the
default behaviour.

On Wed, 27 Dec 2017 16:12:48 +0900 Benda Xu  wrote:
> Hi,
> 
> It looks like this package has not been touch upon for almost 2 years.
> I went ahead and committed version 1.8.0 to collab-maint/babeld.
> 
>   https://anonscm.debian.org/git/collab-maint/babeld.git
> 
> The compiled package works smoothly on jessie, stretch and sid.
> 
> Cheers,
> Benda
> 
> 

Bug#851712: Missing 'kea-admin' executable

[Duane Davis]

Package is useless without the executable.

Any chance this will ever be fixed?

Bug#871544: [Qa-jenkins-dev] Bug#871544: jenkins.debian.org: jtx1b runs armhf builds with wrong personality

[Mattia Rizzolo]

Control: tag -1 wontfix
Control: close -1

On Tue, Aug 08, 2017 at 09:36:27PM -0400, James Cowgill wrote:
> I noticed this build of ffmpeg in buster failed on armhf, while the same
> version does build in the unstable version:
> The configure log contains
> > Mon Aug  7 07:36:24 UTC 2017  I: Starting 1st build on remote node 
> > jtx1b-armhf-rb.debian.net.
> [...]
> >  *** standard ***
> > install prefix/usr
> > source path   /build/ffmpeg-3.3.3
> > C compilergcc
> > C library glibc
> > ARCH  aarch64 (generic)
> 
> While I don't know for certain, my guess is that this is an aarch64
> machine doing armhf builds, and the personality in the chroot has not
> been set correctly for armhf. I don't know if pbuilder has this ability
> (I know schroot does), but if not then you could use "setarch linux32"
> instead.

That's the case indeed, and afaik it's not the only case.
I talked a bit with my peers, and there is a consensus on our side that
thing should not be relying on `uname` to detect the host architecture.
Indeed before the stretch release we were actively testing varying
kernel on the i386 builds by using an amd64 kernel and filed bugs for
them.

Please make your package not rely on uname.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#895144: jessie-pu: package sam2p/0.49.2-3+deb8u1

[Markus Koschany]

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

Hello,

I would like to update sam2p in Jessie. This package is currently
affected by several security vulnerabilities. Please find attached the
debdiff.

Regards,

Markus
diff -Nru sam2p-0.49.2/debian/changelog sam2p-0.49.2/debian/changelog
--- sam2p-0.49.2/debian/changelog   2017-11-22 21:39:20.0 +0100
+++ sam2p-0.49.2/debian/changelog   2018-04-07 17:48:42.0 +0200
@@ -1,3 +1,13 @@
+sam2p (0.49.2-3+deb8u2) jessie; urgency=high
+
+  * Non-maintainer upload.
+  * Fix CVE-2018-7487, CVE-2018-7551, CVE-2018-7552, CVE-2018-7553 and
+CVE-2018-7554. Multiple invalid frees and buffer-overflow vulnerabilities
+were discovered in sam2p that may lead to a denial-of-service (application
+crash) or unspecified other impact.
+
+ -- Markus Koschany   Sat, 07 Apr 2018 17:48:42 +0200
+
 sam2p (0.49.2-3+deb8u1) jessie; urgency=high
 
   * Non-maintainer upload.
diff -Nru sam2p-0.49.2/debian/patches/CVE-2018-7487.patch 
sam2p-0.49.2/debian/patches/CVE-2018-7487.patch
--- sam2p-0.49.2/debian/patches/CVE-2018-7487.patch 1970-01-01 
01:00:00.0 +0100
+++ sam2p-0.49.2/debian/patches/CVE-2018-7487.patch 2018-04-07 
17:48:42.0 +0200
@@ -0,0 +1,22 @@
+From: Markus Koschany 
+Date: Wed, 4 Apr 2018 22:58:32 +0200
+Subject: CVE-2018-7487
+
+Bug-Upstream: https://github.com/pts/sam2p/issues/18
+---
+ in_pcx.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/in_pcx.cpp b/in_pcx.cpp
+index f04e4c1..e8e1ce1 100644
+--- a/in_pcx.cpp
 b/in_pcx.cpp
+@@ -239,7 +239,7 @@ static Image::Sampled *LoadPCX
+ if (fread(pinfo->pal, 1, colors*3, fp) != colors * 3 + 0U ||
+ ferror(fp) || feof(fp)) {
+   pcxError(bname,"Error reading PCX colormap.  Using grayscale.");
+-  for (i=0; i<256; i++) PAL_R(pinfo,i) = PAL_G(pinfo,i) = PAL_B(pinfo,i) 
= i;
++  for (i=0; i
+Date: Thu, 5 Apr 2018 11:02:16 +0200
+Subject: CVE-2018-7551
+
+Bug-Upstream: https://github.com/pts/sam2p/issues/28
+Origin: 
https://github.com/pts/sam2p/commit/a6621e996f976912252018be8a8836ee6a966ee3
+---
+ input-pnm.ci | 24 ++--
+ 1 file changed, 18 insertions(+), 6 deletions(-)
+
+diff --git a/input-pnm.ci b/input-pnm.ci
+index 1645071..033a8ca 100644
+--- a/input-pnm.ci
 b/input-pnm.ci
+@@ -177,6 +177,18 @@ static struct struct_pnm_types
+   {  0 , 0, 0,   0, NULL}
+ };
+ 
++static slen_t multiply_check(slen_t a, slen_t b) {
++  slen_t result;
++  if (a == 0) return 0;
++  /* Check for overflow. Works only if everything is unsigned. */
++  if ((result = a * b) / a != b) FATALP("PNM: can't open file\n");
++  return result;
++}
++
++static slen_t multiply_check(slen_t a, slen_t b, slen_t c) {
++  return multiply_check(multiply_check(a, b), c);
++}
++
+ #if PTS_SAM2P
+ bitmap_type pnm_load_image (FILEE* filename)
+ #else
+@@ -265,8 +277,8 @@ bitmap_type pnm_load_image (at_string filename)
+   BITMAP_HEIGHT (bitmap) = (at_dimen_t) pnminfo->yres;
+ 
+   BITMAP_PLANES (bitmap) = (pnminfo->np)?(pnminfo->np):1;
+-  /* BITMAP_BITS (bitmap) = (unsigned char *) malloc (pnminfo->yres * 
pnminfo->xres * BITMAP_PLANES (bitmap)); */
+-  XMALLOCT(BITMAP_BITS (bitmap), unsigned char *, pnminfo->yres * 
pnminfo->xres * BITMAP_PLANES (bitmap));
++  /* BITMAP_BITS (bitmap) = (unsigned char *) malloc ((slen_t)pnminfo->yres * 
pnminfo->xres * BITMAP_PLANES (bitmap)); */
++  XMALLOCT(BITMAP_BITS (bitmap), unsigned char *, 
multiply_check(pnminfo->yres, pnminfo->xres, BITMAP_PLANES (bitmap)));
+   pnminfo->loader (scan, pnminfo, BITMAP_BITS (bitmap));
+   /* vvv Dat: We detect truncation late truncated files will just have 
garbage :-( */
+   if (pnmscanner_eof(scan))
+@@ -299,7 +311,7 @@ pnm_load_ascii (PNMScanner *scan,
+   #endif
+   d = data;
+   if (info->np==0) { /* PBM */
+-dend=d+info->xres*info->yres;
++dend=d+(slen_t)info->xres*info->yres;
+ while (d!=dend) {
+   /* pnmscanner_getsmalltoken(scan, (unsigned char *)buf); */
+   pnmscanner_eatwhitespace(scan);
+@@ -307,7 +319,7 @@ pnm_load_ascii (PNMScanner *scan,
+   pnmscanner_getchar(scan);
+ }
+   } else { /* PGM or PPM */ / pts /
+-dend=d+info->xres*info->yres*info->np;
++dend=d+(slen_t)info->xres*info->yres*info->np;
+ switch (s=info->maxval) {
+  case 255:
+   while (d!=dend) {
+@@ -350,10 +362,10 @@ pnm_load_raw (PNMScanner *scan,
+ 
+   scanlines = info->yres;
+   d = data;
+-  delta=info->xres * info->np;
++  delta=(slen_t)info->xres * info->np;
+   dend=d+delta*scanlines;
+   while (d!=dend) {
+-if (info->xres*info->np != fread_FILEE((char*)d, delta, fd)) return;
++if (delta != fread_FILEE((char*)d, delta, fd)) return;
+ d+=delta;
+   }
+   d=data;
diff -Nru sam2p-0.49.2/debian/patches/CVE-2018-7553.patch 
sam2p-0.49.2/debian/patches/CVE-2018-7553.patch
--- sam2p-0.49.2/debian/patches/CVE-2018-7553.patch 1970-01-01 
01:00:

Bug#881626: busybox: enable telnetd

[Luca Boccassi]

On Mon, 13 Nov 2017 17:16:26 + Luca Boccassi 
wrote:
> Package: busybox
> Version: 1.27.2-1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainers,
> 
> Please consider enabling telnetd in the busybox package. A tiny and
> trivial patch to set the config is attached inline. A rebuild with
that
> change seems to work fine.
> 
> As much as I wish it wasn't the case, telnet is still widely used,
> especially in the ISP/telco world. Telcos networking engineers expect
> to be able to telnet into boxes in their network even today.
> 
> Having telnetd available without having to rebuild busybox would be
> extremely handy when using Debian (or derivatives) in small boxes
(eg:
> arm64) inside a telecommunication provider's network.
> 
> Thanks!
> 
> -- 
> Kind regards,
> Luca Boccassi
> 
> 
> From b9a2c82b4120a698b6350c7550f5286008892f2c Mon Sep 17 00:00:00
2001
> From: Luca Boccassi 
> Date: Mon, 13 Nov 2017 17:05:12 +
> Subject: [PATCH] Enable telnetd
> 
> ---
>  debian/config/pkg/deb | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/debian/config/pkg/deb b/debian/config/pkg/deb
> index 290205d99..73428dc5b 100644
> --- a/debian/config/pkg/deb
> +++ b/debian/config/pkg/deb
> @@ -903,8 +903,8 @@ CONFIG_TELNET=y
>  CONFIG_FEATURE_TELNET_TTYPE=y
>  CONFIG_FEATURE_TELNET_AUTOLOGIN=y
>  CONFIG_FEATURE_TELNET_WIDTH=y
> -# CONFIG_TELNETD is not set
> -# CONFIG_FEATURE_TELNETD_STANDALONE is not set
> +CONFIG_TELNETD=y
> +CONFIG_FEATURE_TELNETD_STANDALONE=y
>  # CONFIG_FEATURE_TELNETD_INETD_WAIT is not set
>  CONFIG_TFTP=y
>  # CONFIG_TFTPD is not set
> -- 
> 2.11.0

Dear Maintainers,

Any chance this patch could be looked at? 
It would really help those of us in the networking world using Debian,
and would make no difference for anybody else as there's no
service/init script to start the daemon automatically.

Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#895143: corekeeper: simplify calculation of old core files

[Nathaniel Morck Beaver]

Package: corekeeper
Version: 1.6
Severity: wishlist
Tags: patch

This line:

sort current current next | uniq -u > new

corresponds to this set operation:

new = next - current

and this line:

sort deleted deleted new new next | uniq -u > old

corresponds to this set operation:

old = (next - deleted) - new

by substitution:

old = (next - deleted) - (next - current)

hence:

old = current - deleted

So this line:

sort deleted deleted new new next | uniq -u > old

can be replaced by this line:

sort deleted deleted current | uniq -u > old

which does the same thing more simply and without relying on the 
previously calculated file.


A patch is attached.


Sincerely,

Nathaniel Beaver

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

Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

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

Versions of packages corekeeper depends on:
ii  procps  2:3.3.12-3

corekeeper recommends no packages.

corekeeper suggests no packages.

-- Configuration Files:
/etc/sysctl.d/corekeeper.conf changed [not included]

-- no debconf information
diff --git a/debian/corekeeper.cron.daily b/debian/corekeeper.cron.daily
index 9457927..4c6d4fc 100755
--- a/debian/corekeeper.cron.daily
+++ b/debian/corekeeper.cron.daily
@@ -7,7 +7,7 @@ fi
 cd /var/cache/corekeeper/
 find /var/crash -name '*.core' \( \( -mtime +7 -delete -fprint /dev/stderr \) -o \( -print \) \) > next 2> deleted
 sort current current next | uniq -u > new
-sort deleted deleted new new next | uniq -u > old
+sort deleted deleted current | uniq -u > old
 
 if [ -s new ] ; then
 	echo 'New core file(s):'

Bug#895074: debian-installer: Please replace 'c_rehash' with 'openssl rehash'

[Cyril Brulebois]

Control: tag -1 patch pending

Hi Sebastian,

Sebastian Andrzej Siewior  (2018-04-07):
> Source: debian-installer
> Version: 20171204
> Severity: normal
> Tags: sid buster
> User: pkg-openssl-de...@lists.alioth.debian.org
> Usertags: c_rehash
> 
> This package is using the c_rehash command which is part of the
> openssl package. The c_rehash script is considered by upstream as a
> fallback script and will disappear at some point. The recommended way
> is to use the "openssl rehash" command instead which appeared in
> 1.1.0. Please make sure that this package does not use the c_rehash
> command anymore.
> 
> The "openssl rehash" command creates half that many symlinks (one per
> certificate instead of two) because it uses only the newer hash.
> There is also the -compat option which creates both symlinks (and
> behaves like c_rehash currently does). The hash changed from md5 to
> sha1 during the 0.9.8 to 1.0.0 transition so I doubt that the
> "compat" mode will be required.
> 
> Should the c_rehash script be mentioned in the source code or script
> of this package but is not used during the build process or in the
> final package then feel free to close the bug saying so.

Thanks for the notice, implemented in git:
  
https://anonscm.debian.org/cgit/d-i/debian-installer.git/commit/?id=8dd58ee8d229a28280c07d955162c94ebba35a75


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#895142: libevent-dev: Please transition libevent-dev to multiarch

[F. Poirotte]

Package: libevent-dev
Version: 2.0.21-stable-3
Severity: normal

Dear Maintainer,

While bug #675320 added support for multi-arch for the main packages, it seems
the development package was overlooked. As such, it is not currently possible to
install the dev package for multiple architectures (eg. amd64 and i386) at the
same time.

Trying to co-install multiple variants results in apt-get/aptitude trying to 
first
remove previously installed packages. Here's the trace when trying to install
the i386 variant on a system where the amd64 variant is already installed:

$ sudo aptitude install libevent-dev:i386
The following NEW packages will be installed:
  libevent-core-2.0-5:i386{a} libevent-dev:i386{b} libevent-extra-2.0-5:i386{a} 
libevent-openssl-2.0-5:i386{a} libevent-pthreads-2.0-5:i386{a} 
0 packages upgraded, 5 newly installed, 0 to remove and 2 not upgraded.
Need to get 569 kB of archives. After unpacking 1,971 kB will be used.
The following packages have unmet dependencies:
 libevent-dev : Conflicts: libevent-dev:i386 but 2.0.21-stable-3 is to be 
installed
 libevent-dev:i386 : Conflicts: libevent-dev but 2.0.21-stable-3 is installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) libevent-dev [2.0.21-stable-3 (now, stable)]


Accept this solution? [Y/n/q/?] q


I checked the control file in testing/sid (libevent-2.1-6 (2.1.8-stable-4))
and the problem is also visible there.

Best regards,
François


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

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

Versions of packages libevent-dev depends on:
ii  libevent-2.0-5   2.0.21-stable-3
ii  libevent-core-2.0-5  2.0.21-stable-3
ii  libevent-extra-2.0-5 2.0.21-stable-3
ii  libevent-openssl-2.0-5   2.0.21-stable-3
ii  libevent-pthreads-2.0-5  2.0.21-stable-3

libevent-dev recommends no packages.

libevent-dev suggests no packages.

-- no debconf information

Bug#895141: installation-reports: unable to rotate main screen during installation

[sergio]

Package: installation-reports
Severity: normal

fbcon=rotate:3
or
echo 3 > /sys/class/graphics/fbcon/rotate_all
or
echo 3 > /sys/class/graphics/fb0/rotate
or
echo 3 > /sys/class/graphics/fb1/rotate

doesn't rotate the main screen, only other consoles available by Alt-Fx

This is text installation with KMS.

Bug#853035: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Chris Lamb]

[Resending including 853...@bugs.debian.org in CC this time..]

Hi Graham,

Thanks for the followup.

> Chris, you wrote "...the test would still be unreliable whatever value
> you choose", can you propose something other than increasing the
> timeout?

Well, just to be 100% clear, I don't propose increasing the timeout at
all: I'm pretty hardcode on tests being determinstic so merely increasing
the wait time feels especially gross to me. :)

So, indeed, another solution is really required but alas I'm really not
familiar with this particular test nor this package in general so I would
not be able to comment with any authority.

Have you tried speaking to upstream?


Best wishes,

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

Bug#853035: node-liftoff: Non-determistically FTBFS due to unreliable timing in tests

[Graham Inggs]

Hi

This situation seems to get worse with each new version of nodejs.

In Ubuntu, where autopkgtests are run for every release architecture,
node-liftoff failed on armhf [1] and arm64 [2] since the upload of
nodejs 8.9.3.

We resorted to increasing the timeout from 5000 to 1 in
debian/rules and debian/tests/control to allow nodejs to migrate.

Chris, you wrote "...the test would still be unreliable whatever value
you choose", can you propose something other than increasing the
timeout?

Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/node-liftoff/bionic/armhf
[2] http://autopkgtest.ubuntu.com/packages/node-liftoff/bionic/arm64

Bug#894710: awesome: move out of asciidoc

[Joseph Herlant]

Hi Reiner,


> What is your planned timeline for getting rid of asciidoc?
> Is it sufficient to wait for the next awesome release, or do you want to
> have it already applied to the currently released version?

Asciidoc will be removed on next Debian major release when python2
will be removed so if upstream releases before that, then it's
perfect.

Thanks
Joseph

Bug#895140: nbd-client 1:3.17-2 fails to communicate with nbd-client 1:3.15.2-3

[sergio]

Package: nbd-client
Version: 1:3.17-2
Severity: important

The original bug:

nbd-server before commit 2ab3a2d fails to communicate with nbd-client after 
commit e6b56c1
https://github.com/NetworkBlockDevice/nbd/issues/66

It's already fixed in git. So should be fixed with new version.

Bug#895138: gimp: GIMP 2.10 requires BABL >= 0.1.44 to start

[Jeremy Bicha]

Control: reassign -1 gegl 0.3.30-1
Control: forcemerge 894471 -1

On Sat, Apr 7, 2018 at 9:56 AM, Aurélien COUDERC  wrote:
> GIMP 2.10.0~RC1 installed from experimental fails to start due to outaded 
> BABL.
> Could you please refresh the vesionned dependency to >= 0.1.44 ?

I believe this will be fixed once gegl is re-uploaded and then gimp rebuilt.

Therefore, I am marking this a duplicate of the gegl bug.

Thanks,
Jeremy Bicha

Bug#895129: linux: Battery not detected on Lamina 2-in-1 tablet

[Sebastian Reichel]

Hi,

On Sat, Apr 07, 2018 at 01:04:27PM +0200, Marcus Lundblad wrote:
> Source: linux
> Severity: normal
> 
> Dear Maintainer,
> 
> I have a Lamina T-1016B 2-in-1 tablet where the battery is not detected
> (the top bar in GNOME shows only the power icon, like on the desktop machine).
> Checking in /var/log/messages I could see the following (grep:ing on ACPI):
> 
> Apr  6 09:17:21 eridanus kernel: [5.663167] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 09:17:21 eridanus kernel: [5.956763] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 08:20:24 eridanus kernel: [5.720266] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 08:20:24 eridanus kernel: [6.020086] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 08:23:09 eridanus kernel: [5.656934] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 08:23:09 eridanus kernel: [5.979635] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 08:25:49 eridanus kernel: [5.849791] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> Apr  6 08:25:49 eridanus kernel: [6.150902] ACPI: AC: found native 
> INT33F4 PMIC, not loading
> 
> Checking in the kernel sources, I could see the following:
> In https://github.com/torvalds/linux/blob/master/drivers/acpi/battery.c
> 
> There is a blacklist of ACPI HIDs at line 101:
> 
> /* Lists of PMIC ACPI HIDs with an (often better) native battery driver */
> static const char * const acpi_battery_blacklist[] = {
>   "INT33F4", /* X-Powers AXP288 PMIC */
> };
> 
> Further down there's a section for bailing out on blacklisted HIDs at 1491:
> 
> for (i = 0; i < ARRAY_SIZE(acpi_battery_blacklist); i++)
>   if (acpi_dev_present(acpi_battery_blacklist[i], "1", -1)) {
>   pr_info(PREFIX ACPI_BATTERY_DEVICE_NAME
>   ": found native %s PMIC, not loading\n",
>   acpi_battery_blacklist[i]);
>   return;
> }
> 
> In __init acpi_battery_init_async
> 
> I suppose enabling the approriate module(s) would maybe solve this.
> In the make menuconfig I could see the following drivers:
> 
> AXP288_ADC, AXP288_CHARGER, and AXP288_FUEL_GAUGE
> 
> I tried building a custom kernel, but upon booting in panics,
> but it seems to be because the initrams fs is not able to mount, I guess
> the image wasn't properly installed in GRUB, or something like that.
> 
> By the way, the info below shows kernel 4.14, but that's because I ran
> reportbug from my desktop, and haven't rebooted into the newest kernel yet
> I hope this doesn't create a hassle.

Last year the blacklist was introduced for the ACPI battery driver:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/acpi/battery.c?id=dccfae6d4f4c2cfa1fdc3bf55755fcad02184b99

Enabling AXP288_FUEL_GAUGE (and dependencies) should result in
proper battery information. If there are still issues with your
system after enabling the config option, send a mail to the
following addresses:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS?id=dccfae6d4f4c2cfa1fdc3bf55755fcad02184b99#n10012

-- Sebastian


signature.asc
Description: PGP signature

Bug#895139: ITP: node-babel-plugin-array-includes -- Babel plugin to replace the array includes syntax

[Paolo Greppi]

Package: wnpp
Severity: wishlist
Owner: Paolo Greppi 

* Package name: node-babel-plugin-array-includes
  Version : 2.0.3
  Upstream Author : Christoph Hermann
* URL : 
https://github.com/stoeffel/babel-plugin-array-includes#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Babel plugin to replace the array includes syntax

 This Babel plugin replaces the array includes(val) syntax with a check
 based on indexOf.
 .
 Babel is a JavaScript compiler to use next generation JavaScript, today.
 .
 Node.js is an event-based server-side JavaScript engine. 

This is a build-dependency of node-yarnpkg, see ITP:
https://bugs.debian.org/843021

My intention is to maintain it within the JavaScript maintainers team.

The repo will be on salsa:
https://salsa.debian.org/js-team/node-babel-plugin-array-includes

Paolo

Bug#895125: Soundconverter mp3 issue

[James Cowgill]

Control: reassign -1 gstreamer1.0-plugins-ugly 1.14.0-1
Control: retitle -1 gstreamer1.0-plugins-ugly: should have breaks 
gstreamer1.0-plugins-good (<< 1.13.1)

Hi,

On 07/04/18 11:01, Rob Oosterling wrote:
> Package: soundconverter
> Version: 3.0.0~beta1-2
> 
> Dear maintainer,
> 
> I installed this version, including all dependencies and recommended
> options (including gstreams-ugly),
[...]
> but the lame (mp3) option appears not to be seen by Soundconverter:
> 
> SoundConverter 3.0.0-beta1
>   using GTK version: 3.0
>   using Gstreamer version: 1.14.0.0
>   using 4 thread(s)
>   using gio
>   "lamemp3enc" gstreamer element not found, disabling MP3 output.
> 
> Running Debian Testing updated until today:
[...]
> Versions of packages soundconverter depends on:
> ii  gstreamer1.0-plugins-base  1.14.0-2
> ii  gstreamer1.0-plugins-good  1.12.4-1+b1
> 
> Versions of packages soundconverter recommends:
> ii  gstreamer1.0-libav 1.14.0-1
> ii  gstreamer1.0-plugins-ugly  1.14.0-1

The lame plugin was moved from -ugly to -good in 1.14 and because -good
1.14 has not yet migrated to testing, you have managed to lose the
entire plugin.

Upgrading gstreamer1.0-plugins-good to 1.14 in unstable should work, but
I am wondering whether it's a good idea to add a Breaks to -ugly to
prevent this from happening? This is the recommended way according to
#9 on this page:
 https://wiki.debian.org/PackageTransition

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#895138: gimp: GIMP 2.10 requires BABL >= 0.1.44 to start

[Aurélien COUDERC]

Package: gimp
Version: 2.10.0~RC1-1
Severity: important

Dear Maintainer,

GIMP 2.10.0~RC1 installed from experimental fails to start due to outaded BABL.
Could you please refresh the vesionned dependency to >= 0.1.44 ?

Error message where trying to start:
===
BABL version too old!

GIMP requires BABL version 0.1.44 or later.
Installed BABL version is 0.1.42.

Somehow you or your software packager managed
to install GIMP with an older BABL version.

Please upgrade to BABL version 0.1.44 or later.
===

Thanks,
--
Aurélien



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

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

Versions of packages gimp depends on:
ii  gimp-data2.10.0~RC1-1
ii  libaa1   1.4p5-44+b1
ii  libbabl-0.1-00.1.42-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-3
ii  libcairo21.15.10-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgcc1  1:8-20180321-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgegl-0.3-00.3.30-1
ii  libgexiv2-2  0.10.8-1
ii  libgimp2.0   2.10.0~RC1-1
ii  libglib2.0-0 2.56.0-4
ii  libgs9   9.22~dfsg-2
ii  libgtk2.0-0  2.24.32-1
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b1.7.2-1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-1
ii  liblzma5 5.2.2-1.3
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libpangoft2-1.0-01.42.0-1
ii  libpng16-16  1.6.34-1
ii  libpoppler-glib8 0.62.0-2
ii  librsvg2-2   2.40.20-2
ii  libstdc++6   8-20180321-1
ii  libtiff5 4.0.9-4
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-12
ii  libx11-6 2:1.6.5-1
ii  libxcursor1  1:1.1.15-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  python   2.7.14-4
ii  python-gtk2  2.24.0-5.1+b1
ii  python2.72.7.14-8
ii  xdg-utils1.1.2-2
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages gimp recommends:
ii  ghostscript  9.22~dfsg-2

Versions of packages gimp suggests:
ii  gimp-data-extras  1:2.0.2-1
pn  gimp-help-en | gimp-help  
pn  gvfs-backends 
ii  libasound21.1.3-5

-- no debconf information

Bug#895083: [Freewx-maint] Bug#895083: python-wxgtk4.0: module wx is not usable

[Adrian Bunk]

On Fri, Apr 06, 2018 at 11:53:39PM -0400, Scott Talbert wrote:
> On Sat, 7 Apr 2018, Norbert Lange wrote:
> 
> > it appears that the files are installed in a subdirectory,
> > potentially to avoid confligs with previous versions?
> > result is that
> > 
> > import wx fails with
> > 
> > ImportError: No module named wx
> > 
> > I havent found a way to configure the installation
> 
> The purpose of the python-wxgtk4.0 package is primarily for application
> developers to use in porting their applications to wxPython 4.0 (Phoenix).
> There isn't much of a reason otherwise to use the Python 2 version of
> wxPython 4.0.  Instead, you should use python3-wxgtk4.0 with which you can
> 'import wx'.
> 
> If you really would like to use the Python 2 version, you can do:
> 
> PYTHONPATH=/usr/lib/python2.7/dist-packages/wxPython-4.0.1-py2.7-linux-amd64.egg
>  python
> import wx

Is there a good reason why you are making it harder than necessary to 
use python-wxgtk4.0 ?

Python 2 is fully supported by Debian during the lifetime of buster,
and there are various reasons why many users are stuck with Python 2
for some more time.

> Scott

cu
Adrian

-- 

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