Re: New package maintainer (assistant)
Taking Ludovic out of CC to not bother him too much.
Felix Natter:
> There is a problem in "setup-repository":
> I get "[: 13: freeplane: unexpected operator" (but the script still
> works).
>
> It looks like for non-bash shells we need "=" instead of "==":
> if [ "$pkgname" = "" ]; then
Thank you for caching this. I think the pkg-java.git repo might be a good
place to put the setup-repository script in, along with my authors file,
convert-svn-tags-to-git.sh and maybe a convert-debian-java-svn.sh?
I have a convert-debian-java-svn.sh on my machine that needs polishing:
#!/bin/sh
PROJECT=$1
SVN_URL=svn://svn.debian.org/svn/pkg-java
echo converting project $PROJECT
git svn clone -A /tmp/pkg-java-authors --no-metadata \
-Ttrunk/$PROJECT -ttags/$PROJECT -bbranches/$PROJECT \
$SVN_URL $PROJECT
-----
> I probably need to create a new package "simplyhtml-freeplane". Is there
> a script that creates the basic files?
I either use mh_make from maven-debian-helper for maven projects or create all
files manually. But I'm dreaming of a much better toolset... :-)
> If I want to start with the "simplyhtml" files, how about the following
> (will document this in the wiki)?
>
> - ./setup-repsitory simplyhtml-freeplane (on git.debian.org...)
> - git clone
> git+ssh://fnatter-guest@git.debian.org/git/pkg-java/simplyhtml-freeplane.g
> it - add debian/...
This should fail at this point since there hasn't been any commit to the repo.
Your first interaction with the fresh repo should be a push.
> I guess it's not necessary to import the history from "simplyhtml"
> because this is a new package?
simplyhtml isn't a new package:
http://packages.qa.debian.org/s/simplyhtml.html
You mean simplyhtml-freeplane? What history should you import, if there's
nothing in svn.debian.org for this package?
Regarding the upstream history of simplyhtml on sourceforge. I think it's nice
to have upstream's git history in Debian's packaging git repo as the
"upstream" branch and the debian packaging in the master branch. New upstream
releases are then merged in the master branch. In an ideal world, the upstream
tarball would be the exact content of a git tag in upstreams repo. Sometimes I
need to manually the git commit from which the upstream tarball was created
and even make a new commit containing exactly the content of upstreams
tarball, e.g. for sshd[1].
[1] http://anonscm.debian.org/gitweb/?p=pkg-java/libmina-sshd-java.git
Some other examples:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589436#54
Regards,
Thomas Koch, http://www.koch.ro
Reply to: