jquery.js from Doxygen in documentation, what to do about it

Dear all, I'm currently staring with packaging some software (initially intended for debian-med) and amongst these packages is a software library with its Doxygen created documentation. Doxygen created a jquery.js script that depends somehow on the options used to run the document creation

Re: jquery.js from Doxygen in documentation, what to do about it

On Fri, 2012-11-23 at 12:01 -0800, Russ Allbery wrote: P.S: The above isn't an approval for embedding yet another version of jquery in your package, I think it should be avoided as well if possible. Probably one of the options is to patch upstream source code so that it can work with the

Changelog entry for bug workaround but no real fix?

Dear all, a bug [1] was files against the the package (mia) I'm preparing that can not really be fixed within this package, because the actual bug [2] is in another, required package. Considering the ongoing freeze of wheezy, [2] may not be fixed soon, but I have a workaround in mia, that makes

Re: Packaging from scratch

Hello, Ultimately, when I manage to have a clean package, I will be looking for a sponsor. Would anyone here be interested in RNA-seq analysis and willing to help me ? I can not sponsor, and I have no idea about RNA sequencers et al, but your package might fit into the Next generation

Re: permission to write to /usr/local/share/packagename

On Sat, 2013-10-05 at 00:02 -0300, Beco wrote: On 4 October 2013 22:56, Beco r...@beco.cc wrote: Hi mentors, [snip] I suppose that is all I have to do. But myapp still tells me permission denied. I got it working using something I was trying to avoid. SGID. chmod g+s mytouch

Re: possible-gpl-code-linked-with-openssl

On Wed, 2013-10-16 at 10:36 -0400, The Wanderer wrote: I can see where this might not be enough to allow adding the license exception without an explicit statement from upstream, but at least to my eye, it does seem to contradict the notion that upstream did not link against [OpenSSL]. Maybe

Re: [Debian-med-packaging] Please help: sra-sdk

Hello Andreas, the attached patch eliminates the downloads and building of libbz2 and libz and uses the system versions. Building the packages now fails for different reasons (on wheezy): debian/rules override_dh_prep make[1]: Entering directory `/home/gerddie/src/sra-sdk' dh_prep -X

Re: [Debian-med-packaging] Please help: sra-sdk

that the other internal sra-sdk libraries will remain to be found there. Thanks for your hint anyway Andreas. On Tue, Oct 22, 2013 at 12:15:19AM +0200, Gert Wollny wrote: Hello Andreas, the attached patch eliminates the downloads and building of libbz2 and libz and uses

Re: Is it OK to have compile warnings

To directly answer your question, since I think everyone so far has told you that you should fix it, this answer from S/O [1] [...] [1] http://stackoverflow.com/questions/3614691/casting-to-void-doesnt-remove-warn-unused-result-error/3615000#3615000 One should note that the question on S/O

Re: [Debian-med-packaging] Bug#720681: (Further) help with C++ needed

Hello Andreas, The issue is described in the upstream tracker http://ball-trac.bioinf.uni-sb.de/ticket/520 The build system is quite complex, which makes it difficult to fix it without digging too much into it. As far as I can see there is some mixup between creating the files in

Re: [Debian-med-packaging] Bug#720681: Help with cmake needed (Was: Bug#720681: (Further) help with C++ needed)

Hello, it seems the attached patch solves the problem (Building at 95% way beyond where it failed before). Actually, it is commit 1e76c9 in the ball git repro https://bitbucket.org/ball/ball Cheers, Gert From 1e76c9cb1920e9176b725269985c7eb43126d188 Mon Sep 17 00:00:00 2001 From: Luis de

Re: [Debian-med-packaging] Bug#720681: Help with cmake needed (Was: Bug#720681: (Further) help with C++ needed)

Bad news is now compiling fails with: /home/wollny/Debian/ball/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart0.cpp: In member function 'virtual void sipDatasetControl::destroy()': /home/wollny/Debian/ball/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart0.cpp:2981:9: error:

Re: Checking build errors

Hi, I have access to a powerpc laptop and took the liberty to run the build. See the testlog below. Considering that some of the inputfiles seem to be binary, I would guess that this problem stems from powerpc (and mips?) being big-endian. hope that helps, Gert

Re: Checking build errors - endianess problem

one can either fix the code, or mask the big-endian archs in the control file. regards, Gert On Thu, 2014-01-23 at 12:39 +0100, Gert Wollny wrote: Hi, I have access to a powerpc laptop and took the liberty to run the build. See the testlog below. Considering that some of the inputfiles

Question about a licensing problem

Dear all, one of my colleagues, Oscar (in the CC) recently got a software paper accepted that proposes a Multivariate Bayesian Image Segmentation Tool that can be used for Brain MR segmentation. Our plan is to package this for Debian, but we have a licensing problem: The software makes use

Re: Question about a licensing problem

Hello, thanks for the answers. As those of Debian-med have seen, I went out to ask the authors about the licese change. As for all the other pointers, the way version 2.21 is written, I think rewriting the algorithm from scratch based on the original paper is probably easier that

Re: CMake multiarch installation

On Mon, 2014-05-05 at 16:06 +0200, Nico Schlömer wrote: Does anyone have hints about how Debian manages to slip in the x86_64-linux-gnu part in the library install path? You have to add INCLUDE(GNUInstallDirs) to the CMakeLists.txt and use the according variables in the install command. cf:

Re: Help for watch file needed

On Sun, 2014-06-29 at 15:05 +0200, Andreas Tille wrote: Hi Jakub On Sun, Jun 29, 2014 at 12:04:20PM +0200, Jakub Wilk wrote: You got it backwards. It should be: uversionmangle=s/-/./g No, I really want to substitute v2-0-1 to 2.0-1 as the tarball on the download page You could leave

Re: build flags handling

Hello Nico, On Tue, 2015-02-03 at 00:56 +0200, Nico Schlömer wrote: I recently came across a package [1] which ideally would like to handle its own build flags (adding `-O3 -ffast-math` for speed, for example). What is the Debian policy on this? It is up to the maintainer to set the

Re: usage of -mtune=core2 ? (Was: Bug#776812: vsearch: FTBFS on non-x86: uses non-portable flags)

Hello, On Mon, 2015-02-02 at 07:51 +0100, Andreas Tille wrote: Hi Mentors, It is very important to build vsearch with the maximum optimisation for speed and thus I wonder whether dropping this option is a good idea or whether I should enable it on i386 and amd64 (the question extends also

Re: arch optimation for debian packages (here: soundtouch)

On Mon, 2015-01-26 at 22:54 +0500, Andrey Rahmatullin wrote: On Mon, Jan 26, 2015 at 01:14:39PM +0100, Nico Schlömer wrote: You cannot unconditionally use instructions not supported by minimal CPUs in each architecture, this means no MMX in i386 and only SSE2 and earlier on amd64. You can

Re: [Debian-med-packaging] Cmake help for htqc needed

Hi, I've attached a patch that should do the trick. (I'm on a computer without the ssh-keys for Debian git write access). Explanation: The htqc authors might have used a version of cmake that interprets the CMAKE_CXX_FLAGS as a list, and Elements of lists in cmake are separated by ';'.

Re: Bug#795344: libmems-1.6-1: not properly linked to its dependencies

On 13.08.2015 18:17, Andreas Tille wrote: I confirm that this at least has some effect - unfortunately not the wanted one sinde the @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ placeholders remain unresolved and the $(DEPS_LIBS) variable remains empty. :_( After

Re: on detecting OpenCL compute capability

On Fri, 2015-08-07 at 14:54 +0100, Ghislain Vaillant wrote: On 07/08/15 13:07, Gert Wollny wrote: Hello Ghislain, On Fri, 2015-08-07 at 12:34 +0100, Ghislain Vaillant wrote: I have been packaging a few OpenCL libraries lately. For most of them, the test suite can only be run from

Re: on detecting OpenCL compute capability

Hello Ghislain, On Fri, 2015-08-07 at 12:34 +0100, Ghislain Vaillant wrote: I have been packaging a few OpenCL libraries lately. For most of them, the test suite can only be run from an OpenCL capable machine. Since OpenCL can also run on the CPU it should be possible to get the capability

Re: How to inject options only for intel architectures with cmake (Was: Bug#793344: hyphy: FTBFS on non-x86: unrecognized command line option '-msse3')

Hello Andreas, On the contrary users want to get the best performance from their recent processors I certainly can understand this ... Is there any better place to help upstream implementing it? This looks quite interesting: https://gcc.gnu.org/wiki/FunctionMultiVersioning It also

Re: [Debian-med-packaging] Bug#793344: How to inject options only for intel architectures with cmake (Was: Bug#793344: hyphy: FTBFS on non-x86: unrecognized command line option '-msse3')

It also seems to create the run-time decision manually. Of course I meant automatically. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive:

Re: How to inject options only for intel architectures with cmake (Was: Bug#793344: hyphy: FTBFS on non-x86: unrecognized command line option '-msse3')

On Thu, 2015-07-23 at 14:36 +0200, Andreas Tille wrote: Hi, considering the fact that SSE3 optimisation is really wanted on intel architectures how could the option be added only for those architectures that understand -msse3 option? You can do this: ### include(CheckCXXCompilerFlag)

Re: Fwd: Package cuba was rejected

Hi Igor, the key you used to sign the package is not included in the Debian maintainers keyring. The key used to sign the package must be from a Debian maintainer who has permission to upload the package, or a Debian developer. For details see here: http://mentors.debian.net/sponsors hope

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

Hello Andres, On Wed, 2015-12-23 at 21:22 +0100, Andreas Tille wrote: > How were you able to respond without keyboard? ;-) Everybody has a superpower ;) > I commited a patch but now one unit test is failing... :-( Actually, for me it builds without a test failure. (SID updated right now)

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

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

Re: Help with CMake linking Debian's LLVM libs

Am Dienstag, den 07.06.2016, 14:54 + schrieb Gianfranco Costamagna: > Hi, > > > > > $ ./debian/rules build > > which llvm version did upstream bundle? > > LLVM folks are known for breaking API between releases, so maybe just > you need a specific llvm version rather than the default one.

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

Hello Andres,  > 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

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

Hello Andreas,  Am Mittwoch, den 22.06.2016, 14:22 +0200 schrieb 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 >

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

Am Mittwoch, den 22.06.2016, 14:54 +0200 schrieb Gert Wollny: > 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" :) 

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

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

Re: use of deleted function boost::detail::stored_edge_property

Hello Corentin, the problem is that the class boost::detail::stored_edge_property<...> has the copy constructor deleted, because the default is a move constructor and no copy constructor is implemented (this is something new with C++11 and g++-5) As a result the instance of the class can

Re: use of deleted function boost::detail::stored_edge_property

Hello Corentin, On Thu, 2016-01-14 at 15:01 +0100, Corentin Desfarges wrote: > > Sadly, the framework FW4SPL has been designed to be compiled with > c++11... Another option to force the use of an older implementation code path could be to set one of the defines

Re: Packaging an apparently unreleased Git repository

On Thu, 2016-01-28 at 11:40 -0700, Sean Whitton wrote: > An alternative that is perhaps worth considering is the output of > git-describe(1). > This requires at least one tag, without any tags it returns: > git describe --tags > fatal: No names found, cannot describe anything. Best, Gert

Re: Package rebuild

Hello Octavio, On Wed, 2016-02-03 at 14:01 -0800, Octavio Alvarez wrote: > Is it possible to request a rebuild attempt of a package in a > particular architecture, from the same source, to check if now it > builds? See: https://release.debian.org/wanna-build.txt "give back" Hope that helps,

Re: Packaging an apparently unreleased Git repository

Hello Tiago, > Although you did suggested a pretty detailed version string, this is > really needed at all? > > [...] > > If you need to invent a version string, use the MMDD format > such as 20110429 as upstream version. [...] > > This approach is simpler, work as intended and is

Bug#814727: Latex not found

On Sun, 2016-02-14 at 21:35 +, Ghislain Vaillant wrote: > I have to say I only focused on the > HTML documentation, which gets successfully generated with the > existing doxygen settings. I am not sure whether pulling the extra > Latex dependency for generating the pdf version is worth it

Re: Help with new version of iqtree needed

Hello,  > _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. Actually, the compile command defines -D__SSE3, and

Re: Help with new version of iqtree needed

Hi Andreas,  I've update the sse3 patch to not enable sse3 and not define __SSE3, and added an sse2 code path to emulate the _mm_hadd_pd instruction where needed.  It compiles, and the alignment sequence test reports the same "failures "and "passed" like the completely unpatched version.

Re: Bug#818505: sortmerna FTBFS on !x86

On Sun, 2016-03-27 at 14:49 +0200, Adam Borowski wrote: >  > You're not allowed to use -msse2 on i386 either, unless for a code > path that's run conditionally on runtime. Actually, "not allowed" it not the right expression, "discouraged" would be correct. If upstream requires sse2 then not

Re: dbgsym package in d/control?

Hello Tim,  Am Freitag, den 22.04.2016, 13:37 +0200 schrieb Tim Dengel: >  > According to the wiki at https://wiki.debian.org/DebugPackage I > > need "no additional changes to your source package", There is indeed no need to change the source package.  > but I saw that the package openhpi

Re: Appropriate transition from iep to pyzo

Hello Ghislain,  >I wanted to get your opinion on how to best handle the transition > from iep to pyzo. I would like everyone currently using iep to > automatically transit to pyzo via a package update, so that I can > safely ask iep to be removed from the archive.>  I'd suggest method 2: 

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

Hello,  Am Montag, den 16.05.2016, 09:14 + schrieb Gianfranco Costamagna: > Hi, >  > > /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; > >  ^ >

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

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

Bug#832556: RFS: wvstreams/4.6.1-10 [QA, RC]

Package: sponsorship-requests Severity: important Dear mentors,   I am looking for a sponsor for the package "wvstreams"  * Package name: wvstreams    Version : 4.6.1-10    Upstream Author : Net Integration Technologies Inc. et al.   * URL :

Bug#830827: RFS: wvstreams/4.6.1-9 [QA, RC]

Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the package "wvstreams"  * Package name: wvstreams    Version : 4.6.1-9    Upstream Author : Net Integration Technologies Inc. et al.   * URL :

Bug#829707: RFS: cdrdao/1:1.2.3-3 [QA, RC]

Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the package "cdrdao"  * Package name: cdrdao    Version : 1:1.2.3-3    Upstream Author : Manuel Clos ,                      Denis Leroy

Bug#830595: RFS: fracplanet/0.4.0-4 [QA, RC]

Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for the package "fracplanet"  * Package name: fracplanet    Version : 0.4.0-4    Upstream Author : Tim Day  * URL : 

Bug#830595: closed by Gianfranco Costamagna <locutusofb...@debian.org> (Re: Bug#830595: RFS: fracplanet/0.4.0-4 [QA, RC])

Hello Gianfranco,  thanks for sponsoring.  > you also bumped std-version, I added the entry in changelog,  Well, since "cme fix dpkg-control" always bumps to the latest version, I didn't add this explicitly ...  Best,  Gert 

Re: Bug#828529: r-cran-openssl: FTBFS with openssl 1.1.0

Hello,  Am Donnerstag, den 27.10.2016, 08:56 +0200 schrieb Andreas Tille: > Hi, > > I can confirm this problem when trying to build against openssl 1.1: > > ... > gcc -std=gnu99 -I/usr/share/R/include -DNDEBUG  -fpic  -g -O2 > -fdebug-prefix-map=/build/r-base-3.3.1.20161024=.

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

Hello, I did some digging: > Maybe it's a bug in python-tz? Most likely: Pandas uses this code to get the time offset for the local time in tslib.pyx: cpdef _get_utcoffset(tzinfo, obj): try: return tzinfo._utcoffset except AttributeError: return

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

At second thought it might not be a bug in python-tz, but some undefined behavior that results from the pandas use of tz._utcoffset: >   tz = pytz.timezone('Asia/Tokyo') >   dt = datetime.datetime(2011,1,1) >   >   In[76]:  tz.utcoffset(dt) >   Out[76]: datetime.timedelta(0, 32400) > >   In

Re: How to make a shared lib recognized by debhelpers?

Am Montag, den 17.07.2017, 21:20 +0200 schrieb Ole Streicher: > How can I do a proper handling of the library here? I guess (I am not > an octave expert, however), that the name of the library shall not be > changed. One way to make dh_strip recognize files that are not in the typical name

Re: Nanopolish: gcc-7 issue solved, but immintrin.h missing on most architectures

Am Montag, den 18.09.2017, 13:54 +0200 schrieb Andreas Tille: > control: tags -1 help > > Hi, > > the gcc-7 issue of nanopolish described in latest upstream (0.8.1) > which is now in unstable but according to the build logs[1] on most > architecture the build fails with > > ... > cc -o

Re: [Debian-med-packaging] Bug#853568: No idea how to fix abs arguments in nanopolish

Am Donnerstag, den 31.08.2017, 21:00 -0700 schrieb Walter Landry: > Andreas Tille wrote: > > Hi, > > > > to fix bug #853568 I tried a patch (gcc-7.patch) to fix abs() > > arguments > > in nanopolish[1] but I have no idea how to deal with this: > > > > ... > > g++ -o

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

Am Montag, den 04.12.2017, 17:52 +0100 schrieb Andreas Tille: > Hi, > > I intend to package lamarc[1] and hit the following C++ issue: > > ... > g++ -DHAVE_CONFIG_H -I. -I./config   -Wdate-time -D_FORTIFY_SOURCE=2 > -DLAMARC_COMPILE_LINUX -DNDEBUG  -Wall -Wextra -Wno- > unused -I

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

Am Montag, den 04.12.2017, 21:53 +0100 schrieb Andreas Tille: > Hi Gert, > > thanks for your hint. > > On Mon, Dec 04, 2017 at 07:32:42PM +0100, Gert Wollny wrote: > > > > make_pair doesn't require the explicite type specification, i.e. > > the > > fo

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

Am Sonntag, den 10.12.2017, 11:44 +0100 schrieb Gert Wollny: > Am Sonntag, den 10.12.2017, 08:13 +0100 schrieb Andreas Tille: > > Hi again, > > > > On Mon, Dec 04, 2017 at 05:59:28PM +0100, Andreas Tille wrote: > > > some problems with gatb[1].  With the new

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

hout -Wformat [- > > Werror=format-security] > > cc1plus: error: -Wformat-security ignored without -Wformat [- > > Werror=format-security] > > I received another (unrelated) patch by Gert Wollny who told me that > he can not reproduce the issue above.  I refreshed by cow

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

Am Sonntag, den 10.12.2017, 11:54 +0100 schrieb Gert Wollny: > Am Sonntag, den 10.12.2017, 11:44 +0100 schrieb Gert Wollny: > > Am Sonntag, den 10.12.2017, 08:13 +0100 schrieb Andreas Tille: > > > Hi again, > > > > > > On Mon, Dec 04, 2017 at 05:59:28PM +010

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

Am Mittwoch, den 25.10.2017, 16:52 +0200 schrieb Andreas Tille: > Hi, > > I try to package seqtools[1] which originally contained a code copy > of jsoncpp which I removed.  Unfortunately the build fails with the > Debian packaged jsoncpp and I'm lacking the necessary C++ knowledge > to get this

Re: [Debian-med-packaging] Trying to get rid of code copy of jsoncpp in seqtools

Hi Andreas, Am Mittwoch, den 25.10.2017, 20:56 +0200 schrieb Andreas Tille: > I admit I manually injected the -I option but there are probably > some missings.  I'll happily leave it for you since I'm a bit > occupied by other (mainly real life) stuff. Changes pushed, it builds now. I leave the

Re: [Debian-med-packaging] C++ help needed for yellyfish: "error: catching polymorphic type"

Am Montag, den 03.09.2018, 09:18 +0200 schrieb Andreas Tille: > Hi, > > I'm trying to build the latest version of jellyfish which I pushed to > Salsa[1]. Unfortunately I'm running into You can just catch by reference catch(MergeError& e) This is the better approach anyway: