Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Barry Warsaw]

On Aug 15, 2016, at 11:44 PM, Thomas Goirand wrote:

>If we decide to use gbp-pq, in fact, we're deciding to not decide, and anyone
>can use PoQ (my choice, for example). Indeed, the way to store the patches is
>PoQ, and you then "gbp-pq import", modify, then "gbp-pq export" and store the
>packaging branch like this (ie: like a PoQ branch). So, basically, we'll be
>back to what everyone else is doing (ie: 99% of git maintained packages in
>Debian as much as I saw).

That sounds perfect then!

>IMO, that's required if we decide to continue using pristine-tar (which
>I don't think is a good idea, but let's not discuss that, as there seem
>to be a consensus for it).

So at a minimum:

gbp.conf
[import-orig]
pristine-tar = True
gbp.conf

Looking at my ~/.gbp.conf file, I have a bunch of other entries, some of which
are probably not appropriate for team settings.  I'd suggest `sign-tags=True`
though.

*Maybe* also these as conveniences:

[import-orig]
postimport = gbp dch -N%(version)s
import-msg = New upstream release.

What else?

Cheers,
-Barry


pgp_uaUuGilbj.pgp
Description: OpenPGP digital signature

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT

[Thomas Goirand]

On 08/10/2016 10:41 PM, Barry Warsaw wrote:
> * IOW, if
>   you choose to use gbp-pq, am I forced to do so when I modify the same repo?
>   Or if you choose to use PoQ (plain 'ol quilt), will that affect how others
>   can co-maintain the package in git?

That's the point. If we decide to use gbp-pq, in fact, we're deciding to
not decide, and anyone can use PoQ (my choice, for example). Indeed, the
way to store the patches is PoQ, and you then "gbp-pq import", modify,
then "gbp-pq export" and store the packaging branch like this (ie: like
a PoQ branch). So, basically, we'll be back to what everyone else is
doing (ie: 99% of git maintained packages in Debian as much as I saw).

On 08/11/2016 01:12 AM, Simon McVittie wrote:
> no other special metadata present in git (you can optionally commit a
>   debian/gbp.conf, and I would recommend it, but it isn't required)

IMO, that's required if we decide to continue using pristine-tar (which
I don't think is a good idea, but let's not discuss that, as there seem
to be a consensus for it).

On 08/11/2016 01:12 AM, Simon McVittie wrote:
> Not good for gbp-pq (it works OK, but an import/export round-trip will
> mangle the metadata if you don't take steps to preserve it):
>
> Author: Donald Duck 
> Description: Reticulate splines correctly
>  This regressed in 2.0.
>  .
>  In particular, this broke embiggening.
> Last-update: Fri, 01 Apr 2016 12:34:00 +0100
> Origin: vendor, Debian
> Forwarded: http://bugs.example.org/123
> ---
> [diff goes here]
>
> Regards,
> S

If this is what gbp pq does, then that's the *right* thing (I don't
remember, probably because it didn't destroy my Debian headers, which I
carefully crafted by hand...).

Cheers,

Thomas

Re: Help for Python mock test suite needed

[Ben Finney]

Andreas Tille  writes:

> Yes, this is what I guessed from the log.  However, how can I find out
> why exactly the command is not called?

That seems to be a question to take up with the upstream developer, or
just normal Python debugging.

Unless I'm misunderstanding, this doesn't appear to be a problem
specific to a Debian build environment, so I would guess it fails even
when simply running the test suite in a normal development environment.

So you can use the full power of your development environment to hunt
the problem: an interactive debugging session, etc. Use your Python
skills :-)

-- 
 \ “Broken promises don't upset me. I just think, why did they |
  `\ believe me?” —Jack Handey |
_o__)  |
Ben Finney

Re: BTS bot in #debian-python IRC channel

[Daniele Tricoli]

On Sunday, August 14, 2016 10:19:12 PM CEST Ondrej Novy wrote:
> +1 for moving VCS commits too.

+1 also from me! :)

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

signature.asc
Description: This is a digitally signed message part.

Re: Help for Python mock test suite needed

[Andreas Tille]

On Mon, Aug 15, 2016 at 05:00:52AM +1000, Ben Finney wrote:
> > https://paste.debian.net/789238/
> 
> That appears to be a simple failure when the test suite is run. The
> assertions, as reported, are in the ‘test_srst2’ module:
> 
> =
> […]
>   File "test_srst2.py", line 213, in test_run_bowtie_with_defaults
> run_mock.assert_called_once_with(expected_bowtie2_command)
>   File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 947, in 
> assert_called_once_with
> raise AssertionError(msg)
> AssertionError: Expected 'run_command' to be called once. Called 0 times.
> 
> […]
> 
>   File "test_srst2.py", line 180, in test_run_bowtie_with_overide
> run_mock.assert_called_once_with(expected_bowtie2_command)
>   File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 947, in 
> assert_called_once_with
> raise AssertionError(msg)
> AssertionError: Expected 'run_command' to be called once. Called 0 times.
> =
> 
> The tracebacks tell you what test case functions are emitting failures:
> 
>   File "test_srst2.py", line 213, in test_run_bowtie_with_defaults
>   File "test_srst2.py", line 180, in test_run_bowtie_with_overide
> 
> Within those test case functions you can see the exact command that was
> expected to be run. The assertion is that ‘srst2.run_command’ is
> expected to be called (with specific arguments), but is not called,
> hence the assertion fails.

Yes, this is what I guessed from the log.  However, how can I find out
why exactly the command is not called?

Kind regards

  Andreas.

-- 
http://fam-tille.de