Re: Gramps Version 3.4.6
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Mentors,
I am forwarding this back to the list hoping to share my learning
process :-) I am leaving lots of text for the background info. But
there is a question in the middle about dh_overrides that I hope
someone can help me with. I would like to have the package in better
shape before Andreas is back from his break.
On 10/29/2013 08:06 PM, Andreas Tille wrote:
> Hi Ross,
>
> On Tue, Oct 29, 2013 at 07:37:39PM +0100, Ross Gammon wrote:
>>> That's good. Provided that James who is mentioned as the only
>>> maintainer currently is OK with this I'd suggest to add
>>> yourself in the "Uploaders" field. The sense of collab-maint
>>> is to work together and not to add a bunch of NMUs - so you
>>> could issue Debian packages with integer version numbers.
>>
>> Unfortunately, James has not responded to my emails (over the
>> last 4 months) and I have reported that to the MIA team. But I
>> would be happy to collaborate with him if he returns (or even
>> step back if he prefers). Certainly I am happy that with Gramps
>> now in collab-maint it will make it easy to work with others, and
>> ensure that in the future someone else can take over very easily
>> if something goes wrong. Let me know what you think is best - I
>> would certainly prefer not to have to NMU, and James would still
>> be listed as maintainer.
>
> If you ask me if a maintainer does not respond for 4 monthes I
> would consider it as: "He is not against adding you as uploader."
> So if he is not against it - just do it.
Actually, James has now orphaned the package, and I am now intending
to adopt it (ITA). So I am now the Maintainer in the control file, and
the changelog now has a "* New maintaner (Closes: #wnpp bug).
>
>>> Regarding the package itself: It is OK so far and I could
>>> sponsor it but I'm personally changing the following things in
>>> all my packages:
>>>
>>> 1. Using short dh in d/rules. Well, this is probably nothing
>>> you should do in an NMU - but ... see above about Uploaders.
>> I had left the rules file and the maintainer scripts alone
>> because they "just worked". But I am happy to standardise, and
>> will give it a try. We can always drop it (if we take the NMU
>> approach).
>
> I would recommend to standardise on dh and drop the NMU approach.
> This is IMHO a proof that you take things honest about this
> package.
Yes, now I have cleaned the rules file out, and have the standard
short form. The first build failed of course, and the old rules file
gave me the clue that dh_installman needed to be overridden. This is I
believe because Gramps has no manual any longer, it only exists online
(wiki):
override_dh_installman:
So now we successfully build with some new lintian warnings to work
on. And now my question! This is the first lintian warning (I have
some more!):
W: gramps: extra-license-file usr/share/gramps/COPYING
The COPYING file provided by upstream is just the standard text for
the GPL-2 license. The standard GPL2 license text is referenced in my
copyright file in the standard way, so I assume the COPYING file can
just be removed from the package. The old rules file used rm to delete
it (and added a sym-link that lintian used to complain about). I have
googled, but came up blank - so the question:
How do you delete a file/prevent it being copied to usr/share/gramps
with dh_install?
Does someone know a good guide to these overrides?
>
>>> 2. cme fix dpkg-control -> enhances the readability of
>>> d/control which is simply nice for teamwork
>> Will do.
It took me a while to get cme working (it is not obvious what needs to
be installed), but that resulted in some old cruft being removed. They
seemed to be long gone packages in Conflict/Replaces pairs.
>>>
>>> 3. If you do `lintian -I -i *.changes` you get some lintian
>>> info about vcs-field-not-canonical and
Fixed!
>>> desktop-entry-lacks-keywords-entry While lintian is really
>>> nitpicking here it does not harm to solve this.
>> Will look at the vcs field - I just added that, so I should do
>> it right! I noticed the desktop entry info from lintian, but
>> this requires translation. I will propose a patch for upstream,
>> but it probably won't be ready until a future release.
>
> Don't worry about the desktop file. I just wanted to make you
> aware and it is definitely nothing that would stop me from
> uploading.
>
>>>> Would you have time and be interested in sponsoring this?
>>>> Comments are welcome in anycase.
>>>
>>> If you would like me to sponsor despite the cosmetical items I
>>> have mention above I would do this. Just tell me whether you
>>> want to tackle some or all of these items.
>> I would prefer to do the above and improve the package (and me).
>
> OK. Just ping me if you are ready. Please note that I'll be on
> short vacation from Thursday to Sunday. I'll be probably able to
> read my mals but please be patient if I'm not responding as quickly
> as usual.
>
>>> About the tagging: I personally prefer packages that are not
>>> yet uploaded to target at 'UNRELEASED' distribution, which
>>> means the first line in d/control should look like:
Tag deleted. You will also need to delete it locally if you previously
cloned with the tag.
>>>
>>> gramps (3.4.6-0.1) UNRELEASED; urgency=low
>> Yes - I noticed this approach in my googling on the
>> pkg-multimedia. It did not seem universal accross all the
>> debian-alioth sites - but I will revert to this approach as it
>> seems sensible.
Now says "UNRELEASED".
>
> It is most probably not universal accross all teams - but at least
> all teams I'm a member of are following this workflow. So it would
> just be easier for me to keep my workflow.
>
>>> I as the sponsor would turn this to unstable if I'm happy with
>>> the packaging and once this is done we are tagging the state
>>> that reflects the upload. This converntion helps other team
>>> members to know whether a pckage was uploaded or not. I
>>> personally do not require you to upload the package to mentors
>>> - if you like to do this anyway that's OK and you should stick
>>> to 'unstable' for doing so. But in any case the tagging should
>>> be done *after* the upload.
>> Happy to stick on collab-maint to avoid confusion and reduce
>> work. I will also delete the tag (so far it should only be you
>> and I that would have the wrong tag).
>>>
>>> It would be nice to hear James' opinion about this.
>>>
If anyone needs to see what I am talking about, the git collab-maint
repository is here:
>>>> You can find it all on collab-maint here:
>>>> http://anonscm.debian.org/gitweb/?p=collab-maint/gramps.git
>>>
>>> Thanks for your work on this
>>>
>>> Andreas.
>>>
>>> PS: I'm personally a real fan of public discussion for
>>> sponsering. Since there is no gramps related list but we are
>>> talking about sponsering and packaging issues I think
>>> debian-mentors list would be OK to use. I'm reading the list
>>> but sometimes I'm a bit quick in browsing and deleting the
>>> mails per subject. Please ping me if I do not respond in a
>>> reasonable time frame. Feel free to continue the discussion on
>>> list and feel free to quote me in public as explicite as you
>>> want.
Done, this email :-)
>> Will do. I will start work on all the above - leaving the NMU
>> business to last (giving James a chance to reply). Then I will
>> drop a message on the mentors list. Should it ben a RFS?
>
> I'm personally basically ignoring RFS and organise my sponsees via
>
> https://wiki.debian.org/DebianPureBlends/SoB
>
> Since gramps does not yet fit into any Blend and I'm just
> interested because my wife is using it I think it is sufficient if
> you just ping me vial mail. In case I might not respond (for
> whatever reason) in a reasonable time frame, please ask via RFS for
> another sponsor.
It may take me some time anyway!
>
>> Thanks for your time - and advice.
>
> You are welcome
>
> Andreas.
>
All comments & feedback welcome.
Ross
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSdUIhAAoJEFP+e72miRD8X9wQAI0JGEguLAnIb7YvC2RvetA1
r3PAHEau0lSYmSJbG32kUzpIK0ddhy78LaDPIhDRyTrPP3MSBXTrKTGZQpyqqTnb
FoIhw67liqXraj4kS2A7kAo9ZPIkQL9HZAzhp/keRP1zVHDvIsDuCKLmJjwdD5+H
4YvreiYdMXlEvvir/rT2mqvC2tHZOX5ey6lIDzEYJKqEKD90IqwTVgLWI1iyvuxA
mOQqkwcsuffxDDg64VL5i2PUel2UE1TA9FzxfRKLNXI0Fk7/kvNo+O1dXkjcLTpK
MmdVam6cChRtIuUHZat4LKVQKo7qZA0gkVFDYXwtMFarI/T3B5d+lqGwNLskHAWp
KF3FUS1l+pfo7XWktxkRp2daV0XCyDeZic9GvlWLytXJ/PD2qOjywi5FyHFKyr+M
ChI2wURpBXCiFD3/ajf6xfpkx8rObl3a6dvxPtvfoHTAHw69739uO9g68i0FE8Zr
B9Y6f1OMlTRRlia7Jc27SIwLrP/Xivs9ENB5BKRw+k9mFrqV5dBg2QSoTF0J82ww
CCUIgknJtGQAp9t6NNphwKO4zaw3d5KA5DIQ09VjT370J7YNqDXPZy1c/zvHVL+s
w40PsiuVombk06tD2Kr2D1f7LtwwEI9/McQzZUgWfVlAcDutq3rcXUD8fVs5sWUJ
m0/QgE3zp74Un4MQEnzb
=hSsy
-----END PGP SIGNATURE-----
Reply to: