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
>
>
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#890364: pybind11-dev: Request migration to unstable

[Ghislain Vaillant]

Hi Shane, thanks for reaching out,

On Wed, 14 Feb 2018 00:48:14 + Shane Loretz  wrote:
> Would the maintainer be willing to migrate 2.2.1 from experimental to
unstable? I'm a user of a distribution based on debian unstable. I have
been using pybind11 from pip previously. The package in experimental
appears to be working flawlessly for my usecase and has some nice new
features not in the version currently in unstable.

There are a few rdpends I have got to test first to guarantee a smooth
upgrade. But yes, I intend to migrate the new version to unstable soon.

Cheers,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Changing maintainer for mpich to debian-hpc

[Ghislain Vaillant]

Can't we have the Debian Science Maintainers just use debian-science@l.d.o
instead of the Alioth address then?

As long as the package continues to be maintained by a motivated packaging
team, I personally have no objection to the transfer you propose.

Cheers,
Ghis

Le 24 janv. 2018 10:01, "Alastair McKinstry"  a
écrit :

> Hi,
>
> I propose to change the Maintainer: for mpich from "Debian Science
> Maintainers" which is an Alioth list, to debian-...@lists.debian.org.
>
> Any comments or objections?
>
> regards
>
> Alastair McKinstry
>
>
> --
> Alastair McKinstry, , ,
> https://diaspora.sceal.ie/u/amckinstry
> Misentropy: doubting that the Universe is becoming more disordered.
>
>
>
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#877316: Forwarded upstream

[Ghislain Vaillant]

Control: forwarded -1 https://github.com/clMathLibraries/clBLAS/issues/321

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881837: Updating the h5py Uploaders list

[Ghislain Vaillant]

Control: tags -1 + fixed pending

On Wed, 15 Nov 2017 18:16:51 +0100 Tobias Frost  wrote:

Source: h5py
Version: 2.6.0-2 2.7.1-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Soeren Sonnenburg  wishes no longer to be uploader of h5py.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.


Done. Soeren Sonnenburg has been removed from the Uploaders list of this 
package.



(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)


I already took over maintenance a while back.

Thanks for your work within the MIA team.

Regards,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#881054: libarrayfire-opencl3: "INTERNAL KERNEL BUILD ERROR" from af::matmulTN

[Ghislain Vaillant]

Hi Ralf,

Based on the content of your report, you are suggesting that the latest 
version (3.5.1 at this very time) would solve the issue you are 
experiencing, am I correct?


Cheers,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#877419: [Help] Exclusion did not worked (Was: Bug#877419: Bug#877700: RM: pandas [arm64 armel armhf mips mips64el mipsel s390x] ...)

[Ghislain Vaillant]

On 14/10/17 07:54, Andreas Tille wrote:

On Fri, Oct 13, 2017 at 08:00:36PM +0200, Andreas Tille wrote:


I might try to pick some of the failed tests from the logs.  I did so
once with kind of iterative uploads for python-cogent package by
checking the logs of the failing architectures.  If you think the proper
way would be to login to each single architecture and build there this
would not fit into my time frame I'm willing to spent on this task.


I treid to approach this by re-using the exclusion mechanism that was
used before (but not activated) in the rules file of pandas[1]:

  
diff --git a/debian/rules b/debian/rules

index 286e36561..186ae36f1 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,17 +24,8 @@ UVER_PYSHORT := $(shell echo $(UVER_PY) | sed -e 
's,+git.*,,g')
  
  MIN_CYTHONVER = 0.23
  
-ifneq ($(DEB_HOST_ARCH),amd64)

-   # obtained by   grep -e 'ERROR:' -e 'FAIL:' pandas-sid.log |awk '{print 
$2;}' | sed -e 's,^test,,g' | tr '\n' '|'
-   # on log of failed tests on mips build box on pandas 0.19.2-1
-   # Majority of them is probably due to a bug in NumPy 
https://github.com/numpy/numpy/issues/8325
-   # of incorrectly treating NaT on non-amd64 platforms
-   # So for stretch release for now disabling those tests on non-amd64
-# plot ones are excluded due to seems to be a bug in matplotlib which 
shows up
-# on s390
-   # EXCLUDE_TESTS_ARCH := --exclude 
'test(_frame_from_json_to_json|_misc_example|ArrayNumpyLabelled|DataFrameNumpyLabelled|_resample_timedelta_values|_timestamp_compare|_where_timedelta|ArrayNumpyExcept|_resample_datetime_values|_NaT_cast|_where_datetime|_where_datetime|_datetimelikes_nan|_value_counts_normalized|_agg_dict_parameter_cast_result_dtypes|_boxplot|_boxplot_vertical|_errorbar_plot|_hist_df|_line_area_stacked|_plot|_round_trip_valid_encodings)'
-# Try without excludes now that we are so much in the future ;)
-   EXCLUDE_TESTS_ARCH :=
+ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH), arm64 armel armhf mips 
mips64el mipsel s390x alpha hppa powerpc ppc64))
+   EXCLUDE_TESTS_ARCH := --exclude 
'test(test_value_counts_normalized|test_resample_timedelta_values|test_resample_datetime_values|test_datetimelikes_nan|test_where_datetime|test_timestamp_compare|test_agg_dict_parameter_cast_result_dtypes|test_NaT_cast|test_where_datetime|test_where_timedelta)'
  else
 EXCLUDE_TESTS_ARCH :=
  endif


Unfortunately this ends up in:

...
pandas_datareader: None
usage: pytest.py [options] [file_or_dir] [file_or_dir] [...]
pytest.py: error: unrecognized arguments: --exclude
   inifile: /<>/setup.cfg
   rootdir: /<>
debian/rules:109: recipe for target 'python-test2.7' failed
...

I confirm that I have not found the --exclude option for pytest.

I'm not that experienced with pytest.  From some short research I had
the idea to quilt patch some "slow" markers for the failing tests and
for the affected architectures ignore those "slow" tests.

Any better technical idea?


Indeed you could use a custom "slow" marker for it. The corresponding 
patch should be upstreamable too if appropriately motivated.


Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#877316: clblas: Crashes on single-precision-only hardware, due to double-precision literals

[Ghislain Vaillant]

Hi Rebecca,

On Sat, 30 Sep 2017 14:47:03 +0100 "Rebecca N. Palmer" 
 wrote:

Package: libclblas2
Version: 2.12-1
Control: tags -1 upstream
Control: affects -1 beignet-opencl-icd

Some clblas operations use '0.0' (a double-precision literal) not '0.0f' 
(a single-precision literal) even when processing single-precision arrays.


This causes it to crash on GPUs that don't support double precision:

ASSERTION FAILED: sel.hasDoubleType()
   at file 
/build/beignet-1.3.1/backend/src/backend/gen_insn_selection.cpp, 
function void 
gbe::ConvertInstructionPattern::convertBetweenFloatDouble(gbe::Selection::Opaque&, 
const gbe::ir::ConvertInstruction&, bool&) const, line 6148


This particular 0.0 appears to have come from 
http://sources.debian.net/src/clblas/2.12-1/src/library/blas/AutoGemm/KernelOpenCL.py/#L368, 
but there may well be more.


This issue also exists in upstream git.


Are you aware of an existing bug filed upstream for this? If so, could 
you link it to this bug report with an appropriate forward comand ?


Otherwise, would you please consider filing the bug upstream, since you 
already triaged it as non Debian specific.


Thanks for investigating this.

Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#871927: forwarded upstream

[Ghislain Vaillant]

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


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#853658: Forwarded upstream

[Ghislain Vaillant]

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870128: libgpuarray: broken autopkgtests

[Ghislain Vaillant]

On Sun, 2017-07-30 at 17:35 +0200, Graham Inggs wrote:
> Can you test your package with mesa-opencl-icd instead of pocl-
> opencl-icd?

mesa-opencl-icd is for devices compatible with amdgpu.

> This will allow the test suite to run on more architectures than only
> amd64 and i386.

Not really, unless all Debian builders are spec'd with semi-recent AMD
graphics or APUs. I suspect this is not the case.

I am afraid the only solution for testing OpenCL packages in a
hardware-neutral way is pocl.

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#870128: libgpuarray: broken autopkgtests

[Ghislain Vaillant]

On Sat, 29 Jul 2017 23:33:21 -0700 Steve Langasek
 wrote:
>
> Your latest upload of libgpuarray has replaced the previous python
> autopkgtest with one based on pocl.

Indeed, which allows running the upstream test suite on our CPU-based
builders. This is better than the default autopkgtest-pkg-python, which
does nothing but testing the import of the Python module.

> Unfortunately, this means that the autopkgtests now consistently fail
> on ci.debian.net, because they can no longer be run on a system without
> a gpu, e.g.:

Your assessment is wrong. pocl is a **CPU** implementation of OpenCL,
so the tests should run in principle. The issue is that the test suite
does not skip tests for which a specific compute must be satisfied by
the environment, such as CUDA and float16. The rest of the tests runs
fine.

I filed the following issues upstream as a result:

https://github.com/Theano/libgpuarray/issues/491
https://github.com/Theano/libgpuarray/issues/492

> ==
> ERROR: pygpu.tests.test_gpu_ndarray.test_asfortranarray((),
'float32', True, True, 1, 'f')
> ---
---
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/nose/case.py", line 197, in
runTest
> self.test(*self.arg)
>   File "/usr/lib/python2.7/dist-packages/pygpu/tests/support.py",
line 44, in f
> func(*args, **kwargs)
>   File "/usr/lib/python2.7/dist-
packages/pygpu/tests/test_gpu_ndarray.py", line 196, in asfortranarray
> assert b.gpudata == gpu.gpudata
>   File "pygpu/gpuarray.pyx", line 2260, in
pygpu.gpuarray.GpuArray.gpudata.__get__ (pygpu/gpuarray.c:28840)
> TypeError: This is for CUDA arrays.
> 
> https://ci.debian.net/packages/libg/libgpuarray/unstable/amd64/
> 
> I would suggest that it's more useful to have a basic autopkgtest
that
> passes on generic hardware than to have a deep autopkgtest which will
never
> succeed there.

The old basic does nothing. For such package, testing whether the
import is successful is hardly testing at all.

> I am filing this bug because failing autopkgtests are considered
blockers
> for inclusion of a package in the Ubuntu release.  Newer versions of
> libgpuarray might not be included in Ubuntu releases until this is
resolved.

I believe this is wrong. How can we provide upstream with meaningful
logs without enabling the tests in the first place? I can keep the old
autopkgtest-pkg-python to satisfy Ubuntu's policy, but what good would
it make?

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#868992: python-ltfatpy: FTBFS on hurd-i386: No module named 'matplotlib._path'

[Ghislain Vaillant]

On Wed, 19 Jul 2017 21:40:57 -0400 "Aaron M. Ucko" 
> Thanks for taking care of #861094.  Alas, the build of python-ltfatpy
> on hurd-i386 (admittedly not a release architecture) is still
failing:
> 
>   E   ModuleNotFoundError: No module named 'matplotlib._path'
> 
> I see that hurd-i386 still just has matplotlib 1.5.x, whereas the
> other architectures have 2.x; please version the build dependencies
on

Upstream versioned matplotlib to 1.4 minimum, and packages in jessie
(matplotlib/1.4.2-3.1) all provide the said matplotlib._path extension
module. So, a versioned dependency should not be necessary (`cme fix`
actually drops it).

It also looks like the hurd-i386 package does ship this extension
module, so the problem is probably somewhere else.

Cheers,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#868991: fixed in packaging VCS

[Ghislain Vaillant]

control: tags -1 + fixed pending

The fix will be rolled in the next iteration of the package.

Thanks Aaron,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#868877: forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/Theano/libgpuarray/issues/481

Thanks for reporting.

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#867987: h5py: FTBFS on sparc64 due to unaliged accesses in test suite

[Ghislain Vaillant]

On Mon, 10 Jul 2017 22:18:53 +0100 James Clarke  wrote:
> Source: h5py
> Version: 2.7.0-1
> Tags: upstream patch
> Forwarded: https://github.com/h5py/h5py/pull/904
> User: debian-sp...@lists.debian.org
> Usertags: sparc64
> X-Debbugs-Cc: debian-sp...@lists.debian.org
> 
> Hi,
> Currently h5py FTBFS on sparc64 (and has done for as long as sparc64 has
> been building packages without nocheck), as the test suite crashes with
> SIGBUS due to unaligned memory accesses. I have submitted a fix upstream
> at the above URL; please include the patch in the Debian package.
> 
> Regards,
> James

It looks like upstream is planning to make a new release soon, so I'll
probably wait for it. Thanks for working on this, James.

Cheers,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Fixed in python-bayespy/0.5.8-1 [Was: Re: python-bayespy_0.5.6-1_amd64.changes REJECTED]

[Ghislain Vaillant]

On Fri, 2017-05-12 at 19:00 +, Thorsten Alteholz wrote:
> Hi,
> 
> 
> at least
>  bayespy-0.5.6/bayespy/inference/vmp/nodes/logistic.py
> should be also mentioned in your debian/copyright.

Thanks for spotting this, Thorsten. As suspected, it turned out to be
an omission from a relicensing effort, which upstream addressed and
made a new release for (version 0.5.8):

https://github.com/bayespy/bayespy/issues/100

Andreas, could you please submit the new version of the packaging
corresponding to the current tip of the packaging repository:

https://anonscm.debian.org/git/debian-science/packages/python-bayespy.git

I already tested on debomatic:

http://debomatic-amd64.debian.net/distribution#unstable/python-bayespy/0.5.8-1

Thanks,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#826457: Forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/sympy/sympy/issues/12619

Forwarded upstream. Next time, please consider filing feature requests
directly to the upstream bug tracker.

Thanks,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#824073: Marked as wontfix

[Ghislain Vaillant]

control: tags -1 wontfix

I am marking your request as "wontfix" for the following reasons:

- This bug does not affect src:sympy anymore, since the missing
galgebra module is unlikely to reappear in a future release.

- If a new source package were to be introduced for galgebra, an ITP or
RFP bug would have to be filed instead.

- The separately maintained galgebra project is not registered on PyPI
and is yet to have an official release, which makes its suitability for
inclusion and maintenance in Debian questionable.

Moving forward, you could talk with the upstream developer of galgebra
to provide stable releases on PyPI, tagged releases on GitHub, or both.
Once this is done, file an ITP and work on the packaging if you feel
like it, or file an RFP to request for someone else to do so.

Best regards,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#822296: Forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/spyder-ide/spyder/issues/4423

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861095: python-ltfatpy: FTBFS: ValueError: Little-endian buffer not supported

[Ghislain Vaillant]

Thanks for breaking this issues down. Forwarding upstream.

On Mon, 24 Apr 2017 11:55:24 -0400 "Aaron M. Ucko"  wrote:

Source: python-ltfatpy
Version: 1.0.8-1
Severity: important
Justification: fails to build from source

The builds of python-ltfatpy for s390x and the non-release
architectures ppc64 and sparc64 failed with

E   ValueError: Little-endian buffer not supported on big-endian compiler

You can find the full s390x log at

https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=s390x=1.0.8-1=1492853102=0#

The builds for the big-endian non-release architectures m68k and
powerpcspe both nominally succeeded, but AFAICT only because they
skipped the test suite altogether for some reason.

Could you please take a look?

Thanks!

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#861094: python-ltfatpy: FTBFS (32-bit): TypeError: dim should be an integer

[Ghislain Vaillant]

Thanks for breaking this issues down. Forwarding upstream.

On Mon, 24 Apr 2017 11:51:25 -0400 "Aaron M. Ucko"  wrote:

Source: python-ltfatpy
Version: 1.0.8-1
Severity: important
Justification: fails to build from source

Builds of python-ltfatpy for 32-bit architectures such as i386 failed
because most (all?) tests didn't care for dim's type:

if (not isinstance(dim, six.integer_types) and
   not isinstance(dim, np.int_)):
>   raise TypeError("dim should be an integer.")
E   TypeError: dim should be an integer.

You can find the full i386 log at
https://buildd.debian.org/status/fetch.php?pkg=python-ltfatpy=i386=1.0.8-1=1492853191=0

The builds for the 32-bit non-release architectures m68k and
powerpcspe both nominally succeeded, but AFAICT only because they
skipped the test suite altogether for some reason.

Could you please take a look?

Thanks!

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu




--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#859080: Forwarded to proposed PR

[Ghislain Vaillant]

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844601: reassigned to python-qtawesome

[Ghislain Vaillant]

control: reassign -1 src:python-qtawesome
control: fixed -1 src:python-qtawesome/0.4.4
control: affects -1 src:spyder

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#854502: No longer blocked by #854692

[Ghislain Vaillant]

control: unblock -1 by 854692

Upstream provided a fix for the gcc-6 LTO regression affecting the
build of pybind11. As a result, I am removing the block relationship.

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#854502: Blocked by #854692

[Ghislain Vaillant]

control: block -1 by 854692

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848634: python-cartopy: FTBFS on *i386: test_lambert_azimuthal_equal_area fails

[Ghislain Vaillant]

control: reassign -1 src:proj

Reassigning this bug to src:proj, following Aaron's investigation.


On Thu, 26 Jan 2017 11:34:40 -0500 u...@debian.org (Aaron M. Ucko) wrote:
> Ghislain Vaillant <ghisv...@gmail.com> writes:
> 
> > So, you think it would help to request src:proj to be build with 
> > -ffloat-store then?
> 
> Yes; testing in a personal chroot confirms that adjusting its build
> settings is both necessary and sufficient.  (I don't recommend turning
> this flag on blindly.)
> 
> diff --git a/debian/rules b/debian/rules
> index ad58979..ab7da14 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -24,6 +24,11 @@ CFLAGS=$(shell dpkg-buildflags --get CFLAGS)
>  ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
>  CFLAGS += -g
>  endif
> +
> +ifneq (,$(filter i386-%,$(DEB_HOST_MULTIARCH)))
> +CFLAGS += -ffloat-store
> +endif
> +
>  # `nostrip' handled by dh_strip...
> 
>  CFLAGS += -I$(JAVA_HOME)/include/linux
> 
> -- 
> Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
> http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848634: python-cartopy: FTBFS on *i386: test_lambert_azimuthal_equal_area fails

[Ghislain Vaillant]

On Thu, 2017-01-26 at 10:41 -0500, Aaron M. Ucko wrote:
> Ghislain Vaillant <ghisv...@gmail.com> writes:
> 
> > I tried your suggestion out but it did not work on a test build in
> > debomatic. The same errors are reported at the test stage.
> 
> I'm sorry to hear that.  In that case, the calculations affected by the
> lack of -ffloat-store are presumably taking place in some underlying
> library; I particularly suspect proj4.

So, you think it would help to request src:proj to be build with 
-ffloat-store then?

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844601: forwarded to new upstream bug

[Ghislain Vaillant]

control: forwarded -1 https://github.com/spyder-ide/spyder/issues/4049

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844601: forwarded upstream

[Ghislain Vaillant]

control: forwarded -1 https://github.com/spyder-ide/spyder/issues/4014

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#732949: spyder: Internal console spamming

[Ghislain Vaillant]

On Mon, 23 Dec 2013 00:27:56 +0100 =?utf-8?q?=C3=89lie_Gouzien?= 
 wrote:
> Package: spyder
> Version: 2.1.10-2
> Severity: important

This version is now significantly outdated. Could you please verify
whether the issue is still happening on one of the recent versions
being packaged (3.1.2 at the time of writing).

 
> When there is an internal error in spyder, the error shows up and the cursor
> move to it. De-selecting the internal console from the display menu changes
> nothing.
> If for developers it's good, it turns to be a plague for users: if there is a
> recurrent error for any reason (even a "negligeable" error) you are disturbed
> every time a message shows up and have to go back to the line you were editing
> (which mean we have to take the mouse).
> 
> In my case I do have the following error:
> 
> File "/usr/lib/python2.7/dist-packages/spyderlib/widgets/editor.py", line 228,
> in update_queue
> end_callback = self.end_callbacks.pop(id(thread))
> KeyError: 67235920
> 
> and it shows up every 10 s. Working with spyder turns to be impossible with
> it.
> 
> A (according to me) better behavior would be:
> -When you do activate the internal console, errors show up like it is doing 
> now
> -When you do not activate the internal console, it never shows up.

I cannot reproduce this on the new version.

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#851162: forwarded upstream

[Ghislain Vaillant]

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Ghislain Vaillant]

On Thu, 2017-01-12 at 12:27 +, James Cowgill wrote:
> Hi,
> 
> On 12/01/17 12:11, Ghislain Vaillant wrote:
> > On Wed, 11 Jan 2017 11:37:47 +0100 Jochen Sprickerhof <jspri...@debian.org> 
> > wrote:
> > > Package: libfreeimage3
> > > Followup-For: Bug #850027
> > > 
> > > Hi,
> > > 
> > > is there anything I can do to speed this up? Would be nice to get rviz 
> > > back ;).
> > > 
> > > Cheers Jochen
> > 
> > I now have very limited time for this and there is yet to be a
> > definitive agreement on how to proceed.
> > 
> > I believe Anton proposed to upload to experimental first, test
> > the rdepends and attempt a transition to unstable, although time may be
> > short.
> > 
> > Another solution could be to just make the upload to unstable, monitor
> > the autopkgtests of the rdepends and cross our fingers? I don't know.
> 
> Most packages don't have autopkgtests so manual testing is going to be
> required anyway.
> 
> I think you should just upload it to unstable. Experimental is useful if
> you want to test the rdeps, but if you do not have a lot of time then
> unstable is better since other people will test it a lot more.
> 
> > You guys have much more experience than I have so you are in a better
> > position to advise and act, I guess.
> > 
> > Please CC me in the future as I am not automatically subscribed for
> > some reason.
> 
> Unfortunately uploaders don't get automatically subscribed to the BTS (I
> think that should be improved at some point). To subscribe manually, go
> to this page and hit "Subscribe" in the top-right corner:
> https://tracker.debian.org/pkg/freeimage
> 
> Thanks,
> James

