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: [EMAIL PROTECTED] Internet: http://people.panthera-systems.net/~daniel-baumann/ _______________________________________________ forensics-devel mailing list forensics-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/forensics-devel