* [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) @ 2010-12-31 15:47 Frans Meulenbroeks 2010-12-31 15:47 ` [PATCH 2/2] omap4430-panda: fix u-boot Frans Meulenbroeks 2010-12-31 17:14 ` [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Khem Raj 0 siblings, 2 replies; 22+ messages in thread From: Frans Meulenbroeks @ 2010-12-31 15:47 UTC (permalink / raw) To: openembedded-devel Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> --- recipes/u-boot/u-boot_2010.12.bb | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) create mode 100644 recipes/u-boot/u-boot_2010.12.bb diff --git a/recipes/u-boot/u-boot_2010.12.bb b/recipes/u-boot/u-boot_2010.12.bb new file mode 100644 index 0000000..174bebf --- /dev/null +++ b/recipes/u-boot/u-boot_2010.12.bb @@ -0,0 +1,19 @@ +PR = "r0" +require u-boot.inc + +DEFAULT_PREFERENCE = "-1" + +SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2 " +SRC_URI[md5sum] = "9024bbceabd176ae1d52df6db2e84bda" +SRC_URI[sha256sum] = "1705772db7a18635693676abb8818542167cb131921c456a1edd0ed47e6b77fe" + + +TARGET_LDFLAGS = "" + +inherit base + +do_compile () { + oe_runmake ${UBOOT_MACHINE} + oe_runmake all +} + -- 1.7.1 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 15:47 [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Frans Meulenbroeks @ 2010-12-31 15:47 ` Frans Meulenbroeks 2010-12-31 18:41 ` Koen Kooi 2010-12-31 17:14 ` [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Khem Raj 1 sibling, 1 reply; 22+ messages in thread From: Frans Meulenbroeks @ 2010-12-31 15:47 UTC (permalink / raw) To: openembedded-devel The u-boot recipe for pandaboard is nonbuildable for a few months. Apparently this recipe is orphaned. I've made things buildable again by moving to the latest mainline u-boot (as suggested by Steve Sakoman a few monts ago). It builds fine, but is not tested on the actual hardware (as I do not have access to a board). Still I feel that a buildable recipe is better than using a recipe that does not even build. Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> --- conf/machine/omap4430-panda.conf | 6 ++++-- recipes/u-boot/u-boot_2010.12.bb | 1 + 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/conf/machine/omap4430-panda.conf b/conf/machine/omap4430-panda.conf index df2658e..af1d79c 100644 --- a/conf/machine/omap4430-panda.conf +++ b/conf/machine/omap4430-panda.conf @@ -4,12 +4,12 @@ require conf/machine/include/omap3.inc -EXTRA_IMAGEDEPENDS = "x-load-rsalveti u-boot-sakoman " +EXTRA_IMAGEDEPENDS = "x-load-rsalveti u-boot" XLOAD_MACHINE = "omap4430panda_config" XLOAD_LOAD_ADDRESS = 0x40304350 -PREFERRED_PROVIDER_virtual/bootloader = "u-boot-sakoman" +PREFERRED_PROVIDER_virtual/bootloader = "u-boot" UBOOT_MACHINE = "omap4_panda_config" PREFERRED_PROVIDER_virtual/kernel = "linux-omap4" diff --git a/recipes/u-boot/u-boot_2010.12.bb b/recipes/u-boot/u-boot_2010.12.bb index 174bebf..5645576 100644 --- a/recipes/u-boot/u-boot_2010.12.bb +++ b/recipes/u-boot/u-boot_2010.12.bb @@ -2,6 +2,7 @@ PR = "r0" require u-boot.inc DEFAULT_PREFERENCE = "-1" +DEFAULT_PREFERENCE_omap4430-panda = "1" SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2 " SRC_URI[md5sum] = "9024bbceabd176ae1d52df6db2e84bda" -- 1.7.1 ^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 15:47 ` [PATCH 2/2] omap4430-panda: fix u-boot Frans Meulenbroeks @ 2010-12-31 18:41 ` Koen Kooi 2010-12-31 19:06 ` Frans Meulenbroeks 0 siblings, 1 reply; 22+ messages in thread From: Koen Kooi @ 2010-12-31 18:41 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31-12-10 16:47, Frans Meulenbroeks wrote: > The u-boot recipe for pandaboard is nonbuildable for a few > months. Apparently this recipe is orphaned. > I've made things buildable again by moving to the latest > mainline u-boot (as suggested by Steve Sakoman a few monts > ago). It builds fine, but is not tested on the actual > hardware (as I do not have access to a board). > Still I feel that a buildable recipe is better than using a > recipe that does not even build. NAK, since it builds just fine and the result of the new recipe doesn't work as good: koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ MACHINE=omap4430-panda bitbake -b u-boot-sakoman_git.bb Build Configuration: BB_VERSION = "1.11.0" METADATA_BRANCH = "org.openembedded.dev" METADATA_REVISION = "67c4a78" TARGET_ARCH = "arm" TARGET_OS = "linux-gnueabi" MACHINE = "omap4430-panda" DISTRO = "angstrom" DISTRO_VERSION = "2010.7-test-20101231" TARGET_FPU = "hard" NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 1 of 20 (ID: 11, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_setscene) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_setscene: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_setscene: Succeeded - --2010-12-31 19:31:20-- http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz Resolving www.angstrom-distribution.org... 188.40.83.200 NOTE: Running task 2 of 20 (ID: 9, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_fetch) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_fetch: Started NOTE: fetch http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz <snip> 2010-12-31 19:39:01 (24.4 KB/s) - `/OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz' saved [11415903/11415903] NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_fetch: Succeeded NOTE: Running task 4 of 20 (ID: 16, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_distribute_sources) NOTE: Running task 3 of 20 (ID: 0, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_unpack) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_distribute_sources: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_distribute_sources: Succeeded NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_unpack: Started NOTE: Unpacking /OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz to /OE/angstrom-dev/work/omap4430-panda-angstrom-linux-gnueabi/u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0/ NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_unpack: Succeeded NOTE: Running task 5 of 20 (ID: 1, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_patch) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_patch: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_patch: Succeeded NOTE: Running task 6 of 20 (ID: 12, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_configure) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_configure: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_configure: Succeeded NOTE: Running task 7 of 20 (ID: 13, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_qa_configure) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_qa_configure: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_qa_configure: Succeeded NOTE: Running task 8 of 20 (ID: 14, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_compile) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_compile: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_compile: Succeeded NOTE: Running task 9 of 20 (ID: 2, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_install) NOTE: Running task 10 of 20 (ID: 4, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_deploy) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_install: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_install: Succeeded NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_deploy: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_deploy: Succeeded NOTE: Running task 11 of 20 (ID: 15, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package) NOTE: Running task 12 of 20 (ID: 3, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_populate_sysroot) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_populate_sysroot: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_populate_sysroot: Succeeded NOTE: Running task 13 of 20 (ID: 5, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_qa_staging) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_qa_staging: Started NOTE: package u-boot-sakoman skipped NOTE: package u-boot-sakoman-fw-utils skipped NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package: Succeeded NOTE: Running task 14 of 20 (ID: 19, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package_write_ipk) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_write_ipk: Started Packaged contents of u-boot-sakoman-dbg into /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dbg_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk Packaged contents of u-boot-sakoman into /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk NOTE: Not creating empty archive for u-boot-sakoman-doc-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 Packaged contents of u-boot-sakoman-dev into /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dev_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk NOTE: Not creating empty archive for u-boot-sakoman-static-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 NOTE: Not creating empty archive for u-boot-sakoman-locale-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 NOTE: Not creating empty archive for u-boot-sakoman-fw-utils-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_write_ipk: Succeeded NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_qa_staging: Succeeded NOTE: Running task 15 of 20 (ID: 6, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package_write) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_write: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_write: Succeeded NOTE: Running task 16 of 20 (ID: 7, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package_stage) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_stage: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_stage: Succeeded NOTE: Running task 17 of 20 (ID: 8, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package_stage_all) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_stage_all: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_package_stage_all: Succeeded NOTE: Running task 18 of 20 (ID: 10, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_build) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_build: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_build: Succeeded NOTE: Running task 19 of 20 (ID: 17, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_rm_work) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_rm_work: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_rm_work: Succeeded NOTE: Running task 20 of 20 (ID: 18, /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_rm_work_all) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_rm_work_all: Started NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_rm_work_all: Succeeded NOTE: Tasks Summary: Attempted 20 tasks of which 0 didn't need to be rerun and 0 failed. koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFNHiPtMkyGM64RGpERApY1AJ9LZNHfpTr7TQGatDxuFCV/fNPOiACfU2n0 tAJXkFpiWeFxZMI0nnj4jqQ= =vQ8j -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 18:41 ` Koen Kooi @ 2010-12-31 19:06 ` Frans Meulenbroeks 2010-12-31 19:38 ` Koen Kooi 2010-12-31 19:44 ` Philip Balister 0 siblings, 2 replies; 22+ messages in thread From: Frans Meulenbroeks @ 2010-12-31 19:06 UTC (permalink / raw) To: openembedded-devel 2010/12/31 Koen Kooi <k.kooi@student.utwente.nl>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 31-12-10 16:47, Frans Meulenbroeks wrote: >> The u-boot recipe for pandaboard is nonbuildable for a few >> months. Apparently this recipe is orphaned. >> I've made things buildable again by moving to the latest >> mainline u-boot (as suggested by Steve Sakoman a few monts >> ago). It builds fine, but is not tested on the actual >> hardware (as I do not have access to a board). >> Still I feel that a buildable recipe is better than using a >> recipe that does not even build. > > NAK, since it builds just fine and the result of the new recipe doesn't > work as good: It does not build! See the log below. The recipe says: SRCREV = "ccd0c67858c6e2807c695e2c8f545284cb871866" PV = "2010.9+${PR}+git${SRCREV}" SRC_URI = "git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git \ This SRCREV does not exist! The only reason it works for you is because you use a mirror that has a snapshot of the recipe. If you are concerned about this recipe the least you can do is to make sure that people can build it even if they do not have your mirror present. (by either moving the recipe to a SRCREV that exists or by changing the SRC_URI to a location that *does* fetch). In its current form I consider this recipe as broken! Frans. frans@linux-suse:~/oe/openembedded> bitbake u-boot-sakoman Loading cache: 100% |##############################################################################| ETA: 00:00:00 Loaded 7231 entries from dependency cache. Parsing recipes: 100% |############################################################################| Time: 00:00:29 Parsing of 7278 .bb files complete (6537 cached, 741 parsed). 7982 targets, 310 skipped, 0 masked, 0 errors. Build Configuration: BB_VERSION = "1.11.0" METADATA_BRANCH = "org.openembedded.dev" METADATA_REVISION = "ee3dfcd" TARGET_ARCH = "arm" TARGET_OS = "linux-gnueabi" MACHINE = "omap4430-panda" DISTRO = "minimal" DISTRO_VERSION = "dev-snapshot-20101231" TARGET_FPU = "soft" NOTE: Resolving any missing task queue dependencies NOTE: Preparing runqueue NOTE: Executing runqueue NOTE: Running task 1229 of 1247 (ID: 9, /home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb, do_fetch) NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task do_fetch: Started From git://www.sakoman.com/git/u-boot * branch omap4-exp -> FETCH_HEAD NOTE: Creating tarball of git repository fatal: failed to unpack tree object ccd0c67858c6e2807c695e2c8f545284cb871866 NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: task Fetch failed: Unable to fetch URL git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git from any source.: Failed ERROR: Function 'Fetch failed: Unable to fetch URL git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git from any source.' failed ERROR: Task 9 (/home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb, do_fetch) failed with exit code '1' ERROR: '/home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb' failed frans@linux-suse:~/oe/openembedded> > koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ > MACHINE=omap4430-panda bitbake -b u-boot-sakoman_git.bb > > Build Configuration: > BB_VERSION = "1.11.0" > METADATA_BRANCH = "org.openembedded.dev" > METADATA_REVISION = "67c4a78" > TARGET_ARCH = "arm" > TARGET_OS = "linux-gnueabi" > MACHINE = "omap4430-panda" > DISTRO = "angstrom" > DISTRO_VERSION = "2010.7-test-20101231" > TARGET_FPU = "hard" > > NOTE: Preparing runqueue > NOTE: Executing runqueue > NOTE: Running task 1 of 20 (ID: 11, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_setscene) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_setscene: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_setscene: Succeeded > - --2010-12-31 19:31:20-- > http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz > Resolving www.angstrom-distribution.org... 188.40.83.200 > NOTE: Running task 2 of 20 (ID: 9, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_fetch) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_fetch: Started > NOTE: fetch > http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz > > <snip> > > 2010-12-31 19:39:01 (24.4 KB/s) - > `/OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz' > saved [11415903/11415903] > > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_fetch: Succeeded > NOTE: Running task 4 of 20 (ID: 16, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_distribute_sources) > NOTE: Running task 3 of 20 (ID: 0, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_unpack) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_distribute_sources: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_distribute_sources: Succeeded > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_unpack: Started > NOTE: Unpacking > /OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz > to > /OE/angstrom-dev/work/omap4430-panda-angstrom-linux-gnueabi/u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0/ > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_unpack: Succeeded > NOTE: Running task 5 of 20 (ID: 1, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_patch) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_patch: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_patch: Succeeded > NOTE: Running task 6 of 20 (ID: 12, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_configure) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_configure: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_configure: Succeeded > NOTE: Running task 7 of 20 (ID: 13, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_qa_configure) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_configure: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_configure: Succeeded > NOTE: Running task 8 of 20 (ID: 14, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_compile) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_compile: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_compile: Succeeded > NOTE: Running task 9 of 20 (ID: 2, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_install) > NOTE: Running task 10 of 20 (ID: 4, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_deploy) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_install: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_install: Succeeded > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_deploy: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_deploy: Succeeded > NOTE: Running task 11 of 20 (ID: 15, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package) > NOTE: Running task 12 of 20 (ID: 3, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_populate_sysroot) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_populate_sysroot: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_populate_sysroot: Succeeded > NOTE: Running task 13 of 20 (ID: 5, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_qa_staging) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_staging: Started > NOTE: package u-boot-sakoman skipped > NOTE: package u-boot-sakoman-fw-utils skipped > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package: Succeeded > NOTE: Running task 14 of 20 (ID: 19, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_write_ipk) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write_ipk: Started > Packaged contents of u-boot-sakoman-dbg into > /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dbg_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk > Packaged contents of u-boot-sakoman into > /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk > NOTE: Not creating empty archive for > u-boot-sakoman-doc-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > Packaged contents of u-boot-sakoman-dev into > /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dev_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk > NOTE: Not creating empty archive for > u-boot-sakoman-static-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > NOTE: Not creating empty archive for > u-boot-sakoman-locale-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > NOTE: Not creating empty archive for > u-boot-sakoman-fw-utils-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write_ipk: Succeeded > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_staging: Succeeded > NOTE: Running task 15 of 20 (ID: 6, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_write) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write: Succeeded > NOTE: Running task 16 of 20 (ID: 7, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_stage) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage: Succeeded > NOTE: Running task 17 of 20 (ID: 8, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_stage_all) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage_all: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage_all: Succeeded > NOTE: Running task 18 of 20 (ID: 10, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_build) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_build: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_build: Succeeded > NOTE: Running task 19 of 20 (ID: 17, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_rm_work) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work: Succeeded > NOTE: Running task 20 of 20 (ID: 18, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_rm_work_all) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work_all: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work_all: Succeeded > NOTE: Tasks Summary: Attempted 20 tasks of which 0 didn't need to be > rerun and 0 failed. > koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > > iD8DBQFNHiPtMkyGM64RGpERApY1AJ9LZNHfpTr7TQGatDxuFCV/fNPOiACfU2n0 > tAJXkFpiWeFxZMI0nnj4jqQ= > =vQ8j > -----END PGP SIGNATURE----- > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 19:06 ` Frans Meulenbroeks @ 2010-12-31 19:38 ` Koen Kooi 2010-12-31 21:46 ` Michael 'Mickey' Lauer 2011-01-01 18:12 ` Frans Meulenbroeks 2010-12-31 19:44 ` Philip Balister 1 sibling, 2 replies; 22+ messages in thread From: Koen Kooi @ 2010-12-31 19:38 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31-12-10 20:06, Frans Meulenbroeks wrote: > 2010/12/31 Koen Kooi <k.kooi@student.utwente.nl>: > On 31-12-10 16:47, Frans Meulenbroeks wrote: >>>> The u-boot recipe for pandaboard is nonbuildable for a few >>>> months. Apparently this recipe is orphaned. >>>> I've made things buildable again by moving to the latest >>>> mainline u-boot (as suggested by Steve Sakoman a few monts >>>> ago). It builds fine, but is not tested on the actual >>>> hardware (as I do not have access to a board). >>>> Still I feel that a buildable recipe is better than using a >>>> recipe that does not even build. > > NAK, since it builds just fine and the result of the new recipe doesn't > work as good: > >> It does not build! See the log below. >> The recipe says: > >> SRCREV = "ccd0c67858c6e2807c695e2c8f545284cb871866" > >> PV = "2010.9+${PR}+git${SRCREV}" > >> SRC_URI = "git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git \ > >> This SRCREV does not exist! > >> The only reason it works for you is because you use a mirror that has >> a snapshot of the recipe. It's the standard angstrom source mirror from angstrom-mirrors.bbclass, which anyone can use if they want to. >> If you are concerned about this recipe the least you can do is to make >> sure that people can build it even if they do not have your mirror >> present. The configurations I'm concerned about use angstrom-mirrors.bbclass, I don't care about others. I can send you my rate card if you want to pay me to support crap like minimal. >> (by either moving the recipe to a SRCREV that exists or by changing >> the SRC_URI to a location that *does* fetch). >> In its current form I consider this recipe as broken! I only support angstrom for the machines I maintain, if other distros want to support panda, they are free to mirror the snapshot if they want to. There is no guarantee that any other SRCREV will keep existing for the lengths of time, but the angstrom source mirror will keep the snapshot for at least 3 years. > >> Frans. > >> frans@linux-suse:~/oe/openembedded> bitbake u-boot-sakoman >> Loading cache: 100% >> |##############################################################################| >> ETA: 00:00:00 >> Loaded 7231 entries from dependency cache. >> Parsing recipes: 100% >> |############################################################################| >> Time: 00:00:29 >> Parsing of 7278 .bb files complete (6537 cached, 741 parsed). 7982 >> targets, 310 skipped, 0 masked, 0 errors. > >> Build Configuration: >> BB_VERSION = "1.11.0" >> METADATA_BRANCH = "org.openembedded.dev" >> METADATA_REVISION = "ee3dfcd" >> TARGET_ARCH = "arm" >> TARGET_OS = "linux-gnueabi" >> MACHINE = "omap4430-panda" >> DISTRO = "minimal" >> DISTRO_VERSION = "dev-snapshot-20101231" >> TARGET_FPU = "soft" > >> NOTE: Resolving any missing task queue dependencies >> NOTE: Preparing runqueue >> NOTE: Executing runqueue >> NOTE: Running task 1229 of 1247 (ID: 9, >> /home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb, >> do_fetch) >> NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_fetch: Started >> From git://www.sakoman.com/git/u-boot >> * branch omap4-exp -> FETCH_HEAD >> NOTE: Creating tarball of git repository >> fatal: failed to unpack tree object ccd0c67858c6e2807c695e2c8f545284cb871866 >> NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task Fetch failed: Unable to fetch URL >> git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git >> from any source.: Failed >> ERROR: Function 'Fetch failed: Unable to fetch URL >> git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git >> from any source.' failed >> ERROR: Task 9 (/home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb, >> do_fetch) failed with exit code '1' >> ERROR: '/home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb' failed >> frans@linux-suse:~/oe/openembedded> > > > koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ > MACHINE=omap4430-panda bitbake -b u-boot-sakoman_git.bb > > Build Configuration: > BB_VERSION = "1.11.0" > METADATA_BRANCH = "org.openembedded.dev" > METADATA_REVISION = "67c4a78" > TARGET_ARCH = "arm" > TARGET_OS = "linux-gnueabi" > MACHINE = "omap4430-panda" > DISTRO = "angstrom" > DISTRO_VERSION = "2010.7-test-20101231" > TARGET_FPU = "hard" > > NOTE: Preparing runqueue > NOTE: Executing runqueue > NOTE: Running task 1 of 20 (ID: 11, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_setscene) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_setscene: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_setscene: Succeeded > --2010-12-31 19:31:20-- > http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz > Resolving www.angstrom-distribution.org... 188.40.83.200 > NOTE: Running task 2 of 20 (ID: 9, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_fetch) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_fetch: Started > NOTE: fetch > http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz > > <snip> > > 2010-12-31 19:39:01 (24.4 KB/s) - > `/OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz' > saved [11415903/11415903] > > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_fetch: Succeeded > NOTE: Running task 4 of 20 (ID: 16, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_distribute_sources) > NOTE: Running task 3 of 20 (ID: 0, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_unpack) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_distribute_sources: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_distribute_sources: Succeeded > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_unpack: Started > NOTE: Unpacking > /OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz > to > /OE/angstrom-dev/work/omap4430-panda-angstrom-linux-gnueabi/u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0/ > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_unpack: Succeeded > NOTE: Running task 5 of 20 (ID: 1, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_patch) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_patch: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_patch: Succeeded > NOTE: Running task 6 of 20 (ID: 12, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_configure) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_configure: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_configure: Succeeded > NOTE: Running task 7 of 20 (ID: 13, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_qa_configure) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_configure: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_configure: Succeeded > NOTE: Running task 8 of 20 (ID: 14, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_compile) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_compile: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_compile: Succeeded > NOTE: Running task 9 of 20 (ID: 2, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_install) > NOTE: Running task 10 of 20 (ID: 4, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_deploy) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_install: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_install: Succeeded > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_deploy: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_deploy: Succeeded > NOTE: Running task 11 of 20 (ID: 15, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package) > NOTE: Running task 12 of 20 (ID: 3, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_populate_sysroot) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_populate_sysroot: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_populate_sysroot: Succeeded > NOTE: Running task 13 of 20 (ID: 5, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_qa_staging) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_staging: Started > NOTE: package u-boot-sakoman skipped > NOTE: package u-boot-sakoman-fw-utils skipped > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package: Succeeded > NOTE: Running task 14 of 20 (ID: 19, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_write_ipk) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write_ipk: Started > Packaged contents of u-boot-sakoman-dbg into > /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dbg_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk > Packaged contents of u-boot-sakoman into > /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk > NOTE: Not creating empty archive for > u-boot-sakoman-doc-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > Packaged contents of u-boot-sakoman-dev into > /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dev_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk > NOTE: Not creating empty archive for > u-boot-sakoman-static-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > NOTE: Not creating empty archive for > u-boot-sakoman-locale-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > NOTE: Not creating empty archive for > u-boot-sakoman-fw-utils-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write_ipk: Succeeded > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_qa_staging: Succeeded > NOTE: Running task 15 of 20 (ID: 6, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_write) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_write: Succeeded > NOTE: Running task 16 of 20 (ID: 7, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_stage) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage: Succeeded > NOTE: Running task 17 of 20 (ID: 8, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_package_stage_all) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage_all: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_package_stage_all: Succeeded > NOTE: Running task 18 of 20 (ID: 10, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_build) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_build: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_build: Succeeded > NOTE: Running task 19 of 20 (ID: 17, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_rm_work) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work: Succeeded > NOTE: Running task 20 of 20 (ID: 18, > /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, > do_rm_work_all) > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work_all: Started > NOTE: package > u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_rm_work_all: Succeeded > NOTE: Tasks Summary: Attempted 20 tasks of which 0 didn't need to be > rerun and 0 failed. > koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ > >> >> _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFNHjE1MkyGM64RGpERArZOAJ9veqwsqulCV4cyHiGVvdcpVTJQyACdHjOk ICTgpJ+C3jPlacYCwulr1dk= =vgSJ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 19:38 ` Koen Kooi @ 2010-12-31 21:46 ` Michael 'Mickey' Lauer 2011-01-01 18:12 ` Frans Meulenbroeks 1 sibling, 0 replies; 22+ messages in thread From: Michael 'Mickey' Lauer @ 2010-12-31 21:46 UTC (permalink / raw) To: openembedded-devel Am Freitag, den 31.12.2010, 20:38 +0100 schrieb Koen Kooi: > The configurations I'm concerned about use angstrom-mirrors.bbclass, I > don't care about others. I can send you my rate card if you want to pay > me to support crap like minimal. Ah finally, Mr. Attitude is back. We missed you so much. Happy new year! :M: ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 19:38 ` Koen Kooi 2010-12-31 21:46 ` Michael 'Mickey' Lauer @ 2011-01-01 18:12 ` Frans Meulenbroeks 2011-01-01 18:25 ` Philip Balister 1 sibling, 1 reply; 22+ messages in thread From: Frans Meulenbroeks @ 2011-01-01 18:12 UTC (permalink / raw) To: openembedded-devel 2010/12/31 Koen Kooi <k.kooi@student.utwente.nl>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 31-12-10 20:06, Frans Meulenbroeks wrote: >> 2010/12/31 Koen Kooi <k.kooi@student.utwente.nl>: >> On 31-12-10 16:47, Frans Meulenbroeks wrote: >>>>> The u-boot recipe for pandaboard is nonbuildable for a few >>>>> months. Apparently this recipe is orphaned. >>>>> I've made things buildable again by moving to the latest >>>>> mainline u-boot (as suggested by Steve Sakoman a few monts >>>>> ago). It builds fine, but is not tested on the actual >>>>> hardware (as I do not have access to a board). >>>>> Still I feel that a buildable recipe is better than using a >>>>> recipe that does not even build. >> >> NAK, since it builds just fine and the result of the new recipe doesn't >> work as good: >> >>> It does not build! See the log below. >>> The recipe says: >> >>> SRCREV = "ccd0c67858c6e2807c695e2c8f545284cb871866" >> >>> PV = "2010.9+${PR}+git${SRCREV}" >> >>> SRC_URI = "git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git \ >> >>> This SRCREV does not exist! >> >>> The only reason it works for you is because you use a mirror that has >>> a snapshot of the recipe. > > It's the standard angstrom source mirror from angstrom-mirrors.bbclass, > which anyone can use if they want to. > >>> If you are concerned about this recipe the least you can do is to make >>> sure that people can build it even if they do not have your mirror >>> present. > > The configurations I'm concerned about use angstrom-mirrors.bbclass, I > don't care about others. I can send you my rate card if you want to pay > me to support crap like minimal. Oh my, what are we polite again. I can perfectly support myself, thank you. We have a broken recipe and I feel it should be fixed. > >>> (by either moving the recipe to a SRCREV that exists or by changing >>> the SRC_URI to a location that *does* fetch). >>> In its current form I consider this recipe as broken! > > I only support angstrom for the machines I maintain, if other distros > want to support panda, they are free to mirror the snapshot if they want to. > There is no guarantee that any other SRCREV will keep existing for the > lengths of time, but the angstrom source mirror will keep the snapshot > for at least 3 years. Then as a machine maintainer you are doing a lousy job. A key idea of OE is that we support multiple targets and multiple distro's. Frans ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-01 18:12 ` Frans Meulenbroeks @ 2011-01-01 18:25 ` Philip Balister 2011-01-01 18:48 ` Frans Meulenbroeks 0 siblings, 1 reply; 22+ messages in thread From: Philip Balister @ 2011-01-01 18:25 UTC (permalink / raw) To: openembedded-devel On 01/01/2011 01:12 PM, Frans Meulenbroeks wrote: > > We have a broken recipe and I feel it should be fixed. Broken only for some OE use cases. Not broken for others. The wrong solution to the problem is to replace a recipe that works for the people who use it with a recipe that creates untested output. U-boot is a fiddly piece of software, updates should be tested on hardware before they are pushed. Let's keep the focus on the real issue here, disappearing sources versus recipes that produce untested output. Disappearing sources are an issue beyond just rebased git repos. Distros that provide binaries to end users must provide for this event to provide GPL compliance. So it really is not a big deal. Philip ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-01 18:25 ` Philip Balister @ 2011-01-01 18:48 ` Frans Meulenbroeks 0 siblings, 0 replies; 22+ messages in thread From: Frans Meulenbroeks @ 2011-01-01 18:48 UTC (permalink / raw) To: openembedded-devel 2011/1/1 Philip Balister <philip@balister.org>: > On 01/01/2011 01:12 PM, Frans Meulenbroeks wrote: >> >> We have a broken recipe and I feel it should be fixed. > > Broken only for some OE use cases. Not broken for others. > > The wrong solution to the problem is to replace a recipe that works for the > people who use it with a recipe that creates untested output. U-boot is a > fiddly piece of software, updates should be tested on hardware before they > are pushed. > > Let's keep the focus on the real issue here, disappearing sources versus > recipes that produce untested output. > > Disappearing sources are an issue beyond just rebased git repos. Distros > that provide binaries to end users must provide for this event to provide > GPL compliance. So it really is not a big deal. > > Philip > I am not going to rehash what I wrote a few minutes ago. What I want to say is that there are other ways to fix the problem, but the recipe maintainer does not care to fix the problem in a generic way. I'm well aware that u-boot is a complex thing And I am more than happy to test the recipe as soon as my board arrives. (actually I bumped into this issue as I was already preparing the image I want to run on it). Disappearing sources is indeed an issue. We saw that with handhelds.org last month. Distro specific source archives, leading to broken recipes for other distros is probably not the best solution. One other thing: I feel the way Koen is acting and the tone of his emails is not really desirable for an open source project where several developers cooperate to achieve a common goal. Actually this kind of behaviour may well drive away people (e.g. to Yocto). I am not too sure if that is desired. Frans. (who wants to take this opportunity to wish everyone a good 2011 with lots of fun). ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 19:06 ` Frans Meulenbroeks 2010-12-31 19:38 ` Koen Kooi @ 2010-12-31 19:44 ` Philip Balister 2010-12-31 21:48 ` Michael 'Mickey' Lauer 2011-01-01 18:37 ` Frans Meulenbroeks 1 sibling, 2 replies; 22+ messages in thread From: Philip Balister @ 2010-12-31 19:44 UTC (permalink / raw) To: openembedded-devel On 12/31/2010 02:06 PM, Frans Meulenbroeks wrote: > 2010/12/31 Koen Kooi<k.kooi@student.utwente.nl>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 31-12-10 16:47, Frans Meulenbroeks wrote: >>> The u-boot recipe for pandaboard is nonbuildable for a few >>> months. Apparently this recipe is orphaned. >>> I've made things buildable again by moving to the latest >>> mainline u-boot (as suggested by Steve Sakoman a few monts >>> ago). It builds fine, but is not tested on the actual >>> hardware (as I do not have access to a board). >>> Still I feel that a buildable recipe is better than using a >>> recipe that does not even build. >> >> NAK, since it builds just fine and the result of the new recipe doesn't >> work as good: > > It does not build! See the log below. > The recipe says: > > SRCREV = "ccd0c67858c6e2807c695e2c8f545284cb871866" > > PV = "2010.9+${PR}+git${SRCREV}" > > SRC_URI = "git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git \ > > This SRCREV does not exist! > > The only reason it works for you is because you use a mirror that has > a snapshot of the recipe. > If you are concerned about this recipe the least you can do is to make > sure that people can build it even if they do not have your mirror > present. > (by either moving the recipe to a SRCREV that exists or by changing > the SRC_URI to a location that *does* fetch). > In its current form I consider this recipe as broken! Frans, given these two choices: 1) Recipe that builds and has tested output (but depends on distro source mirrors). 2) Recipe that builds (even without source mirrors), BUT the output is not tested. We should use choice #1, since the OUTPUT is tested. If someone who can test the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just to get recipes to build and not testing the output only leads to frustrated users who think the output works. I'd point out that no one on the panda list (or this list) has mentioned they noticed the recipe doesn't build, so I am not sure you are addressing an actual problem. Philip > > Frans. > > frans@linux-suse:~/oe/openembedded> bitbake u-boot-sakoman > Loading cache: 100% > |##############################################################################| > ETA: 00:00:00 > Loaded 7231 entries from dependency cache. > Parsing recipes: 100% > |############################################################################| > Time: 00:00:29 > Parsing of 7278 .bb files complete (6537 cached, 741 parsed). 7982 > targets, 310 skipped, 0 masked, 0 errors. > > Build Configuration: > BB_VERSION = "1.11.0" > METADATA_BRANCH = "org.openembedded.dev" > METADATA_REVISION = "ee3dfcd" > TARGET_ARCH = "arm" > TARGET_OS = "linux-gnueabi" > MACHINE = "omap4430-panda" > DISTRO = "minimal" > DISTRO_VERSION = "dev-snapshot-20101231" > TARGET_FPU = "soft" > > NOTE: Resolving any missing task queue dependencies > NOTE: Preparing runqueue > NOTE: Executing runqueue > NOTE: Running task 1229 of 1247 (ID: 9, > /home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb, > do_fetch) > NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task do_fetch: Started >> From git://www.sakoman.com/git/u-boot > * branch omap4-exp -> FETCH_HEAD > NOTE: Creating tarball of git repository > fatal: failed to unpack tree object ccd0c67858c6e2807c695e2c8f545284cb871866 > NOTE: package u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: > task Fetch failed: Unable to fetch URL > git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git > from any source.: Failed > ERROR: Function 'Fetch failed: Unable to fetch URL > git://www.sakoman.com/git/u-boot.git;branch=omap4-exp;protocol=git > from any source.' failed > ERROR: Task 9 (/home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb, > do_fetch) failed with exit code '1' > ERROR: '/home/frans/oe/openembedded/recipes/u-boot/u-boot-sakoman_git.bb' failed > frans@linux-suse:~/oe/openembedded> > > >> koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ >> MACHINE=omap4430-panda bitbake -b u-boot-sakoman_git.bb >> >> Build Configuration: >> BB_VERSION = "1.11.0" >> METADATA_BRANCH = "org.openembedded.dev" >> METADATA_REVISION = "67c4a78" >> TARGET_ARCH = "arm" >> TARGET_OS = "linux-gnueabi" >> MACHINE = "omap4430-panda" >> DISTRO = "angstrom" >> DISTRO_VERSION = "2010.7-test-20101231" >> TARGET_FPU = "hard" >> >> NOTE: Preparing runqueue >> NOTE: Executing runqueue >> NOTE: Running task 1 of 20 (ID: 11, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_setscene) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_setscene: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_setscene: Succeeded >> - --2010-12-31 19:31:20-- >> http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz >> Resolving www.angstrom-distribution.org... 188.40.83.200 >> NOTE: Running task 2 of 20 (ID: 9, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_fetch) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_fetch: Started >> NOTE: fetch >> http://www.angstrom-distribution.org/unstable/sources/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz >> >> <snip> >> >> 2010-12-31 19:39:01 (24.4 KB/s) - >> `/OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz' >> saved [11415903/11415903] >> >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_fetch: Succeeded >> NOTE: Running task 4 of 20 (ID: 16, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_distribute_sources) >> NOTE: Running task 3 of 20 (ID: 0, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_unpack) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_distribute_sources: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_distribute_sources: Succeeded >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_unpack: Started >> NOTE: Unpacking >> /OE/downloads/git_www.sakoman.com.git.u-boot.git_ccd0c67858c6e2807c695e2c8f545284cb871866.tar.gz >> to >> /OE/angstrom-dev/work/omap4430-panda-angstrom-linux-gnueabi/u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0/ >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_unpack: Succeeded >> NOTE: Running task 5 of 20 (ID: 1, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_patch) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_patch: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_patch: Succeeded >> NOTE: Running task 6 of 20 (ID: 12, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_configure) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_configure: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_configure: Succeeded >> NOTE: Running task 7 of 20 (ID: 13, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_qa_configure) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_qa_configure: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_qa_configure: Succeeded >> NOTE: Running task 8 of 20 (ID: 14, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_compile) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_compile: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_compile: Succeeded >> NOTE: Running task 9 of 20 (ID: 2, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_install) >> NOTE: Running task 10 of 20 (ID: 4, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_deploy) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_install: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_install: Succeeded >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_deploy: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_deploy: Succeeded >> NOTE: Running task 11 of 20 (ID: 15, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_package) >> NOTE: Running task 12 of 20 (ID: 3, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_populate_sysroot) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_populate_sysroot: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_populate_sysroot: Succeeded >> NOTE: Running task 13 of 20 (ID: 5, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_qa_staging) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_qa_staging: Started >> NOTE: package u-boot-sakoman skipped >> NOTE: package u-boot-sakoman-fw-utils skipped >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package: Succeeded >> NOTE: Running task 14 of 20 (ID: 19, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_package_write_ipk) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_write_ipk: Started >> Packaged contents of u-boot-sakoman-dbg into >> /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dbg_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk >> Packaged contents of u-boot-sakoman into >> /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk >> NOTE: Not creating empty archive for >> u-boot-sakoman-doc-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 >> Packaged contents of u-boot-sakoman-dev into >> /OE/angstrom-dev/deploy/glibc/ipk/omap4430-panda/u-boot-sakoman-dev_2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6_omap4430-panda.ipk >> NOTE: Not creating empty archive for >> u-boot-sakoman-static-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 >> NOTE: Not creating empty archive for >> u-boot-sakoman-locale-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 >> NOTE: Not creating empty archive for >> u-boot-sakoman-fw-utils-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0.6 >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_write_ipk: Succeeded >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_qa_staging: Succeeded >> NOTE: Running task 15 of 20 (ID: 6, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_package_write) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_write: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_write: Succeeded >> NOTE: Running task 16 of 20 (ID: 7, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_package_stage) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_stage: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_stage: Succeeded >> NOTE: Running task 17 of 20 (ID: 8, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_package_stage_all) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_stage_all: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_package_stage_all: Succeeded >> NOTE: Running task 18 of 20 (ID: 10, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_build) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_build: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_build: Succeeded >> NOTE: Running task 19 of 20 (ID: 17, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, do_rm_work) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_rm_work: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_rm_work: Succeeded >> NOTE: Running task 20 of 20 (ID: 18, >> /OE/org.openembedded.dev/recipes/u-boot/u-boot-sakoman_git.bb, >> do_rm_work_all) >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_rm_work_all: Started >> NOTE: package >> u-boot-sakoman-2010.9+r0+gitccd0c67858c6e2807c695e2c8f545284cb871866-r0: >> task do_rm_work_all: Succeeded >> NOTE: Tasks Summary: Attempted 20 tasks of which 0 didn't need to be >> rerun and 0 failed. >> koen@dominion:/OE/org.openembedded.dev/recipes/u-boot$ >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.5 (Darwin) >> >> iD8DBQFNHiPtMkyGM64RGpERApY1AJ9LZNHfpTr7TQGatDxuFCV/fNPOiACfU2n0 >> tAJXkFpiWeFxZMI0nnj4jqQ= >> =vQ8j >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> Openembedded-devel mailing list >> Openembedded-devel@lists.openembedded.org >> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel >> > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 19:44 ` Philip Balister @ 2010-12-31 21:48 ` Michael 'Mickey' Lauer 2011-01-01 18:37 ` Frans Meulenbroeks 1 sibling, 0 replies; 22+ messages in thread From: Michael 'Mickey' Lauer @ 2010-12-31 21:48 UTC (permalink / raw) To: openembedded-devel By that logic we either need to ban everything but the one blessed distro to rule them all or introduce a DISTRO_COMPATIBLE asap. I don't think OpenEmbedded benefits from either choice. -- :M: ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2010-12-31 19:44 ` Philip Balister 2010-12-31 21:48 ` Michael 'Mickey' Lauer @ 2011-01-01 18:37 ` Frans Meulenbroeks 2011-01-01 19:13 ` Philip Balister [not found] ` <1294680282.4307.7639.camel@mill.internal.reciva.com> 1 sibling, 2 replies; 22+ messages in thread From: Frans Meulenbroeks @ 2011-01-01 18:37 UTC (permalink / raw) To: openembedded-devel, tsc [Added TSC to the email, as I would like to request a decision on how to handle this] > Frans, given these two choices: > > 1) Recipe that builds and has tested output (but depends on distro source > mirrors). > > 2) Recipe that builds (even without source mirrors), BUT the output is not > tested. > > We should use choice #1, since the OUTPUT is tested. If someone who can test > the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just to > get recipes to build and not testing the output only leads to frustrated > users who think the output works. > > I'd point out that no one on the panda list (or this list) has mentioned > they noticed the recipe doesn't build, so I am not sure you are addressing > an actual problem. > > Philip > Philip, thanks for your reply. I'd like to point out that the fact that the recipe does not build has been reported to this very list late oct 2010. At that point Steve Sakoman (the owner of the git from which the recipe pulls) suggested to use u-boot 2010.09. I did not get to fixing the recipe until yesterday. As u-boot 2010.12 is already out I figured that this would be a better choice. I am also on the u-boot list and I know the changes from Steve are pulled into u-boot master. (and wrt to availability: I am quite confident that in a few years time this version can still be retrieved). The problem that this recipe does not build is already known for more than 2 months but the machine maintainer apparently is not interested in fixing his recipe. As such I feel the maintainer is doing a bad job. There are several ways to fix the problem. To coin a few: - move to a SRCREV that seems to me more stable (e.g. because it is a merge with upstream). I agree that there is still a chance of getting a breakage in the future - putting the tarball for the version that we have now at e.g. downloads.openembedded.org or so and adapt the recipe (we have done this for other recipes as well) - move to upstream. The panda changes from Steve have been merged by Wolfgang. I am not aware of any reason not to do so. While each alternative has its pro's and con's none of them is complicated, and any of them could have been done easily. As the problem is already reported last october, I feel the maintainer is not doing a good job, and actually makes things worse by abusing his powers to block others who want to fix it. Apparently spending a few minutes to resolve the issue is too much work, but there is of course always time to bitch and moan toward others who do want to keep OE a system that supports multiple machines and multiple distros. I'd like to ask the TSC to come up with a decision on how we should fix this recipe. I have already indicated a few solutions above. Yet another alternative (which is not too desirable) is to create another machine that chooses a proper recipe for u-boot. Frans PS: the fact that there are no other reports of this is probably because not many people rebuild u-boot. Most of my boards still use the u-boot that was on the board when I got it. I guess this also holds for other people. ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-01 18:37 ` Frans Meulenbroeks @ 2011-01-01 19:13 ` Philip Balister [not found] ` <1294680282.4307.7639.camel@mill.internal.reciva.com> 1 sibling, 0 replies; 22+ messages in thread From: Philip Balister @ 2011-01-01 19:13 UTC (permalink / raw) To: openembedded-devel On 01/01/2011 01:37 PM, Frans Meulenbroeks wrote: > [Added TSC to the email, as I would like to request a decision on how > to handle this] > >> Frans, given these two choices: >> >> 1) Recipe that builds and has tested output (but depends on distro source >> mirrors). >> >> 2) Recipe that builds (even without source mirrors), BUT the output is not >> tested. >> >> We should use choice #1, since the OUTPUT is tested. If someone who can test >> the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just to >> get recipes to build and not testing the output only leads to frustrated >> users who think the output works. >> >> I'd point out that no one on the panda list (or this list) has mentioned >> they noticed the recipe doesn't build, so I am not sure you are addressing >> an actual problem. >> >> Philip >> > > Philip, thanks for your reply. > > I'd like to point out that the fact that the recipe does not build has > been reported to this very list late oct 2010. > At that point Steve Sakoman (the owner of the git from which the > recipe pulls) suggested to use u-boot 2010.09. > I did not get to fixing the recipe until yesterday. As u-boot 2010.12 > is already out I figured that this would be a better choice. > I am also on the u-boot list and I know the changes from Steve are > pulled into u-boot master. > (and wrt to availability: I am quite confident that in a few years > time this version can still be retrieved). > > The problem that this recipe does not build is already known for more > than 2 months but the machine maintainer apparently is not interested > in fixing his recipe. > As such I feel the maintainer is doing a bad job. > > There are several ways to fix the problem. > To coin a few: > - move to a SRCREV that seems to me more stable (e.g. because it is a > merge with upstream). I agree that there is still a chance of getting > a breakage in the future > - putting the tarball for the version that we have now at e.g. > downloads.openembedded.org or so and adapt the recipe (we have done > this for other recipes as well) > - move to upstream. The panda changes from Steve have been merged by > Wolfgang. I am not aware of any reason not to do so. > > While each alternative has its pro's and con's none of them is > complicated, and any of them could have been done easily. > As the problem is already reported last october, I feel the maintainer > is not doing a good job, and actually makes things worse by abusing > his powers to block others who want to fix it. > Apparently spending a few minutes to resolve the issue is too much > work, but there is of course always time to bitch and moan toward > others who do want to keep OE a system that supports multiple machines > and multiple distros. > > I'd like to ask the TSC to come up with a decision on how we should > fix this recipe. I have already indicated a few solutions above. Yet > another alternative (which is not too desirable) is to create another > machine that chooses a proper recipe for u-boot. For the TSC's consideration, how about we start moving BSP's (board support packages) into layers and letting the users of boards be responsible for their maintenance? Philip > > Frans > > PS: the fact that there are no other reports of this is probably > because not many people rebuild u-boot. Most of my boards still use > the u-boot that was on the board when I got it. I guess this also > holds for other people. > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 22+ messages in thread
[parent not found: <1294680282.4307.7639.camel@mill.internal.reciva.com>]
[parent not found: <AANLkTimXV8BGQf8DQ7rNqu42d2E-RFaEUYkfMEOLPh+6@mail.gmail.com>]
* Re: [PATCH 2/2] omap4430-panda: fix u-boot [not found] ` <AANLkTimXV8BGQf8DQ7rNqu42d2E-RFaEUYkfMEOLPh+6@mail.gmail.com> @ 2011-01-11 9:28 ` Graeme Gregory 2011-01-11 9:35 ` Eric Bénard ` (2 more replies) 0 siblings, 3 replies; 22+ messages in thread From: Graeme Gregory @ 2011-01-11 9:28 UTC (permalink / raw) To: Frans Meulenbroeks, openembedded-devel This is really a technical disagreement between two developers so forwarded it back to the technical list. I do not have my panda yet to test new bootloaders, I can rely on the one official supported by TI working well until tests on a newer version can be performed. Until new version is tested on real panda I am against upgrading it. If some distro does not have the sources in its fetchable list can the source archive not be copied to a more general source mirror? Graeme On 10/01/2011 22:10, Frans Meulenbroeks wrote: > Dear TSC, > > Thank you for your reply. > I agree that replacing the SRC_URI with one that is fetchable > independent on distro specifics is the safest way to handle this. > (but then again the solution I took was suggested by the upstream > maintainer of the code). > > Unfortunately I feel that this decision does not touch the core of the problem. > The issue at hand is that we have a maintainer that is already aware > of the issue for almost three months (I've reported this problem > already back in october). > However this maintainer fails to take action, and has an attitude of > "it works for me and my distro it is ok, and if it does not work for > someone else, I don't care". > I would have appreciated it if the TSC would take a position against > this attitude,and the neglection to properly act as a maintainer. > > I feel this attitude is damaging OE. > The blunt actions of this person have already driven away several > people, and frankly speaking I'm also rapidly loosing interest to work > on issues that are not strictly needed for my own projects. > I feel we have a serious problem at hand that should have been dealt > with a long time ago, difficult as it is. > > If we want to have a future beside yocto, it is important to be a > friendly, respectful and cooperative community. Otherwise I fear OE > will be history in a short while (which is something that I would > pity, having been a member of the project for 5 years or so). As a > crew I feel we are already close to being subcritical in number. > Anyway, I for me, I am getting tired of being bitched at, where a > polite message probably would have had much more effect. > This is especially the case if it is by someone who has repeatedly > shown disrespect for the work of others when it comes to making > changes. > > A bit sad, > Frans Meulenbroeks. > > > 2011/1/10 Phil Blundell<philb@gnu.org>: >> Frans, >> >> Thanks for your email. We discussed this issue at the TSC meeting held >> on 2011-01-05. >> >> The TSC feels that we should be guided by two key principles, namely: >> >> a) all recipes should have a SRC_URI which is fetchable without relying >> on any DISTRO-specific configuration (e.g. custom source mirrors); and >> >> b) the version number (or SRCREV) of a given recipe should only be >> bumped after testing and consultation with its users. This applies >> particularly to packages such as bootloaders and kernels which contain >> many machine-specific parts and which would have particularly bad >> consequences if inadvertently upgraded to nonworking versions. >> >> In this particular case the TSC believes that the right course of action >> is to: >> >> 1. Find a way to repair the SRC_URI for the existing u-boot recipe so >> that it is fetchable for everyone, but without changing the version of >> the source code in use or the resulting binaries. (For example, the >> SRC_URI could be pointed directly at a snapshot tarball hosted in some >> suitable place.) >> >> 2. Create an additional recipe for the current mainline version of >> u-boot which can be fetched from SVN. Individual machine maintainers >> can test this version and, if it works for them, switch to using it at >> their discretion. >> >> Regards >> >> Phil >> (for the TSC) >> >> On Sat, 2011-01-01 at 19:37 +0100, Frans Meulenbroeks wrote: >>> [Added TSC to the email, as I would like to request a decision on how >>> to handle this] >>> >>>> Frans, given these two choices: >>>> >>>> 1) Recipe that builds and has tested output (but depends on distro source >>>> mirrors). >>>> >>>> 2) Recipe that builds (even without source mirrors), BUT the output is not >>>> tested. >>>> >>>> We should use choice #1, since the OUTPUT is tested. If someone who can test >>>> the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just to >>>> get recipes to build and not testing the output only leads to frustrated >>>> users who think the output works. >>>> >>>> I'd point out that no one on the panda list (or this list) has mentioned >>>> they noticed the recipe doesn't build, so I am not sure you are addressing >>>> an actual problem. >>>> >>>> Philip >>>> >>> Philip, thanks for your reply. >>> >>> I'd like to point out that the fact that the recipe does not build has >>> been reported to this very list late oct 2010. >>> At that point Steve Sakoman (the owner of the git from which the >>> recipe pulls) suggested to use u-boot 2010.09. >>> I did not get to fixing the recipe until yesterday. As u-boot 2010.12 >>> is already out I figured that this would be a better choice. >>> I am also on the u-boot list and I know the changes from Steve are >>> pulled into u-boot master. >>> (and wrt to availability: I am quite confident that in a few years >>> time this version can still be retrieved). >>> >>> The problem that this recipe does not build is already known for more >>> than 2 months but the machine maintainer apparently is not interested >>> in fixing his recipe. >>> As such I feel the maintainer is doing a bad job. >>> >>> There are several ways to fix the problem. >>> To coin a few: >>> - move to a SRCREV that seems to me more stable (e.g. because it is a >>> merge with upstream). I agree that there is still a chance of getting >>> a breakage in the future >>> - putting the tarball for the version that we have now at e.g. >>> downloads.openembedded.org or so and adapt the recipe (we have done >>> this for other recipes as well) >>> - move to upstream. The panda changes from Steve have been merged by >>> Wolfgang. I am not aware of any reason not to do so. >>> >>> While each alternative has its pro's and con's none of them is >>> complicated, and any of them could have been done easily. >>> As the problem is already reported last october, I feel the maintainer >>> is not doing a good job, and actually makes things worse by abusing >>> his powers to block others who want to fix it. >>> Apparently spending a few minutes to resolve the issue is too much >>> work, but there is of course always time to bitch and moan toward >>> others who do want to keep OE a system that supports multiple machines >>> and multiple distros. >>> >>> I'd like to ask the TSC to come up with a decision on how we should >>> fix this recipe. I have already indicated a few solutions above. Yet >>> another alternative (which is not too desirable) is to create another >>> machine that chooses a proper recipe for u-boot. >>> >>> Frans >>> >>> PS: the fact that there are no other reports of this is probably >>> because not many people rebuild u-boot. Most of my boards still use >>> the u-boot that was on the board when I got it. I guess this also >>> holds for other people. >>> >>> _______________________________________________ >>> tsc mailing list >>> tsc@lists.linuxtogo.org >>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc >> >> ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-11 9:28 ` Graeme Gregory @ 2011-01-11 9:35 ` Eric Bénard 2011-01-11 18:51 ` Marcin Juszkiewicz 2011-01-11 9:46 ` Koen Kooi 2011-01-11 11:26 ` Frans Meulenbroeks 2 siblings, 1 reply; 22+ messages in thread From: Eric Bénard @ 2011-01-11 9:35 UTC (permalink / raw) To: openembedded-devel On 11/01/2011 10:28, Graeme Gregory wrote: > If some distro does not have the sources in its fetchable list can the > source archive not be copied to a more general source mirror? > more globally, shouldn't OE provide a source mirror for _everything_ which can be fetched by the project. This would avoid problems like handhelds.org's vanishing. Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-11 9:35 ` Eric Bénard @ 2011-01-11 18:51 ` Marcin Juszkiewicz 2011-01-11 18:56 ` Eric Bénard 0 siblings, 1 reply; 22+ messages in thread From: Marcin Juszkiewicz @ 2011-01-11 18:51 UTC (permalink / raw) To: openembedded-devel Dnia wtorek, 11 stycznia 2011 o 03:35:18 Eric Bénard napisał(a): > On 11/01/2011 10:28, Graeme Gregory wrote: > > If some distro does not have the sources in its fetchable list can > > the source archive not be copied to a more general source mirror? > > more globally, shouldn't OE provide a source mirror for everything > which can be fetched by the project. This would avoid problems like > handhelds.org's vanishing. OpenEmbedded project provided metadata. It is distributions which should provide sources. They select which SRCREVs are used... ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-11 18:51 ` Marcin Juszkiewicz @ 2011-01-11 18:56 ` Eric Bénard 0 siblings, 0 replies; 22+ messages in thread From: Eric Bénard @ 2011-01-11 18:56 UTC (permalink / raw) To: openembedded-devel On 11/01/2011 19:51, Marcin Juszkiewicz wrote: > Dnia wtorek, 11 stycznia 2011 o 03:35:18 Eric Bénard napisał(a): >> On 11/01/2011 10:28, Graeme Gregory wrote: >>> If some distro does not have the sources in its fetchable list can >>> the source archive not be copied to a more general source mirror? >> >> more globally, shouldn't OE provide a source mirror for everything >> which can be fetched by the project. This would avoid problems like >> handhelds.org's vanishing. > > OpenEmbedded project provided metadata. It is distributions which should > provide sources. They select which SRCREVs are used... I was thinking of thttp://sources.openembedded.org/ which doesn't seems to be linked to any distro and already mirrors some sources archives. Eric ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-11 9:28 ` Graeme Gregory 2011-01-11 9:35 ` Eric Bénard @ 2011-01-11 9:46 ` Koen Kooi 2011-01-11 11:26 ` Frans Meulenbroeks 2 siblings, 0 replies; 22+ messages in thread From: Koen Kooi @ 2011-01-11 9:46 UTC (permalink / raw) To: openembedded-devel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11-01-11 10:28, Graeme Gregory wrote: > This is really a technical disagreement between two developers so > forwarded it back to the technical list. > > I do not have my panda yet to test new bootloaders, I can rely on the > one official supported by TI working well until tests on a newer version > can be performed. Until new version is tested on real panda I am against > upgrading it. If some distro does not have the sources in its fetchable > list can the source archive not be copied to a more general source mirror? I was actually working with Tom to get the OE and angstrom mirrors synced, but I stopped that. > > Graeme > > On 10/01/2011 22:10, Frans Meulenbroeks wrote: >> Dear TSC, >> >> Thank you for your reply. >> I agree that replacing the SRC_URI with one that is fetchable >> independent on distro specifics is the safest way to handle this. >> (but then again the solution I took was suggested by the upstream >> maintainer of the code). >> >> Unfortunately I feel that this decision does not touch the core of the >> problem. >> The issue at hand is that we have a maintainer that is already aware >> of the issue for almost three months (I've reported this problem >> already back in october). >> However this maintainer fails to take action, and has an attitude of >> "it works for me and my distro it is ok, and if it does not work for >> someone else, I don't care". >> I would have appreciated it if the TSC would take a position against >> this attitude,and the neglection to properly act as a maintainer. >> >> I feel this attitude is damaging OE. >> The blunt actions of this person have already driven away several >> people, and frankly speaking I'm also rapidly loosing interest to work >> on issues that are not strictly needed for my own projects. >> I feel we have a serious problem at hand that should have been dealt >> with a long time ago, difficult as it is. >> >> If we want to have a future beside yocto, it is important to be a >> friendly, respectful and cooperative community. Otherwise I fear OE >> will be history in a short while (which is something that I would >> pity, having been a member of the project for 5 years or so). As a >> crew I feel we are already close to being subcritical in number. >> Anyway, I for me, I am getting tired of being bitched at, where a >> polite message probably would have had much more effect. >> This is especially the case if it is by someone who has repeatedly >> shown disrespect for the work of others when it comes to making >> changes. >> >> A bit sad, >> Frans Meulenbroeks. >> >> >> 2011/1/10 Phil Blundell<philb@gnu.org>: >>> Frans, >>> >>> Thanks for your email. We discussed this issue at the TSC meeting held >>> on 2011-01-05. >>> >>> The TSC feels that we should be guided by two key principles, namely: >>> >>> a) all recipes should have a SRC_URI which is fetchable without relying >>> on any DISTRO-specific configuration (e.g. custom source mirrors); and >>> >>> b) the version number (or SRCREV) of a given recipe should only be >>> bumped after testing and consultation with its users. This applies >>> particularly to packages such as bootloaders and kernels which contain >>> many machine-specific parts and which would have particularly bad >>> consequences if inadvertently upgraded to nonworking versions. >>> >>> In this particular case the TSC believes that the right course of action >>> is to: >>> >>> 1. Find a way to repair the SRC_URI for the existing u-boot recipe so >>> that it is fetchable for everyone, but without changing the version of >>> the source code in use or the resulting binaries. (For example, the >>> SRC_URI could be pointed directly at a snapshot tarball hosted in some >>> suitable place.) >>> >>> 2. Create an additional recipe for the current mainline version of >>> u-boot which can be fetched from SVN. Individual machine maintainers >>> can test this version and, if it works for them, switch to using it at >>> their discretion. >>> >>> Regards >>> >>> Phil >>> (for the TSC) >>> >>> On Sat, 2011-01-01 at 19:37 +0100, Frans Meulenbroeks wrote: >>>> [Added TSC to the email, as I would like to request a decision on how >>>> to handle this] >>>> >>>>> Frans, given these two choices: >>>>> >>>>> 1) Recipe that builds and has tested output (but depends on distro >>>>> source >>>>> mirrors). >>>>> >>>>> 2) Recipe that builds (even without source mirrors), BUT the output >>>>> is not >>>>> tested. >>>>> >>>>> We should use choice #1, since the OUTPUT is tested. If someone who >>>>> can test >>>>> the output wants to bump the SRCREV, that is fine. Bumping SRCREVs >>>>> just to >>>>> get recipes to build and not testing the output only leads to >>>>> frustrated >>>>> users who think the output works. >>>>> >>>>> I'd point out that no one on the panda list (or this list) has >>>>> mentioned >>>>> they noticed the recipe doesn't build, so I am not sure you are >>>>> addressing >>>>> an actual problem. >>>>> >>>>> Philip >>>>> >>>> Philip, thanks for your reply. >>>> >>>> I'd like to point out that the fact that the recipe does not build has >>>> been reported to this very list late oct 2010. >>>> At that point Steve Sakoman (the owner of the git from which the >>>> recipe pulls) suggested to use u-boot 2010.09. >>>> I did not get to fixing the recipe until yesterday. As u-boot 2010.12 >>>> is already out I figured that this would be a better choice. >>>> I am also on the u-boot list and I know the changes from Steve are >>>> pulled into u-boot master. >>>> (and wrt to availability: I am quite confident that in a few years >>>> time this version can still be retrieved). >>>> >>>> The problem that this recipe does not build is already known for more >>>> than 2 months but the machine maintainer apparently is not interested >>>> in fixing his recipe. >>>> As such I feel the maintainer is doing a bad job. >>>> >>>> There are several ways to fix the problem. >>>> To coin a few: >>>> - move to a SRCREV that seems to me more stable (e.g. because it is a >>>> merge with upstream). I agree that there is still a chance of getting >>>> a breakage in the future >>>> - putting the tarball for the version that we have now at e.g. >>>> downloads.openembedded.org or so and adapt the recipe (we have done >>>> this for other recipes as well) >>>> - move to upstream. The panda changes from Steve have been merged by >>>> Wolfgang. I am not aware of any reason not to do so. >>>> >>>> While each alternative has its pro's and con's none of them is >>>> complicated, and any of them could have been done easily. >>>> As the problem is already reported last october, I feel the maintainer >>>> is not doing a good job, and actually makes things worse by abusing >>>> his powers to block others who want to fix it. >>>> Apparently spending a few minutes to resolve the issue is too much >>>> work, but there is of course always time to bitch and moan toward >>>> others who do want to keep OE a system that supports multiple machines >>>> and multiple distros. >>>> >>>> I'd like to ask the TSC to come up with a decision on how we should >>>> fix this recipe. I have already indicated a few solutions above. Yet >>>> another alternative (which is not too desirable) is to create another >>>> machine that chooses a proper recipe for u-boot. >>>> >>>> Frans >>>> >>>> PS: the fact that there are no other reports of this is probably >>>> because not many people rebuild u-boot. Most of my boards still use >>>> the u-boot that was on the board when I got it. I guess this also >>>> holds for other people. >>>> >>>> _______________________________________________ >>>> tsc mailing list >>>> tsc@lists.linuxtogo.org >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc >>> >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) iD8DBQFNLCb7MkyGM64RGpERAo5eAJ9JK6wiIgYldJdVJDXW1ab6mmPTvQCfbXQ+ n7QUhom6IBcJzv4lfFAq/74= =EcQF -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 2/2] omap4430-panda: fix u-boot 2011-01-11 9:28 ` Graeme Gregory 2011-01-11 9:35 ` Eric Bénard 2011-01-11 9:46 ` Koen Kooi @ 2011-01-11 11:26 ` Frans Meulenbroeks 2 siblings, 0 replies; 22+ messages in thread From: Frans Meulenbroeks @ 2011-01-11 11:26 UTC (permalink / raw) To: Graeme Gregory; +Cc: openembedded-devel Dear Graeme, Personally I feel it is not done to forward private mail without permission of the author to a public mailing list, especially not if the email contains opinions on other people. If I did want to send this to the list I would have done so myself. I would have expected a more prudent behaviour of a board member. Best regards, Frans. Dear list, As you can read above this was forwarded to the list without my permission or consent. Frans. 2011/1/11 Graeme Gregory <dp@xora.org.uk>: > This is really a technical disagreement between two developers so forwarded > it back to the technical list. > > I do not have my panda yet to test new bootloaders, I can rely on the one > official supported by TI working well until tests on a newer version can be > performed. Until new version is tested on real panda I am against upgrading > it. If some distro does not have the sources in its fetchable list can the > source archive not be copied to a more general source mirror? > > Graeme > > On 10/01/2011 22:10, Frans Meulenbroeks wrote: >> >> Dear TSC, >> >> Thank you for your reply. >> I agree that replacing the SRC_URI with one that is fetchable >> independent on distro specifics is the safest way to handle this. >> (but then again the solution I took was suggested by the upstream >> maintainer of the code). >> >> Unfortunately I feel that this decision does not touch the core of the >> problem. >> The issue at hand is that we have a maintainer that is already aware >> of the issue for almost three months (I've reported this problem >> already back in october). >> However this maintainer fails to take action, and has an attitude of >> "it works for me and my distro it is ok, and if it does not work for >> someone else, I don't care". >> I would have appreciated it if the TSC would take a position against >> this attitude,and the neglection to properly act as a maintainer. >> >> I feel this attitude is damaging OE. >> The blunt actions of this person have already driven away several >> people, and frankly speaking I'm also rapidly loosing interest to work >> on issues that are not strictly needed for my own projects. >> I feel we have a serious problem at hand that should have been dealt >> with a long time ago, difficult as it is. >> >> If we want to have a future beside yocto, it is important to be a >> friendly, respectful and cooperative community. Otherwise I fear OE >> will be history in a short while (which is something that I would >> pity, having been a member of the project for 5 years or so). As a >> crew I feel we are already close to being subcritical in number. >> Anyway, I for me, I am getting tired of being bitched at, where a >> polite message probably would have had much more effect. >> This is especially the case if it is by someone who has repeatedly >> shown disrespect for the work of others when it comes to making >> changes. >> >> A bit sad, >> Frans Meulenbroeks. >> >> >> 2011/1/10 Phil Blundell<philb@gnu.org>: >>> >>> Frans, >>> >>> Thanks for your email. We discussed this issue at the TSC meeting held >>> on 2011-01-05. >>> >>> The TSC feels that we should be guided by two key principles, namely: >>> >>> a) all recipes should have a SRC_URI which is fetchable without relying >>> on any DISTRO-specific configuration (e.g. custom source mirrors); and >>> >>> b) the version number (or SRCREV) of a given recipe should only be >>> bumped after testing and consultation with its users. This applies >>> particularly to packages such as bootloaders and kernels which contain >>> many machine-specific parts and which would have particularly bad >>> consequences if inadvertently upgraded to nonworking versions. >>> >>> In this particular case the TSC believes that the right course of action >>> is to: >>> >>> 1. Find a way to repair the SRC_URI for the existing u-boot recipe so >>> that it is fetchable for everyone, but without changing the version of >>> the source code in use or the resulting binaries. (For example, the >>> SRC_URI could be pointed directly at a snapshot tarball hosted in some >>> suitable place.) >>> >>> 2. Create an additional recipe for the current mainline version of >>> u-boot which can be fetched from SVN. Individual machine maintainers >>> can test this version and, if it works for them, switch to using it at >>> their discretion. >>> >>> Regards >>> >>> Phil >>> (for the TSC) >>> >>> On Sat, 2011-01-01 at 19:37 +0100, Frans Meulenbroeks wrote: >>>> >>>> [Added TSC to the email, as I would like to request a decision on how >>>> to handle this] >>>> >>>>> Frans, given these two choices: >>>>> >>>>> 1) Recipe that builds and has tested output (but depends on distro >>>>> source >>>>> mirrors). >>>>> >>>>> 2) Recipe that builds (even without source mirrors), BUT the output is >>>>> not >>>>> tested. >>>>> >>>>> We should use choice #1, since the OUTPUT is tested. If someone who can >>>>> test >>>>> the output wants to bump the SRCREV, that is fine. Bumping SRCREVs just >>>>> to >>>>> get recipes to build and not testing the output only leads to >>>>> frustrated >>>>> users who think the output works. >>>>> >>>>> I'd point out that no one on the panda list (or this list) has >>>>> mentioned >>>>> they noticed the recipe doesn't build, so I am not sure you are >>>>> addressing >>>>> an actual problem. >>>>> >>>>> Philip >>>>> >>>> Philip, thanks for your reply. >>>> >>>> I'd like to point out that the fact that the recipe does not build has >>>> been reported to this very list late oct 2010. >>>> At that point Steve Sakoman (the owner of the git from which the >>>> recipe pulls) suggested to use u-boot 2010.09. >>>> I did not get to fixing the recipe until yesterday. As u-boot 2010.12 >>>> is already out I figured that this would be a better choice. >>>> I am also on the u-boot list and I know the changes from Steve are >>>> pulled into u-boot master. >>>> (and wrt to availability: I am quite confident that in a few years >>>> time this version can still be retrieved). >>>> >>>> The problem that this recipe does not build is already known for more >>>> than 2 months but the machine maintainer apparently is not interested >>>> in fixing his recipe. >>>> As such I feel the maintainer is doing a bad job. >>>> >>>> There are several ways to fix the problem. >>>> To coin a few: >>>> - move to a SRCREV that seems to me more stable (e.g. because it is a >>>> merge with upstream). I agree that there is still a chance of getting >>>> a breakage in the future >>>> - putting the tarball for the version that we have now at e.g. >>>> downloads.openembedded.org or so and adapt the recipe (we have done >>>> this for other recipes as well) >>>> - move to upstream. The panda changes from Steve have been merged by >>>> Wolfgang. I am not aware of any reason not to do so. >>>> >>>> While each alternative has its pro's and con's none of them is >>>> complicated, and any of them could have been done easily. >>>> As the problem is already reported last october, I feel the maintainer >>>> is not doing a good job, and actually makes things worse by abusing >>>> his powers to block others who want to fix it. >>>> Apparently spending a few minutes to resolve the issue is too much >>>> work, but there is of course always time to bitch and moan toward >>>> others who do want to keep OE a system that supports multiple machines >>>> and multiple distros. >>>> >>>> I'd like to ask the TSC to come up with a decision on how we should >>>> fix this recipe. I have already indicated a few solutions above. Yet >>>> another alternative (which is not too desirable) is to create another >>>> machine that chooses a proper recipe for u-boot. >>>> >>>> Frans >>>> >>>> PS: the fact that there are no other reports of this is probably >>>> because not many people rebuild u-boot. Most of my boards still use >>>> the u-boot that was on the board when I got it. I guess this also >>>> holds for other people. >>>> >>>> _______________________________________________ >>>> tsc mailing list >>>> tsc@lists.linuxtogo.org >>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc >>> >>> > > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) 2010-12-31 15:47 [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Frans Meulenbroeks 2010-12-31 15:47 ` [PATCH 2/2] omap4430-panda: fix u-boot Frans Meulenbroeks @ 2010-12-31 17:14 ` Khem Raj 2010-12-31 18:01 ` Frans Meulenbroeks 1 sibling, 1 reply; 22+ messages in thread From: Khem Raj @ 2010-12-31 17:14 UTC (permalink / raw) To: openembedded-devel I thought it was preferred for some machine. Whats the use of a DP=-1 recipe? So you intend to use it. On Fri, Dec 31, 2010 at 7:47 AM, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote: > Signed-off-by: Frans Meulenbroeks <fransmeulenbroeks@gmail.com> > --- > recipes/u-boot/u-boot_2010.12.bb | 19 +++++++++++++++++++ > 1 files changed, 19 insertions(+), 0 deletions(-) > create mode 100644 recipes/u-boot/u-boot_2010.12.bb > > diff --git a/recipes/u-boot/u-boot_2010.12.bb b/recipes/u-boot/u-boot_2010.12.bb > new file mode 100644 > index 0000000..174bebf > --- /dev/null > +++ b/recipes/u-boot/u-boot_2010.12.bb > @@ -0,0 +1,19 @@ > +PR = "r0" > +require u-boot.inc > + > +DEFAULT_PREFERENCE = "-1" > + > +SRC_URI = "ftp://ftp.denx.de/pub/u-boot/u-boot-${PV}.tar.bz2 " > +SRC_URI[md5sum] = "9024bbceabd176ae1d52df6db2e84bda" > +SRC_URI[sha256sum] = "1705772db7a18635693676abb8818542167cb131921c456a1edd0ed47e6b77fe" > + > + > +TARGET_LDFLAGS = "" > + > +inherit base > + > +do_compile () { > + oe_runmake ${UBOOT_MACHINE} > + oe_runmake all > +} > + > -- > 1.7.1 > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) 2010-12-31 17:14 ` [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Khem Raj @ 2010-12-31 18:01 ` Frans Meulenbroeks 2010-12-31 18:19 ` Khem Raj 0 siblings, 1 reply; 22+ messages in thread From: Frans Meulenbroeks @ 2010-12-31 18:01 UTC (permalink / raw) To: openembedded-devel 2010/12/31 Khem Raj <raj.khem@gmail.com>: > I thought it was preferred for some machine. Whats the use of a DP=-1 > recipe? So you intend to use it. Yes. a DP=1 for pandaboard is added in the next patch. I wanted to separate adding the recipe and enabling it for pandaboard (as I figured the latter might raise some controversy). I can also imagine other machines can use this (I need to check if it is good enough for kirkwood based hardware and I need some more testing for that before I move to this version). However, I wanted to make this available now, so others can also use it. BTW we have plenty of recipes with a DP=-1: grep DEFAULT_PREFERENCE */* | grep -- -1 | wc 421 1263 23484 guess some of them are enabled for specific hw, but several of them seem to be quite pointless. E.g. for cups we have 6 recipes: cups_1.1.23.bb cups_1.2.12.bb cups_1.2.7.bb cups_1.3.8.bb cups_1.4.3.bb cups_1.4.4.bb The last three have DP -1, none is pinned or has a hw specific DP. Frans ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) 2010-12-31 18:01 ` Frans Meulenbroeks @ 2010-12-31 18:19 ` Khem Raj 0 siblings, 0 replies; 22+ messages in thread From: Khem Raj @ 2010-12-31 18:19 UTC (permalink / raw) To: openembedded-devel On Fri, Dec 31, 2010 at 10:01 AM, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote: > 2010/12/31 Khem Raj <raj.khem@gmail.com>: >> I thought it was preferred for some machine. Whats the use of a DP=-1 >> recipe? So you intend to use it. > > Yes. a DP=1 for pandaboard is added in the next patch. ok > I wanted to separate adding the recipe and enabling it for pandaboard > (as I figured the latter might raise some controversy). > I can also imagine other machines can use this (I need to check if it > is good enough for kirkwood based hardware and I need some more > testing for that before I move to this version). > However, I wanted to make this available now, so others can also use it. > > BTW we have plenty of recipes with a DP=-1: > grep DEFAULT_PREFERENCE */* | grep -- -1 | wc > 421 1263 23484 > guess some of them are enabled for specific hw, but several of them > seem to be quite pointless. > E.g. for cups we have 6 recipes: cups_1.1.23.bb cups_1.2.12.bb > cups_1.2.7.bb cups_1.3.8.bb cups_1.4.3.bb cups_1.4.4.bb > The last three have DP -1, none is pinned or has a hw specific DP. yes we should try to reduce them if possible. > > Frans > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2011-01-11 18:56 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-31 15:47 [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Frans Meulenbroeks
2010-12-31 15:47 ` [PATCH 2/2] omap4430-panda: fix u-boot Frans Meulenbroeks
2010-12-31 18:41 ` Koen Kooi
2010-12-31 19:06 ` Frans Meulenbroeks
2010-12-31 19:38 ` Koen Kooi
2010-12-31 21:46 ` Michael 'Mickey' Lauer
2011-01-01 18:12 ` Frans Meulenbroeks
2011-01-01 18:25 ` Philip Balister
2011-01-01 18:48 ` Frans Meulenbroeks
2010-12-31 19:44 ` Philip Balister
2010-12-31 21:48 ` Michael 'Mickey' Lauer
2011-01-01 18:37 ` Frans Meulenbroeks
2011-01-01 19:13 ` Philip Balister
[not found] ` <1294680282.4307.7639.camel@mill.internal.reciva.com>
[not found] ` <AANLkTimXV8BGQf8DQ7rNqu42d2E-RFaEUYkfMEOLPh+6@mail.gmail.com>
2011-01-11 9:28 ` Graeme Gregory
2011-01-11 9:35 ` Eric Bénard
2011-01-11 18:51 ` Marcin Juszkiewicz
2011-01-11 18:56 ` Eric Bénard
2011-01-11 9:46 ` Koen Kooi
2011-01-11 11:26 ` Frans Meulenbroeks
2010-12-31 17:14 ` [PATCH 1/2] u-boot: added 2010.12 recipe (DEFAULT_PREFERENCE = -1) Khem Raj
2010-12-31 18:01 ` Frans Meulenbroeks
2010-12-31 18:19 ` Khem Raj
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.