-----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----- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5275422a.7060...@mail.dk
