Re: request more advice: lintian warnings and python-tldp + ldp-docbook-stylesheets
Hi,
(note: from now on I'll answer to the RFS bug :) )
>OK, great. I called it python3-tldp, given that the preferred
>Python support these days for Debian is Python3 (and I'm following
>tox and other examples).
yep
>My package builds and tests against Python2, but I don't plan on
>bothering to release that for Debian, unless somebody asserts that
>it is a good idea.
as you wish, just note: adding a new binary means another trip on debian new
queue, so you might want to have them both, because disabling it is just a matter
of commenting a few lines.
but this is up to you, and to your judgment about your reverse-dependencies
(are them all python3 ready?)
> * There's something called 'http://mentors.debian.net/'. I still
> don't know what to do with that, so I'll stay on the mailing
> list for now.
dpkg-buildpackage -S -sa
dput mentors ../file_version_source.changes
and give your mentors the link uploaded.
this means you can use a debian service to upload your source packages, with your gpg key
and your account.
I don't like fetching code outside debian services, because mentors has some nice features (e.g.
it strips binaries, it runs lintian, it checks your gpg key, and something more)
> * Though it is possible to generate a '3.0 (native)' package.
native means: this package is used only in Debian, for Debian purposes, it has no value outside it.
e.g. apt is native.
> https://lintian.debian.org/tags/library-package-name-for-application.html
>
>I created debian/python3-tldp.lintian-overrides with this as the
>sole contents. (It seems I'm in good company, since there are 719
>packages there.)
I'm not sure about overriding such tags, but well, you can leave it.
you just need to understand, if your package is more an application or more a python library
providing an application too.
(you can also provide a binary with the application only, depending on the actual python library)
>within the git history or via github.com, although I'd imagine it's
>possible, So, I'll try to learn that at some point. But, I'm hoping
>that is not a killer, since, as the upstream AND packager, I can
>sign the Debian package with my (new) 4096-bit RSA key (Mattia
>Rizzolo recommend this new key).
yep, for signing on github, just sign it, and in "releases" tab you should have some "upload additional files"
where you can upload it (I'm going through my memory)
>Yes, I see that. And, I see that I have to always do this for a
>Debian release.
yes, this avoids unwanted changes in the archive.
>I switched from debian/source/format: 3.0 (native) to 3.0 (quilt).
wonderful
> dget -x http://linux-ip.net/debian.ITP-822181/tldp_0.7.10-1.dsc
(please try next time to use mentors, it should be trivial to add an account and setup
your key there)
>N.B. My key does not exist on the stock /usr/share/keyrings/debian-keyring.gpg,
> so, for me, dscverify complains that no public key is available.
> Running 'gpg --verify tldp_0.7.10-1.dsc' succeeds, however.
don't worry about this :)
>Lastly, the newest tag (tldp-0.7.10) is available at the canonical
>location [4] with the subsequent changes to the ./debian/ directory
>to handle the packaging.
>
>What do I do next?
wait for somebody to pick up the RFS bug :)
cheers,
G.
Reply to: