Created attachment 300 [details] meta-toolchain-sdk build log Iit appears that 1.2_M1 is broken for at least the meta-toolchain-sdk and meta-toolchain-qte images. When trying to build the meta-toolchain-sdk image for 1.2_M1, using the mpc8315e-rdb machine, I get an error in ... | Configuring libtelepathy-dbg. | Configuring task-core-standalone-gmae-sdk-target-dbg. | Configuring util-linux-blkid. | Collected errors: | * extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists. | + '[' '!' -z '' ']' | + package_tryout_install_multilib_ipk | + multilib_tryout_dirs= | + '[' '!' -z '' ']' | + echo '' | | + do_exit=1 | + for keyword_die in '"exit 1"' '"Collected errors"' ERR Fail | + for keyword_die in '"exit 1"' '"Collected errors"' ERR Fail | + test 1 = 1 | + exit 1 NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed ERROR: Task 8 (/home/wd/git/poky/testing/meta/recipes-core/meta/meta-toolchain-gmae.bb, do_populate_sdk) failed with exit code '1' ERROR: '/home/wd/git/poky/testing/meta/recipes-core/meta/meta-toolchain-gmae.bb' failed Full build log attached below.
There was a recent set of changes from Richard that appears to have addressed this failure, please test with the latest master. We will not back port these to M1 itself.
(In reply to comment #1) > There was a recent set of changes from Richard that appears to have addressed > this failure, please test with the latest master. We will not back port these > to M1 itself. No, this is not fixed. I just re-ran a build of meta-toolchain-sdk for this configuration: OE Build Configuration: BB_VERSION = "1.15.0" TARGET_ARCH = "powerpc" TARGET_OS = "linux" MACHINE = "mpc8315e-rdb" DISTRO = "poky" DISTRO_VERSION = "1.1+snapshot-20111221" TUNE_FEATURES = "m32 fpu-hard ppc603e" TARGET_FPU = "" meta meta-yocto = "master:6036845d1c07420a99b78421bb3479adf7d754e7" [= current master] and I still get this: ... Configuring avahi-dev. Configuring task-core-standalone-gmae-sdk-target. Configuring libtelepathy-dbg. Configuring task-core-standalone-gmae-sdk-target-dbg. Configuring util-linux-blkid. Collected errors: * extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists. + '[' '!' -z '' ']' + package_tryout_install_multilib_ipk + multilib_tryout_dirs= + '[' '!' -z '' ']' + echo '' + do_exit=1 + for keyword_die in '"exit 1"' '"Collected errors"' ERR Fail + for keyword_die in '"exit 1"' '"Collected errors"' ERR Fail + test 1 = 1 + exit 1
The fix was in http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=1855e94280bdbce2de84cb81cdd61f01950d05d9 which is after the revision you say you tested.
Its also possible that http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d350b3168bab234e326c8cf1609d13803e6aba9e might have been an issue depending on your feed configuration (issue was just discovered).
(In reply to comment #4) > Its also possible that > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d350b3168bab234e326c8cf1609d13803e6aba9e > might have been an issue depending on your feed configuration (issue was just > discovered). No, none of these appears to be the issue. I retried a few times since, and again today with current master: f5aa3bb 2011-12-24 10:05:47 +0000 coreutils: ensure --color works so DEPEND on libcap This appears to include all these changes, but still fails to build with the very same error. Is there any specific reason (except build time) that meta-toolchain-sdk is not included into the autobuilder tests? This issue exists for a long time, but nobody really seems to care :-(
(In reply to comment #5) ... > No, none of these appears to be the issue. I retried a few times since, > and again today with current master: I also tried 1.2_M1.final; this fails in the same way, too.
meta-toolchain-gmae is tested on the autobuilder and is the same thing as meta-toolchain-sdk (its old name). There is a backwards compatibility map in place in the recipe: PROVIDES = "meta-toolchain-sdk" The toolchain is therefore tested on the autobuilder. I'd also dispute the fact nobody cares since there have been several replies to this issue here, particularly given the time of year when many people are on holiday. Sadly I'm simply not able to reproduce the problem you're describing after the fixes mentioned here were made. I will try to reproduce this again. For reference this is a known issue with 1.2M1 and we're not going to fix this issue there due to the number of changes that would need to 1.2M1 and our unavailability of QA resources to test/release that branch any further.
(In reply to comment #7) > meta-toolchain-gmae is tested on the autobuilder and is the same thing as > meta-toolchain-sdk (its old name). There is a backwards compatibility map in > place in the recipe: > PROVIDES = "meta-toolchain-sdk" Thanks for pointing out. I missed that. > The toolchain is therefore tested on the autobuilder. The I'm obviously missing another thing as well. Checking at http://autobuilder.yoctoproject.org/nightly/CURRENT/machines/mpc8315e-rdb/ I can only see these files: core-image-minimal-mpc8315e-rdb-20120102222244.rootfs.tar.gz core-image-minimal-mpc8315e-rdb.tar.gz modules-3.0.4-yocto-standard+-r2-mpc8315e-rdb.tgz uImage-3.0.12+git1+c979f1365b1eb74e882b2cbbc8407ec536ab6eb8_1+58ffdb8000e34d2ba7c3ef278b26680b0886e8b5-r2-mpc8315e-rdb-20120102222244.bin uImage-3.0.12+git1+c979f1365b1eb74e882b2cbbc8407ec536ab6eb8_1+58ffdb8000e34d2ba7c3ef278b26680b0886e8b5-r2-mpc8315e-rdb-20120102222244.dtb uImage-3.0.12+git1+c979f1365b1eb74e882b2cbbc8407ec536ab6eb8_1+58ffdb8000e34d2ba7c3ef278b26680b0886e8b5-r2-mpc8315e-rdb-20120103031021.bin uImage-3.0.12+git1+c979f1365b1eb74e882b2cbbc8407ec536ab6eb8_1+58ffdb8000e34d2ba7c3ef278b26680b0886e8b5-r2-mpc8315e-rdb-20120103031021.dtb uImage-mpc8315e-rdb.bin uImage-mpc8315e-rdb.dtb My interpretation was that only core-image-minimal gets built by the autobuilder. Where can I check the results for meta-toolchain-gmae ? > I'd also dispute the fact nobody cares since there have been several replies to > this issue here, particularly given the time of year when many people are on > holiday. I apologize. No offence meant. > Sadly I'm simply not able to reproduce the problem you're describing after the > fixes mentioned here were made. I will try to reproduce this again. Please let me know if there is anything I can do to help testing. [My test builds were done both in Fedora 15 and Fedora 16 build environments, both fully updated, both x86_64,] > For reference this is a known issue with 1.2M1 and we're not going to fix this > issue there due to the number of changes that would need to 1.2M1 and our > unavailability of QA resources to test/release that branch any further. This is understood. My concern is to get this fixed at all. Thanks. Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Anything free is worth what you pay for it.
(In reply to comment #8) > > The toolchain is therefore tested on the autobuilder. > > The I'm obviously missing another thing as well. Checking at > http://autobuilder.yoctoproject.org/nightly/CURRENT/machines/mpc8315e-rdb/ > I can only see these files: [...] You can see the toolchains at: http://autobuilder.yoctoproject.org/nightly/20111224-1/toolchain/i686/ http://autobuilder.yoctoproject.org/nightly/20111224-1/toolchain/x86-64/ (I've not used the CURRENT directory since last nights builds failed for reasons unrelated to this bug). > My interpretation was that only core-image-minimal gets built by the > autobuilder. Where can I check the results for meta-toolchain-gmae ? It attempts core-image-minimal, -sato, -sato-sdk and -lsb. Not all builds always suceed which is why some files were missing in the build you pointed at. We do actively work to fix regressions. > Please let me know if there is anything I can do to help testing. > [My test builds were done both in Fedora 15 and Fedora 16 build > environments, both fully updated, both x86_64,] > > > For reference this is a known issue with 1.2M1 and we're not going to fix this > > issue there due to the number of changes that would need to 1.2M1 and our > > unavailability of QA resources to test/release that branch any further. > > This is understood. My concern is to get this fixed at all. Can I just confirm that: a) We are talking about a build from scratch? b) Was there any sstate being reused? c) You don't have local changes? d) You tested a build from scratch with revision f5aa3bb ? I tried a build here with latest master and ipk with the mpc8315e-rdb machine and it worked so I'm still puzzled about what is going on. Please include a log from the latest build if its still not working as I'd like to check the do_rootfs package install order.
(In reply to comment #9) > > You can see the toolchains at: > http://autobuilder.yoctoproject.org/nightly/20111224-1/toolchain/i686/ > http://autobuilder.yoctoproject.org/nightly/20111224-1/toolchain/x86-64/ I see. Thanks. I was checking http://autobuilder.yoctoproject.org/nightly/CURRENT/toolchain/x86-64/ which was empty when I tried... > Can I just confirm that: > a) We are talking about a build from scratch? Yes. For such test builds I always use a new, empty build directory, and I even make sure not to have any stale files in the git clone (by running "git clean -f -x", which even blows away any pre-existing .py files). > b) Was there any sstate being reused? No. > c) You don't have local changes? No. This is a clean checkout of the public git repo, master branch. > d) You tested a build from scratch with revision f5aa3bb ? Yes: $ git describe 1.1_M4.rc3-1293-gf5aa3bb > I tried a build here with latest master and ipk with the mpc8315e-rdb machine > and it worked so I'm still puzzled about what is going on. Please include a log > from the latest build if its still not working as I'd like to check the > do_rootfs package install order. I will add this as attachment. This was a build done under Fedora 16, in case it matters.
Created attachment 307 [details] Build log
Ah, this is not the same failure as you originally reported! This is the same issue as is reported in bug 1869. The previous error was "extract_archive: Cannot create symlink from ./var/log to 'volatile/log': File exists." The error now is "gtk-update-icon-cache: Failed to open file /usr/share/icons/Adwaita/.icon-theme.cache : Permission denied" (and similar messages). I just posted a patch on the mailing list for this problem.
Fixed in master http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c4de612298266653130dd2e5b8378f62dda77e9f
(In reply to comment #12) > Ah, this is not the same failure as you originally reported! This is the same > issue as is reported in bug 1869. Argh. You are right. Sorry for missing this. > I just posted a patch on the mailing list for this problem. I confirm that this fixes the problem. Thanks a lot.