Hi. Sorry it took so late to reply. I've been busy.
> I created 2 tags (v0.34 and v0.34-2, the later for some corrections I > had to make in the debian-directory). One minor note: there's nothing inherently wrong here, but your life will be a bit easier if you avoid - in your upstream version strings. Debian packages have version UPSTREAM-DEBIAN. For instance: dima@shorty:~$ dpkg -l firefox ... ii firefox 122.0-1 amd64 Mozilla Firefox web browser So this is the firefox 122.0 release from upstream, and it's the first package release. If the package was modified, but shipping the same 122.0 release, the next version would be 122.0-2, and so on. So avoiding - in upstream versions would make this easy. > I created a release on gitlab. Should I create it on salsa too? No. You tag a release upstream. Then you import that release tarball into salsa. The "gbp import-orig" command in the last email should do everything: update the 3 branches, make the upstream/VERSION tag, etc. I don't see the tags in your salsa repo, and I see you were manually cleaning up some stuff in the "upstream" branch. You can manage this repo however you like, but following conventions will make it easier to collaborate. Look at the version control of other packages to see examples. > I created the branch pristine-tar (took me some time to find out how it > works ...). The master-branch ist called "main" in my repository. Is > that ok? It does take a bit of time to figure out how to work the tools and what the conventions are. Definitely look at other packages, and experiment with the tools. The "gbp-import-orig" manpage says that the master branch default is "master". If that's correct, then you'll need a gbp.conf file to tell it that "main" is the branch name. Or just call it "master". >> Sure. Try to make a debianized repository as I described above, and >> let me know when you're done. Or if you need help. > > Perhaps you could check if everthing is fine: > https://salsa.debian.org/blutz/galvani > https://gitlab.com/b.lutz1/galvani Sorry, I don't have the cycles to do this quickly right now. A quick look tells me that your upstream repo (the one on gitlab) doesn't just contain source. Unless there's a specific reason, the sources should be things you, the human, wrote. Here I see src/galvani: something the compiler made, and you did not write. I see src/Makefile: something autotools made, and you did not write. And so on. These are build products, and should be in your repo. There're probably others, like more generated autotools stuff. Do you really want to ship a po/Makefile.in.in? That's not a mistake? The least fun part of the debianization is writing the debian/copyright. This should ideally describe each file in the sources. You should "git grep -ir copyright" on your repo, and everything should end up in the copyright file. This can be long and tedious. Lots of stuff in m4/ is Copyrighted by the FSF. If you really need that stuff (do you?) it should be mentioned in the debian/copyright. Similar, stuff in po/ has various different copyrights that should be mentioned. > I'm looking forward to join the debian-science-team with my project. I > read the policy. What to do now? Sign in and/or subsribe to the > mailing list? Yeah. Subscribe to the list, move your project to salsa.debian.org/science-team/, update the Maintainer: and Uploader: fields, etc.