[Dev] orphan-packaging model

Patrick Ohly patrick.ohly at intel.com
Thu Sep 4 11:08:18 GMT 2014


On Thu, 2014-09-04 at 12:52 +0300, Markus Lehtonen wrote:
> Hi,
> 
> On 04/09/14 12:23, "Patrick Ohly" <patrick.ohly at intel.com> wrote:
> 
> >On Thu, 2014-09-04 at 03:12 +0000, Lv, RuiX wrote:
> >> Hi Patrick,
> >> 
> >> The convert action only create the orphan packaging branch which only
> >>contains packaging info.
> >> Thus, you need to create the corresponding development branch that
> >> contains libphonenumber source code with `gbs devel start`.
> >> 
> >> Please follow the following procedure, I've verified it on my side.
> >> 
> >> 1. Clone the package and switch to it.
> >> 
> >> $ git clone tizen: platform/upstream/libphonenumber
> >> $ cd libphonenumber
> >> $ git br
> >> * accepted/tizen_common
> >> 
> >> 2. Convert to orphan-packaging model
> >> 1) Create packaging branch.
> >> $ gbs devel convert
> >> $ git br 
> >>   accepted/tizen_common
> >> * accepted/tizen_common-orphan
> >> 2) Create development branch
> >> $ gbs devel start
> >> $ git br
> >>   accepted/tizen_common
> >>   accepted/tizen_common-orphan
> >> * development/accepted/tizen_common-orphan/5.3.2
> >> 
> >> 3. Do development on development branch and export patches to packaging
> >>branch.
> >> # Do local development.
> >
> >I did exactly that, and then I got stuck because of one key issue: how
> >is one supposed to do local development now?
> >
> >"gbs build" fails:
> >
> >info: generate repositories ...
> >info: build conf has been downloaded at:
> >      /work/tizen/tmp/gbs/pohly-gbs/common.conf
> >info: start building packages from: /tmp/libphonenumber (git)
> >2014-09-04 06:06 +0000
> >gbs 0.22.2
> >error: No source package found at /tmp/libphonenumber
> >error: <gbs>some packages failed to be built
> >
> >Patches are applied, but without "gbs build", one is limited to
> >compiling on the host system, which is not the same as compiling for
> >Tizen and not possible for many Tizen specific packages.
> 
> GBS build is supposed to work. What do you have in your ~/gbs.conf and
> what command line are you using to build the package (plain "gbs build"
> should be enough)?

It's the --include-all which is causing the failure above. With
--include-all:

$ gbs build --profile common -A i586 --include-all
info: generate repositories ...
info: build conf has been downloaded at:
      /work/tizen/tmp/gbs/pohly-gbs/common.conf
info: start building packages from: /tmp/libphonenumber (git)
2014-09-04 10:26 +0000
gbs 0.22.2
error: No source package found at /tmp/libphonenumber
error: <gbs>some packages failed to be built

Without --include-all I get the same failure as on the packaging branch:

$ schroot -c trusty-amd64 -- gbs build --profile common -A i586
info: generate repositories ...
info: build conf has been downloaded at:
      /work/tizen/tmp/gbs/pohly-gbs/common.conf
info: start building packages from: /tmp/libphonenumber (git)
2014-09-04 10:26 +0000
gbs 0.22.2
info: prepare sources...
info: start export source from: /tmp/libphonenumber ...
info: It seems you're building a development/patch-queue branch. Export
target changed to 'accepted/tizen_common-orphan' and patch-export
enabled!
info: Creating (native) source archive libphonenumber-5.3.2.tgz from
'accepted/tizen_common-orphan'
info: package files have been exported to:
     /work/tizen/GBS-ROOT-profile.common/local/sources/common/libphonenumber-5.3.2-1
...
[    2s] + echo 'Patch #0
(0001-fix-compiler-warnings-about-signed-unsigned-int-cons.patch):'
[    2s] Patch #0
(0001-fix-compiler-warnings-about-signed-unsigned-int-cons.patch):
[    2s]
+ /bin/cat /home/abuild/rpmbuild/SOURCES/0001-fix-compiler-warnings-about-signed-unsigned-int-cons.patch
[    2s] + /bin/patch -p1 --fuzz=2
[    2s] can't find file to patch at input line 13

--with-all needs to work, because otherwise the development cycle gets
even longer: commit, compile, edit, commit amend, etc.

> >Is it necessary to add the patches in the .spec file on the packaging
> >branch? It would be better if that was left out of the .spec that that
> >users edit/commit and only add this when exporting to OBS or building.
> >The reason is that without adding/stripping the patches, the .spec file
> >really is under full control of the user and never changes under his
> >feet (see my comment about the editor above).

Just for my understanding: could the .spec file be left unmodified by
"gbs"?

> >Another nitpick: the "devel" subcommands are not symmetric. There's
> >"start", but where is "stop"? The corresponding command is a combination
> >of "export" and "drop". Once a development branch has been started, it
> >is not obvious how one can continue to use it. A second "gbs devel
> >start" complains and points to "git rebase", which is probably not the
> >right solution. I suspect that "git checkout <development branch>" would
> >be more appropriate.
> 
> Possibly the naming is confusing - gbs devel switch switches between the
> pacakaging and devel branches.

Thanks for pointing that out, I missed that subcommand. It might be
worth enhancing or fixing the "gbs start" error message when the
development branch already exists.

> As a side note, the devel branches in Tizen could be permanent, too. I.e.
> the devel branch(es) would be in Gerrit (not just local) and developers
> would push their changes against that. Maintainer would then update the
> packaging branch (through review, as weel) and eventually submit the
> changes.

I agree, this might be useful.


> The above problem is caused by a missing upstream branch. GBS thinks
> the
> package is "native" and thus doesn't create a correct upstream tarball
> (but only makes a tarball out of the tip of packaging branch).

But there is an "origin/upstream" branch. Are you saying that there also
needs to be a local "upstream" branch? I created one, didn't change
anything.

So how to I convince gbs that libphonenumber is not native?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.





More information about the Dev mailing list