Bug#889931: proj transition started, increasing severity to serious

[Sebastiaan Couwenberg]

severity 889931 serious
severity 876934 serious
severity 889936 serious
thanks

The proj transition (#891966) has started, these build failures are now RC.

Kind Regards,

Bas

-- 
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: hdfview 2.11 locks SWMR files

[Sebastiaan Couwenberg]

On 02/19/2018 10:08 AM, Jan Kotanski wrote:
> is it possible to provide the h5clear tool in the hdf5-tools package for 
> stretch, (e.g. backports).
> Since hdfview brakes SWMR files it would be good to have a script which fix 
> them back.

h5clear is not provided by hdf5-tools in testing/unstable either. Also a
backport of hdf5 is unlikely.

Please file a wishlist bug to enable building of h5client in hdf5. Once
that's available you can install hdf5-tools in a Debian unstable chroot
and use that to fix your file.

Kind Regards,

Bas

-- 
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#885971: libgdal20 depends on version 1:8.300.1+dfsg-1 of libarmadillo8

[Sebastiaan Couwenberg]

reassign 885971 src:armadillo
retitle 885971 Add version information to libarmadillo
affects 885971 src:melt src:gdal
thanks

Hi Kingsley,

On Sun, 31 Dec 2017 22:10:52 -0800 "Kingsley G. Morse Jr." wrote:
> I'm happy to report that upgrading the package
> named 
> 
> libarmadillo8
> 
> from version
> 
> 1:8.200.0+dfsg-3
> 
> to 
> 
> 1:8.300.1+dfsg-1
> 
> seems to have fixed it.
> 
> 
> Why?
> 
> I suspect because
> 
> melt uses /usr/lib/frei0r-1/facedetect.so,
> 
> /usr/lib/frei0r-1/facedetect.so interacts somehow with libopencv,
> (they're in the attached stack trace and valgrind log)
> 
> libopencv-imgcodecs3.2 (3.2.0+dfsg-4+b2) depends on libgdal20 (>= 2.0.1) 
> and
> 
> libgdal20 (2.2.3+dfsg-1) SAYS it depends on ANY version of libarmadillo8,
> 
> but it ACTUALLY needs 1:8.300.1+dfsg-1.
> 
> It seems to me that the dependencies of the
> libgdal20 package might be updated to say it
> depends on at least version 1:8.300.1+dfsg-1 of
> libarmadillo8.
> 
> Humble suggestion:
> 
> If you agree, maybe you could reassign this bug
> report to the libgdal20 package.

gdal is not the correct package to fix the armadillo dependencies,
libgdal20 gets its armadillo dependencies from ${shlibs:Depends} which
is populated with dependency information for libraries it links to.

armadillo doesn't use symbols files for its libraries to set correct
versioned dependencies, nor does it use `dh_makeshlibs -V` for versioned
library dependencies.

The armadillo package will need to adopt either symbols files or use
`dh_makeshlibs -V` to have packages that link to libarmadillo use a
versioned dependency.

Since maintaining symbols files for C++ libraries is a pain, I suggest
to use `dh_makeshlibs -V` for armadillo, or use the pkgkde-symbolshelper
for C++ symbols files.

Kind Regards,

Bas

-- 
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

[Sebastiaan Couwenberg]

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.

Kind Regards,

Bas
diff --git a/debian/control b/debian/control
index dabad673..2afa097f 100644
--- a/debian/control
+++ b/debian/control
@@ -5,6 +5,8 @@ Section: science
 Priority: optional
 Build-Depends: cmake,
debhelper (>= 10),
+   gcc-6,
+   g++-6,
libblas-dev | libblas.so,
libboost-date-time-dev,
libboost-filesystem-dev,
diff --git a/debian/rules b/debian/rules
index 9e6a203e..0f4ad606 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,9 @@ export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
 export DEB_CXXFLAGS_MAINT_APPEND = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+export CC=gcc-6
+export CXX=g++-6
+
 # Common cmake options.
 CMAKE_BUILD_OPTIONS = \
 	-DBUILD_SHARED_LIBS=ON \
-- 
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#840788: vtk6: Change libmysqlclient-dev build dependency to default-libmysqlclient-dev

[Sebastiaan Couwenberg]

On Sat, 15 Oct 2016 13:36:31 +0200 Andreas Beckmann wrote:
> On Fri, 14 Oct 2016 23:44:15 +0200 Bas Couwenberg 
> wrote:
> > Please change the libmysqlclient-dev build dependency to
> > default-libmysqlclient-dev. The vtk6 build dependencies are
> > no longer installable now that libgdal-dev depends on
> > default-libmysqlclient-dev which is not co-installable with
> > libmysqlclient-dev.
> 
> There is also a dependency libvtk6-dev -> libmysqlclient-dev which
> renders the package uninstallable in sid.

Yes, and my patch [0] changes both to default-libmysqlclient-dev.

Kind Regards,

Bas

[0]
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=840788;filename=vtk6_6.3.0%2Bdfsg1-1_default-libmysqlclient-dev.patch;msg=5

-- 
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#835680: Patch for change in FindHDF5.cmake from CMake >= 3.6.0

[Sebastiaan Couwenberg]

Control: tags -1 upstream patch

Hi,

This is a common issue affecting all reverse dependencies of HDF5 using 
CMake.


The recent update to CMake 3.6.x caused the failure because the 
HDF5_INCLUDE_DIR variable is no longer set by FindHDF5.cmake.


HDF5_INCLUDE_DIR has been deprecated some time ago, only 
HDF5_INCLUDE_DIRS is set for CMake >= 3.6.0.


The attached patch supports both by setting HDF5_INCLUDE_DIR to the 
value of HDF5_INCLUDE_DIRS if the former is not defined but the latter is.


Kind Regards,

Bas




cmake-3.6-hdf5.patch
Description: inode/symlink
-- 
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#829166: jhdf: FTBFS: dh_clean: Please specify the compatibility level in debian/compat

[Sebastiaan Couwenberg]

Control: tags -1 patch

Please create the compat file as suggested, or add the attached one.

It fixes the build failure.

Kind Regards,

Bas
7
-- 
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: Could Debian Perl team take over PDL?

[Sebastiaan Couwenberg]

On 06/03/2016 10:55 PM, Sebastiaan Couwenberg wrote:
> On 06/03/2016 10:07 PM, Niko Tyni wrote:
>> On Mon, May 30, 2016 at 12:02:32PM +0200, Andreas Tille wrote:
>>> I've got a request from PDL upstream who fully correctly noticed that
>>> PDL is not properly maintained inside Debian.  Since I once did some
>>> ad-hoc fixes Upstream CCed me whether I could do something as Debian
>>> Science team member.  I had a look and updated Git[1] a bit but I
>>> noticed that it is way better if some Perl programmer could have a look.
>>> I admit that the patches are more than the small time cycles I would be
>>> able to spent into this would permit me to do.
>>>
>>> I'd be really happy if Debian Perl team could take over maintenance
>>> of this package.
>>
>> Thanks for the note. I'm adding debian-perl to the recipient list,
>> that's a bit better for discussions than the pkg-perl-maintainers one.
>>
>> PDL does seem to fit well in the pkg-perl domain so I think that should
>> be fine. It clearly needs some work (there are old Debian patches that
>> have little documentation or anything) and I can't promise any schedule,
>> but I'll try to look at it. Help is welcome of course.
>>
>> I see Henning is still listed as the Maintainer for libpdl-io-hdf5-perl
>> and libpdl-netcdf-perl. Are those up for adoption too?
> 
> I assume they are up for adaption too. libpdl-netcdf-perl hasn't seen
> any activity since I NMUed it for the netcdf transition last October.
> 
> PDL and its related packages are reverse dependencies of several
> packages maintained by the Debian GIS team, I can probably help get PDL
> back into shape within the Perl team too (no promises either).

I've started to update the pdl package to the latest upstream release.
There history from the debian-science git repo has been pushed to the
newly created git repository under pkg-perl.

Henning is listed as the sole Uploader, who would like to be among the
Uploaders of the package within the Perl team to take his place?

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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: Could Debian Perl team take over PDL?

[Sebastiaan Couwenberg]

On 06/03/2016 10:07 PM, Niko Tyni wrote:
> On Mon, May 30, 2016 at 12:02:32PM +0200, Andreas Tille wrote:
>> I've got a request from PDL upstream who fully correctly noticed that
>> PDL is not properly maintained inside Debian.  Since I once did some
>> ad-hoc fixes Upstream CCed me whether I could do something as Debian
>> Science team member.  I had a look and updated Git[1] a bit but I
>> noticed that it is way better if some Perl programmer could have a look.
>> I admit that the patches are more than the small time cycles I would be
>> able to spent into this would permit me to do.
>>
>> I'd be really happy if Debian Perl team could take over maintenance
>> of this package.
> 
> Thanks for the note. I'm adding debian-perl to the recipient list,
> that's a bit better for discussions than the pkg-perl-maintainers one.
> 
> PDL does seem to fit well in the pkg-perl domain so I think that should
> be fine. It clearly needs some work (there are old Debian patches that
> have little documentation or anything) and I can't promise any schedule,
> but I'll try to look at it. Help is welcome of course.
> 
> I see Henning is still listed as the Maintainer for libpdl-io-hdf5-perl
> and libpdl-netcdf-perl. Are those up for adoption too?

I assume they are up for adaption too. libpdl-netcdf-perl hasn't seen
any activity since I NMUed it for the netcdf transition last October.

PDL and its related packages are reverse dependencies of several
packages maintained by the Debian GIS team, I can probably help get PDL
back into shape within the Perl team too (no promises either).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

etsf-io: FTBFS: cp: cannot stat './AUTHORS-XAUTHORS': No such file or directory

[Sebastiaan Couwenberg]

Control: tags -1 pending

Hi Chris,

I've prepared a new NMU to fix this issue, see the attached debdiff.

I've uploaded it to DELAYED/10

Hopefully the maintainer will prepare a proper upload to acknowledge
this and the preceding NMU.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru etsf-io-1.0.4/debian/changelog etsf-io-1.0.4/debian/changelog
--- etsf-io-1.0.4/debian/changelog  2015-08-19 21:17:07.0 +0200
+++ etsf-io-1.0.4/debian/changelog  2016-05-20 17:08:49.0 +0200
@@ -1,3 +1,12 @@
+etsf-io (1.0.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix dh_installdocs invocation,
+cdds cannot exclude files via DEB_INSTALL_DOCS.
+(closes: #824830)
+
+ -- Bas Couwenberg   Fri, 20 May 2016 16:45:38 +0200
+
 etsf-io (1.0.4-1~exp1.1) unstable; urgency=medium
 
   * Non-maintainer upload. Build with GCC 5. (closes: #777844)
diff -Nru etsf-io-1.0.4/debian/rules etsf-io-1.0.4/debian/rules
--- etsf-io-1.0.4/debian/rules  2015-01-06 14:38:16.0 +0100
+++ etsf-io-1.0.4/debian/rules  2016-05-20 17:08:13.0 +0200
@@ -6,9 +6,10 @@
 
 DEB_CONFIGURE_USER_FLAGS := --docdir=\$${prefix}/share/doc/libetsf-io-doc 
--with-moduledir=\$${includedir} FCFLAGS="-O2 -fPIC"
 DEB_MAKE_INSTALL_TARGET  := install DESTDIR=$(DEB_DESTDIR)
-DEB_INSTALL_DOCS_etsf-io := -XTODO
-DEB_INSTALL_DOCS_libetsf-io-doc := -XAUTHORS -XREADME -XNEWS -XTODO
-DEB_INSTALL_DOCS_libetsf-io-dev := -XAUTHORS -XREADME -XNEWS -XTODO
+#DEB_INSTALL_DOCS_etsf-io := -XTODO
+#DEB_INSTALL_DOCS_libetsf-io-doc := -XAUTHORS -XREADME -XNEWS -XTODO 
+#DEB_INSTALL_DOCS_libetsf-io-dev := -XAUTHORS -XREADME -XNEWS -XTODO
 
 get-orig-source:
-uscan --upstream-version 0
+
-- 
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#799195: python-scientific: FTBFS during rebuild against netcdf 4.4.0

[Sebastiaan Couwenberg]

On Wed, 16 Sep 2015 18:23:47 + PICCA Frederic-Emmanuel wrote:
> python-scientific is for now not compatible with numpy 1.9.

python-scientific and libvtk5.8 are keeping the old netcdf (1:4.1.3-7.2)
packages in unstable and hindering testing migration of every subsequent
revision.

python-scientific should be removed from the Debian archive until the
fixes are available allowing it to be reintroduced. Keeping
python-scientific in unstable is actively harmful.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#807237: thepeg: Update build dependencies for GSL 2.x

[Sebastiaan Couwenberg]

On 06-12-15 16:30, Bas Couwenberg wrote:
> Please note that rivet (#807224) needs to be updated for GSL 2,
> before thepeg can be rebuilt with GSL 2.
> 
> Having thepeg rebuilt with GSL 2 will unblock the rebuild for herwig++.

With the upload of rivet (1.8.3-1.3) to unstable two days ago, it no
longer blocks the update of thepeg for GSL 2.

Please update thepeg for GSL 2 to remove this blocker for the rebuild of
herwig++ (#805844) and the gsl transition (#804246).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#807206: hkl: Update build dependencies for GSL 2.x

[Sebastiaan Couwenberg]

reopen 807206
thanks

Hi Michael,

You closed the wrong bugreport (807206 instead of 807026),
so I'm reopening this one.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#805841: qtiplot: Fails to build with GSL 2

[Sebastiaan Couwenberg]

reopen 805841
retitle 805841 qtiplot: Update build dependencies for GSL 2
severity 805841 normal
found 805841 qtiplot/0.9.8.9-11 qtiplot/0.9.8.9-12
block 805841 by 806835
thanks

Hi Anton,

Thanks for fixing the GSL 2 support in qtiplot, unfortunately the patch
for GSL 2 support is not sufficient to build qtiplot with GSL 2.

> The full build log is attached, as is a patch to update the build
> dependencies for GSL 2 (changing libgsl0-dev to libgsl-dev).

The build dependency change hasn't been applied yet, and therefore
qtiplot still pulls in the GSL 1.x packages via libgsl0-dev.

Please note that tamuanova (#806835) needs to be updated for GSL 2
first, before qtiplot can be successfully rebuilt with GSL 2.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#807206: hkl: Update build dependencies for GSL 2.x

[Sebastiaan Couwenberg]

reopen 807206
thanks

Hi Michael,

You closed the wrong bugreport (807206 instead of 807026),
so I'm reopening this one.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#805801: mathgl: Fails to build with GSL 2

[Sebastiaan Couwenberg]

Control: tags -1 patch fixed-upstream

On 22-11-15 18:36, Bas Couwenberg wrote:
> Your package fails to build with GSL 2:
> 
>  /tmp/buildd/mathgl-2.3.3/src/fit.cpp: In function 'mreal 
> mgl_fit_base(mglFitData&, mreal*)':
>  /tmp/buildd/mathgl-2.3.3/src/fit.cpp:196:25: error: 'struct 
> gsl_multifit_fdfsolver' has no member named 'J'
>gsl_multifit_covar (s->J, 0.0, covar );
>   ^
> 
> This needs to be fixed for the ongoing gsl transition (#804246).

GSL 2 compatibility was recently fixed upstream in:

 http://sourceforge.net/p/mathgl/code/1216/

The attached debdiff includes the GSL related changes from upstream
r1216 and updated build dependencies.

With the gsl-2.patch applied, the package still FTBFS due to #803312.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru mathgl-2.3.3/debian/changelog mathgl-2.3.3/debian/changelog
--- mathgl-2.3.3/debian/changelog   2015-10-05 20:53:57.0 +0200
+++ mathgl-2.3.3/debian/changelog   2015-12-03 17:09:53.0 +0100
@@ -1,3 +1,11 @@
+mathgl (2.3.3-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update build dependencies for GSL 2, change libgsl0-dev to libgsl-dev.
+  * Add patch for GSL 2.x support.
+
+ -- Bas Couwenberg   Sun, 22 Nov 2015 18:19:31 +0100
+
 mathgl (2.3.3-3) unstable; urgency=medium
 
   * Disable need for C++11 support (Closes: #800460)
diff -Nru mathgl-2.3.3/debian/control mathgl-2.3.3/debian/control
--- mathgl-2.3.3/debian/control 2015-08-29 06:48:36.0 +0200
+++ mathgl-2.3.3/debian/control 2015-11-22 18:19:30.0 +0100
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Science Maintainers 

 Uploaders: Dimitrios Eftaxiopoulos 
-Build-Depends: debhelper (>= 9), libltdl-dev, libgsl0-dev, freeglut3-dev,
+Build-Depends: debhelper (>= 9), libltdl-dev, libgsl-dev, freeglut3-dev,
  libgl1-mesa-dev | libgl-dev, libpng-dev, libhdf5-dev, libqt5opengl5-dev,
  libjpeg-dev, libtiff-dev, libfltk1.3-dev, libqt5webkit5-dev, libwxgtk3.0-dev, 
  texinfo, texlive, texlive-generic-recommended, liblua5.1-dev, libxcursor-dev,
@@ -201,7 +201,7 @@
 Depends: libmgl7.4.0 (= ${binary:Version}), libmgl-wnd7.4.0 (= 
${binary:Version}),
  libmgl-wx7.4.0 (= ${binary:Version}), libmgl-fltk7.4.0 (= ${binary:Version}),
  libmgl-qt7.4.0 (= ${binary:Version}), libmgl-glut7.4.0 (= ${binary:Version}),
- libmgl-mpi7.4.0 (= ${binary:Version}), ${misc:Depends}, libgsl0-dev, 
+ libmgl-mpi7.4.0 (= ${binary:Version}), ${misc:Depends}, libgsl-dev, 
  libgl1-mesa-dev | libgl-dev, libpng-dev
 Description: library for scientific graphs (development files)
  A free cross-platform library of fast C++ routines for plotting data in up
@@ -223,4 +223,4 @@
  MathGL can also be used in the console. There are interfaces to a set of
  languages, such as, C, Fortran, Pascal, Forth, Python, Octave.
  .
- This package provides the Python module for mathgl.
\ No newline at end of file
+ This package provides the Python module for mathgl.
diff -Nru mathgl-2.3.3/debian/patches/gsl-2.patch 
mathgl-2.3.3/debian/patches/gsl-2.patch
--- mathgl-2.3.3/debian/patches/gsl-2.patch 1970-01-01 01:00:00.0 
+0100
+++ mathgl-2.3.3/debian/patches/gsl-2.patch 2015-12-03 17:25:16.0 
+0100
@@ -0,0 +1,59 @@
+Description: Add support for GSL 2.x.
+Origin: http://sourceforge.net/p/mathgl/code/1216/
+Bug-Debian: https://bugs.debian.org/805801
+
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -259,6 +259,13 @@ endif(enable-pthread)
+ 
+ if(enable-gsl)
+   set(MGL_HAVE_GSL 1)
++  FIND_PACKAGE(PkgConfig)
++  pkg_check_modules(GSL2 REQUIRED gsl)
++  if(GSL2_FOUND)
++  if ( NOT ${GSL2_VERSION} LESS 2.0)
++  SET(MGL_HAVE_GSL2 1)
++  endif ( NOT ${GSL2_VERSION} LESS 2.0)
++  endif ( GSL2_FOUND )
+   find_library(GSL_LIB gsl)
+   find_library(GSL_CBLAS_LIB gslcblas)
+   find_path(GSL_INCLUDE_DIR gsl/gsl_fft_complex.h)
+--- a/src/CMakeLists.txt
 b/src/CMakeLists.txt
+@@ -23,6 +23,9 @@ ${MathGL_BINARY_DIR}/include/mgl2/dllexp
+ )
+ 
+ add_definitions(-DMGL_SRC)
++if(MGL_HAVE_GSL2)
++  add_definitions(-DMGL_HAVE_GSL2)
++endif(MGL_HAVE_GSL2)
+ 
+ if(MGL_HAVE_PNG)
+   set(prc_src prc/PRCbitStream.cc prc/PRCdouble.cc prc/oPRCFile.cc 
prc/writePRC.cc prc.cpp )
+--- a/src/fit.cpp
 b/src/fit.cpp
+@@ -192,14 +192,23 @@ mreal MGL_NO_EXPORT mgl_fit_base(mglFitD
+   status = gsl_multifit_test_delta (s->dx, s->x, 1e-4, 1e-4 );
+   }
+   while ( status == GSL_CONTINUE && iter < 500 );
++
+   gsl_matrix *covar = gsl_matrix_alloc(m, m);
++#ifdef MGL_HAVE_GSL2
++  gsl_matrix *J = gsl_matrix_alloc(s->fdf->n, s->fdf->p);
++  gsl_multifit_fdfsolver_jac(s, J);
++  gsl_multifit_covar (J, 0.0, covar);
++  gsl_matrix_free (J);
++#else
+   

Bug#805829: r-cran-gsl: Fails to build with GSL 2

[Sebastiaan Couwenberg]

Control: tags -1 patch fixed-upstream

Hi Andreas,

On 24-11-15 22:14, Andreas Tille wrote:
> thanks for working on the libgsl migration.  I commited a patch to SVN[1]
> to circumvent the check by configure but that's not sufficient to do the
> migration.  The build fails with
> 
> In file included from ellint.c:1:0:
> /usr/include/gsl/gsl_sf_ellint.h:84:5: note: expected 'gsl_sf_result * {aka 
> struct gsl_sf_result_struct *}' but argument is of type 'int'
>  int gsl_sf_ellint_D_e(double phi, double k, gsl_mode_t mode, gsl_sf_result * 
> result);
>  ^
> ellint.c:82:17: error: too many arguments to function 'gsl_sf_ellint_D_e'
>  status[i] = gsl_sf_ellint_D_e(phi[i], k[i], n[i], sf_mode[*mode], 
> ) ;
>  ^
> 
> Anybody with some gsl experience might perhaps know what to do next
> hopefully.

The attached patch add support for GSL 2.x and make r-cran-gsl build
successfully with GSL 2.1.

The changes were taken from yesterdays 1.9-10.1 upstream release, so
you'll want to package that instead.

 https://cran.r-project.org/web/packages/gsl/
 https://cran.r-project.org/src/contrib/gsl_1.9-10.1.tar.gz

Make sure to update the build dependency to libgsl-dev to not pull in
the old GSL 1.x packages via libgsl0-dev.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru r-cran-gsl-1.9-10/debian/changelog r-cran-gsl-1.9-10/debian/changelog
--- r-cran-gsl-1.9-10/debian/changelog  2014-06-23 12:25:00.0 +0200
+++ r-cran-gsl-1.9-10/debian/changelog  2015-11-22 21:58:37.0 +0100
@@ -1,3 +1,10 @@
+r-cran-gsl (1.9-10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Update build dependencies for GSL 2, change libgsl0-dev to libgsl-dev.
+
+ -- Bas Couwenberg   Sun, 22 Nov 2015 21:58:32 +0100
+
 r-cran-gsl (1.9-10-1) unstable; urgency=low
 
   * Initial release (Closes: #752387).
diff -Nru r-cran-gsl-1.9-10/debian/control r-cran-gsl-1.9-10/debian/control
--- r-cran-gsl-1.9-10/debian/control2014-06-23 10:58:32.0 +0200
+++ r-cran-gsl-1.9-10/debian/control2015-11-22 21:58:30.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (>= 9.0),
cdbs,
r-base-dev,
-   libgsl0-dev
+   libgsl-dev
 Standards-Version: 3.9.5
 Vcs-Browser: 
http://anonscm.debian.org/viewvc/debian-science/packages/R/trunk/packages/r-cran-gsl/trunk/
 Vcs-Svn: 
svn://anonscm.debian.org/debian-science/packages/R/trunk/packages/r-cran-gsl/trunk/
diff -Nru r-cran-gsl-1.9-10/debian/patches/gsl-2.patch 
r-cran-gsl-1.9-10/debian/patches/gsl-2.patch
--- r-cran-gsl-1.9-10/debian/patches/gsl-2.patch1970-01-01 
01:00:00.0 +0100
+++ r-cran-gsl-1.9-10/debian/patches/gsl-2.patch2015-12-03 
16:41:16.0 +0100
@@ -0,0 +1,116 @@
+Description: Add support for GSL (taken from upstream release 1.9-10.1)
+Origin: https://cran.r-project.org/src/contrib/gsl_1.9-10.1.tar.gz
+Bug-Debian: https://bugs.debian.org/805829
+
+--- a/MD5
 b/MD5
+@@ -35,8 +35,8 @@ f2606a5708629a1b4ebc401b857ba00d *R/psi.
+ db9a953c82fb5bcad9aee1bc7c6c053a *R/zzz.R
+ c49ad1d44c0b69af5e210633fcaddcf6 *build/vignette.rds
+ 67c9db5dc1a8e12ccf5880ffe206ce56 *cleanup
+-98d0b4377dad6dcd1014786f247027b5 *configure
+-afdb66942750b3ac5417d2484e59bbfe *configure.ac
++9a9891f695e4676eb2f69fb50f393f57 *configure
++b0a09ce66804c989dc28f289db46011c *configure.ac
+ 4f92f503d9c4f423a6e89a9eaf63b63a *inst/CITATION
+ e2b59fe3fff2bcb30599893a7e590f33 *inst/doc/gslpaper.R
+ 3301d42c84eae58199688edf0b89e67b *inst/doc/gslpaper.Rnw
+@@ -83,7 +83,7 @@ f58e8ead369ee94387edc38f1330ada1 *src/co
+ b9e67aa3572a60fc8cfe5651d386a251 *src/dawson.c
+ 07b6bc201b1956c4a5dd90172fdb6cb2 *src/debye.c
+ 5b5cabf6031c19224e7e7ef4ac9e2b6a *src/dilog.c
+-e8e7cb31ab73cc4f04402445d607965a *src/ellint.c
++ca96b38cdc06b5c35fee02b26b2bff4d *src/ellint.c
+ bb037c708bd7e7ba735b83b8f5166e0a *src/elljac.c
+ 803c371059fc2b48262c6a611f10e48e *src/error.c
+ 23e873053f5e1544a259ef8444d268f8 *src/expint.c
+@@ -93,7 +93,7 @@ f183cb92f62f2132ebcd6c6e87dadbe9 *src/fe
+ 42f6f901e8451ca0b1aa6c24b292a3b8 *src/hyperg.c
+ dfa461e5ad77313a206f82f677ee3cac *src/laguerre.c
+ 5c539738e044a51c33f3916873543392 *src/lambert.c
+-1fe19b728d6a3eb673d94d95ce5e0347 *src/legendre.c
++4c21539636e69450c7ab4da6684dc7c9 *src/legendre.c
+ a60c1c9bc368e9c50a8545aab6ca67bc *src/log.c
+ 8768413013d9891c716a3fe0f60826bd *src/multimin.c
+ d108215b94072249889c251a8e9e6f37 *src/poly.c
+--- a/configure
 b/configure
+@@ -2635,7 +2635,7 @@ int main() {
+if ((sscanf(gslv, "%d.%d", , )) != 2) {
+  exit (1);
+}
+-   exit (minor < 12);
++   exit (major == 1 && minor < 12);
+ #else
+   exit(1);
+ #endif
+--- a/configure.ac
 b/configure.ac
+@@ -33,7 +33,7 @@ int main() {
+if ((sscanf(gslv, "%d.%d", , )) != 2) {
+  exit (1);
+}
+-   exit (minor < 12);
++   exit (major == 1 && minor < 12);
+ #else
+   exit(1);
+ 

Bug#791173: libstxxl: library transition may be needed when GCC 5 is the default

[Sebastiaan Couwenberg]

On 23-08-15 19:15, Simon McVittie wrote:
 On 23/08/15 16:10, Sebastiaan Couwenberg wrote:
 On 23-08-15 16:59, Simon McVittie wrote:
 The SONAME bump option was only really meant to be taken if the library
 had an upstream SONAME bump pending anyway (for instance icu and boost
 went this route). If there is not a SONAME change already in the pipeline,
 you should do the v5 rename instead. My NMUs of gtkmm2.4, gtkmm3.0,
 atlas-cpp, bullet etc. should make a reasonable template for how this works.

 I have the packaging for the libstxll v5 rename mostly ready in my local
 git, I can push this to Alioth and/or NMU it to DELAYED/2 if you want.
 
 Regardless of whether you NMU, please compare what you have done with
 the Ubuntu patch at
 http://patches.ubuntu.com/libs/libstxxl/libstxxl_1.4.1-1ubuntu1.patch
 (you'll probably find it ended up identical), and send a diff against
 current unstable to this bug.

Anton has pushed his changes already, but so far I've not seen the
upload yet. That's a good thing because the Breaks/Replaces needs to use
a version constraint:

 Breaks: libstxxl1 ( 1.4.1-2~)
 Replaces: libstxxl1 ( 1.4.1-2~)

Ubuntu uses Conflicts/Replaces without a version constraint. And
bothered to rename the -dbg package too, which neither I nor Anton have
done.

My proposed changes are attached because cannot push to debian-science,
I think that should be used instead of Conflicts/Replaces as Ubuntu has
done.

 If you've done the work already, and if all the library build-deps
 either don't need a transition or have already started theirs, then I
 would personally say you might as well NMU to an appropriate DELAYED
 queue. This overall transition has broken unstable for 3 weeks already,
 during which lots of packages are either uninstallable or
 non-functional, and basically no C++ can migrate to testing; the sooner
 we can get through it and have our distribution back, the better.

It doesn't look like any of the libstxxl build dependencies are a
blocker, so I do think we need to go ahead with an upload to unstable soon.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


0001-Use-versioned-Breaks-Replaces.patch
Description: application/pgp-encrypted
-- 
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#791173: libstxxl: library transition may be needed when GCC 5 is the default

[Sebastiaan Couwenberg]

On 23-08-15 19:59, Anton Gladky wrote:
 Thanks, Bas. Agreed and accepted. Will upload in a
 few moments.

Thanks. I'll finish up the new osrm revision to close its RC bug after
libstxxl hits the mirrors.

 Feel free to join debian-science group on Alioth, I will
 accept your request, if you want.

Thanks for the offer, I may join debian-science later. For now I'm happy
to remain just the GIS guy, although we should consider moving hdf5 and
netcdf from the Debian GIS team to Debian Science, -science seems a
better fit (but may not have the manpower).

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#791173: libstxxl: library transition may be needed when GCC 5 is the default

[Sebastiaan Couwenberg]

On 23-08-15 16:59, Simon McVittie wrote:
 The SONAME bump option was only really meant to be taken if the library
 had an upstream SONAME bump pending anyway (for instance icu and boost
 went this route). If there is not a SONAME change already in the pipeline,
 you should do the v5 rename instead. My NMUs of gtkmm2.4, gtkmm3.0,
 atlas-cpp, bullet etc. should make a reasonable template for how this works.

I have the packaging for the libstxll v5 rename mostly ready in my local
git, I can push this to Alioth and/or NMU it to DELAYED/2 if you want.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#791173: libstxxl: library transition may be needed when GCC 5 is the default

[Sebastiaan Couwenberg]

Control: reopen -1

On Tue, 11 Aug 2015 09:03:51 +0100 Simon McVittie wrote:
 On Fri, 03 Jul 2015 at 13:12:19 +, Matthias Klose wrote:
   - If there are no reverse dependencies, it should be the package
 maintainers decision if a transition is needed.  However this might
 break software which is not in the Debian archive, and built
 against these packages.
 
 There do not seem to be any rdeps outside the source package, so a
 transition is probably not needed. Closing this to take it off the
 release team's list.
 
 If a transition is needed, please reopen.

It looks like libstxxl needs a transition after al.

At least osrm is a reverse dependency, it cannot be built due to
undefined references to stxxl::print_msg() and others.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
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#793823: etsf-io: ftbfs with GCC-5

[Sebastiaan Couwenberg]

Control: tags -1 pending

On Sun, 16 Aug 2015 14:16:34 +0300 Antti Järvinen wrote:
 By obtaining source of netcfg, compiling and installing that in SID
 made this package to successfully build too so this package is not
 errorneus and listed in
 https://release.debian.org/transitions/html/auto-netcdf.html for a
 reason.

The netcdf transition has started, and etsf-io needs a build dependency
on libnetcdff-dev to build successfully with the new netcdf packages.
(#793823)

I've done an NMU of etsf-io to DELAYED/2, see the attached debdiff for
changes.

You may want to do a proper upload to unstable, including some changes
for some of the lintian issues perhaps.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
diff -Nru etsf-io-1.0.4/debian/changelog etsf-io-1.0.4/debian/changelog
--- etsf-io-1.0.4/debian/changelog  2015-01-06 14:46:51.0 +0100
+++ etsf-io-1.0.4/debian/changelog  2015-08-19 21:17:07.0 +0200
@@ -1,3 +1,12 @@
+etsf-io (1.0.4-1~exp1.1) unstable; urgency=medium
+
+  * Non-maintainer upload. Build with GCC 5. (closes: #777844)
+  * Add build dependency on libnetcdff-dev for netcdf transition.
+(closes: #793823)
+  * Move from experimental to unstable.
+
+ -- Bas Couwenberg sebas...@debian.org  Wed, 19 Aug 2015 21:15:32 +0200
+
 etsf-io (1.0.4-1~exp1) experimental; urgency=low
 
   * New minor upstream release with parallel IO support introduced by NetCDF 4.
diff -Nru etsf-io-1.0.4/debian/control etsf-io-1.0.4/debian/control
--- etsf-io-1.0.4/debian/control2015-01-06 14:38:16.0 +0100
+++ etsf-io-1.0.4/debian/control2015-08-19 21:20:21.0 +0200
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Science Team 
debian-science-maintainers@lists.alioth.debian.org
 Uploaders:  Damien Caliste damien.cali...@cea.fr
-Build-Depends: debhelper (= 5), cdbs, autotools-dev, gfortran, libnetcdf-dev
+Build-Depends: debhelper (= 5), cdbs, autotools-dev, gfortran, libnetcdf-dev 
(= 1:4.3.3.1), libnetcdff-dev
 Standards-Version: 3.9.6
 Homepage: http://www.etsf.eu/resources/software/libraries_and_tools
 Vcs-Svn: svn://svn.debian.org/svn/debian-science/packages/etsf-io/
@@ -51,7 +51,7 @@
 Package: libetsf-io-dev
 Section: libdevel
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libnetcdf-dev
+Depends: ${shlibs:Depends}, ${misc:Depends}, libnetcdf-dev, libnetcdff-dev
 Suggests: libetsf-io-doc
 Description: Static libraries and Fortran module files of ETSF_IO
  ETSF_IO is a library of F90 routines to read/write the ETSF file format.
-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers