Bug#926935: arpack: FTBFS (does not honor parallel=n in DEB_BUILD_OPTIONS)

[Ghislain Vaillant]

Le mer. 24 avr. 2019 à 17:02, Santiago Vila  a écrit :

> On Wed, Apr 24, 2019 at 04:47:16PM +0200, Sylvestre Ledru wrote:
> > Le 24/04/2019 à 16:45, Santiago Vila a écrit :
> > > On Wed, Apr 24, 2019 at 04:24:59PM +0200, ghisv...@gmail.com wrote:
> > > > Anyone objecting on applying Santiago's patch to src:arpack to fix
> the
> > > > occasionnal FTBFS on single-core builders?
> > > >
> > > > If not, then I am happy to prepare a release.
> > >
> > > Thanks a lot.
> > >
> > > One minor clarification: The failure happens always on single-cpu
> systems,
> > > not just occassionally.
> > >
> > Don't hesitate to forward that upstream if you find a fix
> > https://github.com/opencollab/arpack-ng
>
> A general fix (i.e. one that upstream accept) would probably involve
> using "nproc" command inside the Makefiles, but then we would have to
> override that anyway to avoid using so many simultaneous jobs if the
> user explicitly ask for less jobs via DEB_BUILD_OPTIONS.
>
> The safe/conservative thing to do would be to use 1 job for the test suite.
>
> I can put an issue in github if you confirm there is not one yet.
>
> Thanks.
>

I did not find one, but glanced very quickly through the issue tracker.

>

Bug#921460: dead upstream - keep out of testing

[Ghislain Vaillant]

Le mar. 5 févr. 2019 à 20:21, Rebecca N. Palmer  a
écrit :

> Package: clsparse
> Severity: serious
> X-Debbugs-Cc: debian-scie...@lists.debian.org, ghisv...@gmail.com
> (plus an identical one for freefem3d)
>
> This package is dead upstream, and it has been suggested [0] that
> because of this, it should not be fixed for buster.
>
> I don't know enough about it to have an opinion on this: I am opening
> this bug as a "don't waste your time fixing it" notice.
>
> If this remains the consensus, please consider removing it from unstable
> as well.
>
> [0] https://lists.debian.org/debian-science/2019/02/msg00015.html


Agreed. It should be removed.

Ghislain

>
>

Bug#902592: New version does not build

[Ghislain Vaillant]

I am away right now and can't investigate before two weeks.

Looks Cython related from a first look.

Ghis

Le ven. 29 juin 2018 à 11:17, Andreas Tille  a écrit :

> Hi Ghislain,
>
> since one of the Debian Med packages seems to be affected I tried to
> upgrade h5py (see Git repository).  Unfortunately it does not build:
>
> ...
> running build_ext
> Traceback (most recent call last):
>   File "setup.py", line 168, in 
> cmdclass = CMDCLASS,
>   File "/usr/lib/python2.7/dist-packages/setuptools/__init__.py", line
> 129, in setup
> return distutils.core.setup(**attrs)
>   File "/usr/lib/python2.7/distutils/core.py", line 151, in setup
> dist.run_commands()
>   File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands
> self.run_command(cmd)
>   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
>   File "/usr/lib/python2.7/distutils/command/build.py", line 128, in run
> self.run_command(cmd_name)
>   File "/usr/lib/python2.7/distutils/cmd.py", line 326, in run_command
> self.distribution.run_command(command)
>   File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command
> cmd_obj.run()
>   File "/build/h5py-2.8.0/setup_build.py", line 156, in run
> from Cython.Build import cythonize
>   File "/usr/lib/python2.7/dist-packages/Cython/Build/__init__.py", line
> 1, in 
> from .Dependencies import cythonize
>   File "/usr/lib/python2.7/dist-packages/Cython/Build/Dependencies.py",
> line 36, in 
> from ..Compiler.Main import Context, CompilationOptions,
> default_options
>   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Main.py", line
> 30, in 
> from .Symtab import ModuleScope
>   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/Symtab.py", line
> 19, in 
> from . import PyrexTypes
>   File "/usr/lib/python2.7/dist-packages/Cython/Compiler/PyrexTypes.py",
> line 17, in 
> from .Code import UtilityCode, LazyUtilityCode, TempitaUtilityCode
>   File "Cython/Compiler/Code.py", line 38, in init Cython.Compiler.Code
> ImportError: /usr/lib/python2.7/dist-packages/Cython/
> StringIOTree.x86_64-linux-gnu.so: undefined symbol: Py_InitModule4_64
> E: pybuild pybuild:336: build: plugin distutils failed with: exit code=1:
> /usr/bin/python-dbg setup.py build
> dh_auto_build: pybuild --build -i python{version}-dbg -p 2.7 returned exit
> code 13
> make[1]: *** [debian/rules:22: override_dh_auto_build] Error 25
> make[1]: Leaving directory '/build/h5py-2.8.0'
> make: *** [debian/rules:10: build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
>
> Can you please have a look?
>
> Kind regards
>
> Andreas.
>
> --
> http://fam-tille.de
>

Bug#893729: sympy FTBFS: python3-distutils is now a separate package

[Ghislain Vaillant]

Another option could be to patch the build system to use setuptools instead
of distutils as recommended by the PyPA?

Le mer. 21 mars 2018 à 20:45, Rebecca N. Palmer  a
écrit :

> Source: sympy
> Severity: serious
> Control: tags -1 patch
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> python3-distutils has been moved out of python3.6 (as of 3.6.5~rc1-2),
> so if you need it, please build-depend on it.  (Or python3-setuptools,
> given that this looks like it might prefer that.)
>
> (Has anyone checked whether there are more of these?)
>
> dpkg-buildpackage: info: source package sympy
> dpkg-buildpackage: info: source version 1.1.1-4
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Yaroslav Halchenko
> 
> dpkg-buildpackage: info: host architecture amd64
>   dpkg-source --before-build sympy-1.1.1
>   fakeroot debian/rules clean
> dh  clean --with python2,python3 --buildsystem=pybuild
> debian/rules override_dh_auto_clean
> make[1]: Entering directory
> '/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
> dh_auto_clean
> I: pybuild base:217: python2.7 setup.py clean
> /usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
> distribution option: 'install_requires'
>warnings.warn(msg)
> running clean
> I: pybuild base:217: python3.6 setup.py clean
> Traceback (most recent call last):
>File "setup.py", line 46, in 
>  from setuptools import setup, Command
> ModuleNotFoundError: No module named 'setuptools'
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>File "setup.py", line 49, in 
>  from distutils.core import setup, Command
> ModuleNotFoundError: No module named 'distutils'
> E: pybuild pybuild:330: clean: plugin distutils failed with: exit
> code=1: python3.6 setup.py clean
> dh_auto_clean: pybuild --clean -i python{version} -p 3.6 returned exit
> code 13
> make[1]: *** [debian/rules:29: override_dh_auto_clean] Error 25
> make[1]: Leaving directory
> '/home/rnpalmer/Debian/builds/stackbuild/sympy-1.1.1'
> make: *** [debian/rules:10: clean] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
> returned exit status 2
>
>

Bug#888935: node-xterm FTBFS: error TS2339: Property 'parentElement' does not exist on type 'never'

[Ghislain Vaillant]

> Source: node-xterm
> Version: 2.7.0+ds1-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/no
> de-xterm.html
> 
> ...
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/build/1st/node-xterm-2.7.0+ds1'
> tsc --project .
> src/utils/Mouse.ts(30,80): error TS2339: Property 'parentElement'
> does not exist on type 'never'.
> debian/rules:19: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2

No idea how to fix this. The package used to build fine.

Without further context, I am clueless about what to do about it.

Please help,
Ghis

Bug#887583: libjs-fetch FTBFS with mocha 4.0.1-3

[Ghislain Vaillant]

cc'd to Pirate Praveen who reported a similar issue for a version on
experimental?

Do you have an idea what's going on? Why is Adrian's log different to
yours?

On Thu, 18 Jan 2018 09:23:11 +0200 Adrian Bunk  wrote:
> Source: libjs-fetch
> Version: 2.0.3-1
> Severity: serious
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/li
bjs-fetch.html
> 
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/build/1st/libjs-fetch-2.0.3'
> xvfb-run -a -s "-screen 0 640x480x16" ./script/test
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-
pbuilder1'
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.css (203). Details: Error transferring http://localhost:3901/node_modu
les/mocha/mocha.css - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/url-search-
params/build/url-search-params.js (203). Details: Error transferring ht
tp://localhost:3901/node_modules/url-search-params/build/url-search-
params.js - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.js (203). Details: Error transferring http://localhost:3901/node_modul
es/mocha/mocha.js - server replied: Not Found
> ReferenceError: Can't find variable: Mocha
> ReferenceError: Can't find variable: suite
> TypeError: mocha.run is not a function. (In 'mocha.run()',
'mocha.run' is undefined)
> Likely due to external resource loading and timing, your tests
require calling `window.initMochaPhantomJS()` before calling any mocha
setup functions. See https://github.com/nathanboktae/mocha-phantomjs-co
re/issues/12
> TypeError: Attempting to change the setter of an unconfigurable
property.
> TypeError: Attempting to change the setter of an unconfigurable
property.
> QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-
pbuilder1'
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.css (203). Details: Error transferring http://localhost:3901/node_modu
les/mocha/mocha.css - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/url-search-
params/build/url-search-params.js (203). Details: Error transferring ht
tp://localhost:3901/node_modules/url-search-params/build/url-search-
params.js - server replied: Not Found
> Error loading resource http://localhost:3901/node_modules/mocha/mocha
.js (203). Details: Error transferring http://localhost:3901/node_modul
es/mocha/mocha.js - server replied: Not Found
> ReferenceError: Can't find variable: Mocha
> Likely due to external resource loading and timing, your tests
require calling `window.initMochaPhantomJS()` before calling any mocha
setup functions. See https://github.com/nathanboktae/mocha-phantomjs-co
re/issues/12
> TypeError: Attempting to change the setter of an unconfigurable
property.
> TypeError: Attempting to change the setter of an unconfigurable
property.
> debian/rules:28: recipe for target 'override_dh_auto_test' failed
> make[1]: *** [override_dh_auto_test] Error 1
> 
> 

Bug#881205: Assistance for maintaining src:backintime

[Ghislain Vaillant]

Dear Jonathan,

I was suprised to discover that backintime had been removed from
testing despite RC bug #881205 being fixed upstream [1].

For testing/unstable an update of the package to version 1.1.24 should
do the trick, whilst stretch/wheezy will require a backport of this
particular commit.

I was wondering whether you need any help with the maintenance of the
package, which I'd be happy to offer. It might also be useful to move
the package to team-maintenance long term, under collab-maint or one of
the Python packaging teams.

[1] https://github.com/bit-team/backintime/commit/cef81d0da93ff60125260
7df3db1a48f7f6f01

Cheers,
Ghis

Bug#880958: yapf3 explicitly depends on python3.5

[Ghislain Vaillant]

What about the patches fixing the other two bugs affecting yapf? Please
consider checking the BTS.

Ghis


Le 14 nov. 2017 22:25, "Ana C. Custura" <a...@netstat.org.uk> a écrit :

Hi Ghis,

Thank you for the reply. There is a package on mentors that addresses
both this bug (88958) and the split (879196) bug you raised. I am
waiting for my mentor to review it before uploading.

Ana

On Tue, Nov 14, 2017, at 08:59 AM, Ghislain Vaillant wrote:
> Thank you Matthias for raising this issue. CC'ing the maintainer in case
> she's not subscribed.
>
> On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose <d...@debian.org> wrote:
> > Package: yapf3
> > Version: 0.17.0-1
> > Severity: serious
> > Tags: sid buster
> >
> > yapf3 explicitly depends on python3.5. One mistake certainly is the b-d
on
> > python3-all, which is wrong for an application-only package.
>
> The application is not compliant with the Python packaging guidelines.
> The public modules should be split from the application package. See
> #879196 for a discussion about it.
>
> I have proposed a patch offline but it has yet to be applied. Fixing
> #879196 will transitively fix the issue you just reported.
>
> > And if this package is application-only, why ship both Python2 and
Python3 vesions?
>
> It is nether application-only, nor Python 3 specific.
>
> Cheers,
> Ghis

Bug#880958: yapf3 explicitly depends on python3.5

[Ghislain Vaillant]

Thank you Matthias for raising this issue. CC'ing the maintainer in case 
she's not subscribed.


On Mon, 6 Nov 2017 11:52:00 +0100 Matthias Klose  wrote:

Package: yapf3
Version: 0.17.0-1
Severity: serious
Tags: sid buster

yapf3 explicitly depends on python3.5. One mistake certainly is the b-d on
python3-all, which is wrong for an application-only package.


The application is not compliant with the Python packaging guidelines. 
The public modules should be split from the application package. See 
#879196 for a discussion about it.


I have proposed a patch offline but it has yet to be applied. Fixing 
#879196 will transitively fix the issue you just reported.



And if this package is application-only, why ship both Python2 and Python3 
vesions?


It is nether application-only, nor Python 3 specific.

Cheers,
Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 10/10/17 11:58, Adrian Bunk wrote:

On Tue, Oct 10, 2017 at 12:08:29AM +0100, Ghislain Vaillant wrote:

On 09/10/17 23:06, Adrian Bunk wrote:

On Mon, Oct 09, 2017 at 12:28:22PM +0100, Ghislain Vaillant wrote:

...
I was complaining about the insufficiencies behind this RC, more than the
situation with Sphinx. No offense to Adrian, but getting an RC bug reported
without much context to work with is just plain frustrating. Without your
intervention, this RC could have dragged for a long time.


Ghis, I do consider our repeated attempts to blame me for not fixing a bug in
your package VERY offensive.


I don't recall saying anywhere in this thread that I expected *you* to
provide a patch for this. I complained about the lack of context of the
initial bug report, albeit too bluntly to your taste.
...


Your repeated "without much context to work with" are just fancy words
for blaming me for not having debugged a FTBFS in your package.


This interpretation is yours. I acknowledged earlier that nothing was 
implied on my end. Whether you believe or not is a different matter and 
beyond the point of this thread.



I did tell you everything I knew (including providing the email address
of the person causing the FTBFS in the initial bug report), and it is
not my job to debug a FTBFS in your package.



You were even lucky that I was able to point you at what broke it,
there are more than 200 open RC bugs for FTBFS I reported [1] and
in many cases the error message is all I can provide.


Since you failed to quote the second half of my previous reply, I'll 
paste it again:


"Please accept my sincere apologies"

Should you decide to reply to this email, I would appreciate you quoting 
it in full instead of selective pieces of it to fulfill your narrative.


I have come clean and apologized for my wrongs, now is the time to shake 
hands and move on.


Regards,
Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 09/10/17 23:06, Adrian Bunk wrote:

On Mon, Oct 09, 2017 at 12:28:22PM +0100, Ghislain Vaillant wrote:

...
I was complaining about the insufficiencies behind this RC, more than the
situation with Sphinx. No offense to Adrian, but getting an RC bug reported
without much context to work with is just plain frustrating. Without your
intervention, this RC could have dragged for a long time.


Ghis, I do consider our repeated attempts to blame me for not fixing a bug in
your package VERY offensive.


I don't recall saying anywhere in this thread that I expected *you* to 
provide a patch for this. I complained about the lack of context of the 
initial bug report, albeit too bluntly to your taste.



I did not break it, I am not the maintainer of the package that broke,
and I have zero knowledge about either package.


Neither did I explicitly or implicitly held you responsible for the 
issue leading up to this RC bug. Please read again.



And the fact that I even did the extra work of finding the exact change
that broke your package makes it even more insulting - for a large part
of the FTBFS I report I do not even have a clue what broke it.



The only thing I regret is that I tried to be helpful after your initial
email, and I am seriously considering giving you a permanent entry in my
killfile so that I won't have to read another email from you for the rest
of my life.


Let's not reach such extremes yet. We are all working towards the same 
goal, i.e. making Debian a quality Linux distribution. Please accept my 
sincere apologies if I did hurt your feelings in any way.


Now, let's just move on shall we.

Ghis

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

On 03/10/17 12:28, Dmitry Shachnev wrote:

Control: forwarded -1 https://bitbucket.org/pybtex-devs/pybtex/pull-requests/9/

Hi Ghislain,

On Sat, Sep 30, 2017 at 10:40:52AM +0100, Ghislain Vaillant wrote:

And what the hell am I supposed to do with this?!

Nice of you to report the issue but, without further context, I can't take
further actions.

Isn't it the Dmitry's responsibility to at least communicate on the change
and suggest solutions for it to people impacted by RCs? If he did, please
point me to the announcement in case I missed it.

Sorry for that. I was aware of 5 or 6 packages that my change could affect,
but I did not expect that there would be more of them. Also I do not have
the resources to rebuild all reverse dependencies for every change in Sphinx.

Anyway, better late than never, so let me explain what happened there:

* Sphinx has a JavaScript library (doctools.js) that it uses to perform
   search on built HTML documents. This library is loaded from search.html
   page, and that page should contain a DOCUMENTATION_OPTIONS JavaScript
   object which acts like configuration for that library.

* Right now, if you open /usr/share/doc/python-pybtex-doc/html/search.html
   from your package, you will notice that search does not work. The browser
   console will have an error like this:

   searchtools.js:543:96: TypeError: suffix is undefined

   It is not something that I broke; it is caused by a change in Sphinx 1.5,
   that added one more required option (SOURCELINK_SUFFIX) which should be in
   DOCUMENTATION_OPTIONS.


Many thanks for providing these details.


* Good news is that you should not notice such issues yourself; dh_sphinxdoc
   performs the sanity check for you. It had a warning about this since sphinx
   1.5.2-2. In the latest upload I turned this warning into error, which is
   why you get this FTBFS bug.

I see.

* The only packages affected by this are ones that have custom templates,
   that do not inherit from sphinx/themes/basic/layout.html. Yours has one in
   docs/theme/layout.html.

* I have just created an upstream pull request which fixes this issue. You
   can grab the patch from there.

Thanks for working on a fix, very much appreciated.

In future, please CC me if you want to complain about Sphinx.

I was complaining about the insufficiencies behind this RC, more than 
the situation with Sphinx. No offense to Adrian, but getting an RC bug 
reported without much context to work with is just plain frustrating. 
Without your intervention, this RC could have dragged for a long time.


Ghis

Bug#877150: Forwarded upstream

[Ghislain Vaillant]

Control: forwarded -1 https://github.com/shoyer/h5netcdf/issues/32

Bug#877109: pybtex FTBFS with Sphinx 1.6.4-1

[Ghislain Vaillant]

sphinx (1.6.4-1) unstable; urgency=medium
...
  * dh_sphinxdoc: Turn warning about missing SOURCELINK_SUFFIX to an error.
...
 -- Dmitry Shachnev   Tue, 26 Sep 2017 17:47:54 +0300


And what the hell am I supposed to do with this?!

Nice of you to report the issue but, without further context, I can't 
take further actions.


Isn't it the Dmitry's responsibility to at least communicate on the 
change and suggest solutions for it to people impacted by RCs? If he 
did, please point me to the announcement in case I missed it.


This is really frustrating.

Ghis

Bug#853658: Forwarded upstream

[Ghislain Vaillant]

On 18/08/17 17:26, Sebastiaan Couwenberg wrote:

On Mon, 7 Aug 2017 08:49:19 +0100 Ghislain Vaillant wrote:

control: forwarded -1 https://github.com/Shark-ML/Shark/issues/194


Instead of packaging a snapshot as suggested by upstream, I suggest to
explicitly build the package with GCC 6 (as per the attached patch)(
until the new upstream release is available which builds successfully
with GCC 7.


That's a good point, though I am worried of the lack of response from 
upstream and lack of commit activity overall (compared to when I 
packaged the software initially).


Thanks for the patch, I'll incorporate it soon.

Ghis

Bug#871927: forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 
https://github.com/QuantStack/xtensor-python/issues/102

Bug#853658: Forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/Shark-ML/Shark/issues/194

Bug#859080: Forwarded to proposed PR

[Ghislain Vaillant]

control: forwarded -1 https://github.com/spyder-ide/spyder/pull/4311

Bug#859080: spyder-memory-profiler: FTBFS: AttributeError: 'NoneType' object has no attribute 'toUtf8'

[Ghislain Vaillant]

control: reassign -1 spyder
control: affects -1 spyder-memory-profiler

On Fri, 2017-03-31 at 10:33 +0100, Chris Lamb wrote:
> Ghislain Vaillant wrote:
> 
> > I am going to need some more context here. The build ran fine on the 
> > builders when the package was initially uploaded, and still runs fine on 
> > both my unstable chroot and debomatic [1].
> 
>   /usr/lib/python3/dist-packages/spyder/utils/programs.py:33: in 
>   username = encoding.to_unicode_from_fs(os.environ.get('USER'))
> 
> ^ Looks like it assumes that a USER environment variable exists. Is this
> a fair assumption to make?

So that's an issue with upstream spyder, not spyder-memory-profiler
then.

I'll offer a patch to switch to using Python's getpass.getuser(), which
should be more robust than the current reliance on the USER envvar.

Do you believe the RC severity remains justified though?

Cheers,
Ghis

Bug#859080: spyder-memory-profiler: FTBFS: AttributeError: 'NoneType' object has no attribute 'toUtf8'

[Ghislain Vaillant]

Hi Chris,

On Thu, 30 Mar 2017 08:26:36 +0100 Chris Lamb  wrote:

Source: spyder-memory-profiler
Version: 0.1.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Dear Maintainer,

spyder-memory-profiler fails to build from source in unstable/amd64:


[...]


The full build log is attached.


I am going to need some more context here. The build ran fine on the 
builders when the package was initially uploaded, and still runs fine on 
both my unstable chroot and debomatic [1].


[1] 
http://debomatic-amd64.debian.net/distribution#unstable/spyder-memory-profiler/0.1.0-1/buildlog


Regards,
Ghis

Bug#855494: mgltools-pmv: runPmv does not start

[Ghislain Vaillant]

On Sun, 19 Feb 2017 09:00:07 +0100 Andreas Tille  wrote:

Package: mgltools-pmv
Version: 1.5.7-1
Severity: grave
Justification: renders package unusable

Hi,

I intended to reproduce #855485 but I was running into a different
problem:

$ runPmv
Run PMV from  /usr/lib/python2.7/dist-packages/Pmv
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/Pmv/__init__.py", line 378, in runPmv
from Pmv.moleculeViewer import MoleculeViewer
  File "/usr/lib/python2.7/dist-packages/Pmv/moleculeViewer.py", line 16, in 

from MolKit.molecule import Atom, AtomSet, BondSet, Molecule , MoleculeSet
  File "/usr/lib/python2.7/dist-packages/MolKit/molecule.py", line 26, in 

from numpy.oldnumeric import sum, array, less_equal, take, nonzero, argsort
ImportError: No module named oldnumeric


Not too surprising considering that the numpy.oldnumeric modules was 
removed since Numpy 1.9 [1], so it has been broken for a long time 
without people noticing.


We could port the code base to the current Numpy API, but I am not sure 
whether we will have enough of a user-base to validate it (see above) 
and how much effort it will take. Besides, the software did not receive 
updates for years so we would probably be maintaining this effort on our 
own.


Based on this 2 comments, one might ask whether it is worth maintaining 
a package for this piece of software.


[1] https://docs.scipy.org/doc/numpy/reference/routines.oldnumeric.html

Cheers,
Ghis

Bug#855347: libopenshot: Incomplete debian/copyright?

[Ghislain Vaillant]

On Fri, 17 Feb 2017 13:20:28 +1300 Chris Lamb  wrote:
> I just ACCEPTed libopenshot from NEW but noticed it was missing 
> attribution in debian/copyright for at least:
> 
> include/DecklinkInput.h:8: * Copyright (c) 2009 Blackmagic Design
> include/DecklinkOutput.h:8: * Copyright (c) 2009 Blackmagic Design
> src/DecklinkInput.cpp:8: * Copyright (c) 2009 Blackmagic Design
> src/DecklinkOutput.cpp:8: * Copyright (c) 2009 Blackmagic Design
> 
> 
> (This is not exhaustive so please check over the entire package 
> carefully and address these on your next upload.)

No problem, I'll address that in a subsequent upload. Thanks for
spotting this, Chris.

Cheers,
Ghis 

Bug#846045: python-pytest-benchmark: fixture is not detected by pytest

[Ghislain Vaillant]

On Sat, 17 Dec 2016 11:24:17 +0100 Hugo Lefeuvre  wrote:
> Hi Afif,
> 
> Thanks for reporting bugs.
> 
> The problem comes from the fact that pytest-benchmark needs the
> statistics module, which I haven't declared in the dependencies as
> it is not packaged yet and is in the extra section of the setup.py.
> 
> I'll package the needed module as soon as possible.

Since python-pytest-benchmark will not make it to Stretch, you can just
drop the binary package for Python 2 to close this RC.

Ghis

Bug#851162: Still unresolved upstream, help needed

[Ghislain Vaillant]

Cc'd to debian-powerpc

On Fri, 13 Jan 2017 10:17:18 + Ghislain Vaillant 
<ghisv...@gmail.com> wrote:

control: forwarded -1 https://github.com/h5py/h5py/issues/817


Upstream is running out of ideas, so any help from the team would be 
warmly welcome.


Cheers,
Ghis

Bug#851162: forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/h5py/h5py/issues/817

Bug#850699: Focus on mips / s390x issue, fixed upstream

[Ghislain Vaillant]

control: retitle -1 h5py: FTBFS [mips, s390x]: test failures
control: usertag -1 - ppc64el

Splitting this FTBFS into 2 different issues. This one for mips / s390x
and one for ppc* architectures.

There is a fix pending upstream for the mips / s390x issue.

Ghis

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

control: block -1 by 850277

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

Now CC'd to the Debian CMake Team

On 05/01/17 12:26, Ghislain Vaillant wrote:

CC'd  the Debian CMake Team, who might be able to help.

On 05/01/17 10:48, Ghislain Vaillant wrote:

CC'd to the src:glm maintainer,

On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant
<ghisv...@gmail.com> wrote:

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in
the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge=0.9.2-2

Ghis


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

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


Hi Guus, could you have a look at this please?

It looks like it is due to a regression in glm introduced in 0.9.8.3
compared to 0.9.8.1. The CMake detection works correctly for amd64 but
not i386.

The bug only shows up now because src:forge used to silently download a
copy of glm if a system version were not found. I have corrected this
behaviour and pushed a new version of the packaging, which now triggers
the CMake detection problem.

Ghis


Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1
and 0.9.8.3:

```
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b7df09f..253eee5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR
"${CMAKE_INSTALL_LIBDIR}/cmake/glm")
 install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})

 write_basic_package_version_file(
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 VERSION ${GLM_VERSION}
 COMPATIBILITY AnyNewerVersion
 )
@@ -188,7 +188,7 @@ configure_package_config_file(
 install(
 FILES

"${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 DESTINATION ${GLM_INSTALL_CONFIGDIR}
 )
```

It looks like the glm version lookup did not work before (because the
version file was wrongly named) and has been fixed in the most recent
release.

Now if we inspect the content of glmConfigVersion.cmake, we find the
following code, which I believe to be our culprit:

```
# check that the installed version has the same 32/64bit-ness as the one
which is currently searching:
if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
   math(EXPR installedBits "8 * 8")
   set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
   set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
```

Hence the following outcome during the build in src:forge for any 32-bit
architecture:

```
CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
  Could not find a configuration file for package "glm" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```

So the question is how to instruct CMake to produce a ConfigVersion file
without the above bit-ness check?

Ghis

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

CC'd  the Debian CMake Team, who might be able to help.

On 05/01/17 10:48, Ghislain Vaillant wrote:

CC'd to the src:glm maintainer,

On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant
<ghisv...@gmail.com> wrote:

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in
the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge=0.9.2-2

Ghis


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

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


Hi Guus, could you have a look at this please?

It looks like it is due to a regression in glm introduced in 0.9.8.3
compared to 0.9.8.1. The CMake detection works correctly for amd64 but
not i386.

The bug only shows up now because src:forge used to silently download a
copy of glm if a system version were not found. I have corrected this
behaviour and pushed a new version of the packaging, which now triggers
the CMake detection problem.

Ghis


Alright, this one is a bit tricky. Looking at the diff between 0.9.8.1 
and 0.9.8.3:


```
diff --git a/CMakeLists.txt b/CMakeLists.txt
index b7df09f..253eee5 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -164,7 +164,7 @@ set(GLM_INSTALL_CONFIGDIR 
"${CMAKE_INSTALL_LIBDIR}/cmake/glm")

 install(DIRECTORY glm DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})

 write_basic_package_version_file(
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 VERSION ${GLM_VERSION}
 COMPATIBILITY AnyNewerVersion
 )
@@ -188,7 +188,7 @@ configure_package_config_file(
 install(
 FILES

"${CMAKE_CURRENT_BINARY_DIR}/${GLM_INSTALL_CONFIGDIR}/glmConfig.cmake"
-"${CMAKE_CURRENT_BINARY_DIR}/glmVersion.cmake"
+"${CMAKE_CURRENT_BINARY_DIR}/glmConfigVersion.cmake"
 DESTINATION ${GLM_INSTALL_CONFIGDIR}
 )
```

It looks like the glm version lookup did not work before (because the 
version file was wrongly named) and has been fixed in the most recent 
release.


Now if we inspect the content of glmConfigVersion.cmake, we find the 
following code, which I believe to be our culprit:


```
# check that the installed version has the same 32/64bit-ness as the one 
which is currently searching:

if(NOT CMAKE_SIZEOF_VOID_P STREQUAL "8")
   math(EXPR installedBits "8 * 8")
   set(PACKAGE_VERSION "${PACKAGE_VERSION} (${installedBits}bit)")
   set(PACKAGE_VERSION_UNSUITABLE TRUE)
endif()
```

Hence the following outcome during the build in src:forge for any 32-bit 
architecture:


```
CMake Error at src/backend/opengl/CMakeLists.txt:17 (FIND_PACKAGE):
  Could not find a configuration file for package "glm" that is compatible
  with requested version "".

  The following configuration files were considered but not accepted:

/usr/lib/cmake/glm/glmConfig.cmake, version: 0.9.8 (64bit)
```

So the question is how to instruct CMake to produce a ConfigVersion file 
without the above bit-ness check?


Ghis

Bug#850243: forge: FTBFS on multiple architectures

[Ghislain Vaillant]

CC'd to the src:glm maintainer,

On Thu, 05 Jan 2017 10:37:06 + Ghislain Antony Vaillant 
 wrote:

Source: forge
Version: 0.9.2-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Since the latest update of the packaging, src:forge fails to build due
to configuration error whilst looking for glm. Multiple architectures
are affected, including major ones such as i386 or armhf / armel [1].

[1] https://buildd.debian.org/status/logs.php?pkg=forge=0.9.2-2

Ghis


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

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


Hi Guus, could you have a look at this please?

It looks like it is due to a regression in glm introduced in 0.9.8.3 
compared to 0.9.8.1. The CMake detection works correctly for amd64 but 
not i386.


The bug only shows up now because src:forge used to silently download a 
copy of glm if a system version were not found. I have corrected this 
behaviour and pushed a new version of the packaging, which now triggers 
the CMake detection problem.


Ghis

Bug#849593: libfftw3-single3: dependencies in shlibs file not tight enough (Was: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe)

[Ghislain Vaillant]

CC'd to d-science,

On Fri, 30 Dec 2016 01:24:07 + James Cowgill <jcowg...@debian.org> 
wrote:

Hi,

On 30/12/16 00:50, Ghislain Vaillant wrote:
> On Thu, 29 Dec 2016 00:30:58 + James Cowgill <jcowg...@debian.org> wrote:
>> Control: severity -1 serious
>> Control: clone -1 -2
>> Control: reassign -2 libfftw3-single3 3.3.5-1
>> Control: block -1 by -2
>> Control: retitle -2 libfftw3-single3: dependencies in shlibs file not tight 
enough
>>
>> Hi,
>>
>> On 29/12/16 00:02, Oleksandr Gavenko wrote:
>>> Package: ardour
>>> Version: 1:5.5.0~dfsg-1
>>> Severity: important
>>>
>>> Application is being crashing constantly with:
>>>
>>> bash# ardour5
>>> /usr/lib/ardour5/ardour-5.5.0: symbol lookup error: 
/usr/lib/ardour5/ardour-5.5.0: undefined symbol: fftwf_make_planner_thread_safe
>> [...]
>>> Versions of packages ardour depends on:
>> [...]
>>> ii  libfftw3-single3 3.3.4-2
>
> How come? Both testing and unstable have 3.3.5-1.

I don't think that matters. Partial upgrades should work (and
derivatives may rely on it).


Next time, it would be nice to explain upfront that the new version of 
ardour you are trying to build may *conditionally* use new features 
introduced by FFTW 3.5:


https://github.com/Ardour/ardour/search?utf8=%E2%9C%93=fftwf_make_planner_thread_safe=Code


>> This package is the problem. The fftwf_make_planner_thread_safe
>> function is only present in fftw3 3.3.5 (so upgrading your package
>> would fix this). fftw3 should generate a stricter dependency so that
>> this doesn't happen.
>
> libfftw3-dev depends on libfftw3_single3 (=${binary:Version}).
>
> How is that not strict enough?

I'm talking about the dependency from ardour to libfftw3_single3. The
dependency from libfftw3-dev doesn't matter here.


Maybe this could be *temporarily* fixed on ardour's end by requiring 
libfftw3-dev (>= 3.3.5) as a b-dep no?



>> fftw3 maintainers: to fix this you either need to provide a symbols
>> file, or pass a suitable -V option to dh_makeshlibs so the shlibs file
>> contains a stricter dependency.
>
> Please be more explicit about the expected outcome (i.e. the stricter
> dependency you keep mentioning).

Please read policy 8.6 which describes most of this more fully.

The goal is for dpkg-shlibdeps to generate a dependency like
"libfftw3-single3 (>= 3.3.5)" for any package which uses
fftwf_make_planner_thread_safe. This is needed otherwise you may get a
linker error like ardour does, and it's is done by using the symbols or
shlibs systems as described in policy 8.6.


I am personally not familiar with the symbols stuff, so it would be up 
to somewhat from the team or yourself to provide a patch for this issue.


Hope this helps,
Ghis

Bug#849593: Bug#849589: ardour: undefined symbol: fftwf_make_planner_thread_safe

[Ghislain Vaillant]

On Thu, 29 Dec 2016 00:30:58 + James Cowgill  wrote:
> Control: severity -1 serious
> Control: clone -1 -2
> Control: reassign -2 libfftw3-single3 3.3.5-1
> Control: block -1 by -2
> Control: retitle -2 libfftw3-single3: dependencies in shlibs file not tight 
> enough
> 
> Hi,
> 
> On 29/12/16 00:02, Oleksandr Gavenko wrote:
> > Package: ardour
> > Version: 1:5.5.0~dfsg-1
> > Severity: important
> > 
> > Application is being crashing constantly with:
> > 
> > bash# ardour5
> > /usr/lib/ardour5/ardour-5.5.0: symbol lookup error: 
> > /usr/lib/ardour5/ardour-5.5.0: undefined symbol: 
> > fftwf_make_planner_thread_safe
> [...]
> > Versions of packages ardour depends on:
> [...]
> > ii  libfftw3-single3 3.3.4-2

How come? Both testing and unstable have 3.3.5-1.

> This package is the problem. The fftwf_make_planner_thread_safe
> function is only present in fftw3 3.3.5 (so upgrading your package
> would fix this). fftw3 should generate a stricter dependency so that
> this doesn't happen.

libfftw3-dev depends on libfftw3_single3 (=${binary:Version}).

How is that not strict enough?

> fftw3 maintainers: to fix this you either need to provide a symbols
> file, or pass a suitable -V option to dh_makeshlibs so the shlibs file
> contains a stricter dependency.

Please be more explicit about the expected outcome (i.e. the stricter
dependency you keep mentioning).

Thanks,
Ghis

Bug#848761: ovito: FTBFS: Test failures, now fixed upstream

[Ghislain Vaillant]

On Fri, 23 Dec 2016 19:28:09 + Ghislain Vaillant <ghisv...@gmail.com> wrote:
> I have forwarded the issue upstream with a build log on the latest
> upstream version done on debomatic.

Alright, upstream claims the issue is fixed on `master`. I intend to
cherry-pick the fix onto 2.8.1, unless upstream decides to release a
new version as suggested.

Ghis

Bug#848761: ovito: FTBFS: Test failures

[Ghislain Vaillant]

Hopefully, updating the package to the latest upstream (2.8.1) may fix
these test problems. That's what I am trying now.

Ghis

Bug#848771: numexpr: FTBFS: Test failures

[Ghislain Vaillant]

control: forwarded -1 https://github.com/pydata/numexpr/issues/239

Bug#849177: Python-numpy transition breaks at least two packages

[Ghislain Vaillant]

On Fri, 2016-12-23 at 10:43 +0100, Andreas Tille wrote:
> Hi,
> 
> I have cloned bug #848758 where I suggested to revert the python-numpy
> transition which other posters agreed upon.  Besides breaking
> python-skbio I spotted another package python-skimage which fails with:
> 
> 
> ==
> ERROR: skimage.filters.rank.tests.test_rank.test_all
> --
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in runTest
> self.test(*self.arg)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
>  line 16, in test_all
> check_all()
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/_shared/testing.py",
>  line 232, in inner
> result = func(*args, **kwargs)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/tests/test_rank.py",
>  line 89, in check_all
> rank.windowed_histogram(image, selem))
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
>  line 986, in windowed_histogram
> pixel_size=n_bins)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
>  line 90, in _apply_vector_per_pixel
> pixel_size=pixel_size)
>   File 
> "/build/skimage-0.12.3/debian/tmp/usr/lib/python2.7/dist-packages/skimage/filters/rank/generic.py",
>  line 53, in _handle_input
> out = np.empty(image.shape+(pixel_size,), dtype=out_dtype)
> TypeError: 'numpy.float64' object cannot be interpreted as an index
> 
> --
> Ran 1383 tests in 181.697s

Sounds like the kind of bug upstream would be interested in getting
fixed. This implementation must be relying on an implicit integer type
for the overall shape of the filter. My initial guess would be that
pixel_size ends-up being a float rather than an int here?

Not sure whether it is worth reverting numpy for this. From a quick
search, it looks like skimage has had issues like this in the past.

Ghis

Bug#848112: Python-skimage depends on unavailable package python-dask

[Ghislain Vaillant]

On 14/12/16 19:58, Stefan van der Walt wrote:

I would have absolutely no problem moving skimage to team maintenance.
If Yarik agrees, I'd appreciate some pointers on how to move forward
with that.  What I would like is to remain in the loop w.r.t. packaging
changes.  python-dask should be packaged now, I think Diane Trout of one
of the teams has been working on that the past week.


First, you'd need to pick a team (Ole suggested Debian Science or Debian 
Python Modules) and join it via their Alioth page. You might also want 
to email the team's mailing list to speed up the joining process.


Then, you'd have to setup the team maintained git repository. That's 
usually documented in the team's packaging policy and something Ole or 
myself can help you with.


Finally, just push the current content of the packaging to the new 
remote. You can then update the Vcs-Browse and Vcs-Git fields in 
d/control to the canonical path to the team's repository, change the 
Maintainer field to the chosen team and move yourselves to the Uploaders 
field.


And that's about it I think. Ole, feel free to correct me if something 
is not accurate.


Ghis

Bug#848112: Python-skimage depends on unavailable package python-dask

[Ghislain Vaillant]

On 14/12/16 09:59, Ole Streicher wrote:

Since skimage is one of the central packages, I would again ask to put
it under science|python team maintenance. Especially when under some
time pressure (upcoming freeze, combined with autoremovals of packages)
it would help a lot if the problems could be debugged within a standard
Debian developer workflow, without the need to switch to github or so.


I second Ole's suggestion.

Moving to team-maintenance would really help and is pretty painless if 
you are already using git for storing the debianized sources. You would 
still remain the main maintainer(s), but one-off fixes like this could 
be pushed and rolled-out quicker by anyone from the team.


Please consider it.

Ghis

Bug#845737: drop the problematic testcase?

[Ghislain Vaillant]

I would just drop the `test_symlink_time_handling` testcase and check
with upstream what might be going on here.

Apart from that, it looks like the internet access errors are fixed.

Ghis

Bug#845737: Also new upstream version has test failures

[Ghislain Vaillant]

On Tue, 13 Dec 2016 09:27:17 +0100 Andreas Tille  wrote:
> Hi Kevin,
> 
> you injected a "Closes: #845737" in the latest changelog but I get:
> 
> 
> ==
> FAIL: tests.tests.test_symlink_time_handling
> --
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
> self.test(*self.arg)
>   File 
> "/build/snakemake-3.9.0+dfsg/.pybuild/pythonX.Y_3.5/build/tests/tests.py", 
> line 345, in test_symlink_time_handling
> run(dpath("test_symlink_time_handling"))
>   File 
> "/build/snakemake-3.9.0+dfsg/.pybuild/pythonX.Y_3.5/build/tests/tests.py", 
> line 89, in run
> assert success, "expected successful execution"
> AssertionError: expected successful execution
>  >> begin captured logging << 
> snakemake.logging: WARNING: Provided cores: 3
> snakemake.logging: WARNING: Rules claiming more threads will be scaled down.
> snakemake.logging: WARNING: Job counts:
> count   jobs
> 1   main
> 1   make_output
> 2
> snakemake.logging: INFO: rule make_output:
> input: input_link
> output: output_link
> snakemake.logging: INFO: 
> snakemake.logging: WARNING: Removing output files of failed job make_output 
> since they might be corrupted:
> output_link
> snakemake.logging: WARNING: Will exit after finishing currently running jobs.
> snakemake.logging: ERROR: Exiting because a job execution failed. Look above 
> for error message
> - >> end captured logging << -
> 
> --
> Ran 70 tests in 36.997s
> 
> FAILED (failures=1)
> E: pybuild pybuild:276: test: plugin distutils failed with: exit code=1: cd 
> /build/snakemake-3.9.0+dfsg/.pybuild/pythonX.Y_3.5/build; python3.5 -m nose 
> tests
> 
> 
> So if there is no sensible explanation why this test might fail in a
> chroot disconnected from the net this bug is not closed.  In case the
> error occures due to the attempt to access some online resources the
> test needs to be excluded.
> 
> Kind regards
> 
>Andreas.
> 
> -- 
> http://fam-tille.de


Looks like this error is unrelated with access to remote resources.

Andreas' log is missing the following important line:

```
ln: failed to create symbolic link 'input_link': File exists
CalledProcessError in line 37 of 
/<>/snakemake-3.9.0+dfsg/.pybuild/pythonX.Y_3.5/build/tests/test_symlink_time_handling/Snakefile:
Command 'ln -s input_file input_link' returned non-zero exit status 1
  File 
"/<>/snakemake-3.9.0+dfsg/.pybuild/pythonX.Y_3.5/build/tests/test_symlink_time_handling/Snakefile",
 line 37, in 
```

So it seems to be a defect in the upstream testsuite.

Ghis

Bug#847171: Different output, still FTBFS

[Ghislain Vaillant]

I could not repeat the exact output Chris got.

Still FTBFS on my end in a clean chroot, with the following output:

standardPregraph/contig.o: In function `call_heavygraph':
contig.c:(.text+0x8a6): undefined reference to `I'
contig.c:(.text+0x91f): undefined reference to `no symbol'
contig.c:(.text+0x994): undefined reference to `no symbol'
contig.c:(.text+0xa0a): undefined reference to `no symbol'
contig.c:(.text+0xa68): undefined reference to `'
collect2: error: ld returned 1 exit status
Makefile:70: recipe for target 'SOAPdenovo-63mer' failed
make[1]: *** [SOAPdenovo-63mer] Error 1
make[1]: *** Waiting for unfinished jobs
make[2]: Leaving directory '/<>/soapdenovo2-
240+dfsg1/standardPregraph'
standardPregraph/contig.o: In function `call_heavygraph':
contig.c:(.text+0x8a6): undefined reference to `I'
contig.c:(.text+0x91f): undefined reference to `no symbol'
contig.c:(.text+0x994): undefined reference to `no symbol'
contig.c:(.text+0xa0a): undefined reference to `no symbol'
contig.c:(.text+0xa68): undefined reference to `'
collect2: error: ld returned 1 exit status
Makefile:74: recipe for target 'SOAPdenovo-127mer' failed
make[1]: *** [SOAPdenovo-127mer] Error 1
make[1]: Leaving directory '/<>/soapdenovo2-240+dfsg1'

Hope this helps.

Ghis

Bug#832391: consensuscore2: Any news?

[Ghislain Vaillant]

On Fri, 11 Nov 2016 14:17:13 -0800 Afif Elghraoui  wrote:
> Hi, Andreas,
> 
> على الأربعاء  9 تشرين الثاني 2016 ‫03:11، كتب 
> Andreas Tille:
> > 
> > do you have any news with this issue?
> > 
> 
> I should have posted an update. Upstream has moved consensuscore2 into a
> new source package, unanimity [1]. The packaging issues I was having are
> due to building the mixed-language code base. I have not found a good
> solution for this with debhelper, and the upstream build system was also
> very unconventional in order to handle it (which did not help
> debhelper's latching onto it). I think what needs to be done is to just
> package unanimity and have consensuscore2 be one of its binary packages.
> I'll have to see whether this problem will come up again after that.

I confirm Afif's reporting. This project is deprecated in favour of a larger
one.

We should just request an RM for this package, since we won't be getting any
support for it from upstream in the future, and focus on the new project. This
should also clear the current RC bug affecting it.

Ghis

Bug#846871: Suggested fix

[Ghislain Vaillant]

On Mon, 05 Dec 2016 11:53:59 +0100 Hilko Bengen  wrote:
> control: tag -1 patch
> 
> Hi,
> 
> I have verified that aff4 builds just fine if the "keepalive=0.5" line
> is removed from the requires.txt, so the extra python-keepalive package
> is not actually needed.
> 
> Please consider adding the patch below. Thanks!
> 
> Cheers,
> -Hilko
> 
> diff --git a/requirements.txt b/requirements.txt
> index cdd0693..55ec214 100644
> --- a/requirements.txt
> +++ b/requirements.txt
> @@ -1,2 +1 @@
>  rdflib>=4.0
> -keepalive>=0.5

I confirm that the dependency on keepalive should not be so strict. A quick
lookup in the upstream VCS showed that it is only used in one method of the
SPARQLWrapper class and its absence only raises a warning.

@maintainers
Please incorporate Hilko's patch to prevent transitive dependencies on keepalive
from leading to FTBFS in packages depending on rdflib. Thanks.

@Hilko
Do you intend to package keepalive? Your first message somewhat hinted this.

Cheers,
Ghis

Bug#844874: opensurgsim: googletest related build failure

[Ghislain Vaillant]

control: tags -1 pending

It is fixed on my end. Will push soon after testing.

Ghis

Bug#845737: mark as forwarded

[Ghislain Vaillant]

control: forwarded -1 https://bitbucket.org/snakemake/snakemake/issues/
426/random-test-hangs-during-debian-package

Bug#846351: h5py NMU for HDF5 1.10

[Ghislain Vaillant]

On 01/12/16 10:01, Iain Lane wrote:

On Thu, Dec 01, 2016 at 08:27:16AM +, Ghislain Vaillant wrote:

Hi Ian,

Thanks for looking into this issue. Indeed the HDF5 transition has made
quite a few RCs pop the last few days.

Please drop the deferred and let me prepare a conventional update with your
changes in, plus some cleaning of the packaging. Can I ping you back for
sponsorship when I am done?

The long-term solution would be to request a new release upstream which is
HDF5 1.10 compatible. They also recently introduced PyPy support, which I
know quite a few people are interested in.


Okay, I cancelled it. I might be able to offer sponsorship, but can't
promise a lot of time - just let me know and I'll see what I can do.

(In the event that this drags along and somebody else ends up here, the
previous patch should be good to re-upload.)

Cheers,



I have submitted the following update:

  https://mentors.debian.net/debian/pool/main/h/h5py/h5py_2.6.0-2.dsc

which includes the cherry-picked commit you proposed, plus some 
bookkeeping of the packaging files.


It has been successfully tested on debomatic here:


http://debomatic-amd64.debian.net/distribution#unstable/h5py/2.6.0-2/buildlog

Meanwhile, I have requested upstream to consider a new release.

Let me know if you have time to push this update, otherwise I can seek 
sponsorship within my team.


Cheers,
Ghis

Bug#846351: h5py NMU for HDF5 1.10

[Ghislain Vaillant]

On 01/12/16 08:27, Ghislain Vaillant wrote:

Hi Ian,

Thanks for looking into this issue. Indeed the HDF5 transition has made
quite a few RCs pop the last few days.

Please drop the deferred and let me prepare a conventional update with
your changes in, plus some cleaning of the packaging. Can I ping you
back for sponsorship when I am done?

The long-term solution would be to request a new release upstream which
is HDF5 1.10 compatible. They also recently introduced PyPy support,
which I know quite a few people are interested in.

Cheers,
Ghis


The request for a new release has been filed here:

https://github.com/h5py/h5py/issues/784

Ghis

Bug#846351: h5py NMU for HDF5 1.10

[Ghislain Vaillant]

Hi Ian,

Thanks for looking into this issue. Indeed the HDF5 transition has made 
quite a few RCs pop the last few days.


Please drop the deferred and let me prepare a conventional update with 
your changes in, plus some cleaning of the packaging. Can I ping you 
back for sponsorship when I am done?


The long-term solution would be to request a new release upstream which 
is HDF5 1.10 compatible. They also recently introduced PyPy support, 
which I know quite a few people are interested in.


Cheers,
Ghis

Bug#846330: fix pending

[Ghislain Vaillant]

control: tags -1 pending

I have pushed a tentative fix on a staging branch. I have yet to 
validate it on debomatic.


Ghis

Bug#844942: plastimatch: FTBFS: Tests failures

[Ghislain Vaillant]

control: tags -1 pending

On Sat, 19 Nov 2016 08:03:46 +0100 Lucas Nussbaum  wrote:

> The following tests FAILED:
>421 - vf-invert-trans-1 (Failed)
>422 - vf-invert-trans-1-stats (Failed)
>423 - vf-invert-trans-1-check (Failed)
>426 - wed-c (Failed)
> Errors while running CTest
> Makefile:152: recipe for target 'test' failed


The tests above have got mistakes in the declaration of their respective 
dependencies, which makes parallel run fail.


I have identified the mistakes and will push a patch fixing them.

Cheers,
Ghis

Bug#841582: Pyparsing error in sphinxcontrib-doxylink

[Ghislain Vaillant]

CC-ing this reply to the Debian bug report.

Thanks Paul for the patch. I applied it (fixed a missing import for 
ungroup), used your name for the commit authorship and acknowledged

your contribution to the packaging changelog.

I will also forward the patch upstream.

Many thanks for your contribution.

Cheers,
Ghis


On 16/11/16 23:09, Paul McGuire wrote:

Ghislain –



While googling for pyparsing mentions, I found this Debian bug report:



https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844368



I’m sorry that this recent version of pyparsing (2.1.10) causes some
compatibility problems. The change which caused you problems had to do
with the fixing of a bug in the MultipleMatch classes ZeroOrMore and
OneOrMore (although my CHANGES file only mentions ZeroOrMore).



The problem is that expressions that would return potentially multiple
words were only returning the first element when used with a results
name. This was a bug that was introduced in May, version 2.1.6 or so I
think. Apparently, you developed your grammar to work with this bug, and
expected the ‘qualifier’ result to return just a single string. After
fixing the bug, the OneOrMore expression properly returns this value as
a list, even though there is only one value.



I downloaded your module and did some quick tests, and adding the second
line below in parsing.py will fix your problem (I’m assuming that, if
multiple qualifier words are present, you will want all of them reported).



qualifier = OneOrMore(oneOf('const unsigned typename struct enum'))

qualifier = ungroup(qualifier.addParseAction(' '.join))



Again, I’m sorry for this mixup, I hope pyparsing continues to be useful
for you.



Regards,

-- Paul McGuire






Avast logo   

This email has been checked for viruses by Avast antivirus software.
www.avast.com 

Bug#839827: freeimage: CVE-2016-5684

[Ghislain Vaillant]

Dear Salvatore, Balint,

Thanks for forwarding the CVE to us and verifying which versions of the
package were affected.

I'll monitor the progress of this CVE. The CVE reporter offered some
clues as to how to mitigate the problem, but I wonder how appropriate
closure of this vulnerability can be verified.

Any suggestions would be welcome.

Best regards,
Ghis

Bug#839884: network-manager: Update hangs -> unreproducible

[Ghislain Vaillant]

Hi Jorg,

I could not reproduce the problem you are having. Both my laptops
successfully upgraded to the latest version of network-manager.

Regards,
Ghis

Bug#836677: pysparse: still worth maintaining?

[Ghislain Vaillant]

Hi Anton,

Following up on your offer for sponsorship. I pushed debian/1.1.1-1 to
the packaging repository after checking the build runs successfully on
debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/pysparse/1.1.1-1/buildlog

This release will also close the current RC affecting this package.

Ghis


On 22/09/16 20:21, Anton Gladky wrote:

Hi Ghis,

thanks for working on the package! Even it is abandoned by
upstream, we have to support it in Debian, because it has
reverse-dependency.

Feel free to ping me, if one need the package sponsoring.

Best regards

Anton


2016-09-22 9:33 GMT+02:00 Ghislain Vaillant <ghisv...@gmail.com>:

I have had a look at updating the package to the newest upstream
release and fixing this FTBFS. However, I have got strong concerns as
to whether it is worth keeping this package maintained in the archive:

- The latest release on PyPI [1] is busted (missing files). The issue
was reported [2] but never addressed since.

- Latest activity on the upstream repository is from 2013. By now, I
expected upstream would have fixed the PyPI tarball, at least.

- No Python 3 support. A manual call to 2to3 on the Python sources
allows the build process to run, but fails at the compilation stage.

[1] https://pypi.python.org/pypi/pysparse
[2] https://sourceforge.net/p/pysparse/mailman/message/33117282/

Best regards,
Ghis

Bug#836677: pysparse: still worth maintaining?

[Ghislain Vaillant]

I have had a look at updating the package to the newest upstream
release and fixing this FTBFS. However, I have got strong concerns as
to whether it is worth keeping this package maintained in the archive:

- The latest release on PyPI [1] is busted (missing files). The issue
was reported [2] but never addressed since.

- Latest activity on the upstream repository is from 2013. By now, I
expected upstream would have fixed the PyPI tarball, at least.

- No Python 3 support. A manual call to 2to3 on the Python sources
allows the build process to run, but fails at the compilation stage.

[1] https://pypi.python.org/pypi/pysparse
[2] https://sourceforge.net/p/pysparse/mailman/message/33117282/

Best regards,
Ghis

Bug#806616: fixed + pending

[Ghislain Vaillant]

control: tags -1 + fixed pending

I am working on it. The issue is fixed in my fork, and the fix should be
rolled with the next update which will include a new upstream release.

Thanks,
Ghis

Bug#836599: downgrading severity to normal

[Ghislain Vaillant]

control: severity -1 normal

Previous builds on mips and mipsel have been removed [1]. Downgrading 
the severity of this bug to allow the updated package to transition.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836740

Cheers,
Ghis

Bug#836599: shark binaries to be removed from mips and mipsel

[Ghislain Vaillant]

Upstream failed to find the cause for the test issues.

I have requested the removal of the shark binaries currently sitting in
testing for mips and mipsel. Once done, I plan to downgrade this bug to
a non-RC severity to allow the package to transition.

I guess it will be up to mips porters to get it to work on these
architectures.

Cheers,
Ghis

Bug#836599: forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/Shark-ML/Shark/issues/112

Forwarded upstream. Not sure whether this package was intended to work
on these architectures, so upstream might just not care about this.

I'll wait for their reply. The options are:
- Upstream fixes it hopefully.
- Disable testing for mips / mipsel in d/rules.
- Drop shark from the archive for mips / mipsel.

Feel free to comment. Thanks again for the report Emilio.

Ghis

Bug#831669: forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/pyFFTW/pyFFTW/issues/128

Upstream confirmed the non-portability of the package due to both heavy
reliance on x86 alignment, and availability of the long-double precision
of the FFTW library. The latter is not supported by all architectures.

Solving this issue is not high on upstream's priority, so the question 
remains whether we should just cut the archive from the failing 
architectures and only keep the i386 and amd64, or just drop the

package altogether.

Best regards,
Ghis

Bug#835679: Fixed submitted upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/ismrmrd/ismrmrd/pull/70

Forwarded upstream with a fix.

Ghis

Bug#836216: opengm: FTBFS (32-bit): SelfFusion/LazyFlipper type mismatch

[Ghislain Vaillant]

control: forwarded -1 https://github.com/opengm/opengm/issues/475

Thanks for reporting this issue. Upstream has been notified.

Perhaps an explicit cast to size_t where appropriate could solve the compile
error then.

Best regards,
Ghislain

Bug#820701: shark: FTBFS on various architectures - testsuite failures

[Ghislain Vaillant]

control: forwarded -1 https://github.com/Shark-ML/Shark/issues/110

Indeed, some tests were fixed but not all. Forwarded upstream.

Ghis

Bug#826042: Spyder crashes on start

[Ghislain Vaillant]

On 24/07/16 21:49, Ghislain Vaillant wrote:

Regarding rope, the package has a wishlist bug for Python 3 and also a
CVE (which is bad). It might be worth checking with the package
maintainer whether he still actively maintains it, and propose a
migration to the DPMT Git. I'll contact him and propose my help.


I have contacted Arnaud Fontaine, who's the current package maintainer
for rope, to ask for an update on this. I'll report when he responds.
Until he does, rope remains a pending issue for spyder in Python 3.

Ghis

Bug#826042: Spyder crashes on start

[Ghislain Vaillant]

On 24/07/16 21:10, Jitse Niesen wrote:

On 18/07/16 15:15, Ghislain Vaillant wrote:


If you want to be helpful, please consider reviewing whether the
current state of Debian unstable and check whether it contains all the
necessary dependencies for the packaging of Spyder 3.x to happen.


It's possible to run Spyder, but I don't think everything is ready for
it yet. Specifically, I can install (with "python setup.py install") and
run Spyder after I installed the following packages from Debian unstable:

python3 3.5.1-4
python3-docutils0.12+dfsg-1
python3-jinja2  2.8-1
python3-pickleshare 0.7.3-1
python3-qt4 4.11.4+dfsg-2
python3-qtawesome   0.3.3-3
python3-qtpy1.1.1-1
python3-sphinx  1.4.5-1
python3-zmq 15.2.0-1

However, Spyder complains of missing dependencies and while the basic
functionality is there, not all features work correctly. Some of them
can be installed from unstable:

python3-jedi0.9.0-1
python3-pep81.7.0-2
python3-psutil  4.2.0-1
python3-pyflakes1.2.3-1


Thanks Jitse for this listing. This is very helpful.


Spyder has three further dependencies that need more work:

* rope >= 0.9.4: There is a package python-rope version 0.10.2-1 but
  no Python3 version.

* qtconsole >= 4.2.0: Experimental has jupyter-qtconsole.

* nbconvert >= 4.0: As far as I can see, there is no nbconvert but
  there is an Intend-To-Package message at bug 801058.


As you can see here:

  https://lists.debian.org/debian-python/2015/09/msg00087.html

nbconvert is further along in the dependency chain, hence yourself not
finding an RFS for it yet. I believe Julien is working on it. Meanwhile
other dependencies like ipython and the jupyter core packages will have
to find their way to the archive (first via a trip to experimental)
first, before nbconvert is made available.

Regarding rope, the package has a wishlist bug for Python 3 and also a
CVE (which is bad). It might be worth checking with the package 
maintainer whether he still actively maintains it, and propose a

migration to the DPMT Git. I'll contact him and propose my help.

Cheers,
Ghis

Bug#826042: Spyder crashes on start

[Ghislain Vaillant]

On 18/07/16 12:17, Jitse Niesen wrote:

On Sun, 17 Jul 2016 16:50:55 -0700 Afif Elghraoui <a...@debian.org> wrote:


على الخميس 14 تـمـوز 2016 ‫13:05، كتب Jitse Niesen:
> I have recently become a developer with Spyder and I would dearly like
> to have Spyder back into Debian. Is there anything I can do to help?
>

If it's the case as it appears to be that the usual caretakers of this
package don't have time for it anymore, you may want to join Debian
Science and take over maintaining the package here. I could help you get
started with Debian packaging if you're interested.


Thanks for the offer. I was hoping for something less time consuming :)
but I will look into packaging Spyder for Debian if that's what it takes.


Spyder is already packaged for Debian FYI.


I believe Ghislain Vaillant (copied in) was thinking at some point to
work on updating the Spyder package, so I'll wait a few days to give him
and Pippa a chance to reply in order to avoid any duplicated effort.


The reason of the stalling of the packaging arises from the removal of
QtWebkit from Qt4 in Debian. Upstream advised against butchering the
packaged version of Spyder 2.x to run without QtWebkit, and instead
focus on Spyder 3.x.

However, Spyder 3.x introduces quite a lot of new dependencies that
needed to be packaged first. And that is Picca, myself, Julien Puydt
and others have been doing since.

If you want to be helpful, please consider reviewing whether the
current state of Debian unstable and check whether it contains all the
necessary dependencies for the packaging of Spyder 3.x to happen.

Cheers,
Ghis

Bug#830606: python-qtawesome: accesses the internet during build

[Ghislain Vaillant]

You are correct, here is the following line in conf.py:

intersphinx_mapping = {'https://docs.python.org/': None}

Thanks for spotting this.

Cheers,
Ghis

Bug#805678: pyoperators: FTBFS: NameError: global name 'FFTW_DEFAULT_NUM_THREADS' is not defined

[Ghislain Vaillant]

Forwarded upstream. Thanks for reporting this issue.

Ghis.

Bug#808320: fails to upgrade from 'testing'

[Ghislain Vaillant]

Hi Andreas,

Thanks for reporting this bug.

I am not quite sure what the appropriate course of action is here. My 
thinking was the following:


libarrayfire-cpu-dev [3.0.2] shipped all CMake configuration files, 
since it was the only backend available at the time.


With the recent inclusion of new backends (OpenCL, unified), this 
package was split to:


libarrayfire-cpu-dev [3.2.x]
libarrayfire-dev [3.2.x]

whereby libarrayfire-dev now contains the files common to all backends, 
including the offending file you reported.


I thought about the upgrade path from libarrayfire-cpu-dev [3.0.2] to 
libarrayfire-cpu-dev [3.2.x] but probably forgot about someone who just 
wants to install libarrayfire-dev [3.2.x] with an existing 
libarrayfire-cpu-dev [3.0.2] in place. This is a very much a corner case 
though.


So I am guessing the appropriate course of action is to do something on 
the libarrayfire-dev. Can anyone confirm whether would this solution 
suffice:


Replaces: libarrayfire-cpu-dev (<< 3.2.1)
Breaks: libarrayfire-cpu-dev (<< 3.2.1)

Many thanks,
Ghis

Bug#808320: Proposed fix with breaks / replaces

[Ghislain Vaillant]

On 19/12/15 10:49, Ghislain Vaillant wrote:

Hi Andreas,

Thanks for reporting this bug.

I am not quite sure what the appropriate course of action is here. My
thinking was the following:

libarrayfire-cpu-dev [3.0.2] shipped all CMake configuration files,
since it was the only backend available at the time.

With the recent inclusion of new backends (OpenCL, unified), this
package was split to:

libarrayfire-cpu-dev [3.2.x]
libarrayfire-dev [3.2.x]

whereby libarrayfire-dev now contains the files common to all backends,
including the offending file you reported.

I thought about the upgrade path from libarrayfire-cpu-dev [3.0.2] to
libarrayfire-cpu-dev [3.2.x] but probably forgot about someone who just
wants to install libarrayfire-dev [3.2.x] with an existing
libarrayfire-cpu-dev [3.0.2] in place. This is a very much a corner case
though.

So I am guessing the appropriate course of action is to do something on
the libarrayfire-dev. Can anyone confirm whether would this solution
suffice:

Replaces: libarrayfire-cpu-dev (<< 3.2.1)
Breaks: libarrayfire-cpu-dev (<< 3.2.1)

Many thanks,
Ghis


Would the following diff work:

diff --git a/debian/control b/debian/control
index 372e3d1..b111754 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,7 @@ Section: libdevel
 Architecture: any
 Multi-Arch: same
 Depends: libarrayfire-cpu3 (= ${binary:Version}),
- libarrayfire-dev,
+ libarrayfire-dev (>= 3.2.1+dfsg1-6),
  ${misc:Depends}
 Description: Development files for ArrayFire (CPU backend)
  ArrayFire is a high performance software library for parallel computing
@@ -92,6 +92,8 @@ Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}
 Suggests: libarrayfire-doc
+Replaces: libarrayfire-cpu-dev (<< 3.2.1+dfsg1-6)
+Breaks: libarrayfire-cpu-dev (<< 3.2.1+dfsg1-6)
 Description: Common development files for ArrayFire
  ArrayFire is a high performance software library for parallel computing
  with an easy-to-use API. Its array based function set makes parallel

Bug#802172: ismrmrd has an RC bug

[Ghislain Vaillant]

On 02/11/15 09:41, Gianfranco Costamagna wrote:

Hi Ghislain, please don't forget to subscribe to your packages...

Currently ismrmrd has an RC bug and is out of testing #802172

can you please have a look at it?

cheers,

G.



Hi Gianfranco, thanks for the heads-up.

I am aware of the RC bug, which has been revealed when upstream started 
to ship a comprehensive test suite. IMO, it highlights the fact that 
part of the library is not written in a portable way.


I know that upstream is planning a major rewrite for the next major 
release (v2.x), which may or may not result in more portable code. As a 
result, I am not planning to spend much effort on fixing the current 
code (v1.x).


Ghis

Bug#800668: iep ftbfs, missing build dependencies, still fails tests

[Ghislain Vaillant]

Hi Matthias,

The setup.py only lists pyzolib as install_requires, not setup_requires. 
Therefore, I assumed they were not intended to be installed at build time.


I am also not quite sure whether this package has an official test 
suite, so unittest.discover may be picking something which was 
unintended to be picked.


I can make a new upload with an explicit empty test target, will it 
solve your issue?


Many thanks for reporting this,

Ghis

Bug#797165: ITA bug for freeimage?

[Ghislain Vaillant]

Absolutely!

Shall I file an ITA for freeimage and begin transitioning the packaging 
repository to d-science?


Ghis


On 25/09/15 21:04, Anton Gladky wrote:

Hi Ghislain,

I made the previous upload of freeimage to fix RC-bug and
had the same idea to adopt freeimage under Debian-Science.

As far as I understand openjpeg is already in Debian [1].

So, let`s do it?

[1] https://tracker.debian.org/pkg/openjpeg2

Cheers

Anton


2015-09-16 11:17 GMT+02:00 Ghislain Vaillant <ghisv...@gmail.com>:

Hello everyone,

 From Raphael:

Hopefully one the of the people who will discover this RC bug (because
their package depends on freeimage or whatever) can be convinced to take
over this package... it has been orphaned for way too long.


I am one such package maintainers (ArrayFire) affected by the autorm of
freeimage. Also, other projects I am involved with do use freeimage. I may
consider taking over the maintenance of freeimage under d-science but want
to evaluate the amount of efforts that would require first.

 From Scott:

Freeimage > 1.5.4 (that is, the current sid version) requires OpenJPEG
2.1.0, which is not in Debian.



At this moment, the best course of action may be to simply carry the new
patches Raphael pointed out rather than updating freeimage then working to
remove openjpeg 2.1 support.


Which you hinted to be a non-trivial task, isn't it? Would it make things
easier if OpenJPEG was updated to 2.1.0 in Debian? I guess it would be a
requirement for a potential update of freeimage to 3.17 onwards?

Just trying to define what the "ideal" course of actions should be. I
understand the latter is currently far from reality.

Best regards,
Ghislain

--
To unsubscribe, send mail to 797165-unsubscr...@bugs.debian.org.

Bug#797165: moving forward

[Ghislain Vaillant]

Hello everyone,

From Raphael:
> Hopefully one the of the people who will discover this RC bug 
(because their package depends on freeimage or whatever) can be 
convinced to take over this package... it has been orphaned for way too 
long.


I am one such package maintainers (ArrayFire) affected by the autorm of 
freeimage. Also, other projects I am involved with do use freeimage. I 
may consider taking over the maintenance of freeimage under d-science 
but want to evaluate the amount of efforts that would require first.


From Scott:
> Freeimage > 1.5.4 (that is, the current sid version) requires 
OpenJPEG 2.1.0, which is not in Debian.


> At this moment, the best course of action may be to simply carry the 
new patches Raphael pointed out rather than updating freeimage then 
working to remove openjpeg 2.1 support.


Which you hinted to be a non-trivial task, isn't it? Would it make 
things easier if OpenJPEG was updated to 2.1.0 in Debian? I guess it 
would be a requirement for a potential update of freeimage to 3.17 onwards?


Just trying to define what the "ideal" course of actions should be. I 
understand the latter is currently far from reality.


Best regards,
Ghislain

Bug#796306: pyoperators: FTBFS: plugin distutils failed with: exit code=1

[Ghislain Vaillant]

Hi Chris, thanks for reporting this.

Seems that upstream forgot to update the results of some of the doctests.

Forwared upstream here:

https://github.com/pchanial/pyoperators/issues/22

Kind regards,
Ghis

Bug#792748: forwarded upstream

[Ghislain Vaillant]

Thanks for reporting this issue, it has been forwarded upstream.

Waiting for upstream to advise on an alternative name for the entry script.

Ghis


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754347: upgrade to upstream's version 3.12.4 ?

[Ghislain Vaillant]

Version 3.12.4 has been recently released upstream, which fixes a decent 
list of bugs.


http://ftp.acc.umu.se/pub/GNOME/sources/evolution/3.12/evolution-3.12.4.news

How hard would it be to update the current package ?

Ghis


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#743088: linop: FTBFS: Tests failures

[Ghislain Vaillant]

Hi Aaron,

The failing tests were dropped upstream, so I believe the problem you
are reporting is fixed in the latest version of the package, which now
ships the latest upstream version (0.8.2).

Please let me know if there are further issues with this.

Ghislain


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738735: linop: FTBFS: dh_sphinxdoc: Sphinx documentation not found

[Ghislain Vaillant]

Hi Aaron,

Mea culpa, I messed up my sbuild settings and did not test the package
under proper buildd configuration before flagging the package as ready
for upload. I have added the necessary override on dh_sphinxdoc to avoid
this issue in version 0.8.2-2 of the package.

Thanks,

Ghis


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738735: linop: FTBFS: dh_sphinxdoc: Sphinx documentation not found

[Ghislain Vaillant]

Thank you Aaron for reporting the bug and Andreas for providing
instructions for testing the bug.

I have uploaded a new version of the package to the git repository and
tested it against pdebuild with and without the --binary-arch option.

Do I need to do anything else ?

Ghis


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#738735: linop: FTBFS: dh_sphinxdoc: Sphinx documentation not found

[Ghislain Vaillant]

Builds of linop covering only its architecture-dependent binary
packages and skipping its architecture-independent -doc package (as on
the autobuilders) have been faiing:

 dh_sphinxdoc -a -O--buildsystem=pybuild
  dh_sphinxdoc: Sphinx documentation not found
  make: *** [binary-arch] Error 2

 Could you provide the detailed steps to reproduce this bug. I have
only tested the build locally on my machine via pbuilder prior to
submitting the package and it went fine.

Please arrange to invoke dh --with sphinxdoc only when it would have
something to do.

 Sorry but that does not speak to me either. I followed the most recent
iteration of the Python library style guide
(https://wiki.debian.org/Python/LibraryStyleGuide). Please provide an
example or more verbose explanations regarding the solution you
propose. 

Thanks!

 Cheers,
 Ghis


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#724731: [gdm3] gdm does not start properly, cannot login via gdm

[Ghislain Vaillant]

GDM 3.8 just migrated to unstable and I am also hit by this bug.

A workaround for logging in is to use an alternate logging manager for
now. LightDM did the job well and does not pull a lot of additional
dependencies.

I can't really add anything more to this bug report at this point,
although if you guys need my logs or debug command output, please ask.

Ghislain


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org