Re: New package maintainer (assistant)
Thomas Koch <firstname.lastname@example.org> writes:
> 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
>> 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:
> echo converting project $PROJECT
> git svn clone -A /tmp/pkg-java-authors --no-metadata \
> -Ttrunk/$PROJECT -ttags/$PROJECT -bbranches/$PROJECT \
> $SVN_URL $PROJECT
One suggestion: place a:
echo "step x done" && read
after each step so that the user can check whether the previous command
executed without problems and check return value ($?) after each step.
And please let the user do the push command manually so that he/she can
run with --dry-run first and double-check the origin URL.
>> 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
>> 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.
Ok, so I have to create a local repo with debian/... and push the local
repo to the remote (like I did with the "cvt to svn" workflow).
>> I guess it's not necessary to import the history from "simplyhtml"
>> because this is a new package?
> simplyhtml isn't a new package:
> You mean simplyhtml-freeplane? What history should you import, if there's
> nothing in svn.debian.org for this package?
My question was: "there is already a simplyhtml package, and I want to
create a variant simplyhtml-freeplane, should I use the debian package
dev history from 'simplyhtml' in 'simplyhtml-freeplane'?"
Sorry for not being clear.
Hopefully I won't need the simplyhtml-freeplane 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.
>  http://anonscm.debian.org/gitweb/?p=pkg-java/libmina-sshd-java.git
Thanks (but this is a bit too much for me right now).
Concerning the import of the upstream source into the debian pkg repo:
I guess you create an upstream source tarball and use "git-import-orig"
to merge this into the 'upstream' branch of the debian git repo.
Looking at "Import upstream" from the wiki: why do you merge the
upstream source into the master branch when it is already in the
upstream branch (and thus is redundant)?
I also have a question concerning this (it's not clear from the wiki):
"You may want to make two imports with git-import-orig for each new
upstream tarball. The first import is without any filtering and saves
the original tarball as it for later reference. The second import adds a
"+dfsg" suffix to the tarball, filters all jar files and is the one
actually uploaded to debian."
=> this would make sense with freeplane and its many jar dependencies.
Are you suggesting to use a different --upstream-branch
(i.e. "upstream-with-jars", is there a naming convention?) for the
import without filtering?
Is there more documentation about git-buildpackage / git-import-orig /
... other than the man pages that I should read?
(I'd like to find out more in order to try out the "git workflow"
and explain it on the wiki more verbosely)
Thanks and Best Regards,