Re: Debuild issue

2013-12-17 Thread Andreas Tille
Hi Gregory,

On Mon, Dec 16, 2013 at 04:10:29PM -0800, Gregory Sharp wrote:
 The source tarball should not contain the Debian revision number.  The
 -1 in the end is the Debian package version which will be increased
 if there would be a need to change the packaging.
 
  Should I just rename the .tar.gz file and go about my business?
 
 Yes, definitely.  The name should be
 
    plastimatch_1.5.15+dfsg.orig.tar.gz
 
 
 Definitely I was misunderstanding this.  Now I understand and 
 
 my problem was easily resolved.  
 
 
 But I still have a kind of philosophical question.
 
 With change of Debian revision number, couldn't the content of source
 tarball change?

No.  If the content of the source tarball changes it is per definition a
new upstream tarball and usually you will start with Debian revision
number 1 again.

 For example removing an additional file from upstream.
 Then you would have different Debian versions, with different 
 
 source tarballs, but the same filename.

The source file name should change by increasing its version number.
 
 I also think that if I will sponsor the package I will consider using
 the enhanced uscan[1] to create the upstream source and allows better
 compression option.
 
 
 The new uscan looks very promising.  I would like to use it.

It is now in devscripts - unfortunately the option to choose the
compression method is not yet implemented (see #730768).

 So far I ran into two problems, so I stick with the old method 
 
 until I can resolve.
 
 
 - In Files-Excluded I have a pattern doc/*.pdf, but one of the 
 
 files with this pattern did not actually get removed.- I like to run 
 get-orig-source as a shell script on the local file 
 for testing if files are being removed correctly.  But uscan seems only 
 to support downloading the tarball from ftp or http.

Ahhh - that's a bug which seems to happen due to a space in the name of
the PDF in question.  I need to track this down.

Currently the get-orig-script is written in a way that the downloader /
creator of the orig source tarball us using the new uscan feature if it
is installed on his machine.  So if I download the tarball than it is
just used.  This is a consequence of the fact that in our SVN workflow
the source code is not stored in SVN.  It would be different when using
Git since there the original tarball is stored as pristine-tar inside
the Git repository.

 For simplicity you can simply care for commiting your packaging code as
 usual to SVN and ping this list.  We will care for an upload.
 
 Thanks!!  The new plastimatch seems ready.  I hope error building 
 
 on sparc, mips will be resolved.

I just uploaded.  Thanks for your preparation

 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/20131217084214.gc...@an3as.eu



Re: [MoM] ProbABEL packaging

2013-12-17 Thread Andreas Tille
Hi Lennart,

On Tue, Dec 17, 2013 at 12:17:47AM +0100, L.C. Karssen wrote:
  DEBEXAMPLES:=$(DEBPKGNAME)-examples
  
  in the beginning of your rules file and than moving the files around.
  
  If you want to check the more general packaging docs the keyword is
  probably multi binary packages (or something like this - I did not
  checked).
 
 
 Thanks for these hints. In took me a wile to figure it out, but it
 turned out to be simple. The main missing piece of information was the
 when building multiple binary packages the files get installed in d/tmp
 instead of d/$DEBPKGNAME and then copied during the dh_install phase.

Ahh, well this might be a stumbling stone for beginners.  The good thing
is that you most probably will remember now since you have invested some
time in finding it out. ;-)

 In short and for future reference, this is what I did:
 - Add a section to d/control
 - Create d/$DEBPKGNAME.install listing the directories (from d/tmp) that
 need to go in the main (arch-dependent) package
 - Create d/$DEBPKGNAME-examples.install listing the directories (from
 d/tmp) that need to go in the examples package.
 - Update d/rules; previously my changes were in the
 override_dh_auto_install section, now they're in the override_dh_install
 section (changing the path to $DEBPKGNAME-examples where needed)

Sounds all very reasonable.
 
 I would have been cool if dh_install, in the case of multiple binary
 packages, would move the files from d/tmp to d/$DEBPKGNAME (etc.) so you
 can more easily see if you indeed listed everything in the .install
 files. Do you know if such an option exists?

man dh_install
/--list-missing
/--fail-missing

 I think with this we are ready for upload, right?

Yes, it is ... and thus it was just uploaded. :-)
Congratulations!

 Maybe a final change
 in d/changelog to replace the UNRELEASED tag?

This is what I usually do (and have done) since this seems logical to
me.  I just commited and tagged. 

Thanks for your work on this and if we are lucky ftpmaster might process
your package in the next two weeks so the MoM package will be available
at end of this year.

It was a pleasure to work together with you

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/20131217093711.gc2...@an3as.eu



Re: Please be prepared for a move of tasks files for Debian Med from SVN to Git (Was: looking for a review for pycorrfit)

2013-12-17 Thread Alex Mestiashvili



btw, how do I update the tasks page?

I was looking for it in debian-med policy and checkout the
debian-med tasks from svn,
but the link in README seem to be broken:
http://blends.alioth.debian.org/blends/ch-sentinel.en.html

Hmmm, from what README, did you got this link.


The README in the root of debian-med from svn.


   It definitely needs
fixing.  The reason are two migration steps.  The first one was from
SGML to XML in the documentation which changed the file names which was
not backed up by some symlinks.  The next transition was done from
blends.alioth.debian.org to blends.debian.org.  While I installed
redirects to the new location the old file names of the doc where not
regarded.  I now just installed symlinks at the old locations so the
old links should work again (at least the one you posted above) but
all those old READMEs should be fixed in any case.

Just let me know if you have any trouble with updating the tasks files.
Since you either need to be a DD or a member of the blends team you
will perhaps face permission problems.  On the other hand:  What do you
want to change?

$ grep pycorrfit *
bio:Depends: pycorrfit


I see, in that I case I don't need to change anything.



So the package is included and the framework will atomatically notice
that it migrated from Vcs to NEW queue.  Just watch the sentinel page
tomorrow. :-)


Cool, I didn't know that it works this way!


As the subject of this mail says it is planed to move Debian Med tasks
files from SVN to Git in the not so far future.  I just did the
migration for Debian Science and Debian Med will follow in the beginn
of next year.  I'm just announcing this to enable you to rise your
voice if there are strong reasons against this move.


I see, thanks for the information.


Kind regards

Andreas.





Best regards,
Alex


--
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/52b02786.1090...@biotec.tu-dresden.de



Re: Please be prepared for a move of tasks files for Debian Med from SVN to Git (Was: looking for a review for pycorrfit)

2013-12-17 Thread Andreas Tille
Hi Alex,

On Tue, Dec 17, 2013 at 11:29:26AM +0100, Alex Mestiashvili wrote:
 http://blends.alioth.debian.org/blends/ch-sentinel.en.html
 Hmmm, from what README, did you got this link.
 
 The README in the root of debian-med from svn.

Good catch!  Changed!
 
 $ grep pycorrfit *
 bio:Depends: pycorrfit
 
 I see, in that I case I don't need to change anything.

:-)
 
 So the package is included and the framework will atomatically notice
 that it migrated from Vcs to NEW queue.  Just watch the sentinel page
 tomorrow. :-)
 
 Cool, I didn't know that it works this way!

That's why I'm always trying to advocate to put the binary package names
right into the tasks files once a package was pushed into Vcs.  This
advertises our work and makes the package known even before it is
uploaded.
 
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/20131217103702.gf2...@an3as.eu



Re: Debuild issue

2013-12-17 Thread Dominique Belhachemi
On Tue, Dec 17, 2013 at 3:42 AM, Andreas Tille ti...@debian.org wrote:

 Hi Gregory,

 On Mon, Dec 16, 2013 at 04:10:29PM -0800, Gregory Sharp wrote:
  The source tarball should not contain the Debian revision number.  The
  -1 in the end is the Debian package version which will be increased
  if there would be a need to change the packaging.
  
   Should I just rename the .tar.gz file and go about my business?
  
  Yes, definitely.  The name should be
  
 plastimatch_1.5.15+dfsg.orig.tar.gz
 
 
  Definitely I was misunderstanding this.  Now I understand and
 
  my problem was easily resolved.
 
 
  But I still have a kind of philosophical question.
 
  With change of Debian revision number, couldn't the content of source
  tarball change?

 No.  If the content of the source tarball changes it is per definition a
 new upstream tarball and usually you will start with Debian revision
 number 1 again.

  For example removing an additional file from upstream.
  Then you would have different Debian versions, with different
  source tarballs, but the same filename


If you have to repackage upstreams tarball again, e.g. removing a pdf file,
then just change the dfsg part to dfsg0, dfsg1, etc.. So you will end
up with something like plastimatch_1.5.15+dfsg1.orig.tar.gz

-Dominique


Re: Debuild issue

2013-12-17 Thread Andreas Tille
On Tue, Dec 17, 2013 at 08:54:12AM -0500, Dominique Belhachemi wrote:
 
 If you have to repackage upstreams tarball again, e.g. removing a pdf file,
 then just change the dfsg part to dfsg0, dfsg1, etc.. So you will end
 up with something like plastimatch_1.5.15+dfsg1.orig.tar.gz

Well, since I did the first upload I createt the 1.5.15+dfsg.orig.tar.gz
manually - and will try to hunt down the uscan bug soon.  From now on
the source tarball can (and should!) be downloaded via `apt-get source`
anyway.

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/20131217135630.gl2...@an3as.eu



Processed: tagging as pending bugs that are closed by packages in NEW

2013-12-17 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 # Tuesday 17 December  19:03:11 UTC 2013
 # Tagging as pending bugs that are closed by packages in NEW
 # http://ftp-master.debian.org/new.html
 #
 # Source package in NEW: a 
 href=http://packages.qa.debian.org/libmbim;libmbim/a
 tags 728195 + pending
Bug #728195 [libmbim-glib-dev] libmbim-glib-dev: arch-dependent files in 
Multi-Arch: same package
Added tag(s) pending.
 # Source package in NEW: a 
 href=http://packages.qa.debian.org/libmbim;libmbim/a
 tags 731908 + pending
Bug #731908 [libmbim-glib0] libmbim-glib0: new upstream version available: 1.6.0
Added tag(s) pending.
 # Source package in NEW: probabel
 tags 732264 + pending
Bug #732264 [wnpp] ITP: probabel -- Toolset for Genome-Wide Association Analysis
Added tag(s) pending.
 # Source package in NEW: r-cran-evaluate
 tags 732364 + pending
Bug #732364 [wnpp] ITP: r-cran-evaluate -- GNU R parsing and evaluation tools
Added tag(s) pending.
 # Source package in NEW: nat-rtsp
 tags 732026 + pending
Bug #732026 [wnpp] ITP: nat-rtsp -- Connection tracking and NAT support for 
RTSP (DKMS)
Added tag(s) pending.
 # Source package in NEW: yorick-ygsl
 tags 732363 + pending
Bug #732363 [wnpp] ITP: yorick-ygsl -- GSL special functions plugin for the 
Yorick language
Added tag(s) pending.
 # Source package in NEW: jssc
 tags 731189 + pending
Bug #731189 [wnpp] ITP: jssc -- Library for working with serial ports from Java
Added tag(s) pending.

End of message, stopping processing here.

Please contact me if you need assistance.
-- 
728195: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728195
731189: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731189
731908: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731908
732026: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732026
732264: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732264
732363: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732363
732364: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732364
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.138730701825268.transcr...@bugs.debian.org