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

Tue May 12 07:55:00 UTC 2015

Hi Malihe,

On Tue, May 12, 2015 at 09:27:36AM +0430, Malihe Asemani wrote:
> >
> > Did you created a GPG key?
> 
> The pkgos-setup-sbuild creates GPG key. Wrong part of this process was the
> uid information in the key. I dont know how can i configure
> pkgos-setup-sbuild  for creating a GPG key with my information. I think it
> is using User and Hostname for crating key-uid information. Anyway, I
> updated the key with the information which I had added to changelog before.
> Therefore, this problem is solved now. Thank you for your hint :)

Nice that this is solved.

> >
> >      cme fix dpkg-control
> >
> > which does a similar thing regarding formatting first.  After this I
> > would try the suggested `pkgos-reqsdiff`.  The rationale is that I
> > prefer generic packaging (see in Debian Med policy what packages are
> > needed to install cme).
> >
> Interesting tool ! I used it and push the results to git. Thank you.

Hmmm, did you really pushed or just commited and forgot to push by
chance?  I see:

commit 266df93ff2e60659fd7c6092dae73a1a875215b0
Author: Malihe Asemani <ml.asemani at gmail.com>
Date:   Thu May 7 11:05:06 2015 +0000

    Adapt watch file with tag-base-packaging

as last commit.

> > If you ask me please try also:
> >
> > ./debian/rules gen-orig-xz
> > gbp buildpackage
> >
> > This should also build the package without any wrapper.  I'd prefer at
> > least knowing what happens behind the scenes (even if gbp is also a
> > non-trival wrapper - but it is a generic packaging tool working in all
> > teams).
> >
> first I used pkgos-reqdiff and then cme. Afterwards, I did 'debuild -us
> -uc', 'gpg buildpackage', and 'pkgos-bop'. if I remove
> "override_dh_auto_test" from the rule file,

Its a valid procedure to temporarily deactivate testing when developing
a package.  However, in the end we should approach to run the test suite
at build time.

> 'debuld -us -uc' and 'gbp
> buildpackage' will create the package with no more errors.

Seems you are using debuild / gbp on your local machine and not with
sbuild.  I tried using cowbuilder (an alternative to sbuild which I have
simply installed on my build machine) and was running into an issue.

The rationale why any serious package should be build in a minimal
chroot environment (which is what sbuild / cowbuilder are creating) is,
that any package should be able to build with the specified
Build-Dependends (and not additional random software installed on your
system) and *offline* since the build process should not depend from any
data fetched from some random location in the internet.

When doing so I'm running into the issue mentioned by Thomas:

   Depends: python-oslo-concurrency (>= 1.8.0) which is a virtual package.
   Depends: python-oslo-config (>= 1:1.9.3) which is a virtual package.
   Depends: python-oslo-context (>= 0.2.0) which is a virtual package.
   Depends: python-oslo-db (>= 1.7.0) which is a virtual package.
   Depends: python-oslo-i18n (>= 1.5.0) which is a virtual package.
   Depends: python-oslo-log (>= 1.0.0) which is a virtual package.
   Depends: python-oslo-messaging (>= 1.8.0) which is a virtual package.
   Depends: python-oslo-rootwrap (>= 1.6.0) which is a virtual package.
   Depends: python-oslo-serialization (>= 1.4.0) which is a virtual package.
   Depends: python-oslo-utils (>= 1.4.0) which is a virtual package.
Unable to resolve dependencies!  Giving up...

Please replace this by the python-oslo.* packages.  May be you just did
so and simply forgot to push?

> 'pkgos-bop' will
> create package too, but just it fails in the steps after creating package:
> 
> Finished running lintian.
> Now signing changes and any dsc files...
>  signfile manila_2015.1.0-1~bpo80+1.dsc Malihe Asemani <ml.asemani at gmail.com
> >
> 
>  signfile manila_2015.1.0-1~bpo80+1_amd64.changes Malihe Asemani <
> ml.asemani at gmail.com>
> 
> Successfully signed dsc and changes files
> HEAD is now at df2a176 remove test part
> W: python-manila: latest-debian-changelog-entry-without-new-version
> P: python-manila: no-homepage-field
> W: manila-common: latest-debian-changelog-entry-without-new-version
> P: manila-common: no-homepage-field
> P: manila-common: maintainer-script-without-set-e postinst
> W: manila-scheduler: latest-debian-changelog-entry-without-new-version
> P: manila-scheduler: no-homepage-field
> W: manila-api: latest-debian-changelog-entry-without-new-version
> P: manila-api: no-homepage-field

Try `lintian -i` (as well as the relevant severity levels since P is not
default but helpful anyway) if you need a more detailed explanation what
this means and how to fix it.  As always feel free to ask if something
remains unclear.

The good thing is, that you now *have* a package at least which is some
point we can continue working from. :-)

> ===> Updating schroot jessie-amd64
> jessie-amd64: Performing update.
> Hit http://mirror.xamin.ir jessie InRelease
> Hit http://mirror.xamin.ir jessie/main Sources
> Hit http://mirror.xamin.ir jessie/main amd64 Packages
> Hit http://mirror.xamin.ir jessie/main Translation-en
> Ign http://kilo-jessie.pkgs.mirantis.com jessie-kilo-backports-nochange
> InRelease
> Ign http://kilo-jessie.pkgs.mirantis.com jessie-kilo-backports InRelease
> Get:1 http://kilo-jessie.pkgs.mirantis.com jessie-kilo-backports-nochange
> ...

Looks as if pkgos tools also do the backporting here.  While this is
nice it does not bring us forward in *learning* how to package.  May be
it makes sense to skip this somehow for the moment to save time and come
back once we are successful with a package for unstable.

> FAIL:
> unittest.loader.ModuleImportFailure.manila.tests.network.neutron.test_neutron_plugin
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> _StringException: Traceback (most recent call last):
> ImportError: Failed to import test module:
> manila.tests.network.neutron.test_neutron_plugin
> 
> FAIL:
> unittest.loader.ModuleImportFailure.manila.tests.share.drivers.netapp.dataontap.client.test_client_cmode
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> _StringException: Traceback (most recent call last):
> ImportError: Failed to import test module:
> manila.tests.share.drivers.netapp.dataontap.client.test_client_cmode
> 
> FAIL:
> unittest.loader.ModuleImportFailure.manila.tests.share.drivers.netapp.dataontap.cluster_mode.test_lib_multi_svm
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> _StringException: Traceback (most recent call last):
> ImportError: Failed to import test module:
> 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).

Kind regards and nice that you are making progress

      Andreas.

-- 
http://fam-tille.de