> 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
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 c
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 complemen
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
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
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 jus
[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 provi
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 ne
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
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 bu
10 matches
Mail list logo
