Re: Aw: Fwd: pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED
Hi Steffen, I refreshed now - here is the thread: https://lists.debian.org/debian-devel-announce/2012/09/msg8.html I am also not sure if Andreas has done it already or not. Anyway, thanks a lot. Alex On 01/07/2014 08:19 AM, Steffen Möller wrote: Hi Alex, the Debian Maintainer scheme has seen a change such that one needs to explicitly allow every individual uploader - separately from the package upload. I presume this package to have not been on the radar before. I can address this ... back home in a couple of hours. Steffen *Gesendet:* Montag, 06. Januar 2014 um 16:45 Uhr *Von:* Alex Mestiashvili a...@biotec.tu-dresden.de *An:* Debian Med Project List debian-med@lists.debian.org *Betreff:* Fwd: pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED happy New Year to All Debian Med folks :) I wanted to upload the new release of pycorrfit, but it seems that I don't have permission for that. Do you know if I will be able to do it after the previous one is migrated to testing, or do I need to ask the permission in a some special way? Actually I tried to upload the second version 0.8.1 shortly after the 0.8.0-2~beta-2, but before I noticed the reject... So most probably the 0.8.1 will be rejected too. Thank you, Alex Original Message Subject:pycorrfit_0.8.0-2~beta-2_amd64.changes REJECTED Date: Mon, 06 Jan 2014 15:25:43 + From: Debian FTP Masters ftpmas...@ftp-master.debian.org To: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org, Alexandre Mestiashvili a...@biotec.tu-dresden.de ACL dm: not allowed to upload source package 'pycorrfit' === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
Re: I would like to submit a package to debian-med
Hi Andreas, On Mon, Jan 6, 2014 at 3:37 PM, Andreas Tille andr...@an3as.eu wrote: Hi Jorge, please stick to open discussion on Debian Med list. I guess you will not mind if I full quote your prer-technical, non-personal mail. No problem. Gmail defaults to reply instead of reply all... On Mon, Jan 06, 2014 at 11:48:21AM +, Jorge Sebastião Soares wrote: I checked the Git repository and for some strange reason the build totally fails because of removed files from upstream source. What happens on your side when you do some git-buildpackage ? When I run git-buildpackage I get this: js21@builder:~/build/snp-sites_1$ git-buildpackage --git-ignore-new dh clean --with autoreconf dh_testdir dh_auto_clean dh_autoreconf_clean dh_clean dpkg-buildpackage -rfakeroot -D -us -uc -i -I dpkg-buildpackage: source package snp-sites dpkg-buildpackage: source version 1-1 dpkg-buildpackage: source changed by Jorge Soares j...@sanger.ac.uk dpkg-source -i -I --before-build snp-sites_1 dpkg-buildpackage: host architecture amd64 dpkg-checkbuilddeps: Unmet build dependencies: docbook dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed gbp:error: Couldn't run 'debuild -i -I': debuild -i -I returned 29 Hmmm, this is just an unmet build depends which is strange since it should not be needed for the clean target. I have managed to build the package with: git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid --git-ignore-new On my side I get ... dh_clean dpkg-source -i.git -I.git -b snp-sites-1 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building snp-sites using existing ./snp-sites_1.orig.tar.gz dpkg-source: warning: ignoring deletion of file Makefile.in dpkg-source: warning: ignoring deletion of file ltmain.sh dpkg-source: warning: ignoring deletion of file install-sh ... dpkg-source: warning: ignoring deletion of file autom4te.cache/output.0 dpkg-source: warning: file snp-sites-1/src/Makefile.am has no final newline (either original or modified version) dpkg-source: warning: file snp-sites-1/src/Makefile.am has no final newline (either original or modified version) dpkg-source: warning: file snp-sites-1/src/vcf.h has no final newline (either original or modified version) dpkg-source: info: local changes detected, the modified files are: snp-sites-1/LICENSE snp-sites-1/Makefile.am snp-sites-1/configure.ac snp-sites-1/snp-sites.txt snp-sites-1/src/Makefile.am ... snp-sites-1/tests/helper-methods.c snp-sites-1/tests/helper-methods.h snp-sites-1/tests/run-all-tests.c dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/snp-sites_1-1.diff.R6uDKg dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -i.git -I.git -b snp-sites-1 gave error exit status 2 gbp:error: Couldn't run '~/bin/git-pbuilder': ~/bin/git-pbuilder returned 2 It seems the clean target is totally broken or the upstream tarball is somehow wrong. I never have faced such a problem before. What happens if you rename the original tarball to: snp-sites_1? Also when I try a plain pdebuild the process ends in ... dh_install cp: cannot stat 'debian/tmp/usr/bin/snp-sites': No such file or directory dh_install: cp -a debian/tmp/usr/bin/snp-sites debian/snp-sites//usr/bin/ returned exit code 1 This is odd. I have been running pbuilder this way: pdebuild --architecture amd64 --buildresult /home/js21/build_result --pbuilderroot sudo DIST=unstable ARCH=amd64 And it finishes no problem. This also results in problems for me (well, I just use plain pdebuild and have set the variables in ~/.pbuilderrc as suggested in Debian Med policy. It also shows something very similar to git-buildpackage with in the end: ... snp-sites_nogit/tests/check-snp-sites.h snp-sites_nogit/tests/helper-methods.c snp-sites_nogit/tests/helper-methods.h snp-sites_nogit/tests/run-all-tests.c dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/snp-sites_1-1.diff.dmnSDi dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -i.svn -I.svn -b snp-sites_nogit gave error exit status 2 So it seems that the upstream tarball is definitely not what pdebuild or git-buildpackage are expecting. It would help if you could explain how you created the snp-sites_1.orig.tar.gz tarball which is not really available from the upstream site. I simply get a fresh git checkout of the snp_sites git project. Next I rename the snp_sites directory to snp-sites_1. Then I simply tar cvzf
Re: I would like to submit a package to debian-med
Hi Jorge, On Tue, Jan 07, 2014 at 11:04:39AM +, Jorge Sebastião Soares wrote: Gmail defaults to reply instead of reply all... If you write to Debian mailing lists people will even tell you that you should only reply to the list and not to the poster. For sure we are tolerant to newbies ... but in principle I do not need another copy of a mail in my inbox. :-) aborting dpkg-buildpackage: warning: (Use -d flag to override.) debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc -i -I failed gbp:error: Couldn't run 'debuild -i -I': debuild -i -I returned 29 Hmmm, this is just an unmet build depends which is strange since it should not be needed for the clean target. I have managed to build the package with: git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid --git-ignore-new BTW, there is no need to explicit these options since all except the last one are default and the last one is redundant for a fresh pull without changes. It seems the clean target is totally broken or the upstream tarball is somehow wrong. I never have faced such a problem before. What happens if you rename the original tarball to: snp-sites_1? You mean to rename the directory, not the tarball, right? Dpkg-buildsource is clever enough to deal with this automatically. The point is that the files are *really* missing in the master branch while they are inside upstream branch. You should not change the upstream files in the master branch but just add the debian/ dir. Somehow the repository is mixed up - and I really have no idea why it would build at your side. What happens if you clone from scratch and try git-buildpackage? So it seems that the upstream tarball is definitely not what pdebuild or git-buildpackage are expecting. It is rather that the *content* of the directory is different from the tarball and this is hat the build log is telling you. I think so. You should not simply invent a version number if upstream does not provide versioned tarballs. You should ask upstream for doing proper tags for a release since we can not be sure that if upstream does some changes before a final 1 (or 1.0??) release we will have identical tarballs when doing a later checkout. I'm not exactly inventing, but I get your point. Yes - I wrote inventing because your internal knowledge is in advance to what outsiders can really see. At this point, version 1 is the only public version. I'll see what I can do to properly tag the snp-sites code. Just advise (or if you have commit permission to upstream do it yourself) to tag the upstream repository with `git tag 1` (or `git tag 1.0` which would be more convinient tagging). Also, should I add the debian folder to the upstream git project? Oh nooo. ;-) We are *really* happy that there is no such debian/ dir since in the past we had to deal with wrong / broken / outdated packaging stuff in such dirs and we regularly advise upstream to delete this if possible. Sounds sensible. I just had to ask. :) Asking is perfectly fine. I have dropped the git project entirely and have recreated it. So, can you tell me... If I'd tag the snp-sites project with version 1.0, would the tag be appended to the package name? And would it conform to the Debian standard? If I were you I would wait until upstream is tagged properly. Once this is done do $ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: https://github.com/sanger-pathogens/snp_sites/tags /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz -- Found the following matching hrefs: /sanger-pathogens/snp_sites/archive/0.1.tar.gz Newest version on remote site is 0.1, local version is 1 = remote site does not even have current version -- Scan finished If this is reporting 1 (or 1.0) you can do `uscan --force-download` which creates a valid and properly named tarball. Once you have this tarball you can import it using git import-orig --pristine-tar as it is written in our policy document and later simply add the debian/ dir. This workflow usually leads to a properly buildable repository. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107113459.gh6...@an3as.eu
Re: I would like to submit a package to debian-med
Hey Andreas, On Tue, Jan 7, 2014 at 11:34 AM, Andreas Tille andr...@an3as.eu wrote: If you write to Debian mailing lists people will even tell you that you should only reply to the list and not to the poster. For sure we are tolerant to newbies ... but in principle I do not need another copy of a mail in my inbox. :-) Fair enough. This is what I should have done in the first place. Sorted now. I have managed to build the package with: git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid --git-ignore-new BTW, there is no need to explicit these options since all except the last one are default and the last one is redundant for a fresh pull without changes. Cool. There's a lot to read and lots of tools for the same sort of purpose. I'm getting to grips with it... What happens if you rename the original tarball to: snp-sites_1? You mean to rename the directory, not the tarball, right? Dpkg-buildsource is clever enough to deal with this automatically. The point is that the files are *really* missing in the master branch while they are inside upstream branch. You should not change the upstream files in the master branch but just add the debian/ dir. Somehow the repository is mixed up - and I really have no idea why it would build at your side. What happens if you clone from scratch and try git-buildpackage? I have not tried this. I will try it now and report back. Just to be clear, cloning from scratch from the git snp_sites project, not from the debian git project, right? So it seems that the upstream tarball is definitely not what pdebuild or git-buildpackage are expecting. It is rather that the *content* of the directory is different from the tarball and this is hat the build log is telling you. I understand. I'm not exactly inventing, but I get your point. Yes - I wrote inventing because your internal knowledge is in advance to what outsiders can really see. Sure. :) At this point, version 1 is the only public version. I'll see what I can do to properly tag the snp-sites code. Just advise (or if you have commit permission to upstream do it yourself) to tag the upstream repository with `git tag 1` (or `git tag 1.0` which would be more convinient tagging). I will do this now. I do have commit permission. I have dropped the git project entirely and have recreated it. So, can you tell me... If I'd tag the snp-sites project with version 1.0, would the tag be appended to the package name? And would it conform to the Debian standard? If I were you I would wait until upstream is tagged properly. Once this is done do $ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: https://github.com/sanger-pathogens/snp_sites/tags /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz -- Found the following matching hrefs: /sanger-pathogens/snp_sites/archive/0.1.tar.gz Newest version on remote site is 0.1, local version is 1 = remote site does not even have current version -- Scan finished If this is reporting 1 (or 1.0) you can do `uscan --force-download` which creates a valid and properly named tarball. Once you have this tarball you can import it using git import-orig --pristine-tar as it is written in our policy document and later simply add the debian/ dir. This workflow usually leads to a properly buildable repository. Brilliant! Thanks Andreas. I will do this now. Kind regards, Jorge
Re: I would like to submit a package to debian-med
Hi Jorge, On Tue, Jan 07, 2014 at 12:01:42PM +, Jorge Sebastião Soares wrote: If you write to Debian mailing lists people will even tell you that you should only reply to the list and not to the poster. For sure we are tolerant to newbies ... but in principle I do not need another copy of a mail in my inbox. :-) Fair enough. This is what I should have done in the first place. Sorted now. :-) I have managed to build the package with: git-buildpackage --git-pbuilder --git-arch=amd64 --git-dist=sid --git-ignore-new BTW, there is no need to explicit these options since all except the last one are default and the last one is redundant for a fresh pull without changes. Cool. There's a lot to read and lots of tools for the same sort of purpose. I'm getting to grips with it... Yep. In general I'm personally very bad in remembering options and in case there are really some options needed in close to all cases you can specify these in configuration files. These 'musts' are mentioned in the Debian Med team policy document and you only need git-buildpackage [--git-ignore-new] You mean to rename the directory, not the tarball, right? Dpkg-buildsource is clever enough to deal with this automatically. The point is that the files are *really* missing in the master branch while they are inside upstream branch. You should not change the upstream files in the master branch but just add the debian/ dir. Somehow the repository is mixed up - and I really have no idea why it would build at your side. What happens if you clone from scratch and try git-buildpackage? I have not tried this. I will try it now and report back. Just to be clear, cloning from scratch from the git snp_sites project, not from the debian git project, right? What I meant was: gbp-clone ssh://git.debian.org/git/debian-med/snp-sites.git cd snp-sites git-buildpackage If this would work on your side I would be quite astonished. In case you might realise some differences to your local clone this might explain why it works for you. So it seems that the upstream tarball is definitely not what pdebuild or git-buildpackage are expecting. It is rather that the *content* of the directory is different from the tarball and this is hat the build log is telling you. I understand. I'm not exactly inventing, but I get your point. Yes - I wrote inventing because your internal knowledge is in advance to what outsiders can really see. Sure. :) At this point, version 1 is the only public version. I'll see what I can do to properly tag the snp-sites code. Just advise (or if you have commit permission to upstream do it yourself) to tag the upstream repository with `git tag 1` (or `git tag 1.0` which would be more convinient tagging). I will do this now. I do have commit permission. That's good. I have dropped the git project entirely and have recreated it. So, can you tell me... If I'd tag the snp-sites project with version 1.0, would the tag be appended to the package name? And would it conform to the Debian standard? If I were you I would wait until upstream is tagged properly. Once this is done do $ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: https://github.com/sanger-pathogens/snp_sites/tags /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz -- Found the following matching hrefs: /sanger-pathogens/snp_sites/archive/0.1.tar.gz Newest version on remote site is 0.1, local version is 1 = remote site does not even have current version -- Scan finished If this is reporting 1 (or 1.0) you can do `uscan --force-download` which creates a valid and properly named tarball. Once you have this tarball you can import it using git import-orig --pristine-tar as it is written in our policy document and later simply add the debian/ dir. This workflow usually leads to a properly buildable repository. Brilliant! Thanks Andreas. I will do this now. Just let us know in case you might face more stumbling stones. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107132634.gj6...@an3as.eu
Re: I would like to submit a package to debian-med
Hey Andreas, On Tue, Jan 7, 2014 at 12:01 PM, Jorge Sebastião Soares j.s.soa...@gmail.com wrote: On Tue, Jan 7, 2014 at 11:34 AM, Andreas Tille andr...@an3as.eu wrote: If I were you I would wait until upstream is tagged properly. Once this is done do $ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: https://github.com/sanger-pathogens/snp_sites/tags /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz -- Found the following matching hrefs: /sanger-pathogens/snp_sites/archive/0.1.tar.gz Newest version on remote site is 0.1, local version is 1 = remote site does not even have current version -- Scan finished If this is reporting 1 (or 1.0) you can do `uscan --force-download` which creates a valid and properly named tarball. Once you have this tarball you can import it using git import-orig --pristine-tar as it is written in our policy document and later simply add the debian/ dir. This workflow usually leads to a properly buildable repository. I've done all of this. Before I could import the pristine tar I had to: git branch upstream Then I was able to import the original tar ball that was created with uscan. Running git-buildpackage I get this: js21@builder:~/clean_build/snp_sites$ git-buildpackage --git-ignore-new dh clean --with autoreconf dh_testdir dh_auto_clean dh_autoreconf_clean dh_clean fatal: Not a valid object name upstream/1 I can't seem to find where the problem lies. Have you come across this before? Regards, Jorge
Re: I would like to submit a package to debian-med
Hi Jorge, On Tue, Jan 07, 2014 at 01:28:06PM +, Jorge Sebastião Soares wrote: $ uscan --verbose --report -- Scanning for watchfiles in . -- Found watchfile in ./debian -- In debian/watch, processing watchfile line: https://github.com/sanger-pathogens/snp_sites/tags /sanger-pathogens/snp_sites/archive/([.\d]+)\.tar\.gz -- Found the following matching hrefs: /sanger-pathogens/snp_sites/archive/0.1.tar.gz Newest version on remote site is 0.1, local version is 1 = remote site does not even have current version -- Scan finished If this is reporting 1 (or 1.0) you can do `uscan --force-download` which creates a valid and properly named tarball. Once you have this tarball you can import it using git import-orig --pristine-tar as it is written in our policy document and later simply add the debian/ dir. This workflow usually leads to a properly buildable repository. I've done all of this. Cool. I can now reproduce the creation of the original source tarball snp-sites_1.0.orig.tar.gz which helps me to verify your steps. Before I could import the pristine tar I had to: git branch upstream I can confirm this - usually this should be done by pristine tar automatically (there was no need for this in other cases before) but once you do this the import works nicely. Then I was able to import the original tar ball that was created with uscan. I then copied over your old debian/ dir and also adapted the version number since it was only 1 before but now we need 1.0. Feel free to gbp-pull since I commited this status now to git.debian.org. Running git-buildpackage I get this: js21@builder:~/clean_build/snp_sites$ git-buildpackage --git-ignore-new dh clean --with autoreconf dh_testdir dh_auto_clean dh_autoreconf_clean dh_clean fatal: Not a valid object name upstream/1 I have never seen this and even if I have a vague guess that it might have something to do with leaving only 1 as upstream version number in the debian/changelog the build should not have proceeded up to this point since it should not have found a matching source tarball (or it grabs it from your local disk somewhere??). I can't seem to find where the problem lies. Have you come across this before? I'd recommend to fetch the current status at git.debian.org (best via gbp-pull since this also fetches upstream and pristine-tar branch automatically!) and try git-buildpackage again. This should build at your site. If it does we can now start working down the lintian issues. You could try: lintian -i -I snp-sites_1.0-1_amd64.changes to review these. Some of them might be (hopefully) self explanatory. One hint for a typically hard to detect one is W: snp-sites source: source-nmu-has-incorrect-version-number 1.0-1 Lintian assumes a NMU (Non-maintainer upload) since you have specified different e-mail addresses in debian/control Uploaders field and in changelog. I'd recommend using dch for creating changelog entries which grabs you favourite maintainer address from the environment (see `man dch`) and use this address also in debian/control. If you have further questions to other lintian issues feel free to ask. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107140856.gk6...@an3as.eu
Re: Role of afno
Hi Andreas,
Hmmm - I'm not sure what happened with Anfo at all. I put it in BL6 by
special request and I had a working package, but in BL7 it's missing and
I can't seem to find a record (or remember) why I removed it.
It's still of interest to me since it's good for degraded environmental
DNA. I'll take a look if I get time this week - I'm preparing a course
right now so generally busy with that. I also need to upload my Galaxy
work before Stonehaven - it's not ready for Debian yet but I've made
significant progress.
Cheers,
TIM
On Wed, 2014-01-01 at 17:51 +, Andreas Tille wrote:
Hi Tim,
after having fixed a lot of bugs in old packages I was diving into our
todo list and found afno. Since you commited spme packaging stuff for
afno I guess it might be useful for BioLinux. I checked your packaging
in SVN and tried to enhance it to latest Debian Med standards. However,
the package FTBFSes with
...
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I..
-D_FORTIFY_SOURCE=2 -pthread -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o align.lo
align.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -pthread
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -c align.cc -fPIC -DPIC -o .libs/align.o
In file included from index.h:22:0,
from align.h:21,
from align.cc:21:
util.h: In instantiation of 'T throw_errno_if_minus1(T, const char*, const
char*) [with T = long int]':
util.h:107:44: required from here
util.h:48:46: error: 'throw_errno_if_eq' was not declared in this scope, and
no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
{ return throw_errno_if_eq( x, (T)(-1), a, b ) ; }
^
util.h:55:3: note: 'templateclass T T throw_errno_if_eq(T, T, const char*,
const char*)' declared here, later in the translation unit
T throw_errno_if_eq( T x, T y, const char* a, const char* b = 0 )
^
util.h: In instantiation of 'T throw_errno_if_minus1(T, const char*, const
char*) [with T = int]':
util.h:130:73: required from here
util.h:48:46: error: 'throw_errno_if_eq' was not declared in this scope, and
no declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
{ return throw_errno_if_eq( x, (T)(-1), a, b ) ; }
^
util.h:55:3: note: 'templateclass T T throw_errno_if_eq(T, T, const char*,
const char*)' declared here, later in the translation unit
T throw_errno_if_eq( T x, T y, const char* a, const char* b = 0 )
^
make[4]: *** [align.lo] Error 1
I wonder whether the package is worth spending more time into it (asking
some C++ experts what might be wrong here) or whether the package might
be not needed any more since there might be some better replacements.
Kind regards and thanks for your initial work on this
Andreas.
--
Tim Booth tbo...@ceh.ac.uk
NERC Environmental Bioinformatics Centre
Centre for Ecology and Hydrology
Maclean Bldg, Benson Lane
Crowmarsh Gifford
Wallingford, England
OX10 8BB
http://nebc.nerc.ac.uk
+44 1491 69 2705
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1389108304.3165.81.camel@balisaur
Build problems with afno
Hi Udo,
I'm writing you on behalf of the Debian Med team which tries to
integrate Free Software in the field of medicine and biology straight
into Debian. Afno came to our attention because it is used by
BioLinux (an Ubuntu derivative which profits from our work as well)
but when trying to build with latest gcc we were running into build
problems:
...
/bin/bash ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I..
-D_FORTIFY_SOURCE=2 -pthread -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o align.lo
align.cc
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -D_FORTIFY_SOURCE=2 -pthread -g
-O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -c align.cc -fPIC -DPIC -o .libs/align.o
In file included from index.h:22:0,
from align.h:21,
from align.cc:21:
util.h: In instantiation of 'T throw_errno_if_minus1(T, const char*, const
char*) [with T = long int]':
util.h:107:44: required from here
util.h:48:46: error: 'throw_errno_if_eq' was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
{ return throw_errno_if_eq( x, (T)(-1), a, b ) ; }
^
util.h:55:3: note: 'templateclass T T throw_errno_if_eq(T, T, const char*,
const char*)' declared here, later in the translation unit
T throw_errno_if_eq( T x, T y, const char* a, const char* b = 0 )
^
util.h: In instantiation of 'T throw_errno_if_minus1(T, const char*, const
char*) [with T = int]':
util.h:130:73: required from here
util.h:48:46: error: 'throw_errno_if_eq' was not declared in this scope, and no
declarations were found by argument-dependent lookup at the point of
instantiation [-fpermissive]
{ return throw_errno_if_eq( x, (T)(-1), a, b ) ; }
^
util.h:55:3: note: 'templateclass T T throw_errno_if_eq(T, T, const char*,
const char*)' declared here, later in the translation unit
T throw_errno_if_eq( T x, T y, const char* a, const char* b = 0 )
^
make[4]: *** [align.lo] Error 1
I wonder whether you have any clue how to fix this problem.
Kind regards and thanks for providing afno as Free Software
Andreas.
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140107180503.gu6...@an3as.eu
Re: Build problems with afno
Hello Andreas, in old incarnations of g++, a template declaration could come after the actual use of the template, but with new code, the template declaration must be available before the first instantiation, meaning: this declaration in line 55 must be moved before the actual use in line 48. util.h:55:3: note: 'templateclass T T throw_errno_if_eq(T, T, const char*, const char*)' declared here, later in the translation unit T throw_errno_if_eq( T x, T y, const char* a, const char* b = 0 ) ^ Hope that helps, tomorrow I could also dig into it and prepare a patch. Best, Gert -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1389118939.5840.9.camel@localhost.localdomain
Re: Build problems with afno
Hi Gert, On Tue, Jan 07, 2014 at 07:22:19PM +0100, Gert Wollny wrote: Hello Andreas, in old incarnations of g++, a template declaration could come after the actual use of the template, but with new code, the template declaration must be available before the first instantiation, meaning: this declaration in line 55 must be moved before the actual use in line 48. util.h:55:3: note: 'templateclass T T throw_errno_if_eq(T, T, const char*, const char*)' declared here, later in the translation unit T throw_errno_if_eq( T x, T y, const char* a, const char* b = 0 ) ^ Hope that helps, tomorrow I could also dig into it and prepare a patch. A patch would be really welcome (I have some real life things on my todo list this evening). Thanks in any case Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140107185809.gv6...@an3as.eu