If there is no objections by the end of the day, I will prepare an
upload to unstable with James' patch.

Cheers,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Ghislain Vaillant]

On Wed, 11 Jan 2017 11:37:47 +0100 Jochen Sprickerhof  
wrote:
> Package: libfreeimage3
> Followup-For: Bug #850027
> 
> Hi,
> 
> is there anything I can do to speed this up? Would be nice to get rviz back 
> ;).
> 
> Cheers Jochen

I now have very limited time for this and there is yet to be a
definitive agreement on how to proceed.

I believe Anton proposed to upload to experimental first, test
the rdepends and attempt a transition to unstable, although time may be
short.

Another solution could be to just make the upload to unstable, monitor
the autopkgtests of the rdepends and cross our fingers? I don't know.

You guys have much more experience than I have so you are in a better
position to advise and act, I guess.

Please CC me in the future as I am not automatically subscribed for
some reason.

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Ghislain Vaillant]

I believe it is worth trying, since neither the situation before nor 
after freeimage 3.17.0+ds1-4 is ideal. Before, a set of plugins were no 
longer loaded correctly (#841089) and after, the API was somewhat 
changed (because of the dummy node introduced by the updated patch).


Besides, I am now wondering whether we actually did a rebuild of all 
rdepends with 3.17.0+ds1-4?


Ghis


On 08/01/17 12:26, Anton Gladky wrote:

Hmm, I would then make an upoad to experimental first,
build all depends against this new version to detect
possible FTBFS and then upload to sid.

Not sure, whether we have enough time for now.

Cheers

Anton


2017-01-08 11:16 GMT+01:00 Ghislain Vaillant <ghisv...@gmail.com>:

On Thu, 5 Jan 2017 21:57:53 + James Cowgill <jcowg...@debian.org> wrote:


Control: block 849696 by -1
Control: tags -1 patch

Hi,

This is of course the same bug as #849696 in OGRE, but I still think it
should be fixed in freeimage.

I'd like to propose this patch (a new version of
Disable-vendored-dependencies.patch is also attached):


https://anonscm.debian.org/cgit/users/jcowgill/freeimage.git/commit/?h=bug-850027=b5f51dbe600e475a6bfc8e0f52335136b57ca123

My patch reverts the one applied in #841089 which broke the API, and
instead of removing the G3 plugin, it includes a G3 plugin which does
nothing (trying to load a G3 file will always fail). The advantage of
this is that the API is identical to upstream and it should also fix
the issue in #841089 as well.



I like this. I'll roll an update in the next few days.

Thanks to everyone who were involved.

Ghis


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Ghislain Vaillant]

On Thu, 5 Jan 2017 21:57:53 + James Cowgill  wrote:

Control: block 849696 by -1
Control: tags -1 patch

Hi,

This is of course the same bug as #849696 in OGRE, but I still think it
should be fixed in freeimage.

I'd like to propose this patch (a new version of
Disable-vendored-dependencies.patch is also attached):

https://anonscm.debian.org/cgit/users/jcowgill/freeimage.git/commit/?h=bug-850027=b5f51dbe600e475a6bfc8e0f52335136b57ca123

My patch reverts the one applied in #841089 which broke the API, and
instead of removing the G3 plugin, it includes a G3 plugin which does
nothing (trying to load a G3 file will always fail). The advantage of
this is that the API is identical to upstream and it should also fix
the issue in #841089 as well.


I like this. I'll roll an update in the next few days.

Thanks to everyone who were involved.

Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#850027: libfreeimage3: freeimage 3.17.0+ds1-4 makes rviz unusable

[Ghislain Vaillant]

Hi Erik, thanks for reporting this issue,

freeimage/3.17.0+ds1-4 fixed an issue with the patch used to remove the
vendored dependencies and use the system one instead. See #841089 [1].

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

The updated patch introduces a null-node for plugins which have been
disabled (here the G3 fax format). Before this patch, all nodes stored
in the plugin map were guaranteed to be non-null but all plugins with
IDs over FIF_FAXG3 were wrongly indexed.

A fix for your issue in rviz would be to filter the plugin map from
non-null nodes prior to registering the codecs.

Hope this helps,
Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848771: numexpr: FTBFS: Test failures

[Ghislain Vaillant]

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

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#848634: python-cartopy: FTBFS on *i386: test_lambert_azimuthal_equal_area fails

[Ghislain Vaillant]

control: forwarded -1 https://github.com/SciTools/cartopy/issues/799

This issue is already forwarded upstream and was recently pinged for
update.

I would not hold my breath though , as upstream has not been responsive
to any requests / questions I have raised so far. We shall see.

Ghis

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844403: src:nfft: FTBFS on ppc64el

[Ghislain Vaillant]

On Mon, 12 Dec 2016 13:09:10 -0200 Breno Leitao  wrote:

> Sure.  Since the problem is only related to long double, you can bypass
> either all the tests on ppc64el, or, disable long double on ppc64el and keep
> the tests. Either way it should work.

In fact, I came up with a better solution. Just disable the tests for long on
ppc64el.

Let me know if it works for you.

Thank you,
Breno


Yes I was about to do the same. I'll teak your patch slightly to handle 
powerpc as well, since it suffers from the same problem as ppc64el.


Thanks for your contribution. Let me know if a long-term solution comes 
up later.


Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844403: src:nfft: FTBFS on ppc64el

[Ghislain Vaillant]

On Mon, 28 Nov 2016 11:24:27 -0200 Breno Leitao <bren...@br.ibm.com> wrote:

On 11/27/2016 07:16 PM, Ghislain Vaillant wrote:
> On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitao <bren...@br.ibm.com> wrote:
>> I am looking at this issue, and the first test set is checkall.
>>
>> If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run
>> it isolated, I see no errors, as showed:
>>
>>   $ ./checkall 2>&1 | grep -i fail
>>   $
>>
>> Looking all tests I see "-> OK". Anyway, I am continue to debug what is the
>> problem here.
>
> It could be a lucky shot. Have you tried running them multiple times?

Yes, and it works, but it fails when running in multi thread mode. Anyway, I
am able to reproduce the problem here.


Ack.



> If you look carefully at the log you will find that some tests have an
> unrealistically low tolerance value (in the order of 1E-322), which make them
> succeed when the difference is exactly 0 and fail otherwise.

That is interesting, Float precision might be a platform characterstic,
mainly if using long double, or, quad float precision.

Anyway, I will go deeper in the code to understand the problem here.


I might eventually just bypass testing for ppc64el to let the package 
transition to testing, unless you think you are gonna have a fix ready 
very soon. With the transition window extended to 10 days and the 
soft-freeze deadline happening, I cannot wait for very much longer.


Please keep me up-to-date, and thanks for investigating.

Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#838908: awaiting version 3.4.2

[Ghislain Vaillant]

This is currently on hold due to upstream working on the last hotfix 
update of the 3.4.x series. It is scheduled for Dec. 5th.


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844403: src:nfft: FTBFS on ppc64el

[Ghislain Vaillant]

On Thu, 24 Nov 2016 18:49:29 -0200 Breno Leitao  wrote:

I am looking at this issue, and the first test set is checkall.

If I run it inside dpkg-buildpackage, it fails as in the log, but, if I run
it isolated, I see no errors, as showed:

  $ ./checkall 2>&1 | grep -i fail
  $

Looking all tests I see "-> OK". Anyway, I am continue to debug what is the
problem here.


It could be a lucky shot. Have you tried running them multiple times?

If you look carefully at the log you will find that some tests have an 
unrealistically low tolerance value (in the order of 1E-322), which make 
them succeed when the difference is exactly 0 and fail otherwise.


The other tests have an adequate tolerance value set (1E-16). I don't 
know enough about the codebase to tell you why these tolerances are 
different, but that's probably where the issue is. I would expect all 
tolerances to be in the same order (1E-16).


Cheers,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#836599: RE: Bug#836599: shark: FTBFS on mips/mipsel: test errors

[Ghislain Vaillant]

On Tue, 18 Oct 2016 11:36:52 + Dejan Latinovic 
 wrote:

Control: tags -1 + patch
Control: user -1 debian-m...@lists.debian.org
Control: usertags -1 mips-patch


Hi Ghislain,

I have updated the patch that reduces optimization level with requested 
information, Fix-build-on-MIPS.patchý.
Do you want me to add anything else?

Maybe it would be enough to apply only this patch, as the second one was needed 
for
one of my local machines that may have lower performance than Debian's build 
servers.

I will monitor the status of reported issues and ask for patch removal when the 
time comes.


Regards,
Dejan



I have applied your patch and launched a test build on debomatic [1].

The good news is that it indeed fixes the build, but a few tests do 
timeout, including the one you mentioned:


The following tests FAILED:
 60 - Trainers_LinearSvmTrainer (Timeout)
139 - ObjFunct_NegativeLogLikelihood (Timeout)
140 - ObjFunct_SvmLogisticInterpretation (Timeout)

I'll mark them as slow and push the update. Hopefully this should be 
enough to fix this FTBFS bug.


Thanks again for working on this.

[1] 
http://debomatic-mips.debian.net/distribution#unstable/shark/3.1.3+ds1-2/buildlog


Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#845279: freeimage FTCBFS: uses build architecture compiler and pkg-config

[Ghislain Vaillant]

Hi Helmut,

Thanks for looking into this issue with cross-compilation. I'll prepare 
an upload with your patch + fix for #841089 soon.


Cheers,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#841089: Bug and patch acknowledged

[Ghislain Vaillant]

Hi Boris,

Thanks for looking into this issue with the FreeImage plugins.

Your explanation makes sense and I should have probably looked more 
carefully at the details of the patch when cherry-picking this from the 
Fedora packaging.


I'll find some time to try out your patch and roll it out with the next 
iteration of the package. I might also try to break the large 
Disabled-vendored-dependencies.patch patch into individual per-pulgin 
patches to help with future maintenance work.


Your work will be duly acknowledged of course.

Best regards,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#844008: src:clsparse: FTBFS on ppc64el

[Ghislain Vaillant]

tag -1 pending
thanks

On Mon, 14 Nov 2016 17:37:52 -0200 Fernando Seiti Furusato 
 wrote:

Source: clsparse
Followup-For: Bug #844008

I have created a patch that basically undefines "bool" and "vector" as
macros, because it is how they come from altivec.h.
I have tested this on ppc64el and amd64.

Regards.


I will apply your patch and submit a new version. Thanks for looking 
into it.


Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Typo in Changelog

[Ghislain Vaillant]

On 12/10/16 06:41, Salvatore Bonaccorso wrote:

Hi,

On Tue, Oct 11, 2016 at 07:20:47PM +, Ghislain Antony Vaillant wrote:

   [ Ghislain Antony Vaillant ]
   * Fix CVE-2016-5864: apply patch from wheezy-security.
 Thanks to Salvatore Bonaccorso, Balint Reczey and Chris Lamb
 (Closes: #839827)


There is a typo in the CVE ID. Can you please fix that in the
packaging repo so that it will be fixed in a future upload?

CVE-2016-5684.

Thanks for your work,

Regards,
Salvatore


My bad, silly mistake on my end. Thanks for reporting.

Ghis


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#539975: tagged as wontfix

[Ghislain Vaillant]

control: tag -1 wontfix

Debian now has automatic debug packages so a separate -dbg package is
no longer necessary.

Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#836413: forwarded upstream

[Ghislain Vaillant]

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

Thanks for monitoring this package Aaron. This issue has been forwarded
upstream.

Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Comments regarding python-vispy_0.4.0-1_i386.changes

[Ghislain Vaillant]

On 02/07/16 16:40, Chris Lamb wrote:

please check vispy/util/svg/geometry.py (and maybe a few others, I stopped 
looking)
/lamby


This is covered by:

Files: vispy/util/svg/*
Copyright: 2013 Nicolas P. Rougier
License: BSD-2-Clause

All these files have the original copyright of the C++ library at the
top, like here:

Anti-Grain Geometry (AGG) - Version 2.5
A high quality rendering engine for C++
Copyright (C) 2002-2006 Maxim Shemanarev
Contact: mcs...@antigrain.com
 mcseem...@yahoo.com
 http://antigrain.com

but the actual translation to Python is copyright Nicolas Rougier. So I
believe it should be the latter that counts. Not sure why the C++
copyright was added.

Let me know whether I am correct,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: python-vispy_0.4.0-1_i386.changes REJECTED

[Ghislain Vaillant]

On 17/06/16 12:59, Ghislain Vaillant wrote:

Hi Chris, thanks for looking in my package.

Please find my comments below:

On 16/06/16 20:00, Chris Lamb wrote:


please clarify twitter.js,


Which file are you referring to? I have:


find . -name *.js

./debian/missing-sources/bootstrap.js
./debian/missing-sources/vispy.js
./debian/missing-sources/jquery.mousewheel.js
./vispy/html/static/js/webgl-backend.js
./vispy/html/static/js/vispy.min.js
./vispy/html/static/js/jquery.mousewheel.min.js

Hang on, ./debian/missing-sources/bootstrap.js is not needed. If that
was the one you had in mind, good catch !


vispy/ext/png.py.. in fact, everything under ext/ - I stopped looking
after that. :)


vispy/ext/* contains mostly vendored dependencies. They are all
acknowledged in d/copyright.

I have not investigated the possibility of removing them now because
vispy 0.5.x (next stable release) will be able to use the system ones
when available. Therefore, I don't think it is worth the effort.

Let me know whether you have further comments or actions required.

Best regards,
Ghis


I have submitted a new version on mentors at:

https://mentors.debian.net/debian/pool/main/p/python-vispy/python-vispy_0.4.0-1.dsc

which fixes the unneeded missing-source for bootstrap.js.

Could Fred upload the package and then Chris resume his review please?

Cheers,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: python-vispy_0.4.0-1_i386.changes REJECTED

[Ghislain Vaillant]

Hi Chris, thanks for looking in my package.

Please find my comments below:

On 16/06/16 20:00, Chris Lamb wrote:


please clarify twitter.js,


Which file are you referring to? I have:

>>> find . -name *.js
./debian/missing-sources/bootstrap.js
./debian/missing-sources/vispy.js
./debian/missing-sources/jquery.mousewheel.js
./vispy/html/static/js/webgl-backend.js
./vispy/html/static/js/vispy.min.js
./vispy/html/static/js/jquery.mousewheel.min.js

Hang on, ./debian/missing-sources/bootstrap.js is not needed. If that
was the one you had in mind, good catch !


vispy/ext/png.py.. in fact, everything under ext/ - I stopped looking after 
that. :)


vispy/ext/* contains mostly vendored dependencies. They are all
acknowledged in d/copyright.

I have not investigated the possibility of removing them now because
vispy 0.5.x (next stable release) will be able to use the system ones
when available. Therefore, I don't think it is worth the effort.

Let me know whether you have further comments or actions required.

Best regards,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: hdf-compass_0.6.0b5-1_amd64.changes is NEW

[Ghislain Vaillant]

Could you guys hold off the review  upload. I still need to sort something
out with the d-python team.

Many thanks,
Ghis
Le 15 mai 2016 07:33, "Debian FTP Masters" 
a écrit :

> binary:hdf-compass is NEW.
> binary:python-hdf-compass is NEW.
> source:hdf-compass is NEW.
>
> Your package has been put into the NEW queue, which requires manual action
> from the ftpteam to process. The upload was otherwise valid (it had a good
> OpenPGP signature and file hashes are valid), so please be patient.
>
> Packages are routinely processed through to the archive, and do feel
> free to browse the NEW queue[1].
>
> If there is an issue with the upload, you will receive an email from a
> member of the ftpteam.
>
> If you have any questions, you may reply to this email.
>
> [1]: https://ftp-master.debian.org/new.html
>
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Comments regarding pyfr_1.3.0-1_amd64.changes

[Ghislain Vaillant]

On 18/04/16 11:02, Chris Lamb wrote:

Please check (at least) doc/ext/tikz.py




Indeed, I missed that file (BSD-2-Clause). Double-checked the output of
licensecheck and I could not find any other files that slipped under my
radar. I'll update the packaging accordingly.

Thanks for spotting this and reporting.

Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Comments regarding python-arrayfire_3.3.20160328-1_amd64.changes

[Ghislain Vaillant]

Hi Chris,

On 03/04/16 09:06, Chris Lamb wrote:

Check examples/financial/heston_model.py etc for next upload please


Thanks for spotting this. I forgot to scan for new files when rebasing
the packaging on top of the latest release.

Is that something I can address with a subsequent iteration of the
package (python-arrayfire/3.3.20160328-2), or does it have to be
addressed for the initial upload? I would prefer the former, since I
won't have to retag the packaging repository.

Please let me know,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Regarding VTK 7.0.0

[Ghislain Vaillant]

I will try to find some time to send an email around to the team this
weekend.

Cheers,
Ghis

On 23/02/16 14:28, Elvis Stansvik wrote:

2016-02-04 15:41 GMT+01:00 Ghislain Vaillant <ghisv...@gmail.com
<mailto:ghisv...@gmail.com>>:

It is next on my TODO list, I had a bunch of RCs to clear out before.

I will soon be contacting the VTK 6 maintainers to coordinate our
efforts towards VTK 7.


Hi again Ghislain,

I'm just curious if you've had any time to work on this yet?

Cheers,
Elvis


Cheers,
Ghis


On 04/02/16 14:28, Anton Gladky wrote:

Hi Elvis,

we discussed it a couple of days ago with other people,
interested in it VTK7 (CC-ing them). We are not sure, whether
vtk7 can coexist with vtk6 without conflicts. From my
POV, it is a little bit late to start a large transition process.
So, if both of those versions can coexist - no problems.
if not - we should wait.

I am personally will unlikely have time in a near couple of months
for vtk7. So if somebody is ready to work on it - I will provide any
possible help and, if needed, sponsoring.

Best regards

Anton

2016-02-04 14:11 GMT+01:00 Elvis Stansvik
<elvis.stans...@orexplore.com <mailto:elvis.stans...@orexplore.com>
<mailto:elvis.stans...@orexplore.com
<mailto:elvis.stans...@orexplore.com>>>:

 Hi all,

 Just wanted to ask if VTK 7.0.0 is being packaged for
Debian, and if
 so, when it might turn up?

 Now that VTK supports Python 3, will there be a
python3-vtk7 package?

 Thanks for all the great packaging work.

 Best regards,
 Elvis

 --
 debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
<mailto:debian-science-maintainers@lists.alioth.debian.org>
 <mailto:debian-science-maintainers@lists.alioth.debian.org
<mailto:debian-science-maintainers@lists.alioth.debian.org>>

http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers





--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

shark_3.0.1+ds1-1 ready for upload

[Ghislain Vaillant]

On 10/02/16 16:13, Ghislain Vaillant wrote:

On 05/02/16 23:00, Thorsten Alteholz wrote:


Hi Ghislain,

please mention the BSD license of doc/* in your debian/copyright.

Thanks!
  Thorsten

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



This is now fixed in the new version available on mentors.

   http://mentors.debian.net/debian/pool/main/s/shark/shark_3.0.1+ds1-1.dsc

A successful build log on debomatic is available here:


http://debomatic-amd64.debian.net/distribution#unstable/shark/3.0.1+ds1-1/buildlog


Thanks,
Ghis



Hi Andreas,

Just bumping this up in case you did not receive it. I saw your post
about your email problems.

Thanks for taking care of the re-upload.

Best regards,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: shark_3.0.1+ds1-1_amd64.changes REJECTED

[Ghislain Vaillant]

On 05/02/16 23:00, Thorsten Alteholz wrote:


Hi Ghislain,

please mention the BSD license of doc/* in your debian/copyright.

Thanks!
  Thorsten

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.



This is now fixed in the new version available on mentors.

  http://mentors.debian.net/debian/pool/main/s/shark/shark_3.0.1+ds1-1.dsc

A successful build log on debomatic is available here:


http://debomatic-amd64.debian.net/distribution#unstable/shark/3.0.1+ds1-1/buildlog

Thanks,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: shark_3.0.1+ds1-1_amd64.changes REJECTED

[Ghislain Vaillant]

On 05/02/16 23:00, Thorsten Alteholz wrote:


Hi Ghislain,

please mention the BSD license of doc/* in your debian/copyright.

Thanks!
  Thorsten

===

Please feel free to respond to this email if you don't understand why
your files were rejected, or if you upload new files which address our
concerns.


Hi Thorsten,

Thanks for spotting this. Indeed there were some Sphinx code in the
docs which were BSD licensed. This is now rectified.

Looking back on the packaging, I have realised that it was not
completely finalised feature-wise, specifically the support for HDF5
and CBLAS. Work is on-going to get that done.

I'll confirm the build on debomatic first, and then ask Andreas to
re-submit.

My apologize for not landing that one perfectly the first time around.

Best regards to you both,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Your nfft upload to unstable

[Ghislain Vaillant]

On 07/02/16 18:13, Jonathan Wiltshire wrote:

On 2016-02-07 17:47, Jonathan Wiltshire wrote:

Hi,

On 2016-02-03 you uploaded nfft 3.3.0-5 to unstable triggering a
transition. The reverse dependencies are pynfft and yorick-ynfft.

This is not an issue in itself, because that's quite a manageable
transition and you staged it in experiemental first.

However, you found FTBFS bugs in both packages whilst nfft was in
experimental and filed bugs for them. It's not OK to then ignore those
bugs
and upload nfft to unstable anyway.


This said, you got clearance to upload in #813019 which I've just found,
so you aren't really to blame for this. Still, it's a pity the
transition cannot proceed.


Hi Jonathan,

I am very sorry that my first transition did not meet your expectations.

Indeed, I believe I've followed the right steps highlighted on the wiki 
and eventually got clearance for an upload, or so it seemed.


I am actively working on fixing pynfft. For yorick-nfft however, the
package has proven to be more resistant to simple API fixes, for which
only the package maintainer may actually provide a solution.

I take due notes of your remarks on where things got sideways and will
make sure this does not happen again for my next transitions.

Best regards,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Re: Regarding VTK 7.0.0

[Ghislain Vaillant]

It is next on my TODO list, I had a bunch of RCs to clear out before.

I will soon be contacting the VTK 6 maintainers to coordinate our
efforts towards VTK 7.

Cheers,
Ghis


On 04/02/16 14:28, Anton Gladky wrote:

Hi Elvis,

we discussed it a couple of days ago with other people,
interested in it VTK7 (CC-ing them). We are not sure, whether
vtk7 can coexist with vtk6 without conflicts. From my
POV, it is a little bit late to start a large transition process.
So, if both of those versions can coexist - no problems.
if not - we should wait.

I am personally will unlikely have time in a near couple of months
for vtk7. So if somebody is ready to work on it - I will provide any
possible help and, if needed, sponsoring.

Best regards

Anton

2016-02-04 14:11 GMT+01:00 Elvis Stansvik >:

Hi all,

Just wanted to ask if VTK 7.0.0 is being packaged for Debian, and if
so, when it might turn up?

Now that VTK supports Python 3, will there be a python3-vtk7 package?

Thanks for all the great packaging work.

Best regards,
Elvis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org


http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers




--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#742560: freeimage: diff for NMU version 3.17.0+ds1-1.1

[Ghislain Vaillant]

I was about to submit an update for the reproducibility problem. I can 
prepare a proper update with your patch in it.


How does that sound?

Ghis


On Fri, 22 Jan 2016 06:33:52 +0100 Tobias Frost  wrote:

Control: tags 742560 + patch
Control: tags 742560 + pending

Dear maintainer,

I've prepared an NMU for freeimage (versioned as 3.17.0+ds1-1.1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru freeimage-3.17.0+ds1/debian/changelog 
freeimage-3.17.0+ds1/debian/changelog
--- freeimage-3.17.0+ds1/debian/changelog   2016-01-18 08:33:50.0 
+0100
+++ freeimage-3.17.0+ds1/debian/changelog   2016-01-22 06:12:59.0 
+0100
@@ -1,3 +1,10 @@
+freeimage (3.17.0+ds1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with libpng16 to help preparing the libpng16 transition.
+
+ -- Tobias Frost   Fri, 22 Jan 2016 06:12:17 +0100
+
 freeimage (3.17.0+ds1-1) unstable; urgency=medium

   * Move from experimental to unstable.
diff -Nru freeimage-3.17.0+ds1/debian/patches/libpng16.patch 
freeimage-3.17.0+ds1/debian/patches/libpng16.patch
--- freeimage-3.17.0+ds1/debian/patches/libpng16.patch  1970-01-01 
01:00:00.0 +0100
+++ freeimage-3.17.0+ds1/debian/patches/libpng16.patch  2016-01-22 
06:10:39.0 +0100
@@ -0,0 +1,34 @@
+--- a/Source/FreeImage/PluginPNG.cpp
 b/Source/FreeImage/PluginPNG.cpp
+@@ -713,11 +713,19 @@
+
+   if (png_get_valid(png_ptr, info_ptr, PNG_INFO_iCCP)) {
+   png_charp profile_name = NULL;
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  png_bytepp profile_data = NULL;
++#else
+   png_charp profile_data = NULL;
++#endif
+   png_uint_32 profile_length = 0;
+   int  compression_type;
+
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  png_get_iCCP(png_ptr, info_ptr, _name, 
_type, profile_data, _length);
++#else
+   png_get_iCCP(png_ptr, info_ptr, _name, 
_type, _data, _length);
++#endif
+
+   // copy ICC profile data (must be done after 
FreeImage_AllocateHeader)
+
+@@ -1000,7 +1008,11 @@
+
+   FIICCPROFILE *iccProfile = FreeImage_GetICCProfile(dib);
+   if (iccProfile->size && iccProfile->data) {
++#if PNG_LIBPNG_VER_MAJOR >= 1 && PNG_LIBPNG_VER_MINOR >= 4
++  //png_set_iCCP(png_ptr, info_ptr, "Embedded Profile", 
0, (png_const_bytep)iccProfile->data, iccProfile->size);
++#else
+   png_set_iCCP(png_ptr, info_ptr, "Embedded Profile", 
0, (png_charp)iccProfile->data, iccProfile->size);
++#endif
+   }


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#742560: freeimage: diff for NMU version 3.17.0+ds1-1.1

[Ghislain Vaillant]

The patch does not cleanly apply:

--
Applying patch libpng16.patch
patching file Source/FreeImage/PluginPNG.cpp
Hunk #1 FAILED at 713.
Hunk #2 FAILED at 1000.
2 out of 2 hunks FAILED -- rejects in file Source/FreeImage/PluginPNG.cpp
Patch libpng16.patch does not apply (enforce with -f)
--

Also, looking at the patch, what are the rationales behind commenting 
out the call to png_set_iCPP but not png_get_iCPP for libpng 1.4+?


Could you also point use to the Fedora patch this is taken from for 
reference?


Many thanks,
Ghis


On Mon, 25 Jan 2016 15:10:58 +0100 Anton Gladky <gl...@debian.org> wrote:

Thanks, Tobias, for the patch and NMU.
I have pushed your changes to ou git.

Ghis, if you have a fixed reproducibility, please push it
to git and I will upload a new version with both changes.

Regards

Anton

2016-01-25 14:57 GMT+01:00 Ghislain Vaillant <ghisv...@gmail.com>:

> I was about to submit an update for the reproducibility problem. I can
> prepare a proper update with your patch in it.
>
> How does that sound?
>
> Ghis
>
>
>
> On Fri, 22 Jan 2016 06:33:52 +0100 Tobias Frost <t...@debian.org> wrote:
>
>> Control: tags 742560 + patch
>> Control: tags 742560 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for freeimage (versioned as 3.17.0+ds1-1.1) and
>> uploaded it to DELAYED/7. Please feel free to tell me if I
>> should delay it longer.
>>
>> Regards.
>> diff -Nru freeimage-3.17.0+ds1/debian/changelog
>> freeimage-3.17.0+ds1/debian/changelog
>> --- freeimage-3.17.0+ds1/debian/changelog   2016-01-18
>> 08:33:50.0 +0100
>> +++ freeimage-3.17.0+ds1/debian/changelog   2016-01-22
>> 06:12:59.0 +0100
>> @@ -1,3 +1,10 @@
>> +freeimage (3.17.0+ds1-1.1) UNRELEASED; urgency=medium
>> +
>> +  * Non-maintainer upload.
>> +  * Fix FTBFS with libpng16 to help preparing the libpng16 transition.
>> +
>> + -- Tobias Frost <t...@debian.org>  Fri, 22 Jan 2016 06:12:17 +0100
>> +
>>  freeimage (3.17.0+ds1-1) unstable; urgency=medium
>>
>>* Move from experimental to unstable.
>> diff -Nru freeimage-3.17.0+ds1/debian/patches/libpng16.patch
>> freeimage-3.17.0+ds1/debian/patches/libpng16.patch
>> --- freeimage-3.17.0+ds1/debian/patches/libpng16.patch  1970-01-01
>> 01:00:00.0 +0100
>> +++ freeimage-3.17.0+ds1/debian/patches/libpng16.patch  2016-01-22
>> 06:10:39.0 +0100
>> @@ -0,0 +1,34 @@
>> +--- a/Source/FreeImage/PluginPNG.cpp
>>  b/Source/FreeImage/PluginPNG.cpp
>> +@@ -713,11 +713,19 @@


--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#742560: freeimage: diff for NMU version 3.17.0+ds1-1.1

[Ghislain Vaillant]

Thanks for providing the additional information I requested, Tobias.

I am still puzzled by a few things. First, the build of FreeImage 3.17.0 
in Fedora 23 [1] and 24 [2] does not require patching the source code 
for libpng16. This is also consistent with the fact that the FreeImage 
3.17.0 source code came bundled with a vendored copy of libpng 1.6.16 
[3], which now both Debian and Fedora strip from their respective source 
packages.


[1] http://koji.fedoraproject.org/koji/rpminfo?rpmID=6906784
[2] http://koji.fedoraproject.org/koji/rpminfo?rpmID=7143896
[3] http://freeimage.sourceforge.net/download.html

So how come that Fedora does not patch for libpng16 and we do?

AFAIK, the main difference packaging-wise between Debian and Fedora is 
that we run the testsuite.


Cheers,
Ghis


On 25/01/16 19:30, Tobias Frost wrote:

Am Montag, den 25.01.2016, 17:58 + schrieb Ghislain Vaillant:


--
Applying patch libpng16.patch
patching file Source/FreeImage/PluginPNG.cpp
Hunk #1 FAILED at 713.
Hunk #2 FAILED at 1000.
2 out of 2 hunks FAILED -- rejects in file
Source/FreeImage/PluginPNG.cpp
Patch libpng16.patch does not apply (enforce with -f)
--



Also, looking at the patch, what are the rationales behind
commenting
out the call to png_set_iCPP but not png_get_iCPP for libpng 1.4+?


Yes, about the ICC profiles... Sh.. Ah, Sorry, I forgot to mention
that: libpng1.6 seems to be more pickier on ICC profiles. You'll see
that when you run the test suite:

*** PNG Format
known incorrect sRGB profile ***
Aborted


Could you also point use to the Fedora patch this is taken from for
reference?


The patch is from here:
http://pkgs.fedoraproject.org/cgit/rpms/freeimage.git/tree/FreeImage-3.
10.0-libpng15.patch?id=5822c50abae307036e0b7ca4cda7cc8c8939db05


Many thanks,
Ghis





The patch does not cleanly apply:


Here it does:

tobi@edoras:~/workspace/deb/libpng-transistion/buildir/nmus$ apt-get
source freeimage
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'freeimage' packaging is maintained in the 'Git' version
control system at:
git://anonscm.debian.org/debian-science/packages/freeimage.git
Please use:
git clone git://anonscm.debian.org/debian-
science/packages/freeimage.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'freeimage_3.17.0+ds1-1.dsc'
Skipping already downloaded file 'freeimage_3.17.0+ds1.orig.tar.xz'
Skipping already downloaded file 'freeimage_3.17.0+ds1-1.debian.tar.xz'
Need to get 0 B of source archives.
dpkg-source: info: extracting freeimage in freeimage-3.17.0+ds1
dpkg-source: info: unpacking freeimage_3.17.0+ds1.orig.tar.xz
dpkg-source: info: unpacking freeimage_3.17.0+ds1-1.debian.tar.xz
dpkg-source: info: applying Disable-vendored-dependencies.patch
dpkg-source: info: applying Use-system-dependencies.patch
dpkg-source: info: applying Fix-macro-redefinition-for-64-bit-integer-
types.patch
dpkg-source: info: applying Fix-compatibility-with-system-libpng.patch
dpkg-source: info: applying Fix-doxygen-output-settings.patch
dpkg-source: info: applying Disable-usage-of-HTML-timestamps-in-
doxygen.patch
dpkg-source: info: applying Fix-unsafe-usage-of-printf-in-
testsuite.patch
dpkg-source: info: applying Disable-testing-of-JPEG-transform.patch
dpkg-source: info: applying Disable-testing-of-JXR-MemIO.patch
dpkg-source: info: applying Fix-missing-cstdio-include-in-
testsuite.patch
dpkg-source: info: applying Fix-endianness-detection.patch
dpkg-source: info: applying Fix-CVE-2015-0852.patch
dpkg-source: info: applying Fix-encoding-of-fi-header.patch
tobi@edoras:~/workspace/deb/libpng-transistion/buildir/nmus$ cd
freeimage-3.17.0+ds1/
tobi@edoras:~/workspace/deb/libpng-transistion/buildir/nmus/freeimage-
3.17.0+ds1$ cat /tmp/bug_742560_message_19.mbox | patch -p1
patching file debian/changelog
patching file debian/patches/libpng16.patch
patching file debian/patches/series
tobi@edoras:~/workspace/deb/libpng-transistion/buildir/nmus/freeimage-
3.17.0+ds1$ quilt push
Applying patch libpng16.patch
patching file Source/FreeImage/PluginPNG.cpp

Now at patch libpng16.patch
tobi@edoras:~/workspace/deb/libpng-transistion/buildir/nmus/freeimage-
3.17.0+ds1$


--
tobi



--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

[Ghislain Vaillant]

Forwarded upstream. Thanks for reporting this issue.

Ghis.

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

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

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#806379: opengm: FTBFS: test suite errors

[Ghislain Vaillant]

> Those builds of opengm that got as far as running the test suite
> nearly all encountered at least one failure.  Some builds failed
> earlier, due to errors I'll report separately.  The only architecture
> on which an automatic build fully succeeded was mips64el, not a
> release architecture anyway.

Yes, I am aware that only amd64 succeeded, which upstream admitted is 
the only architecture they have tested their project on.



> At any rate, you can find the logs at
> https://buildd.debian.org/status/logs.php?pkg=opengm=2.3.6-1,
> but here's a rundown of the failures so far:

>  1 (test-partitions): i386, mipsel, powerpc, hppa
>  8 (test-functions):  i386
> 18 (test-tribool):arm64, powerpc, ppc64el, s390x, ppc64
> 23 (test-io-hdf5):powerpc, s390x, hppa, ppc64

Thanks for listing this up. I forwarded these results upstream and
and some fixes have already been pushed.

> Could you please take a look?

I will soon submit an update with the upstream fixes.

Cheers,
Ghis

--
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers