Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz

[Andreas Tille]

Hi,

this version was a source only upload.  If I build on my local machine
emboss-data does not contain any dir /usr/share/man.  However, the
binary package on the Debian mirror contains /usr/share/man/man1 with
has two symlinks which are identical to those in the emboss package.

I can not reproduce this and I'm wondering why the source only upload
creates files that are not created on a local build.

Kind regards

   Andreas.

On Thu, Aug 11, 2016 at 02:18:00PM +0200, Andreas Beckmann wrote:
> Package: emboss,emboss-data
> Version: 6.6.0+dfsg-4
> Severity: serious
> User: trei...@debian.org
> Usertags: edos-file-overwrite
> 
> Hi,
> 
> automatic installation tests of packages that share a file and at the
> same time do not conflict by their package dependency relationships has
> detected the following problem:
> 
>   Selecting previously unselected package emboss.
>   (Reading database ... 
> (Reading database ... 8365 files and directories currently installed.)
>   Preparing to unpack .../emboss_6.6.0+dfsg-4_amd64.deb ...
>   Unpacking emboss (6.6.0+dfsg-4) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/emboss_6.6.0+dfsg-4_amd64.deb (--unpack):
>trying to overwrite '/usr/share/man/man1/em_cons.1e.gz', which is also in 
> package emboss-data 6.6.0+dfsg-4
>   Errors were encountered while processing:
>/var/cache/apt/archives/emboss_6.6.0+dfsg-4_amd64.deb
> 
> This is a serious bug as it makes installation fail, and violates
> sections 7.6.1 and 10.1 of the policy. An optimal solution would
> consist in only one of the packages installing that file, and renaming
> or removing the file in the other package. Depending on the
> circumstances you might also consider Replace relations or file
> diversions. If the conflicting situation cannot be resolved then, as a
> last resort, the two packages have to declare a mutual
> Conflict. Please take into account that Replaces, Conflicts and
> diversions should only be used when packages provide different
> implementations for the same functionality.
> 
> 
> This bug is assigned to both packages. If you, the maintainers of
> the two packages in question, have agreed on which of the packages will
> resolve the problem please reassign the bug to that package. You may
> also register in the BTS that the other package is affected by the bug.
> 
> Cheers,
> 
> Andreas
> 
> PS: for more information about the detection of file overwrite errors
> of this kind see https://qa.debian.org/dose/file-overwrites.html


> ___
> 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: Bug#833288: would FTBFS now with cython 0.24.1 MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'

[Andreas Tille]

Hi,

I can confirm this bug.

I've checked MACS2/IO/PeakIO.pyx and I think the typing of the function
call should be fine - so probably the problem is somewhere else - but
where?

Any help would be welcome

  Andreas.

On Tue, Aug 02, 2016 at 10:37:50AM -0400, Yaroslav Halchenko wrote:
> Package: macs
> Version: 2.1.1.20160309-1
> Severity: serious
> Tags: upstream
> Justification: fails to build from source (but built successfully in the past)
> 
> I have just uploaded cython 0.24.1 into sid and while testing reverse build
> depends found that macs fails to build.  Here is the log extract:
> 
> building 'MACS2.Signal' extension
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/lib/python2.7/dist-packages/numpy/core/include 
> -I/usr/include/python2.7 -c MACS2/Signal.c -o 
> build/temp.linux-x86_64-2.7/MACS2/Signal.o -w -O3 -ffast-math
> x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
> -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g 
> -fstack-protector-strong -Wformat -Werror=format-security -Wl,-z,relro 
> -Wl,-z,now -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -Wdate-time -D_FORTIFY_SOURCE=2 build/temp.linux-x86_64-2.7/MACS2/Signal.o -o 
> /build/macs-2.1.1.20160309/.pybuild/pythonX.Y_2.7/build/MACS2/Signal.so
> cythoning MACS2/IO/PeakIO.pyx to MACS2/IO/PeakIO.c
> 
> Error compiling Cython file:
> 
> ...
> pileup = float(fields[5])
> pscore = float(fields[6])
> fc = float(fields[7])
> qscore = float(fields[8])
> peakname = rstrip(fields[9])
> add(chrom, start, end, summit, qscore, pileup, pscore, fc, qscore,
> ^
> 
> 
> MACS2/IO/PeakIO.pyx:632:49: Cannot assign type 'float' to 'int'
> building 'MACS2.IO.PeakIO' extension
> x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall 
> -Wstrict-prototypes -fno-strict-aliasing -g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python2.7 -c MACS2/IO/PeakIO.c -o 
> build/temp.linux-x86_64-2.7/MACS2/IO/PeakIO.o -w -O3 -ffast-math
> MACS2/IO/PeakIO.c:1:2: error: #error Do not use this file, it is the result 
> of a failed Cython compilation.
>  #error Do not use this file, it is the result of a failed Cython compilation.
>   ^
> error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
> E: pybuild pybuild:274: build: plugin distutils failed with: exit code=1: 
> /usr/bin/python setup.py build 
> dh_auto_build: pybuild --build -i python{version} -p 2.7 returned exit code 13
> debian/rules:16: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 25
> make[1]: Leaving directory '/build/macs-2.1.1.20160309'
> debian/rules:13: recipe for target 'build' failed
> make: *** [build] Error 2
> 
> 
> cheers!
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (600, 'unstable'), (300, 'experimental'), 
> (100, 'unstable-debug')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.5.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> ___
> 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: Bug#832299: python-ruffus: FTBFS: sphinx.ext.mathjax: other math package is already loaded

[Andreas Tille]

On Mon, Jul 25, 2016 at 09:50:50PM +0200, Christian Seiler wrote:
> If you really want your package to build _now_ for some
> other reason, you could try to switch the dot format to png instead
> of jpg (I would recommend png instead of jpg anyway for graphviz,
> because jpg is more suitable for photos and not diagrams).

Done since perfectly correct.

Thanks for the hint

  Andreas. 

-- 
http://fam-tille.de

Re: Bug#832299: python-ruffus: FTBFS: sphinx.ext.mathjax: other math package is already loaded

[Andreas Tille]

On Sun, Jul 24, 2016 at 12:43:02AM +0200, Chris Lamb wrote:
>   Running Sphinx v1.4.5
>   making output directory...
>   WARNING: sphinx.ext.pngmath has been deprecated. Please use 
> sphinx.ext.imgmath instead.
>   
>   Extension error:
>   sphinx.ext.mathjax: other math package is already loaded
>   
> ['/home/lamby/temp/cdt.20160723234148.mpT9WCevsF.python-ruffus/python-ruffus-2.6.3+dfsg',
>  '/usr/share/sphinx/scripts/python2', 
> '/home/lamby/temp/cdt.20160723234148.mpT9WCevsF.python-ruffus/python-ruffus-2.6.3+dfsg/debian/python-ruffus/usr/lib/python2.7/dist-packages',
>  
> '/home/lamby/temp/cdt.20160723234148.mpT9WCevsF.python-ruffus/python-ruffus-2.6.3+dfsg/.pybuild/pythonX.Y_2.7/build',
>  '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', 
> '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', 
> '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', 
> '/usr/lib/python2.7/dist-packages']
>   2.6.3 2.6.3
>   Makefile:53: recipe for target 'html' failed
>   make[2]: *** [html] Error 1

I think this is fixed in last commit to Git[1].

However, I'm running into another build issue which is strange since dot
does not seem to support jpg any more:

...
OK
Running test_split_subdivide_checkpointing.py
 Run pipeline normally...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate more files...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate even more files...
 Check that running again does nothing. (All up to date).
. Run pipeline normally...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate more files...
 Check that running again does nothing. (All up to date).
 Running again with forced tasks to generate even more files...
 Check that running again does nothing. (All up to date).
.
--
Ran 2 tests in 5.001s

OK
Running test_pipeline_printout_graph.py
EE
==
ERROR: test_newstyle_ruffus (test_pipeline_printout_graph.Test_ruffus)
--
Traceback (most recent call last):
  File "test_pipeline_printout_graph.py", line 181, in test_newstyle_ruffus
no_key_legend = True)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/task.py", line 1558, in 
printout_graph
pipeline_printout_graph(*unnamed_args, **named_args)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/task.py", line 4659, in 
pipeline_printout_graph
signal_callback=is_node_up_to_date)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/graph.py", line 1175, in 
graph_printout
raise subprocess.CalledProcessError(retcode, cmd + "\n" + 
"\n".join([str(result_str), str(error_str)]))
CalledProcessError: Command 'dot -Gsize='(11,8)' -Gdpi='120' -Tjpg < 
/tmp/tmpW40AHi.dot

Format: "jpg" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps fig 
gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg svgz tk 
vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
' returned non-zero exit status 1

==
ERROR: test_ruffus (test_pipeline_printout_graph.Test_ruffus)
--
Traceback (most recent call last):
  File "test_pipeline_printout_graph.py", line 150, in test_ruffus
no_key_legend = True)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/task.py", line 4659, in 
pipeline_printout_graph
signal_callback=is_node_up_to_date)
  File "/build/python-ruffus-2.6.3+dfsg/ruffus/graph.py", line 1175, in 
graph_printout
raise subprocess.CalledProcessError(retcode, cmd + "\n" + 
"\n".join([str(result_str), str(error_str)]))
CalledProcessError: Command 'dot -Gsize='(11,8)' -Gdpi='120' -Tjpg < 
/tmp/tmpgacay7.dot

Format: "jpg" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps fig 
gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg svgz tk 
vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
' returned non-zero exit status 1

--
Ran 2 tests in 0.029s

FAILED (errors=2)
 Run pipeline normally...
 Run pipeline normally...


Before I cowardly deactivate these tests I wonder whether there is a
more sensible solution.

Kind regards

 Andreas.

[1] 
https://anonscm.debian.org/git/debian-med/python-ruffus.git/tree/debian/patches/sphinx.ext.pngmath_deprecated.patch

-- 
http://fam-tille.de

Please help upgrading eigensoft

[Andreas Tille]

Hi,

I tried to upgrade eigensoft[1].  The build fails with:

...
cc -Wl,-z,relro  pca.o eigensrc/eigsubs.o eigx.o nicksrc/libnick.a  -lgsl 
-lblas -lgfortran -lrt -lm -o pca
eigx.o: In function `eigx_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:100: undefined reference to `dspev_'
eigx.o: In function `eigxv_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:126: undefined reference to `dspev_'
eigx.o: In function `cdc_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:145: undefined reference to `dpotrf_'
eigx.o: In function `inverse_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:186: undefined reference to `dgetrf_'
/build/eigensoft-6.1.2+dfsg/src/eigx.c:194: undefined reference to `dgetri_'
eigx.o: In function `solve_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:223: undefined reference to `dgetrf_'
/build/eigensoft-6.1.2+dfsg/src/eigx.c:230: undefined reference to `dgetrs_'
eigx.o: In function `geneigsolve_':
/build/eigensoft-6.1.2+dfsg/src/eigx.c:250: undefined reference to `dsygv_'
collect2: error: ld returned 1 exit status
: recipe for target 'pca' failed
make[2]: *** [pca] Error 1
...

That's strange sinde the according functions have prototypes in the very
same c file.  Any idea what might be wrong here?

Kind regards

   Andreas.


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

-- 
http://fam-tille.de

Problems with opencl in pbuilder (Was: Bug#831235: libhmsbeagle: FTBFS: Tests failures)

[Andreas Tille]

Hi,

it seems there is some opencl related problem when building libhmsbeagle
in pbuilder (which worked before)

On Thu, Jul 14, 2016 at 11:58:15AM +0200, Lucas Nussbaum wrote:
> Source: libhmsbeagle
> Version: 2.1.2+20151220-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160714 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> ...

the really relevant part is


make[4]: Entering directory 
'/«BUILDDIR»/libhmsbeagle-2.1.2+20151220/examples/tinytest'
make  tinytest
make[5]: Entering directory 
'/«BUILDDIR»/libhmsbeagle-2.1.2+20151220/examples/tinytest'
g++ -DHAVE_CONFIG_H -I. -I../../libhmsbeagle  -I../.. -I../.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/java-8-openjdk-amd64/include 
-I/usr/lib/jvm/java-8-openjdk-amd64/include/linux  -g -O2 -fstack-protecto
/bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -o 
tinytest tinytest.o ../../libhmsbeagle/libhmsbeagle.la -ldl.
libtool: link: g++ -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z -Wl,relro -o .libs/tinytest tinytest.o  
../../libhmsbeagle/.libs/libhmsbeagle.so -ldl
make[5]: Leaving directory 
'/«BUILDDIR»/libhmsbeagle-2.1.2+20151220/examples/tinytest'
make  check-TESTS
make[5]: Entering directory 
'/«BUILDDIR»/libhmsbeagle-2.1.2+20151220/examples/tinytest'
make[6]: Entering directory 
'/«BUILDDIR»/libhmsbeagle-2.1.2+20151220/examples/tinytest'
FAIL: tinytest
==
   libhmsbeagle 2.1.2: examples/tinytest/test-suite.log
==

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

.. contents:: :depth: 2

FAIL: tinytest
==

Unable to load CPU plugin!
Please check for proper libhmsbeagle installation.
Could not create topdir for cacheFAIL tinytest (exit status: 2)


Testsuite summary for libhmsbeagle 2.1.2

# TOTAL: 1
make[6]: *** [test-suite.log] Error 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See examples/tinytest/test-suite.log
Please report to beagle-...@googlegroups.com


BTW, I'm running the build on a Jessie + Jessie-backports machine and
when the pbuilder environment is createt all xfonts of the build machine
are messed up.  I once reported this to Debian backports in connection
with libreoffice.  I would seek for the exact link but I can't since my
browser became unusable.  It was fixed at this time with libreoffice but
now it re-appears with pbuilder.  I'll report there and keep this bug
report in CC.

Any help would be very much appreciated

  Andreas.

-- 
http://fam-tille.de

Re: Bug#797280: Please help porting cufflinks to latest libboost

[Andreas Tille]

Hi Jakub,

On Tue, Jul 12, 2016 at 01:10:44PM +0200, Jakub Wilk wrote:
> 
> For some reason Eigen thinks that v.colwise().sum() cannot be treated as a
> one-dimensional vector, which smells like a bug in Eigen. Changing the last
> line to
> 
>   m = v.colwise().sum()(0, 0);
> 
> seems to do the trick.

Works.

Thanks a lot

 Andreas.

-- 
http://fam-tille.de

Please help porting cufflinks to latest libboost

[Andreas Tille]

Hi,

in my last commit I tried to build cufflinks[1] against libboost 1.60
but failed.  Since the failure does not seem to related to libboost I
wonder whether somebody might be able to understand and fix this issue:

...
In file included from /usr/include/eigen3/Eigen/Core:297:0,
 from /usr/include/eigen3/Eigen/Dense:1,
 from abundances.h:21,
 from abundances.cpp:16:
/usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h: In instantiation of 
'Eigen::DenseCoeffsBase::CoeffReturnType 
Eigen::DenseCoeffsBase::coeff(Eigen::Index) const [with Derived = 
Eigen
/usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h:181:19:   required from 
'Eigen::DenseCoeffsBase::CoeffReturnType 
Eigen::DenseCoeffsBase::operator()(Eigen::Index) const [with Derived
abundances.cpp:3815:28:   required from here
/usr/include/eigen3/Eigen/src/Core/DenseCoeffsBase.h:141:7: error: 
'THIS_COEFFICIENT_ACCESSOR_TAKING_ONE_ACCESS_IS_ONLY_FOR_EXPRESSIONS_ALLOWING_LINEAR_ACCESS'
 is not a member of 'Eigen::internal::static_assert
   EIGEN_STATIC_ASSERT(internal::evaluator::Flags & 
LinearAccessBit,
   ^
Makefile:1627: recipe for target 'abundances.o' failed
...

Any help would be welcome

 Andreas.

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

-- 
http://fam-tille.de

d-shlibs: What package provides ld64-2-dev on ppc64 (and others) (Was: Next autoconf problem for today libdisorder)

[Andreas Tille]

Hi,

On Tue, Jun 28, 2016 at 06:03:39PM +0200, Christian Seiler wrote:
> > I agree that its not necessary to copy files around.  However, I like
> > d-shlibs to ensure that debian/control is properly designed.
> 
> It does appear to not fully support all architectures though, if
> you look at the buildd results:
> https://buildd.debian.org/status/package.php?p=libdisorder
> 
> It would be great if you could report that as a bug against
> d-shlibs, assuming nobody else has done so yet. (Maybe wait
> until all other platforms are either built or failed, to have
> a complete list.)

As Christian realised d-shlibmove is failing to resolve ld64-2-dev on
ppc64el, ppc64 and s390x and on kfreebsd-amd64 it is seeking for
ld-kfreebsd-x86-64-1-dev.  I would like to fix this by using --override
for the moment and provide a patch to d-shlibs.  However, I have no idea
by what might be the correct replacement in these cases.

Any idea?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Andreas Tille]

Hi Tung,

thanks to the very helpful and detailed response of Christian Seiler
which I would like you to read below in detail since it explains the
patches applied in the Debian packaging I was able to build the latest
iqtree version.  You can find all patches that are applied to iqtree
here:

https://anonscm.debian.org/cgit/debian-med/iqtree.git/tree/debian/patches

Please also note that I have updated the spelling patch with some
spelling mistakes (in code and comments).

Kind regards and thanks for your cooperation

 Andreas.

On Tue, Jun 28, 2016 at 08:09:15PM +0200, Christian Seiler wrote:
> On 06/28/2016 11:01 AM, Andreas Tille wrote:
> > I admit I can not answer the question asked by upstream.  The package in
> > question is iqtree[1] and they said that they have different
> > computational kernels implemented to respect different hardware.
> > Current Git[1] does not even build - may be due to some fine tuning of
> > gcc options needed???
> 
> I've looked at this, and there are a couple of things going on here:
> 
> 0. Debian's build flags by default assume a generic architecture, so
> you don't have to do anything by yourself.
> 
> 1. Upstream's build system supports multiple options for the entirety
> of the code. So you can compile the entire code with the AVX or FMA
> instruction set. You patch that out completely from the CMakeLists.txt
> in sse.patch, but that isn't actually required. (IQTREE_FLAGS would
> have to be explicitly set to enable this.)
> 
> 2. Furthermore, upstream's build system provides SSE and AVX kernels
> for regardless of the build flags of the rest of the code, and they are
> always compiled. (Well, you can disable compilation of the AVX kernel
> if you add "novx" to IQTREE_FLAGS, but there's no reason to.) This
> should work out of the box.
> 
> That said, the code doesn't support non-SSE at all, because it hard-
> codes at least SSE2 intrinsics in a lot of platces (and the one part
> where it hardcodes SSE3, you already have a patch for). The code can
> therefore not be compiled without SSE support enabled, unfortunately,
> even on i386. If you want to support non-SSE at all on i386, upstream
> (or yourself) needs to implement the routines in the vectorclass/
> directory (and possibly others) for non-SSE systems. (The kernel that
> optionally uses AVX also exists in a non-SSE variant, so upstream is
> not completely wrong about that, but there's a lot of _other_ code that
> forces at least SSE2.
> 
> 3. pll/ has a bug that it calls posix_memalign with PLL_BYTE_ALIGNMENT.
> However, according to the manpage, the alignment must be a multiple of
> sizeof(void *) for posix_memalign to work (and a power of 2), but
> PLL_BYTE_ALIGNMENT is 1 if SSE3 is not used. If you explicitly set it
> to 8 (to catch both 32bit and 64bit), posix_memalign will not fail and
> the program won't segfault anymore. (posix_memalign with wrong align
> argument will just return without a possibility to check for an error,
> but also not allocating a buffer, leaving it empty.)
> 
> Note though that if you don't compile with sse3 flags enabled, pll will
> not use SSE code at all (other than that which the compiler generates),
> which is probably slower. But it does work, though. (A grep for __SSE3
> shows though that porting this would be a LOT of work.)
> 
> Irrespective of the SSE-stuff, two things:
> 
> 1. Your debian/rules calls dh_auto_clean/configure/build in
>override_dh_auto_build to build two variants. This can be done in a
>more elegant way, because CMake does support out of tree builds, and
>you can have debhelper use a specific build directory by specifying
>-Bdirname to dh_auto_*.
> 
> 2. You might want to add --parallel to your dh call in debian/rules.
>CMake-based projects tend to support paralle builds, and iqtest is
>no exception to that rule. Would speed up build times quite a bit.
> 
> 3. If you want to test the -omp binary as you do in debian/rules
>currently, you have to pass -redo, otherwise the second call will
>simply fail.
> 
> I've update your sse.patch to include the SSE-related fixes, and have
> updated debian/rules to incorporate the two other things. Attached both
> to this email. The package now builds on amd64 and i386 (and probably
> will build on the kfreebsd and hurd variants thereof, though I haven't
> checked) and the test suite runs. The AVX/FMA checks in CMakeLists.txt
> are now not removed, because debian/rules never sets IQTEST_FLAGS to
> fma or avx. (On amd64 the avx kernel is built with -mavx regardless
> separately by the build system, so that's also OK; and on my Haswell
> system the AVX detection works. On i386 the AVX kernel is never built,
> as per what the upstream bui

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

On Tue, Jun 28, 2016 at 03:42:21PM +0200, Christian Seiler wrote:
> 
> (Btw. you still didn't update debian/control in git. ;-))

Ahhh, thanks for noticing ...
 
> Well, but the reason you get help here is so you can learn from
> it. ;-) And you don't have to be an expert in the autotools (while I
> do know quite a bit, I certainly am not), but if you're packaging
> stuff that uses autotools in Debian (and you're packaging quite a
> lot of packages that fall in that category), it is really helpful to
> have an idea about the basics.
> 
> I would therefore really encourage you to do at least a bit of
> reading on that topic.

I fully agree but there is similarly important documentation I would
need to read as well.
 
> > The manpage is not installed since it has zero bytes.  (I actially
> > had a debian/manpages file written but removed it afterwards.)
> 
> Oh, I didn't check that. Funny that upstream ships it then. In
> that case, I do agree with your decision not to include it. ;-)

:-)

Thanks again

  Andreas.

-- 
http://fam-tille.de

How to specify a generic architecture to GCC (Was: SSE3 issue with iqtree when trying to enable i386)

[Andreas Tille]

Hi,

I admit I can not answer the question asked by upstream.  The package in
question is iqtree[1] and they said that they have different
computational kernels implemented to respect different hardware.
Current Git[1] does not even build - may be due to some fine tuning of
gcc options needed???

Any help is welcome

Andreas.

On Sat, Mar 12, 2016 at 07:33:48PM +0100, Tung Nguyen wrote:
> >
> > That's perfect.  A runtime detection is always the best way to go.  The
> > only problem might be that some architectures do not know SSE3 at build
> > time and the code needs to compile also under this conditions.
> >
> >
> Dear Andreas,
> 
> Is it possible to specify a generic architecture to GCC when you compile
> the code so that all 3 computational kernels  (non-SSE, SSE3, AVX) get
> compiled? Then during runtime IQ-TREE will automatically detect which
> kernel it should use, depending on the architecture. I assume that the
> non-SSE kernel should run fine on most x86 architecture. If this approach
> does not work, then we will provide a flag to exclude the compilation of
> the SSE3 and AVX kernels.


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

-- 
http://fam-tille.de

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 11:57:12PM +0200, Christian Seiler wrote:
> 
> Well, autoconf in and by itself doesn't support testing, automake does,
> which fortunately you're also using.
> 
> I've added a very trivial test from the way I understand how the program
> you're using works, and attached an updated patch to this email. (I've
> also updated the autoconf/automake prerequisites, see my last email.)
> It's actually quite trivial: write a shell script that returns
> successfully (exit code 0) or not. (You can run a C program directly if
> it does return 0 or not depending on the test results, but that doesn't
> apply to ropy directly.) My test applies ropy to the COPYING file
> containing the text of the GPL and checks if the result matches the
> expectations. Feel free to extend/change that to your liking, but as a
> basic functionality check I think that is already useful.

Great.  I applied the patch in Git.
 
> Beware though that if "make check" fails, the package build will also
> fail by default.

Yes.  That's what a test is for. :-)

> (I consider that to be a good thing, just something to
> keep in mind.) I did some test builds on amd64, i386, x32, and arm64,
> and the simple test I created succeeds on all of these platforms.

Thanks for the thorough checking!
 
> Well, in general I would consider pkg-config to be good thing for
> libraries, but I'm not sure here, especially if the circle of consumers
> is a very small circle and they don't appear to be using pkg-config so
> far anyway, so it's probably a waste of time here.

Good to know that you have the same feeling as I had.
 
> In your package, that's already the case, so you can just add the header
> to debian/control.

A, well, yes - I simply forgot this.  In my initial question I assumed
something more on the Build-System would be needed.

> Another thing I noticed: your configure.ac checks for a C++
> compiler, which is unnecessary here, as this is a pure C library.
> You can simply drop the C++ checks and save computing resources.
> I've done that in the updated autoconf.patch I've attached (that
> also contains the unit test).

Cool, thanks.
 
> Anyway: in case you want to know more about autoconf/automake etc.
> I would really recommend  in
> addition to the official documentation of that ecosystem ([1],
> [2], [3], [4]).

I know I should know more about these tools but I need to quite rarely
and the good thing on Debian Mentors is that you (obviously) get
brilliant help if needed.  While beeing really great this on the other
hand decreases the motivation to learn everything be heart. ;-)

Thanks a lot for your very verbose and helpful hints

  Andreas.

-- 
http://fam-tille.de

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 10:41:28PM +0200, Christian Seiler wrote:
> On 06/27/2016 07:49 PM, Christian Seiler wrote:
> > Other comments regarding the package:
> 
> Oh btw. I just noticed that you don't install the manpage for
> the library function in the -dev package (because d-shlibmove
> doesn't care about manpages, and you don't have an .install
> file for that package). Since upstream includes the manpage,
> I would recommend also shipping it.

The manpage is not installed since it has zero bytes.  (I actially
had a debian/manpages file written but removed it afterwards.)

Thanks for the hint anyway

 Andreas.

-- 
http://fam-tille.de

Re: Next autoconf problem for today libdisorder

[Andreas Tille]

Hi Christian,

On Mon, Jun 27, 2016 at 07:49:53PM +0200, Christian Seiler wrote:
> However, I think you're making your life far more complicated than it
> needs to be:

Yep - as I said my knowledge here is limited.
 
> I've attached an updated version of your autoconf patch that does just
> his.

Thanks a lot.  That was very helpful.
 
> Other comments regarding the package:
> 
>  - if you use autoconf/automake, you don't need to use d-moveshlibs
>for multiarch, dh_auto_configure / dh_auto_build / dh_auto_install
>will do all the heavy lifting for you (just create proper .install
>files for the packages, and use /usr/lib/*/filename to select the
>proper file names) That's a matter of taste, of course.

I agree that its not necessary to copy files around.  However, I like
d-shlibs to ensure that debian/control is properly designed.
 
>  - you build tool/ropy, but you never use it? Neither in the test suite
>(dh_auto_test doesn't do anything) nor do you package that - why?

Since I wanted to get things working somehow first.  I've now reated a
libdisorder-tools package (will write a ropy.1 as well). If you could
help with a sensible test suite - I have no idea how to get this working
with autoconf.
 
>  - you don't provide a symbols file for your library. Not required,
>but it's good practice to provide one (I've attached one based on
>your current package, save it as debian/libdisorder0.symbols, dh
>will take care of the rest)

Thanks a lot for this as well.
 
>  - why hardening only +bindnow? The package builds with +all in the
>hardening options just fine?

Cut-n-pasto.  Fixed now, thanks for the hint.
 
>  - Have you actually tested this with automake 1.6 and autoconf
>2.57? (they are ancient!) If not I'd recommend using autoconf 2.64
>and automake 1.11 as the minimal required versions for each (just
>to be on the safe side, even though it won't have any effect on
>Debian's package build)

Fixed.
 
>  - you could consider installing a pkg-config file for the library,
>as it requires linking against -lm. While this works automatically
>with the shared library, this is not the case for the static
>library, where you explicitly have to add -lm after libdisorder.a
>when linking against it

I have no specific reason not to use pkg-config.  If you recommend this
I'd happily apply a patch.

>  - I would recommend maybe sending the build system changes upstream,
>so that other people can also profit from this?

Sure.  Once it works I'll propose it upstream.
 
>  - you install everything into the proper multiarch locations, but
>libdisorder0 and libdisorder-dev are not Multi-Arch: same, even
>though they easily could be

How?
 
>  - you don't build the test program (although it doesn't serve as
>a unit test, because it will never fail unless /dev/urandom is
>not accessible, so there's no actual check whether the routine
>works as expected or not - so I don't think that's a problem
>really, just wanted to make you aware of it)

Well, upstream provides a test and I would like to run it - if I would
know how to do this.  Any patch is welcome.
 
>  - this is more of an upstream issue (i.e. not related to your
>packaging): the library uses global state and is non-reentrant;
>which is actually not a great thing for a shared library to be

I guess upstream is MIA since a long time.
 
>Unfortunately, improving that would require breaking both API
>and ABI, so I'm not suggesting to you to do so, but I would
>maybe talk with upstream about improving that in the future.

I can forward this but my guess is that upstream will not change
anything.  It would also spoil my primary goal for the libraries that
are using libdisorder.

Thanks a lot for your great help

 Andreas.
 
> [1] https://www.gnu.org/software/automake/manual/libtool.html#LT_005fINIT

> Author: Andreas Tille <ti...@debian.org>
> Last-Update: Wed, 22 Jun 2016 16:27:46 +0200
> Description: Add autoconf stuff to enable simple library creation
> 
> --- /dev/null
> +++ b/Makefile.am
> @@ -0,0 +1,12 @@
> +lib_LTLIBRARIES  = libdisorder.la
> +libdisorder_la_SOURCES = src/disorder.c
> +libdisorder_la_LDFLAGS = -version-info @LIB_VERSION@
> +libdisorder_la_CPPFLAGS = -Iinclude
> +libdisorder_la_LIBADD = -lm
> +
> +bin_PROGRAMS = ropy
> +ropy_SOURCES = tool/ropy.c
> +ropy_LDADD = libdisorder.la
> +
> +include_HEADERS = include/disorder.h
> +man_MANS = man/shannon_H.3
> --- /dev/null
> +++ b/configure.ac
> @@ -0,0 +1,62 @@
> +#   -*- Autoconf -*-
> +# Process this file with autoconf to produce a configure script.

Next autoconf problem for today libdisorder

[Andreas Tille]

Hi folks,

ftpmaster spotted in two of my packages a code copy of libdisorder[1]
which better should be packaged separately.  Since I'd like to create
dynamic and static library (upstream Makefile only creates static) I
intended to add autoconf - but today I just proved that my skills are
quite limited here.

I wonder whether some kind soul could check my quilt patches in Git[2].
Currently it ends up in

...
make[1]: Entering directory '/build/libdisorder-0.0.2'
make  all-am
make[2]: Entering directory '/build/libdisorder-0.0.2'
make[2]: *** No rule to make target 'libdisorder.c', needed by 
'libdisorder_la-libdisorder.lo'.  Stop.
...


I probably failed in following upstream logich to distribute one file
per directory - but I did not wanted to change upstream directory
layout.

Thanks a lot for any help

  Andreas.

[1] https://github.com/locasto/libdisorder
[2] https://anonscm.debian.org/git/debian-med/libdisorder.git

-- 
http://fam-tille.de

Re: Help needed for autoreconf hmmer

[Andreas Tille]

Hi Jakub,

On Mon, Jun 27, 2016 at 03:35:04PM +0200, Jakub Wilk wrote:
> AUTOHEADER=true dh_autoreconf

Thanks - works perfectly

 Andreas.

-- 
http://fam-tille.de

Re: Help needed for autoreconf hmmer

[Andreas Tille]

Hi Neutron,

I tried

$ git diff
diff --git a/debian/patches/use_debian_packaged_libdivsufsort.patch 
b/debian/patches/use_debian_packaged_libdivsufsort.patch
index 99ed610..fb3b340 100644
--- a/debian/patches/use_debian_packaged_libdivsufsort.patch
+++ b/debian/patches/use_debian_packaged_libdivsufsort.patch
@@ -20,6 +20,15 @@ Description: Use Debian packaged libdivsufsort
  
  AC_SUBST(EASEL_DATE)
  AC_SUBST(EASEL_COPYRIGHT)
+@@ -105,7 +103,7 @@ AC_DEFINE_UNQUOTED(HMMER_VERSION,   "$HM
+ AC_DEFINE_UNQUOTED(HMMER_URL,   "$HMMER_URL")
+ 
+ AC_DEFINE_UNQUOTED(EASEL_DATE,  "$EASEL_DATE")
+-AC_DEFINE_UNQUOTED(EASEL_COPYRIGHT, "$EASEL_COPYRIGHT")
++AC_DEFINE_UNQUOTED(EASEL_COPYRIGHT, "$EASEL_COPYRIGHT", [Define 
EASEL_COPYRIGHT])
+ AC_DEFINE_UNQUOTED(EASEL_LICENSE,   "$EASEL_LICENSE")
+ AC_DEFINE_UNQUOTED(EASEL_VERSION,   "$EASEL_VERSION")
+ 
 @@ -669,14 +667,12 @@ AC_CONFIG_FILES([profmark/Makefile])
  AC_CONFIG_FILES([src/impl_${impl_choice}/Makefile])
  AC_CONFIG_HEADERS([src/p7_config.h])


but this did not changed anything.

Thanks for your attempt to help

   Andreas.

On Mon, Jun 27, 2016 at 07:43:37PM +0700, Neutron Soutmun wrote:
> s/AC_DEFINE/AC_DEFINE_UNQUOTED/g
> 
> On Mon, Jun 27, 2016 at 7:33 PM, Neutron Soutmun <neo.neut...@gmail.com> 
> wrote:
> > Sorry for non-sense example
> >
> > It should be,
> >
> > AC_DEFINE([EASEL_COPYRIGHT], "$EASEL_COPYRIGHT", [Define EASEL_COPYRIGHT])
> >
> > Cheers,
> > Neutron Soutmun
> >
> > On Mon, Jun 27, 2016 at 7:29 PM, Neutron Soutmun <neo.neut...@gmail.com> 
> > wrote:
> >> Hi,
> >>
> >> On Mon, Jun 27, 2016 at 5:41 PM, Andreas Tille <andr...@an3as.eu> wrote:
> >>
> >>>dh_autoreconf
> >>> autoheader: warning: missing template: EASEL_COPYRIGHT
> >>> autoheader: Use AC_DEFINE([EASEL_COPYRIGHT], [], [Description])
> >>
> >> This is the clue. I do the quick review and found that the lines
> >> AC_DEFINE() and AC_DEFINE_UNQUOTED() that warning with missing
> >> template are missing the second and the third arguments, it should be
> >> something like below
> >>
> >> AC_DEFINE([EASEL_COPYRIGHT], [1], [Define EASEL_COPYRIGHT])
> >>
> >> See: 
> >> https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Defining-Symbols.html
> >>
> >> Cheers,
> >> Neutron Soutmun
> 

-- 
http://fam-tille.de

Help needed for autoreconf hmmer

[Andreas Tille]

Hi,

since ftpmaster rejected hmmer[1] due to a missing license statement for
libdivsufsort code I verified that this library is packaged separately
and tried to get rid of this code duplication at all.  Thus I needed to
autoreconfigure but failed:


...
   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: eslDEBUGLEVEL
autoheader: warning: missing template: eslLIBRARY
autoheader: warning: missing template: p7_DEBUGGING
autoheader: warning: missing template: p7_IMPL_DUMMY
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
debian/rules:12: recipe for target 'build' failed
make: *** [build] Error 2
...


I admit my autoconf knowledge is a bit rudementary and I have no idea
what to do next.

Any help would be welcome.

Kind regards

  Andreas.

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

-- 
http://fam-tille.de

Re: C++ help needed for libfastahack

[Andreas Tille]

Thanks for the always useful hints

  Andreas.

On Thu, Jun 23, 2016 at 11:46:51AM +0200, Gert Wollny wrote:
> Hello Andreas, 
> 
> Am Donnerstag, den 23.06.2016, 11:24 +0200 schrieb Andreas Tille:
> > Hi,
> > 
> > As I did yesterday successfully (thanks to the help of Gert) I again
> > considered it the easiest way to build the lib by adding configure.ac
> > and Makefile.am as quilt patch and use autoconf.  This went fine
> > until to a linker problem which I do not understand:
> 
> The problem is that with autotools the C file is now compiled with a c
> compiler, and hence the function name is available  sa plain C symbol
> in the library, but when compiling the executable with the C++ compiler
> the includes the headder aas if it were C++ code, and hence expects a
> C++ mangled function name. 
> 
> I've updated the patch to correct this. 
> 
> Best, 
> Gert
> 
> 
> ___
> 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

C++ help needed for libfastahack

[Andreas Tille]

Hi,

I need to package libfastahack[1] as a pre-pre-dependency for some
Debian Med package.  The code comes with a manually crafted Makefile
that simply creates an executable while the pre-depencency of my
package[2] needs a devel package.

As I did yesterday successfully (thanks to the help of Gert) I again
considered it the easiest way to build the lib by adding configure.ac
and Makefile.am as quilt patch and use autoconf.  This went fine until
to a linker problem which I do not understand:

...
libtool: link: ( cd ".libs" && rm -f "libfastahack.la" && ln -s 
"../libfastahack.la" "libfastahack.la" )
g++ -DHAVE_CONFIG_H -I.   -I. -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -c -o FastaHack.o 
FastaHack.cpp
/bin/bash ./libtool  --tag=CXX   --mode=link g++  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro 
-Wl,-z,now -o fastahack FastaHack.o -lfastahack 
libtool: link: g++ -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/fastahack 
FastaHack.o  /build/libfastahack-0.0+20160309/.libs/libfastahack.so
FastaHack.o: In function `main':
/build/libfastahack-0.0+20160309/FastaHack.cpp:168: undefined reference to 
`shannon_H(char*, long long)'
collect2: error: ld returned 1 exit status
Makefile:540: recipe for target 'fastahack' failed
...


I checked via strings on the resulting libraries that shannon_H is
included - but it is not found anyway.  Any hint?

Thanks for your time

 Andreas.

[1] https://anonscm.debian.org/git/debian-med/libfastahack.git
[2] https://anonscm.debian.org/git/debian-med/libvcflib.git

-- 
http://fam-tille.de

-- 
http://fam-tille.de

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

[Andreas Tille]

On Wed, Jun 22, 2016 at 03:04:06PM +0200, Gert Wollny wrote:
> > I'll see what I can do to add these things, I expect to push this
> > later today or tomorrow.
> 
> Later as in: "I just did it" :) 

Muchas gracias.

Thanks for the very quick help

 Andreas.

-- 
http://fam-tille.de

C++ help needed for libsmithwaterman

[Andreas Tille]

Hi,

I need to package libsmithwaterman[1] as a pre-pre-dependency for some
Debian Med package.  The code comes with a manually crafted Makefile
that simply creates an executable while the pre-depencency of my
package[2] needs a devel package (tries to include one of the contained
headers SmithWatermanGotoh.h).

I considered it the easiest way to build the lib by adding configure.ac
and Makefile.am as quilt patch and use autoconf which does at least to
the point where some C++ error stops the build (due to stricter compile
options).  Any hint how to fix:

...
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -c SWMain.cpp  
-fPIC -DPIC -o .libs/libsmithwaterman_la-SWMain.o
SWMain.cpp: In function ‘int main(int, char**)’:
SWMain.cpp:92:77: error: no matching function for call to 
‘CSmithWatermanGotoh::Align(unsigned int&, std::__cxx11::string&, const char*&, 
const unsigned int&, const char*&, const unsigned int&)’
sw.Align(referenceSW, cigarSW, pReference, referenceLen, pQuery, queryLen);
 ^
In file included from SWMain.cpp:6:0:
SmithWatermanGotoh.h:28:10: note: candidate: void 
CSmithWatermanGotoh::Align(unsigned int&, std::__cxx11::string&, const string&, 
const string&)
 void Align(unsigned int& referenceAl, string& cigarAl, const string& s1, 
const string& s2);
  ^
SmithWatermanGotoh.h:28:10: note:   candidate expects 4 arguments, 6 provided
SWMain.cpp:93:84: error: no matching function for call to 
‘CBandedSmithWaterman::Align(unsigned int&, std::__cxx11::string&, const 
char*&, const unsigned int&, const char*&, const unsigned int&, 
std::pair&)’
bsw.Align(referenceBSW, cigarBSW, pReference, referenceLen, pQuery, 
queryLen, hr);

^
In file included from SWMain.cpp:7:0:
BandedSmithWaterman.h:35:7: note: candidate: void 
CBandedSmithWaterman::Align(unsigned int&, std::__cxx11::string&, const 
string&, const string&, std::pair&)
  void Align(unsigned int& referenceAl, string& stringAl, const string& s1, 
const string& s2, pair< pair, pair >& hr);
   ^
BandedSmithWaterman.h:35:7: note:   candidate expects 5 arguments, 7 provided
Makefile:604: recipe for target 'libsmithwaterman_la-SWMain.lo' failed


would be welcome.  Bonus points for verifying my probably weak autoconf
stuff. :-)

Thanks for your time

 Andreas.

[1] https://anonscm.debian.org/git/debian-med/libsmithwaterman.git
[2] https://anonscm.debian.org/git/debian-med/libvcflib.git

-- 
http://fam-tille.de

Re: Problems building phast against clapack

[Andreas Tille]

Hi Barak,

not sure whether you follow the discussion on debian-mentors[1]

On Fri, Jun 03, 2016 at 03:47:16PM +0500, Andrey Rahmatullin wrote:
> On Fri, Jun 03, 2016 at 11:20:09AM +0200, Andreas Tille wrote:
> > In other words you mean this is a bug in libf2c2 package
> Yes, an RC one.
> 
> > - but how to fix this?
> I have no idea. MAIN__ is used by the library, but not defined in it.

For me this sounds like a FORTRAN to C problem.  The capital letters
somehow seem to be originated in the old FORTRAN age.  I have no idea
how to fix this.

Kind regards

  Andreas.

[1] https://lists.debian.org/debian-mentors/2016/06/msg00090.html

-- 
http://fam-tille.de

Re: Problems building phast against clapack

[Andreas Tille]

On Fri, Jun 03, 2016 at 01:03:28PM +0500, Andrey Rahmatullin wrote:
> On Fri, Jun 03, 2016 at 09:59:00AM +0200, Andreas Tille wrote:
> > ../munge-help.sh consEntropy.help_src > consEntropy.help
> > gcc -O3 -Wall -I/build/phast-1.4/src/util/../../include 
> > -DPHAST_VERSION=\"v1.3\" -DPHAST_HOME=\"/build/phast-1.4/src/util/../..\" 
> > -I/build/phast-1.4/src/util/../../src/lib/pcre -fno-strict-aliasing 
> > -I/usr/lib/INCLUDE -I/usr/lib/F2CLIBS -c indelHistory.c -o indelHistory.o
> > gcc -L/build/phast-1.4/src/util/../../lib  -L/usr/lib/F2CLIBS   -o 
> > /build/phast-1.4/src/util/../../bin/indelHistory indelHistory.o -lphast 
> > -lclapack -lctmg -lcblas -lc -lf2c -lm
> > /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libf2c.so: 
> > undefined reference to `MAIN__'
> 
> $ ldd -r /usr/lib/x86_64-linux-gnu/libf2c.so.2.1
> linux-vdso.so.1 (0x7fff4efd)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7df682a000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7df652c000)
> /lib64/ld-linux-x86-64.so.2 (0x5572c209f000)
> undefined symbol: MAIN__(/usr/lib/x86_64-linux-gnu/libf2c.so.2.1)
> 
> I'd say it's a violation of a "must" policy directive in 10.2, "shared
> libraries must be linked against all libraries that they use symbols from"

In other words you mean this is a bug in libf2c2 package - but how to
fix this?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Problems building phast against clapack

[Andreas Tille]

Hi,

I recently have createt a package from clapack to build phast[1].
Unfortunately the build fails for reasons I do not understand.  I expect
that something might be wrong with either f2c or clapack packaging but
I'm not sure.  Anybody might be able to make some sense out of:

...
../munge-help.sh consEntropy.help_src > consEntropy.help
gcc -O3 -Wall -I/build/phast-1.4/src/util/../../include 
-DPHAST_VERSION=\"v1.3\" -DPHAST_HOME=\"/build/phast-1.4/src/util/../..\" 
-I/build/phast-1.4/src/util/../../src/lib/pcre -fno-strict-aliasing 
-I/usr/lib/INCLUDE -I/usr/lib/F2CLIBS -c indelHistory.c -o indelHistory.o
gcc -L/build/phast-1.4/src/util/../../lib  -L/usr/lib/F2CLIBS   -o 
/build/phast-1.4/src/util/../../bin/indelHistory indelHistory.o -lphast 
-lclapack -lctmg -lcblas -lc -lf2c -lm
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libf2c.so: undefined 
reference to `MAIN__'
collect2: error: ld returned 1 exit status
Makefile:20: recipe for target 
'/build/phast-1.4/src/util/../../bin/indelHistory' failed


Thanks for any help

Andreas.


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

-- 
http://fam-tille.de

Re: Help for backport of seer wanted (may be libhdf5 problem?)

[Andreas Tille]

Hi Gianfranco,

On Mon, May 30, 2016 at 09:33:05AM +, Gianfranco Costamagna wrote:
> Hi, a quick search on codesearch.d.n [1] shows that armadillo might be your 
> answer :)
> 
> 
> [1] https://codesearch.debian.net/results/arma_H5T_NATIVE_DOUBLE/page_0

While this looks somehow convincing I wonder why I can easily do a local
debuild with

$ LC_ALL=C apt-cache policy libarmadillo-dev
libarmadillo-dev:
  Installed: 1:5.200.1+dfsg-1~bpo8+1
  Candidate: 1:5.200.1+dfsg-1~bpo8+1
  Version table:
 1:6.700.6+dfsg-1 0
 50 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
 90 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
 *** 1:5.200.1+dfsg-1~bpo8+1 0
501 http://ftp.de.debian.org/debian/ jessie-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 1:4.450.2+dfsg-1 0
500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

installed while a build in a Jessie+backports chroot fails.  Do you think the
solution is that simple as backporting armadillo 6.700.6+dfsg-1 ?

Kind regards

   Andreas.
 
> Il Lunedì 30 Maggio 2016 11:10, Andreas Tille <andr...@an3as.eu> ha scritto:
> Hi,
> 
> I intend to backport seer[1] but I was running into a build issue:
> 
> ...
> g++ -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
> -Wall -O3 -std=c++11 -D_FORTIFY_SOURCE=2 -D DLIB_NO_GUI_SUPPORT=1 -D 
> DLIB_USE_BLAS=1 -D DLIB_USE_LAPACK=1 -DARMA_USE_HDF5=1 -fPIE -pie 
> -Wl,-z,relro -Wl,-z,now  sample.o significant_kmer.o kmer.o covar.o 
> seerCommon.o seerErr.o seerFilter.o seerIO.o seerChiFilter.o seerMain.o 
> seerCmdLine.o seerContinuousAssoc.o seerBinaryAssoc.o logitFunction.o 
> linearFunction.o -lhdf5 -lgzstream -lz -larmadillo -lboost_program_options 
> -llapack -lblas -lpthread -fPIE -pie -Wl,-z,relro -Wl,-z,now -o seer
> seerIO.o: In function `int arma::hdf5_misc::get_hdf5_type<std::complex 
> >()':
> /usr/include/armadillo_bits/hdf5_misc.hpp:151: undefined reference to 
> `arma_H5Tcreate'
> /usr/include/armadillo_bits/hdf5_misc.hpp:153: undefined reference to 
> `arma_H5T_NATIVE_FLOAT'
> /usr/include/armadillo_bits/hdf5_misc.hpp:153: undefined reference to 
> `arma_H5Tinsert'
> /usr/include/armadillo_bits/hdf5_misc.hpp:154: undefined reference to 
> `arma_H5Tinsert'
> seerIO.o: In function `get_hdf5_type':
> /usr/include/armadillo_bits/hdf5_misc.hpp:131: undefined reference to 
> `arma_H5T_NATIVE_DOUBLE'
> /usr/include/armadillo_bits/hdf5_misc.hpp:131: undefined reference to 
> `arma_H5Tcopy'
> seerIO.o: In function `arma::hdf5_misc::is_supported_arma_hdf5_type(int)':
> /usr/include/armadillo_bits/hdf5_misc.hpp:189: undefined reference to 
> `arma_H5Tequal'
> /usr/include/armadillo_bits/hdf5_misc.hpp:190: undefined reference to 
> `arma_H5Tclose'
> ...
> 
> 
> I wonder whether seer might need a certain libhdf5-dev version.  I was
> able to build seer once under Jessie - but this does not seem to work
> any more.  Any hint would be welcome.
> 
> Kind regards
> 
>   Andreas.
> 
> [1] https://anonscm.debian.org/git/debian-med/seer.git
> 
> -- 
> http://fam-tille.de
> 

-- 
http://fam-tille.de

Help for backport of seer wanted (may be libhdf5 problem?)

[Andreas Tille]

Hi,

I intend to backport seer[1] but I was running into a build issue:

...
g++ -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security 
-Wall -O3 -std=c++11 -D_FORTIFY_SOURCE=2 -D DLIB_NO_GUI_SUPPORT=1 -D 
DLIB_USE_BLAS=1 -D DLIB_USE_LAPACK=1 -DARMA_USE_HDF5=1 -fPIE -pie -Wl,-z,relro 
-Wl,-z,now  sample.o significant_kmer.o kmer.o covar.o seerCommon.o seerErr.o 
seerFilter.o seerIO.o seerChiFilter.o seerMain.o seerCmdLine.o 
seerContinuousAssoc.o seerBinaryAssoc.o logitFunction.o linearFunction.o -lhdf5 
-lgzstream -lz -larmadillo -lboost_program_options -llapack -lblas -lpthread 
-fPIE -pie -Wl,-z,relro -Wl,-z,now -o seer
seerIO.o: In function `int arma::hdf5_misc::get_hdf5_type()':
/usr/include/armadillo_bits/hdf5_misc.hpp:151: undefined reference to 
`arma_H5Tcreate'
/usr/include/armadillo_bits/hdf5_misc.hpp:153: undefined reference to 
`arma_H5T_NATIVE_FLOAT'
/usr/include/armadillo_bits/hdf5_misc.hpp:153: undefined reference to 
`arma_H5Tinsert'
/usr/include/armadillo_bits/hdf5_misc.hpp:154: undefined reference to 
`arma_H5Tinsert'
seerIO.o: In function `get_hdf5_type':
/usr/include/armadillo_bits/hdf5_misc.hpp:131: undefined reference to 
`arma_H5T_NATIVE_DOUBLE'
/usr/include/armadillo_bits/hdf5_misc.hpp:131: undefined reference to 
`arma_H5Tcopy'
seerIO.o: In function `arma::hdf5_misc::is_supported_arma_hdf5_type(int)':
/usr/include/armadillo_bits/hdf5_misc.hpp:189: undefined reference to 
`arma_H5Tequal'
/usr/include/armadillo_bits/hdf5_misc.hpp:190: undefined reference to 
`arma_H5Tclose'
...


I wonder whether seer might need a certain libhdf5-dev version.  I was
able to build seer once under Jessie - but this does not seem to work
any more.  Any hint would be welcome.

Kind regards

  Andreas.

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

-- 
http://fam-tille.de

Re: Trying to disable error=format-security for clapack

[Andreas Tille]

Hi Gert,

On Thu, May 26, 2016 at 04:27:25PM +0200, Gert Wollny wrote:
> ...
> Removing the file INCLUDE/f2c.h solves the problem, because then the
> ...

This tip saved my evening yesterday - thanks a lot.  The only remaining
issue is now 


   E: libclapack3: binary-or-shlib-defines-rpath 
usr/lib/x86_64-linux-gnu/libclapack.so.3.2.1 
/build/clapack-3.2.1+dfsg/obj-x86_64-linux-gnu/BLAS/SRC


Is there any trick how I could tweak cmake files to prevent the
inclusion of rpath or is the only chance to solve this to use

chrpath --delete

?

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: Bug#825461: [Help] Re: Bug#825461: staden: FTBFS in testing

[Andreas Tille]

On Fri, May 27, 2016 at 10:05:03AM +0200, Jakub Wilk wrote:
> * Andreas Tille <andr...@an3as.eu>, 2016-05-27, 09:27:
> >>/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/Scrt1.o: In 
> >>function `_start':
> >>(.text+0x20): undefined reference to `main'
> >>collect2: error: ld returned 1 exit status
> 
> The command line that causes this is:
> 
> gcc -shared -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_NON_CONST  
> -I/build/staden-2.0.0+b10/./tk_utils -I/build/staden-2.0.0+b10/./Misc 
> -I/build/staden-2.0.0+b10/./tk_utils -I/usr/include 
> -I"/usr/include/tcl8.6/tk-private/generic" 
> -I"/usr/include/tcl8.6/tk-private/unix" 
> -I"/usr/include/tcl8.6/tk-private/generic/ttk" 
> -I"/usr/include/tcl8.6/tcl-private/generic" 
> -I"/usr/include/tcl8.6/tcl-private/unix" 
> -I/build/staden-2.0.0+b10/./seq_utils   -I/build/staden-2.0.0+b10  
> -DSVN_VERSION="" -fPIC   -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DUSE_NON_CONST  
> -I/build/staden-2.0.0+b10/./tk_utils -I/build/staden-2.0.0+b10/./Misc 
> -I/build/staden-2.0.0+b10/./tk_utils -I/usr/include 
> -I"/usr/include/tcl8.6/tk-private/generic" 
> -I"/usr/include/tcl8.6/tk-private/unix" 
> -I"/usr/include/tcl8.6/tk-private/generic/ttk" 
> -I"/usr/include/tcl8.6/tcl-private/generic" 
> -I"/usr/include/tcl8.6/tcl-private/unix" 
> -I/build/staden-2.0.0+b10/./seq_utils   -I/build/staden-2.0.0+b10  
> -DSVN_VERSION="" -fPIC  -L/build/staden-2.0.0+b10/lib -Wl,-z,relro 
> -Wl,--export-dynamic  -Wl,-rpath,/usr/lib/staden -o 
> /build/staden-2.0.0+b10/lib/libtk_utils.so  cli_arg.o tclXkeylist.o 
> tclXutil.o tcl_utils.o tcl_debug.o misc.o init.o text_output.o tkRaster.o 
> tkRasterBuiltIn.o sheet.o tkSheet.o tkSheet_common.o trace_print.o 
> postscript.o split.o tkTrace.o tkTraceComp.o tkTraceIO.o tkTraceDisp.o 
> capture.o canvas_box.o ruler_tick.o restriction_enzyme_map.o element_canvas.o 
> container.o container_ruler.o tcl_io_lib.o  -L/usr/lib/x86_64-linux-gnu 
> -lstaden-read -fPIE -pie -Wl,-z,relro -Wl,-z,now -lm -lpthread   -lcurl -lz 
> -L/usr/lib/x86_64-linux-gnu -ltk8.6 -L/usr/lib/x86_64-linux-gnu -ltcl8.6 
> -lX11 -lXss -lXext -lXft -lfontconfig -lfreetype -lfontconfig  -lpthread -ldl 
> -lz  -lpthread -lieee -lm  -lmisc  -lpng -lz
> 
> This is trying to build a shared library with -pie, which is not going to
> fly. -pie (and -fPIE) is only for executables.
> 
> Now, I don't see any mention of pie in debian/rules, or in the old build
> log, so I guess this flag must have come from a (broken) library.

Most probably this is due to libstaden-read-dev where I added

   export DEB_BUILD_MAINT_OPTIONS = hardening=+all

I'll revert this change and see what might happen ...

Thanks for the pointer

  Andreas.


-- 
http://fam-tille.de

Re: [Help] Re: Bug#825461: staden: FTBFS in testing

[Andreas Tille]

Hi Gianfranco,

On Fri, May 27, 2016 at 07:53:45AM +, Gianfranco Costamagna wrote:
> Hi, some quick googling found some possible solutions
> https://www.google.it/search?client=ubuntu=fs=%22Scrt1.o%3A+In+function+`_start%27%3A%22=utf-8=utf-8_rd=cr=5ftHV7_JI8fA8geO-LmABQ
> 
> I remember having that issue on ettercap some years ago, this is how I fixed 
> it [1], but probably it was a little different issue.
> 
> 
> [1] 
> https://github.com/Ettercap/ettercap/commit/cf90ed99361b266e4d0d8a24f61fe5ffa82fc323

Hmmm, both is not really enlightening my poor brain - but thanks for the
pointers any way.
 
> however, it seems to be related to some build flags missing or added (in a 
> library used or in that tool itself)

Its probably some other Build-Depends that changed since staden
packaging itself is rather static.

Kind regards

  Andreas.

-- 
http://fam-tille.de

[Help] Re: Bug#825461: staden: FTBFS in testing

[Andreas Tille]

Hi,

On Fri, May 27, 2016 at 02:29:28AM +0200, Santiago Vila wrote:
> --
> capture.o: In function `tcl_capture':
> /<>/staden-2.0.0+b10/tk_utils/capture.c:31: warning: the use of 
> `tmpnam' is dangerous, better use `mkstemp'

I've fixed this in Git, but this does not help. :-(

> /usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/Scrt1.o: In 
> function `_start':
> (.text+0x20): undefined reference to `main'
> collect2: error: ld returned 1 exit status

Any help would be welcome

 Andreas.


-- 
http://fam-tille.de

Re: [Debian-med-packaging] Trying to disable error=format-security for clapack

[Andreas Tille]

Hi Gianfranco,

On Sun, May 22, 2016 at 06:48:36AM +, Gianfranco Costamagna wrote:
> ...
> I would say: remove the add_subdirectory (line 21)
> and then:
> 1) create a "FindF2C.cmake" file and use it as helper
> (that would be the best and upstreamable choice
> you can find some examples in "ettercap/cmake/Modules/Find*"

thanks to these hints I managed to build against Debian packaged libf2c.
This involved adding two files missing in libf2c source which I took
over as a patch. 

I can confirm that I builded several times on my local disk successfully
including the build time tests.  At first this did not worked until I
made sure that Debian's default CFLAGS are also used for libf2c.  Once I
have uploaded libf2c2 version 20130926-1 the build somehow stopped
working again.  I can not even reproduce things with a local rebuild.
I always get something like:

...
  Start 76: xeigtstd_lse_in
76/76 Test #76: xeigtstd_lse_in ..***Failed0.01 sec
Running: 
/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/EIG//xeigtstd
ARGS= 
OUTPUT_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/dlse.out;ERROR_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/dlse.out.err;INPUT_FILE;/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/TESTING/lse.in
CMake Error at 
/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/TESTING/runtest.cmake:29
 (message):
  Test
  
/home/tillea/debian-maintain/alioth/debian-science/git/packages/build-area/clapack-3.2.1/obj-x86_64-linux-gnu/TESTING/EIG//xeigtstd
  returned Segmentation fault


(for all the 76 tests not just the last one).  Please note that I'm
skipping those tests mentioned by Danny Edel[1] inside the patch
skip_tests_triggering_stack_overflow.patch (see updated Git[2]).

So what I'd like to know:  What's the difference between building the
code copy of libf2c comming with clapack (which can be proved by
deactivating use_debian_packaged_f2c.patch) and using libf2c2.  (Bonus
question is what I have done differently when it worked here with local
builds of libf2c2 when it worked as well - but it might need more than
super power brain reading abilities. :-()

Any help would be welcome

  Andreas.

[1] https://lists.debian.org/debian-mentors/2016/05/msg00406.html
[2] https://anonscm.debian.org/git/debian-science/packages/clapack.git

-- 
http://fam-tille.de

Re: [Debian-med-packaging] Trying to disable error=format-security for clapack

[Andreas Tille]

Sorry for replying to my own mail.  I just noticed that the Debian
packaged libf2c really has no symbol i_len_trim.  Will check what
version is packaged and how this can be fixed.

On Mon, May 23, 2016 at 12:08:08PM +0200, Andreas Tille wrote:
> Hi Gianfranco,
> 
> your very helpful hints helped me to get some steps forward.  However,
> its not finally done.
> 
> On Sun, May 22, 2016 at 06:48:36AM +, Gianfranco Costamagna wrote:
> > >Another question is how I could link against the Debian packaged f2c
> > >rather than building the one that comes with clapack upstream.
> > 
> > I would say: remove the add_subdirectory (line 21)
> > and then:
> > 1) create a "FindF2C.cmake" file and use it as helper
> > (that would be the best and upstreamable choice
> > you can find some examples in "ettercap/cmake/Modules/Find*"
> > 
> > 
> > 2) just include_directories for helping it to find the .h file (if not in 
> > standard directory)
> > and target_link_libraries of the .so file.
> 
> I think the .h files are not a problem.  With my recent changes in Git[1]
> there is a problem with the linker when running the clapack test suite:
> 
> ...
> std.dir/dtrt03.c.o CMakeFiles/xlintstd.dir/dtrt05.c.o 
> CMakeFiles/xlintstd.dir/dtrt06.c.o CMakeFiles/xlintstd.dir/dtzt01.c.o 
> CMakeFiles/xlintstd.dir/dtzt02.c.o CMakeFiles/xlintstd.dir/dgennd.c.o 
> CMakeFiles/xlintstd.dir/ddrvge.c.o CMakeFiles/xlintstd.dir/ddrvgb.c.o 
> CMakeFiles/xlintstd.dir/derrge.c.o CMakeFiles/xlintstd.dir/ddrvpo.c.o 
> CMakeFiles/xlintstd.dir/derrpo.c.o CMakeFiles/xlintstd.dir/dlaord.c.o 
> CMakeFiles/xlintstd.dir/__/__/INSTALL/dsecnd.c.o  -o xlintstd -rdynamic 
> ../MATGEN/libtmglib.a ../../SRC/libclapack.so.3.2.1 
> ../../BLAS/SRC/libcblas.so.3.2.1 -lm -lf2c 
> -Wl,-rpath,/build/clapack-3.2.1/obj-x86_64-linux-gnu/SRC:/build/clapack-3.2.1/obj-x86_64-linux-gnu/BLAS/SRC
>  
> CMakeFiles/xlintstd.dir/alaerh.c.o: In function `alaerh_':
> /build/clapack-3.2.1/TESTING/LIN/alaerh.c:444: undefined reference to 
> `i_len_trim'
> /build/clapack-3.2.1/TESTING/LIN/alaerh.c:591: undefined reference to 
> `i_len_trim'
> /build/clapack-3.2.1/TESTING/LIN/alaerh.c:604: undefined reference to 
> `i_len_trim'
> /build/clapack-3.2.1/TESTING/LIN/alaerh.c:843: undefined reference to 
> `i_len_trim'
> /build/clapack-3.2.1/TESTING/LIN/alaerh.c:473: undefined reference to 
> `i_len_trim'
> CMakeFiles/xlintstd.dir/alaerh.c.o:/build/clapack-3.2.1/TESTING/LIN/alaerh.c:737:
>  more undefined references to `i_len_trim' follow
> CMakeFiles/xlintstd.dir/dchkps.c.o: In function `dchkps_':
> /build/clapack-3.2.1/TESTING/LIN/dchkps.c:252: undefined reference to 
> `i_dceiling'
> collect2: error: ld returned 1 exit status
> 
> 
> Any further hint?
> 
> Kind regards
> 
>   Andreas.
> 
> 
> [1] https://anonscm.debian.org/git/debian-science/packages/clapack.git
> 
> -- 
> http://fam-tille.de

-- 
http://fam-tille.de

Re: [Debian-med-packaging] Trying to disable error=format-security for clapack

[Andreas Tille]

Hi Gianfranco,

your very helpful hints helped me to get some steps forward.  However,
its not finally done.

On Sun, May 22, 2016 at 06:48:36AM +, Gianfranco Costamagna wrote:
> >Another question is how I could link against the Debian packaged f2c
> >rather than building the one that comes with clapack upstream.
> 
> I would say: remove the add_subdirectory (line 21)
> and then:
> 1) create a "FindF2C.cmake" file and use it as helper
> (that would be the best and upstreamable choice
> you can find some examples in "ettercap/cmake/Modules/Find*"
> 
> 
> 2) just include_directories for helping it to find the .h file (if not in 
> standard directory)
> and target_link_libraries of the .so file.

I think the .h files are not a problem.  With my recent changes in Git[1]
there is a problem with the linker when running the clapack test suite:

...
std.dir/dtrt03.c.o CMakeFiles/xlintstd.dir/dtrt05.c.o 
CMakeFiles/xlintstd.dir/dtrt06.c.o CMakeFiles/xlintstd.dir/dtzt01.c.o 
CMakeFiles/xlintstd.dir/dtzt02.c.o CMakeFiles/xlintstd.dir/dgennd.c.o 
CMakeFiles/xlintstd.dir/ddrvge.c.o CMakeFiles/xlintstd.dir/ddrvgb.c.o 
CMakeFiles/xlintstd.dir/derrge.c.o CMakeFiles/xlintstd.dir/ddrvpo.c.o 
CMakeFiles/xlintstd.dir/derrpo.c.o CMakeFiles/xlintstd.dir/dlaord.c.o 
CMakeFiles/xlintstd.dir/__/__/INSTALL/dsecnd.c.o  -o xlintstd -rdynamic 
../MATGEN/libtmglib.a ../../SRC/libclapack.so.3.2.1 
../../BLAS/SRC/libcblas.so.3.2.1 -lm -lf2c 
-Wl,-rpath,/build/clapack-3.2.1/obj-x86_64-linux-gnu/SRC:/build/clapack-3.2.1/obj-x86_64-linux-gnu/BLAS/SRC
 
CMakeFiles/xlintstd.dir/alaerh.c.o: In function `alaerh_':
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:444: undefined reference to 
`i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:591: undefined reference to 
`i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:604: undefined reference to 
`i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:843: undefined reference to 
`i_len_trim'
/build/clapack-3.2.1/TESTING/LIN/alaerh.c:473: undefined reference to 
`i_len_trim'
CMakeFiles/xlintstd.dir/alaerh.c.o:/build/clapack-3.2.1/TESTING/LIN/alaerh.c:737:
 more undefined references to `i_len_trim' follow
CMakeFiles/xlintstd.dir/dchkps.c.o: In function `dchkps_':
/build/clapack-3.2.1/TESTING/LIN/dchkps.c:252: undefined reference to 
`i_dceiling'
collect2: error: ld returned 1 exit status


Any further hint?

Kind regards

  Andreas.


[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git

-- 
http://fam-tille.de

Missing latest version of libgtk-3-common in unstable?

[Andreas Tille]

Hi,

is anybody else observing this:

$ LC_ALL=C apt-cache policy libgtk-3-common  libgtk-3-0
libgtk-3-common:
  Installed: 3.20.4-1
  Candidate: 3.20.4-1
  Version table:
 *** 3.20.4-1 501
501 http://httpredir.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
libgtk-3-0:
  Installed: 3.20.4-1
  Candidate: 3.20.4-1
  Version table:
 3.20.5-1 50
 50 http://httpredir.debian.org/debian unstable/main amd64 Packages
 50 http://ftp.debian.org/debian unstable/main amd64 Packages
 50 http://incoming.debian.org/debian-buildd buildd-unstable/main amd64 
Packages
 *** 3.20.4-1 501
501 http://httpredir.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status


Unstable mirrors seem to miss libgtk-3-common binary package even if it
belongs to the same source as libgtk-3-0 and tracker lists all
versions[1] also of libgtk-3-common.  I'm observing this effect in my
pbuilder chroots since yesterday.

Any hint?

Kind regards

Andreas.

[1] https://tracker.debian.org/pkg/gtk+3.0

-- 
http://fam-tille.de

Re: [Debian-med-packaging] Trying to disable error=format-security for clapack

[Andreas Tille]

Hi again,

after the build issues in clapack[1] were solved and I was even able to
create shared libraries I wonder how I can properly set a sensible
SONAME.  I tried to do this via SET_TARGET_PROPERTIES but failed.

Another question is how I could link against the Debian packaged f2c
rather than building the one that comes with clapack upstream.

Any help would be welcome

Andreas.

[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git

On Mon, May 16, 2016 at 12:21:06PM +0200, Gert Wollny wrote:
> Am Montag, den 16.05.2016, 10:16 + schrieb Gianfranco Costamagna:
> > Hi Gert!
> > 
> > > 
> > > I think, since in this case the (empty) format string passed to the
> > > printf call is not user generated there is no security problem to
> > > be exploited.
> > 
> > yes, sure, but disabling this flag has a nasty side-effect, it is
> > disabled in the *whole* build, possibly
> > hiding more serious issues somewhere else.
> 
> Of course, that's why I gave the #pragma based disabling that can be
> fitted tightly to the offending code. 
> 
> Best, 
> Gert 
> 
> 
> 

-- 
http://fam-tille.de

Re: Trying to disable error=format-security for clapack

[Andreas Tille]

Hi Danny,

On Mon, May 16, 2016 at 04:30:23PM +0200, Danny Edel wrote:
> Sorry for replying to my own email, but after compiling, the test suite
> crashed on the xeigtstz_* with Segmentation Fault errors.

No need to sorry,
 
> I debugged this a little bit and the reason was these tests use a lot of
> local (i.e. stack) variables -- so many in fact that they trigger a
> stack overflow on entry.
> 
> Disabling stack size limit (mine was 8192 KB) with
>   ulimit -s unlimited
> before calling dpkg-buildpackage fixed things for me.
> 
> I hope this avoids someone the half hour I spent in gdb searching for a
> bug that probably isn't there.

Would you mind commiting to Git what was building for you?

Kind regards and thanks for your review

Andreas.

-- 
http://fam-tille.de

Trying to disable error=format-security for clapack

[Andreas Tille]

Hi,

as a precondition for some package for Debian Med I intend to package
clapack[1].  Despite the discussion on Debian Science about the relation
of clapack and lapacke[2] I decided that it is less effort to have
clapack in addition since upstream of phast[3] (my final target) does
not intend to port the code from clapack to lapacke.

I tried to build clapack[1] and it has a nasty format error:

/build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a 
string literal and no format arguments [-Werror=format-security]
  Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;
  ^
cc1: some warnings being treated as errors

When reading the code it seems to me that actually a test whether this
code works or not is intended and thus fixing the format is not in the
intention of the authors.  So I tried 

export DEB_BUILD_HARDENING_FORMAT:=0
DPKG_EXPORT_BUILDFLAGS = 1

but the build keeps on failing.  Any idea?

Kind regards

  Andreas.

[1] https://anonscm.debian.org/git/debian-science/packages/clapack.git
[2] https://lists.debian.org/debian-science/2016/04/msg00053.html
[3] https://anonscm.debian.org/git/debian-med/phast.git

-- 
http://fam-tille.de

Re: Bug#818505: sortmerna FTBFS on !x86

[Andreas Tille]

On Sun, Mar 27, 2016 at 08:15:27PM +0200, Adam Borowski wrote:
> 
> It might be also good to make a "sse2-support" package as mentioned in the
> thread Gert linked to to reduce duplication of such detection logic.  Please
> say so if you think this is a good idea.

Saying "so".  :-)

Yes, having an sse2-support package would be brilliant since this is
definitely not the first time I'm stumbling upon this issue.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Doxygen help needed (Was: FTBFS: error while building documentation)

[Andreas Tille]

Hi,

as you can read below upstream can not reproduce this problem.  I
checked the last upstream version and the problem persists - probably
due to different doxygen versions?  I've moved the packaging of cimg
to Git

  https://anonscm.debian.org/git/debian-science/packages/cimg.git

and injected the latest upstream version there.  Any help from an
doxygen expert would be welcome.

Kind regards

  Andreas.

On Fri, Apr 29, 2016 at 08:49:07AM +0200, David Tschumperlé wrote:
> Hello Andreas,
> 
> I've just tested here with the latest version available (1.7.1), and
> everything works as expected, without error.
> Maybe there was an error in 1.6.5, but so far it seems to have been fixed.
> 
> Regards,
> 
> David.
> 
> 2016-04-28 16:45 GMT+02:00 Andreas Tille <andr...@an3as.eu>:
> 
> > Hi David,
> >
> > there is an error when trying to build the cimg documentation that did
> > not happened before (= at the time when I have created the package).
> >
> > The log which you can find in the Debian bug tracking system[1] in full
> > length says:
> >
> > ...
> > Runaway argument?
> > {\texorpdfstring {operator\%=(const t value)}{operator\begin {DoxyPar\ETC.
> > ! Paragraph ended before \@sect was complete.
> > 
> >\par
> > l.4286
> >
> > ?
> > ! Emergency stop.
> > 
> >\par
> > l.4286
> >
> > !  ==> Fatal error occurred, no output PDF file produced!
> > Transcript written on refman.log.
> > Makefile:6: recipe for target 'refman.pdf' failed
> >
> >
> > Have you ever heard of similar issues?  Is there perhaps an explanation
> > or a known patch?
> >
> > Kind regards
> >
> >Andreas.
> >
> >
> > [1]
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;filename=cimg_1.6.5%2Bdfsg-1_amd64.build;msg=5;bug=819606
> >
> > --
> > http://fam-tille.de
> >

-- 
http://fam-tille.de

Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

Hi Raphael,

On Thu, Apr 14, 2016 at 12:00:26PM +0200, Raphael Hertzog wrote:
> 
> So I did have a look and the problem is that your package doesn't contain any
> usr/lib/R/site-library/shiny/www/shared/jqueryui/images to replace
> with some real files.
> 
> I added this to check it:
>  install/$(package)::
> +   find $(debRlib)
> dh_linktree

Well, yes, that's correct.  I considered it a good idea to strip the
files that are not needed in the final package and to be really sure
that these will not be used from the upstream source tarball via
Files-Excluded.  The additional advantage is that I do not need to
craft several copyright statements for stuff that's not used anyway.
 
> No "images" directory to replace. Are you sure that you need it?

Yes, I'm sure and I need the symlink definitely.
 
> >   Depends: libjs-jquery-ui (<< 1.10.1+dfsg.0~), libjs-jquery-ui (>= 
> > 1.10.1+dfsg), r-base-core (>= 3.2.4.20160412-1), r-api-3, r-cran-httpuv, 
> > r-cran-mime, r-cran-jsonlite, r-cran-xtable, r-cran-digest, r-cran-r6, 
> > r-cran-htmltools
> > 
> > So the embed triggers the (unwanted) strong dependency and the replace
> > triggers no dependency from the other libs.  So most probably I did
> > something really wrong here - but I wonder what?
> 
> That's because nothing got replaced really... the files that you ask to 
> replace
> do not exist.

So may be dh_linktrees is not the correct tool for me.  I just want it
to create symlinks and may be the best idea is to just use dh_link
instead and add the libjs-dependencies manually.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

On Thu, Apr 14, 2016 at 10:02:43AM +0200, Raphael Hertzog wrote:
> On Wed, 13 Apr 2016, Andreas Tille wrote:
> > The thing is I used "replace" in the first place instead of embed but
> > it resulted in
> > 
> > dh_linktree
> > dpkg-query: error: --search needs at least one file name pattern argument
> > 
> > Use --help for help about querying packages.
> > dh_linktree: error: dpkg --search --  gave error exit status 2
> > 
> > when replacing whole directories.  Is there any chance to do a "replace
> > directory"?
> 
> I'm not sure what you tried here.

You might like to checkout r-cran-shiny[1] or look directly at the
linktrees file[2].

> But replace can definitely operate on
> directories even though it will only act on all files below that
> directory. You must have done some mistake in the way you use it...

I can't exclude that it is just my fault. ;-)
 
> And for your explanations of why you want to symlink a directory and not
> the individual files, I can understand it, it's part of the trade off...
> they are better in general, but they are painful if you have to revert
> them to go back to the embedded version (because the Debian version is
> incompatible).

Yes.  Due to your hint I'm now using only one remaining dir replacement
and I needed to use embed here (see [2]) - otherwise the package fails
to build with the above error.

However, what now converns me even more is that when using the replace
action the dependencies are missing in the resulting control
DEBIAN/control inside the package.  It looks like:

  Depends: libjs-jquery-ui (<< 1.10.1+dfsg.0~), libjs-jquery-ui (>= 
1.10.1+dfsg), r-base-core (>= 3.2.4.20160412-1), r-api-3, r-cran-httpuv, 
r-cran-mime, r-cran-jsonlite, r-cran-xtable, r-cran-digest, r-cran-r6, 
r-cran-htmltools

So the embed triggers the (unwanted) strong dependency and the replace
triggers no dependency from the other libs.  So most probably I did
something really wrong here - but I wonder what?

Kind regards

   Andreas.

[1] https://anonscm.debian.org/git/debian-med/r-cran-shiny.git
[2] 
https://anonscm.debian.org/cgit/debian-med/r-cran-shiny.git/tree/debian/linktrees
 

-- 
http://fam-tille.de

Re: Bug#820879: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

On Wed, Apr 13, 2016 at 09:37:00PM +0200, Andreas Tille wrote:
> On Wed, Apr 13, 2016 at 03:38:16PM +0200, Raphael Hertzog wrote:
> > On Wed, 13 Apr 2016, Andreas Tille wrote:
> > > Could you advise for the proper option to get a less strict dependency?
> > 
> > Please read its manual page, it's all documented:
> > 
> > | The "replace" action is like "deduplicate" except that it does
> > | replace existing files even if their content is different from the 
> > content of
> > | the source files. It generates a weak dependency ("at least the current
> > | upstream version") on the basis that you already assume that both version 
> > are
> > | compatible, otherwise you would have used "deduplicate" or "embed".
> 
> The thing is I used "replace" in the first place instead of embed but
> it resulted in
> 
> dh_linktree
> dpkg-query: error: --search needs at least one file name pattern argument
> 
> Use --help for help about querying packages.
> dh_linktree: error: dpkg --search --  gave error exit status 2
> 
> 
> when replacing whole directories.  Is there any chance to do a "replace
> directory"?

To underline why this makes sense:

   /usr/share/twitter-bootstrap/files/js/locales

contains currently 38 different translation files.  If a new package
twitter-bootstrap might be released there could be more translations.
So it makes absolutely sense to just symlink to the directory instead of
single files which would exclude new translations for no good reason.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

On Wed, Apr 13, 2016 at 03:38:16PM +0200, Raphael Hertzog wrote:
> On Wed, 13 Apr 2016, Andreas Tille wrote:
> > Could you advise for the proper option to get a less strict dependency?
> 
> Please read its manual page, it's all documented:
> 
> | The "replace" action is like "deduplicate" except that it does
> | replace existing files even if their content is different from the content 
> of
> | the source files. It generates a weak dependency ("at least the current
> | upstream version") on the basis that you already assume that both version 
> are
> | compatible, otherwise you would have used "deduplicate" or "embed".

The thing is I used "replace" in the first place instead of embed but
it resulted in

dh_linktree
dpkg-query: error: --search needs at least one file name pattern argument

Use --help for help about querying packages.
dh_linktree: error: dpkg --search --  gave error exit status 2


when replacing whole directories.  Is there any chance to do a "replace
directory"?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

Hi Raphael,

On Wed, Apr 13, 2016 at 02:41:52PM +0200, Raphael Hertzog wrote:
> 
> It really depends... you're trading one problem for another. In general,
> it's best if you can just rely on the packaged javascript without having
> to replace any embedded copy.
> 
> But if you have to replace an embedded copy, then dh_linktree is better
> as it lets you easily switch from embedded to non-embedded (without having
> to deal with symlink_to_dir and dir_to_symlink transitions). There are also
> multiple "actions" that result in different dependencies... by default
> you get a strong dependency like said here but if you're confident that
> newer upstream releases will not introduce new files, then you can use
> something less strict.

Could you advise for the proper option to get a less strict dependency?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

Hi James,

On Wed, Apr 13, 2016 at 12:28:58PM +0100, James Cowgill wrote:
> On Wed, 2016-04-13 at 13:13 +0200, Andreas Tille wrote:
> > via this bug I learned (the hard way) that a
> > 
> >    Depends: ${js:Depends}
> > 
> > will be resolved into
> > 
> >    libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
> > 
> > (for instance) in the final package.  I have no reason to assume that
> > the actual version that was available at package build time is the
> > only
> > valid dependency for my package.  So it seems unadvisable to use
> > ${js:Depends} depends at all to avoid continuous uploading of the
> > package (depending from 9 different libjs-* packages) if any of its
> > libjs-* was uploaded with a new version.
> > 
> > I wonder what the idea behind this resulution of the ${js:Depends}
> > would be since I have the feeling that this is not sensible in the
> > most practical cases.
> > 
> > Am I missing something?
> 
> I think those dependencies come from dh_linktree and are placed in
> ${misc:Depends}, not ${js:Depends}.
> 
> dh_linktree(1) contains this:
> 
> Since symlink trees are created statically at build-time, they are not
> very future-proof and have a risk to miss some files introduced by a
> newer version of the package providing the file tree which is
> duplicated. That's why the generated dependencies generally ensure that
> the same upstream version be used at run-time than at build-time.

Ahhh, good hint.  So the solution to my problem would rather be to
drop dh_linktree? (Raphael in CC whether I might have missed something).

Kind regards

 Andreas.

-- 
http://fam-tille.de

How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[Andreas Tille]

Hi,

via this bug I learned (the hard way) that a

   Depends: ${js:Depends}

will be resolved into

   libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)

(for instance) in the final package.  I have no reason to assume that
the actual version that was available at package build time is the only
valid dependency for my package.  So it seems unadvisable to use
${js:Depends} depends at all to avoid continuous uploading of the
package (depending from 9 different libjs-* packages) if any of its
libjs-* was uploaded with a new version.

I wonder what the idea behind this resulution of the ${js:Depends}
would be since I have the feeling that this is not sensible in the
most practical cases.

Am I missing something?

Kind regards

  Andreas.

On Wed, Apr 13, 2016 at 12:33:41PM +0200, Andreas Beckmann wrote:
> Package: r-cran-shiny
> Version: 0.13.1+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
> 1m45.1s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmpmbw__d', 
> 'apt-get', '-y', 'install', 'r-cran-shiny']
> 1m45.6s DUMP: 
>   Reading package lists...
>   Building dependency tree...
>   Reading state information...
>   Some packages could not be installed. This may mean that you have
>   requested an impossible situation or if you are using the unstable
>   distribution that some required packages have not yet been created
>   or been moved out of Incoming.
>   The following information may help to resolve the situation:
>   
>   The following packages have unmet dependencies:
>r-cran-shiny : Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to 
> be installed
>   E: Unable to correct problems, you have held broken packages.
> 
> 
> Cheers,
> 
> Andreas
> 
> ___
> 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: Any reason to keep libsdsl in experimental (Was: Please help creating shared *and* static library with cmake)

[Andreas Tille]

Hi Tomasz,

On Sat, Apr 09, 2016 at 04:47:35PM +0200, Tomasz Buchert wrote:
> 
> the only reason is that it doesn't build on most architectures. The
> upstream devel version build, I think, on other archs, but it hasn't
> been released yet. I've asked the upstream author to release a new
> version, but unfortunately without any success.

That's a bit sad but unfortunately we have several other packages where
this is the case and IMHO that's not a urgent reason to keep a package
in experimental.
 
> So, what I can do is to release libsdsl to only limited number of
> archs (amd64, arm64, ppc64el, s390x) and then in the future I would
> extend this list. This will obviously limit the architectures that
> any reverse dependency will build on.
> 
> What do you think?

This would be really helpful for my plan since I have a package that
depends from this lib and I would like to move this to main (even want
to create a backport).  So if you would upload to unstable this would
be really welcome.

Moreover I would consider the package a sensible target for the Debian
Science team - it would be great if you could move it to Debian Science
Git and use
   "Debian Science Team "
as maintainer.

As a side effect this would simplify contributions to the package - I
noticed that I was not able to commit to the repository (which is
strange since I usually do not have an problems to commit to
collab-maint.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Any reason to keep libsdsl in experimental (Was: Please help creating shared *and* static library with cmake)

[Andreas Tille]

On Fri, Apr 08, 2016 at 06:16:51PM +0100, Sascha Steinbiss wrote:
> For the record, I seem to remember there is already a libsdsl package in 
> experimental:
> https://packages.qa.debian.org/libs/libsdsl.html

Ahhh, very helpful hint!!

Tomasz, is there any reason to have this package in experimental?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Please help creating shared *and* static library with cmake

[Andreas Tille]

On Fri, Apr 08, 2016 at 05:53:48PM +0200, Ole Streicher wrote:
> Andreas Tille <andr...@an3as.eu> writes:
> > I need to package libsdsl[1] as some precondition for a Debian Med
> > package.  The default cmake build only creates a static library and I
> > found a patch to create a shared library.  But since library packages
> > should include both I wonder how to get both shared and static library
> > without doing to much tricky things.
> 
> For the common case, I see no real reason to include both; having just
> the dynamic libs and the header is enough, IMO.

Policy says[1]:

   The static library (libraryname.a) is usually provided in addition to
   the shared version. 

I have no good reason to derive from this.

 
> The only use case I could imagine is to create an executable that can
> run outside of Debian.

That's a valid use case for consumer of the lib*-dev package.

Kind regards

  Andreas.

[1] 
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-static

-- 
http://fam-tille.de

Re: Please help creating shared *and* static library with cmake

[Andreas Tille]

On Fri, Apr 08, 2016 at 06:13:13PM +0200, Joachim Reichel wrote:
> in the "cgal" package I basically build the package twice:
> 
> override_dh_auto_configure-arch:
>   mkdir -p static
>   cd static && cmake .. -DBUILD_SHARED_LIBS=FALSE
>   mkdir -p shared
>   cd shared && cmake .. -DBUILD_SHARED_LIBS=TRUE -DCMAKE_SKIP_RPATH=TRUE
> 
> override_dh_auto_build-arch:
> $(MAKE) $(NJOBS) -C static
> $(MAKE) $(NJOBS) -C shared
> 
> override_dh_install-arch:
> $(MAKE) -C static DESTDIR=$(CURDIR)/debian/tmp install
> $(MAKE) -C shared DESTDIR=$(CURDIR)/debian/tmp install

Thanks for the hint.  I wanted to avoid this two step build and was
hoping to find a solution without the overrides dealing with each build
twice.
 
> Not sure what you mean with "found a patch to create a shared library". Are 
> you
> saying that your project files do not support -DBUILD_SHARED_LIBS?

This patch

   
https://anonscm.debian.org/cgit/debian-med/libsdsl.git/tree/debian/patches/dynamic_lib.patch

turns the build from static (default) to dynamic.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Please help creating shared *and* static library with cmake

[Andreas Tille]

Hi,

I need to package libsdsl[1] as some precondition for a Debian Med
package.  The default cmake build only creates a static library and I
found a patch to create a shared library.  But since library packages
should include both I wonder how to get both shared and static library
without doing to much tricky things.

Besides this I'm wondering how I could get rid of the gtest code
copy and run the test anyway.

Kind regards

 Andreas.


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

-- 
http://fam-tille.de

Re: Problems linking hdf5, gzstream, boost_program_options due to usage of simple Makefile

[Andreas Tille]

Hi Jakub,

On Tue, Mar 29, 2016 at 10:01:51PM +0200, Jakub Wilk wrote:
> 
> https://github.com/johnlees/seer links to:
> http://www.cs.unc.edu/Research/compgeom/gzstream/
> 
> AFAICT, this is not packaged for Debian. (Although we have multiple embedded
> code copies[0]. Yay...)

See #819532.

Kind regards

   Andreas. 

-- 
http://fam-tille.de

Problems linking hdf5, gzstream, boost_program_options due to usage of simple Makefile

[Andreas Tille]

Hi,

I'm trying to package seer[1] for the Debian Med team.  Upstream provides a
simple Makefile which is probably the cause why the libraries for linking
are not found properly so it ends up in

...
g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -O3 
-std=c++11 -I/nonexistent/software/include -I../gzstream -I../dlib -D 
DLIB_NO_GUI_SUPPORT=1 -D DLIB_USE_BLAS=1 -D DLIB_USE_LAPACK=1 -Wl,-z,relro  
sample.o significant_kmer.o kmer.o covar.o seerCommon.o seerErr.o seerFilter.o 
seerIO.o seerChiFilter.o seerMain.o seerCmdLine.o seerContinuousAssoc.o 
seerBinaryAssoc.o logitFunction.o linearFunction.o -lhdf5 -lgzstream -lz 
-larmadillo -lboost_program_options -llapack -lblas -Wl,-z,relro -o seer
/usr/bin/ld: cannot find -lhdf5
/usr/bin/ld: cannot find -lgzstream
/usr/bin/ld: cannot find -lboost_program_options
collect2: error: ld returned 1 exit status

Any hint how to elegantly deal with this situation?

Kind regards

   Andreas.

[1] svn://anonscm.debian.org/debian-med/trunk/packages/seer/trunk/

-- 
http://fam-tille.de

Bug#819391: Please use Git repository layout as described in Debian Science policy

[Andreas Tille]

Hi Thomas,

I had a look into the repository of toulbar2[1] since you asked for
sponsering of the package.  I noticed that it does not follow the
repository layout as specified in the Debian Science policy[2] and also
the control file diverges from Debian Science policy (Maintainer should
be the mailing list, you should be Uploader, VCS fields are missing).

Please fix the repository accordingly

  Andreas.

[1] https://git.debian.org/git/debian-science/packages/toulbar2.git
[2] 
https://debian-science.alioth.debian.org/debian-science-policy.html#idp45010192

-- 
http://fam-tille.de

Re: Bug#818505: sortmerna FTBFS on !x86

[Andreas Tille]

Hi Jurica,

On Thu, Mar 17, 2016 at 05:04:21PM +, Jurica Stanojkovic wrote:
> Package sortmerna FTBFS on archs not in x86 group (amd64, i386, x32, etc. )
> with following error:
> gcc: error: unrecognized command line option '-msse2'
> 
> build logs:
> https://buildd.debian.org/status/logs.php?pkg=sortmerna=2.1-1=sid
> 
> Package use -msse2 for all architectures, 
> but not all archs have support for sse2 instruction set.
> 
> if -msee2 flag is removed from build next error reported is:
> src/ssw.c:45:23: fatal error: emmintrin.h: No such file or directory

As far as I can see this might restrict the package to intel
architectures.  If there is no hint how to build on those other
architectures I'd restrict the architectures to these.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#818623: STatus of r-cran-uuid?

[Andreas Tille]

Hi Mattia,

thanks for the hints.  Its just what I'm doing - but you need to know
when to update your apt cache ... :-)

Kind regards

 Andreas.

On Wed, Mar 23, 2016 at 10:05:51AM +, Mattia Rizzolo wrote:
> On Wed, Mar 23, 2016 at 10:02:06AM +, Mattia Rizzolo wrote:
> > On Wed, Mar 23, 2016 at 10:57:45AM +0100, Andreas Tille wrote:
> > > it seems this package was in NEW queue but it is not any more and I also
> > > can't find it in the package pool.  Could you please give some status
> > > update?
> > 
> > it has been accepted 3 hours ago.
> 
> oh, of course you won't find it in the package pool (it needs a dinstall
> and a it has to reach your mirror before), but right after the accept
> it'll move to incoming.d.o, you can find it there alread.  Also, DDPO is
> a wonder to quickly follow package, and you can find it listed there
> (just grep over my DDPO page).
> 
> BTW, using incoming.d.o is pretty useful when you work on stuff like
> this, you can add it to your sources.list in your chroot and use it to
> do the builds (note that it is slower than a regular mirror, so maybe
> add it *after* the mirror entries, so only packages that aren't on the
> mirror are picked from there).
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-



-- 
http://fam-tille.de

Bug#818623: STatus of r-cran-uuid?

[Andreas Tille]

Hi,

it seems this package was in NEW queue but it is not any more and I also
can't find it in the package pool.  Could you please give some status
update?

I'd suggest to move the package to Debian Science Git and I'd volunteer
to do so but it would be good to know if and why it was rejected.  (One
of the drawbacks of having a person instead a list inside the Maintainer
field is that you can not find a public record of the rejection - at
least I'm not aware of this.)

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#818622: ITP: r-cran-r6 -- R classes with reference semantics

[Andreas Tille]

Hi Gordon,

I realised to late that you also ITPed r-cran-r6 and issued another ITP
for this package.  I noticed as well that you opened another "versioned"
ITP as bug #818622 which is a bit unusual, thought.

I intended to package this as well for the Debian Med team.  Since your
ITP was first I cloned the Git repository at collab-maint, did the changes
I considered sensible and sponsored the upload.

I would recommend to maintain R packages in a more fitting team - for
instance Debian Science.  If you have no idea what to do feel free to
ask me.

Kind regards and thanks for your initial work on the package

Andreas.


-- 
http://fam-tille.de

Re: Help with new version of iqtree needed

[Andreas Tille]

Hi James,

thanks for the fast response:

On Thu, Mar 10, 2016 at 01:49:23PM +, James Cowgill wrote:
> On Thu, 2016-03-10 at 14:39 +0100, Andreas Tille wrote:
> > Hi,
> > 
> > I#m facing a C++ problem with the new version of iqtree.  If I build the
> > current state in Git[1] I get:
> > 
> > ...
> > [  7%] Building C object pll/CMakeFiles/pll.dir/evaluateGenericSpecial.c.o
> > cd /build/iqtree-1.4.0+dfsg/obj-x86_64-linux-gnu/pll && /usr/bin/cc  
> > -DIQ_TREE -D_USE_PTHREADS -D__SSE3 -I/build/iqtree-1.4.0+dfsg 
> > -I/build/iqtree-1.4.0+dfsg/obj-x86_64-linux-gnu  -g -O2 
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> > -D_FORTIFY_SOURCE=2  -pthread-o 
> > CMakeFiles/pll.dir/evaluateGenericSpecial.c.o   -c 
> > /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c
> > In file included from 
> > /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:46:0:
> > /build/iqtree-1.4.0+dfsg/pll/pllInternal.h:150:30: warning: inline function 
> > 'bitcount_64_bit' declared but never defined
> >  extern __inline unsigned int bitcount_64_bit(uint64_t i);
> >   ^
> > In file included from /build/iqtree-1.4.0+dfsg/pll/pll.h:79:0,
> >  from /build/iqtree-1.4.0+dfsg/pll/mem_alloc.h:16,
> >  from 
> > /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:31:
> > /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c: In function 
> > 'evaluateGTRCATPROT':
> > /usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:86:1: error: inlining 
> > failed in call to always_inline '_mm_hadd_pd': target specific option 
> > mismatch
> >  _mm_hadd_pd (__m128d __X, __m128d __Y)
> >  ^
> 
> _mm_hadd_pd is a sse3 intrinsic so you have to pass -msse3 to allow GCC
> to use it. However, this will cause a SIGILL on any amd64/i386
> processor without sse3 so instead the code should be replaced with
> something more portable.

Since I have no idea about SSE my attempt to fix #813436 obviously
triggered this problem.  I admit I have no idea how to deal with this
sensibly.

Kind regards

 Andreas.


-- 
http://fam-tille.de

Help with new version of iqtree needed

[Andreas Tille]

Hi,

I#m facing a C++ problem with the new version of iqtree.  If I build the
current state in Git[1] I get:

...
[  7%] Building C object pll/CMakeFiles/pll.dir/evaluateGenericSpecial.c.o
cd /build/iqtree-1.4.0+dfsg/obj-x86_64-linux-gnu/pll && /usr/bin/cc  -DIQ_TREE 
-D_USE_PTHREADS -D__SSE3 -I/build/iqtree-1.4.0+dfsg 
-I/build/iqtree-1.4.0+dfsg/obj-x86_64-linux-gnu  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -pthread-o 
CMakeFiles/pll.dir/evaluateGenericSpecial.c.o   -c 
/build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c
In file included from 
/build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:46:0:
/build/iqtree-1.4.0+dfsg/pll/pllInternal.h:150:30: warning: inline function 
'bitcount_64_bit' declared but never defined
 extern __inline unsigned int bitcount_64_bit(uint64_t i);
  ^
In file included from /build/iqtree-1.4.0+dfsg/pll/pll.h:79:0,
 from /build/iqtree-1.4.0+dfsg/pll/mem_alloc.h:16,
 from /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:31:
/build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c: In function 
'evaluateGTRCATPROT':
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:86:1: error: inlining 
failed in call to always_inline '_mm_hadd_pd': target specific option mismatch
 _mm_hadd_pd (__m128d __X, __m128d __Y)
 ^
/build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:2667:10: error: called 
from here
   tv = _mm_hadd_pd(tv, tv);
  ^
In file included from /build/iqtree-1.4.0+dfsg/pll/pll.h:79:0,
 from /build/iqtree-1.4.0+dfsg/pll/mem_alloc.h:16,
 from /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:31:
/usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:86:1: error: inlining 
failed in call to always_inline '_mm_hadd_pd': target specific option mismatch
 _mm_hadd_pd (__m128d __X, __m128d __Y)
 ^
/build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:2700:10: error: called 
from here
   tv = _mm_hadd_pd(tv, tv);
  ^
pll/CMakeFiles/pll.dir/build.make:113: recipe for target 
'pll/CMakeFiles/pll.dir/evaluateGenericSpecial.c.o' failed
...


Any hint how to fix this?

Kind regards

   Andreas.


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

-- 
http://fam-tille.de

[Help] Re: pandas FTBFS on BE platforms due to a bunch of tests failures

[Andreas Tille]

Hi,

while pandas builds on intel it fails on several other architectures as
reported in #814795.  This has been reported upstream[1] who does not
seem to be really interested in solving the issue.  Any help from
porters would be really welcome.

Thanks a lot

  Andreas.

[1] https://github.com/pydata/pandas/issues/11282

-- 
http://fam-tille.de

Bug#814727: Latex not found

[Andreas Tille]

Hi,

when trying to build the package I get

...
warning: doxygen no longer ships with the FreeSans font.
You may want to clear or change DOT_FONTNAME.
Otherwise you run the risk that the wrong font is being used for dot generated 
graphs.
sh: 1: latex: not found
sh: 1: dvips: not found
...

I think you should check build dependencies to make sure the docs will
be created properly.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Problems using OpenCL in pbuilder (Was: OpenCL GPU usage on autobuilders)

[Andreas Tille]

Hi,

I did some more investigation and played around with the
Build-Dependencies and added

   ocl-icd-opencl-dev | opencl-dev,
   pocl-opencl-icd | opencl-icd

but without any luck.  I tried to run the affected test in a local
chroot environment which worked nicely.  So I wonder what exactly I need
to do to let the test below pass and enable the detection of a smart
enough GPU in pbuilder.

Thanks for any help

   Andreas.

On Sun, Jan 31, 2016 at 08:27:46AM +0100, Andreas Tille wrote:
> Hi,
> 
> I just realised that the issue also happens on my local machine - so the
> assumption that only autobuilders are affected is wrong.  I think I just
> need to fix the dependencies for libhmsbeagle-dev.  Sorry for the noise
> 
>Andreas.
> 
> On Sun, Jan 31, 2016 at 07:56:31AM +0100, Andreas Tille wrote:
> > Hi,
> > 
> > On Sat, Jan 30, 2016 at 11:51:26PM +0100, Chris Lamb wrote:
> > > Source: python-biopython
> > > Version: 1.66+dfsg-1
> > > Severity: serious
> > > Justification: fails to build from source
> > > ...
> > >   ApplicationError: Non-zero return code 255 from 'phyml -i 
> > > Phylip/interlaced2.phy -d aa', message 'beignet-opencl-icd: no supported 
> > > GPU found, this is probably the wrong opencl-icd package for this 
> > > hardware'
> > > ...
> > 
> > this bug is caused by the change in libhmsbeagle-dev which is now using
> > OpenCL which does not seem to work on the machine that is doing the
> > build tests.  Any hint how that could be done properly?
> > 
> > Kind regards
> > 
> >   Andreas.
> > 
> > -- 
> > http://fam-tille.de
> > 
> > 
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

Re: OpenCL GPU usage on autobuilders (Was: Bug#813262: python-biopython: FTBFS: ApplicationError: Non-zero return code 255 from 'phyml -i Phylip/interlaced2.phy -d aa')

[Andreas Tille]

Hi,

I just realised that the issue also happens on my local machine - so the
assumption that only autobuilders are affected is wrong.  I think I just
need to fix the dependencies for libhmsbeagle-dev.  Sorry for the noise

   Andreas.

On Sun, Jan 31, 2016 at 07:56:31AM +0100, Andreas Tille wrote:
> Hi,
> 
> On Sat, Jan 30, 2016 at 11:51:26PM +0100, Chris Lamb wrote:
> > Source: python-biopython
> > Version: 1.66+dfsg-1
> > Severity: serious
> > Justification: fails to build from source
> > ...
> >   ApplicationError: Non-zero return code 255 from 'phyml -i 
> > Phylip/interlaced2.phy -d aa', message 'beignet-opencl-icd: no supported 
> > GPU found, this is probably the wrong opencl-icd package for this hardware'
> > ...
> 
> this bug is caused by the change in libhmsbeagle-dev which is now using
> OpenCL which does not seem to work on the machine that is doing the
> build tests.  Any hint how that could be done properly?
> 
> Kind regards
> 
>   Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de

OpenCL GPU usage on autobuilders (Was: Bug#813262: python-biopython: FTBFS: ApplicationError: Non-zero return code 255 from 'phyml -i Phylip/interlaced2.phy -d aa')

[Andreas Tille]

Hi,

On Sat, Jan 30, 2016 at 11:51:26PM +0100, Chris Lamb wrote:
> Source: python-biopython
> Version: 1.66+dfsg-1
> Severity: serious
> Justification: fails to build from source
> ...
>   ApplicationError: Non-zero return code 255 from 'phyml -i 
> Phylip/interlaced2.phy -d aa', message 'beignet-opencl-icd: no supported GPU 
> found, this is probably the wrong opencl-icd package for this hardware'
> ...

this bug is caused by the change in libhmsbeagle-dev which is now using
OpenCL which does not seem to work on the machine that is doing the
build tests.  Any hint how that could be done properly?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Bug#812681: [help] Bug#812681: mira: FTBFS with flex >= 2.6]

[Andreas Tille]

Hi Jakub,

On Tue, Jan 26, 2016 at 05:12:26PM +0100, Jakub Wilk wrote:
> * Andreas Tille <andr...@an3as.eu>, 2016-01-25, 22:06:
> >sorry, I have no idea about fley and need help to fix this problem.
> 
> I think it's a bit premature to ask debian-mentors for help when your RC bug
> is 7 minutes old. What you could do instead is:
> 
> * Wait a bit longer. Perhaps one of the numerous co-maintainers knows how to
> fix the bug, but they all busy or asleep at the moment?

The thing is that I know my co-maintainers well enough regarding their
dense schedule (and knowledge about things like flex) that waiting
another 24 hours would not have changed anything.

> * Ask on the team's mailing list.

Receives the message via the bug e-mail anyway.

> * Ask upstream.

Yes, I might pick this option next time.
 
> (Not necessarily in that order.)
> 
> >exp_flexer.cc:766:9: error: no match for 'operator=' (operand types are 
> >'std::istream {aka std::basic_istream}' and 'std::istream* {aka 
> >std::basic_istream*}')
> >   yyin = & std::cin;
> >^
> 
> The problem is that exp_flexer.cc was not regenerated from the corresponding
> *.ll file at build time. Instead, the file included in the .orig.tar (which
> was generated by an older flex) was used.
> 
> Removing the pre-generated flex output fixed it for me:
> 
> find -name '*.ll' | sed -e 's/[.]ll$/.cc/' | xargs rm

Thanks a lot for your patience and help

Andreas. 

-- 
http://fam-tille.de

[help] Bug#812681: mira: FTBFS with flex >= 2.6]

[Andreas Tille]

Hi,

sorry, I have no idea about fley and need help to fix this problem.

Any hint would be welcome.

Kind regards

 Andreas.

- Forwarded message from Michael Tautschnig  -

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error. It should be noted
right away that this may be one of first attempts building with flex 2.6.
Notably, the flex NEWS says:

"C++ scanners now use references instead of pointers. See the manual for 
details."

[...]
g++ -DPACKAGE_NAME=\"mira\" -DPACKAGE_TARNAME=\"mira\" 
-DPACKAGE_VERSION=\"4.9.5_2\" -DPACKAGE_STRING=\"mira\ 4.9.5_2\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"mira\" 
-DVERSION=\"4.9.5_2\" -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 -DENABLE64=1 
-DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DYYTEXT_POINTER=1 -DSTDC_HEADERS=1 
-DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -Drestrict=__restrict -DHAVE_STDLIB_H=1 
-DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 
-DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DHAVE_STRFTIME=1 -DHAVE_MEMSET=1 
-DHAVE_FSEEKO=1 -DHAVE_ISBLANK=1 -DHAVE_BOOST=/\*\*/ -DHAVE_BOOST_THREAD=/\*\*/ 
-DHAVE_BOOST_REGEX=/\*\*/ -DHAVE_BOOST_SYSTEM=/\*\*/ 
-DHAVE_BOOST_FILESYSTEM=/\*\*/ -DHAVE_BOOST_IOSTREAMS=/\*\*/ -DHAVE_LIBRT=1 
-DHAVE_GZOFFSET=1 -DBOUNDTRACKFLAG=1 -DBUGTRACKFLAG=1 -I.  -I../../src  
-Wdate-time  -DPUBLICQUIET -DAJ_Linux64 -g -O0 -fstack-protector-strong 
-Wformat -Werror=format-security  -I/usr/include -O3 -funroll-loops -pthread 
-I/usr/include -I/usr/include -Werror=uninitialized -Werror=return-type 
-Werror=parentheses -Werror=unused-value -std=c++14 -c -o exp_flexer.o 
exp_flexer.cc
exp_flexer.cc: In member function 'virtual int EXPFlexLexer::yylex()':
exp_flexer.cc:766:9: error: no match for 'operator=' (operand types are 
'std::istream {aka std::basic_istream}' and 'std::istream* {aka 
std::basic_istream*}')
yyin = & std::cin;
 ^
In file included from /usr/include/c++/5/iostream:40:0,
 from exp_flexer.cc:96:
/usr/include/c++/5/istream:625:7: note: candidate: std::basic_istream<_CharT, 
_Traits>& std::basic_istream<_CharT, 
_Traits>::operator=(std::basic_istream<_CharT, _Traits>&&) [with _CharT = char; 
_Traits = std::char_traits]
   operator=(basic_istream&& __rhs)
   ^
/usr/include/c++/5/istream:625:7: note:   no known conversion for argument 1 
from 'std::istream* {aka std::basic_istream*}' to 
'std::basic_istream&&'
exp_flexer.cc:769:10: error: no match for 'operator=' (operand types are 
'std::ostream {aka std::basic_ostream}' and 'std::ostream* {aka 
std::basic_ostream*}')
yyout = & std::cout;
  ^
In file included from /usr/include/c++/5/iostream:39:0,
 from exp_flexer.cc:96:
/usr/include/c++/5/ostream:402:7: note: candidate: std::basic_ostream<_CharT, 
_Traits>& std::basic_ostream<_CharT, 
_Traits>::operator=(std::basic_ostream<_CharT, _Traits>&&) [with _CharT = char; 
_Traits = std::char_traits]
   operator=(basic_ostream&& __rhs)
   ^
/usr/include/c++/5/ostream:402:7: note:   no known conversion for argument 1 
from 'std::ostream* {aka std::basic_ostream*}' to 
'std::basic_ostream&&'
exp_flexer.cc:1260:44: error: cannot convert 'std::istream {aka 
std::basic_istream}' to 'std::istream* {aka std::basic_istream*}' 
in assignment
YY_CURRENT_BUFFER_LVALUE->yy_input_file = yyin;
^
In file included from /usr/include/c++/5/iostream:40:0,
 from exp_flexer.cc:96:
/usr/include/c++/5/istream: In constructor 
'EXPFlexLexer::EXPFlexLexer(std::istream*, std::ostream*)':
/usr/include/c++/5/istream:606:7: error: 'std::basic_istream<_CharT, 
_Traits>::basic_istream() [with _CharT = char; _Traits = 
std::char_traits]' is protected
   basic_istream()
   ^
exp_flexer.cc:1370:75: error: within this context
 yyFlexLexer::yyFlexLexer( std::istream* arg_yyin, std::ostream* arg_yyout )
   ^
In file included from /usr/include/c++/5/iostream:39:0,
 from exp_flexer.cc:96:
/usr/include/c++/5/ostream:384:7: error: 'std::basic_ostream<_CharT, 
_Traits>::basic_ostream() [with _CharT = char; _Traits = 
std::char_traits]' is protected
   basic_ostream()
   ^
exp_flexer.cc:1370:75: error: within this context
 yyFlexLexer::yyFlexLexer( std::istream* arg_yyin, std::ostream* arg_yyout )
   ^
exp_flexer.cc:1372:7: error: no match for 'operator=' (operand types are 
'std::istream {aka std::basic_istream}' and 'std::istream* {aka 
std::basic_istream*}')
  yyin = arg_yyin;
   ^
In file included from /usr/include/c++/5/iostream:40:0,
 from exp_flexer.cc:96:

Re: Failed to stop defining RPATH in libncl

[Andreas Tille]

On Mon, Jan 04, 2016 at 05:19:42PM +, Wookey wrote:
> +++ Andreas Tille [2016-01-04 16:19 +0100]:
> > On Mon, Jan 04, 2016 at 03:07:40PM +, Wookey wrote:
> > > > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter 
> > > > /usr/lib/x86_64-linux-gnu/n> > The brute force way to fix this is to 
> > > > use chrpath to remove the rpath
> > > from the binary at the end of the build.
> > 
> > This is what I have now.
> 
> OK. I used to discourage chrpath usage because it broke cross-builds
> (because it didn't understand foreign-arch binary elf formats), but
> chrpath has since become arch-agnostic so it doesn't really matter
> these days (except insofar as it's a workaround, rather than a proper
> cure, and thus unpleasing :-).

+1

Thanks for confirming that it became arch-agnostic and I can stop digging
into the build-system. :-)

Kind regards

  Andreas.

-- 
http://fam-tille.de

Failed to stop defining RPATH in libncl

[Andreas Tille]

Hi,

I'm trying to package libncl[1] but I failed to fight the following
lintian error:


E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter 
/usr/lib/x86_64-linux-gnu/ncl
N: 
N:The binary or shared library sets RPATH. This overrides the normal
N:library search path, possibly interfering with local policy and causing
N:problems for multilib, among other issues.
N:
N:The only time a binary or shared library in a Debian package should set
N:RPATH is if it is linked to private shared libraries in the same
N:package. In that case, place those private shared libraries in
N:/usr/lib/. Libraries used by binaries in other packages should
N:be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in
N:which case RPATH is unnecessary.
N:
N:To fix this problem, look for link lines like:
N:gcc test.o -o test -Wl,--rpath,/usr/local/lib
N:or
N:gcc test.o -o test -R/usr/local/lib
N:and remove the -Wl,--rpath or -R argument. You can also use the chrpath
N:utility to remove the RPATH.
N:
N:Refer to https://wiki.debian.org/RpathIssue for details.
N:
N:Severity: serious, Certainty: possible
N:
N:Check: binaries, Type: binary, udeb
N: 
E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NEXUSnormalizer 
/usr/lib/x86_64-linux-gnu/ncl
E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NEXUSvalidator 
/usr/lib/x86_64-linux-gnu/ncl


