[OE-core] OE-Core Release Status

[Martin Jansa]

On Fri, Sep 28, 2012 at 10:24:14PM +0100, Richard Purdie wrote:
> On Fri, 2012-09-28 at 20:02 +0200, Martin Jansa wrote:
> > On Thu, Sep 27, 2012 at 10:42:46PM +0100, Richard Purdie wrote:
> > > We're now at -rc2 for the October release of OE-Core. I've noticed a
> > > sudden surge of patches on the list, several of which are things like
> > > version increments which are no longer really appropriate at this point
> > > in the release cycle.
> > > 
> > > Why haven't we branched?
> > > 
> > > The plus side of branching now would be continued patches into master.
> > > The downside is that QA and autobuilder resources are concentrating on
> > > release and hence not on ensuring regressions are being added. I also
> > > really need my energy focused on the release rather than reviewing other
> > > code. I'm out of bandwidth so I'm putting off branching.
> > > 
> > > There is also the risk that if we branch, people will continue with
> > > master development and ignore the release branch and I'd like to apply a
> > > little pressure against this.
> > > 
> > > So if patches are getting ignored its likely they've been deemed not
> > > suited to the state of the tree right now. I may start to queue things
> > > on master-next but no guarantees and I would ask people to try and help
> > > make the release a good one.
> > > 
> > > If there are patches being ignored you think do qualify for -rcX, please
> > > ping me as it is hard to keep track of everything.
> > 
> > I don't know what to do with tune* and qt patchset.
> > 
> > This one is not important, but if you like the idea then it would be
> > better to get it in this release already:
> > [PATCH] kernel.bbclass: include PE in KERNEL_IMAGE_BASE_NAME
> 
> The trouble is this close to release, this will likely break the
> autobuilder or qemu scripts or something like that. We can't just rename
> output like that without quite a bit of checking :(.

OK I would expect qemu-scripts to use KERNEL_IMAGE_SYMLINK_NAME link not
version specific KERNEL_IMAGE_BASE_NAME directly.

> > And I have 2 patches to remove time dependent variables from images
> > which I haven't sent to ML yet, because still testing if it has some bad
> > sideeffect and if it's enough to resolve the issue I was seeing.
> > I'll send them as RFC.
> > 
> > commit 9c65f68dc380be34f06c4677d6867bbb874a75d1
> > Author: Martin Jansa <Martin.Jansa at gmail.com>
> > Date:   Wed Sep 26 15:56:05 2012 +0200
> > 
> >     bitbake.conf: exclude DATETIME var dependency from IMAGE_NAME
> >     
> >     * resolves ERROR shown when bitbake -S is used for image:
> >       ERROR: Bitbake's cached basehash does not match the one we just generated
> >       (/OE/oe-core/openembedded-core/meta/recipes-core/images/core-image-minimal.bb.do_rootfs)!
> >       ERROR: The mismatched hashes were 8c35cdf8a5d09c03941f081dd9f6d8dc and b5d6e2e5952770557c48c5779ddb73fc
> >     
> >     Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> 
> Hmm, that might be ok...
> 
> > commit 7173532f91a755911e4822a103c98e7b81b18cb6
> > Author: Martin Jansa <Martin.Jansa at gmail.com>
> > Date:   Wed Sep 26 00:57:21 2012 +0200
> > 
> >     rootfs_*.bbclass: exclude BUILDNAME var dependency from do_rootfs
> >     
> >     * I have kernel recipe which depends on other recipe to build tiny initramfs
> >       image, without this change it rebuilds not only that initramfs image
> >       but also whole kernel when DATE or TIME is changed and OEBasicHash enabled
> >     * also resolves ERROR shown when bitbake -S is used for image:
> >       ERROR: Bitbake's cached basehash does not match the one we just generated
> >       (/OE/oe-core/openembedded-core/meta/recipes-core/images/core-image-minimal.bb.do_rootfs)!
> >       ERROR: The mismatched hashes were 8c35cdf8a5d09c03941f081dd9f6d8dc and b5d6e2e5952770557c48c5779ddb73fc
> >     
> >     Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> 
> Doesn't the above fix obsolete this one?

No, rootfs is doing:
echo ${BUILDNAME} > ${IMAGE_ROOTFS}/${sysconfdir}/version

So patch above resolved 1 difference shown by bitbake-diffsigs, this is
2/2 to resolve other one. Now they have same hash in filename, 
but still it sometimes shows that error about "Bitbake's cached basehash
does not match the one we just generated" but both sigdata files have
the same hash :/ (bitbake-diffsigs is still showing different
BUILDNAME).

Cheers,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120929/22725691/attachment-0002.sig>