Bug#896258: [Pkg-utopia-maintainers] Bug#896258: python3-bytesize: bytesize fails to import

[Michael Biebl]

Am 20.04.2018 um 22:01 schrieb Helmut Grohne:
> Package: python3-bytesize
> Version: 1.2-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python3-bytesize importing the module bytesize
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/bytesize/__init__.py", line 1, in 
> 
> from .bytesize import Size
>   File "/usr/lib/python3/dist-packages/bytesize/bytesize.py", line 4, in 
> 
> import six
> ModuleNotFoundError: No module named 'six'

That looks like an oversight, i.e. missing python3-six dependency indeed.


-- 
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#896303: [Pkg-utopia-maintainers] Bug#896303: python3-blockdev: gi.overrides.BlockDev fails to import

[Michael Biebl]

Control: tags -1 + moreinfo

Am 20.04.2018 um 22:01 schrieb Helmut Grohne:
> Package: python3-blockdev
> Version: 2.16-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python3-blockdev importing the module gi.overrides.BlockDev
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/gi/overrides/BlockDev.py", line 34, in 
> 
> from gi.importer import modules
> ModuleNotFoundError: No module named 'gi.importer'
> 

gi overrides are not supposed to be imported directly.
Those overrides are in effect if the GObject Introspection machinery is
in use, in which case the necessary python packages are already installed.


-- 
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#896198: python3-slip-dbus: slip.dbus fails to import

[Michael Biebl]

Control: tags -1 + moreinfo

Am 20.04.2018 um 22:01 schrieb Helmut Grohne:
> Package: python3-slip-dbus
> Version: 0.6.5-2
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
> 
> After installing python3-slip-dbus importing the module slip.dbus
> into a python interpreter fails with the following error:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/slip/_wrappers/_glib.py", line 46, in 
> 

Hm, but this file is shipped by python3-slip, not python3-slip-dbus.

> import glib
> ModuleNotFoundError: No module named 'glib'
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3/dist-packages/slip/dbus/__init__.py", line 8, in 
> 
> from . import service
>   File "/usr/lib/python3/dist-packages/slip/dbus/service.py", line 32, in 
> 
> from .._wrappers import _glib as GLib
>   File "/usr/lib/python3/dist-packages/slip/_wrappers/_glib.py", line 48, in 
> 
> import gi.repository.GLib
> ModuleNotFoundError: No module named 'gi'
> 

Afaiu, the idea behind this wrapper is, that it's up to the actual
application to decide which implementation it wants, i.e. glib
(python-gobject-2) or the gi based Glib (python3-gi + gir1.2-glib-2.0) ,
and the application should declare the proper dependency.
If I add a dependency to python3-slip-dbus (assuming that would be the
correct package and not python3-slip), I wouldn't know if I should add
python-gobject-2
or
python3-gi, gir1.2-glib-2.0
Both feels wrong somehow.


-- 
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#896429: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import

[Helmut Grohne]

Control: severity 896234 normal
Control: severity 896242 normal
Control: severity 896272 normal
Control: severity 896306 normal
Control: severity 896307 normal
Control: severity 896328 normal
Control: severity 896378 normal
Control: severity 896396 normal
Control: severity 896429 normal

On Sat, Apr 21, 2018 at 09:47:59AM +1000, Brian May wrote:
> Helmut Grohne  writes:
> 
> > django.core.exceptions.ImproperlyConfigured: Requested setting
> > DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must
> > either define the environment variable DJANGO_SETTINGS_MODULE or call
> > settings.configure() before accessing settings.
> 
> I believe this bug report, and several others you filled recently that
> contain this same text are false.

I went passed the bug list to a few others for review and posted the
full list to d-devel (including all tracebacks). Nobody spoke up and
Chris Lamb vaguely said that the django ones looked legit to him.

I have lowered the severity of the relevant bugs (matching
"ImproperlyConfigured") to prevent issues with testing migration.

> Like it or not, it is just not possible to import Django libraries
> without providing a valid django settings file. This is not a sign that
> something is broken.

I wonder whether we can draw anything useful from these bugs before
closing them.

For one thing, you cannot use autopkgtest-pkg-python on these modules as
is.

Then having them not importable means that e.g, pydoc. That's
unfortunate. Often times, modules with non-trivial impact on their
environment do not do so at import time, but provide something like an
install function such that the user makes a conscious choice. An example
would be gbulb.install().

So yeah, for django this may make sense, but this behaviour is still
unfortunate from a qa pov.

I'd like to hear your opinion on this matter.

After the dust has settled, I can follow up on d-devel with a summary
that suggests filtering this particular django exception.

Helmut

Bug#874498: [Pkg-protobuf-devel] Bug#874498: protobuf: Please package latest upstream version

[Andres Salomon]

On Sun, Apr 8, 2018 at 1:55 AM, Andres Salomon  
wrote:

On Sun, 01 Apr 2018 22:07:02 -0700
Andres Salomon  wrote:


 Thanks! I built and tested it with gplaycli; it worked perfectly. So
 +1 from me.
 That's just testing the python3 protobuf bindings, though.

 > [1] dget -x http://www.barcikacomp.hu/gcs/protobuf_3.5.2-1.dsc



Is there anything else you need from me? I'd love to see this uploaded
to experimental or unstable.


Hi,

Just another ping. I'd be happy to upload this if you need me to do it. 
Or, if there's anything
else I can do to help this package get updated, please let me know. 
Thanks!

Bug#896283: python-rpy: rpy fails to import

[Helmut Grohne]

On Fri, Apr 20, 2018 at 04:31:14PM -0500, Dirk Eddelbuettel wrote:
> rpy was abandonded upstream maybe a decade ago, maybe longer. It needs hard
> rebuilds for each new R version -- here R 3.4.4 -- and at some point that
> just ceased to be useful.
> 
> There is rpy2 which is current and maintained for python 3. We also forked
> off the last version of rpy2 that can be build with python 2.7 as another
> software suite needed that.
> 
> Please switch to rpy2.

Ok. That sounds like src:rpy should be removed from debian. python-rpy
does not have any reverse dependencies, so that's possible. Please send
the following commands to control@b.d.o if you agree:

retitle 896283 RM: rpy -- ROM; use rpy2
severity 896283 normal
reassign 896283 ftp.debian.org

Helmut

Bug#896379: python-avc: avc fails to import

[Helmut Grohne]

Control: severity -1 normal

On Sat, Apr 21, 2018 at 01:57:22AM +0200, Fabrizio Pollastri wrote:
> Since python-avc 0.8.3-1.1 supports different widget toolkits and
>   the user is normally interested to only one toolkit among these, I
>   preferred to set them as "suggested" (the list follows) and not as
>   dependencies. If there is a better way to define this, any help is
>   appreciated (I am not an expert Debian packager).

Since the behaviour is intentional, I am lowering the severity of the
bug report. Still, I think the behaviour is improvable.

Since python-avc really doesn't work at all without any toolkit, having
a dependency seems useful to me. For instance, you could put all the
suggested toolkits in as alternatives of a single dependency:

Suggests: a, b, c, d
Depends: a | b | c | d

Even after doing so, the module will fail to import though. That has
more implications to be considered. For one thing, you cannot use
autopkgtest-pkg-python. Then using pydoc fails. This is both
unfortunate. An alternative would be to select the toolkit using a
function to be called on the imported module. Examples of other
libraries where you need to call something before you can use anything
are apt_pkg.init() and gbulb.install(). Not sure whether that is
"better", but it is something to consider.

The other question would be how to exempt python-avc from such tests in
order to avoid future bug reports of this kind. Adding it to a whitelist
is certainly possible, but also fragile.

Helmut

Bug#895184: roundcube: CVE-2018-9846: check_request() bypass in archive plugin

[Salvatore Bonaccorso]

Hi Guilhem,

On Sat, Apr 21, 2018 at 02:13:54AM +0200, Guilhem Moulin wrote:
> On Fri, 20 Apr 2018 at 05:18:36 +0200, Salvatore Bonaccorso wrote:
> > Thanks for following up for stretch. First a quick comment. Please
> > always CC t...@security.debian.org on such questions for if an update
> > is wanted for DSA. This alows team members to better share the load
> > for review, release, etc ... (and it's recorded futhermore on the team
> > alias).
> 
> Oops, I assumed that the Security Team received all bugs tagged
> ‘security’ so I omitted the CC on purpose… my bad.

Unfortunately, or fortunately not (yet), getting all comunication with
Tag security set will overwhelm our mailboxes. But as an improvement
step we are planning to get initial submissions with security tag set.
Until now that happens only if someone uses reportbug to fill the
issue, adding a X-Debbugs-CC, but not if one fills wihout reportbug a
bug. Cf. #895661. Sorry, got now longer as I want. My only intention
was to quickly state that for future cases, so we might distributed
workload within the team better.
>  
> > I think we should release this through stretch-security. The debdiff
> > per se looks already good. Were you able to test the update in
> > production under stretch?
> 
> Yes, I did test the update.

Perfect.

> > There is though one no-dsa issue,
> > https://security-tracker.debian.org/tracker/CVE-2018-171 which
> > would be good to be included. Could you backport that fix as well and
> > send a new debdiff for quick review+ack for upload?
> 
> Sure, new debdiff attached.

Looks good to me, please do upload to security-master.

Regards,
Salvatore

Bug#896441: corosync: please make the build reproducible

[Chris Lamb]

forwarded 896441 https://github.com/corosync/corosync/pull/345
thanks

I've forwarded this upstream here:

  https://github.com/corosync/corosync/pull/345


Regards,

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

Bug#896442: texlive-bin: Please switch back to system poppler

[Adrian Bunk]

Source: texlive-bin
Version: 2018.20180416.47457-1
Severity: normal

poppler 0.63.0 is now in unstable.

Bug#896441: corosync: please make the build reproducible

[Chris Lamb]

Source: corosync
Version: 2.4.4-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that corosync could not be built reproducibly.

This is because, whilst it uses SOURCE_DATE_EPOCH, the output varies
depending on the timezone.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build.patch   1970-01-01 01:00:00.0 
+0100
--- b/debian/patches/reproducible-build.patch   2018-04-21 08:01:32.243876562 
+0200
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-04-21
+
+--- corosync-2.4.4.orig/man/Makefile.am
 corosync-2.4.4/man/Makefile.am
+@@ -166,7 +166,7 @@ HTML_DOCS  = $(dist_man_MANS:%=%.html)
+ %.3: %.3.in $(autogen_common)
+   @echo Generating $@ man page && \
+   rm -f $@-t-t $@-t $@ && \
+-  date="$$(LC_ALL=C date "+%F" $${SOURCE_DATE_EPOCH+-d 
@$$SOURCE_DATE_EPOCH})" && \
++  date="$$(LC_ALL=C date -u "+%F" $${SOURCE_DATE_EPOCH+-d 
@$$SOURCE_DATE_EPOCH})" && \
+   awk "{print}(\$$1 ~ /@COMMONIPCERRORS@/){exit 0}" 
${top_srcdir}/man/$@.in > $@-t-t && \
+   cat ${top_srcdir}/man/$(autogen_common) >> $@-t-t && \
+   awk -v p=0 "(\$$1 ~ /@COMMONIPCERRORS@/){p = 1} {if(p==1)print}" 
${top_srcdir}/man/$@.in >> $@-t-t && \
--- a/debian/patches/series 2018-04-21 07:52:25.589212835 +0200
--- b/debian/patches/series 2018-04-21 08:01:31.479872821 +0200
@@ -15,3 +15,4 @@
 Fix-typo-sucesfully-successfully.patch
 qnetd-stay-with-the-DBM-NSS-DB-format.patch
 Fix-typo-defualt-default.patch
+reproducible-build.patch

Bug#896129: (no subject)

[Louis-Philippe Véronneau]

I am not able to reproduce this on a full fledged Gnome 3 box. The
machine I'm having issues on is a "leaner" Openbox install and might be
missing some packages compared to a regular Gnome 3 install.

-- 
  ,''`.
 : :'  : Louis-Philippe Véronneau
 `. `'`  po...@debian.org / veronneau.org
   `-



signature.asc
Description: OpenPGP digital signature

Bug#896440: munin: Man pages are distributed in a separate package (munin-doc)

[Lars Kruse]

Package: munin
Version: 2.0.37-1
Severity: minor

Hello,

currently the man pages of the various programs and configuration files
of munin are distributed via the binary package munin-doc.

But instead the policy [1] recommends the following:

  Each program, utility, and function should have an associated manual
  page included in the same package."

Thus the man pages should be shipped next to the files, that they describe.


Cheers,
Lars


[1] http://debian.org/doc/debian-policy/#manual-pages

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Sean Whitton]

Hello,

On Fri, Apr 20 2018, kact...@gnu.org wrote:

> [2018-04-19 10:14] Sean Whitton 
>> Hello both,
>>
>> If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
>> (quilt) will not help.  It will not introduce any additional
>> metadata.  The only change will be the addition of a patch header
>> pointing to dgit-repos.
>
> What do you mean by 'additional metadata'? Patch headers generated
> from git commits?

No, I mean separate patches.

>> Switching to dgit-maint-gbp(7) means using a patches-unapplied
>> workflow.  [...]
>
> I want to be able to do raw `dpkg-buildpackage`. I guess it means
> patches-applied workflow, am I right.

I don't think so.  The advantages of patches-applied are different.

>> In the next month or so we (Ian Jackson and I) will be releasing a
>> workflow called dgit-maint-debrebase(7) which
>>
>> - is patches-applied; but
>> - automatically generates a perfect 3.0 (quilt) representation of the
>>   Debian changes.
>>
>> I.e. it should satisfy everyone.
>
> I am okay to wait for your next invention. Last one I remember --
> separate patches instead of single squashed patch in
> dgit-maint-merge(7) was awesome.

Not sure what you're referring to here.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896012: Regression from gcc-7 7.3.0-16

[Matthias Klose]

On 19.04.2018 06:16, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Matthias Klose [mailto:d...@debian.org]
>> Sent: Wednesday, April 18, 2018 9:29 PM
>> To: Limonciello, Mario; 896...@bugs.debian.org
>> Subject: Re: Bug#896012: Regression from gcc-7 7.3.0-16
>>
>> On 18.04.2018 19:34, mario.limoncie...@dell.com wrote:
>>> Package: gcc-7
>>> Version: 7.3.0-16
>>>
>>> The fwupd project as one of the CI tasks runs packaged builds and lintian 
>>> after the
>> build.
>>> CI recently started failing with this error:
>>>
>>> E: fwupd: library-not-linked-against-libc 
>>> usr/lib/x86_64-linux-gnu/fwupd-plugins-
>> 3/libfu_plugin_upower.so
>>> E: fwupd-tests: library-not-linked-against-libc 
>>> usr/lib/x86_64-linux-gnu/fwupd-
>> plugins-3/libfu_plugin_test.so
>>>
>>> We narrowed it down to be caused after upgrading to GCC 7.3.0-16 from Debian
>> testing.
>>> Builds with 7.3.0-15 and no source changes to fwupd are not affected.
>>>
>>> We also found that changing compiler optimization (-O2 to -O0) with the new 
>>> GCC
>> this error
>>> goes away.
>>
>> please could you attach the linker command, run with -v, and maybe all linker
>> scripts?
> 
> Here are both compiler and linker commands when run with -v.

[...]

so yes, this is a behavior change. Up to now the link looked like

  -lgcc --as-needed -lgcc_s --no-as-needed \
  -lpthread -lc \
  -lgcc --as-needed -lgcc_s --no-as-needed

while now we are linking with

  -lgcc --push-state --as-needed -lgcc_s --pop-state \
  -lpthread -lc \
  -lgcc --push-state --as-needed -lgcc_s --pop-state

Up to -15, that resulted in libc always linked in, while starting with -16, it
is linked with the state which is enabled before the gcc link command.  If the
plugin doesn't have a reference to libc and --as-needed is specified as in your
case, then libc isn't linked in.

So probably we need an update for our QA tools to do a better detection of
dynamically linked binaries.

Matthias

Bug#896204:

[A. Jesse Jiryu Davis]

It looks like this package should depend on python3-pymongo.

Bug#896439: gradle-debian-helper points to an invalid java api directory

[Tiago Stürmer Daitx]

Package: gradle-debian-helper
Version: 1.6
Severity: important

Dear Maintainer,

Thus I would like to discuss the possibility of:
1) declaring the binary package gradle-debian-helper as dependend upon
default-jdk-doc;
2) using the directory file:///usr/share/doc/default-jdk-doc/api in
DebianHelperPlugin.java instead of the current default-jdk one.


The reason for this change is that until openjdk-9 the javadoc binary
would ignore invalid javadoc links and at most throw out a warning, but
since openjdk-10 this behavior changed to an error which causes packages
that calls the javadoc binary to FTBFS whenever an invalid, nonexistent,
or unreacheable link is given.


In gradle-debian-helper the file
gradle-helper-plugin/src/main/java/org/debian/gradle/DebianHelperPlugin.java
currently sets the first javadoc link to
file:///usr/share/doc/default-jdk/api 

First, this seems to indicates that the plugin expects that the default-jdk
package will be installed when it's used, but this is not reflected upon
its 'Depends:' (or 'Recommends:').

Second, even if the default-jdk is installed this is problematic because that
directory is actually a relative link to
../openjdk-X-doc/api 
which in turn belongs to an openjdk-X-doc package - such package is not
installed by the default-jdk package. Instead of looking for a default-jdk
directory I proposed that it should instead look for a default-jdk-doc
directory as the api link because the default-jdk-doc package does depends
on an openjdk-X-doc package.


This change shouldn't cause much problem for any packages currently
building with the default-jdk set to openjdk-9 (or 8), since if
/usr/share/doc/default-jdk-doc does not exist then the default-jdk-doc
was not installed anyway and the original link to
/usr/share/doc/default-jdk/api would be invalid anyway and these openjdk
versions ignore that.

Without the proposed changes packages would FTBFS unless both default-jdk
and default-jdk-doc are installed after the default-jdk moves to
openjdk-10 (or 11). Also, packages that depend upon default-jdk-headless
would FTBFS unless they moved to depend upon default-jdk.


Regards,
Tiago

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

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

Bug#896438: javahelper: java-vars.mk is not compatible with Java 9 directory layout

[Mike Miller]

Package: javahelper
Version: 0.63
Severity: normal

Dear Maintainer,

The make variables provided by java-vars.mk, specifically JVM_CLIENT_DIR
and JVM_SERVER_DIR, are not compatible with the directory layout used by
Java 9 and newer. The variables always evaluate to an empty string. The
architecture is no longer a component in the file path.


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

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

Versions of packages javahelper depends on:
ii  bsdmainutils 11.1.2
ii  dctrl-tools  2.24-2+b1
ii  debhelper11.2.1
ii  devscripts   2.18.1
ii  dpkg-dev 1.19.0.5
ii  libarchive-zip-perl  1.60-1
ii  perl 5.26.1-5

javahelper recommends no packages.

Versions of packages javahelper suggests:
ii  cvs   2:1.12.13+real-26
ii  gawk  1:4.1.4+dfsg-1+b1
pn  tofrodos  

-- no debconf information

Bug#895184: roundcube: CVE-2018-9846: check_request() bypass in archive plugin

[Guilhem Moulin]

On Fri, 20 Apr 2018 at 05:18:36 +0200, Salvatore Bonaccorso wrote:
> Thanks for following up for stretch. First a quick comment. Please
> always CC t...@security.debian.org on such questions for if an update
> is wanted for DSA. This alows team members to better share the load
> for review, release, etc ... (and it's recorded futhermore on the team
> alias).

Oops, I assumed that the Security Team received all bugs tagged
‘security’ so I omitted the CC on purpose… my bad.
 
> I think we should release this through stretch-security. The debdiff
> per se looks already good. Were you able to test the update in
> production under stretch?

Yes, I did test the update.

> There is though one no-dsa issue,
> https://security-tracker.debian.org/tracker/CVE-2018-171 which
> would be good to be included. Could you backport that fix as well and
> send a new debdiff for quick review+ack for upload?

Sure, new debdiff attached.

-- 
Guilhem.
diff -Nru roundcube-1.2.3+dfsg.1/debian/changelog 
roundcube-1.2.3+dfsg.1/debian/changelog
--- roundcube-1.2.3+dfsg.1/debian/changelog 2017-11-09 06:45:05.0 
+0100
+++ roundcube-1.2.3+dfsg.1/debian/changelog 2018-04-21 01:51:56.0 
+0200
@@ -1,3 +1,16 @@
+roundcube (1.2.3+dfsg.1-4+deb9u2) stretch-security; urgency=high
+
+  * Backport fix for CVE-2018-9846: When the archive plugin enabled and
+configured, it's possible to exploit the unsanitized, user-controlled
+"_uid" parameter to perform an MX (IMAP) injection attack.
+https://github.com/roundcube/roundcubemail/issues/6238
+(Closes: #895184).
+  * Backport fix for CVE-2018-171: Insecure Permissions vulnerability in
+enigma plugin that can result in exfiltration of gpg private key.
+https://github.com/roundcube/roundcubemail/issues/6173
+
+ -- Guilhem Moulin   Sat, 21 Apr 2018 01:51:56 +0200
+
 roundcube (1.2.3+dfsg.1-4+deb9u1) stretch-security; urgency=high
 
   * Backport fix for CVE-2017-16651: File disclosure vulnerability caused by
diff -Nru roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-171.patch 
roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-171.patch
--- roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-171.patch
1970-01-01 01:00:00.0 +0100
+++ roundcube-1.2.3+dfsg.1/debian/patches/CVE-2018-171.patch
2018-04-21 01:51:56.0 +0200
@@ -0,0 +1,74 @@
+commit 48417c5fc9f6eb4b90500c09596606d489c700b5
+Author: Aleksander Machniak 
+Date:   Sun Mar 4 09:14:43 2018 +0100
+
+Remove default for enigma_pgp_homedir (#6173)
+
+To make the default installation more secure force users to set the folder.
+Added notes that it should be secured or not accessible from the web 
browser.
+
+---
+ plugins/enigma/README  |   15 +--
+ plugins/enigma/config.inc.php.dist |4 ++--
+ plugins/enigma/home/.htaccess  |7 ---
+ plugins/enigma/lib/enigma_driver_gnupg.php |2 +-
+ 4 files changed, 16 insertions(+), 12 deletions(-)
+
+--- a/plugins/enigma/config.inc.php.dist
 b/plugins/enigma/config.inc.php.dist
+@@ -12,8 +12,8 @@ $config['enigma_smime_driver'] = 'phpssl
+ // Enables logging of enigma operations (including Crypt_GPG debug info)
+ $config['enigma_debug'] = false;
+ 
+-// Keys directory for all users. Default 'enigma/home'.
+-// Must be writeable by PHP process
++// REQUIRED! Keys directory for all users.
++// Must be writeable by PHP process, and not in the web server document root
+ $config['enigma_pgp_homedir'] = null;
+ 
+ // Location of gpg binary. By default it will be auto-detected.
+--- a/plugins/enigma/home/.htaccess
 /dev/null
+@@ -1,7 +0,0 @@
+-# deny webserver access to this directory
+-
+-Require all denied
+-
+-
+-Deny from all
+-
+--- a/plugins/enigma/lib/enigma_driver_gnupg.php
 b/plugins/enigma/lib/enigma_driver_gnupg.php
+@@ -39,7 +39,7 @@ class enigma_driver_gnupg extends enigma
+  */
+ function init()
+ {
+-$homedir = $this->rc->config->get('enigma_pgp_homedir', INSTALL_PATH 
. 'plugins/enigma/home');
++$homedir = $this->rc->config->get('enigma_pgp_homedir');
+ $debug   = $this->rc->config->get('enigma_debug');
+ $binary  = $this->rc->config->get('enigma_pgp_binary');
+ $agent   = $this->rc->config->get('enigma_pgp_agent');
+--- a/plugins/enigma/README
 b/plugins/enigma/README
+@@ -21,8 +21,19 @@ Implemented features:
+ + Attaching public keys to email
+ 
+ 
+-TODO:
+--
++INSTALLATION
++
++
++1. Rename config.inc.php.dist to config.inc.php.
++2. Create a directory for keys storage that is writeable for the PHP process.
++   This directory should be out of the document root, so it is not accessible
++   from the web browser. Set it's location in $config['enigma_pgp_homedir'].
++3. Make sure GnuPG is installed.
++
++
++TODO
++
++
+ - Handling of big messages with temp files
+ - Key info in contact details page (optional)
+ - Extended key management:
diff

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

[Tiago Daitx]

I just realized that the existing patch debian/patches/docs.patch was
the one modifying the javaApiUrl to point to the default-jdk api, I
updated it to point to default-jdk-doc.

Please consider the new debdiff and ignore the old one.

thanks

-- 
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/changelog	2018-04-20 19:03:01.0 -0300
@@ -1,3 +1,13 @@
+gradle (3.4.1-8) UNRELEASED; urgency=medium
+
+  * debian/patches/gnu-style-release-flag-jdk9.patch: Use GNU-style release
+flag for Java 9 compiler. (Closes: #895616)
+  * debian/patches/docs.patch: use default-jdk-doc instead of default-jdk
+path for javaApiUrl in subprojects/docs/docs.gradle. LP: #1765866.
+(Closes: #896436)
+
+ -- Tiago Stürmer Daitx   Fri, 20 Apr 2018 22:03:01 +
+
 gradle (3.4.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/docs.patch gradle-3.4.1/debian/patches/docs.patch
--- gradle-3.4.1/debian/patches/docs.patch	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/patches/docs.patch	2018-04-20 19:03:01.0 -0300
@@ -100,7 +100,7 @@
  
 -def javaApiUrl = "https://docs.oracle.com/javase/7/docs/api";
 -def groovyApiUrl = "http://docs.groovy-lang.org/docs/groovy-${versions.groovy}/html/gapi";
-+def javaApiUrl = "file:///usr/share/doc/default-jdk/api/"
++def javaApiUrl = "file:///usr/share/doc/default-jdk-doc/api/"
 +def groovyApiUrl = "file:///usr/share/doc/groovy/api/"
  def mavenApiUrl = "http://maven.apache.org/ref/${versions.maven}/maven-model/apidocs";
  
diff -Nru gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
--- gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	1969-12-31 21:00:00.0 -0300
+++ gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	2018-04-20 19:03:01.0 -0300
@@ -0,0 +1,97 @@
+Description: Use GNU-style release flag for Java 9 compiler
+ Since JDK 9 b135, only the new GNU-style option with double-dashes is
+ supported for the "--release" flag (see
+ https://bugs.openjdk.java.net/browse/JDK-8160851).
+Author: Yannick Welsch 
+Origin: upstream, https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Bug-Debian: https://bugs.debian.org/895616 
+Forwarded: not-needed
+Applied-Upstream: https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 142f2f5233e77ba33146efe3815cd3b4b1245993 Mon Sep 17 00:00:00 2001
+From: Yannick Welsch 
+Date: Mon, 17 Jul 2017 15:53:17 +0200
+Subject: [PATCH] Use GNU-style release flag for Java 9 compiler (#2474)
+
+Since JDK 9 b135, only the new GNU-style option with double-dashes is supported for the "--release" flag
+(see https://bugs.openjdk.java.net/browse/JDK-8160851).
+---
+ design-docs/jdk9-support.md | 6 +++---
+ .../api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java| 2 +-
+ .../src/main/java/org/gradle/api/tasks/compile/CompileOptions.java  | 6 +++---
+ .../internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy  | 6 +++---
+ .../org/gradle/java/compile/BasicJavaCompilerIntegrationSpec.groovy | 4 ++--
+ 5 files changed, 12 insertions(+), 12 deletions(-)
+
+
+--- a/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
 b/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
+@@ -227,7 +227,7 @@ public class JavaCompilerArgumentsBuilde
+ }
+ 
+ private boolean releaseOptionIsSet(List compilerArgs) {
+-return compilerArgs != null && compilerArgs.contains("-release");
++return compilerArgs != null && compilerArgs.contains("--release");
+ }
+ 
+ private void addClasspath() {
+--- a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
 b/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
+@@ -315,10 +315,10 @@ public class CompileOptions extends Abst
+  * Defaults to the empty list.
+  *
+  * Compiler arguments not supported by the DSL can be added here. For example, it is possible
+- * to pass the {@code -release} option of JDK 9:
+- * compilerArgs.addAll(['-release', '7'])
++ * to pass the {@code --release} option of JDK 9:
++ * compilerArgs.addAll(['--release', '7'])
+  *
+- * Note that if {@code -release} is added then {@code -target} and {@code -source}
++ * Note that if {@code --release} is added 

Bug#896437: evolution-alarm-notify: evolution-alarm-notify consuming a lot of virtual memory

[Witold Baryluk]

Package: libevolution
Version: 3.28.1-2
Severity: normal
File: evolution-alarm-notify

I see no problems with evolution-alarm-notify, but I just spotted that it is 
using enormous amount of virtual memory:


  PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
 1261 baryluk   20   0   97,2g  61064  49668 S   0,0   0,2   0:00.22 
/usr/lib/evolution/evolution-alarm-notify

97 GB!

Unknown why.

Thanks.




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

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

Versions of packages libevolution depends on:
ii  evolution-common 3.28.1-2
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libcamel-1.2-61  3.28.1-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libchamplain-0.12-0  0.12.16-2
ii  libchamplain-gtk-0.12-0  0.12.16-2
ii  libclutter-1.0-0 1.26.2+dfsg-4
ii  libcryptui0a 3.12.2-5
ii  libebook-1.2-19  3.28.1-1
ii  libebook-contacts-1.2-2  3.28.1-1
ii  libecal-1.2-19   3.28.1-1
ii  libedataserver-1.2-233.28.1-1
ii  libedataserverui-1.2-2   3.28.1-1
ii  libenchant1c2a   1.6.0-11.1
ii  libgail-3-0  3.22.30-1
ii  libgcr-base-3-1  3.28.0-1
ii  libgcr-ui-3-13.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgeocode-glib0 3.25.4.1-4
ii  libglib2.0-0 2.56.1-2
ii  libgnome-autoar-0-0  0.2.3-1
ii  libgnome-autoar-gtk-0-0  0.2.3-1
ii  libgnome-desktop-3-173.28.1-1
ii  libgtk-3-0   3.22.30-1
ii  libgtkspell3-3-0 3.0.9-2
ii  libgweather-3-15 3.28.1-1
ii  libical3 3.0.1-5
ii  libldap-2.4-22.4.45+dfsg-1
ii  libnotify4   0.7.7-3
ii  libnspr4 2:4.19-1
ii  libnss3  2:3.36.1-1
ii  libpango-1.0-0   1.42.1-1
ii  libpangocairo-1.0-0  1.42.1-1
ii  libsecret-1-00.18.6-1
ii  libsoup2.4-1 2.62.1-1
ii  libsqlite3-0 3.23.1-1
ii  libwayland-server0   1.14.93-1
ii  libwebkit2gtk-4.0-37 2.21.1-1
ii  libxml2  2.9.7+dfsg-1
ii  libytnef01.9.2-2

libevolution recommends no packages.

libevolution suggests no packages.

-- no debconf information

Bug#896379: python-avc: avc fails to import

[Fabrizio Pollastri]

  
  
Il 20/04/2018 22:00, Helmut Grohne ha
  scritto:


  Package: python-avc
Version: 0.8.3-1.1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-avc importing the module avc
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/avc/__init__.py", line 29, in 
import avccore
  File "/usr/lib/python2.7/dist-packages/avc/avccore.py", line 66, in 
raise error,'No supported toolkit found: import it before AVC import.'
avc.avccore.error: 'No supported toolkit found: import it before AVC import.'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut


Since python-avc 0.8.3-1.1 supports different widget toolkits and
  the user is normally interested to only one toolkit among these, I
  preferred to set them as "suggested" (the list follows) and not as
  dependencies. If there is a better way to define this, any help is
  appreciated (I am not an expert Debian packager).


  

  sug: jython
(>= 2.5) 
  Python seamlessly integrated with Java 

  
  

  sug: python-gtk2
(>= 2.0) 
  Python bindings for the GTK+ widget set 

  
  

  sug: python-qt3 (>= 3.0)
  
  Package not available 

  
  

  sug: python-qt4
(>= 4.0) 
  Python bindings for Qt4 

  
  

  sug: python-tk
(>= 2.0) 
  Tkinter - Writing Tk applications with Python 

  
  

  sug: python-wxgtk3.0
  
  Python interface to the wxWidgets Cross-platform
C++ GUI toolki


  
  Fabrizio
  

  



  

Bug#896429: [Python-modules-team] Bug#896429: python3-django-tables2: django_tables2 fails to import

[Brian May]

Helmut Grohne  writes:

> django.core.exceptions.ImproperlyConfigured: Requested setting
> DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must
> either define the environment variable DJANGO_SETTINGS_MODULE or call
> settings.configure() before accessing settings.

I believe this bug report, and several others you filled recently that
contain this same text are false.

Like it or not, it is just not possible to import Django libraries
without providing a valid django settings file. This is not a sign that
something is broken.
-- 
Brian May 

Bug#893919: RFS: yasnippet-snippets/0.2-1

[Nicholas D Steeves]

Please note that 3/4 patches have been tentatively approved in an
upstream PR, pending merge, and the last one is Debian-specific
configuration.

Updated link to dsc:
 
   dget 
https://mentors.debian.net/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0.2-1.dsc
 
I've tagged 3f36c66 as debian/0.2-1 and will push after this package
is uploaded and accepted.

   git clone https://salsa.debian.org/emacsen-team/yasnippet-snippets.git
 
Updated changelog entry since last sponsorship request:

yasnippet-snippets (0.2-1) unstable; urgency=medium

  * New upstream version.
  * debian/control:
- Add elpa-yasnippet-snippets package
- Rely on ${elpa:Depends} for dependency resolution.
- Add Breaks, Replaces, and Provides.
- Yasnippet-snippets is now a dummy transitional package that depends
  on elpa-yasnippet-snippets.
- Change section to lisp, because the user interacts with the package
  yasnippet (section editor) while yasnippet-snippets is more of a
  library/resources package.
  * Update maintscripts to accommodate elpafication.
  * Add 0004-Add-missing-keys-for-all-markdown-mode-snippets.patch.
0001-Rename-files-that-are-prohibited-in-Debian-packages.patch changed
the behaviour of markdown-mode snippets; previously each snippet
inherited its key from its respective file name.  This patch restores
the expected behaviour.
  * Declare Standards-Version: 4.1.4. (No changes needed)
  * Drop unneeded hunk from
0002-Define-canonical-yasnippet-snippets-dir-on-Debian-sy.patch
  * Add 0005-markdown-mode-Give-a-couple-snippets-more-meaningful.patch
- In my upstream PR the maintainer asked that for markdown-mode snippets
  to be given more meaningful names.  This patch implements that request.
  * gbp.conf: Upstream now tags releases.  Use their format for upstream-tag.
  * Add watch file because upstream now has stable releases.

 -- Nicholas D Steeves   Fri, 20 Apr 2018 18:39:32 -0400

yasnippet-snippets (0~git20180307.2b4c4d7e-2) unstable; urgency=medium


Regards,
Nicholas


signature.asc
Description: PGP signature

Bug#895748: mpi-default-dev: add riscv64 to list of MPI arches

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2018-04-16 5:00 GMT+02:00 Drew Parsons :
> On Sun, 2018-04-15 at 18:33 +0200, Manuel A. Fernandez Montecelo wrote:
>>
>> > Whether default to openmpi or to mpich, your choice.
>>
>> mpich fails due to tests in the current buildd, and although ideally
>> we'll work on it and get it properly fixed soon, for riscv64 it'd
>> better
>> be "openmpi" at the moment -- which is the defalt for almost all
>> other
>> arches anyway, as you say further down in your message.
>
> Thanks Manuel, that's a good reason for assigning openmpi to the
> riscv64 defaults then.


I committed support here:

  
https://salsa.debian.org/science-team/mpi-defaults/commit/9ecb7d06b0e283ad8464900bd6800214c1157115


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#870460: [Pkg-javascript-devel] Bug#870460: anyone working on npm?

[Jérémy Lal]

2018-04-19 11:04 GMT+02:00 Jérémy Lal :

>
>
> 2018-04-19 7:57 GMT+02:00 Diane Trout :
>
>>
>> Sure ! You could work on a branch of npm pkg-javascript repository,
>> and ask me for reviewing it and merging it. If all goes well, after that
>> first
>> review, you'll work directly on master branch.
>>
>>
>> Hi
>>
>> I finally had time to finish producing a hopefully easy to review set of
>> patches. (And went through and tried harder to delete packages from the
>> tarball that are packaged for Debian.)
>>
>> I couldn't commit to alioth right now, so I made a personal project for
>> npm on salsa.
>>
>> The branch is intended to be rebased on top of gbp import-orig --uscan.
>>
>> https://salsa.debian.org/diane/npm/tree/diane-npm-5.7.1-pkg
>>
>
> I've moved npm repository to salsa:js-team/npm.git
> I quickly reviewed the commits and it is great work, so please do
> a merge request and we'll fix what need to be fixed afterwise.
>
>

Merged !

I was inspecting npm's master branch and i couldn't resist fixing some
trivial, but also some non-trivial, things, so please make sure you stay
up-to-date with that branch.

Jérémy

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

[Tiago Daitx]

Please consider the attached debdiff as a fix.

Note: it includes the fix for bug #895616 as well, if that is not
wanted simply fully remove the chunk for the new file
gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
and modify the series and changelog accordingly.

thanks
diff -Nru gradle-3.4.1/debian/changelog gradle-3.4.1/debian/changelog
--- gradle-3.4.1/debian/changelog	2018-04-11 18:19:46.0 -0300
+++ gradle-3.4.1/debian/changelog	2018-04-20 19:03:01.0 -0300
@@ -1,3 +1,13 @@
+gradle (3.4.1-8) UNRELEASED; urgency=medium
+
+  * debian/patches/gnu-style-release-flag-jdk9.patch: Use GNU-style release
+flag for Java 9 compiler. (Closes: #895616)
+  * debian/patches/use-local-artifacts.patch: use default-jdk-doc instead
+of default-jdk path for javaApiUrl in subprojects/docs/docs.gradle.
+(Closes: #896436)
+
+ -- Tiago Stürmer Daitx   Fri, 20 Apr 2018 22:03:01 +
+
 gradle (3.4.1-7) unstable; urgency=medium
 
   * Team upload.
diff -Nru gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch
--- gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	1969-12-31 21:00:00.0 -0300
+++ gradle-3.4.1/debian/patches/gnu-style-release-flag-jdk9.patch	2018-04-12 18:01:22.0 -0300
@@ -0,0 +1,97 @@
+Description: Use GNU-style release flag for Java 9 compiler
+ Since JDK 9 b135, only the new GNU-style option with double-dashes is
+ supported for the "--release" flag (see
+ https://bugs.openjdk.java.net/browse/JDK-8160851).
+Author: Yannick Welsch 
+Origin: upstream, https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Bug-Debian: https://bugs.debian.org/895616 
+Forwarded: not-needed
+Applied-Upstream: https://github.com/gradle/gradle/commit/142f2f5233e77ba33146efe3815cd3b4b1245993
+Reviewed-by: Tiago Stürmer Daitx 
+Last-Update: 2018-04-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+
+From 142f2f5233e77ba33146efe3815cd3b4b1245993 Mon Sep 17 00:00:00 2001
+From: Yannick Welsch 
+Date: Mon, 17 Jul 2017 15:53:17 +0200
+Subject: [PATCH] Use GNU-style release flag for Java 9 compiler (#2474)
+
+Since JDK 9 b135, only the new GNU-style option with double-dashes is supported for the "--release" flag
+(see https://bugs.openjdk.java.net/browse/JDK-8160851).
+---
+ design-docs/jdk9-support.md | 6 +++---
+ .../api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java| 2 +-
+ .../src/main/java/org/gradle/api/tasks/compile/CompileOptions.java  | 6 +++---
+ .../internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy  | 6 +++---
+ .../org/gradle/java/compile/BasicJavaCompilerIntegrationSpec.groovy | 4 ++--
+ 5 files changed, 12 insertions(+), 12 deletions(-)
+
+
+--- a/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
 b/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java
+@@ -227,7 +227,7 @@ public class JavaCompilerArgumentsBuilde
+ }
+ 
+ private boolean releaseOptionIsSet(List compilerArgs) {
+-return compilerArgs != null && compilerArgs.contains("-release");
++return compilerArgs != null && compilerArgs.contains("--release");
+ }
+ 
+ private void addClasspath() {
+--- a/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
 b/subprojects/language-java/src/main/java/org/gradle/api/tasks/compile/CompileOptions.java
+@@ -315,10 +315,10 @@ public class CompileOptions extends Abst
+  * Defaults to the empty list.
+  *
+  * Compiler arguments not supported by the DSL can be added here. For example, it is possible
+- * to pass the {@code -release} option of JDK 9:
+- * compilerArgs.addAll(['-release', '7'])
++ * to pass the {@code --release} option of JDK 9:
++ * compilerArgs.addAll(['--release', '7'])
+  *
+- * Note that if {@code -release} is added then {@code -target} and {@code -source}
++ * Note that if {@code --release} is added then {@code -target} and {@code -source}
+  * are ignored.
+  */
+ @Input
+--- a/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
 b/subprojects/language-java/src/test/groovy/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilderTest.groovy
+@@ -79,14 +79,14 @@ class JavaCompilerArgumentsBuilderTest e
+ builder.build() == ["-target", "1.4"] + defaultOptions
+ }
+ 
+-def "removes -source and -target option if -release is present"() {
++def "removes -source and -target option if --release is present"() {
+ when:
+-spec.compileOptions.compilerArgs += ['-release', '7']
++spec.compileOptions.compilerArgs += ['--release', '7']
+ spec.sourceCompatibility = '1.7'
+ spec.targetCompat

Bug#879642: simple-cdd: build-simple-cdd fails with unsigned local repository

[Vagrant Cascadian]

Control: severity 879642 serious
Control: tags 879642 +confirmed

On 2017-10-23, Austin Roach wrote:
> The simple-cdd README suggests that simply running 'build-simple-cdd'
> should be sufficient to build a barebones ISO out of the box. Currently,
> this fails on sid because of an unsigned local repository (logfile
> attached).

Thanks for the bug report, I'm able to confirm it, without much
surprise. :)


> This seems to be related to commit
> cbaf353ead58aa9eefe51542b6ad91e69b6289ce to apt, which now issues an
> error instead of a warning for insecure repositories. I was able to
> successfully create an ISO by adding
> '-o Acquire::AllowInsecureRepositories=true' to the apt options in
> /usr/share/debian-cd/tools/apt-selection before running
> 'build-simple-cdd'. This is undoubtedly not the best long-term fix,
> but it does verify the source of the problem.

Thanks for the detailed explanation of the issue and a workaround.

I'll see if I can't get a proper fix sorted out soon.

Bumping the severity, as this isn't very useful without being able to
build the release it ships with.

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#896436: gradle FTBFS: error fetching java api url when building with openjdk-10

[Tiago Stürmer Daitx]

Package: gradle
Version: 3.4.1-7
Severity: normal

Dear Maintainer,

When using openjdk-10 as the default-jdk gradle will fail with the
following error:

:signing:assemble
:docs:javadocAlljavadoc: error - Error fetching URL: 
file:/usr/share/doc/default-jdk/api/
javadoc: warning - You have not specified the version of HTML to use.

Until openjdk-9 any missing api URLs were considered a warning but from
openjdk-10 upwards this was changed to an error.

The URL is missing because it has been hardcoded in the
subprojects/docs/docs.gradle file as:

def javaApiUrl = "file:///usr/share/doc/default-jdk/api/"

but the path /usr/share/doc/default-jdk is a link that belongs to the
default-jdk package which is not a build dependency of gradle (it is
in fact listed as an alternate dependency of default-jdk-headless).
Still, that is not enough as the default-jdk package does neither
contain nor depend on a package that holds the required api files.
Those files are in the openjdk-X-doc package and the dependency on it
is done through default-jdk-doc.

gradle already build depends on default-jdk-doc and even gradle-doc has
a dependency on it. By changing the javaApiUrl to point to the right api
directory, as in:

def javaApiUrl = "file:///usr/share/doc/default-jdk-doc/api/"

the build works as expected.

The patch debian/patches/use-local-artifacts.patch should be updated to
reflect this new patch.

thanks

Tiago

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

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

Bug#896435: [ftp.debian.org] remove from NEWS node-acorn-node

[Bastien ROUCARIÈS]

Package: ftp.debian.org
Severity: normal


Please remove my package from news. will merge with another package

Bastien

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

Bug#894209: simple-cdd: Specifying '--dist' to build-simple-cdd creates ISO with wrong name

[Vagrant Cascadian]

On 2018-04-20, Vagrant Cascadian wrote:
> On 2018-03-27, Michael Firth wrote:
>> $ build-simple-cdd --dist jessie
>>
>> The expected CD images should be version 8.10, which is the latest
>> Jessie release, but instead the file created is called:
>>
>> debian-9.4-amd64-CD-1.iso
>
> Thanks for the bug report!
>
> I just confirmed this.
>
> I am 95% certain that the only thing the version number is used for is
> the ISO file name.

I guess it's also in the ISO headers...


> You can work around this issue by creating a jessie profile in
> profiles/jessie.conf:
>
>   CODENAME=jessie
>   DEBVERSION=8
>
> and then:
>
>   build-simple-cdd --profiles=jessie

No, that doesn't work either. Hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#774711: openssh 7.6 changes

[Matt Taggart]

Hi,

Just a quick update on #774711. As pre-announced in earlier releases,
OpenSSH 7.6 did drop support for some old unsafe crypto options:

* dropped SSHv1 protocol support
* removed hmac-ripemd160 MAC
* removed arcfour, blowfish and CAST ciphers
* refuses RSA keys <1024 bits in length
* does not offer CBC ciphers by default

As far as I know, the following potentially unsafe things are still
supported in 7.7:

Keys:
* NIST curves

Kex:
* NIST curves
* diffie-hellman-group14-sha1
* diffie-hellman-group-exchange-sha1 (min 2048 now at least)

MACs:
* sha1
* umac-64

Debian users wanting to drop support for the legacy crypto options
mentioned previously in this bug can use the following:

===
HostKeyAlgorithms ssh-ed25519-cert-...@openssh.com, ssh-ed25519,\
ssh-rsa-cert-...@openssh.com, ssh-rsa-cert-...@openssh.com,ssh-rsa

KexAlgorithms curve25519-sha...@libssh.org,\
diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com,
aes128-...@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,\
umac-128-...@openssh.com,hmac-sha2-512,hmac-sha2-256,\
umac-...@openssh.com
===


-- 
Matt Taggart
tagg...@debian.org

Bug#896326: python-csoundac: CsoundAC fails to import

[Felipe Sateler]

Control: severity -1 important
Control: forwarded -1 https://github.com/gogins/csound-extended/issues/27

Hi Helmut,

Thanks for your bug report.

On Fri, Apr 20, 2018 at 5:00 PM, Helmut Grohne  wrote:
> Package: python-csoundac
> Version: 1:6.10.0~dfsg-1
> Severity: serious
> User: helm...@debian.org
> Usertags: python-import
>
> After installing python-csoundac importing the module CsoundAC
> into a python interpreter fails with the following error:
>
> 0dBFS level = 32768.0
> --Csound version 6.10 (double samples) 2018-01-27
> [commit: none]
> libsndfile-1.0.28
> Csound tidy up: Segmentation fault
> backtrace() returned 14 addresses
> /usr/lib/libcsound64.so.6.0(+0x40c43) [0x7f6745d52c43]
> /lib/x86_64-linux-gnu/libc.so.6(+0x34f00) [0x7f6746cdff00]
> python(PyImport_AddModule+0x1c) [0x55ca472194ac]
> python(PyRun_SimpleStringFlags+0x19) [0x55ca47292409]
> /usr/lib/python2.7/dist-packages/_csnd6.x86_64-linux-gnu.so(+0x288d9) 
> [0x7f674159c8d9]
> /usr/lib/libcsound64.so.6.0(csoundMessage+0xa1) [0x7f6745d532a1]
> /usr/lib/libcsound64.so.6.0(csoundCleanup+0x33e) [0x7f6745d7706e]
> /usr/lib/libcsound64.so.6.0(+0x4239c) [0x7f6745d5439c]
> /usr/lib/libcsound64.so.6.0(csoundDestroy+0xa0) [0x7f6745d55120]
> /usr/lib/libcsound64.so.6.0(+0x431c0) [0x7f6745d551c0]
> /lib/x86_64-linux-gnu/libc.so.6(+0x37831) [0x7f6746ce2831]
> /lib/x86_64-linux-gnu/libc.so.6(+0x3792a) [0x7f6746ce292a]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xee) [0x7f6746ccca8e]
> python(_start+0x2a) [0x55ca4720db1a]

The crash actually happens upon module unload (when the interpreter is
exiting). I'm therefore lowering the severity since it doesn't make
the module unusable.

-- 

Saludos,
Felipe Sateler

Bug#894209: simple-cdd: Specifying '--dist' to build-simple-cdd creates ISO with wrong name

[Vagrant Cascadian]

Control: tags 894209 +confirmed
Control: severity 894209 normal

On 2018-03-27, Michael Firth wrote:
> When running 'build-simple-cdd' with the '--dist' option on Debian
> Stretch, the resulting ISO file has the version number of the host
> Debian system, not the built system.
...
> Example invocation:
> $ build-simple-cdd --dist jessie
>
> The expected CD images should be version 8.10, which is the latest
> Jessie release, but instead the file created is called:
>
> debian-9.4-amd64-CD-1.iso

Thanks for the bug report!

I just confirmed this.

I am 95% certain that the only thing the version number is used for is
the ISO file name. The name specified with --dist is what is actually
used to select what packages to download and include on the ISO image,
and what the resulting ISO is named internally.

You can work around this issue by creating a jessie profile in
profiles/jessie.conf:

  CODENAME=jessie
  DEBVERSION=8

and then:

  build-simple-cdd --profiles=jessie



> Is building a CD for an old distribution still supported?

Try to, but there are sometimes bugs.


When simple-cdd tries to build a different --dist or CODENAME it
shouldn't assume it's the same as the host system, or at the very least,
unset the DEBVERSION value. Will look into it at some point.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#896283: python-rpy: rpy fails to import

[Dirk Eddelbuettel]

Hallo Helmut,

On 20 April 2018 at 22:01, Helmut Grohne wrote:
| Package: python-rpy
| Version: 1.0.3-30+b3
| Severity: serious
| User: helm...@debian.org
| Usertags: python-import
| 
| After installing python-rpy importing the module rpy
| into a python interpreter fails with the following error:
| 
| Traceback (most recent call last):
|   File "", line 1, in 
|   File "/usr/lib/python2.7/dist-packages/rpy.py", line 134, in 
| """ % RVERSION)
| RuntimeError: No module named _rpy3044
| 
|   RPy module can not be imported. Please check if your rpy
|   installation supports R 3.4.4. If you have multiple R versions
|   installed, you may need to set RHOME before importing rpy. For
|   example:
|   
|   >>> from rpy_options import set_options
|   >>> set_options(RHOME='c:/progra~1/r/rw2011/')
|   >>> from rpy import *
|   
|   
| 
| The vast majority of import failures is attributed to missing dependencies.
| Often times that manifests as an ImportError or ModuleNotFoundError.
| Typically, dependencies should be inserted by dh-python via ${python:Depends}
| or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
| install_requires in setup.py. Sometimes a missing dependency of a dependency
| is the cause, in such cases this bug should be reassigned.

rpy was abandonded upstream maybe a decade ago, maybe longer. It needs hard
rebuilds for each new R version -- here R 3.4.4 -- and at some point that
just ceased to be useful.

There is rpy2 which is current and maintained for python 3. We also forked
off the last version of rpy2 that can be build with python 2.7 as another
software suite needed that.

Please switch to rpy2.

Dirk

| 
| Helmut

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#889916: simple-cdd-profiles postinst never prompts for which profiles to install

[Vagrant Cascadian]

On 2018-02-08, Sam Overton wrote:
> I am including multiple profiles in my image, but during installation I am
> never prompted for which profile(s) to install, and instead only the
> default profile is used.
>
> The install log contains the following:
...
> Feb  6 18:35:32 anna[2826]: (process:5107): asking simple-cdd debconf 
> questions...
> Feb  6 18:35:32 anna[2826]: (process:5107): loading simple-cdd preseeding 
> files
> Feb  6 18:35:32 anna[2826]: (process:5107): profiles:
> Feb  6 18:35:32 anna[2826]: (process:5107): Finished with simple-cdd debconf 
> preseeding
> Feb  6 18:35:32 anna[2826]: (process:5107): Queuing simple-cdd udebs...
...
> So, it looks like the simple-cdd-profiles postinst script is running, but
> it never prompts for profiles to install.
>
> I am building with the following command:
>
> build-simple-cdd --conf simple-cdd.conf --locale en_GB --keyboard gb
>
> where simple-cdd.conf contains the following:
>
> profiles="gw build"
> mirror_components="main non-free"
> local_packages="./local-packages/"
> export ARCH=amd64
> export KERNEL_PARAMS="preseed/file=/cdrom/simple-cdd/default.preseed 
> priority=critical"

Well, priority critical only one step shy of entirely non-interactive,
and so blocked it from asking the question; the question which asks for
which profiles is only asked at priority high or lower (and I believe is
the default priority).

So don't override the priority; questions need to be preseeded away if
you want it to ask you which profiles :)

Though, I suppose a simple-cdd mode where it runs in priority=critical,
but still asks for the profiles would be interesting... could probably
selectively enable that with another preseeded
question... e.g. simple-cdd/always-ask-profiles=true.


Try creating profiles/default.conf:

  mirror_components="main non-free"
  local_packages="./local-packages/"
  locale=en_GB
  keyboard=gb

and running:

  build-simple-cdd --profiles gw,build


The --conf option is really a legacy option that predates profiles, and
I suspect it may not work correctly in a number of cases.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#896434: vlan interfaces must be created in raw-device ifup post, not during raw-device udev processing

[Dan Streetman]

Package: vlan
Version: 1.9-3.2
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

Currently, vlan interfaces are created by /lib/udev/vlan-network-interface 
during
udev detection/processing of the vlan's raw-device.  However this can lead to
a race condition of both the raw-device and its vlan interface(s) being ifup'ed,
and if a vlan interface is brought up before its raw-device, and that raw-device
is taken down during ifup (such as is required for e.g. bonds with certain 
params),
any additional configuration on the vlan(s) will be lost when they are taken 
down.
For example, if a vlan has a gateway set, it will be lost if the vlan is ifup'ed
before its raw-device (bond) is ifup'ed.
See https://bugs.launchpad.net/bugs/1573272 for details.

In Ubuntu, the attached patch was applied to achieve the following:

  * Revert change for lp1573272; instead fix by redesigning when vlan
interfaces are created; after raw-device ifup, not during raw-device
udev processing. (LP: #1701023)

There are multiple bugs related to this vlan change, all summarized here:
https://bugs.launchpad.net/bugs/1701023

Thanks for considering the patch.


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

Kernel: Linux 4.15.0-13-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -u vlan-1.9/debian/control vlan-1.9/debian/control
--- vlan-1.9/debian/control
+++ vlan-1.9/debian/control
@@ -1,8 +1,7 @@
 Source: vlan
 Section: misc
 Priority: extra
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Ard van Breemen 
+Maintainer: Ard van Breemen 
 Uploaders: Loic Minier 
 Build-Depends: debhelper (>= 5)
 Standards-Version: 3.7.2
diff -u vlan-1.9/debian/network/if-pre-up.d/vlan 
vlan-1.9/debian/network/if-pre-up.d/vlan
--- vlan-1.9/debian/network/if-pre-up.d/vlan
+++ vlan-1.9/debian/network/if-pre-up.d/vlan
@@ -60,9 +60,8 @@
 exit 1
 fi
 if [ ! -e "/sys/class/net/$IFACE" ]; then
-# Try ifup for the raw device, if it fails then bring it up directly
-# this is required e.g. there is no configuration for the raw device
-ifup $IF_VLAN_RAW_DEVICE || ip link set up dev $IF_VLAN_RAW_DEVICE
+# we cannot call ifup for the raw-device here, see LP: #1701023
+ip link set up dev $IF_VLAN_RAW_DEVICE
 vconfig add $IF_VLAN_RAW_DEVICE $VLANID
 fi
 fi
diff -u vlan-1.9/debian/vlan-network-interface 
vlan-1.9/debian/vlan-network-interface
--- vlan-1.9/debian/vlan-network-interface
+++ vlan-1.9/debian/vlan-network-interface
@@ -25,10 +25,21 @@
 
-# Now that the environment is ready, call the pre-up script to create the 
vlan
-export IFACE IF_VLAN_RAW_DEVICE
-
-# Create the VLANs related to the interface
-if [ "$IF_VLAN_RAW_DEVICE" = "$INTERFACE" ] || \
-echo $IFACE | grep -q $INTERFACE; then
-/etc/network/if-pre-up.d/vlan
+# If there is no vlan-raw-device defined, check for vlan-formatted name
+# for example, eth1.123
+if [ -z "$IF_VLAN_RAW_DEVICE" ]; then
+IF_VLAN_RAW_DEVICE=${IFACE%%.*}
+[ "$IFACE" = "$IF_VLAN_RAW_DEVICE" ] && continue
 fi
+
+# Check if this (vlan) $IFACE uses raw-device $INTERFACE
+[ "$IF_VLAN_RAW_DEVICE" != "$INTERFACE" ] && continue
+
+# If we're being called directly from udev, we only want to create the
+# vlan interface if there is no associated ifupdown config for the
+# raw-device; otherwise the ifup for the raw-device will create the
+# vlan interface(s)
+[ "$1" = "UDEV" ] && ifquery $IF_VLAN_RAW_DEVICE && continue
+
+# Create the VLAN interface(s) related to the raw-device interface
+export IFACE IF_VLAN_RAW_DEVICE
+/etc/network/if-pre-up.d/vlan
 done
diff -u vlan-1.9/debian/vlan.vlan-network-interface.udev 
vlan-1.9/debian/vlan.vlan-network-interface.udev
--- vlan-1.9/debian/vlan.vlan-network-interface.udev
+++ vlan-1.9/debian/vlan.vlan-network-interface.udev
@@ -1 +1 @@
-ACTION=="add", SUBSYSTEM=="net", RUN+="vlan-network-interface"
+ACTION=="add", SUBSYSTEM=="net", RUN+="vlan-network-interface UDEV"
only in patch2:
unchanged:
--- vlan-1.9.orig/debian/network/if-up.d/vlan
+++ vlan-1.9/debian/network/if-up.d/vlan
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+# after vlan-raw-device interface is ifup'ed, then
+# create any associated vlan interfaces
+# (LP: #1701032)
+if [ -x /lib/udev/vlan-network-interface ]; then
+  env INTERFACE=$IFACE /lib/udev/vlan-network-interface
+fi

Bug#896433: ifupdown: ifquery can't be called recursively from ifup/ifdown, but if-pre/up.d scripts call it

[Dan Streetman]

Package: ifupdown
Version: 0.8.17
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

Scripts in the if-pre-up.d and if-up.d dirs call ifquery directly, or call it 
indirectly
through other scripts.  However ifquery tries to lock each interface and exits 
with
error if it's called from ifup or ifdown.  Since ifquery doesn't change 
anything,
there is no reason interface locks need to be taken; ifquery can be safely run
recurseively from ifup/ifdown.

In Ubuntu, the attached patch was applied to achieve the following:

  * Allow ifquery to be called recursively from ifup/ifdown.
Many of the if-pre-up.d/if-up.d scripts call ifquery directly,
or indirectly through other scripts they call; these ifquery calls
will fail.  This changes that to allow ifquery to run, since
ifquery does not change anything, it can be safely called
from ifup/ifdown.  (LP: #1701023)

Please see
https://bugs.launchpad.net/ubuntu/bionic/+source/ifupdown/+bug/1701023
for details on why this patch is required.

Thanks for considering the patch.


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

Kernel: Linux 4.15.0-13-generic (SMP w/24 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ifupdown-0.8.17ubuntu1/debian/control 
ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/debian/control
--- ifupdown-0.8.17ubuntu1/debian/control   2018-03-21 17:38:53.0 
-0400
+++ ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/debian/control  2018-04-20 
16:37:59.0 -0400
@@ -1,8 +1,7 @@
 Source: ifupdown
 Section: admin
 Priority: important
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Guus Sliepen 
+Maintainer: Guus Sliepen 
 Standards-Version: 3.9.8
 Build-Depends: debhelper (>= 9.20120410~), dh-systemd
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/ifupdown.git
diff -Nru ifupdown-0.8.17ubuntu1/main.c 
ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/main.c
--- ifupdown-0.8.17ubuntu1/main.c   2016-11-25 06:16:17.0 -0500
+++ ifupdown-0.8.17ubuntu1+hf1701023v20180420b1/main.c  2018-04-20 
16:37:55.0 -0400
@@ -785,6 +785,7 @@
/* Split into physical and logical interface */
 
char iface[80], liface[80];
+   FILE *lock = NULL, *plock = NULL;
 
strncpy(iface, target_iface, sizeof(iface));
iface[sizeof(iface) - 1] = '\0';
@@ -840,44 +841,44 @@
return false;
}
 
+   if (!no_act) {
+   /* Bail out if we are being called recursively on the same 
interface */
 
-   /* Bail out if we are being called recursively on the same interface */
-
-   char envname[160];
-   char *siface = strdup(iface);
-   sanitize_file_name(siface);
-   snprintf(envname, sizeof envname, "IFUPDOWN_%s", siface);
-   free(siface);
-   char *envval = getenv(envname);
-   if(envval && is_locked(iface)) {
-   fprintf(stderr, "%s: recursion detected for interface %s in %s 
phase\n", argv0, iface, envval);
-   return false;
-   }
-
-   /* Are we configuring a VLAN interface? If so, lock the parent 
interface as well. */
-
-   char piface[80];
-   FILE *plock = NULL;
-   strncpy(piface, iface, sizeof piface);
-   if ((pch = strchr(piface, '.'))) {
-   *pch = '\0';
-   snprintf(envname, sizeof envname, "IFUPDOWN_%s", piface);
+   char envname[160];
+   char *siface = strdup(iface);
+   sanitize_file_name(siface);
+   snprintf(envname, sizeof envname, "IFUPDOWN_%s", siface);
+   free(siface);
char *envval = getenv(envname);
-   if(envval && is_locked(piface)) {
-   fprintf(stderr, "%s: recursion detected for parent 
interface %s in %s phase\n", argv0, piface, envval);
+   if(envval && is_locked(iface)) {
+   fprintf(stderr, "%s: recursion detected for interface 
%s in %s phase\n", argv0, iface, envval);
return false;
}
 
-   plock = lock_interface(piface, NULL);
+   /* Are we configuring a VLAN interface? If so, lock the parent 
interface as well. */
+
+   char piface[80];
+   strncpy(piface, iface, sizeof piface);
+   if ((pch = strchr(piface, '.'))) {
+   *pch = '\0';
+   snprintf(envname, sizeof envname, "IFUPDOWN_%s", 
piface);
+   char *envval = getenv(envname);
+   if(envval && is_locked(piface)) {
+   fprintf(stderr, "%s: recursion detected for 
parent interface %

Bug#896350: python3-mapbox-vector-tile: mapbox_vector_tile fails to import

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 04/20/2018 10:01 PM, Helmut Grohne wrote:
> ModuleNotFoundError: No module named 'lib2to3'

Fixed in git, python3-lib2to3 added to dependencies.

Kind Regards,

Bas

Bug#895937: database upgrade from schema 8 to 9 fails - workaround

[tv.deb...@googlemail.com]

Since Digikam crashes on Mariadb database conversion I tried reverting 
to older Digikam version, but that only gave me an empty view. So the 
database is unusable with the previous Digikam versions.
Restoring a previous database version leads to the same result: failed 
conversion, corruption that makes it unusable with previous Digikam version.


I downloaded the Digikam 5.9 appimage from digikam.org, which fails to 
convert the database too, but doesn't crash. From it I was able to 
migrate the Mariadb database to sqlite (conversion is very slow). Using 
the sqlite was totally impractical due to sluggishness and high system 
load, so I converted it back to "external Mysql" (Mariadb) with the 
exact same settings in database configuration as the previous one 'user, 
db names...).

Again conversion is slow but about twice as fast as the other way round.

Important, once conversion back to Mariadb is complete, and Digikam 
settings have been switched back to external Mysql database, Digikam 
scanned all content but displayed an empty view. I needed to close and 
relaunch before I could see the images.


I can now use Digikam 5.9 from Debian Unstable with the newly converted 
Mariadb external database, I did not notice any data loss, tags are 
intact too..


So problem solved for me, the double database conversion workaround is 
time expensive but works.

Bug#895975: #895975: simple-cdd: Fail gracefully with noexec and/or unsupported filesystem

[Vagrant Cascadian]

Control: retitle 895975 simple-cdd: Fail gracefully with noexec and/or 
unsupported filesystem
Control: severity 895975 normal

On 2018-04-18, fin4478 fin4478 wrote:
> Running simple-cdd fails when started from a usb drive:
>
>
> xfce@unassigned:/media/xfce/7E31-3D8F/cd$ build-simple-cdd --dist sid 
> --local-packages /media/xfce/7E31-3D8F/cd/debs/ --profiles desktop
> Traceback (most recent call last):
>   File "/usr/bin/build-simple-cdd", line 658, in 
> scdd.build_mirror()
...
>   File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> PermissionError: [Errno 13] Permission denied: 
> '/media/xfce/7E31-3D8F/cd/tmp/log/mirror-reprepro'

Based on the mountpoint, I'm going to guess that the filesystem you're
running from was mounted without execute permissions
(e.g. "noexec"). There might additionally be issues with incompatible
filesystem types such as vfat; I haven't tested that either.

If you unmount the device from your file manager, and manually mount it:

  sudo mount /dev/disk/by-uuid/7E31-3D8F /mnt
  cd mnt
  simple-cdd ...

Does it work any better? You might also need to pass options to enable
write permissions for your user.


In any case, simple-cdd requires the ability to execute programs in it's
working directory, though it could certainly fail more gracefully in
this situation.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#896431: radvd: Periodic restart required to keep advertising

[Geert Stappers]

On Fri, Apr 20, 2018 at 10:17:43PM +0200, Witold Baryluk wrote:
> Source: radvd
> Version: 1:2.15-2
> 
> I have no idea why, but I need to do /etc/init.d/radvd restart every few hours
> to keep everything working on my network correctly.
> 
> I have static IPv6 prefix.
> 
> # cat /etc/radvd.conf 
 
seems valid
> 
> 
> -- System Information:
> Debian Release: buster/sid

For buster is allready version 1:2.17-1 available.
Also is 1:2.17-1 available for stretch-backports.

Please update to the newer version
and pretty please report back upon recurrent of the issue.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#895953: lintian: check that shlibs-version >= higher-version-symbols-file

[Chris Lamb]

tags 895953 - patch
thanks

Hi Emilio,

>   dh_makeshlibs -plibfoo1 -- -c4
> 
> That will generate a shlibs file with no version. That's a problem for the 
> same
> reason, but may need special treatment in the code

I've updated the description. However, your comment made me review
my own code and I've found a fairly large boo-boo in that I'm not
comparing the *shlibs* version but rather the "Version:" field of
the package itself.

Will get back to you when I've fixed that and untagging as "patch"
for the timebeing.

> Here you mean symbols control file.
[..]
> And here you mean shlibs control file.

Indeed! Both updated locally.. Well-caught, thank you.


Regards,

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

Bug#853682: tiledarray: diff for NMU version 0.6.0-5.1

[Adrian Bunk]

Control: tags 853682 + pending

Dear maintainer,

I've prepared an NMU for tiledarray (versioned as 0.6.0-5.1) and 
uploaded it to DELAYED/15. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru tiledarray-0.6.0/debian/changelog tiledarray-0.6.0/debian/changelog
--- tiledarray-0.6.0/debian/changelog	2017-01-14 00:38:40.0 +0200
+++ tiledarray-0.6.0/debian/changelog	2018-04-20 23:20:04.0 +0300
@@ -1,3 +1,11 @@
+tiledarray (0.6.0-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Juhani Numminen to fix FTBFS with gcc 7.
+(Closes: #853682)
+
+ -- Adrian Bunk   Fri, 20 Apr 2018 23:20:04 +0300
+
 tiledarray (0.6.0-5) unstable; urgency=medium
 
   * debian/rules (BUILD_TYPE): New variable, set to `MinSizeRel' on mips64el
diff -Nru tiledarray-0.6.0/debian/patches/series tiledarray-0.6.0/debian/patches/series
--- tiledarray-0.6.0/debian/patches/series	2016-12-28 11:17:51.0 +0200
+++ tiledarray-0.6.0/debian/patches/series	2018-04-20 23:11:11.0 +0300
@@ -0,0 +1 @@
+specialization-after-instantiation.patch
diff -Nru tiledarray-0.6.0/debian/patches/specialization-after-instantiation.patch tiledarray-0.6.0/debian/patches/specialization-after-instantiation.patch
--- tiledarray-0.6.0/debian/patches/specialization-after-instantiation.patch	1970-01-01 02:00:00.0 +0200
+++ tiledarray-0.6.0/debian/patches/specialization-after-instantiation.patch	2018-04-20 23:10:55.0 +0300
@@ -0,0 +1,40 @@
+Description: #include  before anything else to avoid error
+ This might actually a bug in boost or libstdc++. The message is:
+ In file included from /usr/include/c++/7/bits/unique_ptr.h:36:0,
+  from /usr/include/c++/7/memory:80,
+  from /usr/include/boost/config/no_tr1/memory.hpp:21,
+  from /usr/include/boost/smart_ptr/shared_ptr.hpp:23,
+  from /usr/include/boost/shared_ptr.hpp:17,
+  from /usr/include/boost/test/tools/assertion_result.hpp:21,
+  from /usr/include/boost/test/tools/old/impl.hpp:20,
+  from /usr/include/boost/test/test_tools.hpp:46,
+  from /usr/include/boost/test/unit_test.hpp:18,
+  from /build/tiledarray-0.6.0/obj-x86_64-linux-gnu/tests/unit_test_config.h:32,
+  from /build/tiledarray-0.6.0/tests/tiled_range1.cpp:21:
+ /usr/include/c++/7/utility:168:12: error: partial specialization of
+ 'struct std::__is_tuple_like_impl >' after instantiation of
+ 'struct std::__is_tuple_like_impl >'
+Author: Juhani Numminen 
+Bug-Debian: https://bugs.debian.org/853682
+Last-Update: 2017-12-19
+
+--- a/tests/tiled_range1.cpp
 b/tests/tiled_range1.cpp
+@@ -17,6 +17,7 @@
+  *
+  */
+ 
++#include 
+ #include "TiledArray/tiled_range1.h"
+ #include "unit_test_config.h"
+ #include "range_fixture.h"
+--- a/tests/tiled_range.cpp
 b/tests/tiled_range.cpp
+@@ -17,6 +17,7 @@
+  *
+  */
+ 
++#include 
+ #include "TiledArray/tiled_range.h"
+ #include "tiledarray.h"
+ #include "unit_test_config.h"

Bug#896432: Please configure with --enable-arm

[dann frazier]

Package: rasdaemon
Version: 0.6.0-1.1
Severity: normal
Tags: patch

In #879632 we attempted to enable arm events but, turns out, we also need
to configure this support on at build time because it is labeled
experimental. fyi, rasdaemon built fine on amd64 with this enabled, so
the following patch enables it globally.

--- rasdaemon-0.6.0/debian/rules.orig   2018-04-20 14:23:45.544493560 -0600
+++ rasdaemon-0.6.0/debian/rules2018-04-20 14:21:55.436367591 -0600
@@ -10,7 +10,7 @@
 override_dh_auto_configure:
dh_auto_configure -- \
--enable-mce --enable-aer --enable-sqlite3 --enable-extlog \
-   --enable-abrt-report
+   --enable-abrt-report --enable-arm
 
 override_dh_install:
dh_install


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

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

Versions of packages rasdaemon depends on:
ii  libc62.27-3
pn  libdbd-sqlite3-perl  
ii  libsqlite3-0 3.23.1-1
ii  perl 5.26.2-2
ii  sqlite3  3.23.1-1
ii  systemd  238-4

rasdaemon recommends no packages.

rasdaemon suggests no packages.

Bug#893039: libccnet0: contains a python module

[Moritz Schlarb]

Hello Helmut,

On 20.04.2018 20:06, Helmut Grohne wrote:
> I just looked into the package and only then noticed Christoph's upload.
> Let me share a few remarks though:
> 
>  * The new upstream release is a bit "strange". Even github uses the
>same commit id for both 6.1.5 and 6.1.7. That looks like a mistake to
>me.

It is a deliberate decision made by upstream to ensure that the three
components of the Seafile client "suite" always use the same version
number... Therefore they always re-tag ccnet, even if there are no
changes in the meantime. (Strangely, for searpc, they don't do that, but
use an even stranger tagging scheme, where there's currently only a Git
tag v3.1-latest, though the "internal" version is [correctly] set to
3.0.8...).
We decided to just follow along this decision by upstream since just
rebuilding the package with a new version is only minorly inconvenient
and we wanted to not divert too much from their recommendation. Although
I just now thought that if we think this trough, we should also have
strict same-version dependencies between the three components, which we
don't have right now.

>  * Did you consider porting to Python 3? It seems that for searpc, there
>is a patch to support Python 3 at
>https://github.com/haiwen/libsearpc/pull/21.

I noticed the Lintian warning and did not override it to keep it as a
marker to do that soon.

Best regards,
Moritz

Bug#896431: radvd: Periodic restart required to keep advertising

[Witold Baryluk]

Source: radvd
Version: 1:2.15-2
Severity: important

I have no idea why, but I need to do /etc/init.d/radvd restart every few hours
to keep everything working on my network correctly.

I have static IPv6 prefix.



# cat /etc/radvd.conf 
interface enp2s0 {
  AdvSendAdvert on;
  MaxRtrAdvInterval 30;
  AdvDefaultPreference high;
  AdvManagedFlag off;
  AdvOtherConfigFlag off;
  AdvLinkMTU 1472;

  prefix 2a02:xxx:::/64 {
AdvOnLink on;
AdvAutonomous on;
DeprecatePrefix on;
DecrementLifetimes on;
  };
};
#


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

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

Bug#896423: python-bcolz: bcolz fails to import

[Helmut Grohne]

Package: python-bcolz
Version: 1.2.0+ds1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-bcolz importing the module bcolz
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/bcolz/__init__.py", line 21, in 

from pkg_resources import parse_version
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896425: python3-django-cors-headers: corsheaders fails to import

[Helmut Grohne]

Package: python3-django-cors-headers
Version: 2.1.0+github-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-django-cors-headers importing the module corsheaders
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/corsheaders/__init__.py", line 1, in 

from .checks import check_settings  # noqa: F401
  File "/usr/lib/python3/dist-packages/corsheaders/checks.py", line 5, in 

from django.core import checks
ModuleNotFoundError: No module named 'django'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896417: python3-mplexporter: mplexporter fails to import

[Helmut Grohne]

Package: python3-mplexporter
Version: 0.0.1+20140921-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-mplexporter importing the module mplexporter
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/mplexporter/__init__.py", line 1, in 

from .renderers import Renderer
  File "/usr/lib/python3/dist-packages/mplexporter/renderers/__init__.py", line 
9, in 
from .base import Renderer
  File "/usr/lib/python3/dist-packages/mplexporter/renderers/base.py", line 5, 
in 
import numpy as np
ModuleNotFoundError: No module named 'numpy'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896430: python3: pip3 segfaults when cffi is installed with pip while python3-openssl is installed

[Val Lorentz]

Package: python3
Version: 3.5.3-1

Dear maintainers,

Excuse me if I did not file this bug against the right package; but it
involves three different packages.


I noticed a segfault in pip while installing some program with a huge
set of dependencies. I managed to narrow it down to the cffi package.


Here is how to reproduce the bug on a computer with Stretch installed (I
did not try other Debian versions):

debootstrap stretch chroot/
mount --bind /dev chroot/dev/ # for networking
chroot chroot/
apt install python3 python3-pip python3-openssl
adduser tmp
su tmp
pip3 install --user cffi
pip3 install --user cffi

This causes the *second* call to pip3 to segfault while it is shutting
down (I found other instances of that segfault while a program is
running, but it is harder to reproduce).
You may note that if python3-openssl is not installed, then there is no
segfault.

Here is the valgrind output corresponding to that segfault (this output
is sometimes a bit different):

==25001== Invalid read of size 1
==25001==at 0x25F194: visit_decref (gcmodule.c:373)
==25001==by 0x2E1464: dict_traverse.lto_priv.170 (dictobject.c:2570)
==25001==by 0x264012: subtract_refs (gcmodule.c:398)
==25001==by 0x264012: collect (gcmodule.c:951)
==25001==by 0x35A03C: collect_with_callback (gcmodule.c:1119)
==25001==by 0x35A0A0: PyGC_Collect (gcmodule.c:1583)
==25001==by 0x35D11B: Py_Finalize (pylifecycle.c:567)
==25001==by 0x35D217: Py_Exit (pylifecycle.c:1465)
==25001==by 0x35D2FD: handle_system_exit (pythonrun.c:602)
==25001==by 0x35D365: PyErr_PrintEx (pythonrun.c:612)
==25001==by 0x38BE79: RunModule (main.c:210)
==25001==by 0x38C71E: Py_Main (main.c:709)
==25001==by 0x21CC00: main (python.c:65)
==25001==  Address 0xa9 is not stack'd, malloc'd or (recently) free'd

I did some debugging with gdb, and the "op" object in visit_decref
(gcmodule.c:373) has an ob_type set to NULL.

Unfortunately, because of the compilation optimizations, I was unable to
get more information.

Best regards,
Val



signature.asc
Description: OpenPGP digital signature

Bug#896424: python3-terminado: terminado fails to import

[Helmut Grohne]

Package: python3-terminado
Version: 0.8.1-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-terminado importing the module terminado
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/terminado/__init__.py", line 7, in 

from .websocket import TermSocket
  File "/usr/lib/python3/dist-packages/terminado/websocket.py", line 18, in 

import tornado.web
ModuleNotFoundError: No module named 'tornado'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896422: python3-pymediainfo: pymediainfo fails to import

[Helmut Grohne]

Package: python3-pymediainfo
Version: 2.2.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-pymediainfo importing the module pymediainfo
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pymediainfo/__init__.py", line 6, in 

from pkg_resources import get_distribution
ModuleNotFoundError: No module named 'pkg_resources'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896427: python3-spyder-line-profiler: spyder_line_profiler fails to import

[Helmut Grohne]

Package: python3-spyder-line-profiler
Version: 0.1.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-spyder-line-profiler importing the module 
spyder_line_profiler
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/spyder_line_profiler/__init__.py", line 
12, in 
from .lineprofiler import LineProfiler
  File "/usr/lib/python3/dist-packages/spyder_line_profiler/lineprofiler.py", 
line 14, in 
from spyder.utils.qthelpers import qapplication
  File "/usr/lib/python3/dist-packages/spyder/utils/qthelpers.py", line 25, in 

from spyder.config.base import get_image_path, running_in_mac_app
  File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 221, in 

LANG_FILE = get_conf_path('langconfig')
  File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 126, in 
get_conf_path
xdg_config_home = osp.join(get_home_dir(), '.config')
  File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 116, in 
get_home_dir
raise RuntimeError('Please define environment variable $HOME')
RuntimeError: Please define environment variable $HOME

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896421: python3-lasagne: lasagne fails to import

[Helmut Grohne]

Package: python3-lasagne
Version: 0.1+git20180322.37ca134-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-lasagne importing the module lasagne
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/theano/configdefaults.py", line 1738, in 
filter_compiledir
os.makedirs(path, 0o770)  # read-write-execute for user and group
  File "/usr/lib/python3.6/os.py", line 210, in makedirs
makedirs(head, mode, exist_ok)
  File "/usr/lib/python3.6/os.py", line 210, in makedirs
makedirs(head, mode, exist_ok)
  File "/usr/lib/python3.6/os.py", line 220, in makedirs
mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: '/nonexistent'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/lasagne/__init__.py", line 12, in 

import theano
  File "/usr/lib/python3/dist-packages/theano/__init__.py", line 66, in 
from theano.compile import (
  File "/usr/lib/python3/dist-packages/theano/compile/__init__.py", line 10, in 

from theano.compile.function_module import *
  File "/usr/lib/python3/dist-packages/theano/compile/function_module.py", line 
21, in 
import theano.compile.mode
  File "/usr/lib/python3/dist-packages/theano/compile/mode.py", line 10, in 

import theano.gof.vm
  File "/usr/lib/python3/dist-packages/theano/gof/vm.py", line 662, in 
from . import lazylinker_c
  File "/usr/lib/python3/dist-packages/theano/gof/lazylinker_c.py", line 42, in 

location = os.path.join(config.compiledir, 'lazylinker_ext')
  File "/usr/lib/python3/dist-packages/theano/configparser.py", line 333, in 
__get__
self.__set__(cls, val_str)
  File "/usr/lib/python3/dist-packages/theano/configparser.py", line 344, in 
__set__
self.val = self.filter(val)
  File "/usr/lib/python3/dist-packages/theano/configdefaults.py", line 1745, in 
filter_compiledir
" '%s'. Check the permissions." % path)
ValueError: Unable to create the compiledir directory 
'/nonexistent/.theano/compiledir_Linux-4.14--amd64-x86_64-with-debian-buster-sid--3.6.5-64'.
 Check the permissions.

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896419: python-django-cors-headers: corsheaders fails to import

[Helmut Grohne]

Package: python-django-cors-headers
Version: 2.1.0+github-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-django-cors-headers importing the module corsheaders
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/corsheaders/__init__.py", line 1, in 

from .checks import check_settings  # noqa: F401
  File "/usr/lib/python2.7/dist-packages/corsheaders/checks.py", line 5, in 

from django.core import checks
ImportError: No module named django.core

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896420: python3-winrm: winrm fails to import

[Helmut Grohne]

Package: python3-winrm
Version: 0.3.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-winrm importing the module winrm
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/winrm/__init__.py", line 6, in 
from winrm.protocol import Protocol
  File "/usr/lib/python3/dist-packages/winrm/protocol.py", line 11, in 
from winrm.transport import Transport
  File "/usr/lib/python3/dist-packages/winrm/transport.py", line 18, in 
from distutils.util import strtobool
ModuleNotFoundError: No module named 'distutils.util'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896418: python-setuptools-scm: setuptools_scm fails to import

[Helmut Grohne]

Package: python-setuptools-scm
Version: 1.17.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-setuptools-scm importing the module setuptools_scm
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/setuptools_scm/__init__.py", line 10, 
in 
from .version import format_version, meta, ScmVersion
  File "/usr/lib/python2.7/dist-packages/setuptools_scm/version.py", line 7, in 

from pkg_resources import iter_entry_points
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896428: python3-pytest-runner: ptr fails to import

[Helmut Grohne]

Package: python3-pytest-runner
Version: 2.11.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-pytest-runner importing the module ptr
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/ptr.py", line 18, in 
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896429: python3-django-tables2: django_tables2 fails to import

[Helmut Grohne]

Package: python3-django-tables2
Version: 1.14.2-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-django-tables2 importing the module django_tables2
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/django_tables2/__init__.py", line 2, in 

from .tables import Table, TableBase
  File "/usr/lib/python3/dist-packages/django_tables2/tables.py", line 15, in 

from . import columns
  File "/usr/lib/python3/dist-packages/django_tables2/columns/__init__.py", 
line 8, in 
from .jsoncolumn import JSONColumn
  File "/usr/lib/python3/dist-packages/django_tables2/columns/jsoncolumn.py", 
line 15, in 
from django.contrib.postgres.fields import HStoreField, JSONField
  File 
"/usr/lib/python3/dist-packages/django/contrib/postgres/fields/__init__.py", 
line 1, in 
from .array import *  # NOQA
  File 
"/usr/lib/python3/dist-packages/django/contrib/postgres/fields/array.py", line 
3, in 
from django.contrib.postgres import lookups
  File "/usr/lib/python3/dist-packages/django/contrib/postgres/lookups.py", 
line 4, in 
from .search import SearchVector, SearchVectorExact, SearchVectorField
  File "/usr/lib/python3/dist-packages/django/contrib/postgres/search.py", line 
47, in 
class SearchVector(SearchVectorCombinable, Func):
  File "/usr/lib/python3/dist-packages/django/contrib/postgres/search.py", line 
50, in SearchVector
_output_field = SearchVectorField()
  File "/usr/lib/python3/dist-packages/django/db/models/fields/__init__.py", 
line 172, in __init__
self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 56, in 
__getattr__
self._setup(name)
  File "/usr/lib/python3/dist-packages/django/conf/__init__.py", line 39, in 
_setup
% (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting 
DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must either 
define the environment variable DJANGO_SETTINGS_MODULE or call 
settings.configure() before accessing settings.

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#869990: madness: diff for NMU version 0.10.1~gite4aa500e-10.1

[Adrian Bunk]

Control: tags 869990 + patch
Control: tags 869990 + pending

Dear maintainer,

I've prepared an NMU for madness (versioned as 0.10.1~gite4aa500e-10.1) 
and uploaded it to DELAYED/10. Please feel free to tell me if I should 
cancel it.

cu
Adrian

-- 

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

diff -Nru madness-0.10.1~gite4aa500e/debian/changelog madness-0.10.1~gite4aa500e/debian/changelog
--- madness-0.10.1~gite4aa500e/debian/changelog	2016-12-30 19:02:22.0 +0200
+++ madness-0.10.1~gite4aa500e/debian/changelog	2018-04-20 22:29:45.0 +0300
@@ -1,3 +1,10 @@
+madness (0.10.1~gite4aa500e-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with >= 3.9.0. (Closes: #869990)
+
+ -- Adrian Bunk   Fri, 20 Apr 2018 22:29:45 +0300
+
 madness (0.10.1~gite4aa500e-10) unstable; urgency=medium
 
   * debian/patches/disable_pie.patch: New patch, disables PIE, taken from
diff -Nru madness-0.10.1~gite4aa500e/debian/patches/cmake_else.patch madness-0.10.1~gite4aa500e/debian/patches/cmake_else.patch
--- madness-0.10.1~gite4aa500e/debian/patches/cmake_else.patch	1970-01-01 02:00:00.0 +0200
+++ madness-0.10.1~gite4aa500e/debian/patches/cmake_else.patch	2018-04-20 22:29:45.0 +0300
@@ -0,0 +1,14 @@
+Description: CMake >= 3.9.0 rejects duplicate else
+Author: Adrian Bunk 
+
+--- madness-0.10.1~gite4aa500e.orig/cmake/modules/FindMKL.cmake
 madness-0.10.1~gite4aa500e/cmake/modules/FindMKL.cmake
+@@ -38,7 +38,7 @@ if(NOT MKL_FOUND)
+   
+   if(FORTRAN_INTEGER_SIZE EQUAL 4)
+ set(MKL_INT_TYPE "lp64")
+-  else(FORTRAN_INTEGER_SIZE EQUAL 8)
++  elseif(FORTRAN_INTEGER_SIZE EQUAL 8)
+ set(MKL_INT_TYPE "ilp64")
+   else()
+ set(MKL_INT_TYPE "lp64")
diff -Nru madness-0.10.1~gite4aa500e/debian/patches/series madness-0.10.1~gite4aa500e/debian/patches/series
--- madness-0.10.1~gite4aa500e/debian/patches/series	2016-12-30 11:27:24.0 +0200
+++ madness-0.10.1~gite4aa500e/debian/patches/series	2018-04-20 22:29:26.0 +0300
@@ -3,3 +3,4 @@
 relax_tbb_version_check.patch
 cmake_mraplot_install.patch
 disable_pie.patch
+cmake_else.patch

Bug#896426: python-brian: brian fails to import

[Helmut Grohne]

Package: python-brian
Version: 1.4.3-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-brian importing the module brian
into a python interpreter fails with the following error:

/usr/lib/python2.7/dist-packages/brian/__init__.py:46: UserWarning: Couldn't 
import pylab.
  _warnings.warn("Couldn't import pylab.")
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/brian/__init__.py", line 51, in 

from connections import *
  File "/usr/lib/python2.7/dist-packages/brian/connections/__init__.py", line 
1, in 
from sparsematrix import *
  File "/usr/lib/python2.7/dist-packages/brian/connections/sparsematrix.py", 
line 1, in 
from base import *
  File "/usr/lib/python2.7/dist-packages/brian/connections/base.py", line 14, 
in 
from scipy import weave
ImportError: cannot import name weave

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896412: python-napalm-eos: napalm_eos fails to import

[Helmut Grohne]

Package: python-napalm-eos
Version: 0.6.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-napalm-eos importing the module napalm_eos
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/napalm_eos/__init__.py", line 16, in 

from napalm_eos.eos import EOSDriver
  File "/usr/lib/python2.7/dist-packages/napalm_eos/eos.py", line 39, in 

import napalm_base.helpers
  File "/usr/lib/python2.7/dist-packages/napalm_base/__init__.py", line 25, in 

import pkg_resources
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896415: python-fiat: FIAT fails to import

[Helmut Grohne]

Package: python-fiat
Version: 2017.2.0.0-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-fiat importing the module FIAT
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/FIAT/__init__.py", line 7, in 
import pkg_resources
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896414: python3-fswrap: fswrap fails to import

[Helmut Grohne]

Package: python3-fswrap
Version: 1.0.1-0.1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-fswrap importing the module fswrap
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/fswrap.py", line 14, in 
from distutils import dir_util
ImportError: cannot import name 'dir_util'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896416: python3-fiat: FIAT fails to import

[Helmut Grohne]

Package: python3-fiat
Version: 2017.2.0.0-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-fiat importing the module FIAT
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/FIAT/__init__.py", line 7, in 
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896411: python3-bcolz: bcolz fails to import

[Helmut Grohne]

Package: python3-bcolz
Version: 1.2.0+ds1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-bcolz importing the module bcolz
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/bcolz/__init__.py", line 21, in 
from pkg_resources import parse_version
ModuleNotFoundError: No module named 'pkg_resources'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896413: python-tf2-geometry-msgs: tf2_geometry_msgs fails to import

[Helmut Grohne]

Package: python-tf2-geometry-msgs
Version: 0.5.16-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-tf2-geometry-msgs importing the module tf2_geometry_msgs
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/tf2_geometry_msgs/__init__.py", line 
1, in 
from tf2_geometry_msgs import *
  File 
"/usr/lib/python2.7/dist-packages/tf2_geometry_msgs/tf2_geometry_msgs.py", line 
30, in 
from geometry_msgs.msg import PoseStamped, Vector3Stamped, PointStamped
ImportError: No module named geometry_msgs.msg

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896409: python-tf2-ros: tf2_ros fails to import

[Helmut Grohne]

Package: python-tf2-ros
Version: 0.5.16-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-tf2-ros importing the module tf2_ros
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/tf2_ros/__init__.py", line 39, in 

from buffer import *
  File "/usr/lib/python2.7/dist-packages/tf2_ros/buffer.py", line 34, in 

from tf2_msgs.srv import FrameGraph, FrameGraphResponse
ImportError: No module named tf2_msgs.srv

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896408: python3-spyder-memory-profiler: spyder_memory_profiler fails to import

[Helmut Grohne]

Package: python3-spyder-memory-profiler
Version: 0.1.2-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-spyder-memory-profiler importing the module 
spyder_memory_profiler
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/spyder_memory_profiler/__init__.py", 
line 12, in 
from .memoryprofiler import MemoryProfiler
  File 
"/usr/lib/python3/dist-packages/spyder_memory_profiler/memoryprofiler.py", line 
14, in 
from spyder.utils.qthelpers import qapplication
  File "/usr/lib/python3/dist-packages/spyder/utils/qthelpers.py", line 25, in 

from spyder.config.base import get_image_path, running_in_mac_app
  File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 221, in 

LANG_FILE = get_conf_path('langconfig')
  File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 126, in 
get_conf_path
xdg_config_home = osp.join(get_home_dir(), '.config')
  File "/usr/lib/python3/dist-packages/spyder/config/base.py", line 116, in 
get_home_dir
raise RuntimeError('Please define environment variable $HOME')
RuntimeError: Please define environment variable $HOME

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896407: python-stfio: stfio fails to import

[Helmut Grohne]

Package: python-stfio
Version: 0.15.5-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-stfio importing the module stfio
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/stfio/__init__.py", line 6, in 
from .stfio import *
  File "/usr/lib/python2.7/dist-packages/stfio/stfio.py", line 23, in 
_stfio = swig_import_helper()
  File "/usr/lib/python2.7/dist-packages/stfio/stfio.py", line 22, in 
swig_import_helper
return importlib.import_module('_stfio')
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
ImportError: No module named _stfio

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896410: python-flask-limiter: flask_limiter fails to import

[Helmut Grohne]

Package: python-flask-limiter
Version: 0.9.3-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-flask-limiter importing the module flask_limiter
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/flask_limiter/__init__.py", line 8, in 

from .errors import RateLimitExceeded
  File "/usr/lib/python2.7/dist-packages/flask_limiter/errors.py", line 6, in 

from pkg_resources import get_distribution
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896406: python-cv-bridge: cv_bridge fails to import

[Helmut Grohne]

Package: python-cv-bridge
Version: 1.12.3+ds-1+b2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-cv-bridge importing the module cv_bridge
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/cv_bridge/__init__.py", line 1, in 

from .core import CvBridge, CvBridgeError
  File "/usr/lib/python2.7/dist-packages/cv_bridge/core.py", line 34, in 

import sensor_msgs.msg
ImportError: No module named sensor_msgs.msg

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896405: python-stringtemplate3: stringtemplate3 fails to import

[Helmut Grohne]

Package: python-stringtemplate3
Version: 3.1-3
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-stringtemplate3 importing the module stringtemplate3
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/stringtemplate3/__init__.py", line 14, 
in 
from stringtemplate3.templates import *
  File "/usr/lib/python2.7/dist-packages/stringtemplate3/templates.py", line 
34, in 
import antlr
ImportError: No module named antlr

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896404: python3-django-casclient: cas fails to import

[Helmut Grohne]

Package: python3-django-casclient
Version: 1.2.0-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-django-casclient importing the module cas
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/cas/__init__.py", line 3, in 
from django.conf import settings
ModuleNotFoundError: No module named 'django'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896401: python3-seaborn: seaborn fails to import

[Helmut Grohne]

Package: python3-seaborn
Version: 0.8.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-seaborn importing the module seaborn
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/seaborn/__init__.py", line 6, in 
from .rcmod import *
  File "/usr/lib/python3/dist-packages/seaborn/rcmod.py", line 8, in 
from . import palettes, _orig_rc_params
  File "/usr/lib/python3/dist-packages/seaborn/palettes.py", line 12, in 

from .utils import desaturate, set_hls_values, get_color_cycle
  File "/usr/lib/python3/dist-packages/seaborn/utils.py", line 12, in 
import matplotlib.pyplot as plt
  File "/usr/lib/python3/dist-packages/matplotlib/pyplot.py", line 115, in 

_backend_mod, new_figure_manager, draw_if_interactive, _show = pylab_setup()
  File "/usr/lib/python3/dist-packages/matplotlib/backends/__init__.py", line 
62, in pylab_setup
[backend_name], 0)
  File "/usr/lib/python3/dist-packages/matplotlib/backends/backend_tkagg.py", 
line 4, in 
from . import tkagg  # Paint image to Tk photo blitter extension.
  File "/usr/lib/python3/dist-packages/matplotlib/backends/tkagg.py", line 5, 
in 
from six.moves import tkinter as Tk
  File "/usr/lib/python3/dist-packages/six.py", line 92, in __get__
result = self._resolve()
  File "/usr/lib/python3/dist-packages/six.py", line 115, in _resolve
return _import_module(self.mod)
  File "/usr/lib/python3/dist-packages/six.py", line 82, in _import_module
__import__(name)
ModuleNotFoundError: No module named 'tkinter'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896403: python-fake-factory: faker fails to import

[Helmut Grohne]

Package: python-fake-factory
Version: 0.7.7-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-fake-factory importing the module faker
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/faker/__init__.py", line 4, in 
from faker.factory import Factory
  File "/usr/lib/python2.7/dist-packages/faker/factory.py", line 10, in 
from faker.config import DEFAULT_LOCALE, PROVIDERS, AVAILABLE_LOCALES
  File "/usr/lib/python2.7/dist-packages/faker/config.py", line 13, in 
AVAILABLE_LOCALES = find_available_locales(PROVIDERS)
  File "/usr/lib/python2.7/dist-packages/faker/utils/loading.py", line 19, in 
find_available_locales
provider_module = import_module(provider_path)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/lib/python2.7/dist-packages/faker/providers/internet/__init__.py", 
line 5, in 
from ipaddress import ip_address, ip_network, IPV4LENGTH, IPV6LENGTH
ImportError: No module named ipaddress

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896402: python-easydev: easydev fails to import

[Helmut Grohne]

Package: python-easydev
Version: 0.9.35+dfsg-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-easydev importing the module easydev
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/easydev/__init__.py", line 23, in 

import pkg_resources
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896400: python-cephfs: ceph_volume_client fails to import

[Helmut Grohne]

Package: python-cephfs
Version: 10.2.5-7.2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-cephfs importing the module ceph_volume_client
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/ceph_volume_client.py", line 20, in 

from ceph_argparse import json_command
ImportError: No module named ceph_argparse

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896399: python-livereload: livereload fails to import

[Helmut Grohne]

Package: python-livereload
Version: 2.5.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-livereload importing the module livereload
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/livereload/__init__.py", line 15, in 

from .server import Server, shell
  File "/usr/lib/python2.7/dist-packages/livereload/server.py", line 26, in 

from .handlers import LiveReloadHandler, LiveReloadJSHandler
  File "/usr/lib/python2.7/dist-packages/livereload/handlers.py", line 15, in 

from pkg_resources import resource_string
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896398: python-camera-calibration-parsers: camera_calibration_parsers fails to import

[Helmut Grohne]

Package: python-camera-calibration-parsers
Version: 1.11.11-2+b6
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-camera-calibration-parsers importing the module 
camera_calibration_parsers
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/lib/python2.7/dist-packages/camera_calibration_parsers/__init__.py", line 
2, in 
from sensor_msgs.msg import CameraInfo
ImportError: No module named sensor_msgs.msg

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896397: python-casmoothing: ca_smoothing fails to import

[Helmut Grohne]

Package: python-casmoothing
Version: 0.2-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-casmoothing importing the module ca_smoothing
into a python interpreter fails with the following error:

Segmentation fault

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896396: python-django-tables2: django_tables2 fails to import

[Helmut Grohne]

Package: python-django-tables2
Version: 1.14.2-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-django-tables2 importing the module django_tables2
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/django_tables2/__init__.py", line 2, 
in 
from .tables import Table, TableBase
  File "/usr/lib/python2.7/dist-packages/django_tables2/tables.py", line 15, in 

from . import columns
  File "/usr/lib/python2.7/dist-packages/django_tables2/columns/__init__.py", 
line 8, in 
from .jsoncolumn import JSONColumn
  File "/usr/lib/python2.7/dist-packages/django_tables2/columns/jsoncolumn.py", 
line 15, in 
from django.contrib.postgres.fields import HStoreField, JSONField
  File 
"/usr/lib/python2.7/dist-packages/django/contrib/postgres/fields/__init__.py", 
line 1, in 
from .array import *  # NOQA
  File 
"/usr/lib/python2.7/dist-packages/django/contrib/postgres/fields/array.py", 
line 3, in 
from django.contrib.postgres import lookups
  File "/usr/lib/python2.7/dist-packages/django/contrib/postgres/lookups.py", 
line 4, in 
from .search import SearchVector, SearchVectorExact, SearchVectorField
  File "/usr/lib/python2.7/dist-packages/django/contrib/postgres/search.py", 
line 47, in 
class SearchVector(SearchVectorCombinable, Func):
  File "/usr/lib/python2.7/dist-packages/django/contrib/postgres/search.py", 
line 50, in SearchVector
_output_field = SearchVectorField()
  File "/usr/lib/python2.7/dist-packages/django/db/models/fields/__init__.py", 
line 172, in __init__
self.db_tablespace = db_tablespace or settings.DEFAULT_INDEX_TABLESPACE
  File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 56, in 
__getattr__
self._setup(name)
  File "/usr/lib/python2.7/dist-packages/django/conf/__init__.py", line 39, in 
_setup
% (desc, ENVIRONMENT_VARIABLE))
django.core.exceptions.ImproperlyConfigured: Requested setting 
DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must either 
define the environment variable DJANGO_SETTINGS_MODULE or call 
settings.configure() before accessing settings.

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896394: python-tf2-sensor-msgs: tf2_sensor_msgs fails to import

[Helmut Grohne]

Package: python-tf2-sensor-msgs
Version: 0.5.16-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-tf2-sensor-msgs importing the module tf2_sensor_msgs
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/tf2_sensor_msgs/__init__.py", line 1, 
in 
from tf2_sensor_msgs import *
  File "/usr/lib/python2.7/dist-packages/tf2_sensor_msgs/tf2_sensor_msgs.py", 
line 29, in 
from sensor_msgs.point_cloud2 import read_points, create_cloud
  File "/usr/lib/python2.7/dist-packages/sensor_msgs/point_cloud2.py", line 47, 
in 
import roslib.message
ImportError: No module named roslib.message

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896395: python3-sphinxcontrib.rubydomain: sphinxcontrib.rubydomain fails to import

[Helmut Grohne]

Package: python3-sphinxcontrib.rubydomain
Version: 0.1~dev-20100804-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-sphinxcontrib.rubydomain importing the module 
sphinxcontrib.rubydomain
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/sphinxcontrib/rubydomain.py", line 23, 
in 
from sphinx.util.compat import Directive
ImportError: cannot import name 'Directive'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896391: python-drmaa: drmaa fails to import

[Helmut Grohne]

Package: python-drmaa
Version: 0.5-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-drmaa importing the module drmaa
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/drmaa/__init__.py", line 41, in 

import drmaa.wrappers as _w
  File "/usr/lib/python2.7/dist-packages/drmaa/wrappers.py", line 43, in 

raise RuntimeError(errmsg)
RuntimeError: could not find drmaa library. Please specify its full path using 
the environment variable DRMAA_LIBRARY_PATH

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896390: python3-pip: pip fails to import

[Helmut Grohne]

Package: python3-pip
Version: 9.0.1-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-pip importing the module pip
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pip/__init__.py", line 26, in 
from pip.utils import get_installed_distributions, get_prog
  File "/usr/lib/python3/dist-packages/pip/utils/__init__.py", line 23, in 

from pip.locations import (
  File "/usr/lib/python3/dist-packages/pip/locations.py", line 9, in 
from distutils import sysconfig
ImportError: cannot import name 'sysconfig'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896392: python-goocalendar: goocalendar fails to import

[Helmut Grohne]

Package: python-goocalendar
Version: 0.3-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-goocalendar importing the module goocalendar
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/goocalendar/__init__.py", line 3, in 

import goocanvas
ImportError: No module named goocanvas

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896393: python-fastkml: fastkml fails to import

[Helmut Grohne]

Package: python-fastkml
Version: 0.11-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-fastkml importing the module fastkml
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/fastkml/__init__.py", line 28, in 

from pkg_resources import get_distribution, DistributionNotFound
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896298: python-cluster: cluster fails to import

[Helmut Grohne]

Package: python-cluster
Version: 1.3.3-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-cluster importing the module cluster
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/cluster/__init__.py", line 19, in 

from pkg_resources import resource_string
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896292: python3-easydev: easydev fails to import

[Helmut Grohne]

Package: python3-easydev
Version: 0.9.35+dfsg-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-easydev importing the module easydev
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/easydev/__init__.py", line 23, in 

import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896290: python-ipcalc: ipcalc fails to import

[Helmut Grohne]

Package: python-ipcalc
Version: 1.99.0-3
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-ipcalc importing the module ipcalc
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/ipcalc.py", line 42, in 
import six
ImportError: No module named six

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896327: python-sphinxcontrib.rubydomain: sphinxcontrib.rubydomain fails to import

[Helmut Grohne]

Package: python-sphinxcontrib.rubydomain
Version: 0.1~dev-20100804-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-sphinxcontrib.rubydomain importing the module 
sphinxcontrib.rubydomain
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/sphinxcontrib/rubydomain.py", line 23, 
in 
from sphinx.util.compat import Directive
ImportError: cannot import name Directive

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896323: python-enzyme: enzyme fails to import

[Helmut Grohne]

Package: python-enzyme
Version: 0.4.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-enzyme importing the module enzyme
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/enzyme/__init__.py", line 10, in 

from .mkv import *
  File "/usr/lib/python2.7/dist-packages/enzyme/mkv.py", line 3, in 
from .parsers import ebml
  File "/usr/lib/python2.7/dist-packages/enzyme/parsers/ebml/__init__.py", line 
2, in 
from .core import *
  File "/usr/lib/python2.7/dist-packages/enzyme/parsers/ebml/core.py", line 4, 
in 
from pkg_resources import resource_stream  # @UnresolvedImport
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896301: python-dcmstack: dcmstack fails to import

[Helmut Grohne]

Package: python-dcmstack
Version: 0.6.2+git33-gb43919a.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-dcmstack importing the module dcmstack
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/dcmstack/__init__.py", line 7, in 

from .dcmstack import *
  File "/usr/lib/python2.7/dist-packages/dcmstack/dcmstack.py", line 7, in 

import nibabel as nb
  File "/usr/lib/python2.7/dist-packages/nibabel/__init__.py", line 38, in 

from . import analyze as ana
  File "/usr/lib/python2.7/dist-packages/nibabel/analyze.py", line 87, in 

from .volumeutils import (native_code, swapped_code, make_dt_codes,
  File "/usr/lib/python2.7/dist-packages/nibabel/volumeutils.py", line 22, in 

from .casting import (shared_range, type_info, OK_FLOATS)
  File "/usr/lib/python2.7/dist-packages/nibabel/casting.py", line 11, in 

from .testing import setup_test  # flake8: noqa F401
  File "/usr/lib/python2.7/dist-packages/nibabel/testing/__init__.py", line 29, 
in 
from six.moves import zip_longest
ImportError: No module named six.moves

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896288: python-sphinx-paramlinks: sphinx_paramlinks fails to import

[Helmut Grohne]

Package: python-sphinx-paramlinks
Version: 0.3.4-1
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-sphinx-paramlinks importing the module sphinx_paramlinks
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/sphinx_paramlinks/__init__.py", line 
3, in 
from .sphinx_paramlinks import setup  # noqa
  File 
"/usr/lib/python2.7/dist-packages/sphinx_paramlinks/sphinx_paramlinks.py", line 
6, in 
from sphinx.util.osutil import copyfile
ImportError: No module named sphinx.util.osutil

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896304: python-rosnode: rosnode fails to import

[Helmut Grohne]

Package: python-rosnode
Version: 1.13.5+ds1-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-rosnode importing the module rosnode
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/rosnode/__init__.py", line 61, in 

import rostopic
ImportError: No module named rostopic

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896325: python3-stringtemplate3: stringtemplate3 fails to import

[Helmut Grohne]

Package: python3-stringtemplate3
Version: 3.1-3
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-stringtemplate3 importing the module stringtemplate3
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/stringtemplate3/__init__.py", line 14, 
in 
from stringtemplate3.templates import *
  File "/usr/lib/python3/dist-packages/stringtemplate3/templates.py", line 34, 
in 
import antlr
ModuleNotFoundError: No module named 'antlr'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896293: python3-woo: woo fails to import

[Helmut Grohne]

Package: python3-woo
Version: 1.0+dfsg1-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python3-woo importing the module woo
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/woo/__init__.py", line 64, in 
import distutils.sysconfig
ModuleNotFoundError: No module named 'distutils.sysconfig'

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut

Bug#896318: python-instant: instant fails to import

[Helmut Grohne]

Package: python-instant
Version: 2017.2.0.0-2
Severity: serious
User: helm...@debian.org
Usertags: python-import

After installing python-instant importing the module instant
into a python interpreter fails with the following error:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python2.7/dist-packages/instant/__init__.py", line 19, in 

import pkg_resources
ImportError: No module named pkg_resources

The vast majority of import failures is attributed to missing dependencies.
Often times that manifests as an ImportError or ModuleNotFoundError.
Typically, dependencies should be inserted by dh-python via ${python:Depends}
or ${python3:Depends}. Thus a missing dependency can be caused by incomplete
install_requires in setup.py. Sometimes a missing dependency of a dependency
is the cause, in such cases this bug should be reassigned.

Helmut