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

Tue May 12 09:27:38 UTC 2015

Hey Andreas,

On Tue, May 12, 2015 at 12:25 PM, Andreas Tille <andreas at an3as.eu> wrote:

> 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.
>
> Yes :)

> >
> > >      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.
>
> OMG! I'm really sorry. I've forgotten to push it! I push it just now.

> > > 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.
>
> uhum. Thanks for comment :)

> > '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 use all of these three ways to build the package.
It helps me to find out is the problem related to building the package, or
it is related to other processes like some special openstack or gbp process.

> 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?
>
> Yes. I've done it. and it is pushed now :P

> > '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.
>
> let me dig into that. I need time

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

> > ===> 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.
>
> Uhum. Agree.

> > 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).
>
> good hint. I will check Dependencies again.

> Kind regards and nice that you are making progress
>

Thank you for helping me to make some progress :)

Warmest regards,
Mali

>
>
      Andreas.
>
> --
> http://fam-tille.de
>
> _______________________________________________
> Openstack-devel mailing list
> Openstack-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/openstack-devel
>

-- 
------------
you can't start the next chapter if you keep re-reading the last one

mali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20150512/67956f65/attachment-0001.html>