[Dev] orphan-packaging model

Markus Lehtonen markus.lehtonen at linux.intel.com
Thu Sep 4 11:53:14 GMT 2014


On Thu, 2014-09-04 at 13:08 +0200, Patrick Ohly wrote:
> On Thu, 2014-09-04 at 12:52 +0300, Markus Lehtonen wrote:
> > 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:


> > >"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:

Oh, it is that. Need to investigate that...

> $ 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

which is caused by the missing upstream branch...

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

Yes, it needs to work. Strange that gbs export with --include-all seems
to work fine but build fails.

> > >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"?

The patches must be listed in the .spec file. The idea in this model is
that the spec file in the packaging branch really is under the full
control of the user. Gbs export just tries to help the user by adding
patch tags and macros to the spec. But, the user needs to commit the
changes himself/herself. Gbs devel export should be needed only at the
point one wants to release the software.

The idea is that the packaging branch contains all packaging meta data
as is needed for building (e.g. with rpmbuild) except for the upstream
source tarball.

> > >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?

Yes, there needs to be local upstream branch. I agree that gbs should be
more intelligent in this. Also, it might make sense to create a
configuration option for this so that one could force native or
non-native in the package-specific .gbs.conf.

> I created one, didn't change
> anything.

Looking at the .gbs.conf in libphonenumber:
upstream_branch = origin

So gbs looks for branch "origin" instead of "upstream"

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

Create branch named "origin" or change .gbs.conf.


More information about the Dev mailing list