* Master stability update @ 2011-01-25 22:07 Richard Purdie 2011-01-26 2:45 ` Xu, Dongxiao ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Richard Purdie @ 2011-01-25 22:07 UTC (permalink / raw) To: poky We merged the features into master. I just want to highlight the status of the following issues: * pseudo problem causing failure of meta-toolchain and corruption of certain file permissions - fixed in master * the -live image issues some people and the autobuilder were seeing - fixed in master * the perf issue for linux-yocto-stable - fixed in master The following are know issues with master: * Using rm_work and switching machines to machines of the same "multimachine" architecture breaks. * When switching machines of the same "multimachine" architecture (e.g. emenlow to atom-pc), some sstate packages are changing checksums when at first glance they shouldn't (e.g. perl do_install). A quick scan of my sstate directory: $ ls *core2* | sed -e 's#core2-2-.*_#core2-2_#' | sort | uniq -cd | grep -v siginfo yields: 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-ipk.tgz 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-rpm.tgz 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_package.tgz 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_populate-sysroot.tgz 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-ipk.tgz 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-rpm.tgz 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_package.tgz 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_populate-sysroot.tgz 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-ipk.tgz 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-rpm.tgz 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_package.tgz 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_populate-sysroot.tgz 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-ipk.tgz 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-rpm.tgz 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_package.tgz 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_populate-sysroot.tgz 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-ipk.tgz 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-rpm.tgz 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_package.tgz 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_populate-sysroot.tgz 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-ipk.tgz 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-rpm.tgz 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_package.tgz 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_populate-sysroot.tgz which isn't too bad but shows there are some issues creeping in there. These need investigating and fixing, there is a strong rpm theme going on there. Also note this was just a minimal image, sato will likely reveal other issues. Cheers, Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-25 22:07 Master stability update Richard Purdie @ 2011-01-26 2:45 ` Xu, Dongxiao 2011-01-26 2:52 ` Tian, Kevin 2011-01-26 6:58 ` Saul Wold 2011-01-27 12:45 ` Koen Kooi 2 siblings, 1 reply; 21+ messages in thread From: Xu, Dongxiao @ 2011-01-26 2:45 UTC (permalink / raw) To: Richard Purdie, poky Richard Purdie wrote: > We merged the features into master. I just want to highlight the > status of the following issues: > > * pseudo problem causing failure of meta-toolchain and corruption of > certain file permissions - fixed in master > > * the -live image issues some people and the autobuilder were seeing > - fixed in master > > * the perf issue for linux-yocto-stable - fixed in master > > The following are know issues with master: > > * Using rm_work and switching machines to machines of the same > "multimachine" architecture breaks. After sysroot is per machine, we may need to reserve the "image" folder even when rm_work, since for the second machine build, do_populate_sysroot and do_package will be re-run to populate files into a different sysroot folder. > > * When switching machines of the same "multimachine" architecture > (e.g. > emenlow to atom-pc), some sstate packages are changing checksums when > at first glance they shouldn't (e.g. perl do_install). A quick scan > of my sstate directory: I also have a look at my local build sstate directories, there are 17 packages whose prebuilt result could not shared betweeen atom-pc and emenlow. Some of them may be not a problem since there are ${MACHINE} variables used in do_install(), some others are strange why do_install will have two different signatures between two different machines. I will spend some time investigating it. Thanks, Dongxiao > > $ ls *core2* | sed -e 's#core2-2-.*_#core2-2_#' | sort | uniq -cd | > grep -v siginfo > > yields: > > 2 > > > > > > > > > > > > > > > > > > > > > > > > sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-ipk.tgz > 2 > sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-rpm.tgz > 2 > sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_package.tgz > 2 > sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_populate-sysroot.tgz > 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-ipk.tgz 2 > sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-rpm.tgz 2 > sstate-netbase-core2-poky-linux-4.44-r0-core2-2_package.tgz 2 > sstate-netbase-core2-poky-linux-4.44-r0-core2-2_populate-sysroot.tgz > 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-ipk.tgz 2 > sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-rpm.tgz 2 > sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_package.tgz 2 > sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_populate-sysroot.tgz 2 > sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-ipk.tgz 2 > sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-rpm.tgz 2 > sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_package.tgz 2 > sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_populate-sysroot.tgz 2 > sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-ipk.tgz > 2 > sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-rpm.tgz > 2 > sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_package.tgz > 2 > sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_populate-sysroot.tgz > 2 > sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-ipk.tgz > 2 > sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-rpm.tgz > 2 > sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_package.tgz > 2 > sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_populate-sysroot.tgz > > which isn't too bad but shows there are some issues creeping in there. > These need investigating and fixing, there is a strong rpm theme > going on there. Also note this was just a minimal image, sato will > likely reveal other issues. > > Cheers, > > Richard > > _______________________________________________ > poky mailing list > poky@yoctoproject.org > https://lists.yoctoproject.org/listinfo/poky ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 2:45 ` Xu, Dongxiao @ 2011-01-26 2:52 ` Tian, Kevin 2011-01-26 3:05 ` Tian, Kevin 0 siblings, 1 reply; 21+ messages in thread From: Tian, Kevin @ 2011-01-26 2:52 UTC (permalink / raw) To: Xu, Dongxiao, Richard Purdie, poky > From: Xu, Dongxiao > Sent: Wednesday, January 26, 2011 10:46 AM > > Richard Purdie wrote: > > We merged the features into master. I just want to highlight the > > status of the following issues: > > > > * pseudo problem causing failure of meta-toolchain and corruption of > > certain file permissions - fixed in master > > > > * the -live image issues some people and the autobuilder were seeing > > - fixed in master > > > > * the perf issue for linux-yocto-stable - fixed in master > > > > The following are know issues with master: > > > > * Using rm_work and switching machines to machines of the same > > "multimachine" architecture breaks. > > After sysroot is per machine, we may need to reserve the "image" folder even > when rm_work, since for the second machine build, do_populate_sysroot and > do_package will be re-run to populate files into a different sysroot folder. > > > > > * When switching machines of the same "multimachine" architecture > > (e.g. > > emenlow to atom-pc), some sstate packages are changing checksums when > > at first glance they shouldn't (e.g. perl do_install). A quick scan > > of my sstate directory: > > I also have a look at my local build sstate directories, there are 17 packages > whose prebuilt result could not shared betweeen atom-pc and emenlow. Some > of them may be not a problem since there are ${MACHINE} variables used in > do_install(), some others are strange why do_install will have two different > signatures between two different machines. > > I will spend some time investigating it. > Note that checksum changes may not come from do_install itself, which including the hash from other tasks that do_install depends on. To capture the latter possibility, you can simply use "bitbake -S poky-image-minimal" which only generates .siginfo for all the tasks w/o actually running them. This way you can compare the difference between emenlow and atom-pc easily to see what actually change. Thanks Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 2:52 ` Tian, Kevin @ 2011-01-26 3:05 ` Tian, Kevin 2011-01-26 3:51 ` Mark Hatle 2011-01-26 3:52 ` Xu, Dongxiao 0 siblings, 2 replies; 21+ messages in thread From: Tian, Kevin @ 2011-01-26 3:05 UTC (permalink / raw) To: Tian, Kevin, Xu, Dongxiao, Richard Purdie, poky > From: Tian, Kevin > Sent: Wednesday, January 26, 2011 10:52 AM > > > From: Xu, Dongxiao > > Sent: Wednesday, January 26, 2011 10:46 AM > > > > Richard Purdie wrote: > > > We merged the features into master. I just want to highlight the > > > status of the following issues: > > > > > > * pseudo problem causing failure of meta-toolchain and corruption of > > > certain file permissions - fixed in master > > > > > > * the -live image issues some people and the autobuilder were seeing > > > - fixed in master > > > > > > * the perf issue for linux-yocto-stable - fixed in master > > > > > > The following are know issues with master: > > > > > > * Using rm_work and switching machines to machines of the same > > > "multimachine" architecture breaks. > > > > After sysroot is per machine, we may need to reserve the "image" folder > even > > when rm_work, since for the second machine build, do_populate_sysroot and > > do_package will be re-run to populate files into a different sysroot folder. > > > > > > > > * When switching machines of the same "multimachine" architecture > > > (e.g. > > > emenlow to atom-pc), some sstate packages are changing checksums when > > > at first glance they shouldn't (e.g. perl do_install). A quick scan > > > of my sstate directory: > > > > I also have a look at my local build sstate directories, there are 17 packages > > whose prebuilt result could not shared betweeen atom-pc and emenlow. > Some > > of them may be not a problem since there are ${MACHINE} variables used in > > do_install(), some others are strange why do_install will have two different > > signatures between two different machines. > > > > I will spend some time investigating it. > > > > Note that checksum changes may not come from do_install itself, which > including > the hash from other tasks that do_install depends on. To capture the latter > possibility, you can simply use "bitbake -S poky-image-minimal" which only > generates > .siginfo for all the tasks w/o actually running them. This way you can compare > the > difference between emenlow and atom-pc easily to see what actually change. > After a quick check, I guess this is not a problem. for example perl.do_configure changes checksum due to $MACHINE in dependency variables as Dongxiao said. Once perl is not reusable, at least ~10 recieps (libzypp, libtool, rpm, ...) are not reusable too because perl is in their task dependency chain. I didn't check all the differences yet, but overall feeling is that this should be OK as Dongxiao mentioned there're several obvious MACHINE related recipes. I'll leave to Dongxiao for final confirmation. :-) Thanks Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 3:05 ` Tian, Kevin @ 2011-01-26 3:51 ` Mark Hatle 2011-01-26 11:42 ` Richard Purdie 2011-01-26 3:52 ` Xu, Dongxiao 1 sibling, 1 reply; 21+ messages in thread From: Mark Hatle @ 2011-01-26 3:51 UTC (permalink / raw) To: Tian, Kevin; +Cc: poky On 1/25/11 9:05 PM, Tian, Kevin wrote: >> From: Tian, Kevin >> Sent: Wednesday, January 26, 2011 10:52 AM >> >>> From: Xu, Dongxiao >>> Sent: Wednesday, January 26, 2011 10:46 AM >>> >>> Richard Purdie wrote: >>>> We merged the features into master. I just want to highlight the >>>> status of the following issues: >>>> >>>> * pseudo problem causing failure of meta-toolchain and corruption of >>>> certain file permissions - fixed in master >>>> >>>> * the -live image issues some people and the autobuilder were seeing >>>> - fixed in master >>>> >>>> * the perf issue for linux-yocto-stable - fixed in master >>>> >>>> The following are know issues with master: >>>> >>>> * Using rm_work and switching machines to machines of the same >>>> "multimachine" architecture breaks. >>> >>> After sysroot is per machine, we may need to reserve the "image" folder >> even >>> when rm_work, since for the second machine build, do_populate_sysroot and >>> do_package will be re-run to populate files into a different sysroot folder. >>> >>>> >>>> * When switching machines of the same "multimachine" architecture >>>> (e.g. >>>> emenlow to atom-pc), some sstate packages are changing checksums when >>>> at first glance they shouldn't (e.g. perl do_install). A quick scan >>>> of my sstate directory: >>> >>> I also have a look at my local build sstate directories, there are 17 packages >>> whose prebuilt result could not shared betweeen atom-pc and emenlow. >> Some >>> of them may be not a problem since there are ${MACHINE} variables used in >>> do_install(), some others are strange why do_install will have two different >>> signatures between two different machines. >>> >>> I will spend some time investigating it. >>> >> >> Note that checksum changes may not come from do_install itself, which >> including >> the hash from other tasks that do_install depends on. To capture the latter >> possibility, you can simply use "bitbake -S poky-image-minimal" which only >> generates >> .siginfo for all the tasks w/o actually running them. This way you can compare >> the >> difference between emenlow and atom-pc easily to see what actually change. >> > > After a quick check, I guess this is not a problem. for example perl.do_configure > changes checksum due to $MACHINE in dependency variables as Dongxiao said. > Once perl is not reusable, at least ~10 recieps (libzypp, libtool, rpm, ...) are not > reusable too because perl is in their task dependency chain. > > I didn't check all the differences yet, but overall feeling is that this should be OK > as Dongxiao mentioned there're several obvious MACHINE related recipes. I'll > leave to Dongxiao for final confirmation. :-) It might be nice (if not a bit dangerous) to be able to say "I want perl version X.Y.Z. I don't really care about the checksum, as long as the version matches..." In the case of perl, this is likely to do exactly what we want/need. In the case of other packages (particularly libraries) this could cause serious problems... --Mark > Thanks > Kevin > _______________________________________________ > poky mailing list > poky@yoctoproject.org > https://lists.yoctoproject.org/listinfo/poky ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 3:51 ` Mark Hatle @ 2011-01-26 11:42 ` Richard Purdie 0 siblings, 0 replies; 21+ messages in thread From: Richard Purdie @ 2011-01-26 11:42 UTC (permalink / raw) To: Mark Hatle; +Cc: poky On Tue, 2011-01-25 at 21:51 -0600, Mark Hatle wrote: > On 1/25/11 9:05 PM, Tian, Kevin wrote: > >> From: Tian, Kevin > > After a quick check, I guess this is not a problem. for example perl.do_configure > > changes checksum due to $MACHINE in dependency variables as Dongxiao said. > > Once perl is not reusable, at least ~10 recieps (libzypp, libtool, rpm, ...) are not > > reusable too because perl is in their task dependency chain. > > > > I didn't check all the differences yet, but overall feeling is that this should be OK > > as Dongxiao mentioned there're several obvious MACHINE related recipes. I'll > > leave to Dongxiao for final confirmation. :-) > > It might be nice (if not a bit dangerous) to be able to say "I want perl version > X.Y.Z. I don't really care about the checksum, as long as the version matches..." > > In the case of perl, this is likely to do exactly what we want/need. In the > case of other packages (particularly libraries) this could cause serious problems... Adding "perl" to BB_HASHTASK_WHITELIST would do exactly what you describe so its at least possible although it doesn't cover a version specific match which would probably be better as part of DEPENDS handling. Stopping it being machine specific is the first thing that needs fixing though (I have a patch I'm testing for that one). Cheers, Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 3:05 ` Tian, Kevin 2011-01-26 3:51 ` Mark Hatle @ 2011-01-26 3:52 ` Xu, Dongxiao 2011-01-26 3:55 ` Xu, Dongxiao 2011-01-26 10:01 ` Richard Purdie 1 sibling, 2 replies; 21+ messages in thread From: Xu, Dongxiao @ 2011-01-26 3:52 UTC (permalink / raw) To: Tian, Kevin, Richard Purdie, poky Tian, Kevin wrote: >> From: Tian, Kevin >> Sent: Wednesday, January 26, 2011 10:52 AM >> >>> From: Xu, Dongxiao >>> Sent: Wednesday, January 26, 2011 10:46 AM >>> >>> Richard Purdie wrote: >>>> We merged the features into master. I just want to highlight the >>>> status of the following issues: >>>> >>>> * pseudo problem causing failure of meta-toolchain and corruption >>>> of certain file permissions - fixed in master >>>> >>>> * the -live image issues some people and the autobuilder were >>>> seeing - fixed in master >>>> >>>> * the perf issue for linux-yocto-stable - fixed in master >>>> >>>> The following are know issues with master: >>>> >>>> * Using rm_work and switching machines to machines of the same >>>> "multimachine" architecture breaks. >>> >>> After sysroot is per machine, we may need to reserve the "image" >>> folder >> even >>> when rm_work, since for the second machine build, >>> do_populate_sysroot and do_package will be re-run to populate files >>> into a different sysroot folder. >>> >>>> >>>> * When switching machines of the same "multimachine" architecture >>>> (e.g. emenlow to atom-pc), some sstate packages are changing >>>> checksums when at first glance they shouldn't (e.g. perl >>>> do_install). A quick scan of my sstate directory: >>> >>> I also have a look at my local build sstate directories, there are >>> 17 packages whose prebuilt result could not shared betweeen atom-pc >>> and emenlow. Some >>> of them may be not a problem since there are ${MACHINE} variables >>> used in do_install(), some others are strange why do_install will >>> have two different signatures between two different machines. >>> >>> I will spend some time investigating it. >>> >> >> Note that checksum changes may not come from do_install itself, which >> including the hash from other tasks that do_install depends on. To >> capture the latter possibility, you can simply use "bitbake -S >> poky-image-minimal" which only generates .siginfo for all the tasks >> w/o actually running them. This way you can compare the difference >> between emenlow and atom-pc easily to see what actually change. >> > > After a quick check, I guess this is not a problem. for example > perl.do_configure changes checksum due to $MACHINE in dependency > variables as Dongxiao said. > Once perl is not reusable, at least ~10 recieps (libzypp, libtool, > rpm, ...) are not reusable too because perl is in their task > dependency chain. > > I didn't check all the differences yet, but overall feeling is that > this should be OK as Dongxiao mentioned there're several obvious > MACHINE related recipes. I'll leave to Dongxiao for final > confirmation. :-) > > Thanks > Kevin Thanks Kevin for the suggestion which can quickly track down the issue. Within my poky-image-sdk and meta-toolchain-sdk build, there are totally 17 recipes in core2-poky-linux folder whose prebuilt result could not be shared between two machine of one architecture. They are: connman, kexec-tools, libzypp, sat-solver, rpm, perl, matchbox-keyboard, matchbox-panel-2, netbase, pulseaudio, screenshot, task-poky-sdk, tslib, xf86-input-evdev, xf86-input-keyboard, xf86-input-mouse, zypper. I used bitbake-diffsig tool to dump the sigdata, and results are: Connman: its do_configure depends on hal's do_populate_sysroot, while hal is a recipe of machine specific. Pulseaudio: its do_configure depends on hal's do_populate_sysroot, while hal is a recipe of machine specific. Kexec-tools: its do_configure depends on linux-yocto-stable's do_populate_sysroot, which is a machine specific recipe. Perl: ${MACHINE} in do_configure. Rpm: its do_configure depends on perl's do_populate_sysroot. Sat-solver: its do_configure depends on rpm's do_populate_sysroot. Libzypp: its do_configure depends on sat-solver's do_populate_sysroot. Zypper: its do_configure depends on libzypp's do_populate_sysroot Matchbox-panel-2: its do_configure contains "${MACHINE_FEATURES}" Matchbox-keyboard: its do_configure depends on matchbox-panel-2's do_populate_sysroot. Screenshot: its do_configure depends on matchbox-panel-2's do_populate_sysroot Task-poky-sdk: depends on matchbox-panel-2 Netbase: ${MACHINE} in do_install. Tslib: ${MACHINE} in do_install. Xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: xorg-xserver dependency differences, which emenlow has its own xorg-xserver layer. Here are some dependency graph for those recipes: hal -------> | connman | pulseaudio linux-yocto-stable -------> kexec-tools perl ------> rpm ------> sat-solver ------> libzypp ------> zypper matchbox-panel-2 ------> | matchbox-keyboard | screenshot | task-poky-sdk netbase tslib xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: xorg-xserver layer differences. Therefore I confirmed that the sstate prebuilt result change for the above 17 recipes are not a problem. Thanks, Dongxiao ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 3:52 ` Xu, Dongxiao @ 2011-01-26 3:55 ` Xu, Dongxiao 2011-01-26 10:01 ` Richard Purdie 1 sibling, 0 replies; 21+ messages in thread From: Xu, Dongxiao @ 2011-01-26 3:55 UTC (permalink / raw) To: Xu, Dongxiao, Tian, Kevin, Richard Purdie, poky Xu, Dongxiao wrote: > Tian, Kevin wrote: >>> From: Tian, Kevin >>> Sent: Wednesday, January 26, 2011 10:52 AM >>> >>>> From: Xu, Dongxiao >>>> Sent: Wednesday, January 26, 2011 10:46 AM >>>> >>>> Richard Purdie wrote: >>>>> We merged the features into master. I just want to highlight the >>>>> status of the following issues: >>>>> >>>>> * pseudo problem causing failure of meta-toolchain and corruption >>>>> of certain file permissions - fixed in master >>>>> >>>>> * the -live image issues some people and the autobuilder were >>>>> seeing - fixed in master >>>>> >>>>> * the perf issue for linux-yocto-stable - fixed in master >>>>> >>>>> The following are know issues with master: >>>>> >>>>> * Using rm_work and switching machines to machines of the same >>>>> "multimachine" architecture breaks. >>>> >>>> After sysroot is per machine, we may need to reserve the "image" >>>> folder >>> even >>>> when rm_work, since for the second machine build, >>>> do_populate_sysroot and do_package will be re-run to populate files >>>> into a different sysroot folder. >>>> >>>>> >>>>> * When switching machines of the same "multimachine" architecture >>>>> (e.g. emenlow to atom-pc), some sstate packages are changing >>>>> checksums when at first glance they shouldn't (e.g. perl >>>>> do_install). A quick scan of my sstate directory: >>>> >>>> I also have a look at my local build sstate directories, there are >>>> 17 packages whose prebuilt result could not shared betweeen atom-pc >>>> and emenlow. Some of them may be not a problem since there are >>>> ${MACHINE} variables used in do_install(), some others are strange >>>> why do_install will have two different signatures between two >>>> different machines. >>>> >>>> I will spend some time investigating it. >>>> >>> >>> Note that checksum changes may not come from do_install itself, >>> which including the hash from other tasks that do_install depends >>> on. To capture the latter possibility, you can simply use "bitbake >>> -S poky-image-minimal" which only generates .siginfo for all the >>> tasks w/o actually running them. This way you can compare the >>> difference between emenlow and atom-pc easily to see what actually >>> change. >>> >> >> After a quick check, I guess this is not a problem. for example >> perl.do_configure changes checksum due to $MACHINE in dependency >> variables as Dongxiao said. Once perl is not reusable, at least ~10 >> recieps (libzypp, libtool, rpm, ...) are not reusable too because >> perl is in their task dependency chain. >> >> I didn't check all the differences yet, but overall feeling is that >> this should be OK as Dongxiao mentioned there're several obvious >> MACHINE related recipes. I'll leave to Dongxiao for final >> confirmation. :-) >> >> Thanks >> Kevin > > Thanks Kevin for the suggestion which can quickly track down the > issue. > > Within my poky-image-sdk and meta-toolchain-sdk build, there are > totally 17 recipes in core2-poky-linux folder whose prebuilt result > could not be shared between two machine of one architecture. > > They are: connman, kexec-tools, libzypp, sat-solver, rpm, perl, > matchbox-keyboard, matchbox-panel-2, netbase, pulseaudio, screenshot, > task-poky-sdk, tslib, xf86-input-evdev, xf86-input-keyboard, > xf86-input-mouse, zypper. > > I used bitbake-diffsig tool to dump the sigdata, and results are: > > Connman: its do_configure depends on hal's do_populate_sysroot, while > hal is a recipe of machine specific. > Pulseaudio: its do_configure depends on hal's do_populate_sysroot, > while hal is a recipe of machine specific. > > Kexec-tools: its do_configure depends on linux-yocto-stable's > do_populate_sysroot, which is a machine specific recipe. > > Perl: ${MACHINE} in do_configure. > Rpm: its do_configure depends on perl's do_populate_sysroot. > Sat-solver: its do_configure depends on rpm's do_populate_sysroot. > Libzypp: its do_configure depends on sat-solver's do_populate_sysroot. > Zypper: its do_configure depends on libzypp's do_populate_sysroot > > Matchbox-panel-2: its do_configure contains "${MACHINE_FEATURES}" > Matchbox-keyboard: its do_configure depends on matchbox-panel-2's > do_populate_sysroot. > Screenshot: its do_configure depends on matchbox-panel-2's > do_populate_sysroot > Task-poky-sdk: depends on matchbox-panel-2 > > Netbase: ${MACHINE} in do_install. > Tslib: ${MACHINE} in do_install. > > Xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: > xorg-xserver dependency differences, which emenlow has its own > xorg-xserver layer. > > > > Here are some dependency graph for those recipes: > > hal -------> | connman > | pulseaudio > > linux-yocto-stable -------> kexec-tools perl ------> rpm ------> > sat-solver ------> libzypp ------> zypper > matchbox-panel-2 ------> | matchbox-keyboard > | screenshot > | task-poky-sdk netbase tslib > xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: > xorg-xserver layer differences. Re-draw the graph since outlook wrongly merges some lines together hal -------> | connman. | pulseaudio. linux-yocto-stable -------> kexec-tools. perl ------> rpm ------> sat-solver ------> libzypp ------> zypper. matchbox-panel-2 ------> | matchbox-keyboard. | screenshot. | task-poky-sdk. netbase. tslib. xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: xorg-xserver layer differences. Thanks, Dongxiao > > Therefore I confirmed that the sstate prebuilt result change for the > above 17 recipes are not a problem. > > Thanks, > Dongxiao > > > > > > _______________________________________________ > poky mailing list > poky@yoctoproject.org > https://lists.yoctoproject.org/listinfo/poky ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 3:52 ` Xu, Dongxiao 2011-01-26 3:55 ` Xu, Dongxiao @ 2011-01-26 10:01 ` Richard Purdie 2011-01-26 10:31 ` Tian, Kevin 1 sibling, 1 reply; 21+ messages in thread From: Richard Purdie @ 2011-01-26 10:01 UTC (permalink / raw) To: Xu, Dongxiao; +Cc: poky On Wed, 2011-01-26 at 11:52 +0800, Xu, Dongxiao wrote: > Tian, Kevin wrote: > >> From: Tian, Kevin > >> Sent: Wednesday, January 26, 2011 10:52 AM > >> > >>> From: Xu, Dongxiao > >>> Sent: Wednesday, January 26, 2011 10:46 AM > >>> > >>> Richard Purdie wrote: > >>>> We merged the features into master. I just want to highlight the > >>>> status of the following issues: > >>>> > >>>> * pseudo problem causing failure of meta-toolchain and corruption > >>>> of certain file permissions - fixed in master > >>>> > >>>> * the -live image issues some people and the autobuilder were > >>>> seeing - fixed in master > >>>> > >>>> * the perf issue for linux-yocto-stable - fixed in master > >>>> > >>>> The following are know issues with master: > >>>> > >>>> * Using rm_work and switching machines to machines of the same > >>>> "multimachine" architecture breaks. > >>> > >>> After sysroot is per machine, we may need to reserve the "image" > >>> folder > >> even > >>> when rm_work, since for the second machine build, > >>> do_populate_sysroot and do_package will be re-run to populate files > >>> into a different sysroot folder. > >>> > >>>> > >>>> * When switching machines of the same "multimachine" architecture > >>>> (e.g. emenlow to atom-pc), some sstate packages are changing > >>>> checksums when at first glance they shouldn't (e.g. perl > >>>> do_install). A quick scan of my sstate directory: > >>> > >>> I also have a look at my local build sstate directories, there are > >>> 17 packages whose prebuilt result could not shared betweeen atom-pc > >>> and emenlow. Some > >>> of them may be not a problem since there are ${MACHINE} variables > >>> used in do_install(), some others are strange why do_install will > >>> have two different signatures between two different machines. > >>> > >>> I will spend some time investigating it. > >>> > >> > >> Note that checksum changes may not come from do_install itself, which > >> including the hash from other tasks that do_install depends on. To > >> capture the latter possibility, you can simply use "bitbake -S > >> poky-image-minimal" which only generates .siginfo for all the tasks > >> w/o actually running them. This way you can compare the difference > >> between emenlow and atom-pc easily to see what actually change. > >> > > > > After a quick check, I guess this is not a problem. for example > > perl.do_configure changes checksum due to $MACHINE in dependency > > variables as Dongxiao said. > > Once perl is not reusable, at least ~10 recieps (libzypp, libtool, > > rpm, ...) are not reusable too because perl is in their task > > dependency chain. > > > > I didn't check all the differences yet, but overall feeling is that > > this should be OK as Dongxiao mentioned there're several obvious > > MACHINE related recipes. I'll leave to Dongxiao for final > > confirmation. :-) > > > > Thanks > > Kevin > > Thanks Kevin for the suggestion which can quickly track down the issue. > > Within my poky-image-sdk and meta-toolchain-sdk build, there are totally 17 recipes in core2-poky-linux folder whose prebuilt result could not be shared between two machine of one architecture. > > They are: connman, kexec-tools, libzypp, sat-solver, rpm, perl, matchbox-keyboard, matchbox-panel-2, netbase, pulseaudio, screenshot, task-poky-sdk, tslib, xf86-input-evdev, xf86-input-keyboard, xf86-input-mouse, zypper. > > I used bitbake-diffsig tool to dump the sigdata, and results are: > > Connman: its do_configure depends on hal's do_populate_sysroot, while hal is a recipe of machine specific. > Pulseaudio: its do_configure depends on hal's do_populate_sysroot, while hal is a recipe of machine specific. > > Kexec-tools: its do_configure depends on linux-yocto-stable's do_populate_sysroot, which is a machine specific recipe. > > Perl: ${MACHINE} in do_configure. > Rpm: its do_configure depends on perl's do_populate_sysroot. > Sat-solver: its do_configure depends on rpm's do_populate_sysroot. > Libzypp: its do_configure depends on sat-solver's do_populate_sysroot. > Zypper: its do_configure depends on libzypp's do_populate_sysroot > > Matchbox-panel-2: its do_configure contains "${MACHINE_FEATURES}" > Matchbox-keyboard: its do_configure depends on matchbox-panel-2's do_populate_sysroot. > Screenshot: its do_configure depends on matchbox-panel-2's do_populate_sysroot > Task-poky-sdk: depends on matchbox-panel-2 > > Netbase: ${MACHINE} in do_install. > Tslib: ${MACHINE} in do_install. > > Xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: xorg-xserver dependency differences, which emenlow has its own xorg-xserver layer. > So for each of these we need to decide if rebuilding is a valid or invalid thing to do. The one that jumps out at me is perl. Why does it need MACHINE in do_configure and is it really MACHINE dependent? If you look at the do_configure code, its a rather strange check against the "native" machine which we don't use/support. I'd argue that machine is error prone, problematic and replaced by our nativesdk code so I'm in favour of removing that check. Some of the other items above are trickier. In some cases we should perhaps be marking them as machine specific, e.g. mb-panel-2 ? and maybe also whitelisting some dependencies if we're sure those items don't change if the dependency changes. The nice thing is now that we can make something like mb-panel-2 machine specific and not have the whole world collapse as it would have done previously so we can start to benefit from this change! :) Cheers, Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 10:01 ` Richard Purdie @ 2011-01-26 10:31 ` Tian, Kevin 0 siblings, 0 replies; 21+ messages in thread From: Tian, Kevin @ 2011-01-26 10:31 UTC (permalink / raw) To: Richard Purdie, Xu, Dongxiao; +Cc: poky > From: Richard Purdie [mailto:richard.purdie@linuxfoundation.org] > Sent: Wednesday, January 26, 2011 6:01 PM > > On Wed, 2011-01-26 at 11:52 +0800, Xu, Dongxiao wrote: > > Tian, Kevin wrote: > > >> From: Tian, Kevin > > >> Sent: Wednesday, January 26, 2011 10:52 AM > > >> > > >>> From: Xu, Dongxiao > > >>> Sent: Wednesday, January 26, 2011 10:46 AM > > >>> > > >>> Richard Purdie wrote: > > >>>> We merged the features into master. I just want to highlight the > > >>>> status of the following issues: > > >>>> > > >>>> * pseudo problem causing failure of meta-toolchain and corruption > > >>>> of certain file permissions - fixed in master > > >>>> > > >>>> * the -live image issues some people and the autobuilder were > > >>>> seeing - fixed in master > > >>>> > > >>>> * the perf issue for linux-yocto-stable - fixed in master > > >>>> > > >>>> The following are know issues with master: > > >>>> > > >>>> * Using rm_work and switching machines to machines of the same > > >>>> "multimachine" architecture breaks. > > >>> > > >>> After sysroot is per machine, we may need to reserve the "image" > > >>> folder > > >> even > > >>> when rm_work, since for the second machine build, > > >>> do_populate_sysroot and do_package will be re-run to populate files > > >>> into a different sysroot folder. > > >>> > > >>>> > > >>>> * When switching machines of the same "multimachine" architecture > > >>>> (e.g. emenlow to atom-pc), some sstate packages are changing > > >>>> checksums when at first glance they shouldn't (e.g. perl > > >>>> do_install). A quick scan of my sstate directory: > > >>> > > >>> I also have a look at my local build sstate directories, there are > > >>> 17 packages whose prebuilt result could not shared betweeen atom-pc > > >>> and emenlow. Some > > >>> of them may be not a problem since there are ${MACHINE} variables > > >>> used in do_install(), some others are strange why do_install will > > >>> have two different signatures between two different machines. > > >>> > > >>> I will spend some time investigating it. > > >>> > > >> > > >> Note that checksum changes may not come from do_install itself, which > > >> including the hash from other tasks that do_install depends on. To > > >> capture the latter possibility, you can simply use "bitbake -S > > >> poky-image-minimal" which only generates .siginfo for all the tasks > > >> w/o actually running them. This way you can compare the difference > > >> between emenlow and atom-pc easily to see what actually change. > > >> > > > > > > After a quick check, I guess this is not a problem. for example > > > perl.do_configure changes checksum due to $MACHINE in dependency > > > variables as Dongxiao said. > > > Once perl is not reusable, at least ~10 recieps (libzypp, libtool, > > > rpm, ...) are not reusable too because perl is in their task > > > dependency chain. > > > > > > I didn't check all the differences yet, but overall feeling is that > > > this should be OK as Dongxiao mentioned there're several obvious > > > MACHINE related recipes. I'll leave to Dongxiao for final > > > confirmation. :-) > > > > > > Thanks > > > Kevin > > > > Thanks Kevin for the suggestion which can quickly track down the issue. > > > > Within my poky-image-sdk and meta-toolchain-sdk build, there are totally 17 > recipes in core2-poky-linux folder whose prebuilt result could not be shared > between two machine of one architecture. > > > > They are: connman, kexec-tools, libzypp, sat-solver, rpm, perl, > matchbox-keyboard, matchbox-panel-2, netbase, pulseaudio, screenshot, > task-poky-sdk, tslib, xf86-input-evdev, xf86-input-keyboard, xf86-input-mouse, > zypper. > > > > I used bitbake-diffsig tool to dump the sigdata, and results are: > > > > Connman: its do_configure depends on hal's do_populate_sysroot, while hal > is a recipe of machine specific. > > Pulseaudio: its do_configure depends on hal's do_populate_sysroot, while hal > is a recipe of machine specific. > > > > Kexec-tools: its do_configure depends on linux-yocto-stable's > do_populate_sysroot, which is a machine specific recipe. > > > > Perl: ${MACHINE} in do_configure. > > Rpm: its do_configure depends on perl's do_populate_sysroot. > > Sat-solver: its do_configure depends on rpm's do_populate_sysroot. > > Libzypp: its do_configure depends on sat-solver's do_populate_sysroot. > > Zypper: its do_configure depends on libzypp's do_populate_sysroot > > > > Matchbox-panel-2: its do_configure contains "${MACHINE_FEATURES}" > > Matchbox-keyboard: its do_configure depends on matchbox-panel-2's > do_populate_sysroot. > > Screenshot: its do_configure depends on matchbox-panel-2's > do_populate_sysroot > > Task-poky-sdk: depends on matchbox-panel-2 > > > > Netbase: ${MACHINE} in do_install. > > Tslib: ${MACHINE} in do_install. > > > > Xf86-input-evdev, xf86-input-keyboard, and xf86-input-mouse: xorg-xserver > dependency differences, which emenlow has its own xorg-xserver layer. > > > > So for each of these we need to decide if rebuilding is a valid or > invalid thing to do. > > The one that jumps out at me is perl. Why does it need MACHINE in > do_configure and is it really MACHINE dependent? If you look at the > do_configure code, its a rather strange check against the "native" > machine which we don't use/support. I'd argue that machine is error > prone, problematic and replaced by our nativesdk code so I'm in favour > of removing that check. > > Some of the other items above are trickier. In some cases we should > perhaps be marking them as machine specific, e.g. mb-panel-2 ? and maybe > also whitelisting some dependencies if we're sure those items don't > change if the dependency changes. > > The nice thing is now that we can make something like mb-panel-2 machine > specific and not have the whole world collapse as it would have done > previously so we can start to benefit from this change! :) > Yes, this at least proves that overall now we're in a good state with recent changes. :-) Your suggestions are good, and we'll continue look into them to reduce the machine specific bits as possible. Thanks Kevin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-25 22:07 Master stability update Richard Purdie 2011-01-26 2:45 ` Xu, Dongxiao @ 2011-01-26 6:58 ` Saul Wold 2011-01-26 7:01 ` Xu, Dongxiao 2011-01-27 12:45 ` Koen Kooi 2 siblings, 1 reply; 21+ messages in thread From: Saul Wold @ 2011-01-26 6:58 UTC (permalink / raw) To: Richard Purdie; +Cc: poky On 01/25/2011 02:07 PM, Richard Purdie wrote: > We merged the features into master. I just want to highlight the status > of the following issues: > > * pseudo problem causing failure of meta-toolchain and corruption of > certain file permissions - fixed in master > > * the -live image issues some people and the autobuilder were seeing - > fixed in master > > * the perf issue for linux-yocto-stable - fixed in master > > The following are know issues with master: > > * Using rm_work and switching machines to machines of the same > "multimachine" architecture breaks. > > * When switching machines of the same "multimachine" architecture (e.g. > emenlow to atom-pc), some sstate packages are changing checksums when at > first glance they shouldn't (e.g. perl do_install). A quick scan of my > sstate directory: > > $ ls *core2* | sed -e 's#core2-2-.*_#core2-2_#' | sort | uniq -cd | grep -v siginfo > > yields: > > 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-ipk.tgz > 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-rpm.tgz > 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_package.tgz > 2 sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_populate-sysroot.tgz > 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-ipk.tgz > 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-rpm.tgz > 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_package.tgz > 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_populate-sysroot.tgz > 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-ipk.tgz > 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-rpm.tgz > 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_package.tgz > 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_populate-sysroot.tgz > 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-ipk.tgz > 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-rpm.tgz > 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_package.tgz > 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_populate-sysroot.tgz > 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-ipk.tgz > 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-rpm.tgz > 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_package.tgz > 2 sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_populate-sysroot.tgz > 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-ipk.tgz > 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-rpm.tgz > 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_package.tgz > 2 sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_populate-sysroot.tgz > > which isn't too bad but shows there are some issues creeping in there. > These need investigating and fixing, there is a strong rpm theme going > on there. Also note this was just a minimal image, sato will likely > reveal other issues. > > Cheers, > > Richard > > _______________________________________________ > poky mailing list > poky@yoctoproject.org > https://lists.yoctoproject.org/listinfo/poky > We are looking pretty good after the nightly has been running, a couple of issues were discovered by the Autobuilder, but we are more stable than we have been for a while. Thanks to everyone for their hard work. Seems that we have a couple of additional issues that need to be addressed. 1) Recent changes to the send-pull-request have caused the problem with the email now coming from poky-bounces. * dvhart or sgarman should investigate this please 2) atom-pc connman failure, Dongxiao may have already submitted a patch 3) emenlow rootfs failure, may be related to zypper/rpm, need to verify with Mark and his patch. Thanks Sau! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-26 6:58 ` Saul Wold @ 2011-01-26 7:01 ` Xu, Dongxiao 0 siblings, 0 replies; 21+ messages in thread From: Xu, Dongxiao @ 2011-01-26 7:01 UTC (permalink / raw) To: Wold, Saul, Richard Purdie; +Cc: poky Saul Wold wrote: > On 01/25/2011 02:07 PM, Richard Purdie wrote: >> We merged the features into master. I just want to highlight the >> status of the following issues: >> >> * pseudo problem causing failure of meta-toolchain and corruption of >> certain file permissions - fixed in master >> >> * the -live image issues some people and the autobuilder were seeing >> - >> fixed in master >> >> * the perf issue for linux-yocto-stable - fixed in master >> >> The following are know issues with master: >> >> * Using rm_work and switching machines to machines of the same >> "multimachine" architecture breaks. >> >> * When switching machines of the same "multimachine" architecture >> (e.g. >> emenlow to atom-pc), some sstate packages are changing checksums when >> at first glance they shouldn't (e.g. perl do_install). A quick scan >> of >> my sstate directory: >> >> $ ls *core2* | sed -e 's#core2-2-.*_#core2-2_#' | sort | uniq -cd | >> grep -v siginfo >> >> yields: >> >> 2 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-ipk.tgz >> 2 >> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_deploy-rpm.tgz >> 2 >> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_package.tgz >> 2 >> sstate-libzypp-core2-poky-linux-0.0-git0+4494797d5b0369365b1af63921de45b197ead64f-r6-core2-2_populate-sysroot.tgz >> 2 sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-ipk.tgz 2 >> sstate-netbase-core2-poky-linux-4.44-r0-core2-2_deploy-rpm.tgz 2 >> sstate-netbase-core2-poky-linux-4.44-r0-core2-2_package.tgz 2 >> sstate-netbase-core2-poky-linux-4.44-r0-core2-2_populate-sysroot.tgz >> 2 sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-ipk.tgz 2 >> sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_deploy-rpm.tgz 2 >> sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_package.tgz 2 >> sstate-perl-core2-poky-linux-5.12.2-r0-core2-2_populate-sysroot.tgz >> 2 sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-ipk.tgz 2 >> sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_deploy-rpm.tgz 2 >> sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_package.tgz 2 >> sstate-rpm-core2-poky-linux-5.1.10-r8-core2-2_populate-sysroot.tgz 2 >> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-ipk.tgz >> 2 >> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_deploy-rpm.tgz >> 2 >> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_package.tgz >> 2 >> sstate-sat-solver-core2-poky-linux-0.0-git0+aa799f7bae0ec055e0e527203635001bb7346dbc-r2-core2-2_populate-sysroot.tgz >> 2 >> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-ipk.tgz >> 2 >> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_deploy-rpm.tgz >> 2 >> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be2439149d9ede37531-r3-core2-2_package.tgz >> 2 >> sstate-zypper-core2-poky-linux-1.4.7-git0+9eb0e248e06c8d20ad054be24391 >> 49d9ede37531-r3-core2-2_populate-sysroot.tgz >> >> which isn't too bad but shows there are some issues creeping in >> there. >> These need investigating and fixing, there is a strong rpm theme >> going >> on there. Also note this was just a minimal image, sato will likely >> reveal other issues. >> >> Cheers, >> >> Richard >> >> _______________________________________________ >> poky mailing list >> poky@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/poky >> > > We are looking pretty good after the nightly has been running, a > couple of issues were discovered by the Autobuilder, but we are more > stable than we have been for a while. > > Thanks to everyone for their hard work. > > Seems that we have a couple of additional issues that need to be > addressed. > > 1) Recent changes to the send-pull-request have caused the problem > with the email now coming from poky-bounces. * dvhart or sgarman > should investigate this please > > 2) atom-pc connman failure, Dongxiao may have already submitted a > patch This should be the same issue of doing "rm_work" when building the first machine (autobuilder inherits rm_work.bbclass). I just sent out a fix patch for review. Thanks, Dongxiao > > 3) emenlow rootfs failure, may be related to zypper/rpm, need to > verify with Mark and his patch. > > Thanks > Sau! > _______________________________________________ > poky mailing list > poky@yoctoproject.org > https://lists.yoctoproject.org/listinfo/poky ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-25 22:07 Master stability update Richard Purdie 2011-01-26 2:45 ` Xu, Dongxiao 2011-01-26 6:58 ` Saul Wold @ 2011-01-27 12:45 ` Koen Kooi 2011-01-27 15:06 ` Richard Purdie 2 siblings, 1 reply; 21+ messages in thread From: Koen Kooi @ 2011-01-27 12:45 UTC (permalink / raw) To: Richard Purdie; +Cc: poky Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: > The following are know issues with master: > > * Using rm_work and switching machines to machines of the same > "multimachine" architecture breaks. > > * When switching machines of the same "multimachine" architecture (e.g. > emenlow to atom-pc), some sstate packages are changing checksums when at > first glance they shouldn't (e.g. perl do_install). A After the fixes for those 2 went in builds from scratch fail with: ERROR: Logfile of failure stored in: /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 Log data follows: | automake (GNU automake) 1.9.6 | Written by Tom Tromey <tromey@redhat.com>. | | Copyright 2005 Free Software Foundation, Inc. | This is free software; see the source for copying conditions. There is NO | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. | AUTOV is 1.9 | NOTE: Executing autoreconf --verbose --install --force --exclude=autopoint -I /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/share/aclocal | /usr/bin/autoreconf2.50: unrecognized option `--exclude=autopoint' | Try `/usr/bin/autoreconf2.50 --help' for more information. | FATAL: autoreconf execution failed. | Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) It wants to use the autoreconf from my host, which doesn't have the `--exclude=autopoint' option since that's something OE patches in. After building autoconf native pseudo is gone! /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory After building pseudo-native again: NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Started NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Succeeded NOTE: Tasks Summary: Attempted 785 tasks of which 448 didn't need to be rerun and 0 failed. koen@dominion:/OE/tentacle$ MACHINE=beagleboard bitbake console-image /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory weird regards, Koen ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-27 12:45 ` Koen Kooi @ 2011-01-27 15:06 ` Richard Purdie 2011-01-27 15:35 ` Koen Kooi 0 siblings, 1 reply; 21+ messages in thread From: Richard Purdie @ 2011-01-27 15:06 UTC (permalink / raw) To: Koen Kooi; +Cc: poky On Thu, 2011-01-27 at 13:45 +0100, Koen Kooi wrote: > Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: > > The following are know issues with master: > > > > * Using rm_work and switching machines to machines of the same > > "multimachine" architecture breaks. > > > > * When switching machines of the same "multimachine" architecture (e.g. > > emenlow to atom-pc), some sstate packages are changing checksums when at > > first glance they shouldn't (e.g. perl do_install). A > > After the fixes for those 2 went in builds from scratch fail with: > > ERROR: Logfile of failure stored in: /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 > Log data follows: > | automake (GNU automake) 1.9.6 > | Written by Tom Tromey <tromey@redhat.com>. > | > | Copyright 2005 Free Software Foundation, Inc. > | This is free software; see the source for copying conditions. There is NO > | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > | AUTOV is 1.9 > | NOTE: Executing autoreconf --verbose --install --force --exclude=autopoint -I /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/share/aclocal > | /usr/bin/autoreconf2.50: unrecognized option `--exclude=autopoint' > | Try `/usr/bin/autoreconf2.50 --help' for more information. > | FATAL: autoreconf execution failed. > | Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) > | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) > > It wants to use the autoreconf from my host, which doesn't have the `--exclude=autopoint' option since that's something OE patches in. After building autoconf native pseudo is gone! > > /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory > > After building pseudo-native again: > > NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Started > NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Succeeded > NOTE: Tasks Summary: Attempted 785 tasks of which 448 didn't need to be rerun and 0 failed. > koen@dominion:/OE/tentacle$ MACHINE=beagleboard bitbake console-image > /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory It seems that autoconf.bbclass change is having a weird ripple effect with the sstate packages. Can you clean sstate and then retry, just to try and isolate the issues? I agree having a simple change to autotools.bbclass ripple through sstate like that isn't desirable btw, I just want to try and fix one issue at a time. Cheers, Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-27 15:06 ` Richard Purdie @ 2011-01-27 15:35 ` Koen Kooi 2011-01-27 17:01 ` Koen Kooi 2011-01-27 21:45 ` Richard Purdie 0 siblings, 2 replies; 21+ messages in thread From: Koen Kooi @ 2011-01-27 15:35 UTC (permalink / raw) To: Richard Purdie; +Cc: poky Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: > On Thu, 2011-01-27 at 13:45 +0100, Koen Kooi wrote: >> Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: >>> The following are know issues with master: >>> >>> * Using rm_work and switching machines to machines of the same >>> "multimachine" architecture breaks. >>> >>> * When switching machines of the same "multimachine" architecture (e.g. >>> emenlow to atom-pc), some sstate packages are changing checksums when at >>> first glance they shouldn't (e.g. perl do_install). A >> >> After the fixes for those 2 went in builds from scratch fail with: >> >> ERROR: Logfile of failure stored in: /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 >> Log data follows: >> | automake (GNU automake) 1.9.6 >> | Written by Tom Tromey <tromey@redhat.com>. >> | >> | Copyright 2005 Free Software Foundation, Inc. >> | This is free software; see the source for copying conditions. There is NO >> | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >> | AUTOV is 1.9 >> | NOTE: Executing autoreconf --verbose --install --force --exclude=autopoint -I /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/share/aclocal >> | /usr/bin/autoreconf2.50: unrecognized option `--exclude=autopoint' >> | Try `/usr/bin/autoreconf2.50 --help' for more information. >> | FATAL: autoreconf execution failed. >> | Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) >> | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) >> >> It wants to use the autoreconf from my host, which doesn't have the `--exclude=autopoint' option since that's something OE patches in. After building autoconf native pseudo is gone! >> >> /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory >> >> After building pseudo-native again: >> >> NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Started >> NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Succeeded >> NOTE: Tasks Summary: Attempted 785 tasks of which 448 didn't need to be rerun and 0 failed. >> koen@dominion:/OE/tentacle$ MACHINE=beagleboard bitbake console-image >> /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory > > It seems that autoconf.bbclass change is having a weird ripple effect > with the sstate packages. Can you clean sstate and then retry, just to > try and isolate the issues? > > I agree having a simple change to autotools.bbclass ripple through > sstate like that isn't desirable btw, I just want to try and fix one > issue at a time. I removed tmp, sstate-cache and pseudodone, then did 'bitbake console-image', which failed at the same point. I looked into '/OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/', which had a lot files in it, but no autoconf, so I did 'bitbake autoconf-native', that (re)ran a lot of rm_work tasks. koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ tclConfig.sh* so it removed pretty much everything from the sysroot! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-27 15:35 ` Koen Kooi @ 2011-01-27 17:01 ` Koen Kooi 2011-01-27 21:45 ` Richard Purdie 1 sibling, 0 replies; 21+ messages in thread From: Koen Kooi @ 2011-01-27 17:01 UTC (permalink / raw) To: poky Op 27 jan 2011, om 16:35 heeft Koen Kooi het volgende geschreven: > > Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: > >> On Thu, 2011-01-27 at 13:45 +0100, Koen Kooi wrote: >>> Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: >>>> The following are know issues with master: >>>> >>>> * Using rm_work and switching machines to machines of the same >>>> "multimachine" architecture breaks. >>>> >>>> * When switching machines of the same "multimachine" architecture (e.g. >>>> emenlow to atom-pc), some sstate packages are changing checksums when at >>>> first glance they shouldn't (e.g. perl do_install). A >>> >>> After the fixes for those 2 went in builds from scratch fail with: >>> >>> ERROR: Logfile of failure stored in: /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 >>> Log data follows: >>> | automake (GNU automake) 1.9.6 >>> | Written by Tom Tromey <tromey@redhat.com>. >>> | >>> | Copyright 2005 Free Software Foundation, Inc. >>> | This is free software; see the source for copying conditions. There is NO >>> | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. >>> | AUTOV is 1.9 >>> | NOTE: Executing autoreconf --verbose --install --force --exclude=autopoint -I /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/share/aclocal >>> | /usr/bin/autoreconf2.50: unrecognized option `--exclude=autopoint' >>> | Try `/usr/bin/autoreconf2.50 --help' for more information. >>> | FATAL: autoreconf execution failed. >>> | Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) >>> | ERROR: Function 'do_configure' failed (see /OE/tentacle/build/tmp-angstrom_2010_x/work/x86_64-linux/gmp-native-5.0.1-r0/temp/log.do_configure.31887 for further information) >>> >>> It wants to use the autoreconf from my host, which doesn't have the `--exclude=autopoint' option since that's something OE patches in. After building autoconf native pseudo is gone! >>> >>> /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory >>> >>> After building pseudo-native again: >>> >>> NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Started >>> NOTE: package pseudo-native-0.0+git0+bcb42d80c0817da5479ab9c4f2cd8c4727e98ef8-r17: task do_rm_work_all: Succeeded >>> NOTE: Tasks Summary: Attempted 785 tasks of which 448 didn't need to be rerun and 0 failed. >>> koen@dominion:/OE/tentacle$ MACHINE=beagleboard bitbake console-image >>> /OE/tentacle/sources/openembedded/scripts/bitbake: line 38: /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/pseudo: No such file or directory >> >> It seems that autoconf.bbclass change is having a weird ripple effect >> with the sstate packages. Can you clean sstate and then retry, just to >> try and isolate the issues? >> >> I agree having a simple change to autotools.bbclass ripple through >> sstate like that isn't desirable btw, I just want to try and fix one >> issue at a time. > > I removed tmp, sstate-cache and pseudodone, then did 'bitbake console-image', which failed at the same point. I looked into '/OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/', which had a lot files in it, but no autoconf, so I did 'bitbake autoconf-native', that (re)ran a lot of rm_work tasks. > > > koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ > tclConfig.sh* > > so it removed pretty much everything from the sysroot! RP said the following during a chat: Its do_distribute_sources That has triggered a new fetch call and fetch triggered setscene and setscene cleaned out the populate_staging So we know what's going on, now figure out a fix :) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-27 15:35 ` Koen Kooi 2011-01-27 17:01 ` Koen Kooi @ 2011-01-27 21:45 ` Richard Purdie 2011-01-27 23:33 ` Koen Kooi 2011-01-28 7:56 ` Koen Kooi 1 sibling, 2 replies; 21+ messages in thread From: Richard Purdie @ 2011-01-27 21:45 UTC (permalink / raw) To: Koen Kooi; +Cc: poky On Thu, 2011-01-27 at 16:35 +0100, Koen Kooi wrote: > Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: > > > On Thu, 2011-01-27 at 13:45 +0100, Koen Kooi wrote: > >> Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: > > It seems that autoconf.bbclass change is having a weird ripple effect > > with the sstate packages. Can you clean sstate and then retry, just to > > try and isolate the issues? > > > > I agree having a simple change to autotools.bbclass ripple through > > sstate like that isn't desirable btw, I just want to try and fix one > > issue at a time. > > I removed tmp, sstate-cache and pseudodone, then did 'bitbake > console-image', which failed at the same point. I looked into > '/OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/', which had a lot files in it, but no autoconf, so I did 'bitbake autoconf-native', that (re)ran a lot of rm_work tasks. > > > koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ > tclConfig.sh* > > so it removed pretty much everything from the sysroot! Just to update on this, Koen is using distribute_sources which adds a do_distribute_sources task. This is why things are working on master but not for Koen. That task runs later and causes do_setscene to rerun which cleans out the sysroot rather helpfully assuming that all tasks for that recipe will rerun which isn't true. This branch has some proposed changes to make this work better: http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/misc2 and Koen is testing them to see how they work out. Cheers, Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-27 21:45 ` Richard Purdie @ 2011-01-27 23:33 ` Koen Kooi 2011-01-28 7:56 ` Koen Kooi 1 sibling, 0 replies; 21+ messages in thread From: Koen Kooi @ 2011-01-27 23:33 UTC (permalink / raw) To: Richard Purdie; +Cc: poky Op 27 jan 2011, om 22:45 heeft Richard Purdie het volgende geschreven: > On Thu, 2011-01-27 at 16:35 +0100, Koen Kooi wrote: >> Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: >> >>> On Thu, 2011-01-27 at 13:45 +0100, Koen Kooi wrote: >>>> Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: >>> It seems that autoconf.bbclass change is having a weird ripple effect >>> with the sstate packages. Can you clean sstate and then retry, just to >>> try and isolate the issues? >>> >>> I agree having a simple change to autotools.bbclass ripple through >>> sstate like that isn't desirable btw, I just want to try and fix one >>> issue at a time. >> >> I removed tmp, sstate-cache and pseudodone, then did 'bitbake >> console-image', which failed at the same point. I looked into >> '/OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/', which had a lot files in it, but no autoconf, so I did 'bitbake autoconf-native', that (re)ran a lot of rm_work tasks. >> >> >> koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ >> tclConfig.sh* >> >> so it removed pretty much everything from the sysroot! > > Just to update on this, Koen is using distribute_sources which adds a > do_distribute_sources task. This is why things are working on master but > not for Koen. > > That task runs later and causes do_setscene to rerun which cleans out > the sysroot rather helpfully assuming that all tasks for that recipe > will rerun which isn't true. > > This branch has some proposed changes to make this work better: > > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/misc2 > > and Koen is testing them to see how they work out. It gets a lot further now, I'll check the end result tomorrow after I wake up. regards, Koen ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-27 21:45 ` Richard Purdie 2011-01-27 23:33 ` Koen Kooi @ 2011-01-28 7:56 ` Koen Kooi 2011-01-28 16:59 ` Richard Purdie 1 sibling, 1 reply; 21+ messages in thread From: Koen Kooi @ 2011-01-28 7:56 UTC (permalink / raw) To: Richard Purdie; +Cc: poky Op 27 jan 2011, om 22:45 heeft Richard Purdie het volgende geschreven: > On Thu, 2011-01-27 at 16:35 +0100, Koen Kooi wrote: >> Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: >> >>> On Thu, 2011-01-27 at 13:45 +0100, Koen Kooi wrote: >>>> Op 25 jan 2011, om 23:07 heeft Richard Purdie het volgende geschreven: >>> It seems that autoconf.bbclass change is having a weird ripple effect >>> with the sstate packages. Can you clean sstate and then retry, just to >>> try and isolate the issues? >>> >>> I agree having a simple change to autotools.bbclass ripple through >>> sstate like that isn't desirable btw, I just want to try and fix one >>> issue at a time. >> >> I removed tmp, sstate-cache and pseudodone, then did 'bitbake >> console-image', which failed at the same point. I looked into >> '/OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/', which had a lot files in it, but no autoconf, so I did 'bitbake autoconf-native', that (re)ran a lot of rm_work tasks. >> >> >> koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ >> tclConfig.sh* >> >> so it removed pretty much everything from the sysroot! > > Just to update on this, Koen is using distribute_sources which adds a > do_distribute_sources task. This is why things are working on master but > not for Koen. > > That task runs later and causes do_setscene to rerun which cleans out > the sysroot rather helpfully assuming that all tasks for that recipe > will rerun which isn't true. > > This branch has some proposed changes to make this work better: > > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/misc2 > > and Koen is testing them to see how they work out. That fixes both the setscene and machine switching issues. Everything works as expected again! ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-28 7:56 ` Koen Kooi @ 2011-01-28 16:59 ` Richard Purdie 2011-01-28 17:42 ` Koen Kooi 0 siblings, 1 reply; 21+ messages in thread From: Richard Purdie @ 2011-01-28 16:59 UTC (permalink / raw) To: Koen Kooi; +Cc: poky On Fri, 2011-01-28 at 08:56 +0100, Koen Kooi wrote: > Op 27 jan 2011, om 22:45 heeft Richard Purdie het volgende geschreven: > > > On Thu, 2011-01-27 at 16:35 +0100, Koen Kooi wrote: > >> Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: > >> koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ > >> tclConfig.sh* > >> > >> so it removed pretty much everything from the sysroot! > > > > Just to update on this, Koen is using distribute_sources which adds a > > do_distribute_sources task. This is why things are working on master but > > not for Koen. > > > > That task runs later and causes do_setscene to rerun which cleans out > > the sysroot rather helpfully assuming that all tasks for that recipe > > will rerun which isn't true. > > > > This branch has some proposed changes to make this work better: > > > > http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/misc2 > > > > and Koen is testing them to see how they work out. > > That fixes both the setscene and machine switching issues. Everything works as expected again! Those fixes have been merged into master now. Cheers, Richard ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: Master stability update 2011-01-28 16:59 ` Richard Purdie @ 2011-01-28 17:42 ` Koen Kooi 0 siblings, 0 replies; 21+ messages in thread From: Koen Kooi @ 2011-01-28 17:42 UTC (permalink / raw) To: Richard Purdie; +Cc: poky Op 28 jan 2011, om 17:59 heeft Richard Purdie het volgende geschreven: > On Fri, 2011-01-28 at 08:56 +0100, Koen Kooi wrote: >> Op 27 jan 2011, om 22:45 heeft Richard Purdie het volgende geschreven: >> >>> On Thu, 2011-01-27 at 16:35 +0100, Koen Kooi wrote: >>>> Op 27 jan 2011, om 16:06 heeft Richard Purdie het volgende geschreven: >>>> koen@dominion:/OE/tentacle$ ls /OE/tentacle/build/tmp-angstrom_2010_x/sysroots/x86_64-linux/usr/bin/ >>>> tclConfig.sh* >>>> >>>> so it removed pretty much everything from the sysroot! >>> >>> Just to update on this, Koen is using distribute_sources which adds a >>> do_distribute_sources task. This is why things are working on master but >>> not for Koen. >>> >>> That task runs later and causes do_setscene to rerun which cleans out >>> the sysroot rather helpfully assuming that all tasks for that recipe >>> will rerun which isn't true. >>> >>> This branch has some proposed changes to make this work better: >>> >>> http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=rpurdie/misc2 >>> >>> and Koen is testing them to see how they work out. >> >> That fixes both the setscene and machine switching issues. Everything works as expected again! > > Those fixes have been merged into master now. The problem isn't entirely gone yet. What I did MACHINE=beagleboard bitbake console-image (worked) MACHINE=usrp-e1xx bitbake console-image (worked) MACHINE=hawkboard bitbake console-image (broke) updated metadata MACHINE=omap4430-panda bitbake console-image (broke) The first breakage was a license checksum failure in libusb-compat, which I have overlayed locally, I changed that into a bbappend and rebuilt, things went fine. After switching to pandaboard a lot of things broke (pango, atk, kernel, etc), most of them in package_write. It turns out that the license failure was caused by do_unpack getting skipped, so the it couldn't find the LICENSE and COPYING files to checksum. It seems that during do_configure the stamps don't get reset complete, so no unpack/patch is run. Due to the way the classes are structured, running in an empty dir doesn't cause problems till we encounter custom packaging rules. Does that make sense? The kernel failure looks like this: ERROR: Logfile of failure stored in: /OE/tentacle/build/tmp-angstrom_2010_x/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r99+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/temp/log.do_package_write_ipk.18429 Log data follows: | Lockfile destination directory '/OE/tentacle/build/tmp-angstrom_2010_x/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r99+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/packages-split' does not exist | ERROR: Lockfile destination directory '/OE/tentacle/build/tmp-angstrom_2010_x/work/beagleboard-angstrom-linux-gnueabi/linux-omap-psp-2.6.32-r99+gitr5fc29e7b2a76a64a739f857858ef0b98294aa155/packages-split' does not exist regards, Koen ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2011-01-28 17:42 UTC | newest] Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-01-25 22:07 Master stability update Richard Purdie 2011-01-26 2:45 ` Xu, Dongxiao 2011-01-26 2:52 ` Tian, Kevin 2011-01-26 3:05 ` Tian, Kevin 2011-01-26 3:51 ` Mark Hatle 2011-01-26 11:42 ` Richard Purdie 2011-01-26 3:52 ` Xu, Dongxiao 2011-01-26 3:55 ` Xu, Dongxiao 2011-01-26 10:01 ` Richard Purdie 2011-01-26 10:31 ` Tian, Kevin 2011-01-26 6:58 ` Saul Wold 2011-01-26 7:01 ` Xu, Dongxiao 2011-01-27 12:45 ` Koen Kooi 2011-01-27 15:06 ` Richard Purdie 2011-01-27 15:35 ` Koen Kooi 2011-01-27 17:01 ` Koen Kooi 2011-01-27 21:45 ` Richard Purdie 2011-01-27 23:33 ` Koen Kooi 2011-01-28 7:56 ` Koen Kooi 2011-01-28 16:59 ` Richard Purdie 2011-01-28 17:42 ` Koen Kooi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.