I deactivated my quilt patches and the override_dh_auto_configure since
nothing really helped.  Any hint would be welcome.

Kind regards

   Andreas.

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

-- 
http://fam-tille.de

Re: Failed to stop defining RPATH in libncl

[Andreas Tille]

Hi Gianfranco, 

thanks for your attempt to help.

On Mon, Jan 04, 2016 at 01:03:51PM +, Gianfranco Costamagna wrote:
> I think there is no way for a binary to pick something not in usr/lib or 
> usr/lib/{triplet}
> 
> unless you want to add a new ld.so.conf.d file
> cat /etc/ld.so.conf.d/*
> 
> (e.g. done by mesa libraries).

I admit the chrpath hint by Alec Leamas was sufficient to solve the rpath
issue.
 
> Anyhow, I fixed the packaging, and attached a patch to this email.
> 
> you should be able to directly git am it.
> 
> Please use some fresh packaging for your tools, the current packaging is 
> somewhat bad.

Well, I removed some cruft but I'd like to keep the d-shlibs thingy for
the moment since the packaging uncovers some potential bug in d-shlibs
which I'd like to track down.  (Believe it or not - I'm a fan of this
tool. ;-))

> If you want to fix the RPATH issue I guess you are forced to install the 
> shared libraries
> into usr/lib or usr/lib/{triplet}, because otherwise with no RPATH, and no ld 
> standard path
> the linker won't be able to find them.

Hmmm, the libraries are installed in usr/lib/{triplet} so I'm not sure
what you are talking exactly.  If git.d.o would be online I'd commit
the current status with cleaned up packaging and removed RPATH.

Thanks to all who tried to help

   Andreas.

-- 
http://fam-tille.de

Re: Failed to stop defining RPATH in libncl

[Andreas Tille]

On Mon, Jan 04, 2016 at 03:07:40PM +, Wookey wrote:
> > E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter 
> > /usr/lib/x86_64-linux-gnu/ncl
> > N: 
> > N:The binary or shared library sets RPATH. This overrides the normal
> > N:library search path, possibly interfering with local policy and 
> > causing
> > N:problems for multilib, among other issues.
> > N:
> > N:The only time a binary or shared library in a Debian package should 
> > set
> > N:RPATH is if it is linked to private shared libraries in the same
> > N:package. In that case, place those private shared libraries in
> > N:/usr/lib/. Libraries used by binaries in other packages 
> > should
> > N:be placed in /lib or /usr/lib as appropriate, with a proper SONAME, in
> > N:which case RPATH is unnecessary.
> 
> If this is just a library then it should be in
> 
> /usr/lib/. Only plugins that are used internally and never
> externally should be in /usr/lib//. And because this
> is not on the normal search path an rpath may be needed to load
> them. In this case the above lintian warning is not an error.

This .../ path is simply wrong and the libraries are not
installed to this place in the package.
 
> The brute force way to fix this is to use chrpath to remove the rpath
> from the binary at the end of the build.

This is what I have now.
 
> Better is to stop it being generated with 
> CMAKE: SKIP_BUILD_RPATH TRUE
> autotools: See https://wiki.debian.org/RpathIssue for details
> 
> (that whole page is useful - but maybe you read it and tried that stuff 
> already?)

Yes.  This is what I've tried but failed and was thus writing here.

In short: Brute force chrpath does the trick on my local Git repository.

Thanks anyway

 Andreas.


-- 
http://fam-tille.de

Please help (Was: Bug#808537: jellyfish: FTBFS: error: 'template class std::auto_ptr' is deprecated [-Werror=deprecated-declarations])

[Andreas Tille]

Hi,

I was hoping that Gert could provide any hint how he fixed #778005 but
he seems to be offline.  Any hint how to deal with his?

Kind regards

Andreas.

- Forwarded message from Andreas Tille <andr...@an3as.eu> -

Date: Sun, 20 Dec 2015 17:46:54 +0100
From: Andreas Tille <andr...@an3as.eu>
To: 808...@bugs.debian.org
Cc: Gert Wollny <gw.foss...@gmail.com>
Subject: Re: Bug#808537: jellyfish: FTBFS: error: 'template class 
std::auto_ptr' is deprecated [-Werror=deprecated-declarations]

Hi Gert,

I think you fixed the same issue in #778005 but it seems to be an
upstream fix and thus I can't simply sneak into the patches of the
packaging.  Could you gice some hint how to work around this?

Kind regards

   Andreas.

On Sun, Dec 20, 2015 at 02:06:16PM +, Chris West (Faux) wrote:
> Source: jellyfish
> Version: 2.2.4-1
> Severity: serious
> Justification: fails to build from source
> Tags: sid 
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> The package fails to build:
> 
> g++ -DHAVE_CONFIG_H -I.  -Wall -Wnon-virtual-dtor -I. -I./include -g -O3  
> -D_FORTIFY_SOURCE=2 -std=c++0x -g -O3 -Werror -std=c++0x -g -O2 
> -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:248:8: error: ‘template class 
> std::auto_ptr’ is deprecated [-Werror=deprecated-declarations]
>std::auto_ptr<jellyfish::dumper_t > dumper;
> ^
> In file included from /usr/include/c++/5/memory:81:0,
>  from sub_commands/count_main.cc:28:
> /usr/include/c++/5/bits/unique_ptr.h:49:28: note: declared here
>template class auto_ptr;
> ^
> cc1plus: all warnings being treated as errors
> Makefile:1615: recipe for target 'sub_commands/count_main.o' failed
> make[3]: *** [sub_commands/count_main.o] Error 1
> make[3]: Leaving directory '/jellyfish-2.2.4'
> 
> Full build log:
> https://reproducible.debian.net/rb-pkg/unstable/amd64/jellyfish.html
> 
> -- System Information:
> Debian Release: stretch/sid
> APT prefers unstable
> APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> ___
> 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

- End forwarded message -

-- 
http://fam-tille.de

Re: Please help (Was: Bug#808537: jellyfish: FTBFS: error: 'template class std::auto_ptr' is deprecated [-Werror=deprecated-declarations])

[Andreas Tille]

Hi Gert,

On Wed, Dec 23, 2015 at 06:46:28PM +0100, Gert Wollny wrote:
> > I was hoping that Gert could provide any hint how he fixed #778005
> > but he seems to be offline.  Any hint how to deal with his?
> 
> I was indeed AFK and will be a for few more hours. 

How were you able to respond without keyboard? ;-)
Very cool - thanks a lot!
 
> - Forwarded message from Andreas Tille <andr...@an3as.eu> -
> > Cc: Gert Wollny <gw.foss...@gmail.com>
> > Subject: Re: Bug#808537: jellyfish: FTBFS: error: 'template
> > class std::auto_ptr' is deprecated [-Werror=deprecated-declarations]
> 
> I'll take a look at the code later, but the problem is that when c++11
> is enabled (with g++5 the default I think), then std::auto_ptr is
> deprecated, hence there is a warning. But since someone decided to add
> the -Werror=deprecated-declarations compile flag this warning is
> propagated to an error. 
> 
> One fix is to remove the compile flag, another one replace
> std::auto_ptr with std::unique_ptr. 

I commited a patch but now one unit test is failing... :-(

Kind regards

   Andreas. 

-- 
http://fam-tille.de

cmake issue in libsbml: Cannot generate java documentation, please specify the Java_JAVADOC_JAR.

[Andreas Tille]

Hi,

I'm trying to fix libsbml bugs and while doing so upgrade to the latest
upstream version.  Since the original tarball needs to be stripped I
moved the packaging from SVN to Git[1] (so please do not try debcheckout
which does not lead to the latest packaging status).

Unfortunately my attempt is blocked by

...

CMake Error at docs/CMakeLists.txt:212 (message):
  Cannot generate java documentation, please specify the Java_JAVADOC_JAR.


-- Configuring incomplete, errors occurred!
...


even if I tried in debian/rules

export JDK_PATH=$(readlink -f /usr/bin/javac | sed "s:/bin/javac::")
export JAVA_INCLUDE_PATH=$(JDK_PATH)/include


as well as specifying

-DJDK_PATH:STRING=/usr/lib/jvm/default-java 
-DJAVA_INCLUDE_PATH:STRING=/usr/lib/jvm/default-java/include

to the cmake call.

Any help would be welcome.

Kind regards

   Andreas.


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

-- 
http://fam-tille.de

Re: cmake issue in libsbml: Cannot generate java documentation, please specify the Java_JAVADOC_JAR.

[Andreas Tille]

Hi Kevin,

On Thu, Dec 17, 2015 at 10:44:40PM +1100, Kevin Murray wrote:
> 
> I have pushed a possible fix to the branch 'daube/possible-cmake-fix'. I am 
> not
> sure of the overall effects, the build is taking ages on my laptop, but it 
> seems
> to have fixed the immediate error.

Thanks a lot for this first and very helpful step.  Following this
strategy I was even able to work around another issue with Java bindings
which was also solved by setting a variable accordingly.

Finally after 1-2 hours of building I went into

...
make[4]: Entering directory '/build/libsbml-5.12.0+dfsg/build'
[100%] Generate Java-API Documentation
/usr/bin/javac: error while loading shared libraries: libjli.so: cannot open 
shared object file: No such file or directory
docs/CMakeFiles/api_docs_java.dir/build.make:61: recipe for target 
'../docs/formatted/java-api/index.html' failed
make[4]: *** [../docs/formatted/java-api/index.html] Error 127
make[4]: Leaving directory '/build/libsbml-5.12.0+dfsg/build'
CMakeFiles/Makefile2:1123: recipe for target 
'docs/CMakeFiles/api_docs_java.dir/all' failed
make[3]: *** [docs/CMakeFiles/api_docs_java.dir/all] Error 2
make[3]: Leaving directory '/build/libsbml-5.12.0+dfsg/build'
...


When I trow the error message above in a web search it comes up with the
log of bug #548729 which says:


This is most likely a lack of /proc.  Some ld.so features require
/proc/self/exe.

$ readelf -d /usr/bin/java  | grep ORIGIN
 0x000f (RPATH)  Library rpath: 
[$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli]
 0x6ffb (FLAGS_1)Flags: ORIGIN

AFAIK, a mounted /proc is close to mandatory these days.  The error
message could be nicer, but this is a libc bug.


If I try inside the pbuilder chroot:

1|root@wr-linux01:/ # mount 

 
mount: failed to read mtab: No such file or directory
2|root@wr-linux01:/ # readelf -d /usr/bin/java  | grep ORIGIN
 0x000f (RPATH)  Library rpath: 
[$ORIGIN/../lib/amd64/jli:/usr/local/jre/lib/amd64/jli:$ORIGIN/../lib/amd64:/usr/local/lib/amd64:$ORIGIN/../jre/lib/amd64:/usr/local/jre/lib/amd64]


I can confirm that /proc is not mounted.  Any idea how to approach this
to finally build libsbml successfully (at least passing the step to
Generate Java-API Documentation?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: cmake issue in libsbml: Cannot generate java documentation, please specify the Java_JAVADOC_JAR.

[Andreas Tille]

Hi Gianfranco,

On Thu, Dec 17, 2015 at 05:45:19PM +, Gianfranco Costamagna wrote:
> I remember something ghc related
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787227
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773768

Seems to be the same consequence as I've drawn below.  I checked in the
pbuilder chroot

diff --git a/debian/rules b/debian/rules
index 8916f38..3fdf167 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,7 @@ endif
/bin/sh debian/bin/python_fix.sh
 
 override_dh_auto_build:
+   if mount | grep "^proc " ; then echo "proc mounted - fine"; else mount 
proc /proc -t proc ; fi
cd build ; make
cp NEWS.txt changelog



and I was able to make the api_java_doc target successfully.

Since I have not seen things like this in the ghc source I wonder if
this should be really the suggested solution to the problem.

Comments?

Kind regards

   Andreas.


> --------
> Gio 17/12/15, Andreas Tille <andr...@fam-tille.de> ha scritto:
> 
>  Oggetto: Re: cmake issue in libsbml: Cannot generate java documentation, 
> please specify the Java_JAVADOC_JAR.
>  A: "Debian Mentors List" <debian-mentors@lists.debian.org>
>  Cc: "Debian Med Packaging Team" 
> <debian-med-packag...@lists.alioth.debian.org>, "Ivo Maintz" <i...@maintz.de>
>  Data: Giovedì 17 dicembre 2015, 17:26
>  
>  Hi Kevin,
>  
>  On Thu, Dec 17, 2015 at 10:44:40PM +1100, Kevin Murray
>  wrote:
>  > 
>  > I have pushed a possible fix to the branch
>  'daube/possible-cmake-fix'. I am not
>  > sure of the overall effects, the build is taking ages
>  on my laptop, but it seems
>  > to have fixed the immediate error.
>  
>  Thanks a lot for this first and very helpful step. 
>  Following this
>  strategy I was even able to work around another issue with
>  Java bindings
>  which was also solved by setting a variable accordingly.
>  
>  Finally after 1-2 hours of building I went into
>  
>  ...
>  make[4]: Entering directory
>  '/build/libsbml-5.12.0+dfsg/build'
>  [100%] Generate Java-API Documentation
>  /usr/bin/javac: error while loading shared libraries:
>  libjli.so: cannot open shared object file: No such file or
>  directory
>  docs/CMakeFiles/api_docs_java.dir/build.make:61: recipe for
>  target '../docs/formatted/java-api/index.html' failed
>  make[4]: *** [../docs/formatted/java-api/index.html] Error
>  127
>  make[4]: Leaving directory
>  '/build/libsbml-5.12.0+dfsg/build'
>  CMakeFiles/Makefile2:1123: recipe for target
>  'docs/CMakeFiles/api_docs_java.dir/all' failed
>  make[3]: *** [docs/CMakeFiles/api_docs_java.dir/all] Error
>  2
>  make[3]: Leaving directory
>  '/build/libsbml-5.12.0+dfsg/build'
>  ...
>  
>  
>  When I trow the error message above in a web search it comes
>  up with the
>  log of bug #548729 which says:
>  
>  
>      This is most likely a lack of
>  /proc.  Some ld.so features require
>      /proc/self/exe.
>      
>      $ readelf -d /usr/bin/java  | grep
>  ORIGIN
>   0x000f
>  (RPATH)             
>  Library rpath:
>  [$ORIGIN/../lib/amd64/jli:$ORIGIN/../jre/lib/amd64/jli]
>   0x6ffb
>  (FLAGS_1)            Flags:
>  ORIGIN
>      
>      AFAIK, a mounted /proc is close to
>  mandatory these days.  The error
>      message could be nicer, but this is a
>  libc bug.
>  
>  
>  If I try inside the pbuilder chroot:
>  
>  1|root@wr-linux01:/ #
>  mount               
>                 
>                 
>                 
>                 
>                 
>                 
>                 
>                 
>                 
>                 
>        
>  mount: failed to read mtab: No such file or directory
>  2|root@wr-linux01:/ #
>  readelf -d /usr/bin/java  | grep ORIGIN
>   0x000f (RPATH)       
>        Library rpath:
>  
> [$ORIGIN/../lib/amd64/jli:/usr/local/jre/lib/amd64/jli:$ORIGIN/../lib/amd64:/usr/local/lib/amd64:$ORIGIN/../jre/lib/amd64:/usr/local/jre/lib/amd64]
>  
>  
>  I can confirm that /proc is not mounted.  Any idea how
>  to approach this
>  to finally build libsbml successfully (at least passing the
>  step to
>  Generate Java-API Documentation?
>  
>  Kind regards
>  
>         Andreas.
>  
>  -- 
>  http://fam-tille.de
>  
> 

-- 
http://fam-tille.de

Re: cmake issue in libsbml: Cannot generate java documentation, please specify the Java_JAVADOC_JAR.

[Andreas Tille]

Hi Jakub,

On Thu, Dec 17, 2015 at 11:34:53PM +0100, Jakub Wilk wrote:
> * Andreas Tille <andr...@an3as.eu>, 2015-12-17, 19:11:
> >override_dh_auto_build:
> >+   if mount | grep "^proc " ; then echo "proc mounted - fine"; else 
> >mount proc /proc -t proc ; fi
> 
> Well, you need root privileges to mount /proc, so doing it in debian/rules
> almost certainly won't work.
> 
> If /proc is not mounted in your build environment, then you need to fix the
> environment. There's nothing that can be done about it in debian/rules.

Right, the build-hook makes you root but probably the build itself is a
non-privileged user.

But *how* exactly can I ensure on my machine (and autobuilders!) that
/proc is mounted???


BTW, on a different build machine (running testing in contrast to the
machine some hours ago running stable) I get:


...
0 packages upgraded, 558 newly installed, 0 to remove and 0 not upgraded.
Need to get 146 MB/367 MB of archives. After unpacking 1183 MB will be used.
The following packages have unmet dependencies:
 libnet-ssleay-perl : Depends: perlapi-5.20.2 which is a virtual package and is 
not provided by any available package.

 libxml-libxml-perl : Depends: perlapi-5.20.2 which is a virtual package and is 
not provided by any available package.

 libxml-parser-perl : Depends: perlapi-5.20.2 which is a virtual package and is 
not provided by any available package.

 libhtml-parser-perl : Depends: perlapi-5.20.2 which is a virtual package and 
is not provided by any available package.

Unable to resolve dependencies!  Giving up...
...


This somehow sounds like #787530 but I have no idea how to fix this.

Seems I have opened a can of worms with this package. :-(

Kind regards

   Andreas.

 

-- 
http://fam-tille.de

Re: DNS fails in pbuilder

[Andreas Tille]

On Fri, Dec 11, 2015 at 03:10:23PM +0100, Andreas Tille wrote:
> On Fri, Dec 11, 2015 at 01:26:31PM +, Mattia Rizzolo wrote:
> > > I tried pbuilder 0.221.1 from testing and 0.221.3 from unstable.
> > 
> > Should be fixed by 0.221.2, are you sure it's still broken, because
> > several people confirmed me it's fixed...
> 
> I confirm that the problem persits in 0.221.3

Sorry, my workaround went inbetween!  Version 0.221.3 is fine again.

Thanks for fixing

   Andreas. 

-- 
http://fam-tille.de

Lintian leaves me with error when Build-Depending from qt5-default :-( (Was: C++ / Qt help for Ugene needed)

[Andreas Tille]

Hi,

On Thu, Dec 10, 2015 at 08:28:36PM +0100, Gert Wollny wrote:
> On Thu, 2015-12-10 at 14:07 +0100, Andreas Tille wrote:
> > I'd be really delighted if you get this built!
> 
> It should build now, at least here it just did in an freshly updated
> pbuilder environment. 

Thanks to Gert's and Gianfranco's help I made quite some progress.  Currenly
I'm left with a riddle about the role of qt5-default which is a metapackage
and lintian throws an error when Build-Depending from a metapackage.  So I
thought that would be simple and made sure that ugene would Build-Depend
from all of qt5-default's Dependencies which are

   qtbase5-dev, qtchooser

Since qtbase5-dev is in the Build-Depends anyway I simply did

   s/qt5-default/qtchooser/

in the current status of Git ... and ended up in:


...
dh_auto_configure -- UGENE_WITHOUT_NON_FREE=1
qmake -makefile -nocache "QMAKE_CFLAGS_RELEASE=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-D_FORTIFY_SOURCE=2" "QMAKE_CFLAGS_DEBUG=-g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_RELEASE=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2" 
"QMAKE_CXXFLAGS_DEBUG=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2" 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr UGENE_WITHOUT_NON_FREE=1
qmake: could not find a Qt installation of ''
dh_auto_configure: qmake -makefile -nocache QMAKE_CFLAGS_RELEASE=-g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 
-D_FORTIFY_SOURCE=2 QMAKE_CFLAGS_DEBUG=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
QMAKE_CXXFLAGS_RELEASE=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
QMAKE_CXXFLAGS_DEBUG=-g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2 
QMAKE_LFLAGS_RELEASE=-Wl,-z,relro QMAKE_LFLAGS_DEBUG=-Wl,-z,relro QMAKE_STRIP=: 
PREFIX=/usr UGENE_WITHOUT_NON_FREE=1 returned exit code 1
debian/rules:21: recipe for target 'override_dh_auto_configure' failed
make[1]: *** [override_dh_auto_configure] Error 2
make[1]: Leaving directory '/build/ugene-1.19.0+dfsg'


So what else might qt5-default do besides installing dependencies
to make qmake happy?  Should I simply override the lintian error?

Kind regards

Andreas.

-- 
http://fam-tille.de

DNS fails in pbuilder

[Andreas Tille]

Hi,

since one week I'm observing that when moving to different networks
pbuilder fails to resolve any host names.  I was able to cure it by
copying my local /etc/resolv.conf to
/var/cache/pbuilder/base.cow/etc/resolv.conf but in principle I do
not even understand how this could have worked before without any
such tricks in changing network environments.

Any clue how this worked and how I can get it working again?

I tried pbuilder 0.221.1 from testing and 0.221.3 from unstable.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: DNS fails in pbuilder

[Andreas Tille]

On Fri, Dec 11, 2015 at 01:26:31PM +, Mattia Rizzolo wrote:
> > I tried pbuilder 0.221.1 from testing and 0.221.3 from unstable.
> 
> Should be fixed by 0.221.2, are you sure it's still broken, because
> several people confirmed me it's fixed...

I confirm that the problem persits in 0.221.3

 Andreas.

-- 
http://fam-tille.de

C++ / Qt help for Ugene needed

[Andreas Tille]

Hi folks,

I tried to upgrade ugene to the new upstream package.  When doing so I
moved the packaging to Git[1].  Unfortunately I'm running into a build
error:


...
g++ -c -m64 -pipe -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -O2 -D_REENTRANT -Wall -W -fPIC 
-DQT_WEBKIT -DU2_DISTRIBUTION_INFO=sources -DUGENE_VERSION=1.19.0 -
DUGENE_MIN_VERSION_SQLITE=1.13.0 -DUGENE_MIN_VERSION_MYSQL=1.16.0 
-DUGENE_VER_MAJOR=1 -DUGENE_VER_MINOR=19 -DUGENE_VER_PATCH=0 -DUGENE_X86 
-DUGENE_DATA_DIR=\"/usr/share/ugene/data\" -DQT_DLL -DNDEBUG - 
DQT_FATAL_ASSERT -DBUILDING_U2GUI_DLL -DQT_NO_DEBUG -DQT_SCRIPT_LIB 
-DQT_SVG_LIB -DQT_SQL_LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -I. -I/  
usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui 
-I/usr/include/qt4/QtXml -I/usr/include/qt4/QtSql -I/usr/include/qt4/QtSvg 
-I/usr/include/qt4/QtScript -I/usr/include/qt4 -Isrc -I_tmp -I../../include 
-I../U2Private/src -I_tmp/moc/release -I_tmp/ui -o 
_tmp/obj/release/CreateDocumentFromTextDialogController.o 
src/util/CreateDocumentFromTextDialogController.cpp
src/util/CreateDocumentFromTextDialogController.cpp: In member function 
‘virtual void U2::CreateDocumentFromTextDialogController::accept()’:
src/util/CreateDocumentFromTextDialogController.cpp:110:95: error: ‘class 
QComboBox’ has no member named ‘currentData’
 Task *task = new CreateSequenceFromTextAndOpenViewTask(prepareSequences(), 
ui->formatBox->currentData().toString(), url);

   ^
Makefile.Release:1252: recipe for target 
'_tmp/obj/release/CreateDocumentFromTextDialogController.o' failed
make[3]: *** [_tmp/obj/release/CreateDocumentFromTextDialogController.o] Error 1
make[3]: Leaving directory 
'/home/tillea/debian-maintain/alioth/debian-med_git/build-area/ugene-1.19.0+dfsg/src/corelibs/U2Gui'


I'm afraid this is connected to some Qt migration issue but I'm totally
uneducated about Qt and C++ so any help would be welcome.

Kind regards

   Andreas.


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

-- 
http://fam-tille.de

Bug#805521: Fwd: Bug#805521: RFS: normaliz/3.0.0+ds-2 [FTBFS fix release]

[Andreas Tille]

Hi Jerome,

I get

E: libnormaliz0: postinst-must-call-ldconfig 
usr/lib/x86_64-linux-gnu/libnormaliz.so.3.0.0
N: 
N:The package installs shared libraries in a directory controlled by the
N:dynamic library loader. Therefore, the package must call "ldconfig" in
N:its postinst script.
N:
N:Refer to Debian Policy Manual section 8.1.1 (ldconfig) for details.
N:
N:Severity: serious, Certainty: certain
N:
N:Check: shared-libs, Type: binary, udeb
N: 


On Thu, Nov 19, 2015 at 06:49:43AM +0100, Jerome BENOIT wrote:
> 
> 
> 
>  Forwarded Message 
> Subject: Bug#805521: RFS: normaliz/3.0.0+ds-2 [FTBFS fix release]
> Resent-Date: Thu, 19 Nov 2015 05:45:02 +
> Resent-From: Jerome Benoit 
> Resent-To: debian-bugs-d...@lists.debian.org
> Resent-CC: Debian Mentors 
> Date: Thu, 19 Nov 2015 06:41:40 +0100
> From: Jerome Benoit 
> Reply-To: Jerome Benoit , 805...@bugs.debian.org
> To: Debian Bug Tracking System 
> 
> Package: sponsorship-requests
> Severity: normal
> 
> Dear Mentors,
> 
>   I am looking for a sponsor for my package normaliz that
>   I am maintaining on behalf of the Debian Science-Team.
> 
> Thanks,
> Jerome
> 
> -- System Information:
> Debian Release: Jessie*
>   APT prefers stable
>   APT policy: (990, 'stable'), (500, 'stable-updates')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (SMP w/4 CPU cores)
> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> 
> 
> 

-- 
http://fam-tille.de

Re: Bug#805521: Fwd: Bug#805521: RFS: normaliz/3.0.0+ds-2 [FTBFS fix release]

[Andreas Tille]

Ahh, sorry.  I was not building on my usual build machine ...

On Thu, Nov 19, 2015 at 05:57:07PM +0100, Jerome BENOIT wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hello Forum:
> 
> On 19/11/15 12:48, Jakub Wilk wrote:
> > * Andreas Tille <andr...@an3as.eu>, 2015-11-19, 10:32:
> >> I get
> >>
> >> E: libnormaliz0: postinst-must-call-ldconfig 
> >> usr/lib/x86_64-linux-gnu/libnormaliz.so.3.0.0
> > 
> > Is your Lintian up-to-date?
> > 
> 
> The lintian version on my box is v2.5.38~bpo8+1 , on my pbuilder environment 
> v2.5.38.1 .
> Besides, I have just build on a Debian porter ( partch , not to mention it): 
> everything
> is also fine there.
> 
> This sounds weird.
> 
> Please let me know if I can help further.
> 
> Thanks,
> Jerome
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJWTf9XAAoJEIC/w4IMSybjfmsH+wZ4wOjkNGs8Oy6OkJgEo2u9
> 717KKDRHrF3OkRst6RfUH7O1UU64qCmmDjG0bOUvMCzaODcM2BNFR2RnWS8vRufc
> CqeRjRFV52C/d/xxFKOLUrkNAC3hgQTVhDqDQWEWCv1XXF6Goc9oCsrUuPbbs+5F
> RXcATBPDQ4KVOnFw63RayTfbU2bjL9fqs2eE4DmB1rkeY2xxYYlP/g1Wi2CoF8hq
> y1mlPBFiiUaFjJEYuTzO1/iLiK6XmTsKC2W047VAEZz/stBPDWnjZ0CbPrtiI8/u
> 8ubdPZMbokswKNXURw8FfhB7CWEqkpDkV53sGk4MiFh+LOWrYVEuISoVs1sVjlY=
> =QU6Y
> -END PGP SIGNATURE-
> 

-- 
http://fam-tille.de

Bug#803674: latex not found in opengm

[Andreas Tille]

Hi Ghislain,

in the opengm build log I've found:

...
/usr/bin/doxygen /build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile
Warning: Tag `SYMBOL_CACHE_SIZE' at line 310 of file 
`/build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
Warning: Tag `SHOW_DIRECTORIES' at line 519 of file 
`/build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
Warning: Tag `HTML_ALIGN_MEMBERS' at line 908 of file 
`/build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
Warning: Tag `USE_INLINE_TREES' at line 1095 of file 
`/build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
Warning: Tag `XML_SCHEMA' at line 1347 of file 
`/build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
Warning: Tag `XML_DTD' at line 1353 of file 
`/build/opengm-2.3.6/obj-x86_64-linux-gnu/Doxyfile' has become obsolete.
 To avoid this warning please remove this line from your configuration 
file or upgrade it using "doxygen -u"
Warning: doxygen no longer ships with the FreeSans font.
You may want to clear or change DOT_FONTNAME.
Otherwise you run the risk that the wrong font is being used for dot generated 
graphs.
sh: 1: latex: not found
sh: 1: dvips: not found
...


Did you checked whether the documentation is properly built?

Moreover as far as Debian Med policy concerns all packages should be
by default

Priority: optional

I'm not sure about Debian Science policy but I think it is - or at least
it should be IMHO - the same. Do you have any reason to choose "extra"?

Finally there is an embedded JS copy:

W: libopengm-doc: embedded-javascript-library 
usr/share/doc/libopengm-doc/html/jquery.js please use libjs-jquery


Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#803674: latex not found in opengm

[Andreas Tille]

Hi Ghislain,

On Mon, Nov 02, 2015 at 08:29:42AM +, Ghislain Vaillant wrote:
> >
> >Did you checked whether the documentation is properly built?
> 
> Yes, although the -doc package only contains the HTML documentation. I
> checked it and it runs fine. I can add the pdf build if it is a blocker.

It s no blocker for me - just stumbled upon it and if you are aware of
this it is fine for me.
 
> >Moreover as far as Debian Med policy concerns all packages should be
> >by default
> >
> > Priority: optional
> >
> >I'm not sure about Debian Science policy but I think it is - or at least
> >it should be IMHO - the same. Do you have any reason to choose "extra"?
> 
> An artefact from `debmake`. Will correct that.

I recommend to not use debmake.  Debian Med provides a template which
creates way less work and leads to way less errors.

I'v pushed the change and will build + upload as per current state (if
you do not want me to wait for other changes.
 
> >Finally there is an embedded JS copy:
> >
> >W: libopengm-doc: embedded-javascript-library 
> >usr/share/doc/libopengm-doc/html/jquery.js please use libjs-jquery
> 
> Raised to me by Gianfranco. Also discussed in [1].
> 
> cat /usr/share/doc/doxygen/README.jquery
> 
> [...]
> It is not considered a problem for Doxygen or packages using Doxygen to
> embed jquery. In fact replacing the `jquery.js` file created by Doxygen
> likely results in broken documentation. Packages doing that are buggy.
> Lintian will have to learn that a `jquery.js` embedded by Doxygen is a
> normal thing.
> [...]
> 
> [1] https://lists.debian.org/debian-devel/2014/10/msg00774.html

OK.  No strong opinion about this.

Kind regards

   Andreas.
 

-- 
http://fam-tille.de

Re: Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute

[Andreas Tille]

On Fri, Oct 23, 2015 at 01:43:19AM +0200, Tomasz Buchert wrote:
> this is due to [1]. It seems that 'test_args' is a property.
> I didn't dig very deep, but the attached patch seems to fix this.

Thanks a lot - that worked

  Andreas.

-- 
http://fam-tille.de

Re: Help needed to build libhmsbeagle using OpenCL

[Andreas Tille]

Hi,

I have a totally different question about OpenCL:  Assume I have
successfully built it locally.  When checking the availability of
libhmsbeagle features beast-mcmc (which uses libhmsbeagle) provides a
check which in my case looks like:


$ java -jar /usr/share/beast-mcmc/beast.jar -beagle -beagle_info ...
Using BEAGLE library v2.1.2 for accelerated, parallel likelihood evaluation 
2009-2013, BEAGLE Working Group - http://beagle-lib.googlecode.com/
Citation: Ayres et al (2012) Systematic Biology 61: 170-173 | 
doi:10.1093/sysbio/syr100

BEAGLE resources available:
0 : CPU
Flags: PRECISION_SINGLE PRECISION_DOUBLE COMPUTATION_SYNCH EIGEN_REAL 
EIGEN_COMPLEX SCALING_MANUAL SCALING_AUTO SCALING_ALWAYS SCALERS_RAW 
SCALERS_LOG VECTOR_SSE VECTOR_NONE THREADING_NONE PROCESSOR_CPU FRAMEWORK_CPU

1 : Intel(R) HD Graphics IvyBridge GT1 (OpenCL 1.2 beignet 1.0.3)
Global memory (MB): 2048
Clock speed (Ghz): 1,00
Number of multiprocessors: 6
Flags: PRECISION_SINGLE COMPUTATION_SYNCH EIGEN_REAL EIGEN_COMPLEX 
SCALING_MANUAL SCALING_AUTO SCALING_ALWAYS SCALERS_RAW SCALERS_LOG VECTOR_NONE 
THREADING_NONE PROCESSOR_GPU FRAMEWORK_OPENCL


So the application sees the GPU via libhmsbeagle.

However, a mac user told me that it looks like:

> BEAGLE resources available:
>
> 0 : CPU
>
> Flags: PRECISION_SINGLE PRECISION_DOUBLE COMPUTATION_SYNCH
> EIGEN_REAL EIGEN_COMPLEX SCALING_MANUAL SCALING_AUTO SCALING_ALWAYS
> SCALERS_RAW SCALERS_LOG VECTOR_SSE VECTOR_NONE THREADING_NONE
> PROCESSOR_CPU FRAMEWORK_CPU
>
> 1 : Intel(R) Core(TM) i5-4258U CPU @ 2.40GHz (OpenCL 1.2 )
>
> Global memory (MB): 8192
>
> Clock speed (Ghz): 2,40
>
> Number of multiprocessors: 4
>
> Flags: PRECISION_SINGLE PRECISION_DOUBLE COMPUTATION_SYNCH
> EIGEN_REAL EIGEN_COMPLEX SCALING_MANUAL SCALING_AUTO SCALING_ALWAYS
> SCALERS_RAW SCALERS_LOG VECTOR_NONE THREADING_NONE PROCESSOR_CPU
> FRAMEWORK_OPENCL



> 2 : Iris (OpenCL 1.2 )
>
> Global memory (MB): 1536
>
> Clock speed (Ghz): 1,20
>
> Number of multiprocessors: 280
>
> Flags: PRECISION_SINGLE COMPUTATION_SYNCH EIGEN_REAL EIGEN_COMPLEX
> SCALING_MANUAL SCALING_AUTO SCALING_ALWAYS SCALERS_RAW SCALERS_LOG
> VECTOR_NONE THREADING_NONE PROCESSOR_GPU FRAMEWORK_OPENCL

So the way more important point here is the multiprocessor feature which
is actually wanted for beast-mcmc.  Any idea how to activate this?  I'm
afraid this is rather a question for upstream but may be somebody here
has some experience.

Kind regards

  Andreas.

On Wed, Oct 21, 2015 at 03:38:12PM +0100, Ghislain Vaillant wrote:
> >
> >OpenCL error: CL_DEVICE_NOT_FOUND from file , line 
> >118.
> >FAIL tinytest (exit status: 255)
> 
> The error comes from their GPU interface abstraction. At that point, it may
> be worth asking whether upstream have tested it with POCL. Chances are that
> they did test with Beignet (since it worked on your machine?) but not on
> POCL. It could also well be that POCL v0.10 is insufficient.
> 
> Ghis
> 
> 

-- 
http://fam-tille.de

Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute

[Andreas Tille]

Hi,

I have no idea why this package now fails to build but was building
before.  No helpful response from debian-python list so far.  I opened
an issue at Github but upstream needs time to reproduce and I hope that
this might be a know issue to others here on this list.

Any hint would be welcome

 Andreas.

- Forwarded message from "Chris West (Faux)" 
 -

Date: Mon, 19 Oct 2015 19:05:55 +0100
From: "Chris West (Faux)" 
To: Debian Bug Tracking System 
Subject: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set 
attribute
X-Debian-PR-Message: report 802354
X-Debian-PR-Package: src:python-matplotlib-venn
X-Debian-PR-Keywords: sid stretch
X-Debian-PR-Source: python-matplotlib-venn

Source: python-matplotlib-venn
Version: 0.11-1
Severity: serious
Justification: fails to build from source
Tags: sid stretch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

The package fails to build:

== 49 passed in 1.17 seconds ===
pybuild --test --test-pytest -i python{version} -p 3.4 --test 
--system=custom "--test-args=cp -a README.rst {home_dir}/build && cd 
{home_dir}/build && {interpreter} /python-matplotlib-venn-0.11/setup.py test && 
rm README.rst" --dir .
I: pybuild base:170: cp -a README.rst 
/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && cd 
/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && python3.4 
/python-matplotlib-venn-0.11/setup.py test && rm README.rst
running test
Traceback (most recent call last):
  File "/python-matplotlib-venn-0.11/setup.py", line 56, in 
entry_points=''
  File "/usr/lib/python3.4/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.4/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.4/distutils/dist.py", line 973, in run_command
cmd_obj.ensure_finalized()
  File "/usr/lib/python3.4/distutils/cmd.py", line 107, in ensure_finalized
self.finalize_options()
  File "/python-matplotlib-venn-0.11/setup.py", line 21, in finalize_options
self.test_args = []
AttributeError: can't set attribute
E: pybuild pybuild:262: test: plugin custom failed with: exit code=1: cp -a 
README.rst /python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && cd 
/python-matplotlib-venn-0.11/.pybuild/pythonX.Y_3.4/build && python3.4 
/python-matplotlib-venn-0.11/setup.py test && rm README.rst
dh_auto_test: pybuild --test --test-pytest -i python{version} -p 3.4 --test 
--system=custom --test-args=cp -a README.rst {home_dir}/build && cd 
{home_dir}/build && {interpreter} /python-matplotlib-venn-0.11/setup.py test && 
rm README.rst --dir . returned exit code 13
debian/rules:10: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 25

Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/python-matplotlib-venn.html

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

___
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



- End forwarded message -

-- 
http://fam-tille.de

Re: Help needed to build libhmsbeagle using OpenCL

[Andreas Tille]

Hi Ghislain,

On Wed, Oct 21, 2015 at 02:33:37PM +0100, Ghislain Vaillant wrote:
> Hi Andreas, my answer inline below

sure. ;-)
 
> >advantages when using OpenCL.  I personally do not have any experience
> >with OpenCL and simply added
> >
> > libpoclu-dev,
> > ocl-icd-opencl-dev
> >
> 
> The correct build dependency to build with any OpenCL environment is:
> 
> ocl-icd-opencl-dev | opencl-dev,
> 
> And for testing with any OpenCL ICD:
> 
> pocl-opencl-icd | opencl-icd

OK, I implemented this.
 
> Regarding solutions, you may want to just disable the subset of the test
> suite that requires OpenCL for now, or at least surround the execution of
> the OpenCL tests with OpenCL capability detection. Please have a look at the
> discussion here for a nice implementation [1].
> 
> [1] https://lists.debian.org/debian-mentors/2015/08/msg00081.html

Sounds sensible - so I implemented it as well.

Unfortunately this also did not worked:

diff --git a/debian/control b/debian/control
index 8ead827..c05aed6 100644
--- a/debian/control
+++ b/debian/control
@@ -15,9 +15,9 @@ Build-Depends: debhelper (>= 9),
dh-linktree,
libjs-jquery,
libpoclu-dev,
-   ocl-icd-opencl-dev,
-   beignet-dev,
-   mesa-opencl-icd
+   ocl-icd-opencl-dev | opencl-dev,
+   pocl-opencl-icd | opencl-icd,
+   clinfo
 Standards-Version: 3.9.6
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/libhmsbeagle.git
 Vcs-Git: git://anonscm.debian.org/debian-med/libhmsbeagle.git

...

# cat tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest/tinytest.log 

OpenCL error: CL_DEVICE_NOT_FOUND from file , line 118.
FAIL tinytest (exit status: 255)


Any further hints?

Kind regards

 Andreas.


-- 
http://fam-tille.de

Re: Help needed to build libhmsbeagle using OpenCL

[Andreas Tille]

On Wed, Oct 21, 2015 at 03:38:12PM +0100, Ghislain Vaillant wrote:
> ># cat tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest/tinytest.log
> >
> >OpenCL error: CL_DEVICE_NOT_FOUND from file , line 
> >118.
> >FAIL tinytest (exit status: 255)
> 
> The error comes from their GPU interface abstraction. At that point, it may
> be worth asking whether upstream have tested it with POCL. Chances are that
> they did test with Beignet (since it worked on your machine?) but not on
> POCL. It could also well be that POCL v0.10 is insufficient.

I submitted

https://github.com/beagle-dev/beagle-lib/issues/87

Kind regards

 Andreas.

-- 
http://fam-tille.de

Re: Bug#725434: Problems with gbp when $TMP != /tmp

[Andreas Tille]

On Tue, Oct 20, 2015 at 05:16:06PM +, Mattia Rizzolo wrote:
> > pbuilder:
> >   Installed: 0.215+nmu4~bpo8+1
> >   Candidate: 0.215+nmu4~bpo8+1
> 
> well, please `apt update` :)
> I uploaed 0.219~bpo8+1 2 days ago ^^

Installed - but I need the `chmod 777` part with this one ...

Kind regards

  Andreas.


-- 
http://fam-tille.de

Help needed to build libhmsbeagle using OpenCL

[Andreas Tille]

Hi,

I've got the hint that libhmsbeagle only expresses its real performance
advantages when using OpenCL.  I personally do not have any experience
with OpenCL and simply added

libpoclu-dev,
ocl-icd-opencl-dev

as Build-Depends as well as using the configure option
"--with-opencl=/usr/include/CL" in libhmsbeagle autoconf.

This builds so far but I'm running in a failure in the test suite.  The
build log says:

make  tinytest
make[4]: Entering directory 
'/tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest'
g++ -DHAVE_CONFIG_H -I. -I../../libhmsbeagle  -I../.. -I../.. 
-D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/java-7-openjdk-amd64/include 
-I/usr/lib/jvm/java-7-openjdk-amd64/include/linux  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -c -o tinytest.o 
tinytest.cpp
/bin/bash ../../libtool  --tag=CXX   --mode=link g++  -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -o 
tinytest tinytest.o ../../libhmsbeagle/libhmsbeagle.la -ldl 
libtool: link: g++ -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wl,-z -Wl,relro -o .libs/tinytest tinytest.o  
../../libhmsbeagle/.libs/libhmsbeagle.so -ldl
make[4]: Leaving directory 
'/tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest'
make  check-TESTS
make[4]: Entering directory 
'/tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest'
make[5]: Entering directory 
'/tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest'
FAIL: tinytest
make[6]: Entering directory 
'/tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest'
make[6]: Nothing to be done for 'all'.
make[6]: Leaving directory 
'/tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest'

Testsuite summary for libhmsbeagle 2.1.2

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

See examples/tinytest/test-suite.log
Please report to beagle-...@googlegroups.com

Makefile:696: recipe for target 'test-suite.log' failed


while examples/tinytest/test-suite.log looks like:


==
   libhmsbeagle 2.1.2: examples/tinytest/test-suite.log
==

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

.. contents:: :depth: 2

FAIL: tinytest
==


OpenCL error: Unknown error from file , line 111.


I found the following link

   https://groups.google.com/forum/#!topic/beast-users/vSxxJqL2zPc

with the hint to intel-opencl which translated to another Build-Depends

   beignet-dev

This enabled me to debuild on my local machine.  However, when building
using pbuilder I end up with


# cat tmp/buildd/libhmsbeagle-2.1.2+20150609/examples/tinytest/tinytest.log 
beignet-opencl-icd: no supported GPU found, this is probably the wrong 
opencl-icd package for this hardware
(If you have multiple ICDs installed and OpenCL works, you can ignore this 
message)

OpenCL error: CL_DEVICE_NOT_FOUND from file , line 118.
FAIL tinytest (exit status: 255)


I assume the reason is that the chroot environment does not see any
graphics hardware.  Does this mean I need to exclude this test (which
I actually considered quite helpful) or is there any trick to get the
test working even in a chroot?

Any hint is welcome

  Andreas.

-- 
http://fam-tille.de

Re: Bug#725434: Problems with gbp when $TMP != /tmp

[Andreas Tille]

Hi Mattia,

On Tue, Oct 20, 2015 at 04:18:55PM +, Mattia Rizzolo wrote:
> On Tue, Oct 20, 2015 at 03:07:55PM +0200, Andreas Tille wrote:
> > I'm obviously beaten by bug #725434 when trying to use gbp on a stable
> > box with libpam-tmpdir.  I followed the workaround and added a hook
> > script:
> > 
> > $ cat .pbuilder/D10tmp 
> > [ -n "$TMP" -a ! -d "$TMP" ] && mkdir -p "$TMP" || true
> > [ -n "$TMPDIR" -a ! -d "$TMPDIR" ] && mkdir -p "$TMPDIR" || true
> 
> umh, something tells me this is not enough: hooks are run as root, while
> the build is not, so the build user would not be able to write there.
> Currently the build username or user ID is not exported to the hooks, so
> the better you can do is to chmod 777 TMPDIR and TMP (programs using
> /tmp should be able to use that securely anyway...)

I can confirm that this works.
 
> > The interesting thing here is that while TMP=/tmp/user/0 this
> > dir is empty and the packaging is done in /tmp/buildd.  If I do
> 
> the directory where the package is kept and the build is done is
> hardcoded to /tmp/buildd/ till 0.216, where it was made configurable and
> moved to /build/.
> 
> JOOI, can you try with pbuilder from backports and see whether with the
> changed build place something different happen?

I forget to say that I'm just doing this:

$ apt-cache policy pbuilder
pbuilder:
  Installed: 0.215+nmu4~bpo8+1
  Candidate: 0.215+nmu4~bpo8+1
  Version table:
 *** 0.215+nmu4~bpo8+1 0
501 http://httpredir.debian.org/debian/ jessie-backports/main amd64 
Packages
100 /var/lib/dpkg/status
 0.215+nmu3 0
500 http://httpredir.debian.org/debian/ jessie/main amd64 Packages

> >   # cd /tmp/buildd/python-pyfaidx-0.4.2
> >   # dh_builddeb -O--buildsystem=pybuild
> > dpkg-deb: building package `python-pyfaidx' in 
> > `../python-pyfaidx_0.4.2-0~bpo8+1_all.deb'.
> > dpkg-deb: building package `python3-pyfaidx' in 
> > `../python3-pyfaidx_0.4.2-0~bpo8+1_all.deb'.
> > dpkg-deb: building package `python-pyfaidx-examples' in 
> > `../python-pyfaidx-examples_0.4.2-0~bpo8+1_all.deb'.
> > 
> > this obviously works fine.
> 
> yes, because you're building as root, which can write anywhere he likes
> :)
> 
> > So the problem is definitely created by gbp.
> 
> s/gbp/pbuilder/

If you think so...  At least it is pbuilder only if called by gbp.

Kind regards

  Andreas.


-- 
http://fam-tille.de

Problems with gbp when $TMP != /tmp

[Andreas Tille]

Hi,

I'm obviously beaten by bug #725434 when trying to use gbp on a stable
box with libpam-tmpdir.  I followed the workaround and added a hook
script:

$ cat .pbuilder/D10tmp 
#!/bin/bash
# Work around #725434
# example file to be used with --hookdir
#
#create $TMP and $TMPDIR

echo "***"
echo "* Use workaroud for bug #725434 and create*"
echo "*TMP=$TMP *"
echo "*TMPDIR=$TMPDIR   *"
echo "***"

[ -n "$TMP" -a ! -d "$TMP" ] && mkdir -p "$TMP" || true
[ -n "$TMPDIR" -a ! -d "$TMPDIR" ] && mkdir -p "$TMPDIR" || true


which left the following log entry

I: user script /var/cache/pbuilder/build/cow.101629/tmp/hooks/D10tmp starting
***
* Use workaroud for bug #725434 and create*
*TMP=/tmp/user/0  *
*TMPDIR=/tmp/user/0   *
***
I: user script /var/cache/pbuilder/build/cow.101629/tmp/hooks/D10tmp finished


and the problem described in the bug report is not occuring any more.
However, I get a very similar and most probably related problem way
later in the package build process:


   dh_md5sums -O--buildsystem=pybuild
   dh_builddeb -O--buildsystem=pybuild
dpkg-deb: building package `python-pyfaidx' in 
`../python-pyfaidx_0.4.2-0~bpo8+1_all.deb'.
dpkg-deb: error: failed to make temporary file (control member): Permission 
denied
dh_builddeb: dpkg-deb --build debian/python-pyfaidx .. returned exit code 2
dpkg-deb: building package `python3-pyfaidx' in 
`../python3-pyfaidx_0.4.2-0~bpo8+1_all.deb'.
dpkg-deb: error: failed to make temporary file (control member): Permission 
denied
dh_builddeb: dpkg-deb --build debian/python3-pyfaidx .. returned exit code 2
dpkg-deb: building package `python-pyfaidx-examples' in 
`../python-pyfaidx-examples_0.4.2-0~bpo8+1_all.deb'.
dpkg-deb: error: failed to make temporary file (control member): Permission 
denied
dh_builddeb: dpkg-deb --build debian/python-pyfaidx-examples .. returned exit 
code 2
debian/rules:10: recipe for target 'binary' failed
make: *** [binary] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
E: Failed autobuilding of package


The interesting thing here is that while TMP=/tmp/user/0 this
dir is empty and the packaging is done in /tmp/buildd.  If I do

  # cd /tmp/buildd/python-pyfaidx-0.4.2
  # dh_builddeb -O--buildsystem=pybuild
dpkg-deb: building package `python-pyfaidx' in 
`../python-pyfaidx_0.4.2-0~bpo8+1_all.deb'.
dpkg-deb: building package `python3-pyfaidx' in 
`../python3-pyfaidx_0.4.2-0~bpo8+1_all.deb'.
dpkg-deb: building package `python-pyfaidx-examples' in 
`../python-pyfaidx-examples_0.4.2-0~bpo8+1_all.deb'.

this obviously works fine.  (BTW, the package in question is in
git://anonscm.debian.org/debian-med/python-pyfaidx.git but this problem
exists for any package.)


I can very easily build the package when simply using the export-dir of
gbp cd to the build directory and simply use pdebuild.  So the problem
is definitely created by gbp.

Any clue?

Kind regards

 Andreas.


-- 
http://fam-tille.de

Re: Java problem when upgrading pixelmed

[Andreas Tille]

On Tue, Oct 06, 2015 at 10:36:56PM +0200, Emmanuel Bourg wrote:
> Le 06/10/2015 22:28, Andreas Tille a écrit :
> 
> > export JAVAVERSIONTARGETJARFILE=/usr/lib/jvm/default-java/jre/lib/rt.jar; 
> > javac -O -target 1.7 -source 1.7 -bootclasspath ${JAVAVERSIONTARGETJARFILE} 
> > -encoding "UTF8" -Xlint:   deprecation -XDignore.symbol.file \
> > -classpath 
> > ../../..:/usr/share/java/commons-compress.jar:/usr/share/java/commons-codec.jar:/usr/share/java/vecmath.jar:/usr/share/java/jai_imageio.jar:/usr/share/java/
> >   pixelmed_codec.jar \
> > -sourcepath ../../.. ImageEditUtilities.java
> > ImageEditUtilities.java:119: error: package com.pixelmed.codec.jpeg does 
> > not exist
> > 
> > com.pixelmed.codec.jpeg.Parse.parse(fbis,fbos,shapes);
> 
> I bet you are missing pixelmed_codec.jar which is likely to contain the
> com.pixelmed.codec.jpeg package according to its name:
> 
> http://www.dclunie.com/pixelmed/software/codec/20141206_current/

I think you've won your bet ;-) and I injected some packaging for
pixelmed-codec[1].  Unfortunately I'm not yet through all dependencies
since the build ends with:

...
SetCharacteristicsFromSummary.java:240: error: cannot find symbol
JsonReader jsonReader = Json.createReader(new 
FileReader(jsonfile));
^
  symbol:   class JsonReader
  location: class SetCharacteristicsFromSummary
SetCharacteristicsFromSummary.java:240: error: cannot find symbol
JsonReader jsonReader = Json.createReader(new 
FileReader(jsonfile));
^
  symbol:   variable Json
  location: class SetCharacteristicsFromSummary
SetCharacteristicsFromSummary.java:241: error: cannot find symbol
JsonObject obj = jsonReader.readObject();
^
  symbol:   class JsonObject
  location: class SetCharacteristicsFromSummary
SetCharacteristicsFromSummary.java:244: error: cannot find symbol
JsonObject functionalGroupEntries = 
(JsonObject)(obj.get(functionalGroupName));
^
  symbol:   class JsonObject
  location: class SetCharacteristicsFromSummary
SetCharacteristicsFromSummary.java:244: error: cannot find symbol
JsonObject functionalGroupEntries = 
(JsonObject)(obj.get(functionalGroupName));
 ^
  symbol:   class JsonObject
  location: class SetCharacteristicsFromSummary
37 errors
Makefile:43: recipe for target 'SetCharacteristicsFromSummary.class' failed
make[3]: *** [SetCharacteristicsFromSummary.class] Error 1
make[3]: Leaving directory 
'/home/andreas/debian-maintain/repack/pixelmed/pixelmed-20150917/com/pixelmed/apps'


The makefiles are refering to

   lib/additional/javax.json-api-1.0.jar

and it seems none of the json java classes are fitting this.

I remember times when the jar contents were listed in:

   http://ftp-master.debian.org/users/twerner/jar-content.txt.gz

But this does not seem to be updated any more.

Any further hints are welcome

 Andreas.

[1] svn://anonscm.debian.org/debian-med/trunk/packages/pixelmed-codec/trunk/

-- 
http://fam-tille.de

Re: Java problem when upgrading pixelmed

[Andreas Tille]

Hi,

On Thu, Oct 08, 2015 at 01:40:58PM +0200, Bas Couwenberg wrote:
> On 2015-10-08 13:28, Emmanuel Bourg wrote:
> >It looks like you need the new standard Java API for JSON processing
> >(JSR 353) [1], we haven't packaged it yet, but josm has a local copy (if
> >you search for 'package javax.json' on http://source.debian.net you can
> >quickly find the package containing the classes your are looking for).
> 
> Please don't rely on josm for the javax.json classes.

Is there any work ongoing for a separate javax.json package?

> Due to the difficulties getting JCS [0] and its dependencies [1] packaged,
> I've not been able to update to any of the newer JOSM upstream releases
> making the josm package increasingly irrelevant. And if I remain unable to
> get JCS packaged, I'll have josm removed from the archive before the freeze.

Uhmmm, it would be a shame if we would loose JOSM. :-(

Kind regards

  Andreas.

> [0] https://bugs.debian.org/783538
> [1] https://bugs.debian.org/792690

-- 
http://fam-tille.de

Java problem when upgrading pixelmed

[Andreas Tille]

Hi,

I tried to upgrade pixelmed[1] to the latest version (20150917 as per
trunk in SVN) but the build failed with

export JAVAVERSIONTARGETJARFILE=/usr/lib/jvm/default-java/jre/lib/rt.jar; javac 
-O -target 1.7 -source 1.7 -bootclasspath ${JAVAVERSIONTARGETJARFILE} -encoding 
"UTF8" -Xlint:   deprecation -XDignore.symbol.file \
-classpath 
../../..:/usr/share/java/commons-compress.jar:/usr/share/java/commons-codec.jar:/usr/share/java/vecmath.jar:/usr/share/java/jai_imageio.jar:/usr/share/java/
  pixelmed_codec.jar \
-sourcepath ../../.. ImageEditUtilities.java
ImageEditUtilities.java:119: error: package com.pixelmed.codec.jpeg does not 
exist

com.pixelmed.codec.jpeg.Parse.parse(fbis,fbos,shapes);
   ^
1 error
Makefile:66: recipe for target 'ImageEditUtilities.class' failed

Any help how to solve this would be appreciated.  I tried to address
this by debian/patches/imageio.patch

--- a/com/pixelmed/display/ImageEditUtilities.java
+++ b/com/pixelmed/display/ImageEditUtilities.java
@@ -26,6 +26,7 @@ import java.io.File;
 import java.io.FileNotFoundException;
 import java.io.FileOutputStream;
 import java.io.IOException;
+import javax.imageio.*;

 import java.util.Iterator;
 import java.util.Vector;


but this does not have any effect.

Kind regards

 Andreas.

[1] svn://anonscm.debian.org/debian-med/trunk/packages/pixelmed/trunk/

-- 
http://fam-tille.de