* OE-Core Release Status
@ 2012-09-27 21:42 Richard Purdie
2012-09-28 18:02 ` Martin Jansa
0 siblings, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2012-09-27 21:42 UTC (permalink / raw)
To: openembedded-core
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.
Cheers,
Richard
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: OE-Core Release Status
2012-09-27 21:42 OE-Core Release Status Richard Purdie
@ 2012-09-28 18:02 ` Martin Jansa
2012-09-28 21:24 ` Richard Purdie
0 siblings, 1 reply; 4+ messages in thread
From: Martin Jansa @ 2012-09-28 18:02 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]
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
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@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@gmail.com>
commit 7173532f91a755911e4822a103c98e7b81b18cb6
Author: Martin Jansa <Martin.Jansa@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@gmail.com>
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: OE-Core Release Status
2012-09-28 18:02 ` Martin Jansa
@ 2012-09-28 21:24 ` Richard Purdie
2012-09-28 22:06 ` Martin Jansa
0 siblings, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2012-09-28 21:24 UTC (permalink / raw)
To: Martin Jansa; +Cc: openembedded-core
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 :(.
> 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@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@gmail.com>
Hmm, that might be ok...
> commit 7173532f91a755911e4822a103c98e7b81b18cb6
> Author: Martin Jansa <Martin.Jansa@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@gmail.com>
Doesn't the above fix obsolete this one?
Cheers,
Richard
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: OE-Core Release Status
2012-09-28 21:24 ` Richard Purdie
@ 2012-09-28 22:06 ` Martin Jansa
0 siblings, 0 replies; 4+ messages in thread
From: Martin Jansa @ 2012-09-28 22:06 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 4558 bytes --]
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@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@gmail.com>
>
> Hmm, that might be ok...
>
> > commit 7173532f91a755911e4822a103c98e7b81b18cb6
> > Author: Martin Jansa <Martin.Jansa@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@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@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-09-28 22:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-27 21:42 OE-Core Release Status Richard Purdie
2012-09-28 18:02 ` Martin Jansa
2012-09-28 21:24 ` Richard Purdie
2012-09-28 22:06 ` Martin Jansa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox