* 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