On 24 Nov 2006 21:31:47 +0200
Jari Aalto <jari.aalto@cante.net> wrote:
Something I missed first time through, please remove the unused ',
${misc:Depends}' in debian/control.
dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> > 1. There's a patch in the BTS that you need to include - a translation.
> > Also, check to see if any of the existing bugs are already fixed or
> > have obvious fixes. Tag those that are fixed as 'fixed-upstream' (see
> > later). In particular, #268468 should be looked at and, hopefully,
> > fixed.
>
> Done and done.
Sorry, there is no evidence of activity on the bug report for the
important bug, #268468 - if you have fixed it you should document this
in the bug report, ready for an upload to close it. Please let the bug
reporter know that the issue has been fixed and let him know that the
fixed package is being prepared for upload. Interested users do monitor
the BTS and when there has been no addition to an important bug for
over two years, it doesn't inspire confidence in the package. The other
two non-wishlist bug reports also show no activity recently. It's good
to introduce yourself in these reports, thank the reporters for their
reports, explain a little about how you fixed the problem (if
appropriate) and let them know that a long-awaited fix is in the
pipeline.
Some examples of friendly BTS messages are:
http://www.mail-archive.com/debian-women@lists.debian.org/msg02777.html
Please also tag each fixed bug report as fixed-upstream. I can then
test for these bugs prior to upload.
Also, please don't ignore or "sideline" wishlist bugs - they are
important pointers about how real users want to be able to use your
package. Either explain why you think these ideas should not be
incorporated into the package or describe an alternative implementation
that meets the needs of that user.
Personally, I think #268799 has real merit - it would make dlume much
more usable for me. Nearly all my contacts have a home address and a
place of work and I frequently need to contact them at one or both
addresses. Categories are also an important feature in packages like
dlume.
> > 6. a .desktop file would be a big improvement - the current menu entry
> > in Apps/Text could also be reviewed - most addressbooks go into
> > Apps/Databases or Apps/Tools. The .desktop file should probably use
> > Application;PIM;Office
Any news on that? Not everyone wants to use only the Debian menu.
> > 8. Update the manpage to explain the absence of the claimed upstream
> > location. The manpage and AUTHORS also hint at other copyright holders
> > not specified in debian/copyright.
>
> Done and done.
The manpage still claims that the latest version is available at a dead
location. :-(
> > 12. Provide a download location that can be specified in
> > debian/copyright to replace the dead upstream.
>
> The link can serve as a reference.
Except that the reference leads nowhere. Someone may want to package
dlume for a different distribution after seeing it in Debian, users may
simply want to know how to contact you and find out more about the
package. Make it easy for them.
> I plan to put package at alioth in
> the future, but this should not be an obstacle for upload.
Not necessarily in current Policy but it is something I think should be
done before I sponsor the upload. That's my own preference.
> > BTW. Why did you remove cdbs? dh_make can create cdbs packaging as
> > easily as any other.
>
> For practical reasons. I have tools for dh-make, which is also
> more widely in use. cdbs and dh-make havae been discussed before and
> choice is a personal preference.
Just curious.
> > > - Upstream vanished
> > > - No new features will appear
> >
> > This is bad news. This makes a comparison between dlume and equivalent
> > small addressbooks (like gpe-contacts, contacts and gaby or quicklist)
> > less than favourable.
>
> Can't help that.
?
One of my criteria for sponsoring a package is that it either provides
something new to Debian or provides something that is better than the
existing packages in some identifiable way. gpe-contacts is
specifically designed for embedded environments, contacts is a small
Gtk addressbook and quite similar to dlume. Before we resurrect an
orphaned package, it is as well to evaluate the alternatives - and
there are more than the specific ones that I mentioned above.
It's disappointing that you feel you can't help dlume being
unfavourably compared to equivalent simple and easy to use Gtk
addressbooks. You are seeking to be the Debian maintainer and
prospective upstream for this code - if you can't explain why dlume is
preferable to it's alternatives, who can? More importantly, if you
don't feel you can back your own package, what does that say about the
package? dlume has been orphaned once already - I don't want to sponsor
it and find it orphaned again because you've found something you can
believe in. Sell the package a bit, promote it. Tell me why dlume
shouldn't be left orphaned, what it does differently, what you hope to
do with it in the future, what it does well, what it does that
equivalents do not, etc..
Package maintenance isn't just for now, it's about the future too.
What might the future hold for dlume? I for one would like to know.
>
> > If there is no upstream, I am less keen to sponsor. I'd strongly
> > recommend creating a new upstream (somewhere like SourceForge as
> > this isn't a Debian native package) and seeking help to create a new
>
> Is planned.
> > upstream team - unless you are willing to take on upstream tasks
> > alone.
>
> I am.
OK. This is a good reason to have an upstream location. Someone working
on a similar package may want to see how you fixed a particular bug in
dlume, it would be helpful to have that information available.
> This is not a problem. Dlume is worth keeping and there are no
> open bugs after this upload (all fixed; except wishlist).
I'm glad to hear that but no sv.mo file is included in the package.
There should be a file called :
/usr/share/locale/sv/LC_MESSAGES/dlume.mo
listed in the output of debc after a build. Without this, your
inclusion of the patch is worthless because the effect of the patch is
not installed. You need to include 'sv' in the ALL_LINGUAS variable in
configure.in so the build process doesn't utilise the new translation.
Also, the filename in po/, after patching, should be just 'sv.po' not
'dlume.sv.po'. A successful build needs to create a sv.gmo file which
is then packaged as the sv.mo. All this is done for you via the
Makefile.in.in in po/ - provided you set the correct languages in
configure via configure.in.
Take a look at other packages with translations for tips on how to
ensure the translations get into the final package.
> > Right now, the package is not ready for sponsoring.
>
> Check now. Thanks for detailed review.
Thanks for making the changes so far but more needs to be done. Sorry.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpCi5sGPx7bR.pgp
Description: PGP signature