[PKG-Openstack-devel] [MoM] Packaging manila

[Thomas Goirand]

On 05/12/2015 11:57 AM, Andreas Tille wrote:
> Hi Malihe,
>
> I have a quite formal hint for you.  You seem to use the GMail web
> interface for your mails (which is your decision).  This interface is
> known to have trouble problems inserting the proper quoting and so
> sometimes I see some mix of quoting marks in your responses.  You could
> do your fellow readers a favour by doing the following:
>
>    1. <Ctrl>-A  (to mark the whole text)
>    2. Click the small Tx icon on the edit control line at the bottom
>       to switch to text mode
>
> This will insert proper '> ' strings and you can be safe that the
> quotation remains the same at the receiving end as in your mail
> composition.  Thanks in advance for this.

I agree that it's been *very* hard to read replies!

> On Tue, May 12, 2015 at 01:57:38PM +0430, Malihe Asemani wrote:
>>> Looks as if pkgos tools also do the backporting here.

Yes they do, because that's the only target which we can make sure will 
work 100%. What I do is that I work on the latest stable Debian, then 
only do some checks in Sid to make sure nothing broke. Usually, this is 
revealed by running the unit tests.

Though the "backporting" process of pkgos-bop is only the part which 
insert the last debian/changelog entry. If you run in Sid, it's useless, 
but it will still build correctly.

> So may be you go with `gbp buildpackage` for the testing process and
> switch later to pkgos-* tools.  This should be possible since I've got
> the same build result this way.

Yeah. Though the nice thing about pkgos-bop is that it runs lintian with 
a profile which wont report the usual false-positives, and then it will 
populate a local Debian repository with the newly built package. So it 
doesn't just only build...

>>> manila.tests.share.drivers.netapp.dataontap.cluster_mode.test_lib_multi_svm
>>>
>>> Hmmmm.  I admit this goes beyond my knowledge.  May be Debian Openstack
>>> people could give a hint here or you might ask upstream.  It might
>>> mean a missing (Build-)Dependency (either packaged or missing).
>>>
>>> good hint. I will check Dependencies again.
>
> It even could be a *versioned* dependency that might lead to the
> problem.  My hint also went into the direction:  Try to find a proper
> forum and ask.  I could even imagine that "waiting" is a succesful
> approach since Thomas is way more competent in this field than me
> and he is quite responsive here.

My hint here is to try to do:

python -c "import 
manila.tests.share.drivers.netapp.dataontap.client.test_client_cmode"

and see what's the error. I did that, and could see:

ImportError: No module named lxml

Result: please add python-lxml as build-depends-indep.

BTW, please do run pkgos-reqsdiff, it will show lots of issues. Note 
that you need to run pkgos-fetch-fake-repo so that pkgos-reqsdiff can 
use madison-lite using the versions in Jessie, otherwise it wont be able 
to report versions correctly.

If you didn't get it, pkgos-reqsdiff does a diff between the dependency 
parts which is in your debian/control (try to use 
pkgos-show-control-depends), and what it calculates using the 
requirements.txt and tests-requirements.txt (try pkgos-parse-requirements).

The part on top (the Build-Depends:) is nearly always the same, so it's 
calculated using some static heuristics, like: does the package has 
debconf templates? Does it has python3 support? Stuff like that...

Again, this isn't a magic tool, but a helper for you, as a package 
maintainer, to use and check if you didn't forget anything. For example 
here, it wouldn't have show you the missing python-lxml 
Build-Depends-Indep:, as upstream didn't declare it at all.

I hope this helps...

Cheers,

Thomas Goirand (zigo)