Hi Andreas, In creating the ITP through reportbug, there are two things that are puzzling me.
The first one is, since I closed the first snp-sites ITP bug, I was assuming that there wouldn't be a snp-sites package: js21@builder:~/deb_alioth/snp-sites$ reportbug --email [email protected] *** Welcome to reportbug. Use ? for help at prompts. *** Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: UTF-8 Please change your locale if this is incorrect. Using 'Jorge Soares <[email protected]>' as your from address. Will send report to Debian (per lsb_release). What sort of request is this? (If none of these things mean anything to you, or you are trying to report a bug in an existing package, please press Enter to exit reportbug.) 1 ITP This is an `Intent To Package'. Please submit a package description along with copyright and URL in such a report. 2 O The package has been `Orphaned'. It needs a new maintainer as soon as possible. 3 RFA This is a `Request for Adoption'. Due to lack of time, resources, interest or something similar, the current maintainer is asking for someone else to maintain this package. They will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer. 4 RFH This is a `Request For Help'. The current maintainer wants to continue to maintain this package, but they needs some help to do this, because their time is limited or the package is quite big and needs several maintainers. 5 RFP This is a `Request For Package'. You have found an interesting piece of software and would like someone else to maintain it for Debian. Please submit a package description along with copyright and URL in such a report. Choose the request type: 1 Please enter the proposed package name: snp-sites Checking status database... A package called snp-sites already appears to exist (at least on your system); continue? [y|N|q|?]? y Nonetheless, I simply said yes. Now, I'm behind a proxy, but apt-get knows exactly what to do and I have all my http_proxy env variables set to the proxy address. Yet I'm getting this: Please briefly describe this package; this should be an appropriate short description for the eventual package: Finding snp sites from multi fasta alignment files Your report will be carbon-copied to debian-devel, per Debian policy. Querying Debian BTS for reports on wnpp (source)... Unable to connect to Debian BTS; continue [y|N|?]? N Do you know if I need to set any other variable in order for reportbug to know we are behind a proxy? Also, on the header files being wrongly installed, I have a fix. I will change the src/Makefile.am. Essentially replacing the line: dist_data_DATA = alignment-file.h vcf.h phylib-of-snp-sites.h snp-sites.h fasta-of-snp-sites.h parse-phylip.h string-cat.h kseq.h For these two lines: snpsitesincludedir=$(includedir)/snp-sites snpsitesinclude_HEADERS=alignment-file.h vcf.h phylib-of-snp-sites.h snp-sites.h fasta-of-snp-sites.h parse-phylip.h string-cat.h kseq.h Regards, Jorge On Mon, Jan 13, 2014 at 10:24 AM, Jorge Sebastião Soares < [email protected]> wrote: > Hey Andreas, > > Addressing this: > > > > No. They were originally moved to debian/tmp/usr/share which does not > > make any sense at all. Afterwards we are moving it to /usr/include > > inside the Debian package which is where I would have expected header > > files also after a plain `make install` of the source package. So > > I guess the upstream install target is broken. > > I have a had a look at both configure.ac and src/Makefile.am but am > unsure where the instructions to put these header files into /usr/share are. > > I am having lunch today with a friend that is extremely experienced in > C++. He's having a look at the source code at the moment. > Let's see if he can point me in the right direction. > > Kind regards, > > Jorge > > > > On Mon, Jan 13, 2014 at 9:59 AM, Jorge Sebastião Soares < > [email protected]> wrote: > >> Hey Andreas >> >> On Fri, Jan 10, 2014 at 4:27 PM, Andreas Tille <[email protected]> wrote: >> >>> >>> On Fri, Jan 10, 2014 at 03:57:31PM +0000, Jorge Sebastião Soares wrote: >>> >>> > > I hope you also noticed the additional Provides / >>> > > Conflicts lines in d/control. D-shlibs will issue an error if these >>> are >>> > > missing. >>> .... >>> > Is this there to ensure that in future installations the old version >>> needs >>> > to be removed before the new one is installed? >>> >>> Yes. You should only have one libfoo-dev package installed. >>> >> >> Cool. >> >>> >>> > > I bet you (and me!) would have forgotten these without using >>> > > this tool. >>> > >>> > So these two sections should have been there from the off? >>> > And by using d-shlibs, there is no way I could forget them because >>> d-shlibs >>> > would always complain? >>> >>> Homework: Try removing one or both of these lines and try to build the >>> package. >> >> >> If Conflicts or Provides section is not present, package creation aborts >> and handy hook shell drop-in script kicks in. >> Very nice. >> >> >>> >>> > > > Now just have to deal with NMU and ITP. >>> > > >>> > > If you have no idea about the NMU issue please check my previous >>> > > mails. I have given an explicit hint about this! >>> > > >>> > > >>> > I'm on it. Looking into the dch tool. >>> >>> Fine this was what i meant in the now deleted because redundant >>> paragraphs of my previous mail. >>> >> >> Problem sorted. >> Only using gmail address now. >> >> I have closed the previous ITP. >> I guess only things left doing are: >> >> Generate a new ITP; >> Add bug number to the relevant files; >> Commit everything to git; >> Confirm that the package installs correctly. >> >> Rergards, >> >> Jorge >> >> >> >
