5:06 a.m.
This will not a full patch E-mail, since the only thing that affects
the rest of baserock is glib.
I have a branch on baserock:baserock/morphs named
baserock/xfce-build-rebase-2. It has two commits:
* the first one adds in morphs for building an Xfce system
* the second one updates glib to a newer version (because the Xfce
system requires a newer version of glib), and changes all the stratum
refs to point to the changed morphologies.
I have performed the following tests:
* Build a devel-system-x86_64-generic
* Deploy devel-system-x86_64-generic and test that a programme that
uses glib still works - in this case, I started the
node-startup-controller and checked that it did not raise errors.
* Build a devel-system-armv7b-highbank
* Deploy devel-system-armv7b-highbank and test the
node-startup-controller didn't break
5:12 a.m.
On Mon, Sep 30, 2013 at 11:06:07AM +0100, Jonathan Maw wrote:
This will not a full patch E-mail, since the only thing that affects
the rest of baserock is glib.
I have a branch on baserock:baserock/morphs named
baserock/xfce-build-rebase-2. It has two commits:
* the first one adds in morphs for building an Xfce system
* the second one updates glib to a newer version (because the Xfce
system requires a newer version of glib), and changes all the stratum
refs to point to the changed morphologies.
I have performed the following tests:
* Build a devel-system-x86_64-generic
* Deploy devel-system-x86_64-generic and test that a programme that
uses glib still works - in this case, I started the
node-startup-controller and checked that it did not raise errors.
* Build a devel-system-armv7b-highbank
* Deploy devel-system-armv7b-highbank and test the
node-startup-controller didn't break
I am OK to merge this: merge the stratum changes into master of
baserock:baserock/morphs, and merge the newer glib into the branch in
upstream:glib that we currently use. if the glib merge fails and
cannot be easily fixed, create a new branch for the new version.
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
5:17 a.m.
On Mon, Sep 30, 2013 at 11:12:54AM +0100, Lars Wirzenius wrote:
I am OK to merge this: merge the stratum changes into master of
baserock:baserock/morphs, and merge the newer glib into the branch in
upstream:glib that we currently use. if the glib merge fails and
cannot be easily fixed, create a new branch for the new version.
The glib branch did not merge nicely (because it's not a fast-forward,
since our current glib is from a stable branch), so I created a
baserock/master branch. Last Friday, it was suggested that I could git
merge using the merge-strategy 'theirs' (or alternatively 'ours'), so
I would like you input on whether I should try to merge or stick to
the baserock/master branch I created.
5:21 a.m.
On Mon, Sep 30, 2013 at 11:17:14AM +0100, Jonathan Maw wrote:
On Mon, Sep 30, 2013 at 11:12:54AM +0100, Lars Wirzenius wrote:
>
> I am OK to merge this: merge the stratum changes into master of
> baserock:baserock/morphs, and merge the newer glib into the branch in
> upstream:glib that we currently use. if the glib merge fails and
> cannot be easily fixed, create a new branch for the new version.
>
The glib branch did not merge nicely (because it's not a fast-forward,
since our current glib is from a stable branch), so I created a
baserock/master branch. Last Friday, it was suggested that I could git
merge using the merge-strategy 'theirs' (or alternatively 'ours'), so
I would like you input on whether I should try to merge or stick to
the baserock/master branch I created.
I can live with either solution, though I would like it if we only had
one baserock/ branch we build from. Can you give merging with 'theirs'
a quick try and if it works, we'll do that?
--
http://www.codethink.co.uk/ http://wiki.baserock.org/ http://www.baserock.com/
5:51 a.m.
On Mon, Sep 30, 2013 at 11:21:03AM +0100, Lars Wirzenius wrote:
On Mon, Sep 30, 2013 at 11:17:14AM +0100, Jonathan Maw wrote:
> On Mon, Sep 30, 2013 at 11:12:54AM +0100, Lars Wirzenius wrote:
> >
> > I am OK to merge this: merge the stratum changes into master of
> > baserock:baserock/morphs, and merge the newer glib into the branch in
> > upstream:glib that we currently use. if the glib merge fails and
> > cannot be easily fixed, create a new branch for the new version.
> >
>
> The glib branch did not merge nicely (because it's not a fast-forward,
> since our current glib is from a stable branch), so I created a
> baserock/master branch. Last Friday, it was suggested that I could git
> merge using the merge-strategy 'theirs' (or alternatively 'ours'),
so
> I would like you input on whether I should try to merge or stick to
> the baserock/master branch I created.
I can live with either solution, though I would like it if we only had
one baserock/ branch we build from. Can you give merging with 'theirs'
a quick try and if it works, we'll do that?
I successfully merged against baserock/morph by emulating the
merge-strategy 'theirs' (by using the merge-strategy 'ours' backwards)
and it had an identical tree-sha1, thus having the same cache key.
I am pushing the merged baserock/morph branch now, and will submit the
xfce morphs for review (although I understand they have a low standard
for merging, since they're not first-class citizens)
3462
days inactive
3462
days old
4 comments
2 participants
participants (2)
-
Jonathan Maw -
Lars Wirzenius