Monday, 2013-07-29

*** khem <khem!> has quit IRC00:02
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has joined #yocto00:05
lpapp_what is this? WARNING: QA Issue: ELF binary '/home/lpapp/Projects/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/packages-split/nscd/usr/sbin/nscd' has relocations in .text00:05
lpapp_WARNING: QA Issue: No GNU_HASH in the elf binary: '/home/lpapp/Projects/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/packages-split/nscd/usr/sbin/nscd'00:05
lpapp_WARNING: QA Issue: ELF binary '/home/lpapp/Projects/poky/build/tmp/work/armv5te-poky-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/packages-split/external-sourcery-toolchain-utils/usr/bin/nscd' has relocations in .text00:05
*** Crofton <Crofton!> has quit IRC00:07
*** Crofton <Crofton!> has joined #yocto00:14
wmatit means the linker has to relocate .text segments at runtime00:24
lpapp_ok, let me be clear: why do I get this warning?00:25
lpapp_and why it just does not work?00:25
*** Crofton <Crofton!> has quit IRC00:27
wmatit will, those are just warnings00:27
*** Crofton <Crofton!> has joined #yocto00:28
*** __frank_ <__frank_!~frank@> has quit IRC00:29
*** Crofton <Crofton!> has quit IRC00:37
*** Crofton <Crofton!> has joined #yocto00:37
*** sameo <sameo!~samuel@> has joined #yocto00:40
*** ant_home <ant_home!> has quit IRC00:42
*** Squix <Squix!> has joined #yocto00:47
*** Crofton <Crofton!> has quit IRC00:47
*** Crofton <Crofton!> has joined #yocto00:48
nerdboylpapp_: the answer is to add -Wl,--hash-style=gnu to the package cflags00:48
*** mulhern <mulhern!> has quit IRC00:50
*** volker <volker!> has quit IRC00:52
*** mulhern <mulhern!> has joined #yocto00:53
*** sameo <sameo!~samuel@> has quit IRC00:54
*** _julian_ <_julian_!> has joined #yocto00:55
*** _julian <_julian!> has quit IRC00:56
*** phdeswer_ <phdeswer_!> has quit IRC01:00
*** Crofton <Crofton!> has quit IRC01:07
*** Crofton <Crofton!> has joined #yocto01:08
*** behanw <behanw!> has joined #yocto01:20
*** Crofton <Crofton!> has quit IRC01:27
*** Crofton <Crofton!> has joined #yocto01:28
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:36
*** Crofton <Crofton!> has quit IRC01:48
*** Crofton <Crofton!> has joined #yocto01:48
*** mitz <mitz!> has quit IRC01:53
*** mulhern <mulhern!> has quit IRC02:03
*** mitz <mitz!> has joined #yocto02:04
*** mitz <mitz!> has joined #yocto02:06
*** silviof2 <silviof2!> has joined #yocto02:08
*** silviof1 <silviof1!> has quit IRC02:11
*** Crofton <Crofton!> has quit IRC02:17
*** Crofton <Crofton!> has joined #yocto02:18
*** joeythesaint <joeythesaint!> has quit IRC02:28
*** Crofton <Crofton!> has quit IRC02:38
*** Crofton <Crofton!> has joined #yocto02:38
*** khem <khem!> has joined #yocto02:40
*** andyross <andyross!> has joined #yocto02:45
*** khem <khem!> has quit IRC02:51
*** khem <khem!> has joined #yocto02:53
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto02:58
*** pidge <pidge!> has quit IRC02:59
*** khem <khem!> has quit IRC03:08
*** Crofton <Crofton!> has quit IRC03:17
*** Crofton <Crofton!> has joined #yocto03:18
*** nitink <nitink!nitink@nat/intel/x-iplpenaekleanjvf> has quit IRC03:28
*** khem <khem!> has joined #yocto03:31
*** Crofton <Crofton!> has quit IRC03:38
*** Crofton <Crofton!> has joined #yocto03:38
*** khem <khem!> has quit IRC03:50
*** Crofton <Crofton!> has quit IRC03:57
*** Crofton <Crofton!> has joined #yocto03:58
*** khem <khem!> has joined #yocto04:03
*** Crofton <Crofton!> has quit IRC04:07
*** Crofton <Crofton!> has joined #yocto04:07
lpapp_nerdboy: I do not think everyone should add it on their own04:07
lpapp_wmat: I do *not* wanna see warnings04:07
*** lpapp_ <lpapp_!~lpapp@kde/lpapp> has quit IRC04:10
*** khem <khem!> has quit IRC04:20
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC04:21
*** behanw <behanw!> has quit IRC04:24
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto04:35
*** Crofton <Crofton!> has quit IRC04:47
*** Crofton <Crofton!> has joined #yocto04:48
*** andyross <andyross!> has quit IRC04:54
*** Crofton <Crofton!> has quit IRC04:58
*** Crofton <Crofton!> has joined #yocto04:58
*** ericben <ericben!> has quit IRC05:04
*** ericben <ericben!> has joined #yocto05:05
*** khem <khem!> has joined #yocto05:08
*** Crofton <Crofton!> has quit IRC05:15
*** zecke <zecke!> has joined #yocto05:33
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto05:43
*** chandra_k <chandra_k!7aa6729b@gateway/web/freenode/ip.> has joined #yocto05:46
*** agust <agust!> has joined #yocto05:52
*** mthalmei_away is now known as mthalmei06:03
*** mthalmei is now known as mthalmei_away06:05
*** silviof2 is now known as silviof06:09
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto06:09
*** tor <tor!> has joined #yocto06:22
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:36
*** tsjsieb <tsjsieb!> has joined #yocto06:37
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has joined #yocto06:40
*** B4gder <B4gder!> has joined #yocto06:42
*** chandra_k <chandra_k!7aa6729b@gateway/web/freenode/ip.> has quit IRC06:44
*** eballetbo <eballetbo!> has joined #yocto06:51
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:53
*** smartin <smartin!> has quit IRC06:55
*** smartin <smartin!> has joined #yocto06:56
*** zeeblex <zeeblex!apalalax@nat/intel/x-jxujgscfuemfgfhi> has joined #yocto06:57
*** francois99 <francois99!> has joined #yocto07:01
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC07:08
*** vicky <vicky!~vicky@> has joined #yocto07:10
*** mckoan|away is now known as mckoan07:12
mckoangood morning07:12
*** volker <volker!> has joined #yocto07:14
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto07:15
*** sameo <sameo!samuel@nat/intel/x-fkzetogxugeqveej> has joined #yocto07:16
*** volker <volker!> has joined #yocto07:19
*** TuTizz <TuTizz!~TuTizz@> has quit IRC07:19
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto07:19
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto07:20
yoctiBug 4941: normal, Undecided, ---, saul.wold, NEW , udev does compile with older toolchains07:20
vickyhi yocto. i am using yocto for at91sam9x5ek soc from ''. It was build fine. but  when i tried to boot latest atmel bootstrap, i m getting "unsupported page size". but ecc settings are perfect. We already used those settings. And i degraded to my old stable version and i compiled with yocto compiler. it is not at all booting. But it is working with old compiler(build by buildroot). It is a compiler issue? any ideas?07:23
vickylatest atmel bootstarp src at
*** ka6sox-away <ka6sox-away!ka6sox@nasadmin/ka6sox> has quit IRC07:25
*** tbn <tbn!> has joined #yocto07:26
*** tbn is now known as Guest8839407:27
vickymy stable known working bootstrap (with buildroot uclibc based compiler) - ""07:27
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #yocto07:27
*** Noor <Noor!~noor@> has quit IRC07:28
*** mihai <mihai!~mihai@> has joined #yocto07:30
mckoanvicky: you could ask to forum too07:30
*** Noor <Noor!~noor@> has joined #yocto07:30
mckoanvicky: or #at91 channel07:31
*** sameo <sameo!samuel@nat/intel/x-fkzetogxugeqveej> has quit IRC07:35
*** slaine <slaine!~slaine@> has joined #yocto07:35
*** eren <eren!~eren@unaffiliated/eren> has quit IRC07:36
vickymckoan: thanks. but i doubts compiler because of my old bootstrap not boots with yocto.07:44
*** ant_work <ant_work!> has joined #yocto07:48
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto07:49
fenrigHi are there any special procedures concerning fb support, because with another board I once again have a missing /dev/fb0 (allthough the driver should be installed)07:57
mckoanfenrig: fb support is a kernel feature08:00
*** gmacario <gmacario!> has joined #yocto08:05
*** cristianiorga <cristianiorga!~cristiani@> has quit IRC08:08
*** panda84kde <panda84kde!> has joined #yocto08:12
bluelightningmorning all08:20
mckoanmorning bluelightning, all08:24
lpappbluelightning: hi, how are you08:27
*** zecke <zecke!> has quit IRC08:27
lpappbluelightning: have you seen the udev break?08:27
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:28
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:31
*** panda84kde <panda84kde!> has quit IRC08:31
*** panda84kde <panda84kde!> has joined #yocto08:32
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has joined #yocto08:32
yoctiBug 4941: normal, Undecided, ---, saul.wold, NEW , udev doesn't compile with older toolchains08:34
*** jackmitchell <jackmitchell!> has joined #yocto08:37
*** elmi82 <elmi82!> has joined #yocto08:40
bluelightninglpapp: good thanks, yourself?08:41
bluelightninglpapp: yes I saw the report08:41
*** tasslehoff <tasslehoff!~tasslehof@> has joined #yocto08:43
*** belen <belen!Adium@nat/intel/x-giqfvwvobsovwucj> has joined #yocto08:51
vickyhow to disable documentation on poky root filesystem ?08:54
bluelightningvicky: if you don't have doc-pkgs in IMAGE_FEATURES and aren't explicitly installing any *-doc packages, then you shouldn't have any documentation in the final image08:55
bluelightningvicky: the default is not to have either of those, what documentation are you seeing in your rootfs?08:56
*** slaine <slaine!~slaine@> has quit IRC08:58
lpappbluelightning: do you have any idea for a quick fix?08:58
lpappother than using a different udev in our layer.08:59
bluelightninglpapp: not really, no, unless you can find a distro patch somewhere out there that resolves it08:59
bluelightninglpapp: really I would expect the Mentor folks to have a patch for this if it's their toolchain that it happens with09:00
lpappbluelightning: I guess they would suggest to upgrade the toolchain.09:00
lpappbut it is not a two minutes change.09:00
bluelightning(and if that's the case we'd happily have in the core assuming it doesn't break newer toolchains)09:00
lpappthat will introduce a lot of new issues, too, in our software.09:00
bluelightningyou'd have to ask them09:01
lpappthey upgrade the toolchain in here, too.09:01
lpappI have pretty much the same gcc version as in the latter post.09:01
lpappperhaps, it is better to ask the udev mailing list.09:02
bluelightningyou could try there yes09:02
lpappbut I thought udev would not exist anymore as a standalone?09:02
bluelightningwe build the last standalone version when we build without systemd09:03
lpappwhen will systemd come to existence in Yocto?09:04
bluelightninglpapp: it's already available in dylan and later09:05
bluelightninglpapp: you just have to enable it as per the manual09:05
lpappwhy is udev being built then?09:05
lpappok, let me rephrase then:09:05
lpappwhen will systemd come to existence in Yocto as default?09:05
bluelightninglpapp: not for some time yet I suspect09:05
lpappwhy not?09:06
bluelightninga lot of users just want to keep things simple, sysvinit works for them and they're not comfortable with switching to systemd yet09:06
bluelightningover time that may well change, but that's the situation now09:06
bluelightningthose who do want to switch can do so easily via their distro configs09:07
lpappis that really true ?09:07
lpappI mean many people use systemd on desktop now.09:07
bluelightningsure, but desktop != embedded for many different reasons09:07
lpappin this context, there would be no differnece.09:07
bluelightningsome embedded setups barely even have an init system09:08
lpappsystemd is ok on both.09:08
lpappit would not make a difference for them then ...09:08
bluelightningI'm not the one you have to convince09:08
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC09:08
*** slaine <slaine!~slaine@> has joined #yocto09:11
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-qilwxyvkmzwgziap> has joined #yocto09:15
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-qilwxyvkmzwgziap> has quit IRC09:19
*** cristianiorga <cristianiorga!cristianio@nat/intel/x-afqhaidaspnalmvo> has joined #yocto09:22
*** diego <diego!> has joined #yocto09:23
*** panda84kde <panda84kde!> has quit IRC09:23
*** diego is now known as Guest6640209:24
*** Guest66402 is now known as panda84kde09:24
*** sameo <sameo!samuel@nat/intel/x-sulzjtgkklamqccs> has joined #yocto09:25
*** lpapp <lpapp!~lpapp@> has joined #yocto09:33
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto09:33
*** panda84kde <panda84kde!> has quit IRC09:35
*** panda84kde <panda84kde!> has joined #yocto09:36
*** zecke <zecke!> has joined #yocto09:42
*** JimBaxter <JimBaxter!> has joined #yocto09:51
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC09:59
fenrigokay I don't understand why I have no /dev/fb009:59
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto10:00
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC10:19
*** panda84kde <panda84kde!> has quit IRC10:23
*** panda84kde <panda84kde!> has joined #yocto10:33
lpappbluelightning: is it already decided which u-boot version is shipped for 10.0?10:38
lpappbluelightning: I would like to send a patch to oe-core to update to 2013.0710:38
bluelightninglpapp: don't know, sorry10:38
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto10:40
*** mihai <mihai!~mihai@> has quit IRC10:59
*** swex_ <swex_!~swex@> has joined #yocto11:03
*** swex <swex!~swex@> has quit IRC11:06
*** GunsNRose <GunsNRose!~GunsNRose@> has joined #yocto11:08
*** joseppc <joseppc!> has joined #yocto11:09
*** Crofton <Crofton!~balister@> has joined #yocto11:09
*** roric <roric!> has quit IRC11:14
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:14
*** sveinse <sveinse!~chatzilla@> has joined #yocto11:16
*** gmacario1 <gmacario1!> has joined #yocto11:24
lpappbluelightning: yeah, here is the thing again with git, I need to update the srcrev manually11:26
lpappbluelightning: with tarballs, you have no such troubles.11:26
lpappit will take me a few minutes uselessly because it would be unnecessary with tarballs.11:26
*** gmacario <gmacario!> has quit IRC11:26
*** belen2 <belen2!Adium@nat/intel/x-qsoxxfkrpewemumx> has joined #yocto11:29
*** belen <belen!Adium@nat/intel/x-giqfvwvobsovwucj> has quit IRC11:29
*** roric <roric!> has joined #yocto11:30
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto11:33
*** abelloni <abelloni!> has quit IRC11:36
*** abelloni <abelloni!> has joined #yocto11:36
lpappbluelightning: is there a way to automatically update the SRCREV?11:48
lpappit does not make much sense to demand manual stuff when you already specify the tag anyway11:51
* lpapp is opening a bugreport for it.11:51
lpappseems "${AUTOREV}" already achieves that.11:52
lpappbut then what is the point of SCM, really11:53
lpappwhen _pn is not specified for a variable it can still work, right? Meaning, it has only one package per recipe, right?11:53
*** roric <roric!> has quit IRC11:55
lpappwhich changes need to go to the yocto mailing list?11:55
lpappthe border is quite confusing.11:55
Croftonmeta-yocto layer changes11:56
Croftonoe-core changes go to oe-core11:56
lpappand what to poky?11:57
lpappbecause actually I had to send meta-yocto changes to poky,.11:57
lpappit is full of confusion. :)11:57
Croftonpoky is met-yocyo11:57
lpappnever seen met-yocyo11:58
Croftonmeta-yocto should be called meta-poky11:58
lpappno no11:58
Croftonsorry bad typing11:58
lpappyou mentioned those should go to yocto11:58
lpapppoky != yocto11:58
lpappthey have separate mailing lists.11:58
bluelightninglpapp: check the README in poky's top level directory11:58
lpappbluelightning: I did.11:58
lpappbluelightning: which means I should submit a bugreport to ask for clarification11:59
lpappI have been told last time to send stuff to yocto11:59
lpappI do not know why, but I have been.11:59
bluelightningnot sure who directed you to do that11:59
lpappso he was wrong?11:59
bluelightningwhat is written in the README reflects current practice11:59
lpappbluelightning: I am now sending a u-boot update12:00
lpappwith the use of AUTOREV12:00
lpappbut I will probably remove the git stuff entirely for it.12:00
bluelightninglpapp: we won't accept recipes containing SRCREV = "${AUTOREV}" I'm afraid12:00
bluelightninglpapp: before you ask why, because they'll likely be broken shortly after they've been merged12:01
lpappnot sure why that makes sense, but if it is some strict rule set in stone, the only way to clean up the mess is get rid of git altogether12:02
bluelightningwe want recipes to remain buildable, even in the case of bleeding edge ones, so the SRCREV should be fixed when it comes to published layers12:02
lpappthere is only one indifferent version tag.12:03
bluelightningplus, if SRCREV is not set to a fixed revision, bitbake will have to query the server on every parse which is not desirable12:03
*** mihai <mihai!~mihai@> has joined #yocto12:03
lpappso it should be pretty straightforward what the relevant hash is.12:03
bluelightningif you want SRCREV = "${AUTOREV}" you can easily have that by having a bbappend in your own layer12:03
lpappyeah, it takes 0.0005 s12:03
lpappcompared to the easier maintenance it brings.12:03
bluelightningyou mean, harder maintenance12:04
lpappI am not talking about my layer12:04
lpappI am talking about oe-core proper.12:04
lpappno, it is a lot easier.12:04
bluelightningno, and I'm not either12:04
lpappwhy to have double factor?12:04
lpappbut yes, I agree that the whole git stuff is a bloated mess, and have to go to the trash.12:04
bluelightningdon't put words in my mouth12:05
lpappI did not ?12:06
bluelightningyour last comment agrees with something that I never said, that's the very definition of putting words in my mouth12:06
lpappcould you please clarify where I said I agree with *you*12:06
lpappor is it just a mistinterpretation12:07
*** joseppc <joseppc!> has quit IRC12:07
*** roric <roric!> has joined #yocto12:08
*** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.> has joined #yocto12:08
*** mulhern <mulhern!> has joined #yocto12:09
lpappis it always the latest version that is built out of the recipes for the same software?12:10
lpappI mean by default.12:10
g0hl1ngood morning everybody.12:10
lpappseveral softwares have more than one recipes12:10
lpappnot occasional to have 3-4.12:10
g0hl1nI've a question regarding a own linux kernel recipe...12:11
*** gmacario <gmacario!> has joined #yocto12:11
lpappg0hl1n: which is12:11
g0hl1nI've created a own recipe for the kernel because I have different sources. But now i think the Kernel doesn't take my configuration specified as defconfig. Is this possible?12:11
g0hl1nTo be precise FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}/files:${THISDIR}/${PN}/patches:"12:12
g0hl1nSRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel file://defconfig"12:12
g0hl1nI think the Configuration isn't taken because when I zcat /proc/config.gz on the running machine I can't find some settings I've set in defconfig12:13
g0hl1nany ideas?12:13
*** gmacario1 <gmacario1!> has quit IRC12:14
lpappg0hl1n: have you checked with make menuconfig12:15
lpappwhether your .config is right12:15
g0hl1nlpapp: which .config? the one in the Kernel tree?12:15
g0hl1nlpapp: shouldn't the build ignore the .config in the kernel source but use defconfig from SRC_URI ?12:16
lpappg0hl1n: the kernel needs .config12:20
lpappif the kernel tree does not have a .config, it will not build.12:20
g0hl1nlpapp: and whats the defconfig for?12:21
lpappI cannot build u-boot separately for testing? o_O
lpappg0hl1n: to generate the .config out of.12:21
lpappg0hl1n: if it does not work for boot12:22
lpappyou need to check before the kernel build12:22
lpappfor which vim or preferably make menuconfig is better.12:22
g0hl1nok, so I've no .config is present it will copy over defconfig...12:23
lpappyes, which means always12:23
g0hl1nBut that's the point.12:23
lpappif you start from scratch.12:23
g0hl1nI've no .config in the kernel source tree but a defconfig in SRC_URI.12:23
lpapphave you checked?12:23
lpappin build/tmp/work etc12:24
g0hl1nand when I boot into the kernel and zcat the /proc/config.gz it isn't the same as defconfig12:24
lpapphave you checked?12:24
lpappin build/tmp/work etc12:24
ant_workg0hl1n: whithout seeing the kernel recipe I can't help more. If it is old-style kernel you need to inherit kernel, for linux-yocto there is inherit kernel-yocto as well12:26
lpappso u-boot is not buildable on its own with bitbake? :(12:27
ant_workg0hl1n: and see meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb12:27
zeckelpapp: well, there is no "generic u-boot for this cpu architecture"12:28
zeckelpapp: even.. for a specific SoC there is no.. this will always work config12:29
lpappzecke: ?12:29
ant_workUBOOT_MACHINE is not set ?12:29
lpappit is?12:29
lpappUBOOT_MACHINE="omap3_beagle_config" bitbake u-boot12:29
g0hl1nant_work: here's the recipe:
lpappthat is what I used.12:29
zeckelpapp: "ERROR: u-boot was skipped: because UBOOT_MACHINE is not set" most of the time computers don't lie.12:30
lpappzecke: so?12:31
lpappsuggestions, pls.12:31
lpappnot error message reporting. :)12:31
lpappI can also read.12:31
ant_workg0hl1n: I suppose youhave to fix FILESEXTRAPATHS_prepend12:31
bluelightninglpapp: you can't pass in variable values from the environment like that unless the variable is one of the set listed in BB_ENV_EXTRAWHITE12:32
zeckelpapp: and blog ;)12:32
lpappbluelightning: sounds like a feature request (another report)12:32
g0hl1nant_work: what's wrong with it?12:32
bluelightninglpapp: nope, we're not adding that variable12:32
lpappnow, that does not make sense.12:33
*** challinan <challinan!> has joined #yocto12:33
lpappzecke: actually no.12:33
lpappother people blog a lot more at social sites12:33
lpappI have only 5-10 blogs a year usually.12:33
ant_workg0hl1n: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.1:${THISDIR}/${PN}:${THISDIR}/files:" if you want a specific dir for this kernel12:34
lpappit would be plain silly to say, "no, you cannot try to build u-boot on i ts own"12:34
lpappwhich is exactly the use case when you are trying to get it work.12:34
ant_worklpapp: your machine.conf file should set this var12:35
lpappant_work: I am not sure you realize that I would like to invoke it from command line.12:36
lpappand surely, meta/ already does set that.12:36
ant_workso whitelist the var but still you have a defective conf12:36
* lpapp not sure to whom that message goes ...12:36
ant_workUBOOT_MACHINE is deeply tied with MACHINE, doh12:37
lpappwhich is exactly why I tried to specify the variable?12:37
ant_workyou ought just to specify MACHINE12:37
ant_workresistance is futile12:37
lpappthere is no any resistenace?12:38
*** rburton <rburton!> has joined #yocto12:38
ant_work(with me)12:38
lpappsaying resistance when there is none is futile?12:38
lpappsame with machine12:38
lpappMACHINE="qemuarm" bitbake u-boot12:38
lpappit is just broken in here ...12:38
rburtondoes qemuarm set UBOOT_MACHINE? no.12:39
rburtonuse a machine that has the relevant uboot configuration12:39
rburtonas uboot is by defintion machine-specific12:39
*** Crofton <Crofton!~balister@> has quit IRC12:39
lpappalready tried beagleboard12:39
lpappbesides, it should report missing MACHINE12:39
rburtonits not missing12:39
lpappyes, it does.12:39
rburtonthe log you pasted clearly stated MACHINE=qemuarm12:40
rburtonnow a failure with MACHINE=beagleboard would be more interesting12:40
lpappI think you should be investigating a bit more rather than chim in without the prior history.12:40
lpappthe log is public after all.12:40
rburtonlpapp: how do you think i knew what was in the bitbake log you posted?12:40
lpapprburton: I believe you just did not read back, and you still do not have the proper context.12:41
rburtonlpapp: if you have a log of a failure with the beagleboard then that would be more interesting, but the log you pasted was with the qemuarm machine, which doesn't support uboot.12:41
lpappagain, *please* get the context12:41
*** behanw <behanw!> has joined #yocto12:41
lpappyou chim into the middle of the conversation12:41
lpappand you refer to something that no one refers to.12:41
lpappbecause you lack the context12:42
lpappplease go read it. :)12:42
*** rburton <rburton!> has left #yocto12:42
* lpapp is filing a bugreport in the meantime.12:42
*** blitz00 <blitz00!stefans@nat/intel/x-qvrzzhcegfhtauoc> has joined #yocto12:43
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto12:43
yoctiBug 4945: normal, Undecided, ---, saul.wold, NEW , No reference to missing MACHINE when running u-boot through bitbake12:46
ant_worklpapp: note the defaults for the other vars
lpappant_work: I know.12:51
ant_workso typically you set all 3 like in this BSP i.e.
lpappant_work: however it is pretty pointless.12:51
lpappas it will be supplied to openocd anyway12:51
lpappI have never understood those two variables...12:51
ant_worktbh I'm not following, there was th eidea of auto-calculating those addresses iirc12:51
lpappand that why I would use it.12:51
lpappyou cannot auto calculate those.12:52
lpappyou need to supply it to openocd12:52
lpappor whatever flasher you use anyway12:52
lpappfrankly, I am not sure why yocto has variables for those. :)12:52
lpappsee my other bugreport where I asked for documentation.12:53
ant_workkernel.bbclass  #34812:53
lpapplooks like a broken function12:55
* lpapp will try to patch out when getting some time ...12:55
lpappmake uImage should be used simply.12:56
lpappbut even then, there is no any need for the entry point like that12:56
lpappnor the address.12:57
lpapp0: icu-native-51.2-r0 do_fetch (pid 10940) -> got stuck here for an hour12:57
lpapphow can I make sure it is doing *anything*12:57
lpappprobably there is a logfile somewhere.12:58
*** walters <walters!> has quit IRC12:58
lpappWARNING: Host distribution "arch-rolling" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution.13:00
lpappERROR: Only one copy of bitbake should be run against a build directory13:00
lpappwhy am I getting this for a dry-run try?13:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-pvcgnbthbpxncahn> has joined #yocto13:00
lpappI do not wanna build u-boot... I would just like to get the checksums to update the recipes...13:00
lpappis that possible somehow?13:00
ant_workyes, md5sum and sha256sum the file in /downloads13:00
*** vicky <vicky!~vicky@> has quit IRC13:01
lpappno no13:03
lpappI do not wanna do them separately.13:03
lpappI have been told bitbake can five both off-hand.13:03
*** Net147 <Net147!> has joined #yocto13:04
ant_workunfortunately your other bitbake is stuck on do_fetch13:05
ant_workonly one copy...blah13:05
*** tasslehoff <tasslehoff!~tasslehof@> has left #yocto13:06
lpappnot sure what you are talking about13:06
lpapp1) That was already cancelled.13:06
lpapp2) Dry-run should not interfere with a full fledged run.13:06
ant_worklpapp: maybe I'm getting old and have a déjà vu..I'm pretty sure youwere already updating the checksums of some recipe..those are even suggested13:09
ant_workyou have them both on-screen and in the logs13:09
lpappant_work: no no, I have never updated the checksum of any recipe.13:11
lpappthis is the first time, I would need to do it.13:11
lpapponly thing, I have been told, bitbake can provide both checksums.13:11
lpappbut I do not really find an option for doing so.13:11
ant_workit does indeed13:11
lpapphow then?13:11
lpappwhy do I need to repeat myself ? :D13:11
ant_workjust update the SRC_URI, the new d/l will have different checksums13:11
ant_workand build will blatantly fail13:12
lpappthat is silly.13:12
lpappsounds like another feature request.13:12
lpappwhy do I even need to fail or even try not to fail?13:12
lpappthe whole point is that I am explicitely sure they are outdated.13:12
ant_worklpapp: you remember kernel sources have been hacked last year, do you?13:12
lpappso gimme those.13:12
lpappthat is the user request.13:12
lpappI do not wanna start building when I *explicitly* know it will not work.13:13
ant_workhe he13:13
lpappant_work: I had been working on kernel security for 1-2 years.13:13
lpappbut I do not think it is relevant in here.13:13
ant_workdon't be silly..then use md5sum and sha256sum before13:13
ant_workbitbake does a great service to the lazy developer13:13
lpappwho is silly is relative13:14
lpappbut no, I do not wanna run two tools, when one could do the jobs.13:14
lpappthat is what I call silly.13:14
lpappif one can do, why bother with two.13:14
ant_workhm.. another déjà vu... ah, itwas me telling you that an *human* must verify th eintegrity of the sources13:15
*** yzhao2 <yzhao2!~yzhao2@> has quit IRC13:15
lpappyou can fully verify.13:16
lpappanyway, so someone was a "liar" :)13:17
lpappwho told me bitbake can do it.13:17
lpappin fact, the solution recommended then, is to use low-level tools.13:17
lpappand do the job as many times as bitbake requires.13:17
lpappif you cannot trust bitbake, you would be screwed up anyway already13:18
lpappso it is *very* unlikely this checksum issue would be the only way of screwing up.13:18
lpappsince bitbake has to be a trusted source already anyway.13:18
ant_workpls just try once13:18
lpappso your security concern is moot, respectively.13:18
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto13:18
lpappit is not the matter of try once13:19
lpappit is the matter of inconvenience for:13:19
lpappmd5sums downloads/foo/crap13:19
lpappsha... downloads/foo/crap13:19
ant_worklpapp: there have been repositories changing the tarballs and keeping the same name13:19
lpappinstead of:13:19
lpappbitbake crap -> done13:19
lpappnot to mention, I do not have u-boot inside downloads/ at all.13:20
*** JYDawg <JYDawg!> has quit IRC13:20
lpappalso, why would I need 393 tasks for getting u-boot? o_O13:21
lpappsurely, u-boot does not have that many dependencies?13:22
lpapplike python-native for u-boot, really?13:26
* lpapp feels like another bugreport ...13:26
lpappthere should be a u-boot-minimal13:27
*** Guest25188 <Guest25188!> has left #yocto13:27
lpappwithout the python tools.13:27
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC13:28
*** TuTizz <TuTizz!~TuTizz@> has joined #yocto13:34
*** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto13:34
*** Net147 <Net147!> has quit IRC13:34
lpappbtw, why does u-boot have patches if they are not applied?13:36
lpappwhat is the point of that, then?13:36
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC13:39
*** blitz00 <blitz00!stefans@nat/intel/x-iwwjdwhncyndgurl> has joined #yocto13:39
lpappERROR: QA Issue: external-sourcery-toolchain: Files/directories were installed but not shipped /usr/libexec /lib/
lpapp -> here is the full error.13:42
*** mihai <mihai!~mihai@> has quit IRC13:44
lpappis there any reason why I cannot find u-boot-2013.07.tar.bz2 in the build folder?13:46
lpappit should download it, no?13:46
*** mihai <mihai!~mihai@> has joined #yocto13:47
ant_worklpapp: if you have set it in SRC_URI. oe-core's u-boot is fetching .git13:48
lpappant_work: so?13:50
ant_workso there is no tarball13:50
lpappthat is very bad13:50
*** Crofton <Crofton!~balister@> has joined #yocto13:50
lpappoh, actually there *is* tarball13:51
lpappit is here: ./downloads/
lpapphmm, that is just the git meta info apparently, strange.13:52
lpappmy patch is not downloaded apparently either from the local golder.13:52
lpappwell, it makes super hard to reproduce an issue13:52
lpapphow can I actually get the content?13:53
lpappit is failing to apply a change.13:53
lpappand I would like to get a clean content of the decompressed tarball.13:53
lpappor cloned git stuff13:53
ant_worksorry, have to go. bbl13:54
lpappwhat is the workflow for debugging a failed application of a change?13:55
lpapppresent in files?13:55
*** ant_work <ant_work!> has quit IRC13:56
ndecbitbake -c unpack <target> will unpack the sources. while  "-c patch" will apply any potential patches13:56
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-pvcgnbthbpxncahn> has quit IRC13:56
lpappthere is nothing to unpack as noted above.13:56
ndecwhen using .git or any other SCM, bitbake will fetch the entire 'tree', then checkout the right version, and create a tarball of that version.13:58
ndecso next build, if the tarball is there, it's used.13:58
lpappit is just the bare repository inside the tarball as noted above.13:58
lpappwhich does not help in my case.13:59
lpappseems it is in here13:59
* lpapp hates git when it is just about a release13:59
ndecthere is a tarball of the bare repo in git folder, iirc. but there should be a tarball of the right version too in downloads13:59
lpappthe whole situation would be sooo much easier with a tarball.13:59
lpapppatch does not seem to need checksum?14:00
lpappbecause it is local?14:00
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fhfxpctqlrwyaedi> has joined #yocto14:02
*** Crofton <Crofton!~balister@> has quit IRC14:02
lpapp    Prepare v2011.0314:02
lpappah, it is downloading that u-boot...14:03
lpappso is it guaranteed somehow that always the latest is picked up?14:03
*** mulhern <mulhern!> has left #yocto14:04
lpappwhy in the hell does it pick up 2011.03?14:04
lpappwhen it is 2013.07 inside the recipe?14:04
lpappPV = "v2013.07+git${SRCPV}"14:05
lpappPR = "r1"14:05
*** jchonig <jchonig!~jch@> has joined #yocto14:06
ndecwhat does bitbake -s| grep u-boot tell you? it should tell you which uboot recipe/version is being used.14:08
ndecare you on master or dylan?14:08
lpappas master and dylan suck huge balls14:08
lpappdenzil is the last sane release with an older toolchain.14:09
lpapplong live to denzil14:09
ndeci don't see your PV line, in denzil.14:09
ndeci see PV = "v2011.06+git${SRCPV}"14:10
zeckelpapp: "suck huge balls". that is not very approriate language..14:10
lpappndec: well, obviously, we have to ship it in our own layer14:10
lpappthat is what the bsp layer is for.14:11
ndecso, that means you have 'something' in your layer, that prevent your uboot from being used.14:11
ndecagain, bitbake -s should help.14:11
ndecit must be a 'preference' issue or something like that.14:11
lpappit is really strange14:12
lpappbitbake u-boot does not rebuild stuff14:12
lpappalthough I deleted stuff from downloads and tmp/work, too.14:12
lpappzecke: imagine your language there for "totally blocking our business"14:12
* zecke updates the ignore list14:12
lpappndec: we have higher priority in there.14:13
lpapppriority 6.14:13
ndecbitbake -s will tell you the truth.. i can't tell you about something i can't see.14:14
ndeci am tempted to say that you have DEFAULT_PREFERENCE = "-1" in your recipe...14:15
lpappalso, I already pasted this before:v2013.07+git14+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r114:15
lpappbut 2011 content inside.14:15
lpappI have no clue.14:17
lpappalso, bitbake u-boot does not build u-boot anymore.14:17
lpappI have no idea why.14:17
lpappI deleted the downloads and tmp/work contents14:17
lpappI thought it should do a brand new stuff.14:17
* lpapp is about to dump the whole build folder content14:18
lpappthat seems to be the only reliable option most of the time.14:18
lpappthis package and job cashing usually goes crazy14:19
lpappand results hard to debug issues like this.14:19
lpappndec: as I already wrote before, but here you go anyway:
*** arky <arky!~arky@> has joined #yocto14:23
*** munch <munch!> has joined #yocto14:25
lpapphow can I force bitbake to redownload and rebuild u-boot from scratch?14:25
* lpapp will dump the build folder for real as it is better to waste 40 minutes than few hours of debugging14:26
RPlpapp: bitbake u-boot -c cleanall14:27
lpappI already dumped14:27
*** zenlinux <zenlinux!> has joined #yocto14:28
RPlpapp: I should have bothered mentioning it for next time then...14:28
lpappyeah, but not sure I can memorize it, really. :-)14:29
RPIt is also mentioned in the manuals...14:29
lpappyeah, after reading for hours, sure.14:29
* RP shrugs14:30
lpappI already spent my whole weekend with reading yocto manuals.14:30
lpappand apparently I still do not know.14:30
RPdamned if you write documentation, damned if you don't14:30
lpappnot damned if you write good documentation14:30
lpappor yu have good options, like --clean14:31
lpappwhich I raised several times by now.14:31
lpappcheck the output of "bitbake --help" with a user hat on.14:31
lpappor run the following command: bitbake --help | grep clean14:31
lpappyou might be surprised.14:31
RPlpapp: perhaps remember -c listtasks if you can only remember one option14:31
lpappbut that is what an average user will do14:32
lpappread the help output, and then look for clean14:32
RPlpapp: I wouldn't be surprised at all ;-)14:32
lpappnone of them goes nowhere.14:32
lpappyou would not be surprised that a tool does not have clean?14:32
RPlpapp: I know clean wouldn't be listed there, I also know why14:32
lpappwhen you need a clean operation?14:32
lpappyou are genius then.14:33
lpappbut I am not.14:33
lpappnor are many users.14:33
fenrigHow do I fix this? "NOTE: Your conf/bblayers.conf has been automatically updated. Please re-run bitbake."14:39
lpappfenrig: have you tried to rerun14:39
fenrigjust issuing bitbake in the shell triggers the same error14:39
lpappfenrig: have you tried to delete the file14:39
fenrigno conf/bblayers.conf is not deleted :)à14:39
lpappcan you try after backing up14:40
fenrigUnable to find conf/bblayers.conf14:41
fenrigso :/14:41
lpappyou do not have $builddir/conf/bblayers.conf?14:42
lpappthat should be autogenerated14:42
lpappeven that fails for you?14:42
lpappthen I have no clue ...14:42
lpappRP: why is removing the downloads and tmp/work related entries not enough?14:42
RPlpapp: I lack context but likely you also have something in the sstate cache?14:44
fenrigHuh :/14:44
lpappRP: ok, so it is not recommended to delete stuff manually?14:45
RPlpapp: no, its not14:45
lpappand it is definitely not just about tmp as a few people claimed in here before.14:45
RPlpapp: roughly speaking you have downloads, sstate and tmp14:45
*** igrigorx <igrigorx!c0c69725@gateway/web/freenode/ip.> has joined #yocto14:46
RPlpapp: sstate remains valid between builds with some assumptions. Most people work fine with those assumptions, I suspect you are stepping outside of them14:46
RPlpapp: for more details read about how the sstate checksums are generates which is in the manual14:46
lpappRP: no, -c cleanall will be fine for me...14:47
lpappRP: why are 507 tasks needed for u-boot?14:49
lpappRP: it should be a pretty headless software!14:49
bluelightninglpapp: bitbake -g u-boot if you want to examine the dependencies14:50
lpappis it just me or the documentation does not really clarify why it is recommended to set the parallel stuff to double value of the cpus?14:53
lpappusually it is just cpu+114:54
*** nitink <nitink!~nitink@> has joined #yocto14:55
RPlpapp: there are scripts in the tree which experiment to find the optimal value for your hardware. That is the best value we've found on average14:58
* RP -> afk14:58
lpappthen make is not optimal?14:59
*** Squix <Squix!> has quit IRC15:00
*** Squix <Squix!> has joined #yocto15:01
*** hollisb <hollisb!> has joined #yocto15:01
*** Squix <Squix!> has quit IRC15:03
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has quit IRC15:03
*** Squix <Squix!> has joined #yocto15:04
*** seebs <seebs!> has quit IRC15:04
lpappNOTE: package u-boot-v2013.07+git9+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r1: task do_fetch: Started15:06
lpappwhy did it get stuck here 10 minutes ago???15:06
lpappwithout any error message whatsoever.15:07
bluelightningmaybe because it has neither failed nor succeeded?15:08
lpappyeah, sure git gets stuck so often without any diagnostics..15:08
*** davest <davest!Adium@nat/intel/session> has joined #yocto15:08
bluelightningit can, yes15:08
lpappyeah, I just never saw the last 6 years.15:09
*** seebs <seebs!> has joined #yocto15:10
lpappand even then, there should be a timeout on the bitbake layer.15:12
lpappNOTE: package perl-5.14.2-r6: task do_compile: Started15:12
*** davest <davest!Adium@nat/intel/session> has quit IRC15:12
*** davest <davest!Adium@nat/intel/x-qtgwgvziozdoiddj> has joined #yocto15:12
lpappjesus, it is rebuilding all the core packages. :(15:13
lpappnot sure why perl is needed for u-boot ?!15:13
TuTizzhey, I have got this error : "/home/adrien/LinuxArm/oe-core/meta-ti/recipes-graphics/mesa/mesa_9.1.3.bbappend", rename mesa_9.1.3.bbappend in mesa_9.1.5.bbappend will be enought or should I do something more?15:13
TuTizzsorry this is the complete error : ERROR: No recipes available for:15:14
TuTizz  /home/adrien/LinuxArm/oe-core/meta-ti/recipes-graphics/mesa/mesa_9.1.3.bbappend15:14
TuTizzERROR: Command execution failed: Exited with 115:14
*** Jefro <Jefro!> has joined #yocto15:14
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-fhfxpctqlrwyaedi> has quit IRC15:14
*** mulhern <mulhern!> has joined #yocto15:16
lpappffs... I am rebuilding u-boot for half an hour15:17
lpappand it is still that much left15:17
lpappto try a patch application ?15:17
lpappwhat am I doing wrong that it takes this much time with full of babysitting?15:17
lpappwhat is the ideal workflow for such development ?15:17
bluelightningTuTizz: I assume so... denix ?15:18
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ykcdfyxgwbyyxynf> has joined #yocto15:19
lpappprobably I could have rebuilt u-boot 20 times manually no.15:19
lpappwhy is it so painful with Yocto?15:19
lpappI must be doing something very wrong.15:19
bluelightningdidn't you just delete your TMPDIR?15:19
lpappI did.15:20
lpappbut I rebuild u-boot from scratch in a couple of minutes.15:22
lpapphere I have 509 tasks... what for?15:22
lpappand one hour building of * just * ** the ** *** bootloader ***?15:23
lpappand I have a very efficient desktop PC.15:23
TuTizzbluelightning, What denix mean? Is that a branch of yocto? I just git clone git:// oe-core to get a fresh version15:24
bluelightningTuTizz: sorry if it wasn't clear, I'm just trying to catch denix's attention since he's the maintainer of meta-ti15:24
TuTizz:D ok np15:25
bluelightninglpapp: I mentioned above, if you want to find out why those dependencies exist, the output of bitbake -g will tell you15:25
lpappbluelightning: to be honest, I do not care.15:25
bluelightningyou asked...15:25
lpappI just wanna get a sane few minutes build maximum.15:25
lpappthat was more like a statement, as in: it is kinda insane.15:26
*** mckoan is now known as mckoan|away15:26
denixbluelightning: did master update mesa again? :) sorry, missed it, will fix soon15:26
bluelightningdenix: I'm afraid so...15:27
*** andyross <andyross!> has joined #yocto15:27
TuTizzdenix, July 1715:27
denixyeah, I was on vacation then :)15:29
ndecdenix: is that supposed to be a valid excuse ;-)15:29
denixndec: you got me! :)15:29
lpappis it one hour for others as well to build only the boot loader which is even way before the kernel?15:30
lpappwhy is there do_patch in the log?15:31
lpappit means, it did not actually apply the patch of mine?15:31
*** levi <levi!> has quit IRC15:33
*** mulhern <mulhern!> has quit IRC15:33
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-ykcdfyxgwbyyxynf> has quit IRC15:33
*** mulhern <mulhern!> has joined #yocto15:34
lpappwhy does the do_patch not log at all what patches it applied ?!15:34
*** elmi82 <elmi82!> has quit IRC15:34
*** levi <levi!> has joined #yocto15:35
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-anvbipmihduwsosj> has joined #yocto15:35
lpappthis should contain a patches folder, no? ./tmp/work/foo-linux-gnueabi/u-boot-v2013.07+git9+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r115:39
*** eren <eren!~eren@unaffiliated/eren> has quit IRC15:47
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC15:53
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto15:55
*** walters <walters!> has joined #yocto15:57
*** slaine <slaine!~slaine@> has quit IRC15:58
seebs<eyes darting around wildly> who said it was morning?16:00
seebs*runs away*16:00
*** GunsNRose <GunsNRose!~GunsNRose@> has quit IRC16:00
lpapphow do others verify if a patch had been applied?16:01
*** pidge <pidge!> has joined #yocto16:01
*** sgw1 is now known as sgw_16:02
mranostaylpapp: logfiles?16:03
*** eballetbo <eballetbo!> has quit IRC16:04
lpappmranostay: ?16:04
*** galak <galak!> has joined #yocto16:10
*** Guest88394 <Guest88394!> has quit IRC16:12
*** zerus <zerus!> has quit IRC16:14
lpappmranostay: where should the log file be?16:28
lpappbecause what I have, does not contain that information.16:28
lpappI only have pseudo.log containing the word u-boot.16:29
*** hollisb <hollisb!> has quit IRC16:29
fraypatches are generally applied using quilt, so you can check the quilt series file..16:31
lpappsurely, it is applied by quilt, but I kinda need more concrete suggestions. :)16:32
lpappit is not like I am a hard code Yocto developer.16:32
*** hollisb <hollisb!> has joined #yocto16:32
-YoctoAutoBuilder- build #241 of nightly-mips-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
lpappI do not understand thse from half words.16:32
ndeclog.do_patch in the WORKDIR gives you all the info.16:33
lpappif there is no error in that file, it means it applied the change nicely?16:35
ndecif there is any error, bitbake would abort and tell you. whatever the task it is that you are running.16:36
lpappor it would not apply a change for some reason16:36
lpappbut I guess it is now there16:36
ndecthe log file even tells you where the file was taken from16:36
*** arky <arky!~arky@> has quit IRC16:38
-YoctoAutoBuilder- build #68 of minnow-lsb is complete: Failure [failed Building Images] Build details are at
lpappndec: k, thanks.16:42
*** mihai <mihai!~mihai@> has quit IRC16:49
*** zeeblex <zeeblex!apalalax@nat/intel/x-jxujgscfuemfgfhi> has left #yocto16:49
lpappndec: is there any reason why u-boot.bin did not get into the deploy folder?16:50
-YoctoAutoBuilder- build #229 of nightly-ppc-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
lpappit can be found only in "work".16:50
ndecis u-boot.img there?16:50
lpapphow can I get it into the deployment folder?16:52
lpappI only used bitbake u-boot though, not bitbake core-image-minimal.16:52
ndecif the recipe doesn't do it, there must be a reason.16:53
ndeci don't have a local build with u-boot, so i can't check.16:53
*** blitz00 <blitz00!stefans@nat/intel/x-iwwjdwhncyndgurl> has quit IRC16:53
lpappis it supposed to?16:54
*** rtollert_ is now known as rtollert16:57
ndeclpapp: you need to check what is in <WORKDIR>/packages that's what's used to generate the package.16:59
-YoctoAutoBuilder- build #232 of nightly-arm-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
lpappyou mean package?17:00
*** zerus <zerus!> has joined #yocto17:01
lpappor packages-split17:01
ndecyes. or packages-split.17:01
lpappthose are just packages.17:02
lpappnot sure where it is defined to be put into deploy, then.17:02
lpappshould "bitbake u-boot" put it into the deploy folder, at all?17:04
lpappndec: ^17:04
*** michael_e_brown <michael_e_brown!~michaeleb@> has joined #yocto17:07
lpappso if I have eight cores, I should put -j16 into the config?17:08
lpappsorry, 4 cores, 8 threads.17:08
lpappdoes such a change need a full rebuild or it will take effect at the next recipe parsing, or so?17:09
lpappor next bitbake run?17:09
*** zerus <zerus!> has quit IRC17:10
lpappalso, why do I have two .bins in the package folder?17:12
lpappu-boot-v2013.07+git9+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r1.bin and u-boot.bin?17:12
lpapphmm, it does seem a lot faster after switching to -j8.17:12
*** pidge <pidge!> has quit IRC17:16
-YoctoAutoBuilder- build #232 of nightly-x86-lsb is complete: Failure [failed Building Images Building Images_1] Build details are at
sgw_lpapp:  a machine with 4 cores 8 threads could have BB_NUMBER_THREADS="8"  and PARALLEL_MAKE = "-j 8", not sure if you set BB_NUMBER_THREADS also17:21
lpappyeah, I used 8 for both, thanks.17:22
*** W1N9Zr0 <W1N9Zr0!> has quit IRC17:22
* lpapp is still not sure about the mkimage usage in Yocto instead of "make uImage"17:22
lpappcan I get the mkimage u-boot binary available at kernel build time?17:23
lpappor it is only available after everything built and installed?17:23
*** W1N9Zr0 <W1N9Zr0!> has joined #yocto17:23
lpappit would be nicer than a host tool which needs an installation from each developer.17:25
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto17:26
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:26
-YoctoAutoBuilder- build #229 of nightly-non-gpl3 is complete: Success [build successful] Build details are at
*** bluelightning_ is now known as bluelightning17:26
lpappas you may already know, u-boot requires uImages.17:26
-YoctoAutoBuilder- build #200 of nightly-fsl-arm-lsb is complete: Failure [failed Building Images Building Images_1 Building Images_2] Build details are at
*** zenlinux <zenlinux!> has quit IRC17:30
* lpapp is still not sure why the UBOOT_ADDRESS/ENTRYPOINT exists.17:31
lpappwhy does the kernel need to know those ? That is for the flasher, no?17:31
*** belen2 <belen2!Adium@nat/intel/x-qsoxxfkrpewemumx> has quit IRC17:31
*** sameo <sameo!samuel@nat/intel/x-sulzjtgkklamqccs> has quit IRC17:33
otaviolpapp: this is for uImage17:33
lpappotavio: ?17:34
otaviolpapp: in case you use zImage it is not need17:34
lpappI think we just hard coded it.17:34
lpappthat will work for us.17:34
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:34
lpappnot too flexible though.17:34
lpappCONFIG_SYS_TEXT_BASE is the proper config for the entry point17:35
lpapphave not found the other one yet17:35
otaviolpapp: in U-Boot?17:35
otaviobut kernel needs to know it17:35
otavio(for uimage format)17:35
lpapp../meta/classes/kernel.bbclass:72:UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"17:35
lpappright, so they are eventually the same for the average case.17:35
lpappso, how can I get the u-boot.bin into the deployed folder?17:37
*** mulhern <mulhern!> has quit IRC17:38
*** panda84kde <panda84kde!> has quit IRC17:41
otaviolpapp: bitbake u-boot17:43
lpappotavio: ok, so how can I debug why that does not work?17:44
otaviolpapp: what does not work?17:44
*** galak <galak!> has quit IRC17:44
otaviolpapp: I use it daily here and it does.17:44
lpappmeta-mylayer/conf/machine/mymachine.conf should define KERNEL_IMAGETYPE="uImage"?17:45
*** ftonello_ <ftonello_!> has joined #yocto17:45
*** ftonello_ is now known as ftonello17:45
lpappotavio: ok, but that does not make it work for me automatically, right? :)17:45
lpappotavio: it is not getting moved/copied from the workdir.17:46
lpapppopulated if you like.17:46
otaviolpapp: I didn't get what you mean17:46
lpappotavio: it is not in the deploy folder.17:48
otaviolpapp: it will be if:17:48
otavioyou build it17:48
otavioyou build an image which depends on it17:48
lpappmeta-mylayer/conf/machine/mymachine.conf -> if I change anything in here, and execute bitbake core-image-minimal, will everything be properly rebuilt, respectively?17:49
lpappotavio: yeah, but it is clearly not working for me.17:50
lpappI need to debug it somehow.17:50
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto17:51
lpappotavio: so how can I debug the fact it is not there?17:52
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto17:52
*** mulhern <mulhern!> has joined #yocto17:53
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:55
lpappit should be the do_install task, right?17:56
lpappNOTE: package u-boot-v2013.07+git16+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r1: task do_install: Succeeded17:57
*** pidge <pidge!pidge@nat/intel/x-rsukdcsiabjnsrqb> has joined #yocto18:00
lpapphmm, it makes it is not in ./tmp/deploy/rpm/armv5te/18:01
*** Jefro1 <Jefro1!> has joined #yocto18:01
lpappas it is not a package like that.18:01
lpappotavio: where is u-boot.bin installed on your system?18:01
lpappoh, it is actually there now.18:01
lpappjust with a different name than I looked!18:02
lpappwhy symbolic links in the images btw?18:02
*** yzhao2 <yzhao2!~yzhao2@> has joined #yocto18:04
*** Jefro <Jefro!> has quit IRC18:04
sgw_lpapp: are you referring to tmp/deploy/images?18:05
-YoctoAutoBuilder- build #198 of nightly-fsl-ppc-lsb is complete: Failure [failed Building Images] Build details are at
lpappsgw_: yeah18:09
sgw_lpapp: if you are referring to the symlinks in there, they are from the dated version to the undated, that way you can keep older versions of images and kernels around for testing, but have scripts find the current versions.18:10
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC18:14
lpappsgw_: it is vice versa for e.18:14
lpappundated to dated.18:14
lpappjust like so to so.1, etc.18:14
lpappanyone here using openocd?18:16
lpappI wonder the workflow Yocto people prefer when flashing u-boot, etc with openocd.18:16
sgw_lpapp: maybe I gave the wrong sense of direction, it's as such: bzImage -> bzImage--3.8.13+git0+375cb6ebfd_f20047520a-r4.2-qemux86-64-20130726212309.bin18:16
sgw_undated -> dated18:16
lpappdo people keep openocd scripts in the images folder?18:16
*** gmacario <gmacario!> has quit IRC18:17
*** zecke <zecke!> has quit IRC18:21
-YoctoAutoBuilder- build #226 of nightly-x86-64 is complete: Failure [failed Running Sanity Tests] Build details are at
-YoctoAutoBuilder- build #227 of nightly-world is complete: Failure [failed Building Images] Build details are at
*** levi <levi!> has quit IRC18:47
*** levi <levi!~user@> has joined #yocto18:48
*** JimBaxter <JimBaxter!> has quit IRC18:57
-YoctoAutoBuilder- build #228 of nightly-arm is complete: Success [build successful] Build details are at
*** Jefro1 <Jefro1!> has quit IRC19:01
*** zerus <zerus!> has joined #yocto19:01
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:04
*** zerus <zerus!> has quit IRC19:07
*** Jay7 <Jay7!jay@> has quit IRC19:22
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has joined #yocto19:26
*** mulhern <mulhern!> has quit IRC19:28
*** Jay7 <Jay7!jay@> has joined #yocto19:28
*** trollixx_ <trollixx_!> has joined #yocto19:31
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC19:32
*** _julian_ <_julian_!> has quit IRC19:33
*** trollixx <trollixx!> has quit IRC19:33
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC19:33
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto19:33
*** _julian <_julian!> has joined #yocto19:33
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto19:33
lpapphow can I avoid having the output name, u-boot-$UBOOT_MACHINE.bin?19:38
lpappI would like to have only u-boot.bin.19:38
lpapphow can I avoid having the output name, u-boot-$MACHINE.bin?19:39
lpappsame for the uImage19:39
lpappbtw, why am I getting zImage generated when I have set the KERNEL_IMAGETYPE to uImage?19:39
ndeclpapp: not easily. i mean for the renaming.19:42
lpappndec: why not?19:46
lpappanyway, I am fine with it, then.19:46
lpappbut why don't I get uImage generated?19:46
ndecbecause it's how the recipe is writtn.19:46
lpappwhy I asked for that?19:46
ndecwhere/how did you set KERNEL_IMAGETYPE?19:46
*** dl9pf <dl9pf!~quassel@opensuse/member/dl9pf> has quit IRC19:47
lpappndec: in the machine conf19:48
lpappgrep -rn KERNEL_IMAGETYPE ./meta-foo/conf/machine/mymachine.conf19:48
lpapp36:KERNEL_IMAGETYPE = "uImage"19:48
ndecsomething might be overriding it. can you try bitbake -e virtual/kernel | grep KERNEL_IMAGETYPE19:50
lpappI already deleted tmp19:52
lpappsstate downloads etc19:52
lpappI will do a fresh build19:52
lpappit might be the recipe overriding it.19:55
ndeclpapp: so, your KERNEL_IMAGETYPE is not taken care. something must be wrong, either with your machine, or config.19:55
lpappyeah, the recipe sets it to zImage... I wonder why.19:55
lpappI thought our recipe would be a clone of the meta/19:56
*** zerus <zerus!> has joined #yocto19:56
lpappndec: the recipe should not define it, I guess?19:57
lpappFILES_kernel-image = "/boot/zImage*"19:57
lpappmeh, it also does this.19:58
lpappthat is also wrong.19:58
lpappequally wrong.19:58
lpappok, itbake -e virtual/kernel | grep KERNEL_IMAGETYPE19:58
lpappthat yields uImage now, thanks.19:58
*** jmdelos_ <jmdelos_!> has joined #yocto19:59
*** zenlinux <zenlinux!> has joined #yocto20:00
*** jmpdelos <jmpdelos!> has quit IRC20:00
*** joeythesaint <joeythesaint!> has joined #yocto20:02
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC20:08
*** martiert <martiert!> has joined #yocto20:10
*** tor <tor!> has quit IRC20:11
*** smartin_ <smartin_!> has joined #yocto20:19
*** sameo <sameo!~samuel@> has joined #yocto20:19
*** sakoman <sakoman!> has quit IRC20:29
*** jchonig <jchonig!~jch@> has quit IRC20:31
*** sakoman <sakoman!> has joined #yocto20:31
*** jchonig <jchonig!~jch@> has joined #yocto20:34
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC20:34
*** mulhern <mulhern!> has joined #yocto20:37
*** walters <walters!> has quit IRC20:46
*** zecke <zecke!> has joined #yocto20:49
*** YoctoAutoBuilder <YoctoAutoBuilder!> has quit IRC20:56
*** YoctoAutoBuilder <YoctoAutoBuilder!> has joined #yocto20:56
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC20:57
*** eren <eren!~eren@unaffiliated/eren> has quit IRC20:58
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto20:58
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto21:01
*** zerus <zerus!> has quit IRC21:07
*** ant_home <ant_home!> has joined #yocto21:13
*** jchonig <jchonig!~jch@> has quit IRC21:22
*** mulhern <mulhern!> has quit IRC21:30
*** Jefro <Jefro!> has joined #yocto21:31
*** zenlinux <zenlinux!> has quit IRC21:31
*** zecke <zecke!> has quit IRC21:32
*** mulhern <mulhern!> has joined #yocto21:36
*** smartin_ <smartin_!> has quit IRC21:53
*** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.> has quit IRC21:55
*** Umeaboy <Umeaboy!> has joined #yocto22:05
*** levi` <levi`!> has joined #yocto22:11
*** munch <munch!> has quit IRC22:13
*** munch <munch!> has joined #yocto22:14
*** Umeaboy <Umeaboy!> has quit IRC22:43
*** zenlinux <zenlinux!> has joined #yocto22:45
*** levi` <levi`!> has quit IRC22:52
*** levi <levi!~user@> has quit IRC22:52
*** smartin <smartin!> has quit IRC22:53
*** levi <levi!> has joined #yocto22:54
*** ant_home <ant_home!> has quit IRC22:58
*** arky <arky!~arky@> has joined #yocto22:59
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-anvbipmihduwsosj> has quit IRC23:01
*** smartin <smartin!> has joined #yocto23:08
*** jchonig <jchonig!~jch@> has joined #yocto23:27
*** pidge <pidge!pidge@nat/intel/x-rsukdcsiabjnsrqb> has quit IRC23:31
*** mulhern <mulhern!> has quit IRC23:32
*** flihp <flihp!~flihp@> has quit IRC23:33
*** flihp <flihp!~flihp@> has joined #yocto23:34
*** Jefro <Jefro!> has quit IRC23:35
*** mulhern <mulhern!> has joined #yocto23:37
*** B4gder <B4gder!> has quit IRC23:41
*** phdeswer_ <phdeswer_!> has joined #yocto23:51
*** hollisb <hollisb!> has quit IRC23:54
*** agust <agust!> has quit IRC23:56
*** andyross <andyross!> has quit IRC23:56
*** seebs <seebs!> has quit IRC23:58

Generated by 2.11.0 by Marius Gedminas - find it at!