[Debian-med-packaging] status of meme Debian packaging

Andreas Tille andreas at an3as.eu
Tue Jan 15 08:11:32 UTC 2013


Hi Faheem,

On Tue, Jan 15, 2013 at 02:23:20AM +0530, Faheem Mitha wrote:
> >Sorry, no.  If you find a reasonable way to contact meme authors - we
> >need to ask them for a better download link.  The current ftp server
> >layout is very bad for parsing using uscan.
> 
> The contact address mentioned on the web site is meme at nbcr.net. Have
> you tried that?  I suppose another approach, if this got no response,
> would be to email some of the people listed in
> http://meme.nbcr.net/meme/doc/cite.html. Also
> http://meme.nbcr.net/meme/doc/authors.html. They might not like it,
> but they might reply.

I was not that deeply into meme packaging that I tried anything.  If
there is no volunteer to take over the contact in the next couple of
days I might consider this at our sprint in Kiel.
 
> >Good hint.  Well, the reason why we do not have these is that those who
> >worked on the package (at least me) do not know about this.  This is
> >*very* unfriendly for distributors.  It is hard enough to parse their
> >version number at ftp mirror and impossble to detect new patch levels
> >automatically.  :-(
> 
> You want a script to tell you when the patches are updated?

No.  I rather want that our default tool (uscan) works out of the box.
I do not have much interest to develop a script for one single package
(amongst about 200 others maintained by our team) just because upstream
s decided to go non-standard ways to distribute their code.  I do not
regard it sustainable to guess how upstream might structure their
download tree and write weak scripts to follow this.  I'd rather would
like to convince upstream to do releases like 4.9.0.1 and 4.9.0.2 while
the last version number incorporates the patch level.

> As I
> expect you are aware, the current patches for 4.9.0 are at
> ftp://ftp.ebi.edu.au/pub/software/MEME/r4.9.0/.

Yes I am.  But this contains the source in a dir named "rc5" while meme
r4.8.1 contains rc2 - this is not obvious to me and makes it hard to
write a reasonable watch file.  Verifying the patches subdirectory
for the number of patches is also nothing you really want to do with
uscan.

So my suggestion for upstream would be to release fully patched source
tarballs and if they insist on this directory structure providing a
separate page (may be static or autogenerated html or wiki) to link to
every single release which makes it easy for uscan to pick the latest
release.
 
> >Please test the packages and report issues here on the list (no need
> >to CC me personally).
> 
> It seems you made changes to the Debian packaging, updating the
> packaging for 4.9.0. I can confirm with this change, the package
> builds and installs without problems,

Good.

> though I have not yet tried
> doing anything with it.

It would be interesting to get a report here.
 
> However, adding the additional patches breaks the build, because there
> are conflicts between the Debian packages, and those patches, at least
> for src/init.c. I didn't understand what was going on well enough to
> fix it myself, so I left out the upstream patches.

I'll see whether I manage to incorporate the patches and will let you
know. 

Kind regards

      Andreas.

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list