Need help

[Daniel Baumann]

Christophe Monniez wrote:
> I don't know how to handle that problem

I've fixed those in galleta and pasco, and uploaded them.

> and I'm affraid of making mistakes.

Stopp worring. We're using a version control. You cannot make errors.
And even if you do, those can be reverted (if needed, even including the
history). So, just be bold.. I do read the commit diffs, and if I see
something that can be improved, I'll of course let you know.

> I also need help for another kind of problem:
> there is a new upstream version of grokevt. I send a mail to David
> Paleino who is the first maintainer/uploader.
> He told me to take the package because he is not interested anymore in
> Debian forensics.

how comes?

> The problem is that I don't know how to handle new upstream versions.
> If someone can give here the steps to do it the right way, it would be
> of great help.

that's easy..

first.. import the new upstream version on the upstream branch:

git checkout upstream
rm * -rf
<unpack the new upstream tarball into the directory>
git add .
git commit -a -m "Adding upstream version ${new_upstream_version}."
git tag -a -m "Tagging upstream version ${new_upstream_version}."
upstream/${new_upstream_version}
git push
git push --tags

second.. import the orig.tar.gz:

pristine-tar commit ../foo_${new_upstream_version}.orig.tar.gz

third.. merge the new upstrema version on the debian branch:

there are two ways; a 'normal' way and a 'cheap&dirty' way.

first, the normal way:

git checkout debian
git merge --no-commit --squash upstream/${new_upstream_version}

git will then tell you if the merge was possible, or if there are any
conflicts you need to fix. if the merge went well (or if there were
conflicts and you resolved them), commit them with:

git commit -a -m "Merging upstream version ${new_upstream_version}."

second, the 'cheap&dirty' way:

if and only iff the difference between the upstream branch and the
debian branch are only files inside debian/*; then you can do this
instead (which is much easier than fixing a couple of conflicts):

git checkout debian
mv debian ../
rm * -rf
<unpack upstreams orig.tar.gz here>
mv ../debian ./
git add .
git commit -a -m "Merging upstream version ${new_upstream_version}."

If there are unmerged files, those have to be removed with git rm bevor
git will allow you to commit.

I'm no git expert, probably there is a way with less commands to
acchieve the same, don't know.

> The last one is not really a problem but a general question:
> the libewf software (http://www.uitwisselplatform.nl/projects/libewf/)
> have two different branches:
> - libewf
> and
> - libewf-beta
> 
> The beta one is sometimes interesting and stable enough to replace the
> normal one.
> Is it a possible / a good idea to create a libewf-beta package ?
> Is it a common practice with other softwares ?

Generally, having two packages with different version of the same
upstream project in the archive is quite bad. If it is absolutely
required, then one can do that. I've done that with botan and
botan-devel for example (where API is not the same).

However, if your difference in library is more like general advantages
of newer versions, but they are interchangeable (means, a package built
against the one lib can also be used with the other lib, without the
need of a rebuild), then I would upload libewf stable to unstable, and
libewf beta versions to experimental, and upload the experimental
version to unstable when it is good enough. hm, have I confused you or
did you get it? :))

> I know that we are only a few to read this mailing list but I really
> need some help to go further.

yeah, I'm more visible again here from now on.. I had three really ruff
weeks.

-- 
Address:        Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:          daniel.baumann at panthera-systems.net
Internet:       http://people.panthera-systems.net/~daniel-baumann/