Bug#887479: libpdfbox2-java FTBFS: dh_installexamples fails

2018-01-16 Thread Adrian Bunk
Source: libpdfbox2-java
Version: 2.0.8-1
Severity: serious

Some recent change in unstable makes libpdfbox2-java FTBFS:

https://tests.reproducible-builds.org/debian/history/libpdfbox2-java.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpdfbox2-java.html

...
dh_installexamples
find /build/1st/libpdfbox2-java-2.0.8/debian/libpdfbox2-java-doc/ -type d 
-empty -delete
rm 
/build/1st/libpdfbox2-java-2.0.8/debian/libpdfbox2-java-doc/usr/share/doc/libpdfbox2-java-doc/examples/pom.xml.save
rm: cannot remove 
'/build/1st/libpdfbox2-java-2.0.8/debian/libpdfbox2-java-doc/usr/share/doc/libpdfbox2-java-doc/examples/pom.xml.save':
 No such file or directory
debian/rules:10: recipe for target 'override_dh_installexamples' failed
make[1]: *** [override_dh_installexamples] Error 1



Bug#777089: Next python-mote pre-condition test issue: python-jsondiff trows ModuleNotFoundError: No module named 'nose_random'

2018-01-16 Thread Tristan Seligmann
On Tue, 16 Jan 2018 at 22:45 Andreas Tille  wrote:

> My web search for a module named 'nose_random' remained empty.
>

I found this package, which seems to match, from the same organization:
https://github.com/ZoomerAnalytics/nose-random

Unfortunately it seems to be unreleased, so I think you would need to
package a GitHub snapshot or something (or alternatively disable the tests).


Bug#887478: kdiff3: please remove the extra libkonq5-dev build dependency

2018-01-16 Thread Pino Toscano
Source: kdiff3
Version: 0.9.98-3
Severity: normal
Tags: patch

Hi,

kdiff3 has libkonq5-dev as build dependency, although it is used only
when kdelibs < 4.6 is found, as used by the old file manager plugin.
Since src:kde-baseapps (currently building the kdelibs 4.x libkonq)
will be removed within Buster, then this extra build dependency sort of
blocks this.

(Of course, switching kdiff3 to Qt5/KF5 would fix this, #583268,
#801680, and #874949, but that's for another day.)

Thanks,
-- 
Pino
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: kdiff3
 Priority: optional
 Section: kde
 Maintainer: Eike Sauer 
-Build-Depends: cdbs, debhelper (>= 7.0.50~), dpkg-dev (>= 1.16.2), cmake, 
kdelibs5-dev (>= 4:4.4.4), libkonq5-dev, qt4-dev-tools, libicu-dev
+Build-Depends: cdbs, debhelper (>= 7.0.50~), dpkg-dev (>= 1.16.2), cmake, 
kdelibs5-dev (>= 4:4.4.4), qt4-dev-tools, libicu-dev
 Standards-Version: 3.9.8
 Homepage: http://kdiff3.sourceforge.net
 Vcs-Svn: https://kdiff3.svn.sourceforge.net/svnroot/kdiff3/trunk/


Bug#799781: ping

2018-01-16 Thread Vincent McIntyre
Hi

just checking why this was still open -
I see that the jessie tree now contains the patch
'libmultipath: use a shared lock to co-operate with udev'
and is tagged 0.5.0-6+deb8u3.
But it seems to have missed the 8.10 point release,
and is not lurking in jessie-proposed-updates;
0.5.0-6+deb8u2 is the latest available for jessie.

Does something need a nudge?
AFAICT this would close #799781 and #843953

Cheers
Vince
-- 



Bug#887477: mysql-5.7: Security fixes from the January 2018 CPU

2018-01-16 Thread Salvatore Bonaccorso
Source: mysql-5.7
Version: 5.7.20-1
Severity: grave
Tags: security upstream

Hi

See
http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixMSQL
for a list of CVEs affecting it and
https://security-tracker.debian.org/mysql-5.7.

Regards,
Salvatore



Bug#887476: ITP: lavacli -- LAVA XML-RPC command line interface

2018-01-16 Thread Senthil Kumaran S
Package: wnpp
Severity: wishlist
Owner: Senthil Kumaran S (stylesen) 

* Package name: lavacli
  Version : 0.7
  Upstream Author : Linaro LAVA Team 
* URL : https://www.linaro.org/initiatives/lava/
* License : GPL
  Programming Lang: Python
  Description : LAVA XML-RPC command line interface

 LAVA is a continuous integration system for deploying operating systems onto
 physical and virtual hardware for running tests. Tests can be simple boot
 testing, bootloader testing and system level testing, although extra hardware
 may be required for some system tests. Results are tracked over time and data
 can be exported for further analysis.

 This package provides a user space command line interface to any LAVA (Linaro
 Automated Validation Architecture) instance for submitting test jobs or
 querying the instance for device and job status over XML-RPC. A user account
 on the instance is needed to create and use authentication tokens for some
 calls. The list of calls supported is described on the API section of the LAVA
 instance.

 This package is a replacement for the previously available lava-tool package
 which will be obsoleted shortly and the LAVA team will maintain lavacli as the
 official command line interface for LAVA. I am one of the upstream maintainers
 of LAVA project available in Debian. I would like to package the latest
 version (0.7) of lavacli. I would like to maintain this package along with the
 "Debian LAVA team" members, who already agree the need for lavacli package in
 Debian.



Bug#887475: dh-golang: support comma-separated import paths in dh_golang_autopkgtest

2018-01-16 Thread Alexandre Viau
Package: dh-golang
Version: 1.28
Severity: normal
Tags: patch

Hello,

I have noticed that autopkgtests for packages with comma-separated
import paths are failing.

Here is a patch.

Would you please review and/or apply it?

Cheers,

-- 
Alexandre Viau
av...@debian.org
From 923f325dc9e7617814f43d28e898c7d8c48bb058 Mon Sep 17 00:00:00 2001
From: aviau 
Date: Wed, 17 Jan 2018 00:49:10 -0500
Subject: [PATCH] dh_golang_autopkgtest support for several import paths

---
 script/dh_golang_autopkgtest | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/script/dh_golang_autopkgtest b/script/dh_golang_autopkgtest
index c15447a..ee3f125 100755
--- a/script/dh_golang_autopkgtest
+++ b/script/dh_golang_autopkgtest
@@ -57,18 +57,26 @@ call_rules() {
 }
 
 get_import_path() {
-# Find package's import path from debian/rules or debian/control.
-pkg=$(call_rules apt-print-DH_GOPKG)
+# Find package's main import path from debian/rules or debian/control.
+pkgs=$(call_rules apt-print-DH_GOPKG)
 
-if [ -z "$pkg" ]; then
+if [ -z "$pkgs" ]; then
 # DH_GOPKG not set, find it in control file.
-pkg=$(perl -w -MDpkg::Control::Info -e '
+pkgs=$(perl -w -MDpkg::Control::Info -e '
 my $s = Dpkg::Control::Info->new()->get_source();
 print $s->{"XS-Go-Import-Path"} || "";')
 fi
-if [ -z "$pkg" ]; then
-error "Can't find import path."
+
+if [ -z "$pkgs" ]; then
+error "Can't find import paths."
+else
+# One import path per line. Commas and empty lines removed.
+pkgs=$(echo $pkgs | tr -d " " | tr "," "\n" | awk "NF")
 fi
+
+# Only return the first import path.
+pkg=$(echo "$pkgs" | head -n 1)
+
 echo "$pkg"
 }
 
-- 
2.14.2



signature.asc
Description: OpenPGP digital signature


Bug#873417: pocl: Please update to llvm-toolchain 4.0 or, better, 5.0

2018-01-16 Thread Andreas Beckmann
Followup-For: Bug #873417

Hi,

I got distracted from pocl over the holidays, but today I finally took a
look again.
This is the current self test result matrix of the different pocl and llvm
versions on amd64 and i386:

amd64   i386testsuite time (amd64)
(there is only VECMATHLIB, no SLEEF)
pocl 0.14 / llvm 3.9passpass 205.87 sec
pocl 0.14 / llvm 4.0passfail 12 2676.44 sec

-DENABLE_VECMATHLIB=ON (non-default)
pocl 1.0 / llvm 3.9 passpass 130.87 sec
pocl 1.0 / llvm 4.0 passfail 10 2950.16 sec
pocl 1.0 / llvm 5.0 passfail 11 3952.99 sec

-DENABLE_SLEEF=ON (default)
pocl 1.0 / llvm 3.9 passfail 1   172.41 sec
pocl 1.0 / llvm 4.0 passfail 1   127.27 sec
pocl 1.0 / llvm 5.0 passfail 2   121.52 sec


pocl 0.14 / llvm 4.0

89% tests passed, 12 tests failed out of 111

The following tests FAILED:
  3 - kernel/test_convert_type_1 (Failed)
  4 - kernel/test_convert_type_2 (Failed)
  5 - kernel/test_convert_type_4 (Failed)
  6 - kernel/test_convert_type_8 (Failed)
  7 - kernel/test_convert_type_16 (Failed)
 12 - kernel/test_length_distance (Failed)
 13 - kernel/test_fmin_fmax_fma (Failed)
 16 - kernel/test_fabs (Failed)
 18 - kernel/test_frexp_modf (Failed)
109 - examples/scalarwave (OTHER_FAULT)
110 - examples/trig (SEGFAULT)
111 - EinsteinToolkit (OTHER_FAULT)

examples/scalarwave and EinsteinToolkit are fixed by commit
0d5683c68cda1401b66243c74d4f798ea2b2280f, which is not backportable to 0.14


pocl 1.0 / llvm 4.0 -DENABLE_VECMATHLIB=ON

92% tests passed, 10 tests failed out of 120

The following tests FAILED:
  3 - kernel/test_convert_type_1 (Failed)
  4 - kernel/test_convert_type_2 (Failed)
  5 - kernel/test_convert_type_4 (Failed)
  6 - kernel/test_convert_type_8 (Failed)
  7 - kernel/test_convert_type_16 (Failed)
 12 - kernel/test_length_distance (Failed)
 13 - kernel/test_fmin_fmax_fma (Failed)
 16 - kernel/test_fabs (Failed)
 18 - kernel/test_frexp_modf (Failed)
118 - examples/trig (OTHER_FAULT)


pocl 1.0 / llvm 5.0 -DENABLE_VECMATHLIB=ON

91% tests passed, 11 tests failed out of 120

The following tests FAILED:
  3 - kernel/test_convert_type_1 (Failed)
  4 - kernel/test_convert_type_2 (Failed)
  5 - kernel/test_convert_type_4 (Failed)
  6 - kernel/test_convert_type_8 (Failed)
  7 - kernel/test_convert_type_16 (Failed)
 12 - kernel/test_length_distance (Failed)
 13 - kernel/test_fmin_fmax_fma (Failed)
 16 - kernel/test_fabs (Failed)
 18 - kernel/test_frexp_modf (Failed)
 70 - regression/struct_kernel_arguments (Failed)
118 - examples/trig (OTHER_FAULT)


pocl 1.0 / llvm 3.9 -DENABLE_SLEEF=ON

99% tests passed, 1 tests failed out of 120

The following tests FAILED:
 16 - kernel/test_fabs (Failed)


pocl 1.0 / llvm 4.0 -DENABLE_SLEEF=ON

99% tests passed, 1 tests failed out of 120

The following tests FAILED:
 16 - kernel/test_fabs (Failed)


pocl 1.0 / llvm 5.0 -DENABLE_SLEEF=ON

The following tests FAILED:
 16 - kernel/test_fabs (Failed)
 70 - regression/struct_kernel_arguments (Failed)


Looks like we need to move to pocl 1.0 and llvm 4.0, unfortunately
that will need another pass through NEW, since the SOVERSION was bumped.


Andreas



Bug#886652: WWW: identi.ca/debian does not work

2018-01-16 Thread Paul Wise
On Tue, 2018-01-16 at 15:37 +0100, Laura Arjona Reina wrote:

> There is already a link to micronews.d.o there.

Hmm, are you sure? I don't see any:

$ curl -s https://www.debian.org/ | grep -i micron

I meant that we should remove the links to identi.ca/debian and instead
link to the micrownews site.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#885525: /usr/bin/nm-applet: nm-applet crashes when connecting to VPN

2018-01-16 Thread Sean DuBois
Works perfectly!

No worries about timing, you are not getting paid I
really appreciate the quick turn around :)

thanks



Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

2018-01-16 Thread Martin-Éric Racine
2018-01-17 4:24 GMT+02:00 Michael Biebl :
> On Tue, 19 Dec 2017 06:55:34 +0100 Michael Biebl  wrote:
>> Am 19.12.2017 um 02:18 schrieb Martin-Éric Racine:
>> > 2017-12-19 2:02 GMT+02:00 Michael Biebl :
>> >> Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
>> >>> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
>>  Hi,
>> 
>>  I just uploaded v236 today. Before we try to debug this further, it
>>  would be great if you can give this version a try. Maybe your issue is
>>  already fixed.
>>  If not, we'll have to involve upstream at some point by filing an
>>  upstream bug report. But let's first wait for your results with 236-1
>> >>>
>> >>> The issue is not fixed. Something fails at communicating with dbus,
>> >>> and it messes up everything else.
>> >>
>> >> Just to be sure, have you rebooted your system after upgrading to 236-1?
>> >
>> > Yes I have, but this required issuing "exec reboot -f" to bypass init
>> > entirely, otherwise it fails due to the lack of dbus connection.
>>
>> Sure, if PID 1 has crashed, it will freeze itself and no longer respond
>> to any (D-Bus) requests.
>>
>> When exactly does systemd crash? Is it immediately during boot or after
>> you've been using the system for a while?
>> I assume it works at least for a while, otherwise no other services
>> would be started and you would not be able to log in.
>> When systemd crashes, you should get an entry in the kernel log (dmesg)
>> respectively the journal.
>>
>> It would be great if you can follow the instructions at [1] to boot with
>> debug logging enabled and then provide a journal log which shows such a
>> crash.
>>
>
> Any updates on this?

Not yet.  I just spent the last month or so giving interviews to the
media.  Will get back to this ASAP.

Martin-Éric



Bug#822603: Remove network-config from Debian?

2018-01-16 Thread Jeremy Bicha
On Sun, Dec 31, 2017 at 7:21 PM, Jeremy Bicha  wrote:
> Hi,
>
> network-config was removed from Debian Testing because it depends on
> gksu [1]. The Debian GNOME team would like to remove gksu from Debian
> Unstable too but we need to fix or remove the reverse depends first.
>
> Can I file a Debian removal bug for network-config now?
>
> [1] https://bugs.debian.org/822603
>
> Thanks,
> Jeremy Bicha

network-config is now the last thing in Debian depending on gksu. The
Debian GNOME team wants to remove gksu since it is deprecated and no
longer maintained. Because network-config has already been removed
from Debian Testing since July for this issue and there has been no
response from the Debian maintainer for this package, I intend to
request that network-config be removed from Debian soon. It can be
reintroduced to Debian if this bug is fixed.

Thanks
Jeremy Bicha



Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

2018-01-16 Thread Michael Biebl
On Tue, 19 Dec 2017 06:55:34 +0100 Michael Biebl  wrote:
> Am 19.12.2017 um 02:18 schrieb Martin-Éric Racine:
> > 2017-12-19 2:02 GMT+02:00 Michael Biebl :
> >> Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
> >>> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
>  Hi,
> 
>  I just uploaded v236 today. Before we try to debug this further, it
>  would be great if you can give this version a try. Maybe your issue is
>  already fixed.
>  If not, we'll have to involve upstream at some point by filing an
>  upstream bug report. But let's first wait for your results with 236-1
> >>>
> >>> The issue is not fixed. Something fails at communicating with dbus,
> >>> and it messes up everything else.
> >>
> >> Just to be sure, have you rebooted your system after upgrading to 236-1?
> > 
> > Yes I have, but this required issuing "exec reboot -f" to bypass init
> > entirely, otherwise it fails due to the lack of dbus connection.
> 
> Sure, if PID 1 has crashed, it will freeze itself and no longer respond
> to any (D-Bus) requests.
> 
> When exactly does systemd crash? Is it immediately during boot or after
> you've been using the system for a while?
> I assume it works at least for a while, otherwise no other services
> would be started and you would not be able to log in.
> When systemd crashes, you should get an entry in the kernel log (dmesg)
> respectively the journal.
> 
> It would be great if you can follow the instructions at [1] to boot with
> debug logging enabled and then provide a journal log which shows such a
> crash.
> 

Any updates on this?

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



signature.asc
Description: OpenPGP digital signature


Bug#887474: sort order no longer date but man page still says so

2018-01-16 Thread 積丹尼 Dan Jacobson
Package: mutt
Version: 1.9.2-1
File: /usr/share/man/man5/muttrc.5.gz

$ man muttrc

   sort
  Type: sort order
  Default: date # This is no longer the case in Debian.



Bug#886908: systemd enabled services unable to access shares

2018-01-16 Thread Michael Biebl
Am 11.01.2018 um 07:54 schrieb Hannu Laitinen:
> Package: systemd
> Version: 236-2

Can you please upgrade to 236-3, reboot and then test again and report
back with your findings.


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



signature.asc
Description: OpenPGP digital signature


Bug#887456: init-system-helpers: deb-systemd-helper does not honor the same package-relevant unit paths as systemd

2018-01-16 Thread Michael Biebl
Hi Guillem

Am 16.01.2018 um 20:02 schrieb Guillem Jover:
> Source: init-system-helpers
> Source-Version: 1.51
> Severity: normal
> Tags: patch
> 
> Hi!
> 
> The current list of paths honored by deb-systemd-helper does not match
> the one in systemd [L]. That's fine for several of them because they
> are intended to be for run-time generated content, or local admin
> content. There is still at least one that can be used by packages
> depending on the distribution policy that is missing, i.e.
> “/usr/local/lib/systemd/system”.

You talk about /usr/local/lib/systemd/system here but the patch is adds
/usr/lib/systemd/system/

Can you please clarify


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



signature.asc
Description: OpenPGP digital signature


Bug#884466: Is this still an issue?

2018-01-16 Thread Hillel Lubman
Original bug reporter didn't get back to confirm the bug, and others report it 
as working
fine now. May be severity should be lowered at least until it's confirmed?

Regards,
Hillel Lubman.



Bug#886892: More info

2018-01-16 Thread Peter.Chubb

I tried with another (networked, PS and PDF) printer, a Konica Bizhub 454.

If I print a PDF document with
   lp -n 10 foo.pdf

I get 10 copies;  if I load foo.pdf into evince and print, I get 100
copies printed, neatly stapled into lots of 10.

-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group   Data61 (formerly NICTA)


Bug#880246: magic-wormhole: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13

2018-01-16 Thread Harlan Lieberman-Berg
tag 880246 +pending
thanks

Hi Antoine,

I talked with the Privacy Tools team, and they've taken the patch.
0.10.3-1 now builds successfully and works fine!  It's waiting for
your upload.

Sincerely,

On Sat, Jan 6, 2018 at 7:30 PM, Harlan Lieberman-Berg
 wrote:
> On Sat, Jan 6, 2018 at 12:45 PM, Antoine Beaupré
>  wrote:
>> I'm fine with you pushing to collab-maint - this is what it's for after
>> all. :)
>
> Still, didn't want you to get surprised if you were working on it at
> the same time!
>
>> So even after this you still FTBFS? Did you report that issue upstream
>> as well?
>
> Right now, it's FTBFS because of an inappropriate dependency in the
> setuptools config of one of the libraries, txtorcon.  They've merged
> my PR, but they haven't cut a new release yet.  If you want, I can
> open a bug over with the Privacy Tools team and see if they'd be
> willing to take the patch out of the release cycle.
>
> Sincerely,
> --
> Harlan Lieberman-Berg
> ~hlieberman



-- 
Harlan Lieberman-Berg
~hlieberman



Bug#885556: multipath-udeb: depends on a non-udeb package: liburcu6

2018-01-16 Thread Cyril Brulebois
Hi,

Michael Jeanson  (2018-01-15):
> I've uploaded 0.10.0-3 with the included patch and some other minor
> packaging fixes, it's sitting in the NEW queue because of the added udeb.

Thanks Michael, I've pinged #-ftp to see if that can speed things up. :)
 

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


signature.asc
Description: PGP signature


Bug#886693: linux: please reinstate ia64 for the linux kernel package

2018-01-16 Thread Ben Hutchings
Control: tag -1 moreinfo

On Mon, 2018-01-08 at 19:04 -0500, Jason Duerstock wrote:
> Source: linux
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> As you may be aware, the ia64 architecture has recently been added
> back to Debian, but now resides in Debian ports.
> The attached patch should enable the linux package to build the ia64
> kernel again.
> 
> Thanks for your time!

This appears to be almost exactly reverting the change I made to remove
ia64 support, which is not the right thing to do.

You need to actually review the changes that have happened in the 2.5
years since then and update the config accordingly.  In particular, the
following symbols no longer exist in Linux 4.15-rc8:

CONFIG_BLK_CPQ_CISS_DA
CONFIG_BLK_CPQ_DA
CONFIG_CISS_SCSI_TAPE
CONFIG_I2O
CONFIG_I2O_BLOCK
CONFIG_I2O_CONFIG
CONFIG_I2O_PROC
CONFIG_I2O_SCSI
CONFIG_MMTIMER
CONFIG_SCSI_DC390T

The commit message for the removal of CONFIG_MMTIMER upstream (commit
07903ada96139ced48f2f893fe57a26a8fbc6043) implies that SGI SN2 systems
are no longer supported, in which case presumably the sn-modules udeb
should also be removed.

Do Itanium systems typically have floppy drives?  If not, delete the
"suggests: fdutils" from debian/config/ia64/defines.

Shouldn't the "mckinley" configuration be renamed, since it's supposed
to support later processors as well?

Does it still make sense to build an "itanium" configuration, given how
few Merced systems exist?

Also, do you have any idea whether these bugs have been fixed upstream:

https://bugs.debian.org/679545
https://bugs.debian.org/691576
https://bugs.debian.org/728706

If not, those should be reopened when ia64 is enabled again.

Ben.

-- 
Ben Hutchings
Experience is directly proportional to the value of equipment
destroyed.
- Carolyn Scheppner


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


Bug#887473: gnuplot-data: Please add Multi-Arch: foreign

2018-01-16 Thread Elrond
Package: gnuplot-data
Version: 5.2.2+dfsg1-2
Severity: wishlist

Hi,

It looks like gnuplot-data offers an architecture
independent (data/translations/script level) interface to
its users.
Would you mind setting it to Multi-Arch: foreign?
Like gnuplot-doc is already.
It's usually a matter of adding one line to debian/control.

This would hopefully improve install options for different
architectures. Like running the x32 variant on an amd64
system.

Note: Architecture=all packages are not Multi-Arch=foreign
automatically for various reasons, so they need to be set
manually.


Cheers

Elrond



Bug#789119: Hello

2018-01-16 Thread Ahmad .s.al kharji

i was wondering if you got my previous email regarding my proposal ?



Bug#887472: Please update to newer version

2018-01-16 Thread Matthew Wilcox

Package: x86info
Version: 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1+b1

This version doesn't recognise the Kaby Lake in my laptop.
The version I just downloaded from git does.



Bug#887471: isa-support: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2018-01-16 Thread Correa Jr

Package: isa-support
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.



pt_BR.po.gz
Description: application/gzip


Bug#887470: slixmpp: please package new version 1.3.0

2018-01-16 Thread W. Martin Borgert
Package: python3-slixmpp
Version: 1.2.2-1.1
Severity: wishlist

Version 1.3.0 of slixmpp has been released on 2017-11-28.
Please consider packaging the new version. Thanks!



Bug#885725: freecol: Source includes "build/installer/iso-639-2.txt" listed in Files-Excluded header

2018-01-16 Thread Chris Lamb
Hi Markus,

> those files are dfsg-free

Cool. I didn't actually check that when filing, it's just such
a common use-case for Files-Excluded and, as you saw, being a
DFSG violation was only one of potentially many many reasons I
listed.

ACK and agree with corresponding severity change. Thanks!


Regards,

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



Bug#887469: grilo-plugins-0.3: radiofrance source broken

2018-01-16 Thread Antoine Musso
Package: grilo-plugins-0.3
Version: 0.3.3-1
Severity: normal

Dear Maintainer,

On Stretch using Rhythmbox I have enabled the grilo plugin which get me
a lot of online sources automagically. Notably a Radio France list but
unfortunately it lists a single radio "Mouv'" when there are several of
them.

Turns out the URL have been changed since 0.3.3 and a patch needs to be
applied and release for stretch.

The upstream bug with patch:
https://bugzilla.gnome.org/show_bug.cgi?id=773310

The commit is 4617b91983792f3282757b93134f0b7e8f287d52

https://github.com/grilofw/grilo-plugins/commit/4617b91983792f3282757b93134f0b7e8f287d52

Would you mind applying it as a hotfix to 0.3.3? Thank you!

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

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

Versions of packages grilo-plugins-0.3 depends on:
ii  libarchive13 3.2.2-2
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavahi-glib1   0.6.32-2
ii  libavahi-gobject00.6.32-2
ii  libc62.24-11+deb9u1
ii  libdmapsharing-3.0-2 2.9.37-1
ii  libgdata22   0.17.6-2
ii  libglib2.0-0 2.50.3-2
ii  libgmime-2.6-0   2.6.22+dfsg2-1
ii  libgoa-1.0-0b3.22.5-1
ii  libgom-1.0-0 0.3.2-2
ii  libgrilo-0.3-0   0.3.2-2
ii  libgstreamer1.0-01.10.4-1
ii  libjson-glib-1.0-0   1.2.6-1
ii  liblua5.3-0  5.3.3-1
ii  libmediaart-2.0-01.9.0-2
ii  liboauth01.0.1-1
ii  libsoup2.4-1 2.56.0-2+deb9u1
ii  libsqlite3-0 3.16.2-5+deb9u1
ii  libtotem-plparser18  3.10.7-1+b1
ii  libtracker-sparql-1.0-0  1.10.5-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2

Versions of packages grilo-plugins-0.3 recommends:
ii  dleyna-server  0.4.0-1.1

grilo-plugins-0.3 suggests no packages.

-- no debconf information



Bug#887468: hpanel: Crashes with SIGSEGV sometimes

2018-01-16 Thread Paul Szabo
Package: hpanel
Version: 0.3.2-4
Severity: normal

Dear Maintainer,

Running on x86_64, hpanel sometimes crashes with SIGSEGV.
As yet I have not noticed what actions may cause this, so
do not know how to make it happen at will.

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


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

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

Versions of packages hpanel depends on:
ii  libc6 2.24-11+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libxft2   2.3.2-1+b2
ii  libxpm4   1:3.5.12-1

hpanel recommends no packages.

hpanel suggests no packages.

-- no debconf information



Bug#885725: freecol: Source includes "build/installer/iso-639-2.txt" listed in Files-Excluded header

2018-01-16 Thread Markus Koschany
Control: severity -1 minor

On Fri, 29 Dec 2017 15:25:30 + Chris Lamb  wrote:
> Source: freecol
> Version: 0.11.6+dfsg-2
> Severity: important
> User: la...@debian.org
> Usertags: files-excluded
> 
> Dear Maintainer,
> 
> freecol lists "build/*" in the Files-Excluded field
> in debian/copyright but the source tree contains build/installer/iso-639-2.txt
> amongst others.
> 
> This might be a DFSG violation, the referenced files are probably not
> attributed in debian/copyright or the upstream tarball was simply not
> repacked as intended. Alternatively, the field is simply out of date.

Hi Chris,

those files are dfsg-free. After I uploaded 0.11.6+dfsg-1 to unstable, I
discovered that I could also remove the build directory because we don't
need it to actually build the package.

https://anonscm.debian.org/git/pkg-games/freecol.git/commit/?id=671534dabe8d3e6910c2a47599741eee1743ce33

This is the reason why there is a mismatch between the Files-Excluded
paragraph and the content of the original tarball. Nothing to worry
about. It can be fixed with the next upload.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature


Bug#887467: hpanel: x86_64 shows broken icons

2018-01-16 Thread Paul Szabo
Package: hpanel
Version: 0.3.2-4
Severity: normal

Dear Maintainer,

Hpanel running on x86_64, shows broken icons; though hpanel on i386
shows correct icons. (Fspanel has the same behaviour.)

Cheers, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia


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

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

Versions of packages hpanel depends on:
ii  libc6 2.24-11+deb9u1
ii  libx11-6  2:1.6.4-3
ii  libxft2   2.3.2-1+b2
ii  libxpm4   1:3.5.12-1

hpanel recommends no packages.

hpanel suggests no packages.

-- no debconf information



Bug#887369: RFS: libreoffice-style-papirus/20170228-1 [ITP]

2018-01-16 Thread Rene Engelhard
Hi,

On Tue, Jan 16, 2018 at 11:01:32PM +0100, Adam Borowski wrote:
> On Tue, Jan 16, 2018 at 08:20:10PM +0100, I wrote:
> > An icon theme might be more work than a cursor or window theme as whatever
> > needs the new icon would borrow from another theme and thus look out of
> > place.
> > 
> > > You can have another opinion. If not I will close the RFS and ITP in
> > > the next few days.
> > 
> > This is your time, no one has the right to tell you what to work on (at
> > least not in Debian).  You maintain a diverse set of packages, so a theme
> > that's not a part of your main area has a pretty low priority.
> 
> I just learned that Deepin's default theme is based on Papirus, which makes
> this package a matter of adjusting LibreOffice to match, rather than just a
> random unrelated theme.
> 
> I don't know if there's a reasonable way to make LibreOffice default to this
> theme when started from Deepin -- if not, it'd require a manual action from
> the user, which hardly anyone is going to do.

LO has it:
https://cgit.freedesktop.org/libreoffice/core/tree/vcl/source/app/IconThemeSelector.cxx?h=libreoffice-6-0-0#n50

This would need to be amended to detect Deepin (there's also desktop
detection..)

But then still there's the point I raised: the libreoffice part was last
touched 1 year ago. In the meanwhile there have been icon changes here
and there in LO and 6.0.0 is around the corner. Who is going to support
this and eventual inconsistencies when icons are missing? (LOs -style
packages have fallback Depends: to the "last-resort-fallback" tango,
but...)

Regards,

Rene



Bug#883297: "Packages: list" field removed from tasksel control file

2018-01-16 Thread Wolfgang Schweer
On Tue, Jan 16, 2018 at 10:50:17PM +0100, Wolfgang Schweer wrote:
> But, with the exception of the existing (with unexplicable content) 
> debian-med-tasks.desc file, things are IMO fine. 

One more thing:
I ran 'git log --follow debian-med-tasks.desc'

debian-med-tasks.desc with 'Packages: list' content is due to your 
commit 2c219f08e54:

'Render dependency relations using UDD based blends-dev'

Don't know what this actually means, but maybe the reason is a different 
blends-dev?

Wolfgang


signature.asc
Description: PGP signature


Bug#887465: guacamole: Please update to new upstream version 0.9.13

2018-01-16 Thread Fabian Rodriguez
Package: guacamole
Version: 0.9.9+dfsg-1
Severity: important

Dear Maintainer,

There have been several version of Guacamole since it was last updated in 
Debian - current version is 0.9.9 released in 2015-12-18.

The latest is 0.9.13 available at http://guacamole.apache.org/releases/

Perhaps the newer version will build succesfuly in a recent Debian install.

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

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

Versions of packages guacamole depends on:
ii  debconf [debconf-2.0]1.5.61
ii  guacd0.9.9-2
ii  libatinject-jsr330-api-java  1.0+ds1-2
ii  libcommons-codec-java1.10-1
ii  libguava-java19.0-1
ii  libguice-java4.0-3
ii  libjackson-json-java 1.9.2-8
ii  libjersey1-core-java 1.19.3-1
ii  libjersey1-guice-java1.19.3-1
ii  libjersey1-json-java 1.19.3-1
ii  libjersey1-server-java   1.19.3-1
ii  libjs-angularjs  1.5.10-1
ii  libjs-jquery 3.1.1-2
ii  libjs-lodash 4.16.6+dfsg-2
ii  libjsr311-api-java   1.1.1-1
ii  liblogback-java  1:1.1.9-3
ii  libservlet3.1-java   8.5.14-1+deb9u2
ii  libslf4j-java1.7.22-1
ii  tomcat8  8.5.14-1+deb9u2

Versions of packages guacamole recommends:
ii  apache2 [httpd]  2.4.25-3+deb9u3

Versions of packages guacamole suggests:
pn  xrdp  

-- Configuration Files:
/etc/guacamole/guacamole.properties changed [not included]
/etc/guacamole/user-mapping.xml [Errno 13] Permission denied: 
'/etc/guacamole/user-mapping.xml'

-- debconf information excluded



Bug#887466: flameshot: weird system menu entries

2018-01-16 Thread Adam Borowski
Package: flameshot
Version: 0.5.0+git20180114-1
Severity: normal
Control: block -1 by 886409

(Reporting while still in NEW.)


The display name in the system menu looks odd.  No other program has "Launch
XXX" as its entry, just "XXX".

There's also that "Configure Flameshot" which is redundant, as this is
something the user can do from the program -- no other program has such
separate configuration (at least not in the menu).


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

Kernel: Linux 4.15.0-rc8-debug-00026-g18d1715aac67 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages flameshot depends on:
ii  libc6   2.26-4
ii  libgcc1 1:7.2.0-19
ii  libqt5core5a5.9.2+dfsg-6
ii  libqt5dbus5 5.9.2+dfsg-6
ii  libqt5gui5  5.9.2+dfsg-6
ii  libqt5network5  5.9.2+dfsg-6
ii  libqt5widgets5  5.9.2+dfsg-6
ii  libstdc++6  7.2.0-19

flameshot recommends no packages.

Versions of packages flameshot suggests:
ii  ca-certificates  20170717
ii  openssl  1.1.0g-2

-- no debconf information



Bug#776433: dict-devil: please make the build reproducible

2018-01-16 Thread Chris Lamb
Hi Sven,

> > Shall I go ahead and upload?
> 
> Yes, please do so.

Done!


Regards,

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



Bug#886506: Also still not bootable

2018-01-16 Thread Gerhard Hellmann

I also tried with the new version of libc6 and kernel, which became
available in the last few days, but the outcome unfortunately is the
same.

Unstable unfortunately also doesn't provide the old version of libc6, so
I assume, I have to wait further, hoping a fix is possible. Any other
suggestions how to upgrade to the newest version of the kernel?



Bug#887428: lintian: Use of uninitialized value in string ne at /usr/share/perl5/Lintian/Collect/Package.pm line 579

2018-01-16 Thread Chris Lamb
tags 887428 + pending
found 887428 2.5.66
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=1d7d5f746fe774c5e0d6bde66bbcdb2d181f73d8


Regards,

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



Bug#886878:

2018-01-16 Thread Mario.Limonciello
I tried in a fully up to date debian unstable VM and can not reproduce this 
myself.


Bug#887369: RFS: libreoffice-style-papirus/20170228-1 [ITP]

2018-01-16 Thread Adam Borowski
On Tue, Jan 16, 2018 at 08:20:10PM +0100, I wrote:
> An icon theme might be more work than a cursor or window theme as whatever
> needs the new icon would borrow from another theme and thus look out of
> place.
> 
> > You can have another opinion. If not I will close the RFS and ITP in
> > the next few days.
> 
> This is your time, no one has the right to tell you what to work on (at
> least not in Debian).  You maintain a diverse set of packages, so a theme
> that's not a part of your main area has a pretty low priority.

I just learned that Deepin's default theme is based on Papirus, which makes
this package a matter of adjusting LibreOffice to match, rather than just a
random unrelated theme.

I don't know if there's a reasonable way to make LibreOffice default to this
theme when started from Deepin -- if not, it'd require a manual action from
the user, which hardly anyone is going to do.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...



Bug#883297: "Packages: list" field removed from tasksel control file

2018-01-16 Thread Wolfgang Schweer
Hi Andreas,

On Tue, Jan 16, 2018 at 10:06:26PM +0100, Andreas Tille wrote:
> On Tue, Jan 16, 2018 at 05:46:34PM +0100, Wolfgang Schweer wrote:
> > 
> > After having cloned the debian-med repo:
> > The generated debian-med-tasks.desc file seems to be  ok. Further, the 
> > content is similar to the one available here:
> > https://sources.debian.org/src/debian-med/3.0.1/debian-med-tasks.desc/
> > (which contained neither a 'Packages: list').
> > 
> > Also, the generated .deb packages seem to be ok.
> 
> Good.  Now try
> 
> make dist
> 
> and check the diff.  That's my point.  I have not commited what
> I consider broken.

I guess I should have been more verbose:

What I ment with 'generated' was the output of 'make dist' for the tasks 
desc file; I ran 'git status' and 'git diff' as well. Afterwards I ran 
'debuild -- binary'.  The Debian packages seem to be ok.

> > Like suspected: if 'TASKSELOPT = -u' is added to the debian-med 
> > Makefile, the generated debian-med-tasks.desc file has a content like 
> > the one contained in git.

What I meant and did is: Change the Makefile like stated above and run 
'make dist' again. (I just wanted to understand what's going on.)
This time the generated debian-med-tasks.desc file is similar to the one 
in git as shown by 'git diff'.
 
> The Makefile is not changed since years.

Strange, indeed. I'm at a loss here…
 
But, with the exception of the existing (with unexplicable content) 
debian-med-tasks.desc file, things are IMO fine. 

I also did an 'apt source debian-astro' on sid and compared. Their 
tasks.desc file, too, has no 'Packages: list' section.

So I guess you can use everything as is and this bug could be closed.

Wolfgang


signature.asc
Description: PGP signature


Bug#776433: dict-devil: please make the build reproducible

2018-01-16 Thread Sven Joachim
On 2018-01-17 03:13 +0530, Chris Lamb wrote:

> Hi Sven Joachim,
>
>> After touching debian/copyright, I got the same package as you, and
>> touching all files in debian/ finally gave me the same .dsc as yours.
>
> Shall I go ahead and upload?

Yes, please do so.

Cheers,
   Sven



Bug#887464: guacamole: Can't set language or remote protocol, can't create connections

2018-01-16 Thread Fabian Rodriguez
Package: guacamole
Version: 0.9.9+dfsg-1
Severity: important

Dear Maintainer,

After installing Guacamole when adding a new connection several protocol 
options should be available (RDP, SSH, VNC). The dropdown list is empty and as 
a result new connections can't be added making the package unusable.

This may be related to Bug #870607.

In user preferences several languages should also be available. The dropdown 
list there is also empty.

As a workaround, the client ("web application") can be downloaded from upstream 
and deployed in the same environment. I've described this in the Debian wiki at 
https://wiki.debian.org/Guacamole.

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

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

Versions of packages guacamole depends on:
ii  debconf [debconf-2.0]1.5.61
ii  guacd0.9.9-2
ii  libatinject-jsr330-api-java  1.0+ds1-2
ii  libcommons-codec-java1.10-1
ii  libguava-java19.0-1
ii  libguice-java4.0-3
ii  libjackson-json-java 1.9.2-8
ii  libjersey1-core-java 1.19.3-1
ii  libjersey1-guice-java1.19.3-1
ii  libjersey1-json-java 1.19.3-1
ii  libjersey1-server-java   1.19.3-1
ii  libjs-angularjs  1.5.10-1
ii  libjs-jquery 3.1.1-2
ii  libjs-lodash 4.16.6+dfsg-2
ii  libjsr311-api-java   1.1.1-1
ii  liblogback-java  1:1.1.9-3
ii  libservlet3.1-java   8.5.14-1+deb9u2
ii  libslf4j-java1.7.22-1
ii  tomcat8  8.5.14-1+deb9u2

Versions of packages guacamole recommends:
ii  apache2 [httpd]  2.4.25-3+deb9u3

Versions of packages guacamole suggests:
pn  xrdp  

-- Configuration Files:
/etc/guacamole/guacamole.properties changed:
guacd-hostname: localhost
guacd-port: 4822
mysql-hostname: localhost
mysql-port: 3306
mysql-database: guacamole_db
mysql-username: guacamole_user
mysql-password: some_password

-- debconf information:
* guacamole-tomcat/restart-server: true



Bug#776433: dict-devil: please make the build reproducible

2018-01-16 Thread Chris Lamb
Hi Sven Joachim,

> After touching debian/copyright, I got the same package as you, and
> touching all files in debian/ finally gave me the same .dsc as yours.

Shall I go ahead and upload?


Regards,

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



Bug#887421: [Aptitude-devel] Bug#887421: dpkg: warning: unable to delete old directory '/usr/share/man/gl/man8': Directory not empty

2018-01-16 Thread Manuel A. Fernandez Montecelo

Control: tag -1 + pending


Hi,

2018-01-16 13:14 Axel Beckert:

Control: retitle -1 aptitude-common: Missing Breaks/Replaces against aptitude 
for moving man pages around
Control: severity -1 important
Control: tag -1 + confirmed

[...]


Yeah, sorry, I forgot to add those, thanks for noticing and for the
diagnosis.

Added now, and will uploading in a bit, marking as pending in the
meantime.


Cheers.
--
Manuel A. Fernandez Montecelo 



Bug#860366: okular: Okular crashes when opening some documents

2018-01-16 Thread Michael Weghorn
Hi Rainer,

thanks for the quick reply.

Let's close the bug report then as you suggested.

Regards,
  Michael

On 2018-01-16 22:23, Rainer Dorsch wrote:
> Hi Michael,
> 
> thanks for testing.
> 
> It works here now as well on stable. I switched though from i386 to amd64 in 
> the meantime. Since it uses an enormous amount of memory > 2GB you might hit 
> it only on i386
> 
> I suggest to close the issue, when somebody repros it, it can be reopened
> 
> Thanks
> Rainer
> 
> Am Dienstag, 16. Januar 2018, 18:26:12 CET schrieben Sie:
>> tags 860366 moreinfo
>> thanks
>>
>> Hi Rainer,
>>
>> I just tried to reproduce the crash with the mentioned file. With the
>> Okular version in current Debian testing/unstable (4:17.08.3-2), I
>> cannot reproduce the problem, the file opens fine for me.
>>
>> Does the problem still occur there for you?
>>
>> Regards,
>>   Michael
> 
> 



Bug#887420: RFS: deepin-icon-theme/15.12.52-1 [ITP]

2018-01-16 Thread Adam Borowski
On Tue, Jan 16, 2018 at 04:52:04PM +0800, Yangfl wrote:
>  * Package name: deepin-icon-theme

> It builds those binary packages:
> 
>   deepin-icon-theme - Deepin Icon Theme

It provides both an icon and a cursor theme, it'd be good to mention this.

Also, the priority for x-cursor-theme looks a wee bit inflated.
I'm not sure what's a good value, though.  The problem is, the priority is
shared between all installed desktop environments, affecting the system
globally -- while one would expect an environment to pick its own default
unless overridden by the user.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...



Bug#883297: "Packages: list" field removed from tasksel control file

2018-01-16 Thread Andreas Tille
Hi Wolfgang,

On Tue, Jan 16, 2018 at 05:46:34PM +0100, Wolfgang Schweer wrote:
> 
> After having cloned the debian-med repo:
> The generated debian-med-tasks.desc file seems to be  ok. Further, the 
> content is similar to the one available here:
> https://sources.debian.org/src/debian-med/3.0.1/debian-med-tasks.desc/
> (which contained neither a 'Packages: list').
> 
> Also, the generated .deb packages seem to be ok.

Good.  Now try

make dist

and check the diff.  That's my point.  I have not commited what
I consider broken.
 
> Like suspected: if 'TASKSELOPT = -u' is added to the debian-med 
> Makefile, the generated debian-med-tasks.desc file has a content like 
> the one contained in git.

The Makefile is not changed since years.

Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#886994: src:speech-tools: please package new version of speech-tools

2018-01-16 Thread Paul Gevers
Control: tags -1 pending

On Fri, 12 Jan 2018 12:10:11 +0100 Paul Gevers  wrote:
> This is a heads up that I am working on packaging the 2.5.0 version of
> speech-tools. As the changes that I want/need to make to the package are more
> involved (and thus may take some time to properly implement and test) I want 
> to
> avoid duplicate work by filing myself as owner of this bug.

I am building right now and will upload to experimental once it is
finished. It will have to go through NEW. Then I'll discuss with the
release team about transitions (although I expect I can handle myself).

Paul



signature.asc
Description: OpenPGP digital signature


Bug#851271: sslsplit: cachedsess.c(kh_dynbuf_hash_func) invokes undefined behavior

2018-01-16 Thread Daniel Roethlisberger
Thanks, I've just fixed this upstream:

https://github.com/droe/sslsplit/commit/f7e5c084a6ae0559682e15ed7cc5d05d2d94f802

-Daniel

-- 
Daniel Roethlisberger
http://daniel.roe.ch/



Bug#777089: Next python-mote pre-condition test issue: python-jsondiff trows ModuleNotFoundError: No module named 'nose_random'

2018-01-16 Thread Andreas Tille
Hi,

when continuing to check preconditions for python-moto my next target
is python-jsondiff[1].  When trying to build I get:


...
I: pybuild base:184: cd 
/build/python-jsondiff-1.1.1/.pybuild/pythonX.Y_3.6/build; python3.6 -m 
unittest discover -v 
tests (unittest.loader._FailedTest) ... ERROR

==
ERROR: tests (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: tests
Traceback (most recent call last):
  File "/usr/lib/python3.6/unittest/loader.py", line 462, in _find_test_path
package = self._get_module_from_name(name)
  File "/usr/lib/python3.6/unittest/loader.py", line 369, in 
_get_module_from_name
__import__(name)
  File 
"/build/python-jsondiff-1.1.1/.pybuild/pythonX.Y_3.6/build/tests/__init__.py", 
line 7, in 
from nose_random import randomize
ModuleNotFoundError: No module named 'nose_random'


--
Ran 1 test in 0.000s
...


My web search for a module named 'nose_random' remained empty.

Any idea what might be wrong here?

Kind regards

Andreas.

[1] https://salsa.debian.org/science-team/python-jsondiff.git

-- 
http://fam-tille.de



Bug#887463: qtwebkit-opensource-src: Please update symbols file for sh4

2018-01-16 Thread John Paul Adrian Glaubitz
Source: qtwebkit-opensource-src
Version: 5.212.0~alpha2-6
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh4

Hi!

After reducing the optimization level for qtwebkit-opensource-src on
sh3/sh4 to -O1, I was able to build the package on sh4. However, the
build eventually failed as the symbols file was outdated.

I have use the symbols helper from pkg-kde-tools to update the symbols
file from the build log.

Please apply the attached patch to update the symbols file.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
diff -Nru 
old/qtwebkit-opensource-src-5.212.0~alpha2/debian/libqt5webkit5.symbols 
new/qtwebkit-opensource-src-5.212.0~alpha2/debian/libqt5webkit5.symbols
--- old/qtwebkit-opensource-src-5.212.0~alpha2/debian/libqt5webkit5.symbols 
2018-01-09 16:38:23.0 +0100
+++ new/qtwebkit-opensource-src-5.212.0~alpha2/debian/libqt5webkit5.symbols 
2018-01-16 21:17:50.403141337 +0100
@@ -1,4 +1,4 @@
-# SymbolsHelper-Confirmed: 5.212.0~alpha2 amd64 arm64 armel armhf hppa 
hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64 
ppc64el s390x
+# SymbolsHelper-Confirmed: 5.212.0~alpha2 amd64 arm64 armel armhf hppa 
hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64 
ppc64el s390x sh4
 libQt5WebKit.so.5 libqt5webkit5 #MINVER#
  WKAccessibilityEnableEnhancedAccessibility@Base 5.212.0~alpha2
  WKAccessibilityEnhancedAccessibilityEnabled@Base 5.212.0~alpha2
@@ -1903,7 +1903,7 @@
  _ZN25QWebNotificationPresenter16staticMetaObjectE@Base 5.212.0~alpha2
  _ZN25QWebNotificationPresenter18notificationClosedEv@Base 5.212.0~alpha2
  _ZN25QWebNotificationPresenter19notificationClickedEv@Base 5.212.0~alpha2
- (arch=sh4)_ZN3WTF9dataLogFVEPKc13__va_list_tag@Base 5.9.1
+#MISSING: 5.212.0~alpha2# (arch=sh4)_ZN3WTF9dataLogFVEPKc13__va_list_tag@Base 
5.9.1
  _ZN6WebKit16WebProcessMainQtEP15QGuiApplication@Base 5.0.2
  _ZN6WebKit18initializeWebKitQtEv@Base 5.0.2
  _ZN6WebKit20NetworkProcessMainQtEiPPc@Base 5.212.0~alpha2
@@ -1911,6 +1911,7 @@
  _ZN6WebKit24setImagePlatformResourceEPKcRK7QPixmap@Base 5.0.2
  
_ZN6WebKit28setWebKitWidgetsInitCallbackEPFPN7WebCore12QStyleFacadeEP15QWebPageAdapterE@Base
 5.0.2
  _ZN7WebCore19initializeWebCoreQtEv@Base 5.0.2
+ 
(optional=templinst|arch=sh4)_ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_jPKS8_13__va_list_tagEjSB_z@Base
 5.212.0~alpha2
  
(optional=templinst|arch=powerpc)_ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_jPKS8_P13__va_list_tagEjSB_z@Base
 5.212.0~alpha2
  (optional=templinst|arch=amd64 kfreebsd-amd64 
s390x)_ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_mPKS8_P13__va_list_tagEmSB_z@Base
 5.212.0~alpha2
  (optional=templinst|arch=hurd-i386 i386 kfreebsd-i386 ppc64 
ppc64el|subst)_ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_{size_t}PKS8_PcE{size_t}SB_z@Base
 5.212.0~alpha2
@@ -2192,6 +2193,14 @@
  _ZNK25QWebNotificationPresenter10metaObjectEv@Base 5.212.0~alpha2
  
(optional=templinst)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES5_St9_IdentityIS5_ESt4lessIS5_ESaIS5_EE4findERKS5_@Base
 5.212.0~alpha2
  
(optional=templinst)_ZNKSt8_Rb_treeINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt4pairIKS5_9TBehaviorESt10_Select1stIS9_ESt4lessIS5_ESaIS9_EE4findERS7_@Base
 5.4.2
+ 
(optional=templinst|arch=sh4)_ZNKSt8functionIFvN6WebKit12CallbackBase5ErrorEEEclES2_@Base
 5.212.0~alpha2
+ 
(optional=templinst|arch=sh4)_ZNKSt8functionIFvN7WebCore12PolicyActionEEEclES1_@Base
 5.212.0~alpha2
+ 
(optional=templinst|arch=sh4)_ZNKSt8functionIFvN7WebCore15HysteresisStateEEEclES1_@Base
 5.212.0~alpha2
+ (optional=templinst|arch=sh4)_ZNKSt8functionIFvbEEclEb@Base 5.212.0~alpha2
+ (optional=templinst|arch=sh4)_ZNKSt8functionIFvjEEclEj@Base 5.212.0~alpha2
+ 
(optional=templinst|arch=sh4)_ZNKSt8functionIFvjN6WebKit12CallbackBase5ErrorEEEclEjS2_@Base
 5.212.0~alpha2
+ (optional=templinst|arch=sh4)_ZNKSt8functionIFvvEEclEv@Base 5.212.0~alpha2
+ (optional=templinst|arch=sh4)_ZNKSt8functionIFvyEEclEy@Base 5.212.0~alpha2
  (optional=templinst|arch=hurd-i386 i386 kfreebsd-i386 mips 
mipsel)_ZNSt10_HashtableIxSt4pairIKxPdESaIS3_ENSt8__detail10_Select1stESt8equal_toIxESt4hashIxENS5_18_Mod_range_hashingENS5_20_Default_ranged_hashENS5_20_Prime_rehash_policyENS5_17_Hashtable_traitsILb0ELb0ELb121_M_insert_unique_nodeEjjPNS5_10_Hash_nodeIS3_Lb0EEE@Base
 5.212.0~alpha2
  (optional=templinst|arch=hurd-i386 i386 kfreebsd-i386 mips 

Bug#887462: qtwebkit-opensource-src: Please reduce optimization level on sh3/sh4 to -O1

2018-01-16 Thread John Paul Adrian Glaubitz
Source: qtwebkit-opensource-src
Version: 5.212.0~alpha2-6
Severity: normal
Tags: patch
User: debian-sup...@lists.debian.org
Usertags: sh3 sh4

Hi!

Due to an upstream bug in gcc [1], both webkit2gtk and qtwebkit-opensource-src
fail to build from source on sh4 (and consequently sh3):

../Source/JavaScriptCore/heap/ConservativeRoots.cpp: In member function 'void 
JSC::ConservativeRoots::add(void*, void*, JSC::JITStubRoutineSet&, 
JSC::CodeBlockSet&)':
../Source/JavaScriptCore/heap/ConservativeRoots.cpp:145:1: error: unable to 
find a register to spill in class 'R0_REGS'
 }
 ^
../Source/JavaScriptCore/heap/ConservativeRoots.cpp:145:1: error: this is the 
insn:
(insn 23 122 28 2 (parallel [
(set (subreg:SI (reg:QI 182) 0)
(unspec_volatile:SI [
(mem/v:QI (reg/f:SI 4 r4 [orig:162 _1 ] [162]) [-1  S1 
A8])
(reg:QI 184)
(reg:QI 186)
] UNSPECV_CMPXCHG_1))
(set (mem/v:QI (reg/f:SI 4 r4 [orig:162 _1 ] [162]) [-1  S1 A8])
(unspec_volatile:QI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_2))
(set (reg:SI 147 t)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_CMPXCHG_3))
(clobber (scratch:SI))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
]) "/usr/include/c++/7/bits/atomic_base.h":434 403 
{atomic_compare_and_swapqi_soft_gusa}
 (expr_list:REG_DEAD (reg:QI 186)
(expr_list:REG_DEAD (reg:QI 184)
(expr_list:REG_UNUSED (reg:QI 182)
(expr_list:REG_UNUSED (reg:SI 1 r1)
(expr_list:REG_UNUSED (reg:SI 0 r0)
(nil)))
../Source/JavaScriptCore/heap/ConservativeRoots.cpp:145: confused by earlier 
errors, bailing out

This error can be worked around by reducing the optimization level to -O1
which is what the attached patch is enabling in the debian/rules file.

Could you integrate this change into qtwebkit-opensource-src for the next
upload?

Thanks,
Adrian

> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
> [2] 
> https://buildd.debian.org/status/fetch.php?pkg=qtwebkit-opensource-src=sh4=5.212.0%7Ealpha2-6=1515522880=0

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- old/qtwebkit-opensource-src-5.212.0~alpha2/debian/rules 2018-01-09 
16:38:23.0 +0100
+++ new/qtwebkit-opensource-src-5.212.0~alpha2/debian/rules 2018-01-16 
17:30:08.481774799 +0100
@@ -20,6 +20,11 @@
export DEB_CXXFLAGS_MAINT_APPEND = -mfp32
 endif
 
+# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
+ifneq (,$(filter $(DEB_HOST_ARCH_CPU),sh3 sh4))
+   export DEB_CXXFLAGS_MAINT_APPEND = -O1
+endif
+
 # Disable gold linker on all architectures except x32
 ifneq ($(DEB_HOST_ARCH),x32)
EXTRA_CMAKE_ARGUMENTS += -DUSE_LD_GOLD=OFF


Bug#887461: btrfsmaintenance: blindly assumes systemd

2018-01-16 Thread Adam Borowski
Package: btrfsmaintenance
Version: 0.3.1-17-gf7d61e3-1~exp1
Severity: important

Hi!
The package, as currently provided, is non-functional without manual actions
on non-systemd systems.

During installation, there's an error:
/usr/bin/deb-systemd-helper: error: unable to read btrfsmaintenance-refresh.path

then the cron jobs are not installed by default.  According to README.Debian:

# # or run the script directly
# /usr/share/btrfsmaintenance/btrfsmaintenance-refresh-cron.sh
#
# Running the refresh-cron script is required on Debian or Debian-like
# systems that do not use systemd.

so fixing this should be a matter of just running this in appropriate places
(such as postinst; or, to be safe, during boot as well).

(I haven't actually tested the scripts yet -- having manually written ones
everywhere.)


Also, I don't see what's the point in using .service/.timer at all, as they
use no systemd-specific features, so this complicates maintenance for no gain.


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

Kernel: Linux 4.15.0-rc8-debug-00026-g18d1715aac67 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages btrfsmaintenance depends on:
ii  btrfs-progs  4.14.1-1

Versions of packages btrfsmaintenance recommends:
ii  cron  3.0pl1-128.1

btrfsmaintenance suggests no packages.

-- no debconf information



Bug#887460: nvidia-kernel-dkms: Laptop cannot start nvidia.ko when in battery mode

2018-01-16 Thread Volker Linke
Package: nvidia-kernel-dkms
Version: 384.111-3
Severity: important
Tags: a11y

Dear Maintainer,

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

   * What led up to the situation?

Didn't know, what made kernel-module nvidia start or did not start when booting.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Booting the laptop, which didn't make bumblebee run.

   * What was the outcome of this action?
   * What outcome did you expect instead?

Now knowing that you need online power supply for working with optimus when 
starting laptop.


-- Package-specific info:
uname -a:
Linux barberou 4.15.0-rc8-biscuit-de-barberou #56 SMP Mon Jan 15 15:23:06 CET 
2018 x86_64 GNU/Linux

/proc/version:
Linux version 4.15.0-rc8-biscuit-de-barberou (voli@barberou) (gcc version 7.2.0 
(Debian 7.2.0-19)) #56 SMP Mon Jan 15 15:23:06 CET 2018

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  384.111  Tue Dec 19 23:51:45 
PST 2017
GCC version:  gcc version 7.2.0 (Debian 7.2.0-19) 

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:591b] 
(rev 04) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device [103c:825d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

01:00.0 3D controller [0302]: NVIDIA Corporation GP107M [GeForce GTX 1050 
Mobile] [10de:1c8d] (rev a1)
Subsystem: Hewlett-Packard Company GP107M [GeForce GTX 1050 Mobile] 
[103c:825d]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.252006] pci :00:02.0: vgaarb: setting as boot VGA device
[0.252006] pci :00:02.0: vgaarb: VGA device added: 
decodes=io+mem,owns=io+mem,locks=none
[0.252009] pci :00:02.0: vgaarb: bridge control possible
[0.252010] vgaarb: loaded
[0.678655] fb0: EFI VGA frame buffer device
[0.680719] Linux agpgart interface v0.103
[2.097560] bbswitch: Found integrated VGA device :00:02.0: 
\_SB_.PCI0.GFX0
[2.097566] bbswitch: Found discrete VGA device :01:00.0: 
\_SB_.PCI0.PEG0.PEGP
[2.198083] fb: switching to inteldrmfb from EFI VGA
[2.198299] [drm] Replacing VGA console driver
[2.206209] i915 :00:02.0: vgaarb: changed VGA decodes: 
olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   32.796829] nvidia: module license 'NVIDIA' taints kernel.
[   32.818227] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 245
[   32.818679] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  384.111  Tue Dec 
19 23:51:45 PST 2017 (using threaded interrupts)
[   33.316904] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for 
UNIX platforms  384.111  Tue Dec 19 22:56:18 PST 2017

Device node permissions:
crw-rw+ 1 root video 226,   0 Jan 16 20:45 /dev/dri/card0
crw-rw+ 1 root video 226, 128 Jan 16 20:45 /dev/dri/renderD128
crw-rw-rw-  1 root root  195, 254 Jan 16 20:46 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 Jan 16 20:46 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Jan 16 20:46 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root  8 Jan 16 20:45 pci-:00:02.0-card -> ../card0
lrwxrwxrwx 1 root root 13 Jan 16 20:45 pci-:00:02.0-render -> ../renderD128
video:x:44:voli

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root25 Jan 13 20:11 /etc/alternatives/glx -> 
/usr/lib/nvidia/bumblebee
lrwxrwxrwx 1 root root51 Jan 13 20:11 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libEGL.so.1
lrwxrwxrwx 1 root root48 Jan  5 13:12 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root48 Jan  5 13:12 
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root50 Jan 13 20:11 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root50 Jan 13 20:11 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1
lrwxrwxrwx 1 root root54 Jan 13 20:11 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root54 Jan 13 20:11 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2
lrwxrwxrwx 1 root root42 Jan 13 

Bug#828483: osslsigncode: FTBFS with openssl 1.1.0

2018-01-16 Thread Stephen Kitt
Hi Raphaël,

On Tue, 16 Jan 2018 17:15:08 +0100, Raphael Hertzog 
wrote:
> On Sun, 26 Jun 2016, Stephen Kitt wrote:
> > On Sun, 26 Jun 2016 12:23:30 +0200, Kurt Roeckx  wrote:  
> > > If you have problems making things work, feel free to contact us.  
> > 
> > I've managed to fix most of the build issues, the remaining issue I'm
> > faced with is the apparent disappearance of the STACK API
> > (DECLARE_STACK_OF()) etc. What should I be using instead?  
> 
> There's a patch that has been submitted to upstream here:
> https://sourceforge.net/p/osslsigncode/patches/10/
> https://sourceforge.net/p/osslsigncode/patches/10/attachment/0001-Make-code-work-with-OpenSSL-1.1.patch
> 
> It removes (not very cleanly) the "pagehash" functionality alltogether to
> avoid this problem (-ph command line option).

The last time I checked that patch I ran into validation errors, not the same
as those reported by Develar, but I’d have to check again.

> This package has already been dropped out of testing so it would be
> nice if we could complete this OpenSSL 1.1 transition to bring
> it back into Debian testing.
> 
> Per, do you have plans to make osslsigncode compatible with OpenSSL 1.1?
> Could you review the above patch and work with Reimar Döffinger and/or
> Stephen Kitt to have something suitable for merge?

Hilko’s patch at
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=828483;msg=70 is also
useful.

I’ve been meaning to look into all this further, but help is welcome.

Regards,

Stephen


pgpBqw5WnEPOw.pgp
Description: OpenPGP digital signature


Bug#887404: libreoffice: LibreOffice eats up 100%CPU even without any document loaded

2018-01-16 Thread Rene Engelhard
forwarded 887404 https://bugs.documentfoundation.org/show_bug.cgi?id=108246
close 887404 1:6.0.0~rc1-1
thanks

Hi,

On Tue, Jan 16, 2018 at 12:59:47PM +, victor.bo...@disroot.org wrote:
>I found that this bug came back since libglib2.0-* packages were upgraded
>from 2.54.2-5 (previous testing version) to 2.54.3-1 (unstable ->
>testing). Reverting to the previous testing version solves the problem.

Ah, OK, thanks for the info.

>https://bugs.documentfoundation.org/show_bug.cgi?id=108246

Thanks even more for this. comment 18
(https://bugs.documentfoundation.org/show_bug.cgi?id=108246#c18) even
says that 6.0 is not affected by this anymore which I tried to confirm
in my replies to the bug so far but Maria didn't reply to...

Let's close it then with the proper version.

Regards,

Rene



Bug#877849: [tryton-debian] Namespace conflict for python-magic

2018-01-16 Thread Christoph Biedl
Christoph Biedl wrote...

> Adam Hupp wrote...

> > - disable the deprecation warning. this wouldn't actually show
> > anything by default unless you run python with the warning enabled
> > (-Wd), but until there's a clear plan for the future of this package
> > it seems premature to declare deprecation.
> 
> Um, I cannot see that one.

Got it, so never mind.

Christoph


signature.asc
Description: Digital signature


Bug#887458: shelxle FTBFS on armel/armhf: fatal error: GL/glu.h: No such file or directory

2018-01-16 Thread Adrian Bunk
Source: shelxle
Version: 1.0.886-2
Severity: serious

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

...
In file included from molecule.cpp:19:0:
./molecule.h:37:10: fatal error: GL/glu.h: No such file or directory
 #include 
  ^~
compilation terminated.
Makefile:738: recipe for target 'molecule.o' failed
make[1]: *** [molecule.o] Error 1


Different from all other architectures, Qt5 is on armel/armhf
(and arm64 on Ubuntu) built with OpenGL ES.

Ideally it should be made working to build when Qt is using
OpenGL ES, but if that is not possible:
- avoid the FTBFS by changing the build dependency from
  libqt5opengl5-dev to libqt5opengl5-desktop-dev, and
- submit a bug against ftp.debian.org asking for removal
  of the old armel/armhf binaries



Bug#887459: cdo FTBFS on big endian: FAIL: test_resource_copy

2018-01-16 Thread Adrian Bunk
Source: cdo
Version: 1.9.2+dfsg.1-4
Severity: serious

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

...
make  check-TESTS
make[4]: Entering directory '/<>/cdo-1.9.2+dfsg.1/libcdi/tests'
PASS: cksum_verify
PASS: test_cksum_grib
PASS: test_cksum_nc
PASS: test_cksum_extra
PASS: test_cksum_service
PASS: test_cksum_nc2
PASS: test_cksum_nc4
PASS: test_cksum_ieg
PASS: test_chunk_cksum
PASS: pio_write_run
SKIP: pio_cksum_mpinonb
SKIP: pio_cksum_fpguard
SKIP: pio_cksum_asynch
SKIP: pio_cksum_writer
SKIP: pio_cksum_cdf
SKIP: pio_cksum_mpi_fw_ordered
SKIP: pio_cksum_mpi_fw_at_all
SKIP: pio_cksum_mpi_fw_at_reblock
FAIL: test_resource_copy
PASS: pio_write_deco2d_run
PASS: test_cdf_transformation
PASS: test_cdf_const
PASS: test_table
PASS: test_byteswap
=
1 of 16 tests failed
(8 tests were not run)
Please report to http://mpimet.mpg.de/cdi
=
Makefile:828: recipe for target 'check-TESTS' failed
make[4]: *** [check-TESTS] Error 1



Bug#884371: Hangs on boot without messages

2018-01-16 Thread Salvatore Bonaccorso
Control: forcemerge 883938 884371
Control: tags 884371 - moreinfo

Hi Sven,

On Tue, Jan 16, 2018 at 03:29:54PM +0100, Sven Bartscher wrote:
> Hi Salvatore,
> 
> On Thu, 14 Dec 2017 20:42:48 +0100 Salvatore Bonaccorso
>  wrote:
> > Hi Sven!
> > 
> > On Thu, Dec 14, 2017 at 06:20:14PM +0100, Sven Bartscher wrote:
> > > Hi Salvatore,
> > > 
> > > Am 14.12.2017 um 17:33 schrieb Salvatore Bonaccorso:
> > > > Just to confirm, the output is not logged to any console you are
> > > > capturing?
> > > 
> > > That's a good question. There might actually be another console where
> > > the output is going. I will definitely check this the next time it's
> > > possible.
> > > 
> > > > Is this the same issue as #883938
> > > 
> > > Depends on the output I might see on the serial console.
> > > 
> > > > There are test-kernels available at https://bugs.debian.org/883938#170
> > > > which is pending to be scheudled via a jessie-updates upload.
> > > 
> > > I will try if they work as soon as possible. Unfortunately, we can only
> > > schedule the next downtime next month. I will post then (or sooner if an
> > > unplanned opportunity arrises).
> > 
> > Alright, thanks. I will mark it for now as moreinfo, please let us
> > know as soon you get a chance to confirm either the duplication of
> > #883938 or when more infos with the 3.16.51-3 kernel are avaiable[*].
> 
> We tried 3.16.51-3+deb8u1 today and it booted without problems, so I
> guess this was actually the same issue as #883938 and the output was
> missing for some other reason.

Alright thanks for reporting back! I'm merging then the two reports,
since I'm quite confident it was then the same issue.

Regards,
Salvatore



Bug#887369: RFS: libreoffice-style-papirus/20170228-1 [ITP]

2018-01-16 Thread Adam Borowski
On Tue, Jan 16, 2018 at 04:57:46PM +0800, Yangfl wrote:
> Actually upstream said maybe they don't need a package (see
> https://github.com/PapirusDevelopmentTeam/papirus-libreoffice-theme/issues/13#issuecomment-357725329

I don't know about LibreOffice (I use it about once a year), but Firefox
extensions, while also supposed to be handled by the program itself, are
packaged quite often.

> ) and others are concerned about the maintaince (
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887367#10 ).

A side package of a very active upstream doesn't sound like something that's
in any risk.  Worst case, you'd need to steal a few icons from the main
project or another theme.


Also, of the two themes I maintain:
* chameleon-cursor-theme: dead upstream for 11 years
  Fixes I had to do since then involved reducing some images to 64x64 (some
  drivers are buggy wrt cursors bigger than that) by shortening their
  shadows, and assigning a whole new set of symlinks to existing ones (KDE
  had an overhaul of names they expect), fortunately without needing any
  actual new ones.
* darkcold-gtk-theme: dead upstream even before I packaged it, I had to do
  non-trivial upstreamish work to port it to GTK3.22.  Still worth the
  effort as Debian didn't have any black theme (at most middle-gray).

An icon theme might be more work than a cursor or window theme as whatever
needs the new icon would borrow from another theme and thus look out of
place.

> You can have another opinion. If not I will close the RFS and ITP in
> the next few days.

This is your time, no one has the right to tell you what to work on (at
least not in Debian).  You maintain a diverse set of packages, so a theme
that's not a part of your main area has a pretty low priority.

Thus, my opinion is:
* neither of the concerns raised is a show-stopper, but
* a decision to prioritize other packages over mere eye-candy is valid
  (especially when it turns out it's not as trivial as it seemed)


喵!

> 2018-01-16 7:05 GMT+08:00 Adam Borowski :
> > On Mon, Jan 15, 2018 at 11:02:14PM +0800, Yangfl wrote:
> >> I am looking for a sponsor for my package "libreoffice-style-papirus"
> >> https://github.com/PapirusDevelopmentTeam/papirus-libreoffice-theme

> > I'm afraid that the orig tarball has a stray set of .zips in it, with all of
> > the images doubled: every file stands both on its own, and inside one of the
> > .zips.
> >
> > Thus, could you please repack the .orig?

-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Imagine there are bandits in your house, your kid is bleeding out,
⢿⡄⠘⠷⠚⠋⠀ the house is on fire, and seven big-ass trumpets are playing in the
⠈⠳⣄ sky.  Your cat demands food.  The priority should be obvious...



Bug#877849: [tryton-debian] Namespace conflict for python-magic

2018-01-16 Thread Christoph Biedl
Adam Hupp wrote...

> Whew, I was worried for a moment :)  I've pushed an update to the
> branch

Great to see.

> Changes:
> - disable the deprecation warning. this wouldn't actually show
> anything by default unless you run python with the warning enabled
> (-Wd), but until there's a clear plan for the future of this package
> it seems premature to declare deprecation.

Um, I cannot see that one. However, there is a version bump, but in the
libmagic-compat branch only while I'd expect that one in master. Care to
check?

> - fix the libmagic test under python3.  this is actually a bug in the
> libmagic python bindings but I'd rather not make changes there.

ACK

Christoph


signature.asc
Description: Digital signature


Bug#887457: freecad crashes with SIGSEGV if want to create a curve on a cylinder edge

2018-01-16 Thread Robert Richter
Package: freecad
Version: 0.16+dfsg2-3
Severity: normal

Dear Maintainer,

I want to create an round edge on a cylinder.

And than freecad crashes or freeze with gdb:

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
FreeCAD 0.16, Libs: 0.16R
© Juergen Riegel, Werner Mayer, Yorik van Havre 2001-2015
  #   ###   
  ##  # #   #   #
  # ##     # #   #  #   #
    # # #  # #  #  # #  #   #
  # #      ## # #   #
  # #   ## ## # #   #  ##  ##  ##
  # #       ### # #    ##  ##  ##

[New Thread 0x7fffd6273700 (LWP 30276)]
[New Thread 0x7fffd5838700 (LWP 30277)]
[New Thread 0x7fffd5037700 (LWP 30278)]
[New Thread 0x7fffd4836700 (LWP 30279)]
[New Thread 0x7fffd4035700 (LWP 30280)]
[New Thread 0x7fffcbfff700 (LWP 30297)]
[New Thread 0x7fffcb7fe700 (LWP 30298)]
[New Thread 0x7fffcabfd700 (LWP 30299)]

Thread 1 "freecad" received signal SIGSEGV, Segmentation fault.
0x7fff78048d38 in Geom2d_Curve::Value(double) const ()
   from /usr/lib/x86_64-linux-gnu/libTKG2d.so.10
(gdb)



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

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

Versions of packages freecad depends on:
ii  libboost-atomic1.62.0   1.62.0+dfsg-4
ii  libboost-chrono1.62.0   1.62.0+dfsg-4
ii  libboost-date-time1.62.01.62.0+dfsg-4
ii  libboost-filesystem1.62.0   1.62.0+dfsg-4
ii  libboost-program-options1.62.0  1.62.0+dfsg-4
ii  libboost-python1.62.0   1.62.0+dfsg-4
ii  libboost-regex1.62.01.62.0+dfsg-4
ii  libboost-signals1.62.0  1.62.0+dfsg-4
ii  libboost-system1.62.0   1.62.0+dfsg-4
ii  libboost-thread1.62.0   1.62.0+dfsg-4
ii  libc6   2.24-11+deb9u2
ii  libcoin80v5 3.1.4~abc9f50+dfsg1-2
ii  libfreeimage3   3.17.0+ds1-5
ii  libfreetype62.6.3-3.2
ii  libgcc1 1:6.3.0-18
ii  libgl1-mesa-glx [libgl1]13.0.6-1+b2
ii  libglu1-mesa [libglu1]  9.0.0-2.1
ii  liboce-foundation10 0.17.2-2
ii  liboce-modeling10   0.17.2-2
ii  liboce-ocaf-lite10  0.17.2-2
ii  liboce-ocaf10   0.17.2-2
ii  liboce-visualization10  0.17.2-2
ii  libpyside1.21.2.2-2+b1
ii  libpython2.72.7.13-2+deb9u2
ii  libqt4-network  4:4.8.7+dfsg-11
ii  libqt4-opengl   4:4.8.7+dfsg-11
ii  libqt4-svg  4:4.8.7+dfsg-11
ii  libqt4-xml  4:4.8.7+dfsg-11
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libqtwebkit42.3.4.dfsg-9.1
ii  libshiboken1.2v51.2.2-3.1
ii  libsoqt4-20 1.6.0~e8310f-3
ii  libspnav0   0.2.3-1
ii  libstdc++6  6.3.0-18
ii  libx11-62:1.6.4-3
ii  libxerces-c3.1  3.1.4+debian-2
ii  libxext62:1.3.3-1+b2
ii  libzipios++0v5  0.1.5.9+cvs.2007.04.28-6
ii  pyside-tools0.2.15-1+b1
ii  python  2.7.13-2
ii  python-collada  0.4-2
ii  python-matplotlib   2.0.0+dfsg1-2
ii  python-pivy 0.5.0~v609hg-3.1
ii  python-ply  3.9-1
ii  python-pyside   1.2.2-2
ii  python2.7   2.7.13-2+deb9u2
ii  zlib1g  1:1.2.8.dfsg-5

freecad recommends no packages.

Versions of packages freecad suggests:
pn  graphviz  
pn  povray

-- no debconf information


Bug#887456: init-system-helpers: deb-systemd-helper does not honor the same package-relevant unit paths as systemd

2018-01-16 Thread Guillem Jover
Source: init-system-helpers
Source-Version: 1.51
Severity: normal
Tags: patch

Hi!

The current list of paths honored by deb-systemd-helper does not match
the one in systemd [L]. That's fine for several of them because they
are intended to be for run-time generated content, or local admin
content. There is still at least one that can be used by packages
depending on the distribution policy that is missing, i.e.
“/usr/local/lib/systemd/system”.

 [L] 


Thanks,
Guillem
From 99fb1880ce55a79a135a4dc60aa94fd88d7b362b Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Tue, 16 Jan 2018 19:07:44 +0100
Subject: [PATCH] Honor the same package-relevant unit paths as systemd
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The current list of paths honored by deb-systemd-helper does not match
the one in systemd. That's fine for several of them because they are
intended to be for run-time generated content, or local administrator
content. There is still at least one that can be used by packages
depending on the distribution policy that is missing, i.e.
“/usr/local/lib/systemd/system”.

Signed-off-by: Guillem Jover 
---
 script/deb-systemd-helper | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/script/deb-systemd-helper b/script/deb-systemd-helper
index 3d40d8d..5e630d5 100755
--- a/script/deb-systemd-helper
+++ b/script/deb-systemd-helper
@@ -122,6 +122,8 @@ sub find_unit {
 $service_path = "/etc/systemd/system/$scriptname";
 } elsif (-f "/lib/systemd/system/$scriptname") {
 $service_path = "/lib/systemd/system/$scriptname";
+} elsif (-f "/usr/lib/systemd/system/$scriptname") {
+$service_path = "/usr/lib/systemd/system/$scriptname";
 }
 return $service_path;
 }
-- 
2.15.1



Bug#776433: dict-devil: please make the build reproducible

2018-01-16 Thread Sven Joachim
On 2018-01-16 05:09 +0530, Chris Lamb wrote:

> Hi Sven,
>
>> > Odd, I get a099de2728c8dcf2ab38ed6b798b0ee39565c8a4 (reproducibly..)
>> 
>> That's not good.  Can you please send me the deb and the buildinfo file
>> so that I can investigate the discrepancy?
>
>   https://people.debian.org/~lamby/dict-devil_1.0-13_all.deb
>   https://people.debian.org/~lamby/dict-devil_1.0-13_amd64.buildinfo

Thanks, I found the problem and while the explanation is really simple
it unveiled an aspect of "reproducibility" that I had never considered
hitherto.

The reason why our packages differed is that in my git repository
debian/copyright had a timestamp older than $SOURCE_DATE_EPOCH whereas
you apparently cloned the repository afresh after the last change to
debian/changelog.  So /usr/share/doc/dict-devil/copyright had a
different timestamp too since dpkg-deb only clamps timestamps _after_
$SOURCE_DATE_EPOCH.

After touching debian/copyright, I got the same package as you, and
touching all files in debian/ finally gave me the same .dsc as yours.

For a long time I had wondered why my supposedly reproducible packages
often produced different .debs when building directly from git than via
pbuilder.  Now I know why, switching branches in git changed the mtime
of upstream files!

Conclusion: while one can expect identical binary packages when building
from a freshly unpacked source package, neither source nor binary
packages can be expected to be deterministic when building from a git
repository due to the random timestamps.

Cheers,
   Sven



Bug#299007: Transitioning perms of /usr/local

2018-01-16 Thread Russ Allbery
Adding the bug instead of debian-policy@.

Ian Jackson  writes:
> Don Armstrong writes ("Re: Bug#299007: Transitioning perms of /usr/local"):

>> Thanks for doing this work! The original wording took me a few readings
>> to parse; I suggest this instead:
>> 
>>  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 /etc/staff-group-for-usr-local exists,
>>  /usr/local and subdirectories should have permissions 2775
>>  (group-writable and set-group-id) and be owned by "root:staff".

> SGTM.  (AKA "seconded".)

Seconded.

Thank you for bringing this back to life, Santiago!  I've been wanting to
resolve this for some time.

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



Bug#299007: Transitioning perms of /usr/local

2018-01-16 Thread Ian Jackson
Santiago Vila writes ("Bug#299007: Transitioning perms of /usr/local"):
> [ I, for one, would prefer to reunificate with Ubuntu in this issue
>   and get rid of staff completely, but this is just my opinion ]
> 
> Should we maybe ask TC again about this? A lot of time have elapsed
> since they made their decision, and the world has changed a lot since
> then.

None of the reasons why I like to use the group staff the way I do
have changed.  See
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484841#62

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#880920: Document Rules-Requires-Root field

2018-01-16 Thread Ian Jackson
Josh Triplett writes ("Bug#880920: Document Rules-Requires-Root field"):
> On Fri, 29 Dec 2017 11:29:00 + Niels Thykier  wrote:
> > +  # Command "sudo", with arguments "-nE" and "--"
> > +  export DPKG_GAIN_ROOT_CMD='sudo -nE --'
> > +  # Command "fakeroot" with the single argument "--"
> > +  export DPKG_GAIN_ROOT_CMD='fakeroot --'
> 
> You use sudo with -E here to preserve the environment. If that's a
> requirement, then the preceding paragraph should explicitly say
> something like "the command must preserve all environment variables,
> unmodified".

I think the environment does need to be preserved, indeed.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.



Bug#887455: RFP: idemptables -- idempotent iptables wrapper

2018-01-16 Thread Sam Kuper
Package: wnpp
Severity: wishlist

* Package name: idemptables
  Version : 2012
  Upstream Author : Xyne 
* URL : https://xyne.archlinux.ca/projects/idemptables/
* License : GPLv2
  Programming Lang: sh
  Description : Idempotent iptables wrapper for appending and
deleting rules.

Idempotent iptables wrapper for appending and deleting rules.



Bug#887454: console_bridge: Update console_bridge package to version 0.4.0

2018-01-16 Thread Jose Luis Rivero
Package: console_bridge
Severity: wishlist

consolde_bridge released the version 0.4.0 some time ago. It would be
good to have it into Debian Sid.



Bug#887453: libunwind: please disable lzma on ia64

2018-01-16 Thread Jason Duerstock
Source: libunwind
Severity: normal
Tags: patch
User: debian-i...@lists.debian.org
Usertags: ia64

Dear Maintainer,

For the ia64 port, we would like to disable lzma support for ia64, as it has 
caused several packages
to fail building when static linking is used.  (gcc doesn't know to include 
liblzma.a when it tries to
include libunwind.a).

The attached patch should accomplish this.

We will re-enable it once we've determined a good way to work through this 
problem.

Thanks,

Jason


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

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- debian/control.orig 2018-01-16 10:06:58.752562266 -0500
+++ debian/control  2018-01-16 10:07:19.420483094 -0500
@@ -2,8 +2,8 @@
 Priority: optional
 Section: libs
 Maintainer: Adrian Bunk 
-Build-Depends: debhelper (>= 10), liblzma-dev , 
texlive-extra-utils
-Build-Conflicts: liblzma-dev 
+Build-Depends: debhelper (>= 10), liblzma-dev [!ia64] , 
texlive-extra-utils
+Build-Conflicts: liblzma-dev [ia64] 
 Standards-Version: 4.1.1
 Homepage: http://www.nongnu.org/libunwind
 


Bug#887452: libkf5config-bin-dev is not useful for cross compilation

2018-01-16 Thread Helmut Grohne
Package: libkf5config-bin-dev
Version: 5.41.0-1
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:okular

libkf5config-bin-dev is not useful for cross compilation. Unfortunately,
I don't know how to fix it, so this bug comes without a patch. I'm sorry
about that. Still let me explain the things I understood thus far.

Observation 1
~
While building okular, I see:

| [  8%] Generating settings_core.h, settings_core.cpp
| /usr/lib/mips-linux-gnu/libexec/kf5/kconfig_compiler_kf5 
/<>/conf/okular_core.kcfg 
/<>/conf/settings_core.kcfgc -d 
/<>/obj-mips-linux-gnu/
| /usr/lib/mips-linux-gnu/libexec/kf5/kconfig_compiler_kf5: 1: 
/usr/lib/mips-linux-gnu/libexec/kf5/kconfig_compiler_kf5: Syntax error: "(" 
unexpected
| CMakeFiles/okularcore_autogen.dir/build.make:76: recipe for target 
'settings_core.h' failed

This means that kconfig_compiler_kf5 was needed for execution (aka build
architecture), but was actually installed for the host architecture.
Likely some package needs Multi-Arch: foreign.

Observation 2
~
The libkf5config-dev -> libkf5config-bin-dev split is odd. Splitting
executables from a -dev package is common, but then the package
containing the executables is usually marked Multi-Arch: foreign. Not so
here! libkf5config-bin-dev is marked Multi-Arch: same. This is very
unusual as it removes the benefit of the libkf5config-dev <->
libkf5config-bin-dev split. At present, those packages could simply be
merged without regressing anything.

The Multi-Arch: same marking does have a little merit though: The
package ships most of its file on architecture-dependent paths and when
that happens, we usually use Multi-Arch: same. Just in this case it
turns out to not be useful.

Also usually the package containing the executables is called -dev-bin
rather than -bin-dev.

Observation 3
~
Simply marking libkf5config-bin-dev Multi-Arch: foreign likely is wrong
in a number of ways:
 * It contains .cmake files on an architecture-dependent path. That's
   not reasonable for Multi-Arch: foreign. Likely those can be moved to
   libkf5config-dev. (Don't forget Breaks + Replaces!)
 * The kconfig_compiler_kf5 lives on an architecture-dependent path.
   That's inappropriate for Multi-Arch: foreign as well. If we add such
   a marking, the path needs to be moved. Fortunately, it seems to be
   referenced exclusively via a path mentioned in
   KF5ConfigCompilerTargets-debian.cmake, so updating that file with
   a new path might be sufficient.
 * Then the question arises whether kconfig_compiler_kf5 is eligible for
   being marked Multi-Arch: foreign at all. That's not a given. The
   question to be asked here is whether its interface is
   architecture-dependent.

   Its main method to communicate with a user is the command line as
   well as two input files (.kcfg and .kcgfc) and some output files. The
   .kcfg file seems to be XML, the .kcfgc file seems to be some textual
   variable assignment syntax and the output seems to be a C++ header
   and source file. All of these are text files and that usually means
   that Multi-Arch: foreign is correct.

Plan

I think making libkf5config-bin-dev Multi-Arch: foreign is the right
approach. For consistency with other packages, it should be renamed to
libkf5config-dev-bin (optional). For the marking to be correct,
kconfig_compiler_kf5 needs to live on an architecture-independent path
(needs to be moved) and the .cmake files need to be moved to
libkf5config-dev.

Can someone make that work? Or maybe support me in figuring how to
implement that?

Helmut



Bug#886630: linux-image-3.2.0-5-amd64 Kernel panic after upgrading when use hidepid Debian wheezy

2018-01-16 Thread Ben Hutchings
On Tue, 2018-01-16 at 13:56 +0100, Niels Hendriks wrote:
> Hi Ben,
> 
> Thanks for your response. Is there any ETA for when the new version will be
> released ?

No, there isn't.

> We'd like to patch the Meltdown vulnerability and also keep
> hidepid enabled, but currently the system is unusable with this kernel and
> hidepid enabled. We tried running with wheezy-backports but it seems that
> kernel doesn't have the meltdown patch yet. We'd prefer not to compile the
> kernel manually from source.
[...]

wheezy-backports is not supported and will never get any more security
updates.

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson



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


Bug#879712: Update wokkel?

2018-01-16 Thread Angel Abad
Hi, at the moment I have no response from the upstream developer.

Cheers

2018-01-02 11:40 GMT+01:00 W. Martin Borgert :

> On 2017-10-27 17:26, Angel Abad wrote:
> > Because there is no official release with these changes, I will
> > write upstream developer and I will tell you.
>
> Was there any outcome? TIA!
>



-- 
Angel Abad
an...@debian.org | angela...@ubuntu.com | angela...@gmail.com
http://www.pastelero.net
FPR: 4A08 9719 1621 CCF7 FBEE  F752 A6D5 8816 010A 1096


Bug#886879: RM: kde-baseapps -- ROM; manual decruft needed

2018-01-16 Thread Emilio Pozuelo Monfort
Control: retitle -1 RM: kde-baseapps kde-baseapps-data -- ROM

On Wed, 10 Jan 2018 22:15:09 +0100 Pino Toscano  wrote:
> Package: ftp.debian.org
> Severity: normal
> 
> Hi,
> 
> please decruft the old binaries of src:kde-baseapps, which seem to not
> have been removed automatically:
> dolphin4 konqueror-nsplugins libkonqsidebarplugin-dev, libkonqsidebarplugin4a 
> kde-baseapps-data

Those are already decrufted, except for kde-baseapps-data, which is arch:all and
not in the cruft report.

The old kde-baseapps arch:all package from src:kde-baseapps needs to be
decrufted as well. It is now arch:any and built from src:meta-kde.

Please decruft those two.

Thanks,
Emilio



Bug#816354: okular: No file association for pdf files and no menu entry

2018-01-16 Thread Michael Weghorn
Hi Sten,

does the described problem still occur for you?

I just tried to reproduce but did not encounter this problem.

Regards,
  Michael

On Mon, 29 Feb 2016 23:10:56 -0500 Sten Heinze  wrote:
> [...]
>   Trying to open a pdf file from dolphin only leads to an 'open with..' dialog
>   where I can select the application to do so. But no entry for okular can be
>   found is the list of known application nor in the applications list in the 
>   Plasma launcher. However, okular can be run from the command line and can 
>   open the pdf file, so just the file associations and menu entry is missing.
> [...]



Bug#885983: O: tupi -- 2D Animation design and authoring tool

2018-01-16 Thread Carlos Maddela
Control: retitle -1 ITA: tupi -- 2D Animation design and authoring tool
Control: owner -1 !

I'd like to adopt this package.

On Mon, 01 Jan 2018 20:51:58 +1100 Dmitry Smirnov wrote:
> Package: wnpp
> Severity: normal
> Control: affects -1 tupi
> X-Debbugs-CC: i...@maefloresta.com
>
> I have no capacity left to maintain _tupi_ hence it needs new
maintainer...
>
> Maintaining this package requires time and skills. Please only adopt this
> package if you will have enough time and attention to work on it.
>
> If you want to be the new maintainer, please see [1] for detailed
> instructions how to adopt a package properly.
>
> [1]: https://www.debian.org/devel/wnpp/index.html#howto-o
>
> --
> Regards,
> Dmitry Smirnov.



Bug#860366: okular: Okular crashes when opening some documents

2018-01-16 Thread Michael Weghorn
tags 860366 moreinfo
thanks

Hi Rainer,

I just tried to reproduce the crash with the mentioned file. With the
Okular version in current Debian testing/unstable (4:17.08.3-2), I
cannot reproduce the problem, the file opens fine for me.

Does the problem still occur there for you?

Regards,
  Michael



Bug#887428: lintian: Use of uninitialized value in string ne at /usr/share/perl5/Lintian/Collect/Package.pm line 579

2018-01-16 Thread Niels Thykier
On Tue, 16 Jan 2018 21:10:53 +0530 Chris Lamb  wrote:
> 
> Hi Hilmar, 
> 
> > I'm building a package. After the build is done, lintian is called and 
> > writes a lot of these messages:
> 
> But what is the package called..? :) How might I reproduce this? 
> 
> 
> Regards, 
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-
> 
> 

This bug appears to be reproducible on lindsay.d.o:

"""
linday.d.o $ grep 'Use of uninitialized ' lintian.log -c
4148
"""

(In case you are missing material for debugging)

Thanks,
~Niels



Bug#868132: Needless build dependency on kdelibs5-dev

2018-01-16 Thread Samuel Thibault
Control: tags -1 + wontfix

Hello,

Samuel Thibault, on jeu. 07 déc. 2017 02:04:59 +0100, wrote:
> Alexander Volkov, on lun. 04 déc. 2017 13:50:59 +0300, wrote:
> > Here is our extended nokde patch.
> 
> Thanks, I have updated it in Debian.

It actually completely breaks qt-at-spi, see #887431

So it seems qt-at-spi does need at least the kde4_add_library etc.
things.

This package is going to get removed with the qt4 removal anyway, so
marking as wontfix.

Samuel



Bug#886219: lintian should be less pedantic about latest policy version

2018-01-16 Thread Ian Jackson
Sean Whitton writes ("Re: Bug#886219: lintian should be less pedantic about 
latest policy version"):
> Let me first say exactly what change I'd recommend:
> - out-of-date-standards-version should be I: or P: instead of W:
> - ancient-standards-version should remain W:
> - ancient-standards-version should be triggered when S-V contains a
>   release of Policy from the previous stable release cycle
...
> You argue that
> - whenever a maintainer uploads a package and S-V is out-of-date, they
>   should work through the relevant entries in the Policy Manual's
>   Upgrading Checklist
> - Policy Manual releases should be infrequent to avoid maintainers
>   having to do this too often
> 
> On the contrary, I argue that
> - the only thing that should be /required/ when uploading a package is
>   making the package non-trivially better than the current version in
>   unstable
> - updating S-V should never block uploading other improvements
> - there are good reasons to release the Policy Manual frequently, and
>   this should not be blocked by the expectation that everyone respond to
>   those new versions in their very next uploads.

Thank you, Sean, for arguing this so much better than I am doing.

> Also relevant here is Enrico's talk at DebConf17,[1] where he cautioned
> against manipulating volunteers into doing work.  Requiring prerequisite
> work that is not necessary for co-ordinating with other volunteers might
> well fall into that category.
> 
> [1] https://debconf17.debconf.org/talks/92/

I clearly must watch this talk.

Ian.



Bug#814602: okular: freezes on trying to load *.chm file

2018-01-16 Thread Michael Weghorn
Hi,

On Sat, 13 Feb 2016 13:14:56 +0100 Maria
 wrote:
> Okular freezes when trying to load a *.chm file.
> Mouse turns into please wait status, menus doesn't react.
> Only possibillity is killing the window.
> [...]

does this problem still occur with the Okular version in current Debian
testing/unstable?

If so, could you possibly attach a file with which the problem occurs?

Regards,
  Michael



Bug#887404: libreoffice: LibreOffice eats up 100%CPU even without any document loaded

2018-01-16 Thread JS Ubei
Yes I confirm that disabling gtk3 UI by executing:
export SAL_USE_VCLPLUGIN=gensoffice &
resolves the issue for me.
Regards


Bug#887451: RFS: trafficserver/7.1.1-1

2018-01-16 Thread Jean Baptiste Favre
Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "trafficserver":

 * Package name: trafficserver
   Version : 7.1.1-1
   Upstream Author : Leif Hedstrom 
 * URL : http://trafficserver.apache.org/
 * License : Apache-2.0
   Section : web

It builds those binary packages:

trafficserver: fast, scalable and extensible HTTP/1.1 compliant
caching proxy server
trafficserver-experimental-plugins: experimental plugins for Apache
Traffic Server

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/trafficserver

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/t/trafficserver/trafficserver_7.1.1-1.dsc

More information about trrafficserver can be obtained from
http://trafficserver.apache.org/.

Changes since the last upload:

  * Fix trafficserver-dev dependencies. (Closes: #877457)
  * Fix d/gbp.conf. Remove duplicate filter option
  * Update standards version in d/control
  * Fix debian-rules-sets-dpkg-architecture-variable lintian warning
  * Fix debian-watch-uses-insecure-uri lintian info
  * Update d/patches
  * Update d/rules to reflect healthcheck being managed as a stable plugin
  * Add a patch to fix kfreebsd build
  * Add a patch to fix arm build
  * New upstream version 7.1.0
  * Remove broken 0008-fix_build_armel patch
  * Patches refresh for 7.1.0
  * Add new patch to fix build with luajit 2.1 (Closes: #873328)
  * Update experimental modules list
  * Update Debian Standards-Version & d/compat
  * Update Vcs-* fields to use secure communication
  * Lintian fix for d/NEWS
  * Add new build option to use system luajit
  * Update build dependencies (Closes: #859750)
  * Fix lintian warning in d/copyright
  * New upstream version 7.1.1
  * Patches refresh for 7.1.1

Though I'm listed as Upploader, I don't have the right to upload it by
myself and, unfortunatly, didn't hear from the maintainer for a while.

Regards,
Jean Baptiste Favre



Bug#886219: lintian should be less pedantic about latest policy version

2018-01-16 Thread Ian Jackson
Mattia Rizzolo writes ("Re: Bug#886219: lintian should be less pedantic about 
latest policy version"):
> Currently there are two related tags:
> * https://lintian.debian.org/tags/out-of-date-standards-version.html
>   which is reported when an upload is done and the date of the
>   changelog is older than the date of a policy release newer than what
>   is in Std-Ver. (I.e. a package doesn't get this if no uploads are
>   done, but it assumes that when somebody updates a package the
>   maintainer checks whether it is compliant to the very last Policy
>   update, which IMHO it is totally reasonable…?)

I'm afraid I disagree.  I think it is not reasonable to expect a
maintainer to always double-check for the latest policy updates on
every upload.  Even for packages I care a lot about I check for policy
updates on each package only once or twice per Debian release.

> If you update your package you should spend your time checking it is
> still Policy compliant (how would you know it is otherwise without
> checking?!),

I think a maintainer can safely rely on the rest of the Debian project
not declaring your package buggy enough that you definitely need to do
something about it right now.  Unless one hears to the contrary some
other way, of course.

Ian.



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

2018-01-16 Thread Michael Weghorn
Hi Marc and Adi,

On Thu, 27 Apr 2017 19:53:45 +0200 Adi Kriegisch  wrote:
> There seem to be several upstream issues dealing with this, eg.
> https://bugs.kde.org/show_bug.cgi?id=348171
> 
> Okular in its current version in Stretch (16.08.2-1+b1) cannot be used for
> printing.

The mentioned upstream bug has been closed in the meanwhile.
Does the problem still occur with the Okular version in current Debian
unstable/testing?

If so, could you please provide more detailed steps how to reproduce and
possibly attach a PDF document that is affected?
(If I understand correctly, the use case which breaks for you is
printing an A4 document to A4 paper, which has been working fine for me
so far.)

Regards,
  Michael



Bug#883297: "Packages: list" field removed from tasksel control file

2018-01-16 Thread Wolfgang Schweer
On Tue, Jan 16, 2018 at 04:12:48PM +0100, Andreas Tille wrote:
> H, may be we should not ask how it looked before but rather what
> should be the content of the tasksel file we *want* to create.

After having cloned the debian-med repo:
The generated debian-med-tasks.desc file seems to be  ok. Further, the 
content is similar to the one available here:
https://sources.debian.org/src/debian-med/3.0.1/debian-med-tasks.desc/
(which contained neither a 'Packages: list').

Also, the generated .deb packages seem to be ok.

Wolfgang

P.S.
Like suspected: if 'TASKSELOPT = -u' is added to the debian-med 
Makefile, the generated debian-med-tasks.desc file has a content like 
the one contained in git.


signature.asc
Description: PGP signature


Bug#887450: lighttpd missing dependency on perl5 for mod scripts

2018-01-16 Thread lambda

Package: lighttpd
Version: 1.4.45-1

I had a minor bug.

/usr/sbin/lighttpd-disable-mod fails with errors that Term/ReadLine.pm  
is missing.


The error was fixed by installing perl (replacing perl-base).

Thank you for your great efforts.



Bug#887449: RM: pdfsandwich [armel] -- ROM; ocaml no longer supports ocamlopt for armel

2018-01-16 Thread Tobias Frost
Package: ftp.debian.org
Severity: normal

Hallo,

please remove pdfsandwich for armel. The latest ocaml upload disabled support 
for
ocamlopt on this architecture and pdfsandwich needs it.

Thanks!

--
tobi



Bug#802849: Proposed patch

2018-01-16 Thread Luca Falavigna
Now patch builds, but apparently unsharing still does not work
because, even if the parameter is set via option, this->unshare_net is
not updated with the correct value.

Suggestions welcome :)
Description: Add support for unshare(CLONE_NEWNET)
Author: Luca Falavigna 
Bug-Debian: https://bugs.debian.org/802849

Index: schroot-1.6.10/CMakeLists.txt
===
--- schroot-1.6.10.orig/CMakeLists.txt
+++ schroot-1.6.10/CMakeLists.txt
@@ -274,6 +274,18 @@ endif (DOXYGEN_EXECUTABLE)
 option(doxygen "Enable doxygen documentation" ${DOXYGEN_DEFAULT})
 set(BUILD_DOXYGEN ${doxygen})
 
+# Namespace unshare feature
+# sched.h ==> UNSHARE_HEADER
+check_include_file_cxx (sched.h UNSHARE_HEADER)
+check_function_exists(unshare UNSHARE_FUNC)
+set(UNSHARE_DEFAULT OFF)
+if (UNSHARE_HEADER AND UNSHARE_FUNC)
+  set (UNSHARE_DEFAULT ON)
+endif (UNSHARE_HEADER AND UNSHARE_FUNC)
+option(unshare "Enable unshare support (Linux only)" ${UNSHARE_DEFAULT})
+set(BUILD_UNSHARE ${unshare})
+set(SBUILD_FEATURE_UNSHARE ${unshare})
+
 # Kernel personality feature
 # sys/personality.h ==> PERSONALITY_HEADER
 check_include_file_cxx (sys/personality.h PERSONALITY_HEADER)
Index: schroot-1.6.10/sbuild/CMakeLists.txt
===
--- schroot-1.6.10.orig/sbuild/CMakeLists.txt
+++ schroot-1.6.10/sbuild/CMakeLists.txt
@@ -80,6 +80,13 @@ if(BUILD_UNION)
   sbuild-chroot-facet-union.cc)
 endif(BUILD_UNION)
 
+if(BUILD_UNSHARE)
+  set(public_unshare_h_sources
+  sbuild-chroot-facet-unshare.h)
+  set(public_unshare_cc_sources
+  sbuild-chroot-facet-unshare.cc)
+endif(BUILD_UNSHARE)
+
 set(public_h_sources
 sbuild-basic-keyfile.h
 sbuild-basic-keyfile.tcc
Index: schroot-1.6.10/sbuild/sbuild-chroot-facet-unshare.cc
===
--- /dev/null
+++ schroot-1.6.10/sbuild/sbuild-chroot-facet-unshare.cc
@@ -0,0 +1,159 @@
+/* Copyright © 2005-2009  Roger Leigh 
+ *
+ * schroot is free software: you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * schroot is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see
+ * .
+ *
+ */
+
+#include 
+
+#include "sbuild-chroot.h"
+#include "sbuild-chroot-facet-unshare.h"
+#include "sbuild-feature.h"
+
+#include 
+
+#ifdef SBUILD_FEATURE_UNSHARE
+#include 
+#endif // SBUILD_FEATURE_UNSHARE
+
+using boost::format;
+using namespace sbuild;
+
+namespace
+{
+
+  typedef std::pair emap;
+
+  /**
+   * This is a list of the supported error codes.  It's used to
+   * construct the real error codes map.
+   */
+  emap init_errors[] =
+{
+  // TRANSLATORS: %1% = integer personality ID
+  emap(chroot_facet_unshare::UNSHARE,
+	   N_("Could not unshare process execution context"))
+};
+
+#ifdef SBUILD_FEATURE_UNSHARE
+  sbuild::feature feature_unshare
+  ("UNSHARE",
+   N_("Linux dissassociation of shared execution context"));
+#endif
+
+}
+
+template<>
+error::map_type
+error::error_strings
+(init_errors,
+ init_errors + (sizeof(init_errors) / sizeof(init_errors[0])));
+
+chroot_facet_unshare::chroot_facet_unshare ():
+  chroot_facet(),
+  unshare_net(false)
+{
+}
+
+chroot_facet_unshare::~chroot_facet_unshare ()
+{
+}
+
+chroot_facet_unshare::ptr
+chroot_facet_unshare::create ()
+{
+  return ptr(new chroot_facet_unshare());
+}
+
+chroot_facet::ptr
+chroot_facet_unshare::clone () const
+{
+  return ptr(new chroot_facet_unshare(*this));
+}
+
+std::string const&
+chroot_facet_unshare::get_name () const
+{
+  static const std::string name("unshare");
+
+  return name;
+}
+
+bool
+chroot_facet_unshare::get_unshare_net () const
+{
+  return this->unshare_net;
+}
+
+void
+chroot_facet_unshare::set_unshare_net (bool unshare_net)
+{
+  this->unshare_net = unshare_net;
+}
+
+void
+chroot_facet_unshare::unshare () const
+{
+  if (this->unshare_net)
+{
+  log_debug(DEBUG_INFO) << "Unsharing network" << std::endl;
+  if (::unshare(CLONE_NEWNET) < 0)
+	throw error(UNSHARE, strerror(errno));
+}
+}
+
+void
+chroot_facet_unshare::setup_env (chroot const& chroot,
+ environment&  env) const
+{
+}
+
+sbuild::chroot::session_flags
+chroot_facet_unshare::get_session_flags (chroot const& chroot) const
+{
+  return sbuild::chroot::SESSION_NOFLAGS;
+}
+
+void
+chroot_facet_unshare::get_details 

Bug#887421: [Aptitude-devel] Bug#887421: dpkg: warning: unable to delete old directory '/usr/share/man/gl/man8': Directory not empty

2018-01-16 Thread Axel Beckert
Hi,

積丹尼 Dan Jacobson wrote:
> Users will still freak out if any errors are printed like this

No. This is a warning message, not an error message.

> so maybe also print a one-time soothing message that will appear in
> the apt output.

I don't think that's helpful at all. These warnings are there because
there's something fishy with these directories, either due to
non-packaged files in there or because dpkg is handling even the
warnings differently if such file movings miss the Replaces header.

> If there is no way to do that then that should be a bug in itself.

I currently see two possibilities where these warnings could come from:

* There are update-alternatives generated symlinks in these
  directories. Those are likely recognized as non-packaged files by
  dpkg.

* The missing Replaces headers.

In both cases, I'm quite sure the warnings came only for these three
directory because of this fact:

$ apt-file search /usr/share/man/gl/man8
aptitude: /usr/share/man/gl/man8/aptitude-curses.8.gz
aptitude-common: /usr/share/man/gl/man8/aptitude-curses.8.gz
kde-l10n-gl: /usr/share/man/gl/man8/kbuildsycoca4.8.gz
kde-l10n-gl: /usr/share/man/gl/man8/kcookiejar4.8.gz
kde-l10n-gl: /usr/share/man/gl/man8/kded4.8.gz
kde-l10n-gl: /usr/share/man/gl/man8/kdeinit4.8.gz
kde-l10n-gl: /usr/share/man/gl/man8/meinproc4.8.gz
$ apt-file search /usr/share/man/fi/man8
aptitude: /usr/share/man/fi/man8/aptitude-curses.8.gz
aptitude-common: /usr/share/man/fi/man8/aptitude-curses.8.gz

(And for /usr/share/man/gl/ in general, I only see GUI tools having
files in there, so chances are high that no other packages has files
in there, too. So I focus on the other two for the following details.)

They only appear for /usr/share/man/{gl,fi}/man8/ because
with the exception of kde-l10n-gl (which likely only native speakers
of that language will install), aptitude/aptitude-common is the only
package which ships man pages in section 8 for Finnish and Galician.

All other directories for which manual pages were moved around have
other (installed) packages with files in there, i.e. no warning.

So dpkg wants to remove that directory, but can't and warns about it.

If it's the update-alternatives case, we probably can't do much about
it. I only see a vague chance to move around the update-alternatives
call within the maintainer scripts. But from a first glance the
current locations for that call look sane and normal and just simply
moving them around might break other things.

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#887448: ujson needs build dependency on 2to3

2018-01-16 Thread Adrian Bunk
Source: ujson
Version: 1.35-1
Severity: serious
Tags: buster sid

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

...
2to3 --no-diffs -n --add-suffix='3' -w tests/tests.py
make[1]: 2to3: Command not found
debian/rules:41: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 127


2to3 is now in an own package.



Bug#877367: www.debian.org: Please consider adding redirects for old Policy chapters/appendices

2018-01-16 Thread Laura Arjona Reina
Hello

El 15/01/18 a las 01:57, Sean Whitton escribió:
> 
> Okay.  TTBBMK you should use 302 redirects, not 301, because of the
> possible change back to the multi-page format.
> 

I've sent a patch changing the 301 to 302, via RT #7058.

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona



Bug#887447: network-manager-ssh FTBFS with network-manager 1.10.2-1

2018-01-16 Thread Adrian Bunk
Source: network-manager-ssh
Version: 1.2.6-1
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/network-manager-ssh.html

...
gcc -DHAVE_CONFIG_H -I. -I..  -pthread -I/usr/include/libnm 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DNM_VERSION_MIN_REQUIRED=NM_VERSION_1_2 
-DNM_VERSION_MAX_ALLOWED=NM_VERSION_1_2 -pthread -I/usr/include/gio-unix-2.0/ 
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-DBINDIR=\"/usr/bin\" -DPREFIX=\""/usr"\" -DSYSCONFDIR=\""/etc"\" 
-DLIBDIR=\""/usr/lib/x86_64-linux-gnu"\" 
-DLIBEXECDIR=\""/usr/lib/NetworkManager"\" -DLOCALSTATEDIR=\""/var"\" 
-DDATADIR=\"/usr/share\" -DNM_SSH_LOCALEDIR=\"/usr/share/locale\" -I.. 
-Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Werror -std=gnu89 -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wshadow 
-Wmissing-declarations -Wmissing-prototypes -Wdeclaration-after-statement 
-Wfloat-equal -Wno-unused-parameter -Wno-sign-compare -fno-strict-aliasing 
-Wno-unused-but-set-variable -c -o nm-ssh-service.o nm-ssh-service.c
In file included from /usr/include/libnm/nm-utils.h:38:0,
 from /usr/include/libnm/nm-setting-ip-config.h:31,
 from /usr/include/libnm/nm-setting-ip4-config.h:30,
 from /usr/include/libnm/NetworkManager.h:72,
 from nm-ssh-service.c:49:
/usr/include/libnm/nm-setting-tc-config.h:43:1: error: 'NMTCQdisc' is 
deprecated: Not available before 1.10.2 [-Werror=deprecated-declarations]
 voidnm_tc_qdisc_ref  (NMTCQdisc *qdisc);
 ^~~~
/usr/include/libnm/nm-setting-tc-config.h:32:16: note: declared here
 typedef struct NMTCQdisc NMTCQdisc;
^
/usr/include/libnm/nm-setting-tc-config.h:45:1: error: 'NMTCQdisc' is 
deprecated: Not available before 1.10.2 [-Werror=deprecated-declarations]
 voidnm_tc_qdisc_unref(NMTCQdisc *qdisc);
 ^~~~
/usr/include/libnm/nm-setting-tc-config.h:32:16: note: declared here
 typedef struct NMTCQdisc NMTCQdisc;
^
...



Bug#887446: astroplan: FTBFS and Debci failure

2018-01-16 Thread Adrian Bunk
Source: astroplan
Version: 0.4-1
Severity: serious

Some recent change in unstable makes astroplan FTBFS and Debci fail:

https://ci.debian.net/packages/a/astroplan/unstable/amd64/
https://tests.reproducible-builds.org/debian/history/astroplan.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/astroplan.html

...
=== FAILURES ===
__ test_schedule_insert_slot ___

def test_schedule_insert_slot():
start = Time('2016-02-06 03:00:00')
schedule = Schedule(start, start + 5*u.hour)
# testing for when float comparison doesn't work, does it start/end at 
the right time
duration = 2*u.hour + 1*u.second
end_time = start + duration
block = TransitionBlock.from_duration(duration)
schedule.insert_slot(end_time - duration, block)
assert not end_time - duration == start
assert len(schedule.slots) == 2
assert schedule.slots[0].start == start
schedule = Schedule(start, start + 5*u.hour)
# testing for when float evaluation does work
duration = 2*u.hour
end_time = start + duration
block = TransitionBlock.from_duration(duration)
schedule.insert_slot(end_time - duration, block)
>   assert end_time - duration == start
E   AssertionError: assert ( - ) == 
...
 1 failed, 113 passed, 1 skipped, 11 warnings in 386.32 seconds 
debian/rules:29: recipe for target 'python-test2.7' failed
make[1]: *** [python-test2.7] Error 1



Bug#828483: osslsigncode: FTBFS with openssl 1.1.0

2018-01-16 Thread Raphael Hertzog
[ Copy to upstream author to know his plans wrt openssl 1.1
  and to invite him to review the current patches ]

Hello Stephen,

On Sun, 26 Jun 2016, Stephen Kitt wrote:
> On Sun, 26 Jun 2016 12:23:30 +0200, Kurt Roeckx  wrote:
> > If you have problems making things work, feel free to contact us.
> 
> I've managed to fix most of the build issues, the remaining issue I'm faced
> with is the apparent disappearance of the STACK API (DECLARE_STACK_OF()) etc.
> What should I be using instead?

There's a patch that has been submitted to upstream here:
https://sourceforge.net/p/osslsigncode/patches/10/
https://sourceforge.net/p/osslsigncode/patches/10/attachment/0001-Make-code-work-with-OpenSSL-1.1.patch

It removes (not very cleanly) the "pagehash" functionality alltogether to
avoid this problem (-ph command line option).

This package has already been dropped out of testing so it would be
nice if we could complete this OpenSSL 1.1 transition to bring
it back into Debian testing.

Per, do you have plans to make osslsigncode compatible with OpenSSL 1.1?
Could you review the above patch and work with Reimar Döffinger and/or
Stephen Kitt to have something suitable for merge?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/



Bug#887428: lintian: Use of uninitialized value in string ne at /usr/share/perl5/Lintian/Collect/Package.pm line 579

2018-01-16 Thread Hilmar Preuße

Am 16.01.2018 um 16:40 teilte Chris Lamb mit:

Hi Chris,


I'm building a package. After the build is done, lintian is called and
writes a lot of these messages:


But what is the package called..? :) How might I reproduce this?

Hmm, this is proftp 1.3.6, not yet in the archive. I could upload 
orig.tar.gz, debian.tar.gz anywhere if you like to. Please drop me a note.


Hilmar
--
#206401 http://counter.li.org



Bug#871502: zotero-standalone-build: The newer Zotero is standalone only ; a reorganization is neded.

2018-01-16 Thread Félix Sipma
On 2018-01-16 16:47+0100, Sébastien Villemot wrote:
> On Tue, Jan 16, 2018 at 04:32:02PM +0100, Félix Sipma wrote:
>> On 2018-01-16 12:46+0100, Sébastien Villemot wrote:
> 
>>> Indeed you’re right. The zotero-web-library.js stuff is included in the
>>> official Zotero client distribution. So lots of work ahead, I'm not sure 
>>> I'm up
>>> to the task. I think I am going to orphan the package.
>> 
>> I have to admit it did not motivate me either to see such a big work to do...
>> Maybe an acceptable possibility would be to put the js libs in the package 
>> and
>> move it in contrib?
> 
> I'm not sure to understand your reasoning.
> 
> Do you mean that the libraries would be downloaded at build time? This has 
> been
> discussed on debian-devel@ recently, and it is clearly not acceptable, even 
> for
> contrib.
> 
> Or do you mean we would bundle the JS libs in the zotero package? If all the
> source is there, it can go into "main". Still it's borderline, because library
> bundling is bad practice, but maybe it could be acceptable as a temporary 
> solution.

I was thinking of the bundling solution. I think this was also discussed on
debian-devel, and the conclusion was that the package had to go in contrib
(because which would provide something which is different from the source:
concatenated/minified/etc. js).

>> More and more js libs get packaged, so when the ones with a lot of 
>> dependencies
>> would have entered Debian, we can try to package the last ones. What do you
>> think about this?
> 
> That may be an option, though we have no control of whether this will happen
> anytime soon.

I know it's far from perfect, but I see no other reasonable solution :(.

I don't know exactly how we would prepare the tarball with the bundle of the JS
libs.


signature.asc
Description: PGP signature


Bug#885525: /usr/bin/nm-applet: nm-applet crashes when connecting to VPN

2018-01-16 Thread Michael Biebl
Hi Sean

Am 16.01.2018 um 06:33 schrieb Sean DuBois:
> Mike,
> I don't believe that part is needed, I did a full diff against upstream
> and there is a g_strdup in both. If you do an apt-get source it does a
> g_strdup by default. May be wrong though!
> 
> What happens with not establishing the connection? If you launch
> nm-applet via terminal do you get anything via stderr/stdout? If you
> launch it via valgrind any warnings?
> 
> Michael,
> Anything I do to help get this merged?

Sorry it took a bit longer to get this released.

I now pulled a52ccb2fe170558fc0aab4dd1d15ba8808b10951 and
0c90e08f77b71d2bda699cf032fceec0122bbf82 from upstream and released
1.8.10-2. I quickly tested the result and it seemed to fix the issue.
Your confirmation would be very much appreciated.

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



signature.asc
Description: OpenPGP digital signature


  1   2   >