[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [fis-gtm] ready for upload - needs sponsor



Hi Amul,

On Sat, Nov 23, 2013 at 06:25:33PM -0500, Amul Shah wrote:
> > you totally missed the point what we need to build the package.  As I
> > said from the beginning the difference between the
> > gtm_<version>_linux_i686_pro.tar.gz and
> > gtm_<version>_linux_i686_src.tar.gz are not clear to me.  You claimed
> > that V60003 would have been the latext fis-gtm version and I can confirm
> > that there is
> > 
> >   gtm_V60003_linux_i686_pro.tar.gz
> > 
> > available but this file does not contain the SOURCE.  The latest
> > download file which really contains source files is
> > 
> >   gtm_V60001_linux_i686_src.tar.gz
> > 
> 
> To clarify, the GT.M binary archive has never shipped with the sources. Previously, we uploaded to SourceForge two archives per platform, one for the binaries and one for the sources. FIS releases GT.M as open source on VMS and Linux IA32 and x86_64. As part of the after hackathon (many thanks to Luis, Brad and Yaroslav for their help then and afterwards) todo items, I merged all sources into one unified tar archive containing the sources for Linux (IA32 and x86_64) and VMS.
> 
> I also renamed the archive to use fis-gtm-<version major>-<version minor>-<sub minor version>.tar.gz which unpacked into a directory with the same name as the archive without the tar.gz. Previously the archive untarred to the current working directory which meant that someone had to create the target directory for the sources, change directory into it and untar the archive.

While this is perfectly sensible I was not aware of exactly this change.
 
> The binary archives are available from the following links:
> http://sourceforge.net/projects/fis-gtm/files/GT.M-amd64-Linux/V6.0-003/
> http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux/V6.0-003/
> 
> The source archive is available from the following link:
> http://sourceforge.net/projects/fis-gtm/files/GT.M-x86-Linux-src/V6.0-003/
> 
> The same sources are also available via SourceForge CVS.
> 
> I have a strong feeling that I’m not saying anything new to you.

May be I was not reading your previous mails studiously enough but
exactly this was the information I needed and this was totally new to
me.  I tried to express this in my mail on month ago[1] where I used the
word "urgently" in connection to clarification between 'pro' and 'src'
because we needed to create a working watch file first.  When I
yesterday tried to fetch the tarball with the watch file which I assumed
to be valid I endedt up with the binary distribution.  That's why I was
wondering whether you were assuming that we would package the binaries
...
 
> With respect to not understanding the principles behind packaging, I would say that I don’t know what the principles are. Hence no understanding. For that I apologize.  My knowledge is completely adhoc.

Well, in the case above probably the main principle is beeing more
verbose in case some open questions are remaining.  In your last mail
you have precisely answered these.  Thanks for this and sorry if I was a
bit grumpy yesterday night.
 
> To get this going forward, do I need to push the archive somewhere as part of the GIT repository? Or is it the watch file that needs fixing?

The watch file is just fixed in the packaging git repository now.
 
> Is FIS expected to ship binaries and sources in the same archive for Debian packaging?

No, we do not need the binaries at all.  We just *build* the binaries on
our own and they are considered as waste inside a source tarball - so
please keep them outside.

There is one remaining question:  In the packaging git in

  debian/upstream-files/

there are some external README files (GTM_V6.0-001_Release_Notes.html)
which are included into the packaging as upstream changelog.  BTW,
missing to specify the proper license for these files was finally the
reason for the rejection.  From my point of view these files are doing
more harm than good.  Besides this rejection it always creates manual
work - for instance I now need to fetch the file for the new version.
If this changelog is not included in your source tarball it is probably
not important enough for the user to be shipped inside the binary Debian
package.  So why not simply providing a link inside README.Debian where
the user can find the needed information instead of creating manual
work over and over and blowing up the debian/copyright file with an
extra copy of GFDL?

In short: Where is the download location of

   GTM_V6.0-003_Release_Notes.html

and would you agree to just provide a link to this location instead of
the complete file?

Kind regards

        Andreas.

[1] https://lists.debian.org/debian-med/2013/10/msg00083.html 

-- 
http://fam-tille.de


Reply to: