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

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

Re: hdfview 2.11 locks SWMR files

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

Bug#885971: libgdal20 depends on version 1:8.300.1+dfsg-1 of libarmadillo8

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

Bug#853658: Forwarded upstream

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

Bug#840788: vtk6: Change libmysqlclient-dev build dependency to default-libmysqlclient-dev

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

Bug#835680: Patch for change in FindHDF5.cmake from CMake >= 3.6.0

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

Bug#829166: jhdf: FTBFS: dh_clean: Please specify the compatibility level in debian/compat

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

Re: Could Debian Perl team take over PDL?

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 maintai

Re: Could Debian Perl team take over PDL?

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

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

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

Bug#799195: python-scientific: FTBFS during rebuild against netcdf 4.4.0

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.

Bug#807237: thepeg: Update build dependencies for GSL 2.x

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

Bug#807206: hkl: Update build dependencies for GSL 2.x

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

Bug#805841: qtiplot: Fails to build with GSL 2

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

Bug#807206: hkl: Update build dependencies for GSL 2.x

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

Bug#805801: mathgl: Fails to build with GSL 2

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 >

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

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

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

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

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

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.

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

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

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

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

Bug#793823: etsf-io: ftbfs with GCC-5

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