Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation
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.
Reply to: