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

Re: Orphaning my packages...

Hi Francois,

On Wed, Sep 30, 2009 at 3:04 AM, francois.niedercorn2@laposte.net
<francois.niedercorn2@laposte.net> wrote:

> Now, the first step I've to do is to answer every of these bug reports
> (cernlib - #508413, cfortran - #508500,geant321 - #508496, mclibs -
> #508498, mn-fit - #508501, paw - #508495) by changing the subject with
> ITA, am I right ?

Yes.  (By the way, if you don't use all of those packages, you aren't
obligated to adopt every single one!  I know that mn-fit and mclibs,
at least, have really low popcon numbers, so if you don't have any use
for them, feel free to leave them orphaned.)

> For the second step : "upload the packages with my name in its
> Maintainer: field, and put something like | * New maintainer (Closes:
> #bugnumber) | in the changelog of the package in order to automatically
> close this bug once the package has been installed." I can't upload the
> packages, so I need to ask to debian-mentors-list (or debian-science) to
> find a sponsor for the upload, is this correct ?

Yes.  However, take note that some of the source packages are quite
large, and it is a little hard on the buildd machines to make a new
upload solely for the purpose of changing the maintainer name/email.
I'd suggest also doing at least some cleanup of Lintian warnings prior
to a new upload.

(But really, you're free to do whatever you like as long as someone
will sponsor it :-)

> But I don't know the procedure for a comaintainership package, or for a
> team maintainership, if somebody can explain me the extra steps ?
> I also need to correct outstanding bugs affecting the packages.

It's perfectly OK to take over packages and make a new upload without
fixing every outstanding bug ... some bugs are hard or impossible to
fix, while some are wishlist and not really necessary to implement.
(Bugs in both those categories are often best pushed upstream, except
that none of these packages really have an active upstream anymore.)

> bug #348065  affecting cernlib is not yet
> corrected (I've basically no experience on bsd, I can't give it a try
> now, but as the severity is "wishlist" perhaps I didn't have to correct
> it before uploading cernlib ?)

This is likely one of those "hard or impossible" bugs except maybe for
an Imake / BSD expert.

> bug#374978  affecting paw seems to be
> corrected, so I've basically nothing to do (?)

It's been corrected at least for the immediate problem that was
initially reported ... in my opinion the cause of this symptom is a
bug itself, but it's a systemic bug in the architecture of Paw that
would be very difficult to fix.  So I agree that there isn't much to
be done here... maybe either leave the bug open and tag "wontfix", or
just close it.

> bug #507429 affecting cfortran didn't
> seem to be corrected (yes ?), but I could apply the correction that is
> suggested in the last mail.

Please feel free.

> bug #249483  affecting cfortran, it is a
> wishlist also.

Right, it was something I didn't feel I had the wherewithal to tackle.

> For bug #497023  (affecting cfortran) I
> think it may be corrected...

Right, although before uploading a cfortran package that fixes this,
it would be good to make sure that all the dependent packages still

Finally, just wanted to double-check that you saw my other email to
debian-science at
http://lists.debian.org/debian-science/2009/09/msg00066.html in case
you also wanted to adopt the "Cernlib on Debian" web pages.

best regards,

Kevin B. McCarty <kmccarty@gmail.com>
WWW: http://www.starplot.org/
WWW: http://people.debian.org/~kmccarty/
GPG: public key ID 4F83C751

Reply to: