On Mon, Jan 17, 2011 at 1:11 PM, Andreas Tille <email@example.com>
[Arvind, I hope you don't mind if I publish quotes from your private
mail to the public list. I do not really consider the information very
private and it is important to share the information. Otherwise you will
not get further helpful input of other mentors.]
Not an issue; I will mail the entire list in future.
Sure. No problem at all.
On Mon, Jan 17, 2011 at 09:00:50AM +0530, Arvind S Raj wrote:
> Also do forgive me if I'm asking really stupid questions-it's my first ever
> time at packaging and maintaining. Never done it before.
The Vcs fields in Debian are used by some applications and thus should be
> > - #Vcs-*
> > -> any reason why not just injecting the package to Vcs? I'm in
> > big favour of using team maintenance and thus I would really like
> > you to use the Vcs and set the Tags accordingly
> I thought it is sufficient to add the launchpad link since it takes you to
> their official page that also has the links to the source.
properly set. Launchpad is not used inside applications at any debian.org
Hmmmm, I admit I have no idea in how far sourceforge projects can do
> 1. I actually downloaded the source from sourceforge. They do their version
> control at launchpad. Do I have to add those links?
version control at launchpad. The sense of the Vcs tags in the Debian
package is to give links where *the* *Debian* *packaging* *stuff* (so
the content of your debian/ directory) is maintained. In collab-qa you
do not keep just another copy of upstream code but you maintain the code
which is for Debian exclusively and you should NOT maintain the debian/
directory in the upstream source tree (for several reasons discussed
several times before).
When using Git it is a matter of policy if you keep a clone of the
upstream code or not in collab-qa. In Svn usually only the debian/
directory is kept.
I further admit that I have no idea about bzr. If you want me to
> 2. They use bzr for version control and so when I add the line "Vcs-Bzr: bzr
> branch lp:openteacher", it highlights "bzr branch lp:openteacher" in red. Is
> there anything wrong in the way I specified the bzr branch?
sponsor openteacher I would like to ask you to stick to SVN or Git for
maintaining the debian/ dir. For the upstream code I do not need to
access the Vcs directly because only the tarball is used I do not care
at all about the Vcs.
Their development happens in launchpad but they release new source packages in sourceforge-at least the new version was released there. Also, a new version was released-2.0. It's no longer in beta. So, I will be packaging that from scratch now.
>If you would decide for a Vcs location at Alioth I could have a look...
> > - long description: <nitpicking mode on>Please do not add newlines
> > inbetween each single item, using two spaces in the beginning of a
> > line is sufficient to get the wanted pacing. It might disturb the
> > rendering in some applications<nitpicking mode off>
> Done; do take a look if the present changes are sufficient once I've
> uploaded. I've also changed the description a bit.
I have registered a project under the name openteacher at alioth. Awaiting review of the administrators.
> What do I add in the watch file? I assumed that upstream sources are alwaysTry
> in the archive format so what can I watch?
In Debian there exist tools to scan upstream websites for new releases
to inform the maintainer that he needs to package this new version.
I will update the watch page in the new packaging that I will upload soon as I have created uploaded debian/ to alioth.
$ lintian openteacher_2.0beta2-1_amd64.deb
> > debian/opentecher.1: Manpage needs to be installed
> What did you mean by needs to be installed? I didn't get you.
W: openteacher: binary-without-manpage usr/bin/openteacher
To fix this you want to add a file
with the content
(see man dh_installman) to make sure that the manpage you provided is
actually moved to the package.
Hope this helps