Package: linux-libc-dev,libc6-dev
Severity: serious
Justification: makes systemd ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:systemd libmount-dev
systemd FTBFS here, because compiling load-fragment.c fails. I spent a while
minimizing that file and it boils down
:04:03.0 +0100
+++ pasco-20040505/debian/changelog 2018-05-19 13:33:09.0 +0200
@@ -1,3 +1,10 @@
+pasco (20040505-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix the upstream Makefile. (Closes: #-1)
+
+ -- Helmut Grohne <hel...@subdivi.de> Sat, 19 May 2
Source: bolt
Version: 0.3-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
bolt fails to build from source on unstable:
| dpkg-buildpackage: info: source package bolt
| dpkg-buildpackage: info: source version 0.3-3
| dpkg-buildpackage: info: source distribution
Source: libtasn1-6
Version: 4.13-2
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
libtasn1-6 fails to build from source in unstable (full build).
| Making check in reference
| make check-TESTS
| make[5]: Entering directory '/<>/doc/reference'
| echo "#!/bin/sh -e"
On Mon, Jun 18, 2018 at 06:10:04PM +0200, Roland Fehrenbacher wrote:
> >>>>> "HG" == Helmut Grohne writes:
> HG> You moved the programs and the corresponding manual pages, but
> HG> the development manual pages still live in libfabric1 and are
>
Source: gnushogi
Version: 1.4.2-3
Severity: serious
Justification: policy 4.6
Tags: upstream
If you run
grep '^\s*-' Makefile.in
you'll find a number of crucial make rules that ignore errors. In
particular the main build and install targets are among them. Thus
gnushogi continues building
Control: reopen -1
On Thu, May 31, 2018 at 09:03:09AM +, Debian Bug Tracking System wrote:
>* Add package libfabric-bin (Closes: #891395)
You moved the programs and the corresponding manual pages, but the
development manual pages still live in libfabric1 and are still
problematic for the
Hi Adrian,
On Sun, Jun 17, 2018 at 02:52:40PM +0300, Adrian Bunk wrote:
> do you plan to upload anything here?
No. At least not soon.
> I am a bit confused about a maintainer-upload versioned change saying
> "Non-maintainer upload." plus nothing uploaded to the archive so far.
That's an
Control: tags -1 - moreinfo
On Sat, May 26, 2018 at 05:27:20PM +0300, Adrian Bunk wrote:
> Where is the attachment?
Here you go.
Helmut
From: Helmut Grohne <hel...@subdivi.de>
Subject: make sh/autoconfall.sh work somewhat
Index: ncftp-3.2.5/sh/autoc
Source: nss
Version: 2:3.37-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
nss fails to build from source on at least armel, armhf, mips and
mipsel. It fails linking libfreeblpriv3.so with lots of undefined
references. For build logs see e.g.
Source: rifiuti
Version: 20040505-1
Severity: serious
Justification: policy 4.6
The install target in src/Makefile chains commands with ";" and thus
does not abort on an error. This violates Debian policy section 4.6.
Helmut
On Sat, Jun 02, 2018 at 11:58:21AM +0300, Juhani Numminen wrote:
> On Fri, 1 Jun 2018 21:12:06 +0200 Sébastien Villemot
> wrote:
> > Package: src:rkward
> > Severity: serious
> For a build log of the failure, see the link "rbuild (41KB)" at [1].
>
> It seems that the cmake invocation is
Source: predict
Version: 2.2.3-4
Severity: serious
Justification: Debian policy section 4.6
predict's debian/rules chains commands with ";" in a lot of places. This
covers simply "cd something; execute something else", but also longer
chains involving autoconf or the like. Such practise is
Source: glibc
Version: 2.27-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
glibc fails to cross build from source. An arch-only build log (using
DEB_BUILD_OPTIONS=nocheck to speed things
Source: libatomic-ops
Version: 7.6.4-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
libatomic-ops fails to build from source on amd64. The build ends with:
| dh_installdirs
Source: gfsview
Version: 20121130+dfsg-5
Severity: serious
Justification: missing source
While trying to fix gfsview, I noticed that the source of gfsview is
incomplete. debian/Makefile.in is quite obviously generated from
debian/Makefile.am, but debian/Makefile.am is missing. I'm not sure what
Source: libseccomp
Version: 2.3.3-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
libseccomp fails to build from source on amd64. The build ends with:
|dh_install
|dh_installdocs
On Thu, Oct 19, 2017 at 10:52:41PM +0200, Markus Koschany wrote:
> I am quoting:
>
> https://sources.debian.net/src/glee/5.4.0-2/configure/
>
> The license is very liberal. You can argue that it should be mentioned
> in debian/copyright but that does not make the file non-free or
> unsuitable
On Tue, Jul 03, 2018 at 12:29:00PM +0200, Alberto Gonzalez Iniesta wrote:
> Have you tested your assertion? Because if ./configure fails, MCONFIG is
> not created and the build (make) fails:
That was a general statement. I think it doesn't really matter whether
it practically does cause
Control: reopen -1
Control: affects 882785 + src:geeqie
On Wed, Jan 03, 2018 at 11:21:06PM +, Debian Bug Tracking System wrote:
>* New upstream version 1.4
> - Really fixes the problems with trapping errors (Closes: 883526)
I'm very sorry to reopen this bug again, but this fix
Package: debhelper
Version: 11.1
Severity: serious
Control: affects -1 + src:file
User: helm...@debian.org
Usertags: rebootstrap
Building file started to fail tonight. The new error comes from
debhelper and debhelper was the thing that was uploaded. Very likely,
debhelper is the culprit, but it
Source: texstudio
Version: 2.12.6+debian-1
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
texstudio fails to build from source, because it does not find quazip.
Tail of a build log:
| g++ -c -pipe -std=c++0x -g -O2
-fdebug-prefix-map=/<>/texstudio-2.12.6+debian=.
Source: systemd
Version: 236-3
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
systemd fails to build from source on mipsel. Very likely this is not
caused by this particular systemd upload, but by the binutils upload
instead. In any case, the build log (attached) ends with:
|
Control: clone -1 -2
Control: reopen -2
Control: reassign -2 src:squid3
On Tue, Nov 21, 2017 at 10:03:22AM +, Debian Bug Tracking System wrote:
> #853668: squid3: ftbfs with GCC-7
This bug report is very confusing now. src:squid3 FTBFS. The bug is
fixed in src:squid/experimental though.
Package: libqt5core5a
Version: 5.9.2+dfsg-8
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
libqt5core5a fails to install:
# apt-get install libqt5core5a
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional
:50.0
+0100
@@ -1,3 +1,10 @@
+bsdmainutils (11.1.1+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS: Add libncurses5-dev to Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne <hel...@subdivi.de> Thu, 28 Dec 2017 18:17:50 +0100
+
bsdmainutils (11.1.1) un
Control: reopen -1
On Mon, Dec 25, 2017 at 08:12:15PM +, Andreas Rönnquist wrote:
> Add patch trap_errors_from_make.patch (Closes: #883526)
Thank you for attempting to fix this. Unfortunately, this doesn't quite
do it. My initial suggestion to add set -e apparently doesn't do it.
Package: libfabric1
Version: 1.5.3-1
Severity: serious
Justification: policy 8.2
libfabric1 ships /usr/bin/fi_{info,pingpong,strerror}. These files are
independent of the soname of the library. Debian policy section 8.2
prohibits such files from being shipped in the shared library package.
The
Source: network-manager-strongswan
Version: 1.4.4-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
network-manager-strongswan fails to build from source. A build on amd64
ends with:
| libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time
-D_FORTIFY_SOURCE=2
Source: libtextwrap
Version: 0.1-14.1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
libtextwrap fails to build from source on amd64 in unstable. A build log
ends with:
| touch configure-stamp
| dh_testdir
| /usr/bin/make
| make[1]: Entering directory '/<>'
|
On Sun, Aug 05, 2018 at 07:31:55AM +0200, Helmut Grohne wrote:
> libtextwrap fails to build from source on amd64 in unstable. A build log
> ends with:
>
> | touch configure-stamp
> | dh_testdir
> | /usr/bin/make
> | make[1]: Entering directory '/<>'
> | /usr/bin/make
Control: tags -1 + patch
On Sun, Aug 05, 2018 at 08:55:32AM +0200, Helmut Grohne wrote:
> Scanning the recent upload history, automake-1.16 looks suspicious now.
Yes, it looks like a missing Makefile.am dependency. The attached patch
makes it build.
Helmut
--- libtextwrap-0.1.orig/Makefile
-2.7.6/debian/changelog2018-08-05 11:53:06.0 +0200
@@ -1,3 +1,10 @@
+patch (2.7.6-2.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS: dh_autoreconf (Closes: #-1)
+
+ -- Helmut Grohne Sun, 05 Aug 2018 11:53:06 +0200
+
patch (2.7.6-2) unstable; urgency=high
Source: gcc-7
Version: 7.3.0-27
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Hi Matthias,
I'm not sure whether you're aware already, but I felt that it was best
to just document that gcc-7 fails to build against isl 0.20. I tried to
check the vcs on whether this
Source: psi-plus
Version: 1.3.384-1
Severity: serious
Tags: ftbfs
psi-plus fails to build from source in unstable on amd64. A build ends
with:
| /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -Wdate-time
On Wed, Aug 08, 2018 at 12:35:36PM +0300, Boris Pek wrote:
> Package src:qtkeychain is not FTBFS, so this tag is wrong. I am not sure
> which severity is better, but severity "serious" looks wrong to me.
The ftbfs tag was correct. The bug wasn't assigned to src:qtkeychain
(source package), but to
Source: moria
Version: 5.6.debian.1-2
Severity: serious
Justification: debian policy 4.6
The Debian policy requires that a build aborts on errors rather than
continuing. The moria package is interesting in this regard:
( cd build ; $(MAKE) )
It tries to cd to build and then runs make
Source: ckermit
Version: 302-5.3
Severity: serious
Justification: policy section 4.6
Tags: upstream
ckermit does not trap errors from make. Failing to do so is prohibited
by the Debian policy section 4.6, because it can cause silent misbuilds
and makes debugging failures unnecessarily hard.
The
e-3.11.0/debian/changelog
--- logrotate-3.11.0/debian/changelog 2017-01-07 19:54:50.0 +0100
+++ logrotate-3.11.0/debian/changelog 2018-08-06 20:54:00.0 +0200
@@ -1,3 +1,10 @@
+logrotate (3.11.0-0.2) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix FTBFS: autore
Source: libtasn1-6
Version: 4.13-3
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Doing an arch-only build of libtasn1-6 on amd64 fails. A build log ends
with:
| make[3]: Entering directory '/<>/doc'
| restore=: && backupdir=".am$$" && \
| am__cwd=`pwd` &&
Source: libgd2
Version: 2.2.5-4
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
libgd2 fails to build from source on amd64 in unstable. A build ends
with:
|dh_auto_build
| make -j1
| make[1]: Entering directory '/<>'
| Making all in src
| make[2]:
Control: retitle -1 unnecessary dependency on python3:any
Control: severity -1 wishlist
On Fri, Aug 24, 2018 at 05:35:09PM +0200, Helmut Grohne wrote:
> # apt-get install gir1.2-ibus-1.0:i386 python3-gi
Laurent explained to me that this is not how things are supposed to
work. For us
Package: gir1.2-ibus-1.0
Version: 1.5.18-1
Severity: serious
In a fresh sid amd64 chroot, I did:
# dpkg --add-architecture i386
# apt-get update
# apt-get install gir1.2-ibus-1.0:i386 python3-gi
I then tried to use ibus:
$ python3
Python 3.6.6+ (default, Aug 20 2018, 16:21:04)
[GCC 8.2.0] on
Source: sketch
Version: 1:0.3.7-6
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
sketch fails to build from source in unstable on amd64 when performing
an arch-only build. A log ends with:
| dh binary-arch
|dh_testroot -a
|dh_prep -a
|dh_auto_install -a
Source: stockfish
Version: 9-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
stockfish fails to build from source on armel, mips, mipsel, m68k,
powerpc, powerpcspe and sh4. A build log from mips ends with:
| g++ -o stockfish benchmark.o bitbase.o bitboard.o
Source: meson
Version: 0.47.1-1
Severity: serious
Tags: ftbfs
User: helm...@debian.org
Usertags: rebootstrap
While trying to sponsor 0.47.1-2 I noticed that the current and
prospective version fail to build from source. The build ends with:
| The Meson build system
| Version: 0.47.1
| Source
Control: tags -1 - moreinfo
On Wed, Jul 04, 2018 at 10:37:32PM +0200, Michael Biebl wrote:
> sound like an sbuild bug. Using pbuilder I have no problems building the
> gnupg2 package.
I kinda agree with you here. I actually ran into this bug a while
earlier:
Unlike systemd-sysv, systemd-shim
Source: slt
Version: 0.0.git20140301-4
Severity: serious
Since ronn got split out of ruby-ronn, slt fails to build from source.
It was not possible to have ruby-ronn temporarily depend on ronn,
because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Source: git-lfs
Version: 2.4.2-1
Severity: serious
Since ronn got split out of ruby-ronn, git-lfs fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Source: duc
Version: 1.4.3-3
Severity: serious
Since ronn got split out of ruby-ronn, duc fails to build from source.
It was not possible to have ruby-ronn temporarily depend on ronn,
because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn with ronn
Package: curvedns
Version: 0.87-4
Severity: serious
Since ronn got split out of ruby-ronn, curvedns fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Source: espeak-ng
Version: 1.49.2+dfsg-2
Severity: serious
Since ronn got split out of ruby-ronn, espeak-ng fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
Source: foremancli
Version: 1.0-2
Severity: serious
Since ronn got split out of ruby-ronn, foremancli fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Source: decopy
Version: 0.2.3-2
Severity: serious
Since ronn got split out of ruby-ronn, decopy fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn with
Package: dbab
Version: 1.3.2-1
Severity: serious
Since ronn got split out of ruby-ronn, dbab fails to build from source.
It was not possible to have ruby-ronn temporarily depend on ronn,
because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn with
Source: shapelib
Version: 1.4.1-1
Severity: serious
Since ronn got split out of ruby-ronn, shapelib fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Source: git-extras
Version: 4.5.0-1
Severity: serious
Since ronn got split out of ruby-ronn, git-extras fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
Source: unburden-home-dir
Version: 0.4.1
Severity: serious
Since ronn got split out of ruby-ronn, unburden-home-dir fails to build
from source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and
Source: brutespray
Version: 1.6.0-1
Severity: serious
Since ronn got split out of ruby-ronn, brutespray fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
Source: haproxyctl
Version: 1.3.0-2
Severity: serious
Since ronn got split out of ruby-ronn, haproxyctl fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
Source: ledger-wallets-udev
Version: 0.1
Severity: serious
Since ronn got split out of ruby-ronn, ledger-wallets-udev fails to
build from source. It was not possible to have ruby-ronn temporarily
depend on ronn, because that would have created a dependency cycle.
Please update Build-Depends and
Source: r10k
Version: 2.6.2-2
Severity: serious
Since ronn got split out of ruby-ronn, r10k fails to build from source.
It was not possible to have ruby-ronn temporarily depend on ronn,
because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn with ronn
Source: qiime
Version: 1.9.1+dfsg-2
Severity: serious
Since ronn got split out of ruby-ronn, qiime fails to build from source.
It was not possible to have ruby-ronn temporarily depend on ronn,
because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Source: seqprep
Version: 1.3.2-2
Severity: serious
Since ronn got split out of ruby-ronn, seqprep fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace ruby-ronn
Package: coquelicot
Version: 0.9.6-1
Severity: serious
Since ronn got split out of ruby-ronn, coquelicot fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
Source: ruby-coveralls
Version: 0.8.21-1
Severity: serious
Since ronn got split out of ruby-ronn, ruby-coveralls fails to build
from source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and
Source: python-base58
Version: 1.0.0-1
Severity: serious
Since ronn got split out of ruby-ronn, python-base58 fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
Source: foodcritic
Version: 13.1.1-1
Severity: serious
Since ronn got split out of ruby-ronn, foodcritic fails to build from
source. It was not possible to have ruby-ronn temporarily depend on
ronn, because that would have created a dependency cycle. Please update
Build-Depends and replace
On Sun, Jul 08, 2018 at 01:24:06PM +, Santiago Vila wrote:
> [...]
> debian/rules build-indep
> dh build-indep
>dh_update_autotools_config -i
>dh_autoreconf -i
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/<>'
> dh_auto_build
> HOME=$(mktemp -d)
Source: bundler
Version: 1.16.1-2
Severity: serious
Tags: ftbfs
bundler fails to build from source since ronn got split out from
ruby-ronn into a separate package ronn. Fixing this problem will involve
adding ronn to Build-Depends as the build system tries to invoke ronn
with "ruby2.5 -S ronn".
Package: libpam-systemd
Version: 239-4
Severity: critical
Justification: makes gnupg2 ftbfs
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:gnupg2
A native(!) build of gnupg2 with sbuild and
--bd-uninstallable-explainer=apt fails. dose3 finds an installation set,
but it
Package: dash
Version: 0.5.8-2.7
Severity: serious
debootstrap sid now fails:
| I: Installing core packages...
| W: Failure trying to run: chroot $TARGET dpkg --force-depends --install
/var/cache/apt/archives/base-passwd_3.5.44_amd64.deb
| W: See $TARGET/b/debootstrap/debootstrap.log for
Package: netdiag
Version: 1.1-2
Severity: serious
Justification: policy 4.6
User: helm...@debian.org
Usertags: rebootstrap
debian/rules ignores errors from automake. That violates the Debian
policy section 4.6. Incidentally that command fails on the buildds:
Source: libxcb
Version: 1.12-1
Severity: serious
Justification: FTBFS
User: helm...@debian.org
Usertags: rebootstrap
Since a few days(?), libxcb FTBFS. The build ends with:
| make[1]: Entering directory '/<>/build'
| Making all in src
| make[2]: Entering directory '/<>/build/src'
|
Package: libccnet0
Version: 6.1.5-1
Severity: serious
Justification: policy 8.2
libccnet0 contains a python module "ccnet". The Debian policy section
8.2 prohibits shipping soname-independent files with the shared library
package:
| If your package contains files whose names do not change with
Package: libseafile0
Version: 6.1.5-1
Severity: serious
Justification: policy 8.2
libseafile0 contains a python module "ccnet". The Debian policy section
8.2 prohibits shipping soname-independent files with the shared library
package:
| If your package contains files whose names do not change
Source: apcupsd
Version: 3.14.14-1
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
apcupsd fails to build from source in unstable. Its Build-Depends are no
longer satisfiable, because python-imaging was removed from
pillow/5.0.0-1.
Helmut
Source: glib2.0
Version: 2.56.0-6
Severity: serious
User: helm...@debian.org
Usertags: rebootstrap
glib2.0 FTBFS during dh_auto_clean. Including the full build log:
| dpkg-buildpackage: info: source package glib2.0
| dpkg-buildpackage: info: source version 2.56.0-6
| dpkg-buildpackage: info:
Source: galleta
Version: 1.0+20040505-8
Severity: serious
Justification: policy 4.6
Tags: upstream
User: helm...@debian.org
Usertags: rebootstrap
galleta's upstream build system does not trap errors from gcc as it
chains multiple commands with ";". Doing so is required by policy
section 4.6 to
On Tue, Apr 17, 2018 at 12:04:07PM +0200, Moritz Schlarb wrote:
> I addressed this issue in 6.1.5-2, but since this leads to a new binary
> upload, I can't upload it myself since I'm just a DM.
> My mentor/sponsor Christoph is currently out of the office, so he can't
> do it either.
> So I've
Package: python-linop
Version: 0.8.2-3
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-linop importing the module linop
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
File
Package: python-django-celery-transactions
Version: 0.3.6-2
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-django-celery-transactions importing the module
djcelery_transactions
into a python interpreter fails with the following error:
Traceback (most
Package: python-terminado
Version: 0.8.1-2
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-terminado importing the module terminado
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
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
Package: python-pgspecial
Version: 1.9.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-pgspecial importing the module pgspecial
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
Package: python3-setools
Version: 4.1.1-3
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-setools importing the module setools
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
File
Package: python3-django-haystack
Version: 2.8.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-django-haystack importing the module haystack
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line
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
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
Package: python3-django-netfields
Version: 0.8-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-django-netfields importing the module netfields
into a python interpreter fails with the following error:
Traceback (most recent call last):
File
Package: python-rosservice
Version: 1.13.5+ds1-2
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-rosservice importing the module rosservice
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1,
Package: python-tf
Version: 1.11.9-1+b1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-tf importing the module tf
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
File
Package: python-laditools
Version: 1.1.0-2
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-laditools importing the module laditools
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
Package: python3-segyio
Version: 1.5.2-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-segyio importing the module segyio
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
File
Package: python-mplexporter
Version: 0.0.1+20140921-2
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-mplexporter importing the module mplexporter
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "",
Package: python-resource-retriever
Version: 1.12.3-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-resource-retriever importing the module
resource_retriever
into a python interpreter fails with the following error:
Traceback (most recent call last):
Package: python3-django-ipware
Version: 2.0.1-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-django-ipware importing the module ipware
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
Package: python3-yapf
Version: 0.21.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-yapf importing the module yapf
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
File
Package: python3-preludedb
Version: 4.1.0-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python3-preludedb importing the module preludedb
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
Package: python-msrestazure
Version: 0.4.13-1
Severity: serious
User: helm...@debian.org
Usertags: python-import
After installing python-msrestazure importing the module msrestazure
into a python interpreter fails with the following error:
Traceback (most recent call last):
File "", line 1, in
401 - 500 of 1514 matches
Mail list logo
