uh, please don't break the threading AND change the subject, you are
lucky I didn't archive your email right away…
On Wed, Jun 06, 2018 at 03:33:29PM -0500, Mario Frasca wrote:
> > * d/changelog:
> ok, reduced to a single paragraph; urgency=low.
>
> so each time I dput a new one, I simply increment the counter behind the
> 0.0.x?
Well, it depends. whatever before the '-' is the upstream version, it
doesn't really matter to debian.
Anything after the '-' is the debian revision, and you bump it every
time you upload changes to the packaging without importing a new
upstream release.
https://www.debian.org/doc/debian-policy/#s-f-version
This also means you shouldn't be bumping the debian revision over -1
until it's uploaded to debian itself.
mentors.d.n supports uploading the same versions over and over, but it
then quickly get messy on the interface. Can I ask you to just delete
all the five uploads I can see on
https://mentors.debian.net/package/fibra and upload the next with -1,
and keep using that version?
> > * d/compat:
> I have no reason to use any specific version, I just kept what came in
> the template. I moved this to 10.
Why not 11, which is the latest?
> > * d/control:
> tons of warnings? no, not really. initially several, now just one which
> I could not remove:
> W: python-fibra: readme-debian-contains-debmake-template
That's of course unrelated to d/control, it's talking about
d/README.Debian.
This is what I get from your 0.0.20-3 uploaded today at 20:44:
I: fibra source: duplicate-short-description python-fibra python3-fibra
W: fibra source: ancient-python-version-field x-python-version 2.6
W: fibra source: ancient-python-version-field x-python3-version 3.2
I: fibra source: out-of-date-standards-version 3.9.8 (released 2016-04-06) (current is 4.1.4)
I: python-fibra: description-synopsis-might-not-be-phrased-properly "Advanced cooperative concurrency using Python generators."
W: python-fibra: new-package-should-not-package-python2-module python-fibra
I: python3-fibra: description-synopsis-might-not-be-phrased-properly "Advanced cooperative concurrency using Python generators."
> > * d/rules:
> removed useless comments
Also,
P: fibra source: file-contains-trailing-whitespace debian/rules (line 8)
> > * d/copyright:
> right, I didn't consider my work adding any value to fibra, but I can
> add my signature.
It doesn't really work like that.
https://www.debian.org/doc/debian-policy/#s-copyrightfile
d/copyright is the file that collects all the copyright claims and
license information from the upstream package. That means that any
copyright claim of yours on the upstream part needs to be done on the
upstream side (i.e. you'd need to cut a new release) and _then_ reported
in d/copyright. At any rate, that comment of mine about you not adding
yourself anywhere in the upstream part is more of your choice than
anything we impose.
> I do not know why the README states 2007. I used the timestamps of the
> versions published on PyPI, all in rather tight sequence. maybe that
> was the inception? I'll add 2009, and myself this year.
"timestamps of the versions published on PyPI" is very different than
the years of a copyright claim. Also PyPI is not the source package,
all the copyright claims and licenses details MUST be inside the
released tarballs (besides, not doing so usually goes against any
license rules).
From what I see in the package, there is only one claim for 2007,
nothing more.
> yes, I actually do mean to introduce the python2 package: bauble depends
> on it.
I see. Then please look at the description of lintian's
new-package-should-not-package-python2-module for how to deal with it.
> I need to make some time to re-read and understand what you mean by 'you
> should be building your package in a sid chroot', and how I should do
> that. lintian is being run every time after debuild, and where should I
> add those pedantic flags? `rules`?
mh, you use plain debuild on which distribution? Anyway, it clearly
doesn't belong to d/rules: this is a single person settings, and as such
it goes somewhere on your system. Given that you are deferring calling
lintian to debuild, it goes in debuild's configuration file, which means
~/.devscripts. See the manpage for debuild(1) for more details.
> the location for this package is https://github.com/mfrasca/fibra/
> is this what you were referring to, by "any VCS"?
Well, I mean the packaging VCS, which is usually different than the one
used by the upstream development.
https://www.debian.org/doc/debian-policy/#version-control-system-vcs-fields
It seems like this is not the case here and the repository is the same,
nonetheless please read that link and at the end of this email for more
details about that repository.
> 'gbp' to me sounds like Great Britain Pound, but I'm sure you don't mean
> that. so I guess I've never heard about the one you mean.
gbp is short for git-buildpackage (and the command line program is
called `gbp`). It simplifies importing new upstream tarballs into git
repositories and other stuff.
https://honk.sigxcpu.org/piki/projects/git-buildpackage/
Nonetheless, you are probably better off without for now, as it's yet
another tool that is true it's very handy, but it's clear that it
enforces a workflow that is very different than what you are doing now.
> As you surely understand and see, I'm quite new to publishing for
> Debian.
Yes :) But don't worry! ^^
> my focus is on developing software, and I'm now trying to get
> ghini.desktop/bauble/fibra into Debian myself more of out of despair
> than anything else, after so many years not managing to find anyone who
> could do this, and do this properly.
Let me help you and pull you out of your despair!
You have clearly come a long way by yourself, and this is a tiny simple
package so it's very handy to get accostumed to it.
Once you get the hang of it you'll see it's nothing particularly hard by
itself; alas the hardest parts are about policies and how to interact
with the rest of the project...
> I wrote myself a small helper script, that I hoped would allow me not
> need learning anything:
>
> https://github.com/mfrasca/fibra/blob/master/makedeb.sh
I see some big problems with that script:
1) you seem to be recreating the tarballs every single time: that's not
acceptable. Once you cut a release and upload the tarball to pypi,
that's it: you have to use that tarball you uploaded. Seriously
different tarballs are different versions, don't mix them.
2) you call dh_make, and I can't quite understand why. You already have
the packaging done in the debian/ directory, so dh_make's job is done
and good, time to ditch it
All in all I believe the problem you are having there is because you are
mixing the upstream development with the packaging part. The usual way
to deal with it by the same person is to keep the packaging part on a
different branch. Let me explain a bit the workflow I recommend here;
of course there are basically infinite variants, but I believe this is
good enough and simple at the same time:
- master branch: upstream stuff, no debian/ directory at all
- hack and stuff, commits in there with upstream stuff
- time to do an upstream release: bump version in setup.py, git tag,
run sdist to upload to pypi
- get a copy of the same tarball you uploaded to pypi in the parent
directory, and name it e.g. 'fibra_0.0.20.orig.tar.gz'
- `git clean -fdx` and clean it all up and checkout the 'debian' branch,
which is a descendant of the master branch, but contains the debian/
directory with the packaging. This is also called "packaging branch"
- `git merge v0.0.20` (or whatever you named the tag) to "import" the
upstream changes in the packaging branch
- `dch -v 0.0.20-1` to edit the changelog and note that you imported the
new upstream release.
- at this point you are able to call `debuild` and get the package built
debuild will use the tarball you put in .. just before
This makes possible to seperate the upstream stuff and the packaging
stuff, that really needs to be separated and not mixed up.
At this point, every change to the upstream stuff, will need to be made
on the master branch; equivalently, anything related to the packaging,
lives in the debian branch. At this point in time 0.0.20 is good as it
is (ok, IMHO it has the problem of not having a changelog and that
copyright thing, but those are my own opinion, and I'm not sure whether
it makes sense to do a new upstream release just for that, your choice).
Incidentally, uploads accepted in debian archive are usually tagged with
tags named like 'debian/0.0.20-1'.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature