OE-Core Release Status
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
Quoted 17 lines · Richard Purdie
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.
Quoted 7 lines
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 <[email protected]> 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
commit 7173532f91a755911e4822a103c98e7b81b18cb6
Author: Martin Jansa <[email protected]> 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
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 23 lines · Martin Jansa
Quoted 22 lines · Richard Purdie
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.
Quoted 8 lines
Quoted 2 lines
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 inKERNEL_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 :(.
Quoted 9 lines
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
9c65f68dc380be34f06c4677d6867bbb874a75d1Author: Martin Jansa <[email protected]> Date: Wed Sep 26 15:56:05 2012 +0200
Quoted 8 lines
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 were8c35cdf8a5d09c03941f081dd9f6d8dcandb5d6e2e5952770557c48c5779ddb73fcSigned-off-by Martin Jansa <[email protected]>
Hmm, that might be ok...
Quoted 14 lines
commit
7173532f91a755911e4822a103c98e7b81b18cb6Author: Martin Jansa <[email protected]> Date: Wed Sep 26 00:57:21 2012 +0200rootfs_*.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 were8c35cdf8a5d09c03941f081dd9f6d8dcandb5d6e2e5952770557c48c5779ddb73fc
Quoted 1 line
Signed-off-by Martin Jansa <[email protected]>
Doesn't the above fix obsolete this one?
Cheers,
Richard
Quoted 29 lines · Richard Purdie
Quoted 28 lines · Martin Jansa
Quoted 17 lines · Richard Purdie
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.
Quoted 7 lines
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.
Quoted 7 lines
Quoted 3 lines
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 inKERNEL_IMAGE_BASE_NAMEThe 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.
Quoted 34 lines
Quoted 9 lines
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
9c65f68dc380be34f06c4677d6867bbb874a75d1Author: Martin Jansa <[email protected]> Date: Wed Sep 26 15:56:05 2012 +0200Quoted 8 lines
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 were8c35cdf8a5d09c03941f081dd9f6d8dcandb5d6e2e5952770557c48c5779ddb73fcSigned-off-by Martin Jansa <[email protected]>Hmm, that might be ok...
Quoted 14 lines
commit
7173532f91a755911e4822a103c98e7b81b18cb6Author: Martin Jansa <[email protected]> Date: Wed Sep 26 00:57:21 2012 +0200rootfs_*.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 were8c35cdf8a5d09c03941f081dd9f6d8dcandb5d6e2e5952770557c48c5779ddb73fc
Quoted 3 lines
Quoted 1 line
Signed-off-by Martin Jansa <[email protected]>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,
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]