Solved (Was: Pristine-tar is broken when doing backports)

2019-05-02 Thread Andreas Tille
Argh, for some reason the ~/.gbp.conf I'm using for Stretch contained

   # pristine-tar = True

(I probably once backported a package without pristine-tar.)
Its probably a bug to create **wrong** tarballs if pristine-tar is
unset but after removing the comment my setup is working again.

Kind regards

Andreas.

On Thu, May 02, 2019 at 10:44:14AM +0500, Andrey Rahmatullin wrote:
> On Thu, May 02, 2019 at 07:40:56AM +0200, Andreas Tille wrote:
> > Hi folks,
> > 
> > I'm using gbp successfully in all my packaging projects and it works
> > perfectly when building in sid.  However since some time (about 1-2
> > months) always if I try to do a backport to stretch git-buildpackage is
> > creating a wrong upstream source tarball (wrong size and md5sum).  This
> > *only* happens for backports so I assume the Git archive is OK, but the
> > backport build process does something differently.
> > 
> > Any idea what might be wrong?
> Anything.
> Please provide more info.
> 
> -- 
> WBR, wRAR



-- 
http://fam-tille.de



Pristine-tar is broken when doing backports

2019-05-01 Thread Andreas Tille
Hi folks,

I'm using gbp successfully in all my packaging projects and it works
perfectly when building in sid.  However since some time (about 1-2
months) always if I try to do a backport to stretch git-buildpackage is
creating a wrong upstream source tarball (wrong size and md5sum).  This
*only* happens for backports so I assume the Git archive is OK, but the
backport build process does something differently.

Any idea what might be wrong?

Kind regards

   Andreas.

-- 
http://fam-tille.de



Re: Looking for a mentor -- multiscale molecular modeling package MMB (and molmodel)

2019-03-04 Thread Andreas Tille
Hi,

On Wed, Feb 27, 2019 at 10:02:32AM +0200, Andrius Merkys wrote:
> Hi Samuel,
> 
> On 2019-02-26 18:27, Samuel Flores wrote:
> > I would like some help packaging MacroMoleculeBuilder (MMB) for 
> > distribution in Debian or Ubuntu. It is a mature piece of code, used to 
> > publish many scientific articles in structural bioinformatics and 
> > structural and molecular biology. It has been downloaded thousands of times.
> 
> I would gladly help with the packaging of this modeling tool.
> 
> > I would be happy to change MMB's license to be compatible with this process.
> 
> You are absolutely right to start with the license check. Debian accepts
> only those licenses that are compatible with Debian Free Software Guides
> [1]. You can find (incomplete) list of DFSG-compatible licenses here [2].
> 
> [1] http://www.debian.org/social_contract#guidelines
> [2] https://wiki.debian.org/DFSGLicenses
> 
> > MMB requires OpenMM, simbody, and SeqAn, I believe all of these are already 
> > packaged. It also requires SimTK molmodel which is not packaged -- I am the 
> > maintainer of molmodel and would like to package this as well. Molmodel is 
> > not hard to compile, but it does use cmake. 
> 
> OpenMM and molmodel are not yet in Debian, AFAIK. Thus they have to be
> packaged before the MMB. To start with, I would suggest reading the
> introduction to packaging [3], as Andrey has advised.

I'd recommend to discuss this with DebiChem team (list in CC)
 
> Andrius Merkys
> Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
> LT-10257 Vilnius, Lithuania

See you soon at Debian Med sprint

  Andreas. 

-- 
http://fam-tille.de



Re: Bug#919413: cascade of FTBFS

2019-02-14 Thread Andreas Tille
On Thu, Feb 14, 2019 at 03:16:22PM +0100, Dominique Dumont wrote:
> On Tuesday, 12 February 2019 16:54:12 CET Andreas Tille wrote:
> > I'm
> > not sure how to deal with the jquery.js one since this is potentially an
> > issue with lots of dependencies - I remember discussions about this
> > which I did not followed.
> 
> Fortunately, jquery is available as a Debian package.

Sure it is.  I simply remember some discussions about why doxygen needs its
own jquery.  I'd be really happy if this is not the case any more.
 
Kind regards

   Andreas.

-- 
http://fam-tille.de



Bug#919413: cascade of FTBFS

2019-02-12 Thread Andreas Tille
Control: tags -1 help

Hi Paolo,

in my attempt to see what I can do for #921779 which breaks several
packages I stumbled upon your attempt to adopt doxygen.  Thanks a lot
for this brave intention. ;-)

I realised that the watch file did not work properly - feel free to `git
am` the attached patch.  I also noticed that there are remaining lintian
errors:

E: doxygen source: source-is-missing templates/html/jquery.js line length is 
32401 characters (>512)
N: 
N:The source of the following file is missing. Lintian checked a few
N:possible paths to find the source, and did not find it.
N:
N:Please repack your package to include the source or add it to
N:"debian/missing-sources" directory.
N:
N:If this is a false-positive, please report a bug against Lintian.
N:
N:Please note, that insane-line-length-in-source-file tagged files are
N:likely tagged source-is-missing. It is a feature not a bug.
N:
N:Severity: serious, Certainty: possible
N:
N:Check: cruft, Type: source
N: 
E: doxygen source: source-is-missing templates/html/menu.js line length is 695 
characters (>512)
E: doxygen source: source-is-missing templates/html/svgpan.js line length is 
312 characters (>256)


You should override the latter two since these are false positives.  I'm
not sure how to deal with the jquery.js one since this is potentially an
issue with lots of dependencies - I remember discussions about this
which I did not followed.

Regarding the ratt results[1] the issue

   librostlab: ! LaTeX Error: File 'listofitems.sty' not found.

can be solved by a doxygen-latex Build-Depends - at least I added this
to frobby in Git[2] which helped against this very error but after this it
was running into:

[572]
! Undefined control sequence.
l.211 ...+t-1$. The inner slice will have $(a\text
  {'},b)$, where $a^\prime$ ...

?.
! Emergency stop.
l.211 ...+t-1$. The inner slice will have $(a\text
  {'},b)$, where $a^\prime$ ...

!  ==> Fatal error occurred, no output PDF file produced!



I have no idea how to fix this.

Kind regards

   Andreas.



[1] https://salsa.debian.org/paolog-guest/doxygen/wikis/ratt4
[2] 
https://salsa.debian.org/science-team/frobby/commit/d2fd89875e8491a755ee702e710aa9e003982ee7

-- 
http://fam-tille.de
>From b0a8a6a14c391fbc40489ab6df984435efaba1c4 Mon Sep 17 00:00:00 2001
From: Andreas Tille 
Date: Tue, 12 Feb 2019 16:02:57 +0100
Subject: [PATCH] Fix watch file

---
 debian/changelog | 4 
 debian/watch | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index beb9ad6..6ca0d0b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 doxygen (1.8.15-1) unstable; urgency=medium
 
+  [ Paolo Greppi ]
   * doxygen 1.8.15 release. Closes: #920447.
   * Do not produce "Directory Reference" man pages. Closes: #742871.
   * Bump debhelper compat.
@@ -13,6 +14,9 @@ doxygen (1.8.15-1) unstable; urgency=medium
   * Switch to llvm-toolchain-7. Closes: #912799.
   * Make the output of $year reproducible. Closes: #863054
 
+  [ Andreas Tille ]
+  * Fix watch file
+
  -- Paolo Greppi   Tue, 05 Feb 2019 16:45:02 +0100
 
 doxygen (1.8.13-10) unstable; urgency=medium
diff --git a/debian/watch b/debian/watch
index f688d00..2e294c4 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,4 +1,4 @@
-version=3
+version=4
 
-opts=filenamemangle=s/.+\/Release_(\d\S*)\.tar\.gz/doxygen-$1.tar\.gz/ \
+opts=uversionmangle=s/_/./g,filenamemangle=s/.+\/Release_(\d\S*)\.tar\.gz/doxygen-$1.tar\.gz/ \
   https://github.com/doxygen/doxygen/tags .*/Release_(\d\S*)\.tar\.gz
-- 
2.20.1



Re: Bug#921843: discosnp has unsatisfiable dependencies

2019-02-09 Thread Andreas Tille
Control: tags -1 help moreinfo

Hi,

I really wonder why gatb-core should be missing.  According to
tracker[1] gatb-core is in testing and the build logs[2] are specifying
exactly those architectures as successfully installed that you claim
missing (in agreement with discosnp tracker page[3] admittedly but
not more enlightening to me).

Any idea what might be wrong here and how to fix this?

Kind regards

   Andreas.


[1] https://tracker.debian.org/pkg/gatb-core
[2] https://buildd.debian.org/status/package.php?p=gatb-core
[3] https://tracker.debian.org/pkg/discosnp

On Sat, Feb 09, 2019 at 12:48:07PM +0100, Matthias Klose wrote:
> Package: src:discosnp
> Version: 2.3.0-1
> Severity: serious
> Tags: sid buster
> 
> Impossible Depends: discosnp -> gatb-core/amd64
> Impossible Depends: discosnp -> gatb-core/arm64
> Impossible Depends: discosnp -> gatb-core/i386
> Impossible Depends: discosnp -> gatb-core/mips64el
> Impossible Depends: discosnp -> gatb-core/ppc64el
> Impossible Depends: discosnp -> gatb-core/s390x
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de



Re: my first debian package

2019-02-03 Thread Andreas Tille
On Sun, Feb 03, 2019 at 02:48:38PM +0800, Paul Wise wrote:
> of the repository to git and continue from there. You can also skip
> the conversion and just checkout the latest svn revision and continue
> from there.

May be its easier and in the end more sensible to create a Git archive
via

gbp import-dscs --ignore-repo-config --debsnap --pristine-tar pyfltk

which conserves the main important parts of history without any
hassle to deal with archived svn.

Kind regards

 Andreas
 
> https://tracker.debian.org/pkg/pyfltk
> https://alioth-archive.debian.org/svn/python-modules.tar.xz
> https://snapshot.debian.org/package/pyfltk/

-- 
http://fam-tille.de



Error only occures on sid but not on testing

2019-02-01 Thread Andreas Tille
Hi,

since I wanted to track down this issue I tried

t_coffee -aln sproteases_small.cw_aln sproteases_small.muscle 
sproteases_small.tc_aln -outfile combined_aln.aln

on my usual testing machine.  However, when running on sid I get the
reported error:

*
*FULL TRACE BACK PID: 23180 
   
23197 -- ERROR: COREDUMP: T-COFFEE Version_12.00.7fb08c2 (2018-12-11 09:27:12 - 
Revision 7fb08c2 - Build 211)
*

Unfortunately just starting plainly under gdb does not change anything.

Any idea how to track down this besides adding debugging printf into the
code?

Kind regards

   Andreas.

-- 
http://fam-tille.de



doxygen fails for cimg when build under unstable but not under testing

2019-01-26 Thread Andreas Tille
Hi,

I'd like to update cimg[1] but the build fails in an unstable
chroot due to an invalid LaTeX file

...
[26] [27]) [28] (./group__cimg__displays.tex) [29] (./group__cimg__storage.tex)
 [30] (./group__cimg__files__io.tex) [31] (./group__cimg__options.tex
! Missing } inserted.
 
}
l.10 \end{DoxyParams}
 
?

If I build the package on a testing system it builds fine.  Strangely
enough the doxygen version is the same under testing and unstable.

Any idea how to fix this?

Kind regards

   Andreas.

[1] https://salsa.debian.org/science-team/cimg

-- 
http://fam-tille.de



Cmake is seeking for OpenCV legacy in libsitplus

2019-01-25 Thread Andreas Tille
Hi,

to upgrade package sitplus I need to package libsitplus[1].  I made some
progress to adjust Build-Depends and some cmake patches but I'm now
running into:

CMake Error at 
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find OpenCV (missing: legacy) (found version "3.2.0")
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/OpenCV/OpenCVConfig.cmake:260 (find_package_handle_standard_args)
  src/mod_vision/CMakeLists.txt:4 (FIND_PACKAGE)


which is triggert by the line

  FIND_PACKAGE( OpenCV REQUIRED core imgproc legacy)

I have no idea what this "legacy" part of OpenCV might be and
how I can provide it.  Any ideas?

Kind regards

 Andreas.


[1] https://salsa.debian.org/med-team/libsitplus

-- 
http://fam-tille.de



Re: cmake issue with minia: include could not find load file (GatbCore)

2019-01-22 Thread Andreas Tille
On Mon, Jan 21, 2019 at 07:58:29PM -, Sune Vuorela wrote:
> On 2019-01-21, Andreas Tille  wrote:
> > Is there any way to make cmake more verbose where it is seeking for files
> > to include?
> 
> cmake --trace 
> 
> at least give you more debugging info than you could ever wish for.

Thanks a lot, that was very helpful, Andreas.

-- 
http://fam-tille.de



cmake issue with minia: include could not find load file (GatbCore)

2019-01-21 Thread Andreas Tille
Hi,

I try to update minia[1] to its latest upstream version but cmake runs into:

CMake Error at CMakeLists.txt:66 (include):
  include could not find load file:

GatbCore

However, the build dependency libgatbcore-dev provides the according
cmake input file:

dpkg -L libgatbcore-dev | grep GatbCore
/usr/lib/x86_64-linux-gnu/cmake/GatbCore.cmake

and I verified that this is available in the pbuilder chroot.

Is there any way to make cmake more verbose where it is seeking for files
to include?

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/minia

-- 
http://fam-tille.de



Elastix: dh_testroot: You must run this as root (or use fakeroot).

2019-01-14 Thread Andreas Tille
Hi,

I intend to upgrade elastix[1] but I'm running into:


...
[100%] Built target itkMevisDicomTiffImageIOTest
make[2]: Leaving directory '/build/elastix-4.9.0/obj-x86_64-linux-gnu'
/usr/bin/cmake -E cmake_progress_start 
/build/elastix-4.9.0/obj-x86_64-linux-gnu/CMakeFiles 0
make[1]: Leaving directory '/build/elastix-4.9.0/obj-x86_64-linux-gnu'
   create-stamp debian/debhelper-build-stamp
 fakeroot debian/rules binary
dh binary-arch --no-parallel
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
   dh_testroot -a -O--no-parallel
ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded 
(cannot open shared object file): ignored.
dh_testroot: You must run this as root (or use fakeroot).
make: *** [debian/rules:12: binary-arch] Error 255
dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned exit 
status 2


I was able to build this package today with minor changes (on a
different machine but always in up to date pbuilder chroot).  Any
idea what might be wrong here?

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/elastix

-- 
http://fam-tille.de



Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

2019-01-10 Thread Andreas Tille
Hi Sune,

On Thu, Jan 10, 2019 at 06:27:47PM +, Sune Vuorela wrote:
> ...
> I looked briefly at the code, but I didn't feel like actually trying to
> understand what's going on.

Thanks a lot for this detailed analysis.  I'll forward it to bug #907624
and the upstream issue[1].  I admit I also will not try to understand
the code since I not even have an idea what the program is supposed to
do.

I think we have now provided sufficient input for upstream to track down
the issue.

Thanks again

   Andreas.

[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7

-- 
http://fam-tille.de



How to sneak -llib into meson.build

2019-01-10 Thread Andreas Tille
Hi,

I'm busy packaging libbasr[1] and try to use the Debian packaged
libhdf5-dev.  I managed to take the configure and compile step but if it
comes to the linker the flag -lhdf5_cpp is missing and all symbols of
the hdf5 library are not found.  Is there an easy way to sneak this
into a meson.build file?

Thanks for any hint

Andreas.

[1] https://salsa.debian.org/med-team/libblasr

-- 
http://fam-tille.de



Re: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

2019-01-09 Thread Andreas Tille
Hi,

On Thu, Jan 10, 2019 at 02:14:14AM +0500, Andrey Rahmatullin wrote:
> On Wed, Jan 09, 2019 at 09:42:43PM +0100, Andreas Tille wrote:
> > to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
> > that the elements of a structure are not accessible:
> > 
> >(gdb) print entry->offset
> >Cannot access memory at address 0x7
> It's because entry is 0x7.

When I was running the code with some more debugging info activated[1]
I had pretty valid looking adresses 0x555666 (or something in that line
just remembering by heart - can activate the patch if needed).  I have
no idea why the address is this without that extra debug code.
 
> > The values of the structure are set in line 350[3] and are OK there.
> The problem is not about the structure fields but about the structure
> pointer itself though.
> ...
> You need to find out why one of the tree nodes has an invalid address.

Can you propose any means to find this out?  I have no idea about
specific compiler differences.  BTW, I also tried to set -O0 but this
did not avoided the SIGSEGV.

Thanks for your hint anyway

  Andreas.

[1] 
https://salsa.debian.org/med-team/ffindex/blob/master/debian/patches/debug_segfault

-- 
http://fam-tille.de



Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

2019-01-09 Thread Andreas Tille
Hi,

as reported in bug #907624 ffindex autopkgtest fails with SIGSEGV in sid
and buster.  I've tested in stretch (gcc 6.3) and the code works fine.
I've reported upstream[1] the results of my gdb session where I was able
to find the exact code line[2] where the SIGSEGV is thrown.  It turns out
that the elements of a structure are not accessible:

   (gdb) print entry->offset
   Cannot access memory at address 0x7

(full gdb log under [1] or in the bug log).

In fact I tried in some more detailed debugging that any attempt to
access one of the structure elements even for instance only injecting
something like 

   if ( !entry->offset ) {

in line 554 will trigger the SIGSEGV.  The values of the structure are
set in line 350[3] and are OK there.  The funktion that contains the
failing line is action() [4] and called via a pointer to this function
in line 563[5] (I admit I have no real idea why this pointer to a
function should be needed.  Its the only function that is used in this
place and IMHO only adds an extra layer of complexity.)

The structure is declared in the header file[6].

I admit I fail to see why the code works under stretch with gcc 6.3
but fails with gcc 8.2.

Any idea?

Kind regards

   Andreas.


[1] https://github.com/soedinglab/ffindex_soedinglab/issues/7
[2] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L554
[3] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L350
[4] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L541
[5] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.c#L563
[6] https://salsa.debian.org/med-team/ffindex/blob/master/src/ffindex.h#L30

-- 
http://fam-tille.de



Re: Cmake help needed: Fails to find check.h and ieeefp.h

2018-12-04 Thread Andreas Tille
On Tue, Dec 04, 2018 at 12:04:36AM +0500, Andrey Rahmatullin wrote:
> On Mon, Dec 03, 2018 at 07:19:52PM +0100, Andreas Tille wrote:
> > I try to build the latest libsbml[1] in Git but I was running
> > into:
> Why do you think it's a problem? It's not.

Since cmake decided to mention it in build/CMakeFiles/CMakeError.log
and gave an explicit hint to read this file.

> Again, please learn how to read the program output including the build
> system output. Your build fails with the following error:
> 
> CMake Error at src/bindings/r/CMakeLists.txt:339 (get_target_property):
>   The LOCATION property may not be read from target "binding_r_lib".  Use the
>   target name directly with add_custom_command, or use the generator
>   expression $, as appropriate.

... while this was not mentioned in CMakeError.log.

Thanks for the helpful hint anyway

   Andreas.

-- 
http://fam-tille.de



Re: Cmake help needed: Fails to find check.h and ieeefp.h

2018-12-03 Thread Andreas Tille
Hi Ferenc,

thanks a lot for your helpful hints which solved at least half of
my problem.

On Mon, Dec 03, 2018 at 07:46:30PM +0100, Ferenc Wágner wrote:
> Andreas Tille  writes:
> 
> > I explicitly added "Build-Depends: libnewlib-dev" und thus there is
> >
> > find /usr/include -name ieeefp.h
> > /usr/include/newlib/ieeefp.h
> > /usr/include/newlib/machine/ieeefp.h
> 
> Use #include  or pass -Inewlib to the compiler (I don't
> know whether that's a good idea).

How to pass -Inewlib option to the

   check_include_files (ieeefp.h HAVE_IEEEFP_H)

specifically in a way that it persists for resulting commands to finally
build the code?
 
> > I have no idea what check.h is seeked in src/CMakeLists.txt which has
> 
> Have you got the 'check' package installed?

I've added it to Build-Depends and that error vanished now.

Kind regards

   Andreas. 

-- 
http://fam-tille.de



Cmake help needed: Fails to find check.h and ieeefp.h

2018-12-03 Thread Andreas Tille
Hi,

I try to build the latest libsbml[1] in Git but I was running
into:

cat /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeError.log
Determining if files check.h exist failed with the following output:
Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_71faf/fast"
make[2]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_71faf.dir/build.make 
CMakeFiles/cmTC_71faf.dir/build
make[3]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o
/usr/bin/cc   -g -O2 -fdebug-prefix-map=/build/libsbml-5.17.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-fPIC-o CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o   -c 
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_CHECK_H.c
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_CHECK_H.c:2:10:
 fatal error: check.h: No such file or directory
 #include 
  ^
compilation terminated.
make[3]: *** [CMakeFiles/cmTC_71faf.dir/build.make:66: 
CMakeFiles/cmTC_71faf.dir/HAVE_CHECK_H.c.o] Error 1
make[3]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_71faf/fast] Error 2
make[2]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'

Source:
/* */
#include 


int main(void){return 0;}

Determining if files ieeefp.h exist failed with the following output:
Change Dir: /build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_8b304/fast"
make[2]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
/usr/bin/make -f CMakeFiles/cmTC_8b304.dir/build.make 
CMakeFiles/cmTC_8b304.dir/build
make[3]: Entering directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o
/usr/bin/cc   -g -O2 -fdebug-prefix-map=/build/libsbml-5.17.0+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing 
-fPIC-o CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o   -c 
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_IEEEFP_H.c
/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CheckIncludeFiles/HAVE_IEEEFP_H.c:2:10:
 fatal error: ieeefp.h: No such file or directory
 #include 
  ^~
compilation terminated.
make[3]: *** [CMakeFiles/cmTC_8b304.dir/build.make:66: 
CMakeFiles/cmTC_8b304.dir/HAVE_IEEEFP_H.c.o] Error 1
make[3]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'
make[2]: *** [Makefile:121: cmTC_8b304/fast] Error 2
make[2]: Leaving directory 
'/build/libsbml-5.17.0+dfsg/build/CMakeFiles/CMakeTmp'

Source:
/* */
#include 


int main(void){return 0;}



I explicitly added "Build-Depends: libnewlib-dev" und thus there is

find /usr/include -name ieeefp.h
/usr/include/newlib/ieeefp.h
/usr/include/newlib/machine/ieeefp.h


I have no idea what check.h is seeked in src/CMakeLists.txt which has

# create libsbml-config-common.h
#
include(CheckIncludeFiles)
check_include_files (check.h HAVE_CHECK_H)
check_include_files (expat.h HAVE_EXPAT_H)
check_include_files (errno.h HAVE_ERRNO_H)
check_include_files (ieeefp.h HAVE_IEEEFP_H)


but I know that the configure step worked in end of May when I did my
last attempt to build that code.  Unfortunately there seems to be some
issue with codesearch.d.n (I get "The results may be incomplete, not all
Debian Code Search servers are okay right now." and no results) so I
hope somebody can give a hint how to pass the configure step
successfully.

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/libsbml

-- 
http://fam-tille.de



Re: bison/flex (?) issue: error: cannot convert 'UserLevelRewritingContext::ParseResult*' to 'char*'

2018-09-18 Thread Andreas Tille
Hi Sergio

On Wed, Sep 19, 2018 at 12:50:37AM -0400, Sergio Durigan Junior wrote:
> On Sunday, September 16 2018, Andreas Tille wrote:
> 
> > Hi,
> >
> > in the latest version of maude[1] I get:
> >
> > ...
> > g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/Utility -I../../src/Temporal 
> > -I../../src/Interface -I../../src/Core -I../../src/Variable 
> > -I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory 
> > -I../../src/S_Theory -I../../src/NA_Theory -I../../src/FreeTheory 
> > -I../../src/ObjectSystem -I../../src/Mixfix -I../../src/BuiltIn 
> > -I../../src/MSCP10 -I../../src/IO_Stuff -I../../src/ACU_Persistent 
> > -I../../src/ACU_Theory -I../../src/AU_Persistent -I../../src/AU_Theory 
> > -I../../src/Meta -I../../src/3rdParty -I../../src/FullCompiler 
> > -I../../src/StrategyLanguage -I../../src/SMT -Wdate-time 
> > -D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/build/maude-2.7.1=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -fpermissive -c 
> > -o libmixfix_a-surface.o `test -f 'surface.cc' || echo './'`surface.cc
> > surface.c: In function 'int yyparse(void*, 
> > UserLevelRewritingContext::ParseResult*)':
> > surface.c:5382:16: warning: invalid conversion from 'void*' to 
> > 'UserLevelRewritingContext::ParseResult*' [-fpermissive]
> > surface.c:5382:31: error: cannot convert 
> > 'UserLevelRewritingContext::ParseResult*' to 'char*'
> > surface.yy:97:80: note:   initializing argument 2 of 'void 
> > yyerror(UserLevelRewritingContext::ParseResult*, char*)'
> >  static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, 
> > char *s);
> >   
> > ~~^
> > surface.c:5526:12: warning: invalid conversion from 'void*' to 
> > 'UserLevelRewritingContext::ParseResult*' [-fpermissive]
> > surface.c:5526:27: error: cannot convert 
> > 'UserLevelRewritingContext::ParseResult*' to 'char*'
> > surface.yy:97:80: note:   initializing argument 2 of 'void 
> > yyerror(UserLevelRewritingContext::ParseResult*, char*)'
> >  static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, 
> > char *s);
> >   
> > ~~^
> > surface.yy:313:12: warning: ignoring return value of 'int system(const 
> > char*)', declared with attribute warn_unused_result [-Wunused-result]
> >   system((string("ls") + $3).c_str());
> >   ~~^~
> > make[6]: *** [Makefile:1110: libmixfix_a-surface.o] Error 1
> > ...
> >
> > I suspect bison/flex might have created a broken C++ file.  Any idea how
> > to fix this?
> 
> Hey Andreas,
> 
> Short:
> 
> Yeah, if you remove debian/patches/bison-parse-param.patch, it compiles
> successfully.

Cool.  I can confirm this and pushed the change to Git.
 
> Long:
> 
> I haven't investigated a lot, but apparently the parser used
> YYPARSE_PARAM to define 'UserLevelRewritingContext::ParseResult*' as a
> possible argument for the reentrant parser.  However, at some point the
> code was rewritten to explicitly use and pass
> 'UserLevelRewritingContext::ParseResult*', without resorting to
> YYPARSE_PARAM.  For that reason, there's no need to define "%parse-param
> {void* YYPARSE_PARAM}" in the beginning of the parser code anymore.
 
Thanks a lot for the detailed explanation.

> Now, after this fix, I'm seeing another error:
> 
>   variableGenerator.cc: In member function 'CVC4::Expr 
> VariableGenerator::dagToCVC4(DagNode*)':
>   variableGenerator.cc:326:73: error: 'IFF' is not a member of 'CVC4::kind'
> return exprManager->mkExpr(((smtType == SMT_Info::BOOLEAN) ? 
> kind::IFF : kind::EQUAL), exprs[0], exprs[1]);
>^~~
> 
> CVC4 indeed doesn't have any 'kind::IFF'.  I spent some time looking at
> its source code, but couldn't find anything helpful.  I can try to work
> more later.

I admit I also have no clue.

@Scott: You initially worked on this package.  Will you continue with
this and may be you have some clue about the issue above?

Kind regards

 Andreas.

-- 
http://fam-tille.de



bison/flex (?) issue: error: cannot convert 'UserLevelRewritingContext::ParseResult*' to 'char*'

2018-09-16 Thread Andreas Tille
Hi,

in the latest version of maude[1] I get:

...
g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/Utility -I../../src/Temporal 
-I../../src/Interface -I../../src/Core -I../../src/Variable 
-I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory 
-I../../src/S_Theory -I../../src/NA_Theory -I../../src/FreeTheory 
-I../../src/ObjectSystem -I../../src/Mixfix -I../../src/BuiltIn 
-I../../src/MSCP10 -I../../src/IO_Stuff -I../../src/ACU_Persistent 
-I../../src/ACU_Theory -I../../src/AU_Persistent -I../../src/AU_Theory 
-I../../src/Meta -I../../src/3rdParty -I../../src/FullCompiler 
-I../../src/StrategyLanguage -I../../src/SMT -Wdate-time -D_FORTIFY_SOURCE=2  
-g -O2 -fdebug-prefix-map=/build/maude-2.7.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -fpermissive -c -o libmixfix_a-surface.o `test 
-f 'surface.cc' || echo './'`surface.cc
surface.c: In function 'int yyparse(void*, 
UserLevelRewritingContext::ParseResult*)':
surface.c:5382:16: warning: invalid conversion from 'void*' to 
'UserLevelRewritingContext::ParseResult*' [-fpermissive]
surface.c:5382:31: error: cannot convert 
'UserLevelRewritingContext::ParseResult*' to 'char*'
surface.yy:97:80: note:   initializing argument 2 of 'void 
yyerror(UserLevelRewritingContext::ParseResult*, char*)'
 static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, char 
*s);
  
~~^
surface.c:5526:12: warning: invalid conversion from 'void*' to 
'UserLevelRewritingContext::ParseResult*' [-fpermissive]
surface.c:5526:27: error: cannot convert 
'UserLevelRewritingContext::ParseResult*' to 'char*'
surface.yy:97:80: note:   initializing argument 2 of 'void 
yyerror(UserLevelRewritingContext::ParseResult*, char*)'
 static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, char 
*s);
  
~~^
surface.yy:313:12: warning: ignoring return value of 'int system(const char*)', 
declared with attribute warn_unused_result [-Wunused-result]
  system((string("ls") + $3).c_str());
  ~~^~
make[6]: *** [Makefile:1110: libmixfix_a-surface.o] Error 1
...

I suspect bison/flex might have created a broken C++ file.  Any idea how
to fix this?

Kind regards

   Andreas.

[1] https://salsa.debian.org/med-team/maude 

-- 
http://fam-tille.de



Re: How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed

2018-09-10 Thread Andreas Tille
Hi Andrey,

On Mon, Sep 10, 2018 at 07:40:45PM +0500, Andrey Rahmatullin wrote:
> > is correct behaviour and return code is 0.  
> You are not running this in a minimal chroot.
> 
> # pkg-config --cflags pbbam
> Package zlib was not found in the pkg-config search path.
> Perhaps you should add the directory containing `zlib.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'zlib', required by 'htslib', not found
> 
> I've submitted #908501 against libhts-dev.

Good catch.  Meanwhile I've added zlib1g-dev directly to Build-Depends
of this package and it turned out that also libhdf5-dev is needed
(including an according patch for meson.build.  Unfortunately there are
remaining issues related to hdf5 lib:

...
c++ -Iblasr@sha -I. -I.. -I../ -I/usr/include/hdf5/serial 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++11 -g -O2 
-fdebug-prefix-map=/build/libblasr-5.3.1=. -fstack-protecto
In file included from ../hdf/HDFAtom.cpp:1:
../hdf/HDFAtom.hpp: In member function ‘int HDFAtom::Initialize(H5::H5File&, 
const string&, const string&)’:
../hdf/HDFAtom.hpp:64:44: error: no matching function for call to 
‘HDFGroup::Initialize(H5::H5File&, const string&)’
 group.Initialize(hdfFile, groupName);
^
In file included from ../hdf/HDFData.hpp:10,
 from ../hdf/HDFAtom.hpp:12,
 from ../hdf/HDFAtom.cpp:1:
../hdf/HDFGroup.hpp:28:9: note: candidate: ‘int 
HDFGroup::Initialize(H5::Group&, std::__cxx11::string)’
 int Initialize(H5::Group& fg, std::string groupName);
 ^~
../hdf/HDFGroup.hpp:28:9: note:   no known conversion for argument 1 from 
‘H5::H5File’ to ‘H5::Group&’
../hdf/HDFGroup.hpp:30:9: note: candidate: ‘int HDFGroup::Initialize(HDFGroup&, 
std::__cxx11::string)’
 int Initialize(HDFGroup& parentGroup, std::string groupName);
 ^~
../hdf/HDFGroup.hpp:30:9: note:   no known conversion for argument 1 from 
‘H5::H5File’ to ‘HDFGroup&’
...

Any idea how to fix this?

Kind regards

Andreas.



-- 
http://fam-tille.de



Re: Packaging in git and Files-Excluded

2018-09-10 Thread Andreas Tille
Hi,

On Sun, Sep 09, 2018 at 12:09:00PM +0200, Birger Schacht wrote:
> i'm trying to package a software using git and importing upstream
> releases from git tags. There are files in the git tree that have to be
> removed to make the package dfsg compliant (what would normally happen
> through repackaging). I figured i can just create a git tag
> upstrea/0.1.2-ds which does exclude the non dfsg compliant files. But
> now i'm not sure how to create that tag- should i create a branch of the
> tag, remove the files and tag that branch? Is there a best practice how
> that branch should be called? I didn't find anything regarding this
> situation in DEP14.

As far as I know Files-Excluded is just about repackaging since it
is consumed by uscan which is downloading and optionally repackaging
a tarball.  Is there any reason not to use uscan as intended and than
use

gbp import-orig --pristine-tar downloaded_repackaged_tarball

?

Kind regards

   Andreas.

-- 
http://fam-tille.de



How to make meson accept that `pkg-config --cflags ` has empty result in case only /usr/include is needed

2018-09-10 Thread Andreas Tille
Hi,

it seems that if a pkg-config file just has

prefix=/usr
includedir=${prefix}/include
Cflags: -I${includedir}

the call

  pkg-config --cflags libfoo

returns nothing which makes sense.  This is for instance the case for
/usr/lib/*/pkgconfig/pbbam.pc of libpbbam-dev and I think that

$ pkg-config --cflags pbbam

$ echo $?
0

is correct behaviour and return code is 0.  However when I try to build
the new package libblasr[1] against this lib I get:


...
Found pkg-config: /usr/bin/pkg-config (0.29)
Determining dependency 'pbbam' with pkg-config executable '/usr/bin/pkg-config'
Called `/usr/bin/pkg-config --modversion pbbam` -> 0
0.18.0
Called `/usr/bin/pkg-config --cflags pbbam` -> 1


meson.build:52:0: ERROR:  Could not generate cargs for pbbam:


I have no idea why meson considers the normal behaviour as error neither
do I have a clue how to convince meson to accept this argument.

Any help would be welcome

  Andreas.


[1] https://salsa.debian.org/med-team/libblasr

-- 
http://fam-tille.de



C++ help needed for yellyfish: "error: catching polymorphic type"

2018-09-03 Thread Andreas Tille
Hi,

I'm trying to build the latest version of jellyfish which I pushed to
Salsa[1].  Unfortunately I'm running into


g++ -DHAVE_CONFIG_H -I.  -Wall -Wnon-virtual-dtor -I. -I./include  -Wdate-time 
-D_FORTIFY_SOURCE=2   -Werror -std=c++11 -g -O2 
-fdebug-prefix-map=/build/jellyfish-2.2.10=. -fstack-protector-strong -Wformat 
-Werror=format-security -c -o sub_commands/count_main.o 
sub_commands/count_main.cc
sub_commands/count_main.cc: In function 'int count_main(int, char**)':
sub_commands/count_main.cc:363:28: error: catching polymorphic type 'class 
MergeError' by value [-Werror=catch-value=]
 } catch(MergeError e) {
^
In file included from sub_commands/count_main.cc:38:
./include/jellyfish/hash_counter.hpp: In instantiation of 'bool 
jellyfish::cooperative::hash_counter::double_size(bool) [with Key = 
jellyfish::mer_dna_ns::mer_base_static; word = long 
unsigned int; atomic_t = atomic::gcc; mem_block_t = allocators::mmap]':
./include/jellyfish/hash_counter.hpp:189:28:   required from 'bool 
jellyfish::cooperative::hash_counter::handle_full_ary() [with Key = 
jellyfish::mer_dna_ns::mer_base_static; word = long 
unsigned int; atomic_t = atomic::gcc; mem_block_t = allocators::mmap]'
./include/jellyfish/hash_counter.hpp:167:7:   required from 'bool 
jellyfish::cooperative::hash_counter::update_add(const Key&, uint64_t, Key&) [with Key = 
jellyfish::mer_dna_ns::mer_base_static; word = long 
unsigned int; atomic_t = atomic::gcc; mem_block_t = allocators::mmap; uint64_t 
= long unsigned int]'
sub_commands/count_main.cc:176:11:   required from 'void 
mer_counter_base::start(int) [with MerIteratorType 
= mer_qual_iterator; ParserType = sequence_qual_parser]'
sub_commands/count_main.cc:151:16:   required from here
./include/jellyfish/hash_counter.hpp:216:9: error: catching polymorphic type 
'class 
jellyfish::large_hash::array_base, long unsigned int, atomic::gcc, 
jellyfish::large_hash::unbounded_array, long unsigned int, atomic::gcc, allocators::mmap> 
>::ErrorAllocation' by value [-Werror=catch-value=]
   } catch(typename array::ErrorAllocation e) {
 ^
cc1plus: all warnings being treated as errors


My weak attempt to ignore this for the moment via 

   export DEB_CFLAGS_MAINT_APPEND = -Wno-error=catch-value

in d/rules failed.  Any better hint, how to deal with this?

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/jellyfish

-- 
http://fam-tille.de



Help for qmake in package bandage needed

2018-08-26 Thread Andreas Tille
Hi,

I try to package bandage[1] which is has a qmake based build system.
Unfortunately the default rules files ends up in:

...
   dh_auto_configure
qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/build/bandage-0.8.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr
Usage: /usr/lib/qt5/bin/qmake [mode] [options] [files]

QMake has two modes, one mode for generating project files based on
some heuristics, and the other for generating makefiles. Normally you
shouldn't need to specify a mode, as makefile generation is the default
mode for qmake, but you may use this to test qmake on an existing project

Mode:
  -project   Put qmake into project file generation mode
 In this mode qmake interprets files as files to
 be built,
 defaults to *; *; *; *.ts; *.xlf; *.qrc
 Note: The created .pro file probably will 
 need to be edited. For example add the QT variable to 
 specify what modules are required.
  -makefile  Put qmake into makefile generation mode (default)
 In this mode qmake interprets files as project files to
 be processed, if skipped qmake will try to find a project
 file in your current working directory

...
dh_auto_configure: qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/build/bandage-0.8.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr returned exit code 1
make: *** [debian/rules:20: build] Error 2


Any idea what might be wrong here?

Kind regards

 Andreas.


[1] https://salsa.debian.org/med-team/bandage

-- 
http://fam-tille.de



Re: C++ help needed for new version of pbdagcon

2018-08-18 Thread Andreas Tille
On Sat, Aug 18, 2018 at 09:18:58AM +0800, Paul Wise wrote:
> On Fri, Aug 17, 2018 at 10:44 PM, Andrey Rahmatullin wrote:
> 
> > Looks like the project code was updated for s/HITS_DB/DAZZ_DB/ but the
> > DAZZ_DB submodule snapshot was not updated. Ask the upstream.
> 
> This sounds like an embedded code copy, you might want to talk to
> upstream to find out and get it removed.
> 
> https://wiki.debian.org/EmbeddedCodeCopies

Upstream has turned out to be not very responsive and regarding the
code copy you might like to read here:

https://lists.debian.org/debian-med/2018/07/msg00088.html

Kind regards

 Andreas. 

-- 
http://fam-tille.de



C++ help needed for new version of pbdagcon

2018-08-17 Thread Andreas Tille
Hi,

I've updated pbdagcon[1] to latest upstream commit.  Unfortunately the
build fails with:


...
g++ -g -O2 -fdebug-prefix-map=/build/pbdagcon-0.3+git20180411.c14c422+ds=. 
-fstack-protector-strong -Wformat -Werror=format-security -O3 -std=c++11 -Wall 
-Wuninitialized -pedantic -Wdate-time -D_FORTIFY_SOURCE=
In file included from DazAlnProvider.cpp:10:
DazAlnProvider.hpp:97:19: error: expected ')' before '&' token
 Target(DAZZ_DB& db, int tspace, int small);
   ~   ^
   )
DazAlnProvider.hpp:122:5: error: 'DAZZ_DB' does not name a type
 DAZZ_DB db_;
 ^~~
DazAlnProvider.hpp:161:5: error: 'DAZZ_DB' does not name a type
 DAZZ_DB db_;
 ^~~
DazAlnProvider.cpp: In constructor 'DazAlnProvider::DazAlnProvider(const 
ProgramOpts&)':
DazAlnProvider.cpp:34:33: error: 'db_' was not declared in this scope
 int status = Open_DB(path, _);
 ^~~
DazAlnProvider.cpp: In destructor 'virtual DazAlnProvider::~DazAlnProvider()':
DazAlnProvider.cpp:74:15: error: 'db_' was not declared in this scope
 Close_DB(_);
   ^~~
DazAlnProvider.cpp: In member function 'virtual bool 
DazAlnProvider::nextTarget(std::__cxx11::string&, 
std::vector&)':
DazAlnProvider.cpp:125:25: error: 'db_' was not declared in this scope
 seq = Load_Subread(_, trg_->id, 0, trg_->length, targSeqBuf_, 0);
 ^~~
DazAlnProvider.cpp: At global scope:
DazAlnProvider.cpp:225:15: error: expected constructor, destructor, or type 
conversion before '(' token
 Target::Target(DAZZ_DB& db, int tspace, int small) :
   ^
DazAlnProvider.cpp: In member function 'void Target::firstRecord(Record&, 
bool)':
...


Any hint how to fix this?


Kind regards

Andreas.


[1] https://salsa.debian.org/med-team/pbdagcon

-- 
http://fam-tille.de



Re: automake issue in virtuoso: "library has 'libwi_odbc_la' as canonical name (possible typo)"

2018-08-14 Thread Andreas Tille
Hi Andrey,

On Tue, Aug 14, 2018 at 08:47:11PM +0500, Andrey Rahmatullin wrote:
> On Tue, Aug 14, 2018 at 05:33:01PM +0200, Andreas Tille wrote:
> > > On Tue, Aug 14, 2018 at 04:21:10PM +0200, Andreas Tille wrote:
> > > > libsrc/Wi/Makefile.am:544: library has 'libwi_base_la' as canonical 
> > > > name (possible typo)
> > > This is correct, there is a var named libwi_base_la_cflags which seems to
> > > be a generic var so it should be renamed to something not looking like
> > > foo_cflags automake var.
> > 
> > That's why I did s/cflags/CFLAGS/.
> Ah, I was assuming the vars are case insensitive so the original name is
> problematic.

I assumed that Makefile variables are case sensitive and so Makefile.am
variables are.  I've never seen lower case spelling in those cases.

> Do you have the same error without that change? Because the
> canonical names of automake target vars are foo_CFLAGS.

Automake was warning about typos and from what I can see these are
simply typos.
 
> > > > libsrc/Wi/Makefile.am:574: warning: variable 'libwi_odbc_la_LDFLAGS' is 
> > > > defined but no program or
> > > > libsrc/Wi/Makefile.am:574: library has 'libwi_odbc_la' as canonical 
> > > > name (possible typo)
> > > This is because that library is indeed not defined.
> > > 
> > > > I searched the web for
> > > >"library has" + "as canonical name (possible typo)"
> > > Well, the error messages say "no program or library has that name" which
> > > is correct:
> > > 
> > > noinst_LTLIBRARIES = libwi.la libwic.la
> > > 
> > > So this is just dead code.
> > 
> > OK, I think I fixed this specifiv Makefile.am[1]. 
> So you've enabled building IODBC_LIBS? Why? It is disabled by the
> upstream.

It's a conditional variable (further above in Makefile.am).  I see no
point in uncommenting it since it can be enabled or disabled via flags.
When enabling it the automake bug goes away and thus I assumed that
would just have been a regression from some upstream change.

> And you made a libwi_base.la which is not what was intended. As I said,
> libwi_base_la_cflags is a generic var meant to be included in other vars.
> And are you sure you need to fix those "LDLAGS" if it was that way in the
> upstream code?

May be I misunderstood your hint.  What less invasive / more upstream
intended patch would you suggest?
 
Kind regards

Andreas.

-- 
http://fam-tille.de



Re: automake issue in virtuoso: "library has 'libwi_odbc_la' as canonical name (possible typo)"

2018-08-14 Thread Andreas Tille
Hi Andrey,

On Tue, Aug 14, 2018 at 07:47:51PM +0500, Andrey Rahmatullin wrote:
> On Tue, Aug 14, 2018 at 04:21:10PM +0200, Andreas Tille wrote:
> > libsrc/Wi/Makefile.am:544: library has 'libwi_base_la' as canonical name 
> > (possible typo)
> This is correct, there is a var named libwi_base_la_cflags which seems to
> be a generic var so it should be renamed to something not looking like
> foo_cflags automake var.

That's why I did s/cflags/CFLAGS/.

> > libsrc/Wi/Makefile.am:574: warning: variable 'libwi_odbc_la_LDFLAGS' is 
> > defined but no program or
> > libsrc/Wi/Makefile.am:574: library has 'libwi_odbc_la' as canonical name 
> > (possible typo)
> This is because that library is indeed not defined.
> 
> > I searched the web for
> >"library has" + "as canonical name (possible typo)"
> Well, the error messages say "no program or library has that name" which
> is correct:
> 
> noinst_LTLIBRARIES = libwi.la libwic.la
> 
> So this is just dead code.

OK, I think I fixed this specifiv Makefile.am[1].  I learned that there
are more issues of this kind in other Makefile.am.  Hope to be able to
deal with this thanks to you hints.

Kind regards

  Andreas.


[1] 
https://salsa.debian.org/science-team/virtuoso-opensource/commit/2a88abfb3bde303be1984090f08c34483abfcebe

-- 
http://fam-tille.de



automake issue in virtuoso: "library has 'libwi_odbc_la' as canonical name (possible typo)"

2018-08-14 Thread Andreas Tille
Hi,

I've commited the latest free version of virtuoso to Debian Science git[1].
Unfortunately automake fails.  I even tried inside build chroot:


/build/virtuoso-opensource-7.2.4.2+dfsg# ./autogen.sh 

Checking build environment ...
Using aclocal (GNU automake) 1.16.1
Using autoconf (GNU Autoconf) 2.69
Using autoheader (GNU Autoconf) 2.69
Using automake (GNU automake) 1.16.1
Using libtoolize (GNU libtool) 2.4.6
Using bison (GNU Bison) 3.0.4
Using flex 2.6.4
Using GNU Awk 4.1.4, API: 1.1 (GNU MPFR 4.0.1, GNU MP 6.1.2)
Using GNU gperf 3.1
Using OpenSSL 1.1.0h  27 Mar 2018

Generating build scripts ...
Running libtoolize ...
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'binsrc/config'.
libtoolize: copying file 'binsrc/config/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'binsrc/config'.
libtoolize: copying file 'binsrc/config/libtool.m4'
libtoolize: copying file 'binsrc/config/ltoptions.m4'
libtoolize: copying file 'binsrc/config/ltsugar.m4'
libtoolize: copying file 'binsrc/config/ltversion.m4'
libtoolize: copying file 'binsrc/config/lt~obsolete.m4'
Running aclocal ...
Running autoheader ...
Running automake ...

** ERROR **
libsrc/Wi/Makefile.am:544: library has 'libwi_base_la' as canonical name 
(possible typo)
libsrc/Wi/Makefile.am:574: warning: variable 'libwi_odbc_la_LDFLAGS' is defined 
but no program or
libsrc/Wi/Makefile.am:574: library has 'libwi_odbc_la' as canonical name 
(possible typo)

Bootstrap script aborting (see autogen.log for details) ...



I searched the web for
   "library has" + "as canonical name (possible typo)"

which basically advised to seek for typos and I even fixed several of
those[2] but either that's not in all cases the solution or it is
something else behind this error.  I admit I'm also a bit suspicious
about adding -static flag to _la libraries.

Any hint what might be wrong here?

Kind regards

   Andreas.

[1] https://salsa.debian.org/science-team/virtuoso-opensource
[2] 
https://salsa.debian.org/science-team/virtuoso-opensource/blob/master/debian/patches/fix_makefile.am.patch

-- 
http://fam-tille.de



libmuscle does not build any more - probably some issue of newer automake

2018-08-11 Thread Andreas Tille
Hi,

libmuscle[1] was bilding fine in several uploads but when I now
try to rebuild to fix #904690 I get:

...
dh_auto_build --no-parallel
make -j1
make[2]: Entering directory '/build/libmuscle-3.7+4565'
Making all in libMUSCLE
make[3]: Entering directory '/build/libmuscle-3.7+4565/libMUSCLE'
g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" 
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT
_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 
-DLT_OBJDIR=\".libs/\" -DSTDC_HEADERS=
1 -DTIME_WITH_SYS_TIME=1 -I. -I..  -Wdate-time -D_FORTIFY_SOURCE=2 -O2 
-funroll-loops -fomit-frame-pointer -ftree-vectorize  -DNDEBUG=1  -fopenmp -g 
-O2 -fdebug-prefix-map=/build/libmuscle-
3.7+4565=. -fstack-protector-strong -Wformat -Werror=format-security -c -o 
main.o main.cpp
make[3]: *** No rule to make target '../libMUSCLE/libMUSCLE.la', needed by 
'muscle'.  Stop.
make[3]: Leaving directory '/build/libmuscle-3.7+4565/libMUSCLE'
...


I suspect an issue in libMUSCLE/Makefile.am.  Any hint how to fix this?

Kind regards

  Andreas.


[1] https://salsa.debian.org/med-team/libmuscle

-- 
http://fam-tille.de



Re: Help to build libsmithwaterman with gcc-8 needed

2018-08-05 Thread Andreas Tille
Hi Andrey,

On Sun, Aug 05, 2018 at 01:00:28PM +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 05, 2018 at 05:31:48AM +0200, Andreas Tille wrote:
> > Hi,
> > 
> > I thinks I've fixed the issue for bug #897797 in Git[1] for
> > libsmithwaterman but somehow it fails to build for a different
> > reason now.  Any idea why this might happen:
> > 
> > ...
> > make  all-am
> > make[2]: Entering directory 
> > '/build/libsmithwaterman-0.0+git20160702.2610e25'
> > g++ -DHAVE_CONFIG_H -I.   -I. -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
> > -fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -c -o 
> > smithwaterman.o smithwaterman.cpp
> > /bin/bash ./libtool  --tag=CXX   --mode=link g++  -g -O2 
> > -fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
> > -fstack-protector-strong -Wformat -Werror=format-security  -  Wl,-z,relro 
> > -Wl,-z,now -o smithwaterman smithwaterman.o -lsmithwaterman -ldisorder
> > libtool: link: g++ -g -O2 
> > -fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
> > -Wl,-z -Wl,now -o smithwaterman smithwaterman.o  -lsmithwaterman -ldisorder
> > /usr/bin/ld: cannot find -lsmithwaterman
> > collect2: error: ld returned 1 exit status
> Well, your Makefile.am doesn't say you need to build the lib before the
> binary.

Strange.  I have never seen such kind of specification and I assumed
that this is automatically the case.  I checked some references about
automake and also example packages but failed to find a clue.  Could you
give any more detailed hint to specify that the library needs to be
build first.

Kind regards

 Andreas.

-- 
http://fam-tille.de



Help to build libsmithwaterman with gcc-8 needed

2018-08-04 Thread Andreas Tille
Hi,

I thinks I've fixed the issue for bug #897797 in Git[1] for
libsmithwaterman but somehow it fails to build for a different
reason now.  Any idea why this might happen:

...
make  all-am
make[2]: Entering directory '/build/libsmithwaterman-0.0+git20160702.2610e25'
g++ -DHAVE_CONFIG_H -I.   -I. -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o smithwaterman.o 
smithwaterman.cpp
/bin/bash ./libtool  --tag=CXX   --mode=link g++  -g -O2 
-fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
-fstack-protector-strong -Wformat -Werror=format-security  -  Wl,-z,relro 
-Wl,-z,now -o smithwaterman smithwaterman.o -lsmithwaterman -ldisorder
libtool: link: g++ -g -O2 
-fdebug-prefix-map=/build/libsmithwaterman-0.0+git20160702.2610e25=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o smithwaterman smithwaterman.o  -lsmithwaterman -ldisorder
/usr/bin/ld: cannot find -lsmithwaterman
collect2: error: ld returned 1 exit status
...


Any hints?

Kind regards

 Andreas.


[1] https://salsa.debian.org/med-team/libsmithwaterman

-- 
http://fam-tille.de



Re: bison help needed

2018-08-03 Thread Andreas Tille
Hi Dan,

On Fri, Aug 03, 2018 at 09:50:03PM -0700, Dan Kegel wrote:
> Try
> 
> --- a/debian/rules
> +++ b/debian/rules
> @@ -1,6 +1,7 @@
>  #!/usr/bin/make -f
>  # debian/rules file for maude
>  export DH_VERBOSE=1
> +export DEB_CXXFLAGS_MAINT_APPEND=-fpermissive

I tried this but the error remains exactly the same.
 
>  %:
> dh $@
> 
> but I wonder how many arguments yyparse and yyerror are really
> supposed to have; there may be a bit of confusion there.

Sorry, I do not understand this.

Kind regards

 Andreas.


> On Fri, Aug 3, 2018 at 7:17 AM, Andreas Tille  wrote:
> > On Fri, Aug 03, 2018 at 03:29:49PM +0500, Andrey Rahmatullin wrote:
> >> > flex -t -p -p ./lexer.ll > lexer.cc
> >> > -I (interactive) entails a minor performance penalty
> >> > mv surface.c surface.cc
> >> > mv: cannot stat 'surface.c': No such file or directory
> >>
> >> surface.cc surface.h: surface.yy
> >>   $(BISON) -dv surface.yy -o surface.c
> >>   mv surface.c surface.cc
> >>
> >> Looks like this target is executed twice in parallel?
> >
> > Ahhh, thanks for pointing this out.  I added the --no-parallel option
> > which brought me further away until:
> >
> > ...
> > g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/Utility -I../../src/Temporal 
> > -I../../src/Interface -I../../src/Core -I../../src/Variable 
> > -I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory 
> > -I../../src/S_Theory -I../../src/NA_Theory -I../../src/FreeTheory 
> > -I../../src/ObjectSystem -I../../src/Mixfix -I../../src/BuiltIn 
> > -I../../src/MSCP10 -I../../src/IO_Stuff -I../../src/ACU_Persistent 
> > -I../../src/ACU_Theory -I../../src/AU_Persistent -I../../src/AU_Theory 
> > -I../../src/Meta -I../../src/3rdParty -I../../src/FullCompiler 
> > -I../../src/StrategyLanguage -I../../src/SMT -Wdate-time 
> > -D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/build/maude-2.7.1=. 
> > -fstack-protector-strong -Wformat -Werror=format-security -c -o 
> > libmixfix_a-surface.o `test -f 'surface.cc' || echo './'`surface.cc
> > surface.c: In function 'int yyparse(void*, 
> > UserLevelRewritingContext::ParseResult*)':
> > surface.c:5382:16: error: invalid conversion from 'void*' to 
> > 'UserLevelRewritingContext::ParseResult*' [-fpermissive]
> > surface.c:5382:31: error: cannot convert 
> > 'UserLevelRewritingContext::ParseResult*' to 'char*'
> > surface.yy:97:80: note:   initializing argument 2 of 'void 
> > yyerror(UserLevelRewritingContext::ParseResult*, char*)'
> >  static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, 
> > char *s);
> >   
> > ~~^
> > surface.c:5526:12: error: invalid conversion from 'void*' to 
> > 'UserLevelRewritingContext::ParseResult*' [-fpermissive]
> > surface.c:5526:27: error: cannot convert 
> > 'UserLevelRewritingContext::ParseResult*' to 'char*'
> > surface.yy:97:80: note:   initializing argument 2 of 'void 
> > yyerror(UserLevelRewritingContext::ParseResult*, char*)'
> >  static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, 
> > char *s);
> >   
> > ~~^
> > surface.yy:313:12: warning: ignoring return value of 'int system(const 
> > char*)', declared with attribute warn_unused_result [-Wunused-result]
> >   system((string("ls") + $3).c_str());
> >   ~~^~
> > make[6]: *** [Makefile:1066: libmixfix_a-surface.o] Error 1
> > make[6]: Leaving directory '/build/maude-2.7.1/src/Mixfix'
> > make[5]: *** [Makefile:484: all] Error 2
> > ...
> >
> >
> > Any further hint?
> >
> > Kind regards
> >
> >  Andreas.
> >
> >
> > --
> > http://fam-tille.de
> >
> >
> >
> 
> 

-- 
http://fam-tille.de



Re: bison help needed

2018-08-03 Thread Andreas Tille
On Fri, Aug 03, 2018 at 03:29:49PM +0500, Andrey Rahmatullin wrote:
> > flex -t -p -p ./lexer.ll > lexer.cc
> > -I (interactive) entails a minor performance penalty
> > mv surface.c surface.cc
> > mv: cannot stat 'surface.c': No such file or directory
> 
> surface.cc surface.h: surface.yy
>   $(BISON) -dv surface.yy -o surface.c
>   mv surface.c surface.cc
> 
> Looks like this target is executed twice in parallel?

Ahhh, thanks for pointing this out.  I added the --no-parallel option
which brought me further away until:

...
g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/Utility -I../../src/Temporal 
-I../../src/Interface -I../../src/Core -I../../src/Variable 
-I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory 
-I../../src/S_Theory -I../../src/NA_Theory -I../../src/FreeTheory 
-I../../src/ObjectSystem -I../../src/Mixfix -I../../src/BuiltIn 
-I../../src/MSCP10 -I../../src/IO_Stuff -I../../src/ACU_Persistent 
-I../../src/ACU_Theory -I../../src/AU_Persistent -I../../src/AU_Theory 
-I../../src/Meta -I../../src/3rdParty -I../../src/FullCompiler 
-I../../src/StrategyLanguage -I../../src/SMT -Wdate-time -D_FORTIFY_SOURCE=2  
-g -O2 -fdebug-prefix-map=/build/maude-2.7.1=. -fstack-protector-strong 
-Wformat -Werror=format-security -c -o libmixfix_a-surface.o `test -f 
'surface.cc' || echo './'`surface.cc
surface.c: In function 'int yyparse(void*, 
UserLevelRewritingContext::ParseResult*)':
surface.c:5382:16: error: invalid conversion from 'void*' to 
'UserLevelRewritingContext::ParseResult*' [-fpermissive]
surface.c:5382:31: error: cannot convert 
'UserLevelRewritingContext::ParseResult*' to 'char*'
surface.yy:97:80: note:   initializing argument 2 of 'void 
yyerror(UserLevelRewritingContext::ParseResult*, char*)'
 static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, char 
*s);
  
~~^
surface.c:5526:12: error: invalid conversion from 'void*' to 
'UserLevelRewritingContext::ParseResult*' [-fpermissive]
surface.c:5526:27: error: cannot convert 
'UserLevelRewritingContext::ParseResult*' to 'char*'
surface.yy:97:80: note:   initializing argument 2 of 'void 
yyerror(UserLevelRewritingContext::ParseResult*, char*)'
 static void yyerror(UserLevelRewritingContext::ParseResult* parseResult, char 
*s);
  
~~^
surface.yy:313:12: warning: ignoring return value of 'int system(const char*)', 
declared with attribute warn_unused_result [-Wunused-result]
  system((string("ls") + $3).c_str());
  ~~^~
make[6]: *** [Makefile:1066: libmixfix_a-surface.o] Error 1
make[6]: Leaving directory '/build/maude-2.7.1/src/Mixfix'
make[5]: *** [Makefile:484: all] Error 2
...


Any further hint?

Kind regards

 Andreas.


-- 
http://fam-tille.de




bison help needed

2018-08-03 Thread Andreas Tille
Hi,

I intend to upgrade maude[1] to its latest upstream version.  Unfortunately
I was running into:

...
Making all in Mixfix
make[4]: Entering directory '/build/maude-2.7.1/src/Mixfix'
cat \
./top.yy \
./modules.yy \
./commands.yy \
./bottom.yy \
> surface.yy
bison -dv surface.yy -o surface.c
bison -dv surface.yy -o surface.c
mv surface.c surface.cc
flex -t -p -p ./lexer.ll > lexer.cc
-I (interactive) entails a minor performance penalty
mv surface.c surface.cc
mv: cannot stat 'surface.c': No such file or directory
...


So something might be wrong with bison but I have no idea how to fix
this.  Any ideas?

Kind regards

Andreas.

[1] https://salsa.debian.org/med-team/maude

-- 
http://fam-tille.de



Is uscan git mode able to fetch submodules? [Was: Please clarify relation of code copy of daligner and dazzdb in package pbdagcon]

2018-07-19 Thread Andreas Tille
Hi,

is there any way to also fetch submodules when using git mode in a watch
file?  If the answer would be yes, than I could get rid of a
get-orig-source script (see full story below).

Kind regards

   Andreas.

- Forwarded message from Afif Elghraoui  -

Date: Thu, 19 Jul 2018 06:24:32 -0400
From: Afif Elghraoui 
To: Andreas Tille , Debian Med Project List 

Subject: Re: Please clarify relation of code copy of daligner and dazzdb in 
package pbdagcon

Hi, Andreas

On July 19, 2018 5:36:15 AM EDT, Andreas Tille  wrote:
>Hi Afif,
>
>in my attempt to fix Vcs-fields and other issues in packages that were
>not uploaded a long time I stumbled upon pbdagcon[1].  In my latest
>commit[2] I managed to convert d/watch to git mode.  However, git mode
>does not support submodules and thus the dirs DALIGNER and DAZZ_DB are
>not included into the fetched upstream source tarball.  This could mean
>we need to keep the get-orig-source script.
>
>However, I've checked these submodules[3] and realised that these are
>outdated versions of the packaged code inside daligner and dazzdb[4].
>The upstream author just moved to a different repository and has left
>[3] alone which means pbdagcon is using outdated code.  Is there any
>good reason to keep this situation (like incompatibilities with new
>code
>etc.)?
>

One of pbdagcon's binaries (dazcon) needs that code to build. Anyway, the 
included daligner/dazzdb code [3] was modified from the original [4] and is not 
just an exact copy of an older verion.

regards
Afif

>
>[1] https://salsa.debian.org/med-team/pbdagcon
>[2]
>https://salsa.debian.org/med-team/pbdagcon/commit/439fc65a84f142570223a477914d403ece9f2354
>[3] https://github.com/PacificBiosciences/DALIGNER
>https://github.com/PacificBiosciences/DAZZ_DB
>[4] https://github.com/thegenemyers/DALIGNER
>https://github.com/thegenemyers/DAZZ_DB
>
>-- 
>http://fam-tille.de



Help needed for different gcc-8 bug in new upstream version (Was: spades: ftbfs with GCC-8)

2018-07-18 Thread Andreas Tille
Control: tags -1 help

Hi,

upstream seems to have dealt with the original issue in the logs of this
bug report in the new upstream version which I commited to Salsa[1].
Unfortunately there is a new issue where I need help from a C++ programmer:

...
[ 69%] Building CXX object 
common/utils/CMakeFiles/utils.dir/logger/logger_impl.cpp.o
cd /build/spades-3.12.0+dfsg/build_spades/common/utils && /usr/bin/c++  
-DJEMALLOC_NO_DEMANGLE -DUSE_GLIBCXX_PARALLEL=1 
-I/build/spades-3.12.0+dfsg/build_spades/common/utils 
-I/build/spades-3.12.0+dfsg/src/common/utils 
-I/build/spades-3.12.0+dfsg/src/include 
-I/build/spades-3.12.0+dfsg/build_spades/include 
-I/build/spades-3.12.0+dfsg/src -I/build/spades-3.12.0+dfsg/src/common -isystem 
/build/spades-3.12.0+dfsg/src/../ext/include  -g -O2 
-fdebug-prefix-map=/build/spades-3.12.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp 
-std=c++14 -O2 -g -DNDEBUG   -UNDEBUG -Wno-deprecated -g3 -O2 -Wall -Wextra 
-Wconversion -Wno-sign-conversion -Wno-long-long -Wwrite-strings -o 
CMakeFiles/utils.dir/logger/logger_impl.cpp.o -c 
/build/spades-3.12.0+dfsg/src/common/utils/logger/logger_impl.cpp
/build/spades-3.12.0+dfsg/src/common/utils/logger/logger_impl.cpp: In member 
function 'void logging::logger::log(logging::level, const char*, size_t, const 
char*, const char*)':
/build/spades-3.12.0+dfsg/src/common/utils/logger/logger_impl.cpp:115:20: 
error: 'get_max_rss' is not a member of 'utils'
   max_rss = utils::get_max_rss();
^~~
make[4]: *** [common/utils/CMakeFiles/utils.dir/build.make:115: 
common/utils/CMakeFiles/utils.dir/logger/logger_impl.cpp.o] Error 1
...


Any help would be welcome

Andreas.


[1] https://salsa.debian.org/med-team/spades

-- 
http://fam-tille.de



Missing define (Was: infernal: another autoreconf issue)

2018-07-16 Thread Andreas Tille
Hi Yagor,

On Sun, Jul 15, 2018 at 11:33:36PM +0300, Yavor Doganov wrote:
> Andreas Tille wrote:
> > autoheader: warning: missing template: EASEL_COPYRIGHT
> > autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
> 
> The problem here is that AC_DEFINE and AC_DEFINE_UNQUOTED are used to
> define preprocessor symbols without the third argument which is the
> description.  This is fine as long as AC_CONFIG_HEADERS is *not* used.
> However, that is not the case -- there are three configuration headers
> with separate calls to AC_CONFIG_HEADERS.
> 
> The simple, but kinda tiresome solution is to add a third argument to
> every AC_DEFINE/AC_DEFINE_UNQUOTED call, like this:
> 
> AC_DEFINE_UNQUOTED([EASEL_COPYRIGHT], ["$EASEL_COPYRIGHT"],
>[Easel copyright information.])
> 
> Some of the symbols are already documented in the templates provided
> by upstream (the .h.in files) but they are invisible to autoheader.

Ahhh, this hint helped me to finalise the autoreconf step.  Thanks a lot
so far. Unfortunately I now get


 CC cm_dpsmall.o
cm_dpsmall.c: In function 'generic_splitter':
cm_dpsmall.c:721:51: error: expected expression before ')' token
   if (insideT_size(cm, L, r, z, i0, j0) < RAMLIMIT) {
   ^
cm_dpsmall.c: In function 'wedge_splitter':
cm_dpsmall.c:943:51: error: expected expression before ')' token
   insideT_size(cm, L, r, z, i0, j0) < RAMLIMIT)
   ^
cm_dpsmall.c: In function 'v_splitter':
cm_dpsmall.c:1120:57: error: expected expression before ')' token
   vinsideT_size(cm, r, z, i0, i1, j1, j0) < RAMLIMIT)
 ^
cm_dpsmall.c: In function 'generic_splitter_b':
cm_dpsmall.c:3762:51: error: expected expression before ')' token
   if (insideT_size(cm, L, r, z, i0, j0) < RAMLIMIT) {
   ^
cm_dpsmall.c: In function 'wedge_splitter_b':
cm_dpsmall.c:3991:51: error: expected expression before ')' token
   insideT_size(cm, L, r, z, i0, j0) < RAMLIMIT)
   ^
cm_dpsmall.c: In function 'v_splitter_b':
cm_dpsmall.c:4184:57: error: expected expression before ')' token
   vinsideT_size(cm, r, z, i0, i1, j1, j0) < RAMLIMIT)
 ^
cm_dpsmall.c: In function 'voutside_b':
cm_dpsmall.c:5718:3: warning: implicit declaration of function 'assert'; did 
you mean 'tzset'? [-Wimplicit-function-declaration]
   assert(dmin[r] <= (j0-i0)+1);
   ^~


RAMLIMIT is defined in src/config.h.in but for some reason not
propagated to src/config.h.  I tried to cure this via


 --- a/configure.ac
 +++ b/configure.ac
-@@ -121,24 +121,24 @@ AC_SUBST(EASEL_VERSION)
+@@ -120,25 +120,28 @@ AC_SUBST(EASEL_LICENSE)
+ AC_SUBST(EASEL_VERSION)
  AC_SUBST(EASEL_URL)
  
++AC_SUBST(RAMLIMIT)
++AC_DEFINE_UNQUOTED([RAMLIMIT], [], [This definition is needed to propagate it 
in src/config.h.in])
++
  # Preprocessor symbols (replace #undefs in hmmer/src/p7_config.h and 
src/config.h)
 -AC_DEFINE_UNQUOTED(INFERNAL_DATE,  "$INFERNAL_DATE")
 -AC_DEFINE_UNQUOTED(INFERNAL_COPYRIGHT, "$INFERNAL_COPYRIGHT")


but this did not help.  Any further hint

Kind regards

  Andreas.
 

-- 
http://fam-tille.de



Am I missing something with symlink_to_dir? Re: Bug#903819: r-cran-rmarkdown: Broken link /usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5/shim

2018-07-15 Thread Andreas Tille
Control: tags -1 help

Hi Ralf,

On Sun, Jul 15, 2018 at 12:06:49PM +0200, Ralf Stubner wrote:
> lrwxrwxrwx 1 root root   43 Jun 29 16:16 shim -> 
> ../../../../shiny/www/shared/bootstrap/shim
> 
> Please let me know if you need further info.

No further info is needed.  I actually realised the issue before and
fixed it in r-cran-rmarkdown_1.10+dfsg-2.  So if you remove
r-cran-rmarkdown_1.10+dfsg-1 and install r-cran-rmarkdown_1.10+dfsg-2
you will succeed with your test.

Unfortunately the issue persists since dpkg can not replace a symlink
with a directory or vice versa and thus if you have installed
r-cran-rmarkdown_1.10+dfsg-1 before the symlink issue remains.

This can be solved by using symlink_to_dir (see
dpkg-maintscript-helper(1)) and I tried this.  Unfortunately my
debian/maintscript[2] does not work (despite the resulting
preinst script looks like


#!/bin/sh
set -e
# Automatically added by dh_installdeb/11.3.5
dpkg-maintscript-helper symlink_to_dir 
/usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5 
../../../../../../share/javascript/bootstrap 1.10\+dfsg-2 -- "$@"
# End automatically added section


My question to debian-mentors list is now: Am I missing something?  How
can I turn the link
/usr/lib/R/site-library/rmarkdown/rmd/h/bootstrap-3.3.5 successfully into
a dir?

Thanks for any help

   Andreas.


[1] 
https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Will_dpkg_replace_a_symlink_with_a_directory_or_vice_versa.3F
[2] 
https://salsa.debian.org/r-pkg-team/r-cran-rmarkdown/blob/master/debian/maintscript

-- 
http://fam-tille.de



infernal: another autoreconf issue (Was: staden: possibly undefined macro: AC_MSG_ERROR despite pkg-config was added to Build-Depends)

2018-07-15 Thread Andreas Tille
Hi again,

thanks a lot to Yavor for his patch for staden.  I'd like to come up
with another autoreconf issue which hit me in package infernal[1].
I'm running into

...
   dh_autoreconf
autoheader: warning: missing template: EASEL_COPYRIGHT
autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
autoheader: warning: missing template: EASEL_DATE
autoheader: warning: missing template: EASEL_LICENSE
autoheader: warning: missing template: EASEL_VERSION
autoheader: warning: missing template: HAVE_FLUSH_ZERO_MODE
autoheader: warning: missing template: HAVE_GZIP
autoheader: warning: missing template: HAVE_MPI
autoheader: warning: missing template: HAVE_SSE2
autoheader: warning: missing template: HAVE_SSE2_CAST
autoheader: warning: missing template: HAVE_VMX
autoheader: warning: missing template: HMMER_COPYRIGHT
autoheader: warning: missing template: HMMER_DATE
autoheader: warning: missing template: HMMER_LICENSE
autoheader: warning: missing template: HMMER_THREADS
autoheader: warning: missing template: HMMER_URL
autoheader: warning: missing template: HMMER_VERSION
autoheader: warning: missing template: INFERNAL_COPYRIGHT
autoheader: warning: missing template: INFERNAL_DATE
autoheader: warning: missing template: INFERNAL_LICENSE
autoheader: warning: missing template: INFERNAL_URL
autoheader: warning: missing template: INFERNAL_VERSION
autoheader: warning: missing template: eslDEBUGLEVEL
autoheader: warning: missing template: eslLIBRARY
autoheader: warning: missing template: p7_DEBUGGING
autoheader: warning: missing template: p7_IMPL_SSE
autoheader: warning: missing template: p7_IMPL_VMX
autoreconf: /usr/bin/autoheader failed with exit status: 1
dh_autoreconf: autoreconf -f -i returned exit code 1
...

and I have no idea how to fix this.  Any ideas?

Kind regards

Andreas.

[1] https://salsa.debian.org/med-team/infernal

-- 
http://fam-tille.de



staden: possibly undefined macro: AC_MSG_ERROR despite pkg-config was added to Build-Depends

2018-07-14 Thread Andreas Tille
Hi,

I tried to build staden[1] using debhelper 11 but I get

...
   dh_autoreconf
aclocal: warning: autoconf input should be named 'configure.ac', not 
'configure.in'
configure.in:32: error: possibly undefined macro: AC_MSG_ERROR
  If this token and others are legitimate, please use m4_pattern_allow.
  See the Autoconf documentation.
configure.in:33: error: possibly undefined macro: AC_MSG_WARN
autoreconf: /usr/bin/autoconf failed with exit status: 1
...

Since usually the solution is to add pkg-config to Build-Depends
I tried this but this does not change anything.  Any idea how to
fix this?

Kind regards

   Andreas.

[1] https://salsa.debian.org/med-team/staden

-- 
http://fam-tille.de



C++ help needed for spaced: call of overloaded 'abs(uint32_t&)' is ambiguous

2018-07-09 Thread Andreas Tille
Hi,

I take the freedom to ask for some C++ help for the new version of
spaced[1]:

...
g++ -DHAVE_CONFIG_H -I. -I..   -Wall -Wextra -std=c++11 -Wno-char-subscripts 
-Wdate-time -D_FORTIFY_SOURCE=2 -fopenmp -g -O2 
-fdebug-prefix-map=/build/spaced-1.2.0-201605+dfsg=. -fstack-protector-strong - 
  Wformat -Werror=format-security -c -o spaced-patternset.o `test -f 
'patternset.cpp' || echo './'`patternset.cpp
...
patternset.cpp: In member function 'void patternset::CheckParams()':
patternset.cpp:187:10: warning: comparison of unsigned expression < 0 is always 
false [-Wtype-limits]
  if(size < 0){
 ~^~~
patternset.cpp:188:23: error: call of overloaded 'abs(uint32_t&)' is ambiguous
   size = std::abs(size);
   ^
In file included from /usr/include/c++/7/cstdlib:77:0,
 from /usr/include/c++/7/bits/stl_algo.h:59,
 from /usr/include/c++/7/algorithm:62,
 from patternset.h:24,
 from patternset.cpp:21:
/usr/include/c++/7/bits/std_abs.h:78:3: note: candidate: constexpr long double 
std::abs(long double)
   abs(long double __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:74:3: note: candidate: constexpr float 
std::abs(float)
   abs(float __x)
   ^~~
/usr/include/c++/7/bits/std_abs.h:70:3: note: candidate: constexpr double 
std::abs(double)
   abs(double __x)
   ^~~
...


Any hint how to fix this?

Kind regards

   Andreas.


[1] https://salsa.debian.org/med-team/spaced

-- 
http://fam-tille.de



Re: Bug#902592: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

2018-06-29 Thread Andreas Tille
Hi Tristan,

On Fri, Jun 29, 2018 at 02:26:47PM +0200, Tristan Seligmann wrote:
> On Fri, 29 Jun 2018 at 14:20 Andreas Tille  wrote:
> 
> > Hi Tristan,
> >
> > On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote:
> > > This is a cython bug; cython-dbg fails to ship the StringIOTree extension
> > > module, so the regular non-debug module is found when doing a debug build
> > > but fails to load.
> >
> > Are you refering to #902551?
> >
> 
> No, that bug looks unrelated.

Would you mind filing an according bug report we could refer to?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: [Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

2018-06-29 Thread Andreas Tille
Hi Tristan,

On Fri, Jun 29, 2018 at 01:31:31PM +0200, Tristan Seligmann wrote:
> This is a cython bug; cython-dbg fails to ship the StringIOTree extension
> module, so the regular non-debug module is found when doing a debug build
> but fails to load.

Are you refering to #902551?

I'd consider to do a team upload of Cython since this has a patch attached.

Kind regards

   Andreas.

-- 
http://fam-tille.de



[Help] Potential Cython issue with new version of h5py (Was: Bug#902592: New version does not build)

2018-06-29 Thread Andreas Tille
Control: tags -1 help

I agree with Ghislain that the issue below might be caused by Cython.
Any idea how to fix this?

Kind regards

  Andreas.

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

> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging


-- 
http://fam-tille.de



Help for build-time test failure of libhmsbeagle (phylogeny algorithms using GPU) needed

2018-06-22 Thread Andreas Tille
Hi,

I'm trying to update libhmsbeagle[1] to its latest upstream version.
Unfortunately I'm running into a build time test where I have no idea
how to deal with:

...
make[4]: Entering directory 
'/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'

  -
make  matrixtest
make[5]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'
g++ -DHAVE_CONFIG_H -I. -I../../libhmsbeagle  -I../.. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/java-10-openjdk-amd64/include 
-I/usr/lib/jvm/java-10-openjdk-amd64/include/linux -O3 -std=c++11 -pthread -g 
-O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security -c -o matrixtest.o 
matrixtest.cpp
/bin/bash ../../libtool  --tag=CXX   --mode=link g++ -O3 -std=c++11 -pthread -g 
-O2 -fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro 
-Wl,-z,now -o matrixtest matrixtest.o ../../libhmsbeagle/libhmsbeagle.la -ldl 
libtool: link: g++ -O3 -std=c++11 -pthread -g -O2 
-fdebug-prefix-map=/build/libhmsbeagle-3.0.2+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
.libs/matrixtest matrixtest.o  ../../libhmsbeagle/.libs/libhmsbeagle.so -ldl 
-pthread
make[5]: Leaving directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest' 

 e 
make  check-TESTS   

  -
make[5]: Entering directory '/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'
make[6]: Entering directory 
'/build/libhmsbeagle-3.0.2+dfsg/examples/matrixtest'

 md
FAIL: matrixtest

  -

   libhmsbeagle 3.0.2: examples/matrixtest/test-suite.log


# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: matrixtest



OpenCL error: CL_INVALID_VALUE from file , line 923.
Using resource 1:
Rsrc Name : pthread-Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz (OpenCL 
1.2 pocl HSTR: pthread-x86_64-pc-linux-gnu-haswell)
Impl : OpenCL-Single
Impl Desc : none

FAIL matrixtest (exit status: 255)


Before I contact upstream I wonder whether I might have missed some GPU
specific things that might help here.

Kind regards

Andreas.


[1] https://salsa.debian.org/med-team/libhmsbeagle

-- 
http://fam-tille.de



numpy boolean subtract, the `-` operator, is deprecated, use the bitwise_xor, the `^` operator, or the logical_xor function instead (Was: Bug#899205: python-cogent: Test suite fails with latest matplo

2018-06-05 Thread Andreas Tille
Control: tags -1 help

Hi,

I have reported the issue upstream but no response so far.  While the
error message contains some hint how to solve the issue I would like
to backup this by some competent advise.


==
ERROR: test_consistent_gap_degen_handling 
(test_core.test_sequence.ModelSequenceTests)
gap degen character should be treated consistently
--
Traceback (most recent call last):
  File 
"/tmp/autopkgtest-lxc.5a99fnj6/downtmp/autopkgtest_tmp/tests/test_core/test_sequence.py",
 line 660, in test_consistent_gap_degen_handling
self.assertEqual(dna.stripBadAndGaps(), raw_ungapped)
  File "/usr/lib/python2.7/dist-packages/cogent/core/sequence.py", line 1251, 
in stripBadAndGaps
valid_indices -= self._data == i
TypeError: numpy boolean subtract, the `-` operator, is deprecated, use the 
bitwise_xor, the `^` operator, or the logical_xor function instead.

==


I would be happy for some suggested patch how to solve this.  The line
in question is

   
https://salsa.debian.org/med-team/python-cogent/blob/master/cogent/core/sequence.py

   Line 1251

If my feeling is not totally wrong the correct patch would be 

   valid_indices -= (self._data == i)

since the left value is rather an integer than boolean.

What do you think?

Kind regards

Andreas.

-- 
http://fam-tille.de



Problem with lintian error symbols-file-contains-current-version-with-debian-revision

2018-05-23 Thread Andreas Tille
Hi,

I've created a symbols file for libseqlib version 1.1.1+dfsg since I
suspected an ABI change by upstream.  A test build with this symbols
file went fine without lintian errors.  I upgraded to libseqlib version
1.1.2 which in fact had an ABI change[2].  I have upgraded the symbols
file accordingly[3].  When I build this package I get:

E: libseqlib1: symbols-file-contains-current-version-with-debian-revision on 
symbol 
_ZN12aho_corasick10basic_trieIcE10parse_textENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 and 433 others
N: 
N:Debian revisions should be stripped from versions in symbols files. Not
N:doing so leads to dependencies unsatisfiable by backports (1.0-1~bpo <<
N:1.0-1 while 1.0-1~bpo >= 1.0). If the Debian revision can't be stripped
N:because the symbol really appeared between two specific Debian
N:revisions, you should postfix the version with a single "~" (example:
N:1.0-3~ if the symbol appeared in 1.0-3).
N:
N:This problem normally means that the symbols were added automatically by
N:dpkg-gensymbols. dpkg-gensymbols uses the full version number for the
N:dependency associated to any new symbol that it detects. The maintainer
N:must update the debian/.symbols file by adding the new symbols
N:with the corresponding upstream version.
N:
N:Severity: important, Certainty: certain
N:
N:Check: shared-libs, Type: binary, udeb
N: 

I wonder whether I'm missing something but this smeels like a wrong
lintian warning to me since the Debian revision "-1" was stripped from
the diff.  To be sure to not create noise for lintian in BTS I'd like
to have a second pair of eyeballs on this symbols file.

Kind regards

  Andreas.


[1] 
https://salsa.debian.org/med-team/libseqlib/blob/23e6ae31d0155b6b5011aabdc3944b695ed79986/debian/libseqlib0.symbols
[2] https://github.com/walaj/SeqLib/issues/24
[3] 
https://salsa.debian.org/med-team/libseqlib/commit/b8991175a61613622bf9776a296967740db74057

-- 
http://fam-tille.de



error: 'char16_t' does not name a type; did you mean 'wchar_t'? (Was: Bug#899129: prime-phylo: FTBFS: cd obj-x86_64-linux-gnu && make -j8 -Oline returned exit code 2)

2018-05-20 Thread Andreas Tille
Control: tags -1 help

Hi,

the build log of prime-phylo[1] has:

...
cd /build/prime-phylo-1.0.11/obj-x86_64-linux-gnu/src/cxx/libraries/prime && 
/usr/bin/c++  -DONLY_ONE_TIMESAMPLE -DPERTURBED_NODE -Dprime_phylo_EXPORTS 
-I/build/prime-phylo-1.0.11/obj-x86_64-linux-gnu/src/cxx/libraries/prime 
-I/build/prime-phylo-1.0.11/src/cxx/libraries/prime 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
-I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/  
lib/x86_64-linux-gnu/openmpi/include/ompi/mpi/cxx -I/usr/include/libxml2 
-I/build/prime-phylo-1.0.11/src/cxx/libraries 
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi/ompi/mpi/cxx 
-I/usr/lib/openmpi/include/openmpi/ompi/mpi/cxx  -g -O2 
-fdebug-prefix-map=/build/prime-phylo-1.0.11=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wreorder 
-Wall -fexceptions -g -fPIC   -std=gnu++98 -o 
CMakeFiles/prime-phylo.dir/TreeInputOutput.cc.o -c 
/build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.cc
In file included from /usr/include/unicode/utypes.h:38:0,
 from /usr/include/unicode/ucnv_err.h:88,
 from /usr/include/unicode/ucnv.h:52,
 from /usr/include/libxml2/libxml/encoding.h:31,
 from /usr/include/libxml2/libxml/parser.h:810,
 from /usr/include/libxml2/libxml/globals.h:18,
 from /usr/include/libxml2/libxml/threads.h:35,
 from /usr/include/libxml2/libxml/xmlmemory.h:218,
 from /usr/include/libxml2/libxml/tree.h:1307,
 from 
/build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.hh:9,
 from 
/build/prime-phylo-1.0.11/src/cxx/libraries/prime/TreeInputOutput.cc:1:
/usr/include/unicode/umachine.h:347:13: error: 'char16_t' does not name a type; 
did you mean 'wchar_t'?
 typedef char16_t UChar;
 ^~~~
 wchar_t
In file included from /usr/include/unicode/utypes.h:39:0,
 from /usr/include/unicode/ucnv_err.h:88,
 from /usr/include/unicode/ucnv.h:52,
 from /usr/include/libxml2/libxml/encoding.h:31,
 from /usr/include/libxml2/libxml/parser.h:810,
 from /usr/include/libxml2/libxml/globals.h:18,
 from /usr/include/libxml2/libxml/threads.h:35,
 from /usr/inclmake[3]: Entering directory 
'/build/prime-phylo-1.0.11/obj-x86_64-linux-gnu'
...

and similar things.  Any idea how to fix this?

Kind regards

   Andreas.

[1] https://salsa.debian.org/med-team/prime-phylo

-- 
http://fam-tille.de



Re: Bug#898964: mrs: FTBFS: you don't seem to have log4cpp installed

2018-05-18 Thread Andreas Tille
Hi Andrey,

On Fri, May 18, 2018 at 03:05:24PM +0500, Andrey Rahmatullin wrote:
> On Fri, May 18, 2018 at 11:44:02AM +0200, Andreas Tille wrote:
> > > Checking for liblog4cpp...
> > > 
> > > Cannot continue since you don't seem to have log4cpp installed
> > > Please install the log4cpp-dev package and run configure again.
> > > make[1]: *** [debian/rules:11: override_dh_auto_configure] Error 2
> The reason for this: the configure script compiles the following code:
> 
> #include 
> #include 
> int main() { std::cout << 1 << '\t' << 0; return 0; }
> 
> in order to check that  exists.
> But this code still requires -llog4cpp:

Thanks for the explanation but may be I'm missing your point.  The
package installs liblog4cpp.a as well and the dynamic library installs
the according .so file.  So why should the requriement -llog4cpp not
fulfilled?
 
> /tmp/cc41MUW4.o: In function `__static_initialization_and_destruction_0(int, 
> int)':
> 2.cpp:(.text+0x5b): undefined reference to 
> `log4cpp::Appender::AppenderMapStorageInitializer::AppenderMapStorageInitializer()'
> 2.cpp:(.text+0x70): undefined reference to 
> `log4cpp::Appender::AppenderMapStorageInitializer::~AppenderMapStorageInitializer()'
> collect2: error: ld returned 1 exit status

Isn't this rather a bug in log4cpp?
 
Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Bug#898964: mrs: FTBFS: you don't seem to have log4cpp installed

2018-05-18 Thread Andreas Tille
Control: tags -1 help

On Thu, May 17, 2018 at 11:15:17PM +0200, Dominic Hargreaves wrote:
> Whilst test-rebuilding packages for the next perl release we found
> an unrelated build failure:
> 
> Checking for liblog4cpp...
> 
> Cannot continue since you don't seem to have log4cpp installed
> Please install the log4cpp-dev package and run configure again.
> make[1]: *** [debian/rules:11: override_dh_auto_configure] Error 2
> 
> The full log is here:
> 
> 
> 
> This seems likely to be caused by the new release of log4cpp 1.1.3-1
> last week.

Most probably that is the reason - but how to solve this?  I admit I
have no idea. :-(

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Gitlab API question: Fetching group ID works not reliably

2018-05-15 Thread Andreas Tille
Hi Paul,

On Tue, May 15, 2018 at 02:25:36PM +0800, Paul Wise wrote:
> 
> I thought there was a way to lookup the id for a group by querying the name.

This would be very convenient but I have not found it.  The pagination
solution is not very handy, thought.

Kind regards

  Andreas. 

-- 
http://fam-tille.de



Gitlab API question: Fetching group ID works not reliably

2018-05-15 Thread Andreas Tille
Hi,

I'm using the following script to fetch the group ID of a salsa team:

#!/bin/sh

SALSA_URL="https://salsa.debian.org/api/v4;
SALSA_TOKEN="MYSECRETTOKEN"

SALSA_GROUP="med-team"
#SALSA_GROUP="science-team"
#SALSA_GROUP="r-pkg-team"

SALSA_GROUP_ID=$(curl --silent -f -XGET --header "PRIVATE-TOKEN: $SALSA_TOKEN" 
"$SALSA_URL/groups?all_available=false" | jq ".[] | select(.path == 
\"$SALSA_GROUP\") | .id")

echo "ID=$SALSA_GROUP_ID"



For SALSA_GROUP="med-team" this returns

  ID=2799

If I try science-team or r-pkg-team it returns nothing.  Any idea
what might be wrong here?

Kind regards

Andreas.

-- 
http://fam-tille.de



Re: r-cran-dbi changed from arch=any to arch=all which makes it "unvisible" in unstable (Was: New version of r-bioc-genomicranges breaks autopkgtests of r-bioc-summarizedexperiment in testing)

2018-05-10 Thread Andreas Tille
On Thu, May 10, 2018 at 12:57:54PM -0500, Dirk Eddelbuettel wrote:
> | 
> | ftp.debian.org is the right pseudo-package for removal (of the 0.8-1
> | packages) from unstable.
> 
> Ok, thanks, filed as #898354.

Seems that bug is somehow needed for this specific issue.  However, I
think I had other packages moved from Arch=any to Arch=all without any
trouble.  So my question is:  Did something changed in the software
dealing with those uploads recently or is that package in some other
aspect different which might cause the observed issue?

Kind regards

 Andreas.

-- 
http://fam-tille.de



r-cran-dbi changed from arch=any to arch=all which makes it "unvisible" in unstable (Was: New version of r-bioc-genomicranges breaks autopkgtests of r-bioc-summarizedexperiment in testing)

2018-05-10 Thread Andreas Tille
Hi,

a lot of r-* packages received mails about test suite errors like this:

On Wed, May 09, 2018 at 02:16:29PM +0100, Paul Gevers wrote:
> ...
> [2] 
> https://ci.debian.net/packages/r/r-bioc-summarizedexperiment/testing/amd64/

I think the problem is that the packages depend directly or indirectly
from r-cran-dbi version 1.0.0 which is according to tracker[1] available
for architecture all but an older version is available for all
architectures.  This ends up in something like

$ apt-cache policy r-cran-dbi
r-cran-dbi:
  Installed: 0.8-1
  Candidate: 0.8-1
  Version table:
 *** 0.8-1 501
501 http://httpredir.debian.org/debian testing/main amd64 Packages
 50 http://httpredir.debian.org/debian unstable/main amd64 Packages
 50 http://ftp.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


May be this will "heal" somehow automatically but I wanted to give some
hint about this in case some manual action might be needed.

Kind regards

   Andreas.

[1] https://packages.debian.org/unstable/r-cran-dbi

-- 
http://fam-tille.de



Re: [Pkg-javascript-devel] Problems to recreate minimized JS in r-cran-jsonld

2018-05-10 Thread Andreas Tille
Hi,

On Thu, May 10, 2018 at 01:31:56PM +0500, Pirate Praveen wrote:
> 
> You'll need to update webpack.config.js with system path for it to find apt
> installed modules.

I naively tried

diff --git a/webpack.config.js b/webpack.config.js
index 7ce5c6e..87f7559 100644
--- a/webpack.config.js
+++ b/webpack.config.js
@@ -20,11 +20,11 @@ const outputs = [
 entry: [
   // 'babel-polyfill' is very large, list features explicitly
   'regenerator-runtime/runtime',
-  'core-js/fn/array/includes',
-  'core-js/fn/object/assign',
-  'core-js/fn/promise',
-  'core-js/fn/string/starts-with',
-  'core-js/fn/symbol',
+  '/usr/lib/nodejs/core-js/fn/array/includes',
+  '/usr/lib/nodejs/core-js/fn/object/assign',
+  '/usr/lib/nodejs/core-js/fn/promise',
+  '/usr/lib/nodejs/core-js/fn/string/starts-with',
+  '/usr/lib/nodejs/core-js/fn/symbol',
   // main lib
   './lib/index.js'
 ],

which did not help.
 
> > jsonld.js does not work.  The file size of this uncompressed file is way
> > smaller than the minimazion result and doese not work together with the
> > R code.  Thus I really need to undergo the process to create the
> > minimized JS.
> 
> https://wiki.debian.org/Javascript/#Using_build_tools_like_grunt has
> examples.

Is there any actual package example?  The anchor does not exist (any
more) on that wiki page (which should be updated to Salsa anyway ;-) ).

Kind regards

 Andreas.

-- 
http://fam-tille.de



Problems to recreate minimized JS in r-cran-jsonld

2018-05-09 Thread Andreas Tille
Hi,

I was stumbling upon an issue with some minimized JS in the package
r-cran-jsonld (ITPed in #898224).  I tried to recreate jsonld.min.js and
have written a script[1] which calls webpack in a clone of the Github
reporsitory.  Unfortunately the webpack call ends in:



webpack-merge@4.1.2 node_modules/webpack-merge
└── lodash@4.17.10
Hash: eaf5c95c94821ab4944c9f696b4a89040915c26b
Version: webpack 3.5.6
Child
Hash: eaf5c95c94821ab4944c
Time: 140ms
Asset Size  Chunks Chunk Names
jsonld.js  3.61 kB   0  [emitted]  jsonld
   [0] multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js 100 bytes {0} [built]

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'babel-loader' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'core-js/fn/array/includes' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'core-js/fn/object/assign' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'core-js/fn/promise' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'core-js/fn/string/starts-with' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'core-js/fn/symbol' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Module not found: Error: Can't resolve 'regenerator-runtime/runtime' in 
'/home/andreas/debian-maintain/salsa/r-pkg-team/0_prospective/r-cran-jsonld/debian/JS/jsonld.js'
 @ multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js
Child
Hash: 9f696b4a89040915c26b
Time: 126ms
Asset Size  Chunks Chunk Names
jsonld.min.js  1.24 kB   0  [emitted]  jsonld
   [0] multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise core-js/fn/string/starts-with 
core-js/fn/symbol ./lib/index.js 100 bytes {0} [built]

ERROR in multi regenerator-runtime/runtime core-js/fn/array/includes 
core-js/fn/object/assign core-js/fn/promise 

Re: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

2018-05-04 Thread Andreas Tille
On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> Andreas Tille wrote:
> > What's the correct way to fix the symbols file to work with both
> > versions of gcc?
> 
> Don't use symbols files for C++ libraries?

Well, it took a *long* time before I've undergone the process from
ignoring symbols files to finally providing some in cases where there
are good reasons to use them.  Shortly after I now get adise to not
use them.  I'm not sure whether this is fully honest - but to you
want to file a bug report against lintian to warn only about missing
symbols files if its not a C++ library?

Kind regards

 Andreas.

-- 
http://fam-tille.de



How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

2018-05-04 Thread Andreas Tille
Hi,

there are several bugs filed against packages of the Debian Med
team.  What's the correct way to fix the symbols file to work
with both versions of gcc?

Kind regards

Andreas.

On Fri, May 04, 2018 at 12:22:23PM +, Matthias Klose wrote:
> Package: src:libquazip
> Version: 0.7.3-6
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-8
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-8/g++-8, but succeeds to build with gcc-7/g++-7. The
> severity of this report will be raised before the buster release.
> 
> The full build log can be found at:
> http://aws-logs.debian.net/2018/05/01/gcc8/libquazip_0.7.3-6_unstable_gcc8.log.gz
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 8, either set CC=gcc-8 CXX=g++-8 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-8/porting_to.html
> 
> [...]
>   _ZN5QListI16QuaZipFileInfo64E6appendERKS0_@Base 0.7.3
> - (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3
> - (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3
>   _ZN5QListI7QStringE13detach_helperEi@Base 0.7.3
>   _ZN5QListI7QStringE18detach_helper_growEii@Base 0.7.3
>   (optional)_ZN5QListI7QStringE5clearEv@Base 0.7.3
>   _ZN5QListI7QStringE6appendERKS0_@Base 0.7.3
> - (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3
> - (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3
>   _ZN5QListI9QFileInfoE13detach_helperEi@Base 0.7.3
> - (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3
> - (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3
>   _ZN6QuaZip10getUnzFileEv@Base 0.7.3
>   _ZN6QuaZip10getZipFileEv@Base 0.7.3
>   _ZN6QuaZip10setCommentERK7QString@Base 0.7.3
> @@ -202,8 +202,8 @@
>   _ZN6QuaZipC2Ev@Base 0.7.3
>   _ZN6QuaZipD1Ev@Base 0.7.3
>   _ZN6QuaZipD2Ev@Base 0.7.3
> - (optional)_ZN7QStringD1Ev@Base 0.7.3
> - (optional)_ZN7QStringD2Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN7QStringD1Ev@Base 0.7.3
> +#MISSING: 0.7.3-6# (optional)_ZN7QStringD2Ev@Base 0.7.3
>   _ZN8QuaCrc325resetEv@Base 0.7.3
>   _ZN8QuaCrc325valueEv@Base 0.7.3
>   _ZN8QuaCrc326updateERK10QByteArray@Base 0.7.3
> dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
> file: see diff output below
> dpkg-gensymbols: warning: debian/libquazip5-1/DEBIAN/symbols doesn't match 
> completely debian/libquazip5-1.symbols
> --- debian/libquazip5-1.symbols (libquazip5-1_0.7.3-6_amd64)
> +++ dpkg-gensymbolsslI1lw 2018-05-02 13:22:04.076864552 +
> @@ -74,8 +74,8 @@
>   _ZN10QuaZipFileD0Ev@Base 0.7.3
>   _ZN10QuaZipFileD1Ev@Base 0.7.3
>   _ZN10QuaZipFileD2Ev@Base 0.7.3
> - _ZN11QStringListC1ERK7QString@Base 0.7.3
> - _ZN11QStringListC2ERK7QString@Base 0.7.3
> +#MISSING: 0.7.3-6# _ZN11QStringListC1ERK7QString@Base 0.7.3
> +#MISSING: 0.7.3-6# _ZN11QStringListC2ERK7QString@Base 0.7.3
>   _ZN11QuaGzipFile11qt_metacallEN11QMetaObject4CallEiPPv@Base 0.7.3
>   _ZN11QuaGzipFile11qt_metacastEPKc@Base 0.7.3
>   _ZN11QuaGzipFile11setFileNameERK7QString@Base 0.7.3
> dh_makeshlibs: failing due to earlier errors
> make: *** [debian/rules:20: binary-arch] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-arch subprocess 
> returned exit status 2
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de



Re: Bug#896483: beast-mcmc FTBFS with TeX Live 2018

2018-04-30 Thread Andreas Tille
Control: tags -1 help

Hi

On Sat, Apr 21, 2018 at 05:57:50PM +0300, Adrian Bunk wrote:
> 
> Fix is attached.

I tried this patch in Git[1] but when I build the packag I'm running
into

...
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode

kpathsea: Running mktextfm ecrm1200
/usr/share/texlive/texmf-dist/web2c/mktexnam: Could not map source abbreviation 
 for ecrm1200.
/usr/share/texlive/texmf-dist/web2c/mktexnam: Need to update ?
mkdir: cannot create directory ‘././nonexistent’: Permission denied
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
input ecrm1200
This is METAFONT, Version 2.7182818 (TeX Live 2018/Debian) (preloaded base=mf)

kpathsea: Running mktexmf ecrm1200

! I can't find file `ecrm1200'.
<*> ...ljfour; mag:=1; nonstopmode; input ecrm1200

Please type another input file name
! Emergency stop.
<*> ...ljfour; mag:=1; nonstopmode; input ecrm1200

Transcript written on mfput.log.
grep: ecrm1200.log: No such file or directory
mktextfm: `mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; input 
ecrm1200' failed to make ecrm1200.tfm.
kpathsea: Appending font creation commands to missfont.log.

kpathsea: Running mktextfm ecrm2074
/usr/share/texlive/texmf-dist/web2c/mktexnam: Could not map source abbreviation 
 for ecrm2074.
/usr/share/texlive/texmf-dist/web2c/mktexnam: Need to update ?
mkdir: cannot create directory ‘././nonexistent’: Permission denied
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; nonstopmode; 
input ecrm2074
This is METAFONT, Version 2.7182818 (TeX Live 2018/Debian) (preloaded base=mf)

kpathsea: Running mktexmf ecrm2074

! I can't find file `ecrm2074'.
<*> ...ljfour; mag:=1; nonstopmode; input ecrm2074

Please type another input file name
! Emergency stop.
<*> ...ljfour; mag:=1; nonstopmode; input ecrm2074

Transcript written on mfput.log.
grep: ecrm2074.log: No such file or directory
...


The strange thing is if I start the pdflatex job inside the pbuilder
environment manually it works.

Any hint would be welcome

  Andreas.


[1] https://salsa.debian.org/med-team/beast-mcmc

-- 
http://fam-tille.de



cmake packages fail to build since yesterday even if package has build before

2018-04-08 Thread Andreas Tille
Hi,

since yesterday packages using cmake are failing.  Example:  libbpp-core
has build yesterday according to

https://buildd.debian.org/status/package.php?p=libbpp-core

but it fails if I build today in current pbuilder (just not building the
build target).  A very similar package libbpp-seq was uploaded later and
fails now:

https://buildd.debian.org/status/package.php?p=libbpp-seq

Nothing inside libbpp-seq was changed that should affect the build
process.  I have the same problem with other cmake based packages.

Any clue what might go wrong here?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Different symbols files on different architectures

2018-04-06 Thread Andreas Tille
Hi Bas,

On Fri, Apr 06, 2018 at 02:18:03PM +0200, Sebastiaan Couwenberg wrote:
> On 04/06/2018 02:08 PM, Andreas Tille wrote:
> > after adding a symbols file to libbpp-core all other architectures are
> > failing due to different symbols (see below for ppc64el[1]) but others
> > are failing as well.  What is the correct way to fix this?
> 
> Use (arch=ppc64el) tags for the symbols, or something more generic like
> arch-bits or arch-endian if those symbols differ based on 32/64 bits
> CPUs or big/little endian.
> 
> See: dpkg-symbols(1)
> https://manpages.debian.org/unstable/dpkg-dev/dpkg-gensymbols.1.en.html#Standard_symbol_tags

I've checked this and I think I understand the task in principle but
in practice for libbpp-core that's a no-go for manual adaption to
edit about 1000 entries (may be per architecture).  Is there some
tool that helps here?  If not my proposed solution would be to
provide a symbols file for amd64 only and move it out of the way
in debian/rules for other architectures.

(I gave it a very minimal shot in branch symbols_i386 but gave up
after some 20+x entries.)

Kind regards

Andreas.

-- 
http://fam-tille.de



Different symbols files on different architectures

2018-04-06 Thread Andreas Tille
Hi,

after adding a symbols file to libbpp-core all other architectures are
failing due to different symbols (see below for ppc64el[1]) but others
are failing as well.  What is the correct way to fix this?

Kind regards

  Andreas.

On Fri, Apr 06, 2018 at 11:04:02AM +0200, Julien Yann Dutheil wrote:
> 
> I was referring to this one [1].
> Seems to be sthg with the new symbol files...?
> 
> Julien.
> 
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=libbpp-core=ppc64el=2.4.0-2=1522864679=log


-- 
http://fam-tille.de



Re: Testsuite of package squizz fails for d/compat > 9

2018-02-18 Thread Andreas Tille
On Sun, Feb 18, 2018 at 04:00:48PM +0100, Sebastiaan Couwenberg wrote:
> The parallel option is enabled by default for compat level >= 10, try
> setting `dh --no-parallel` to disable the parallel option again.

I confirm that running only build time tests with --no-parallel is
sufficient.  I'm a bit astonished that this works despite my previous
analysis that $srcdir is not set.

Anyway thanks for the helpful hint

  Andreas.

-- 
http://fam-tille.de



Testsuite of package squizz fails for d/compat > 9

2018-02-18 Thread Andreas Tille
Hi,

my last commit to squizz[1] breaks the build time tests.  This commit is

index 9e8f3c6..b932c33 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+squizz (0.99d+dfsg-2) UNRELEASED; urgency=medium
+
+  * Check why debhelper compat level 10 makes test fail
+
+ -- Andreas Tille <ti...@debian.org>  Sun, 18 Feb 2018 15:27:33 +0100
+
 squizz (0.99d+dfsg-1) unstable; urgency=medium
 
   * New upstream version
diff --git a/debian/compat b/debian/compat
index ec63514..f599e28 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+10
diff --git a/debian/control b/debian/control
index c543fc7..46b86f0 100644
--- a/debian/control
+++ b/debian/control
@@ -4,8 +4,7 @@ Uploaders: Olivier Sallou <osal...@debian.org>,
    Andreas Tille <ti...@debian.org>
 Section: science
 Priority: optional
-Build-Depends: debhelper (>= 9),
-   dh-autoreconf
+Build-Depends: debhelper (>= 10)
 Standards-Version: 4.1.3
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/squizz.git
 Vcs-Git: https://anonscm.debian.org/git/debian-med/squizz.git
diff --git a/debian/rules b/debian/rules
index 7b8b6cd..b9c72e7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,4 +9,4 @@
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 %:
-   dh $@ --with autoreconf
+   dh $@


The reason why several tests are failing is that the scripts in test/
dir are trying to access for instance files seqdir=$srcdir/sequence but
the $srcdir variable is not properly set (its actually empty).  So
somehow setting d/compat to 10 does something else than simply
autoreconf.  I assumed that the debhelper 10 is actually enforcing
autoreconf which does not seem to be the case here.

Any idea what might be wrong?

Kind regards

   Andreas.

[1] https://anonscm.debian.org/git/debian-med/squizz.git

-- 
http://fam-tille.de



Re: Problem with Qt progam bandage

2018-02-12 Thread Andreas Tille
On Mon, Feb 12, 2018 at 01:01:28PM +0500, Andrey Rahmatullin wrote:
> On Sun, Feb 11, 2018 at 06:51:45PM +0100, Andreas Tille wrote:
> > I'm currently mentoring Cédric Lood to package bandage[1].
> > Unfortunately we both failed to get the package building inside
> > a pbuilder chroot while it builds on Cédric's local machine.
> You could show the error...

Sorry, I was a bit to short.

> This is what I get (locally too):
> 
> dh_auto_configure
> qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
> -fdebug-prefix-map=/home/wrar/tmp/bandage=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
> "QMAKE_CFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/home/wrar/tmp/bandage=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_RELEASE=-g -O2 
> -fdebug-prefix-map=/home/wrar/tmp/bandage=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
> "QMAKE_CXXFLAGS_DEBUG=-g -O2 -fdebug-prefix-map=/home/wrar/tmp/bandage=. 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2" QMAKE_LFLAGS_RELEASE=-Wl,-z,relro 
> QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: PREFIX=/usr
> Usage: /usr/lib/qt5/bin/qmake [mode] [options] [files]
> 
> Doesn't look like something that can be fixed with B-D. If that's the
> whole command it's truncated.

That's the case here as well.  If I do


diff --git a/debian/rules b/debian/rules
index a8d5a44..f71a7aa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ include /usr/share/dpkg/default.mk
 # for hardening you might like to uncomment this:
 # export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
-export QT_SELECT = qt5
+#export QT_SELECT = qt5
 %:
dh $@


than it turns to:

   dh_auto_configure
qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/build/bandage-0.8.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr
qmake: could not find a Qt installation of ''
dh_auto_configure: qmake -makefile "QMAKE_CFLAGS_RELEASE=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g 
-O2 -fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fdebug-prefix-map=/build/bandage-0.8.1=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2" "QMAKE_CXXFLAGS_DEBUG=-g -O2 
-fdebug-prefix-map=/build/bandage-0.8.1=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2" 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr returned exit code 1


I once have "learned a lesson" in previous cases when I had this
incredibly useless message

  qmake: could not find a Qt installation of '' 

   
That

  export QT_SELECT = qt5

helps - but in this case it don't.  I admit I'm totally clueless with
these Qt programs and I keep on wondering what the trick might be to get
the right Build-Depends.

> > [1] https://salsa.debian.org/med-team/bandage
> Also, you haven't pushed the upstream tag.

Thanks - Cédric pushed tags.

Thanks a lot for your patience

  Andreas.

-- 
http://fam-tille.de



Problem with Qt progam bandage

2018-02-11 Thread Andreas Tille
Hi folks,

I'm currently mentoring Cédric Lood to package bandage[1].
Unfortunately we both failed to get the package building inside
a pbuilder chroot while it builds on Cédric's local machine.
I remember that there was a magic way to know how to add the
needed Build-Depends but I forgot how to do this.  Any hint
how to get[1] built?

Thanks a lot for any help

   Andreas.

[1] https://salsa.debian.org/med-team/bandage

-- 
http://fam-tille.de



How to sensibly announce a finalised packaging if I do not intend to upload myself (Was: packjpg packaging: C++ help needed)

2018-01-31 Thread Andreas Tille
Hi Juhani,

On Wed, Jan 31, 2018 at 07:35:47PM +0200, Juhani Numminen wrote:
> 
> The compilation succeeds if I modify the patch not to define DEV_INFOS:
> 
> $ git diff -U0
> diff --git a/debian/patches/dev.patch b/debian/patches/dev.patch
> index 02869a1..415ebda 100644
> --- a/debian/patches/dev.patch
> +++ b/debian/patches/dev.patch
> @@ -14 +14 @@ Description: include developer functions
> -+#define DEV_INFOS // uncomment to include developer information
> ++// #define DEV_INFOS // uncomment to include developer information^M
> 
> (Afterwards I ran "quilt push -a ; quilt refresh" to clean up the patch.)
> 
> With DEV_INFOS defined, packjpg.cpp tries to use member functions that
> were removed in https://github.com/packjpg/packJPG/commit/bb72a4e1b.

Thanks for the hint.  This works and I think I have completed the
packaging.  However, I think I will not upload since the result of
the compression is no usable JPG format any more.  Thus I've added
an according paragraph to the description:

 The compression is done into a packJPG native format PJG which can
 not be used by any image viewer.  To use the image again you need to
 re-do the compression step using packJPG.  Thus the compression is
 only helpful for archiving the images.

So if somebody is interested in taking over packjpg[1] that's fine but
since I have no use personally I will not do the final upload.  Do we
have any proper method to announce a ready packaging for somebody
to pick up.  The closest I know would be an RFP bug - but I'm not
really requesting the packaging, thought.

Kind regards

  Andreas.

[1] https://anonscm.debian.org/git/pkg-phototools/packjpg.git

-- 
http://fam-tille.de



packjpg packaging: C++ help needed

2018-01-31 Thread Andreas Tille
Hi,

I stumbled upon unfinished packaging for packjpg in collab-maint SVN[1].
I intended to save the current packaging state to Git before SVN will be
closed down and consiered pkg-phototools a better place than
collab-maint.  So I updated the packaging to latest upstream and pushed
the packaging to Git[2].

When trying to build[2] I stumbled upon

...
g++ -c -o aricoder.o aricoder.cpp -I. -O3 -Wall -pedantic -funroll-loops 
-ffast-math -fsched-spec-load -fomit-frame-pointer -std=c++14 -DUNIX
packjpg.cpp: In function 'bool pack_pjg()':
packjpg.cpp:3312:22: error: 'class Writer' has no member named 'getpos'
  dev_size = str_out->getpos();^M
  ^~
packjpg.cpp:3314:27: error: 'class Writer' has no member named 'getpos'
  dev_size_hdr += str_out->getpos() - dev_size;^M
   ^~
packjpg.cpp:3340:23: error: 'class Writer' has no member named 'getpos'
   dev_size = str_out->getpos();^M
   ^~
packjpg.cpp:3343:35: error: 'class Writer' has no member named 'getpos'
   dev_size_zsr[ cmp ] += str_out->getpos() - dev_size;^M
   ^~
packjpg.cpp:3344:23: error: 'class Writer' has no member named 'getpos'
   dev_size = str_out->getpos();^M
   ^~
...


Unfortunately I have no idea how to fix this.  Any hints?

Kind regards

Andreas.

[1] https://anonscm.debian.org/viewvc/collab-maint/deb-maint/packjpg/
[2] https://anonscm.debian.org/cgit/pkg-phototools/packjpg.git

-- 
http://fam-tille.de



Re: r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)

2018-01-12 Thread Andreas Tille
Hi Dirk,

On Thu, Jan 11, 2018 at 10:51:45AM -0600, Dirk Eddelbuettel wrote:
> 
> I had some friendly emails with Stefan (git2r upstream) when he started the R
> package git2r (as I needed some features in my drat R package) and he
> expressed quite some frustration at working with libgit2 as it changed so
> much upstream.
> 
> I know we collectively really hate embedding copies, but r-cran-git2r may be
> defensible case because libgot2 is too complex / volatile.

Thanks for your insight, uploaded with code copy.

Kind regards

   Andreas.

-- 
http://fam-tille.de



r-cran-git2r uses private header files of libgit2 (Was: Help with libgit2 needed to strip code copy from r-cran-git2r)

2018-01-11 Thread Andreas Tille
Hi again,

On Thu, Jan 11, 2018 at 08:34:09AM +0100, Andreas Tille wrote:
> >   # Add include paths for git2r
> >  -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
> > ${CPPFLAGS}"
> > -+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
> > ++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"
> 
> ...
> gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -idirafter 
> /usr/include/git2  -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
> -DGIT_OPENSSL -DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL -DGIT_SSH -DGIT_CURL 
> -DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R  -fpic  
> -g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c 
> git2r_branch.c -o git2r_branch.o
> git2r_branch.c: In function 'git2r_branch_upstream_canonical_name':
> git2r_branch.c:407:19: error: 'GIT_BUF_INIT' undeclared (first use in this 
> function); did you mean 'GIT_REF_OID'?
>  git_buf buf = GIT_BUF_INIT;
>^~~~
>GIT_REF_OID
> git2r_branch.c:407:19: note: each undeclared identifier is reported only once 
> for each function it appears in
> git2r_branch.c:427:11: warning: implicit declaration of function 
> 'git_buf_join3'; did you mean 'git_buf_set'? [-Wimplicit-function-declaration]
>  err = git_buf_join3(
>^
>git_buf_set
> /usr/lib/R/etc/Makeconf:159: recipe for target 'git2r_branch.o' failed
> 
> 
> This is in
> 
>/usr/include/git2/buffer.h:#define GIT_BUF_INIT_CONST(STR,LEN) { (char 
> *)(STR), 0, (size_t)(LEN) }
> 
> but it seems a different buffer.h is used.

I dived a bit deeper into this and found this other buffer.h: It is a
private header from libgit2/src/ and other headers from there are needed
as well like common.h, cc_compat.h, thread-utils.h and possibly other
header files.

That's ... uh, no idea how to call this.  What would you suggest:
Live with the nasty code copy and just add it to debian/copyright or
hack around all those usage of private header files.  I've pushed some
changes to Git[1] which keeps some (not all needed - for instance
thread-utils.h is missing) but if there is no better idea how to deal
with this I think I have better things to spent my time on than getting
rid of a code copy you can not really cleanly get rid of.

Kind regards

   Andreas.

[1] https://salsa.debian.org/r-pkg-team/r-cran-git2r.git

-- 
http://fam-tille.de



Re: Help with libgit2 needed to strip code copy from r-cran-git2r

2018-01-10 Thread Andreas Tille
On Thu, Jan 11, 2018 at 12:58:16AM +0100, Jose Luis Rivero wrote:
> dah .. I sent the reverse patch sorry:
> 
> diff --git a/debian/patches/use_debian_packaged_libgit2.patch
> b/debian/patches/use_debian_packaged_libgit2.patch
> index c716773..ab603cd 100644
> --- a/debian/patches/use_debian_packaged_libgit2.patch
> +++ b/debian/patches/use_debian_packaged_libgit2.patch
> @@ -87,7 +87,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
>   if test "x${have_ssh2}" = xyes; then
>  -LIBSSH2_CFLAGS="-Ilibgit2/deps/libssh2/include"
>  -LIBSSH2_LIBS="-Llibgit2/deps/libssh2/lib -lssh2"
> -+LIBSSH2_CFLAGS="-I/usr/include/git2"
> ++LIBSSH2_CFLAGS="-idirafter /usr/include/git2"
>  +LIBSSH2_LIBS="-lgit2 -lssh2"
>   fi
>   fi
> @@ -97,7 +97,7 @@ Last-Update: Wed, 10 Jan 2018 10:33:31 +0100
> 
>   # Add include paths for git2r
>  -CPPFLAGS="-I. -Ilibgit2/src -Ilibgit2/include -Ilibgit2/deps/http-parser
> ${CPPFLAGS}"
> -+CPPFLAGS="-I. -I/usr/include/git2 ${CPPFLAGS}"
> ++CPPFLAGS="-I. -idirafter /usr/include/git2 ${CPPFLAGS}"

...
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -idirafter /usr/include/git2 
 -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL 
-DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL -DGIT_SSH -DGIT_CURL 
-DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R  -fpic  
-g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c 
git2r_branch.c -o git2r_branch.o
git2r_branch.c: In function 'git2r_branch_upstream_canonical_name':
git2r_branch.c:407:19: error: 'GIT_BUF_INIT' undeclared (first use in this 
function); did you mean 'GIT_REF_OID'?
 git_buf buf = GIT_BUF_INIT;
   ^~~~
   GIT_REF_OID
git2r_branch.c:407:19: note: each undeclared identifier is reported only once 
for each function it appears in
git2r_branch.c:427:11: warning: implicit declaration of function 
'git_buf_join3'; did you mean 'git_buf_set'? [-Wimplicit-function-declaration]
 err = git_buf_join3(
   ^
   git_buf_set
/usr/lib/R/etc/Makeconf:159: recipe for target 'git2r_branch.o' failed


This is in

   /usr/include/git2/buffer.h:#define GIT_BUF_INIT_CONST(STR,LEN) { (char 
*)(STR), 0, (size_t)(LEN) }

but it seems a different buffer.h is used.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: Help with libgit2 needed to strip code copy from r-cran-git2r

2018-01-10 Thread Andreas Tille
Hi Aaron,

On Wed, Jan 10, 2018 at 06:37:17PM -0500, Aaron M. Ucko wrote:
> Andreas Tille <andr...@an3as.eu> writes:
> 
> > Hi,
> 
> Hi, Andreas.
> 
> > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -I/usr/include/git2  
> > -DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL 
> > -DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL - DGIT_SSH -DGIT_CURL 
> > -DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R  
> > -fpic  -g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. 
> > -fstack-protector-strong -Wformat - Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2 -g  -c git2r.c -o git2r.o
> 
> Please try leaving off -I/usr/include/git2 to avoid this unwanted
> shadowing.  (git2.h includes the other headers as "git2/*.h", so you
> shouldn't need that flag.)

If I leave this of it ends up in a missing include refs.h (which is
in /usr/include/git2.

Kind regards

  Andreas.

PS: I also tried the other proposed solution - see my answer there.


-- 
http://fam-tille.de



Help with libgit2 needed to strip code copy from r-cran-git2r

2018-01-10 Thread Andreas Tille
Hi,

r-cran-git2r was rejected by ftpmaster[1] due to the code copy of
libgit2.  I intended to fix this by removing the code copy and linking
against the Debian packaged libgit2.  The attempt to do so can be found
in Git[2].  Unfortunately that seems to be not as simple as I was
hoping for since I'm running into:

...
configure: creating ./config.status
config.status: creating src/Makevars
** libs
make[1]: Entering directory '/build/r-cran-git2r-0.21.0+dfsg/src'
gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG -I. -I/usr/include/git2  
-DGIT_ARCH_64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DGIT_OPENSSL 
-DLIBGIT2_NO_FEATURES_H -DGIT_SHA1_OPENSSL - DGIT_SSH -DGIT_CURL 
-DGIT_USE_STAT_MTIM -DGIT_USE_NSEC -DHAVE_FUTIMENS -DHAVE_QSORT_R  -fpic  
-g -O2 -fdebug-prefix-map=/build/r-base-3.4.3=. -fstack-protector-strong 
-Wformat - Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -g  -c 
git2r.c -o git2r.o
In file included from /usr/include/git2/common.h:29:0,
 from /usr/include/git2/annotated_commit.h:10,
 from /usr/include/git2.h:11,
 from git2r.c:32:
/usr/include/git2/inttypes.h:33:2: error: #error "Use this header only with 
Microsoft Visual C++ compilers!"
 #error "Use this header only with Microsoft Visual C++ compilers!"
  ^
In file included from /usr/include/git2/inttypes.h:46:0,
 from /usr/include/git2/common.h:29,
 from /usr/include/git2/annotated_commit.h:10,
 from /usr/include/git2.h:11,
 from git2r.c:32:
/usr/include/git2/stdint.h:33:2: error: #error "Use this header only with 
Microsoft Visual C++ compilers!"
 #error "Use this header only with Microsoft Visual C++ compilers!"
  ^
In file included from /usr/include/git2/inttypes.h:46:0,
 from /usr/include/git2/common.h:29,
 from /usr/include/git2/annotated_commit.h:10,
 from /usr/include/git2.h:11,
 from git2r.c:32:
/usr/include/git2/stdint.h:89:30: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'int64_t'
 typedef signed __int64   int64_t;
  ^~~
/usr/include/git2/stdint.h:90:30: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before 'uint64_t'
 typedef unsigned __int64 uint64_t;
  ^~~~
/usr/include/git2/stdint.h:101:9: error: unknown type name 'uint64_t'
 typedef uint64_t  uint_least64_t;
 ^~~~
/usr/include/git2/stdint.h:111:9: error: unknown type name 'uint64_t'
 typedef uint64_t  uint_fast64_t;
 ^~~~
/usr/include/git2/stdint.h:124:9: error: unknown type name 'uint64_t'
 typedef uint64_t  uintmax_t;
 ^~~~
In file included from /usr/include/git2/common.h:29:0,
 from /usr/include/git2/annotated_commit.h:10,
 from /usr/include/git2.h:11,
 from git2r.c:32:
/usr/include/git2/inttypes.h:282:1: error: unknown type name '_inline'; did you 
mean '__nlink_t'?
 _inline
 ^~~
 __nlink_t
/usr/include/git2/inttypes.h:284:11: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '__cdecl'
 imaxdiv_t __cdecl imaxdiv(intmax_t numer, intmax_t denom)
   ^~~
/usr/include/git2/inttypes.h:284:11: error: unknown type name '__cdecl'
/usr/lib/R/etc/Makeconf:159: recipe for target 'git2r.o' failed
make[1]: *** [git2r.o] Error 1
make[1]: Leaving directory '/build/r-cran-git2r-0.21.0+dfsg/src'
...


I admit I have no idea why the includes delivered by libgit2 do
not work here.  Any idea for a correct fix?

Kind regards

   Andreas.

[1] 
http://lists.alioth.debian.org/pipermail/debian-science-maintainers/2018-January/056928.html
[2] https://salsa.debian.org/r-pkg-team/r-cran-git2r.git

-- 
http://fam-tille.de



[Help] How to relace PADDED define (Was: Bug#884236: fis-gtm FTBFS with linux-libc-dev 4.14.2-1)

2017-12-19 Thread Andreas Tille
Control: tags -1 help

Any hint how to replace this define?

Thanks for any help

   Andreas.

- Forwarded message from Adrian Bunk  -

Date: Tue, 12 Dec 2017 22:28:40 +0200
From: Adrian Bunk 
To: Debian Bug Tracking System 
Subject: Bug#884236: fis-gtm FTBFS with linux-libc-dev 4.14.2-1
X-Debian-PR-Message: report 884236
X-Debian-PR-Package: src:fis-gtm
X-Debian-PR-Keywords: 
X-Debian-PR-Source: fis-gtm

Source: fis-gtm
Version: 6.3-002-3
Severity: serious

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/fis-gtm.html

...
/usr/bin/cc -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-D_XOPEN_SOURCE=600 -I/build/1st/fis-gtm-6.3-002/obj-x86_64-linux-gnu/gen 
-I/build/1st/fis-gtm-6.3-002/sr_linux -I/build/1st/fis-gtm-6.3-002/sr_x86_64 
-I/build/1st/fis-gtm-6.3-002/sr_x86_regs 
-I/build/1st/fis-gtm-6.3-002/sr_unix_gnp 
-I/build/1st/fis-gtm-6.3-002/sr_unix_cm -I/build/1st/fis-gtm-6.3-002/sr_unix 
-I/build/1st/fis-gtm-6.3-002/sr_port_cm -I/build/1st/fis-gtm-6.3-002/sr_port 
-I/build/1st/fis-gtm-6.3-002/obj-x86_64-linux-gnu -I/usr/local/include 
-I/usr/local/ssl/include  -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -ansi -fPIC  
-fsigned-char -Wmissing-prototypes -Wreturn-type -Wpointer-sign 
-fno-omit-frame-pointer -O2 -DNDEBUG   -o 
CMakeFiles/gtm_threadgbl_deftypes.dir/sr_port/gtm_threadgbl_deftypes.c.o   -c 
/build/1st/fis-gtm-6.3-002/sr_port/gtm_threadgbl_deftypes.c
In file included from /build/1st/fis-gtm-6.3-002/sr_port/gdsfhead.h:29:0,
 from 
/build/1st/fis-gtm-6.3-002/sr_port/gtm_threadgbl_deftypes.c:43:
/build/1st/fis-gtm-6.3-002/sr_port/gtm_libaio.h:72:2: warning: parameter names 
(without types) in function declaration
  __u32 PADDED(aio_key, aio_reserved1);
  ^
/build/1st/fis-gtm-6.3-002/sr_port/gtm_libaio.h:72:8: error: field 'PADDED' 
declared as a function
  __u32 PADDED(aio_key, aio_reserved1);
^~
CMakeFiles/gtm_threadgbl_deftypes.dir/build.make:65: recipe for target 
'CMakeFiles/gtm_threadgbl_deftypes.dir/sr_port/gtm_threadgbl_deftypes.c.o' 
failed
make[3]: *** 
[CMakeFiles/gtm_threadgbl_deftypes.dir/sr_port/gtm_threadgbl_deftypes.c.o] 
Error 1


The PADDED define was removed from /usr/include/linux/aio_abi.h

___
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging


- End forwarded message -

-- 
http://fam-tille.de



What to do if arch:all package is lacking arch:any package on specific architecture

2017-12-19 Thread Andreas Tille
Hi,

there is a series of bugs filed about missing Build-Depends
python-pbcore on i386.  The problem is that the Arch:all package
python-pbcore Depends the Arch:any package python-pysam which is not
available on all architectures.

I wonder whether the issue would be more transparent when adding
python-pysam to the Build-Depends of the packages affected by a larger
series of bugs (two of these in CC #860631, #860615) and thus preventing
the autobuilders attempting to build what needs to fail.

Or is there any better solution for the issue?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Test failure due to C++ error

2017-12-15 Thread Andreas Tille
control: reopen -1

While the header that was formerly missing is provided the C++ file
used for testing has syntax errors:


khmer/src/oxli(master) $ c++ -o test-prog-static -static -std=c++11 
-I/usr/local/include -I/usr/include/oxli/smhasher test-compile.cc 
-L/usr/local/lib -loxli -lbz2 -lz
test-compile.cc: In function ‘int main()’:
test-compile.cc:46:26: error: variable ‘oxli::Countgraph test’ has initializer 
but incomplete type
 oxli::Countgraph test(1,1);
  ^


So I'm reopening this bug.

Any help how to fix this would be welcome.

Kind regards

Andreas.

See also
  
https://ci.debian.net/data/autopkgtest/unstable/amd64/k/khmer/20171215_215850/log.gz

-- 
http://fam-tille.de



Suspected change in test dependencies - where is "discover" (Was: [Help] Re: Bug#884040: python-matplotlib-venn FTBFS: test failure)

2017-12-12 Thread Andreas Tille
Hi again,

On Mon, Dec 11, 2017 at 09:27:57AM +0100, Andreas Tille wrote:
> 
> On Sun, Dec 10, 2017 at 09:05:07PM +0200, Adrian Bunk wrote:
> > === warnings summary 
> > ===
> > None
> >   [pytest] section in setup.cfg files is deprecated, use [tool:pytest] 
> > instead.
> 
> I've fixed this in Git[1]
>  
> > -- Docs: http://doc.pytest.org/en/latest/warnings.html
> > == 1 warnings in 0.00 seconds 
> > ==
> > ERROR: file not found: discover
> 

I tried to build on local host (not in a pbuilder chroot) and than this
issue does not occure.  Seems I need to add a new Build-Depends for
whatever reason.  Any hint which one?  I parsed the package pool for
anything Python related containing a file "discover" / "discover.py" but
besides many hits there was no real helpful one.

Kind regards

  Andreas.

-- 
http://fam-tille.de




Re: [Help] How to fix type issue on 32bit archs in C++ (Was: Bug#852839: baitfisher: FTBFS (32-bit): mixes ::size_t and faststring::size_t)

2017-12-11 Thread Andreas Tille
On Mon, Dec 11, 2017 at 03:23:49PM +0200, Juhani Numminen wrote:
> This is not related to the FTBFS, but your and James' messages made me
> take a look at the package.  I found its makefile could be improved to
> accept {CPP,CXX,LD}FLAGS. So if you're also interested in getting
> hardening to work for baitfisher please check out
> https://github.com/cmayer/BaitFisher-package/pull/8

Pushed to Git - thanks for the patch

  Andreas.

-- 
http://fam-tille.de



[Help] How to fix type issue on 32bit archs in C++ (Was: Bug#852839: baitfisher: FTBFS (32-bit): mixes ::size_t and faststring::size_t)

2017-12-11 Thread Andreas Tille
control: tags -1 help

Hi,

I admit I have to poor C++ knowledge to fix this possibly very simple
issue.  Any help would be welcome.

Kind regards

  Andreas.

On Fri, Jan 27, 2017 at 01:23:40PM -0500, Aaron M. Ucko wrote:
> Source: baitfisher
> Version: 1.0+dfsg-1
> Severity: important
> Justification: fails to build from source
> 
> Builds of baitfisher for 32-bit architectures such as i386 have been
> failing:
> 
>   range_functions.h: In member function 'bool CRangeList::add(faststring)':
>   range_functions.h:596:31: error: invalid initialization of non-const 
> reference of type 'faststring::size_t& {aka long unsigned int&}' from an 
> rvalue of type 'faststring::size_t {aka long unsigned int}'
> 
> The issue appears to be that, for some reason, class faststring has
> (https://anonscm.debian.org/cgit/debian-med/baitfisher.git/tree/faststring2.h#n128)
> 
>   // Shadow the "global" size_t typedef for this class.
> typedef unsigned long size_t;
> 
> but CRangeList::add uses the global size_t typedef, which is formally
> unsigned int on 32-bit systems:
> 
> https://anonscm.debian.org/cgit/debian-med/baitfisher.git/tree/range_functions.h#n591
> 
> size_t pos1=0, pos2, len=str.size();
> 
> Although the two types are de facto equivalent on 32-bit
> architectures, C++ compilers insist on treating them as different.
> (This problem doesn't occur on 64-bit architectures, on which both
> size_t typedefs are unsigned long.)
> 
> 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-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
> 

-- 
http://fam-tille.de



Re: cc1plus: error: -Wformat-security ignored without -Wformat (Re: CMake help needed to enable hdf5 for gatb-core)

2017-12-10 Thread Andreas Tille
On Sun, Dec 10, 2017 at 12:59:30PM +0100, Gert Wollny wrote:
> In summary, Debian flags set -Wformat and -Werror=format-security, but
> the package also sets -Wno-format which overrides the former and
> results in the error message. 
> 
> Pushed another patch.

Cool.  Thanks a lot!

> Now it seems it still wants to install  (non
> existing) HDF5 files. 

I guess this is a relict of the local copy of hdf5 files and it
just needs fixing the install target.  Hmmm, may be I'll manage
tomorrow (if nobody beats me before ;-) ).

Thanks a lot for your help

  Andreas.

-- 
http://fam-tille.de



cc1plus: error: -Wformat-security ignored without -Wformat (Re: CMake help needed to enable hdf5 for gatb-core)

2017-12-09 Thread Andreas Tille
Hi again,

On Mon, Dec 04, 2017 at 05:59:28PM +0100, Andreas Tille wrote:
> some problems with gatb[1].  With the new upstream version, I get:
> 
> cc1plus: error: -Wformat-security ignored without -Wformat 
> [-Werror=format-security]
> cc1plus: error: -Wformat-security ignored without -Wformat 
> [-Werror=format-security]

I received another (unrelated) patch by Gert Wollny who told me that he
can not reproduce the issue above.  I refreshed by cowbuilder chroot but
the issue remains:


...
cd /build/gatb-core-1.4.0+dfsg/obj-x86_64-linux-gnu/src && /usr/bin/c++   
-I/usr/include/hdf5/serial 
-I/build/gatb-core-1.4.0+dfsg/obj-x86_64-linux-gnu/include 
-I/build/gatb-core-1.4.0+dfsg/obj-x86_64-linux-gnu/include/None 
-I/build/gatb-core-1.4.0+dfsg/gatb-core/src 
-I/build/gatb-core-1.4.0+dfsg/gatb-core/thirdparty  -g -O2 
-fdebug-prefix-map=/build/gatb-core-1.4.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -msse2 
-msse4.2 -mpopcnt   -std=c++11 -O3 -DNDEBUG -Wall -Wno-unused-function 
-Wno-format -Wno-unknown-pragmas -Wno-invalid-offsetof -o 
CMakeFiles/gatbcore-static.dir/gatb/bank/impl/Bank.cpp.o -c 
/build/gatb-core-1.4.0+dfsg/gatb-core/src/gatb/bank/impl/Bank.cpp
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
/build/gatb-core-1.4.0+dfsg/gatb-core/src/gatb/bank/impl/BankBinary.cpp: In 
function 'bool gatb::core::bank::impl::checkMagic(FILE*)':
/build/gatb-core-1.4.0+dfsg/gatb-core/src/gatb/bank/impl/BankBinary.cpp:54:11: 
warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', 
declared with attribute warn_unused_result [-Wunused-result]
 fread (, sizeof(value), 1, file);
 ~~^~~~
/build/gatb-core-1.4.0+dfsg/gatb-core/src/gatb/bank/impl/BankBinary.cpp: In 
member function 'virtual void 
gatb::core::bank::impl::BankBinary::Iterator::next()':
/build/gatb-core-1.4.0+dfsg/gatb-core/src/gatb/bank/impl/BankBinary.cpp:453:15: 
warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', 
declared with attribute warn_unused_result [-Wunused-result]
 fread (_bufferData->getBuffer(), sizeof( char),block_size, 
binary_read_file); // read a block of reads into the buffer
 
~~^~
cc1plus: some warnings being treated as errors
src/CMakeFiles/gatbcore-static.dir/build.make:113: recipe for target 
'src/CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankBinary.cpp.o' failed
make[3]: *** 
[src/CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankBinary.cpp.o] Error 1


Does this (obviously not always reproducible) problem ring a bell?

Kind regards

   Andreas.
 
> [1] https://anonscm.debian.org/git/debian-med/gatb-core.git

-- 
http://fam-tille.de



Re: [Debian-med-packaging] C++ help needed for lamarc

2017-12-04 Thread Andreas Tille
Hi Gert,

thanks for your hint.

On Mon, Dec 04, 2017 at 07:32:42PM +0100, Gert Wollny wrote:
> 
> make_pair doesn't require the explicite type specification, i.e. the
> following should work: 
> 
> - return make_pair(eigvals, eigvecs);
> + return make_pair(eigvals, eigvecs);

This worked at that very place, but later I get:


src/tree/arrangervec.cpp: In member function ‘void 
ArrangerVec::CopyAllMembers(const ArrangerVec&)’:
src/tree/arrangervec.cpp:125:83: error: no matching function for call to 
‘make_pair(std::__cxx11::string, Arranger*&)’
 arrangers.insert(std::make_pair(arr->GetName(), 
arr));

   ^
In file included from /usr/include/c++/7/bits/stl_algobase.h:64:0,
 from /usr/include/c++/7/bits/char_traits.h:39,
 from /usr/include/c++/7/ios:40,
 from /usr/include/c++/7/ostream:38,
 from /usr/include/c++/7/iostream:39,
 from src/tree/arrangervec.cpp:12:
/usr/include/c++/7/bits/stl_pair.h:519:5: note: candidate: template constexpr std::pair::__type, 
typename std::__decay_and_strip<_T2>::__type> std::make_pair(_T1&&, _T2&&)
 make_pair(_T1&& __x, _T2&& __y)
 ^
/usr/include/c++/7/bits/stl_pair.h:519:5: note:   template argument 
deduction/substitution failed:
src/tree/arrangervec.cpp:125:83: note:   cannot convert ‘arr’ (type 
‘Arranger*’) to type ‘Arranger*&&’
 arrangers.insert(std::make_pair(arr->GetName(), 
arr));

   ^
Makefile:6859: recipe for target 'lamarc-arrangervec.o' failed


Kind regards

   Andreas. 

-- 
http://fam-tille.de



Re: CMake help needed to enable hdf5 for gatb-core (Was: [MoM] Re: gatb-core packaging)

2017-12-04 Thread Andreas Tille
Hi again

some problems with gatb[1].  With the new upstream version, I get:

cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]


Any idea how to fix this?

Kind regards

  Andreas. 


[1] https://anonscm.debian.org/git/debian-med/gatb-core.git

-- 
http://fam-tille.de



C++ help needed for lamarc

2017-12-04 Thread Andreas Tille
Hi,

I intend to package lamarc[1] and hit the following C++ issue:

...
g++ -DHAVE_CONFIG_H -I. -I./config   -Wdate-time -D_FORTIFY_SOURCE=2 
-DLAMARC_COMPILE_LINUX -DNDEBUG  -Wall -Wextra -Wno-unused -I 
./config -I ./config -I ./src/bayeslike -I ./   src/control -I ./src/conversion 
-I ./src/convErr -I ./src/convModel -I ./src/convParse -I ./src/convStrings -I 
./src/convUtil -I ./src/datalike -I ./src/force -I ./src/guiconv -I ./src/  
guiutil -I ./src/lamarcmenus -I ./src/menu -I ./src/postlike -I ./src/report -I 
./src/tools -I ./src/tree -I ./src/ui_interface -I ./src/ui_util -I 
./src/ui_vars -I ./src/xml -I/usr/include/ boost -I ./resources -DTIXML_USE_STL 
-g -O2 -fdebug-prefix-map=/build/lamarc-2.1.10+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -c -o lamarc-mathx.o `test -f 'src/tools/ 
mathx.cpp' || echo './'`src/tools/mathx.cpp
src/tools/mathx.cpp: In member function ‘std::pair > EigenCalculator::Eigen(DoubleVec2d)’:
src/tools/mathx.cpp:781:64: error: no matching function for call to 
‘make_pair(DoubleVec1d&, DoubleVec2d&)’
 return make_pair(eigvals, eigvecs);
^
In file included from /usr/include/c++/7/bits/stl_algobase.h:64:0,
 from /usr/include/c++/7/bits/char_traits.h:39,
 from /usr/include/c++/7/ios:40,
 from /usr/include/c++/7/ostream:38,
 from /usr/include/c++/7/iostream:39,
 from src/tools/mathx.cpp:13:
/usr/include/c++/7/bits/stl_pair.h:519:5: note: candidate: template constexpr std::pair::__type, 
typename std:: __decay_and_strip<_T2>::__type> 
std::make_pair(_T1&&, _T2&&)
 make_pair(_T1&& __x, _T2&& __y)
 ^
/usr/include/c++/7/bits/stl_pair.h:519:5: note:   template argument 
deduction/substitution failed:
src/tools/mathx.cpp:781:64: note:   cannot convert ‘eigvals’ (type ‘DoubleVec1d 
{aka std::vector}’) to type ‘std::vector&&’
 return make_pair(eigvals, eigvecs);
^
Makefile:6719: recipe for target 'lamarc-mathx.o' failed


Any hint how to fix this?

Kind regards

   Andreas.


[1] https://anonscm.debian.org/git/debian-med/lamarc.git

-- 
http://fam-tille.de



Help to get Qt GUI of clonalorigin needed

2017-12-03 Thread Andreas Tille
Hi,

I intend to package ClonalOrigin and the packaging is ready in Debian
Med Git[1] in principle.  I needed to apply some patches to migrate the
code from Qt4 to Qt5[2] which enabled to **build** the package.
However, my totally Qt uneducated simply web search inspired patches
only enable to **build** the GUI.  When trying to run clonalorigin-gui
(from clonalorgigin-gui package) the interface is totally empty.  Even
the Help menu entry does not change this.  In the xterm that I used to
start the GUI I get:

$ clonalorigin-gui 
QMetaObject::connectSlotsByName: No matching signal for 
on_actionGelman_Rubin_test_activated()
QMetaObject::connectSlotsByName: No matching signal for 
on_actionShowComment_activated()
QMetaObject::connectSlotsByName: No matching signal for 
on_actionExit_activated()
QMetaObject::connectSlotsByName: No matching signal for 
on_actionSave_picture_activated()
QMetaObject::connectSlotsByName: No matching signal for 
on_actionReOpen_output_file_activated()
QMetaObject::connectSlotsByName: No matching signal for 
on_actionOpen_output_file_activated()
QMetaObject::connectSlotsByName: No matching signal for 
on_actionAbout_activated()
...

I do not have the slightest idea what this might mean and how to fix it.
Any help from a kind Qt educated soul would be really appreciated.

Kind regards

 Andreas.

[1] https://anonscm.debian.org/git/debian-med/clonalorigin.git
[2] 
https://anonscm.debian.org/git/debian-med/clonalorigin.git/tree/debian/patches/qt5.patch

-- 
http://fam-tille.de



Re: Bug#882349: sra-sdk FTBFS with glibc 2.25

2017-12-02 Thread Andreas Tille
control: tags -1 help

Hi,

is there any hint how to fix this issue?

On Tue, Nov 21, 2017 at 07:34:09PM +0200, Adrian Bunk wrote:
> Source: sra-sdk
> Version: 2.8.1-2+dfsg-2
> Severity: serious
> Tags: buster sid
> Forwarded: https://github.com/ncbi/sra-tools/issues/67
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/sra-sdk.html
> 
> ...
> /build/1st/sra-sdk-2.8.1-2+dfsg/tools/bam-loader/bam.c:3998:17: error: 
> conflicting types for 'canonicalize'
>  static unsigned canonicalize(uint32_t cigar[], unsigned n)
>  ^~~~
> In file included from /usr/include/features.h:406:0,
>  from 
> /usr/include/x86_64-linux-gnu/bits/libc-header-start.h:33,
>  from /usr/include/stdint.h:26,
>  from /usr/lib/gcc/x86_64-linux-gnu/7/include/stdint.h:9,
>  from /usr/include/ncbi-vdb/kfc/defs.h:34,
>  from /usr/include/ncbi-vdb/klib/defs.h:31,
>  from 
> /build/1st/sra-sdk-2.8.1-2+dfsg/tools/bam-loader/bam.c:27:
> /usr/include/x86_64-linux-gnu/bits/mathcalls.h:435:1: note: previous 
> declaration of 'canonicalize' was here
>  __MATHDECL_1 (int, canonicalize,, (_Mdouble_ *__cx, const _Mdouble_ *__x));
>  ^
> /build/1st/sra-sdk-2.8.1-2+dfsg/tools/bam-loader/bam.c:2990:17: warning: 
> 'SequenceLengthFromCIGAR' defined but not used [-Wunused-function]
>  static unsigned SequenceLengthFromCIGAR(const BAM_Alignment *self)
>  ^~~
> /build/1st/sra-sdk-2.8.1-2+dfsg/build/Makefile.rules:31: recipe for target 
> 'bam.o' failed
> make[5]: *** [bam.o] Error 1
> 

Any help would be welcome.

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: CMake help needed to enable hdf5 for gatb-core (Was: [MoM] Re: gatb-core packaging)

2017-11-28 Thread Andreas Tille
On Tue, Nov 28, 2017 at 10:00:48PM +0100, Christian Seiler wrote:
> Hi Andreas,
> 
> On 11/28/2017 11:52 AM, Andreas Tille wrote:
> > it turned out hat the cmake issue is a bit tricky for a MoM project so I
> > gave it a try myself.  The current state of gatb-core packaging is in
> > Git[1].  I went as far as my poor cmake knowledge permits to replace the
> > cmake hdf5 code to use the Debian packaged code after the internal code
> > copy was removed.  Unfortunately I failed to get the proper -I options
> > propagated to the compiler call since I'm ending up with:
> 
> Problem is that the system-wide hdf5.h  is always directly in the include
> path (#include , wherease the embedded code copy of the project
> you're trying to use was somehow put into the source project in such a
> way that they used #include  (see the error message). And
> since that _adds_ a directory layer, there's no -I flag you can pass that
> will make this work out of the box.
> 
> So you'll definitely need to patch the source files and replace
> #include  with #include 

I did so in
   
https://anonscm.debian.org/cgit/debian-med/gatb-core.git/tree/debian/patches/fix_hdf5_includes.patch

I guess this has no better effect than:

...
[  5%] Building CXX object 
src/CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankConverterAlgorithm.cpp.o
cd /build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/src && /usr/bin/c++   
-I/build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/include 
-I/build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/include/None 
-I/build/gatb-core-1.3.0+dfsg/gatb-core/src 
-I/build/gatb-core-1.3.0+dfsg/gatb-core/thirdparty  -g -O2 
-fdebug-prefix-map=/build/gatb-core-1.3.0+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -msse2 
-msse4.2 -mpopcnt   -std=c++11 -O3 -DNDEBUG -Wall -Wno-unused-function 
-Wno-format -Wno-unknown-pragmas -Wno-invalid-offsetof -o 
CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankConverterAlgorithm.cpp.o -c 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/BankConverterAlgorithm.cpp
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
In file included from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/tools/math/Integer.hpp:29:0,
 from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/tools/misc/impl/Algorithm.hpp:37,
 from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/BankConverterAlgorithm.hpp:31,
 from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/BankConverterAlgorithm.cpp:20:
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/tools/math/LargeInt.hpp:38:10: 
fatal error: hdf5.h: No such file or directory
 #include 
  ^~~~
cc1plus: some warnings being treated as errors
compilation terminated.
...


Since I also need to implement this ...

> Then you also have the problem that your compile line doesn't include
> the HDF5 directories. I haven't looked at your packaging, but in
> general you need to have the following in CMake to link against HDF5:
> 
> find_package(HDF5 REQUIRED)
> include_directories(${HDF5_INCLUDE_DIRS})
> target_link_libraries(name_of_program_or_library ${HDF5_LIBRARIES})
> 
> The last line possibly multiple times for multiple targets.

... properly.

I also added this to
   
https://anonscm.debian.org/cgit/debian-med/gatb-core.git/tree/debian/patches/use_debian_packaged_hdf5.patch
(line 60+) but I have no idea how to name the targets.  I'm sorry
but I'm quite illiterate in cmake and have no idea where to find
the proper location for this line and the target name. :-(

Sorry for requesting more detailed help.

Kind regards

   Andreas.

-- 
http://fam-tille.de



CMake help needed to enable hdf5 for gatb-core (Was: [MoM] Re: gatb-core packaging)

2017-11-28 Thread Andreas Tille
Hi,

it turned out hat the cmake issue is a bit tricky for a MoM project so I
gave it a try myself.  The current state of gatb-core packaging is in
Git[1].  I went as far as my poor cmake knowledge permits to replace the
cmake hdf5 code to use the Debian packaged code after the internal code
copy was removed.  Unfortunately I failed to get the proper -I options
propagated to the compiler call since I'm ending up with:

...
[  5%] Building CXX object 
src/CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankConverterAlgorithm.cpp.o
cd /build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/src && /usr/bin/c++   
-I/build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/include 
-I/build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/ include/None 
-I/build/gatb-core-1.3.0+dfsg/gatb-core/src 
-I/build/gatb-core-1.3.0+dfsg/gatb-core/thirdparty  -g -O2 
-fdebug-prefix-map=/build/gatb-core-1.3.0+dfsg=. -fstack-protector-  strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -msse2 
-msse4.2 -mpopcnt   -std=c++11 -O3 -DNDEBUG -Wall -Wno-unused-function 
-Wno-format -Wno-unknown-pragmas -Wno- invalid-offsetof -o 
CMakeFiles/gatbcore-static.dir/gatb/bank/impl/Bank.cpp.o -c 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/Bank.cpp
cd /build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/src && /usr/bin/c++   
-I/build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/include 
-I/build/gatb-core-1.3.0+dfsg/obj-x86_64-linux-gnu/ include/None 
-I/build/gatb-core-1.3.0+dfsg/gatb-core/src 
-I/build/gatb-core-1.3.0+dfsg/gatb-core/thirdparty  -g -O2 
-fdebug-prefix-map=/build/gatb-core-1.3.0+dfsg=. -fstack-protector-  strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -msse2 
-msse4.2 -mpopcnt   -std=c++11 -O3 -DNDEBUG -Wall -Wno-unused-function 
-Wno-format -Wno-unknown-pragmas -Wno- invalid-offsetof -o 
CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankConverterAlgorithm.cpp.o -c 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/BankConverterAlgorithm.cpp
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
cc1plus: error: -Wformat-security ignored without -Wformat 
[-Werror=format-security]
In file included from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/tools/math/Integer.hpp:29:0,
 from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/tools/misc/impl/Algorithm.hpp:37,
 from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/BankConverterAlgorithm.hpp:31,
 from 
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/bank/impl/BankConverterAlgorithm.cpp:20:
/build/gatb-core-1.3.0+dfsg/gatb-core/src/gatb/tools/math/LargeInt.hpp:38:10: 
fatal error: hdf5/hdf5.h: No such file or directory
 #include 
  ^
cc1plus: some warnings being treated as errors
compilation terminated.
src/CMakeFiles/gatbcore-static.dir/build.make:137: recipe for target 
'src/CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankConverterAlgorithm.cpp.o'
 failed
make[3]: *** 
[src/CMakeFiles/gatbcore-static.dir/gatb/bank/impl/BankConverterAlgorithm.cpp.o]
 Error 1
...


Any help to use Debian packaged hdf5 would be really appreciated.

Kind regards

Andreas.


[1] https://anonscm.debian.org/git/debian-med/gatb-core.git

-- 
http://fam-tille.de



Re: C++ help needed for centrifuge

2017-11-26 Thread Andreas Tille
Hi,

On Sat, Nov 25, 2017 at 01:39:03PM -0800, Walter Landry wrote:
> > In file included from centrifuge_build.cpp:27:0:
> > bt2_idx.h: In static member function 'static std::pair > Ebwt*> Ebwt::fromStrings(const 
> > EList&, bool, int, int, bool, 
> > int32_t, int32_t, int32_t, const string&, bool, index_t, index_t, index_t, 
> > int, uint32_t, bool, bool, bool)':
> > bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is 
> > deprecated [-Wdeprecated-declarations]
> 
> This is only a warning, so you can ignore it.  If you are feeling
> ambitious, the recommended fix is to replace all auto_ptr's with
> unique_ptr's and copies with moves().

I've applied this in

   
https://anonscm.debian.org/cgit/debian-med/centrifuge.git/tree/debian/patches/fix_auto_ptr_usage_in_gcc-7.patch

> Apparently, clang-modernize can
> do this automatically.

In what package can I find clang-modernize (apt-file search did not find
anything - but I'm currently not on my development machine).

Unfortunately I've hit another issue:

...
classifier.h:428:54: error: the value of 'rank' is not usable in a constant 
expression
 while((uint8_t)_hitMap[i].rank < rank) {
  ^~~~
classifier.h:424:21: note: 'uint8_t rank' is not const
 uint8_t rank = 0;
 ^~~~
...

I tried my luck with some type castings but failed. :-(

Kind regards

  Andreas.

-- 
http://fam-tille.de



C++ help needed for centrifuge

2017-11-25 Thread Andreas Tille
Hi,

I started packaging centrifuge[1] and hit a build error which
is most probably caused by gcc-7 incompatibility:

...
In file included from centrifuge_build.cpp:27:0:
bt2_idx.h: In static member function 'static std::pair Ebwt::fromStrings(const 
EList&, bool, int, int, bool, int32_t, 
int32_t, int32_t, const string&, bool, index_t, index_t, index_t, int, 
uint32_t, bool, bool, bool)':
bt2_idx.h:1053:3: warning: 'template class std::auto_ptr' is deprecated 
[-Wdeprecated-declarations]
   auto_ptr ss(new stringstream());
   ^~~~
In file included from /usr/include/c++/7/memory:80:0,
 from bt2_idx.h:28,
 from centrifuge_build.cpp:27:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template class auto_ptr;
^~~~
In file included from centrifuge_build.cpp:27:0:
bt2_idx.h:1057:3: warning: 'template class std::auto_ptr' is deprecated 
[-Wdeprecated-declarations]
   auto_ptr fb(new FileBuf(ss.get()));
   ^~~~
In file included from /usr/include/c++/7/memory:80:0,
 from bt2_idx.h:28,
 from centrifuge_build.cpp:27:
/usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
   template class auto_ptr;
...


Unfortunately I have no idea about C++.  Any idea how to fix this?

Kind regards

  Andreas.


[1] https://anonscm.debian.org/git/debian-med/centrifuge.git

-- 
http://fam-tille.de



Re: Trying to get rid of code copy of jsoncpp in seqtools

2017-10-25 Thread Andreas Tille
Hi Gert,

On Wed, Oct 25, 2017 at 05:47:01PM +0200, Gert Wollny wrote:
> This looks like 
> 
> #include  
> 
> was missing in that file (fix pushed). 

Thanks.
 
> In addition the  include is not found. For that a 
> "pkg-config jsoncpp" and the according flag setting should be added.
> 
> If you don't beat bme to it I'll look into it tomorrow. 

I admit I manually injected the -I option but there are probably
some missings.  I'll happily leave it for you since I'm a bit
occupied by other (mainly real life) stuff.

Thanks a lot

 Andreas.

-- 
http://fam-tille.de



Trying to get rid of code copy of jsoncpp in seqtools

2017-10-25 Thread Andreas Tille
Hi,

I try to package seqtools[1] which originally contained a code copy of
jsoncpp which I removed.  Unfortunately the build fails with the Debian
packaged jsoncpp and I'm lacking the necessary C++ knowledge to get this
fixed.  Does anybody have an idea how to fix


...
gbtoolsTrackhub.cpp: In function 'Json::Value 
{anonymous}::processRequestResult(const string&, long int, Json::Reader, 
std::__cxx11::string&)':
gbtoolsTrackhub.cpp:174:16: error: aggregate 'std::stringstream err_ss' has 
incomplete type and cannot be defined
   stringstream err_ss;
^~
gbtoolsTrackhub.cpp: In member function 'bool 
gbtools::trackhub::Registry::getSearchPage(std::stringstream&, int, 
std::__cxx11::list&, std::__cxx11::string&)':
gbtoolsTrackhub.cpp:655:16: error: aggregate 'std::stringstream url_ss' has 
incomplete type and cannot be defined
   stringstream url_ss;
^~
gbtoolsTrackhub.cpp:658:46: error: invalid use of incomplete type 
'std::stringstream {aka class std::__cxx11::basic_stringstream}'
   Json::Value js = postRequest(url_ss.str(), payload_ss.str(), false, err_msg);
  ^~
In file included from /usr/include/c++/7/ios:38:0,
 from /usr/include/c++/7/ostream:38,
 from /usr/include/c++/7/iostream:39,
 from gbtoolsTrackhub.cpp:31:
/usr/include/c++/7/iosfwd:108:11: note: declaration of 'std::stringstream {aka 
class std::__cxx11::basic_stringstream}'
 class basic_stringstream;
   ^~
gbtoolsTrackhub.cpp:658:46: error: invalid use of incomplete type 
'std::stringstream {aka class std::__cxx11::basic_stringstream}'
   Json::Value js = postRequest(url_ss.str(), payload_ss.str(), false, err_msg);
  ^~
In file included from /usr/include/c++/7/ios:38:0,
 from /usr/include/c++/7/ostream:38,
 from /usr/include/c++/7/iostream:39,
 from gbtoolsTrackhub.cpp:31:
/usr/include/c++/7/iosfwd:108:11: note: declaration of 'std::stringstream {aka 
class std::__cxx11::basic_stringstream}'
 class basic_stringstream;
   ^~
gbtoolsTrackhub.cpp: In member function 
'std::__cxx11::list 
gbtools::trackhub::Registry::search(const string&, const string&, const 
string&, const string&, std::__cxx11::string&)':
gbtoolsTrackhub.cpp:708:16: error: aggregate 'std::stringstream payload_ss' has 
incomplete type and cannot be defined
   stringstream payload_ss;
^~
gbtoolsTrackhub.cpp: In member function 'gbtools::trackhub::TrackDb 
gbtools::trackhub::Registry::searchTrackDb(const string&, 
std::__cxx11::string&)':
gbtoolsTrackhub.cpp:731:20: error: aggregate 'std::stringstream query_ss' has 
incomplete type and cannot be defined
   stringstream query_ss;
^~~~
gbtoolsTrackhub.cpp: In member function 
'std::__cxx11::list 
gbtools::trackhub::Registry::retrieveHub(const string&, std::__cxx11::string&)':
gbtoolsTrackhub.cpp:873:16: error: aggregate 'std::stringstream query_ss' has 
incomplete type and cannot be defined
   stringstream query_ss;
^~~~
gbtoolsTrackhub.cpp:893:24: error: aggregate 'std::stringstream ss' has 
incomplete type and cannot be defined
   stringstream ss;
^~
gbtoolsTrackhub.cpp: In member function 'Json::Value 
gbtools::trackhub::Registry::retrieveTrackDb(const string&, 
std::__cxx11::string&)':
gbtoolsTrackhub.cpp:932:16: error: aggregate 'std::stringstream query_ss' has 
incomplete type and cannot be defined
   stringstream query_ss;
^~~~
...


Any hint is welcome.

Kind regards

Andreas.


[1] https://anonscm.debian.org/git/debian-med/seqtools.git

-- 
http://fam-tille.de



Re: C++ help needed (Was: Help with cmake / Qt5 migration needed)

2017-10-21 Thread Andreas Tille
Hi Juhani,

thanks a lot for your help.

On Fri, Oct 20, 2017 at 08:41:35PM +0300, Juhani Numminen wrote:
> 
> I think that's the build system sorted, even though the compilation still
> fails. Now you probably need to add some includes.

I was able to add the said includes but somehow this project is balky.
Now I get: 


...
cd 
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads
 && /usr/bin/c++  -DHAVE_PTHREAD_H -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG
In file included from /usr/include/CImg.h:337:0,
 from 
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/../../../src/qtbeads/../images/imageCode.h:7,
 from 
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/../../../src/qtbeads/../images/imageIntensity.h:7,
 from 
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/../../../src/qtbeads/properties.h:13,
 from 
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/../../../src/qtbeads/main_window.h:17,
 from 
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/moc_main_window.cpp:9:
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/moc_main_window.cpp:106:33:
 error: expected unqualified-id before ‘int’
 QMetaType::Void, QMetaType::Bool,   10,
 ^
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/moc_main_window.cpp:106:33:
 error: expected ‘}’ before ‘int’
/home/andreas/debian-maintain/alioth/debian-med_git/build-area/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads/moc_main_window.cpp:118:1:
 error: expected declaration before ‘}’ token
 };
 ^
src/qtbeads/CMakeFiles/qtbeads.dir/build.make:793: die Regel für Ziel 
„src/qtbeads/CMakeFiles/qtbeads.dir/moc_main_window.cpp.o“ scheiterte
...


somehow the file obj-x86_64-linux-gnu/src/qtbeads/moc_main_window.cpp is
autogenerated and I have no idea where to fix it.  The suspicious line 106
looks like this (I added the line numbering to the context):

 68 static const uint qt_meta_data_MainWindow[] = {
 69 
 70  // content:
 717,   // revision
 720,   // classname
...
 99  // slots: parameters
100 QMetaType::Void,
101 QMetaType::Void,
102 QMetaType::Void,
103 QMetaType::Void,
104 QMetaType::Void,
105 QMetaType::Void, 0x8000 | 7,8,
106 QMetaType::Void, QMetaType::Bool,   10,
107 QMetaType::Void,
108 QMetaType::Void,
109 QMetaType::Void,
110 QMetaType::Void,
111 QMetaType::Void,
112 QMetaType::Void,
113 QMetaType::Void, 0x8000 | 18,   19,
114 QMetaType::Void, 0x8000 | 18,   19,
115 QMetaType::Void, 0x8000 | 18,   19,
116 
1170// eod
118 };


Any hint how to fix this?

Kind regards

  Andreas.

-- 
http://fam-tille.de



Re: C++ help needed (Was: Help with cmake / Qt5 migration needed)

2017-10-20 Thread Andreas Tille
Hi Juhani,

On Fri, Oct 20, 2017 at 06:14:02PM +0300, Juhani Numminen wrote:
> > I think I fixed this by removing the code copy of CImg.h and using the
> > Debian packaged version instead.  But the QDebug issue came back and
> > may be I need another trick to tweak src/qtbeads/CMakeLists.txt that
> > the -I directive is inserted properly:
> 
> Didn't test this, but it seems you have missed this required change in
> src/qtbeads/CMakeLists.txt:
> 
> -TARGET_LINK_LIBRARIES( qtbeads ${QT_LIBRARIES} ...
> +TARGET_LINK_LIBRARIES( qtbeads Qt::Widgets ...
> 
> I can't see that line in the patch at
> > [1] https://anonscm.debian.org/git/debian-med/beads.git

Its in line 86 now but does not help.

Kind regards

   Andreas. 

-- 
http://fam-tille.de



C++ help needed (Was: Help with cmake / Qt5 migration needed)

2017-10-20 Thread Andreas Tille
Hi again,

On Fri, Oct 20, 2017 at 11:55:22AM +0200, Wout B wrote:
> It looks like the initial #include  was actually correct and that
> it indeed doesn't find it somehow. Manually adding Qt5::Core and
> Qt5::Widgets to target_link_libraries seems to work though.

I can confirm that this helps - thanks a lot!

> Then there's
> still some error (declaration of 'float t' shadows template parameter), but
> I don't know how to fix that one.

I think I fixed this by removing the code copy of CImg.h and using the
Debian packaged version instead.  But the QDebug issue came back and
may be I need another trick to tweak src/qtbeads/CMakeLists.txt that
the -I directive is inserted properly:

...
cd /build/beads-1.1.13+dfsg/obj-x86_64-linux-gnu/src/qtbeads && /usr/bin/c++  
-DHAVE_PTHREAD_H -DQT_NO_DEBUG_OUTPUT 
-I/build/beads-1.1.13+dfsg/src/X11_INCLUDE_DIR -I/build/beads-1.1.13+dfsg
In file included from 
/build/beads-1.1.13+dfsg/src/images/imageIntensity.cpp:1:0:
/build/beads-1.1.13+dfsg/src/images/imageIntensity.h:4:10: fatal error: QDebug: 
No such file or directory
 #include 
  ^~~~
compilation terminated.
src/qtbeads/CMakeFiles/qtbeads.dir/build.make:145: recipe for target 
'src/qtbeads/CMakeFiles/qtbeads.dir/__/images/imageIntensity.cpp.o' failed
make[3]: *** 
[src/qtbeads/CMakeFiles/qtbeads.dir/__/images/imageIntensity.cpp.o] Error 1
...

I have the feeling that this might be the last hint I need. ;-)

Thanks for all your help

Andreas.


[1] https://anonscm.debian.org/git/debian-med/beads.git

-- 
http://fam-tille.de



Re: Help with cmake / Qt5 migration needed

2017-10-20 Thread Andreas Tille
Hi again,

On Fri, Oct 20, 2017 at 10:30:08AM +0200, Wout B wrote:
> Shouldn't it be #include ? I may be wrong though.

I replaced all instances of '#include ' by
'#include ' and the error now occures in some other
file (not sure whether this is by chance due to parallel build):

cd /build/beads-1.1.13/obj-x86_64-linux-gnu/src/qtbeads && /usr/bin/c++  
-DHAVE_PTHREAD_H -DQT_NO_DEBUG_OUTPUT -I/build/beads-1.1.13/src/X11_INCLUDE_DIR 
-I/build/beads-1.1.13/obj-x86_64-linux-gnu  -g -O2 
-fdebug-prefix-map=/build/beads-1.1.13=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -O3 -DNDEBUG   -Wall -o 
CMakeFiles/qtbeads.dir/__/images/imageIntensity.cpp.o -c 
/build/beads-1.1.13/src/images/imageIntensity.cpp
In file included from /build/beads-1.1.13/src/images/imageIntensity.cpp:1:0:
/build/beads-1.1.13/src/images/imageIntensity.h:4:10: fatal error: 
QtCore/qdebug.h: No such file or directory
 #include 
  ^
compilation terminated.


I verified that my chroot has

# find /usr/include -name qdebug.h
/usr/include/x86_64-linux-gnu/qt5/QtCore/qdebug.h


but I'm somehow missing some proper -I option to tell gcc where to seek
for the qt5 includes.  I'm afraid that the cmake configuration was not
fully successful.  Any further hints?

Kind regards

  Andreas.

 
> Op 19 okt. 2017 10:41 p.m. schreef "Andreas Tille" <andr...@an3as.eu>:
> 
> On Thu, Oct 19, 2017 at 07:18:45PM +0200, Wout B wrote:
> > Have you added the LinguistTools component too? I think it depends on
> that.
> 
> Ahhh, another step forward and I fixed some more in [1].
> 
> Now the configuration seems to be finalised but I get:
> 
> ...
> cd /build/beads-1.1.13/obj-x86_64-linux-gnu/src && /usr/bin/c++
> -DHAVE_PTHREAD_H -DQT_NO_DEBUG_OUTPUT
> -I/build/beads-1.1.13/src/X11_INCLUDE_DIR
> -g -O2 -fdebug-prefix-map=/build/beads-1.1.
> In file included from /build/beads-1.1.13/src/beads.cpp:1:0:
> /build/beads-1.1.13/src/beads.h:19:10: fatal error: QDebug: No such file or
> directory
>  #include 
>   ^~~~
> compilation terminated.
> src/CMakeFiles/beads.dir/build.make:65: recipe for target
> 'src/CMakeFiles/beads.dir/beads.cpp.o' failed
> make[3]: *** [src/CMakeFiles/beads.dir/beads.cpp.o] Error 1
> ...
> 
> 
> What next?
> 
> Thanks for all the helpful hints in any case
> 
>  Andreas.
> 
> 
> > > > [1] https://anonscm.debian.org/git/debian-med/beads.git
> > > No repositories found
> >
> > Strange.  I was able to create a fresh clone from this URL.
> >
> > Kind regards
> >
> >   Andreas.
> >
> >
> > --
> > http://fam-tille.de
> 
> --
> http://fam-tille.de

-- 
http://fam-tille.de



  1   2   3   4   5   6   7   8   9   >