Re: Naming convention for -doc package
> For instance, I have a source package (pytest-qt) which builds a Python > 3 binary package and its corresponding documentation. Right now, they > are respectively named python3-pytest-qt and pytest-qt-doc. I'd use python-modulename-doc even for new packages that provide python3-modulename binary package only BTW, it's pytestqt, not pytest-qt so binary package name for Python 3 should be python3-pytestqt (source name: pytest-qt) > Shall we keep the current python- prefix (as per Python the language, > not Python 2 the version) that would be my pick -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Naming convention for -doc package
On Thu, 2017-02-09 at 18:58 -0500, Sandro Tosi wrote: > On Thu, Feb 9, 2017 at 5:40 PM, Ghislain Vaillant wrote: > > On Thu, 2017-02-09 at 16:51 -0500, Sandro Tosi wrote: > > > On Thu, Feb 9, 2017 at 3:17 PM, Ghislain Vaillant > > > wrote: > > > > Now that new packages are targeting the Buster cycle, and that Python 2 > > > > packages should no longer be built, > > > > > > this is news to me, can you point me to where this was announced? > > > > Announced, I don't know. But: > > > > https://lintian.debian.org/tags/new-package-should-not-package-python2-module.html > > > > Unless I am missing something? > > this was triggered by > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829744 -- sigh Thanks for finding it out. So based on #829744, both pytest-qt and pytest-xvfb, which are new packages, do not produce a corresponding Python 2 binary package. Back to the original question, what about the naming for -doc packages? Ghis
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Nikolaus Rath writes: > But it seems to me that you are contemplating whether or not the team > should be using dgit. This is also not a decision that needs to be made > prior to any switch away from dgit-dpm, you can start using dgit at any > point. My vague understanding is that dgit complements the workflow, whatever workflow you may want - including git-dpm and pq. Hence I was surprised and confused when people said it only supported the single patch model - I don't think this is correct. My attempt to build a package (in this case pq based) was less then successful. Possibly because I am not awake. [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git sbuild --verbose Format `3.0 (quilt)', need to check/update patch stack examining quilt state (multiple patches, gbp mode) dgit: split brain (separate dgit view) may be needed (--quilt=gbp). dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea dgit: quilt differences: src: ## orig ## gitignores: == orig == dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p dgit: --quilt=gbp specified, implying patches-unapplied git tree dgit: but git tree differs from orig in upstream files. This error puzzles me, to me it seems to be saying there is a mismatch between git with patches unapplied and the *.orig.tar.gz file - however I don't think this is the case. -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Scott Kitterman writes: > How is that different/better than debcheckout? I am still learning dgit, however I think that dgit uses its own git repositories. dgit-repos. I am not sure where these are located or how access is controlled. >From the man page for push "This will push your git history to the dgit-repos, but you probably want to follow it up with a push to alioth." -- Brian May
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
On 2017-02-10 21:11:42, Brian May wrote: > Scott Kitterman writes: > > > How is that different/better than debcheckout? > > I am still learning dgit, however I think that dgit uses its own git > repositories. dgit-repos. I am not sure where these are located or how > access is controlled. dgit indeed is using it's own repos: https://browse.dgit.debian.org/ git.dgit.debian.org All DDs are having RW access, but I'm not sure how exactly it's done, service is managed by DSA from what I know. -- |_|0|_| | |_|_|0| "Panta rei" | |0|0|0| kuLa | gpg --keyserver pgp.mit.edu --recv-keys 0x686930DD58C338B3 3DF1 A4DF C732 4688 38BC F121 6869 30DD 58C3 38B3 signature.asc Description: PGP signature
Re: Naming convention for -doc package
On Fri, Feb 10, 2017 at 4:33 AM, Ghislain Vaillant wrote: > So based on #829744, both pytest-qt and > pytest-xvfb, which are new packages, do not produce a corresponding > Python 2 binary package. my point is: this looks wrong and premature, and should have been discussed more broadly and not just lamby submitting a bug report to lintian, and thus getting it already kind-of-official -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi G+: https://plus.google.com/u/0/+SandroTosi
Re: Re: Naming convention for -doc package
[Piotr Ożarowski] > > For instance, I have a source package (pytest-qt) which builds a Python > > 3 binary package and its corresponding documentation. Right now, they > > are respectively named python3-pytest-qt and pytest-qt-doc. > > I'd use python-modulename-doc even for new packages that provide > python3-modulename binary package only Ok. > BTW, it's pytestqt, not pytest-qt so binary package name for Python 3 > should be python3-pytestqt (source name: pytest-qt) Considering pytest plugins aren't meant to be used directly, but by pytest via the registered entry-point, using "pytestqt" over "pytest- qt" for the binary package sounded unnecessary to me. And yes, I do know there is a policy and I follow it closely. In this particular case however, we would be breaking the consistency between the naming of the other pytest plugins for no obvious benefit to me. > > Shall we keep the current python- prefix (as per Python the language, > > not Python 2 the version) > > that would be my pick So given your criteria above, you would choose: - python3-pytestqt - python-pytestqt-doc Am I correct? Is everyone happy with that? Cheers, Ghis
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
Brian May writes: > [brian:~/tree … modules/factory-boy] master 255 ± dgit --gbp --clean=git > sbuild --verbose > Format `3.0 (quilt)', need to check/update patch stack > examining quilt state (multiple patches, gbp mode) > dgit: split brain (separate dgit view) may be needed (--quilt=gbp). > dgit: base trees orig=3b9eaf2cb2a9245a1c10 o+d/p=6f1d04c157a8cd0a7eea > dgit: quilt differences: src: ## orig ## gitignores: == orig == > dgit: quilt differences: HEAD ## o+d/p HEAD == o+d/p > dgit: --quilt=gbp specified, implying patches-unapplied git tree > dgit: but git tree differs from orig in upstream files. > > This error puzzles me, to me it seems to be saying there is a mismatch > between git with patches unapplied and the *.orig.tar.gz file - however > I don't think this is the case. Ok, so there really was a difference: the git archive was missing the "docs/_static/.keep_dir" file that is included in the upstream file. Probably good that dgit detects discrepancies such as these, however not so good that it took me sometime to work out the problem based on the given message. If it told me what was different, it would be much be helpful. (also leads to the question why this file was missing from my import last month - but I can't remember what I did now) When I did build the package I can confirm that the generated source package had multiple patch files (as expected). -- Brian May
Re: Naming convention for -doc package
Ghislain Vaillant writes: > So given your criteria above, you would choose: > > - python3-pytestqt > - python-pytestqt-doc > > Am I correct? That allows a future ‘python4-pytestqt’ to use the same documentation. So far, the overwhelming pattern is that upstream's documentation does not come in separate versions for different Python platforms. It's the same Py.test QT documentation, regardless of Python version. The corresponding Debian packages of documentation should not be named by any Python version, either. > Is everyone happy with that? I am. -- \ “Smoking cures weight problems. Eventually.” —Steven Wright | `\ | _o__) | Ben Finney
Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)
kuLa writes: > dgit indeed is using it's own repos: > https://browse.dgit.debian.org/ > git.dgit.debian.org The way I understand it is that dgit is simply a replacement for the upload operation. To implement this with the required checks, it is recommended (but not required) that you use its build operation. Instead of using "dput" or similar, you use "dgit push". This checks the most recent build and makes sure it was built correctly from git HEAD, and then uploads the build to debian *and* the source to git.dgit.debian.org Apart from build and upload there are no other changes to standard git-dpm or gbp pq procedures. This provides one key benefit for us, we can be reasonably confident that the upload corresponds with a published git source. As an example of an existing dgit package with multiple patches, have a look at Samba: https://browse.dgit.debian.org/samba.git/tree/debian/patches Having said that, it looks like the server might be having problems at the moment, I can't clone any packages. [brian:/tmp] % dgit clone samba canonical suite name for unstable is sid fetching existing git history remote: fatal: Out of memory, calloc failed remote: aborting due to possible repository corruption on the remote side. fatal: protocol error: bad pack header dgit: failed command: git fetch -p -n -q https://git.dgit.debian.org/samba '+refs/tags/archive/debian/*:refs/dgit-fetch/debian/tags/archive/debian/*' '+refs/tags/debian/*:refs/dgit-fetch/debian/tags/debian/*' '+refs/dgit/sid:refs/dgit-fetch/debian/dgit/sid' dgit: subprocess failed with error exit status 128 -- Brian May
