**** BEGIN LOGGING AT Mon Jul 29 02:59:58 2013 Jul 29 04:07:38 nerdboy: I do not think everyone should add it on their own Jul 29 04:07:52 wmat: I do *not* wanna see warnings Jul 29 07:12:42 good morning Jul 29 07:20:24 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4941 Jul 29 07:20:25 Bug 4941: normal, Undecided, ---, saul.wold, NEW , udev does compile with older toolchains Jul 29 07:23:08 hi yocto. i am using yocto for at91sam9x5ek soc from 'https://github.com/linux4sam/meta-atmel'. 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? Jul 29 07:24:40 latest atmel bootstarp src at https://github.com/linux4sam/at91bootstrap Jul 29 07:27:34 my stable known working bootstrap (with buildroot uclibc based compiler) - "ftp://ftp.at91.com/pub/at91bootstrap/AT91Bootstrap3.1/" Jul 29 07:30:33 vicky: you could ask to http://www.at91.com/ forum too Jul 29 07:31:05 vicky: or #at91 channel Jul 29 07:44:01 mckoan: thanks. but i doubts compiler because of my old bootstrap not boots with yocto. Jul 29 07:57:13 Hi 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) Jul 29 08:00:36 fenrig: fb support is a kernel feature Jul 29 08:20:55 morning all Jul 29 08:24:11 morning Jul 29 08:24:26 morning bluelightning, all Jul 29 08:27:35 bluelightning: hi, how are you Jul 29 08:27:43 bluelightning: have you seen the udev break? Jul 29 08:33:59 bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4941 Jul 29 08:34:00 Bug 4941: normal, Undecided, ---, saul.wold, NEW , udev doesn't compile with older toolchains Jul 29 08:41:17 lpapp: good thanks, yourself? Jul 29 08:41:24 lpapp: yes I saw the report Jul 29 08:54:10 how to disable documentation on poky root filesystem ? Jul 29 08:55:40 vicky: 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 image Jul 29 08:56:18 vicky: the default is not to have either of those, what documentation are you seeing in your rootfs? Jul 29 08:58:48 bluelightning: do you have any idea for a quick fix? Jul 29 08:59:05 other than using a different udev in our layer. Jul 29 08:59:38 lpapp: not really, no, unless you can find a distro patch somewhere out there that resolves it Jul 29 09:00:01 lpapp: really I would expect the Mentor folks to have a patch for this if it's their toolchain that it happens with Jul 29 09:00:34 bluelightning: I guess they would suggest to upgrade the toolchain. Jul 29 09:00:39 but it is not a two minutes change. Jul 29 09:00:44 (and if that's the case we'd happily have in the core assuming it doesn't break newer toolchains) Jul 29 09:00:47 that will introduce a lot of new issues, too, in our software. Jul 29 09:01:11 you'd have to ask them Jul 29 09:01:16 http://comments.gmane.org/gmane.comp.embedded.ptxdist.devel/9215 Jul 29 09:01:21 they upgrade the toolchain in here, too. Jul 29 09:01:35 http://permalink.gmane.org/gmane.comp.embedded.ptxdist.devel/9215 Jul 29 09:01:43 I have pretty much the same gcc version as in the latter post. Jul 29 09:02:16 perhaps, it is better to ask the udev mailing list. Jul 29 09:02:23 you could try there yes Jul 29 09:02:35 but I thought udev would not exist anymore as a standalone? Jul 29 09:03:03 we build the last standalone version when we build without systemd Jul 29 09:04:12 when will systemd come to existence in Yocto? Jul 29 09:05:15 lpapp: it's already available in dylan and later Jul 29 09:05:26 lpapp: you just have to enable it as per the manual Jul 29 09:05:30 why is udev being built then? Jul 29 09:05:37 ok, let me rephrase then: Jul 29 09:05:41 when will systemd come to existence in Yocto as default? Jul 29 09:05:58 lpapp: not for some time yet I suspect Jul 29 09:06:11 why not? Jul 29 09:06:38 a lot of users just want to keep things simple, sysvinit works for them and they're not comfortable with switching to systemd yet Jul 29 09:06:54 over time that may well change, but that's the situation now Jul 29 09:07:07 those who do want to switch can do so easily via their distro configs Jul 29 09:07:11 is that really true ? Jul 29 09:07:21 I mean many people use systemd on desktop now. Jul 29 09:07:40 sure, but desktop != embedded for many different reasons Jul 29 09:07:56 in this context, there would be no differnece. Jul 29 09:07:59 difference* Jul 29 09:08:05 some embedded setups barely even have an init system Jul 29 09:08:08 systemd is ok on both. Jul 29 09:08:22 it would not make a difference for them then ... Jul 29 09:08:40 I'm not the one you have to convince Jul 29 09:59:48 okay I don't understand why I have no /dev/fb0 Jul 29 10:38:22 bluelightning: is it already decided which u-boot version is shipped for 10.0? Jul 29 10:38:31 bluelightning: I would like to send a patch to oe-core to update to 2013.07 Jul 29 10:38:38 lpapp: don't know, sorry Jul 29 11:26:20 bluelightning: yeah, here is the thing again with git, I need to update the srcrev manually Jul 29 11:26:26 bluelightning: with tarballs, you have no such troubles. Jul 29 11:26:38 it will take me a few minutes uselessly because it would be unnecessary with tarballs. Jul 29 11:48:29 bluelightning: is there a way to automatically update the SRCREV? Jul 29 11:51:36 it does not make much sense to demand manual stuff when you already specify the tag anyway Jul 29 11:51:45 * lpapp is opening a bugreport for it. Jul 29 11:52:52 seems "${AUTOREV}" already achieves that. Jul 29 11:53:09 but then what is the point of SCM, really Jul 29 11:53:44 when _pn is not specified for a variable it can still work, right? Meaning, it has only one package per recipe, right? Jul 29 11:55:30 which changes need to go to the yocto mailing list? Jul 29 11:55:34 the border is quite confusing. Jul 29 11:56:28 meta-yocto layer changes Jul 29 11:56:37 oe-core changes go to oe-core Jul 29 11:57:08 and what to poky? Jul 29 11:57:15 because actually I had to send meta-yocto changes to poky,. Jul 29 11:57:17 poky.* Jul 29 11:57:27 it is full of confusion. :) Jul 29 11:57:43 poky is met-yocyo Jul 29 11:57:54 ? Jul 29 11:58:00 never seen met-yocyo Jul 29 11:58:01 meta-yocto should be called meta-poky Jul 29 11:58:08 no no Jul 29 11:58:10 sorry bad typing Jul 29 11:58:14 you mentioned those should go to yocto Jul 29 11:58:16 poky != yocto Jul 29 11:58:21 they have separate mailing lists. Jul 29 11:58:24 lpapp: check the README in poky's top level directory Jul 29 11:58:38 bluelightning: I did. Jul 29 11:59:11 bluelightning: which means I should submit a bugreport to ask for clarification Jul 29 11:59:16 I have been told last time to send stuff to yocto Jul 29 11:59:23 I do not know why, but I have been. Jul 29 11:59:29 not sure who directed you to do that Jul 29 11:59:45 so he was wrong? Jul 29 11:59:52 what is written in the README reflects current practice Jul 29 12:00:17 bluelightning: I am now sending a u-boot update Jul 29 12:00:25 with the use of AUTOREV Jul 29 12:00:32 but I will probably remove the git stuff entirely for it. Jul 29 12:00:52 lpapp: we won't accept recipes containing SRCREV = "${AUTOREV}" I'm afraid Jul 29 12:01:25 lpapp: before you ask why, because they'll likely be broken shortly after they've been merged Jul 29 12:01:43 huh? Jul 29 12:02:41 not 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 altogether Jul 29 12:02:43 we want recipes to remain buildable, even in the case of bleeding edge ones, so the SRCREV should be fixed when it comes to published layers Jul 29 12:02:57 no? Jul 29 12:03:16 there is only one indifferent version tag. Jul 29 12:03:22 plus, if SRCREV is not set to a fixed revision, bitbake will have to query the server on every parse which is not desirable Jul 29 12:03:31 so it should be pretty straightforward what the relevant hash is. Jul 29 12:03:44 if you want SRCREV = "${AUTOREV}" you can easily have that by having a bbappend in your own layer Jul 29 12:03:45 yeah, it takes 0.0005 s Jul 29 12:03:56 compared to the easier maintenance it brings. Jul 29 12:04:05 you mean, harder maintenance Jul 29 12:04:09 I am not talking about my layer Jul 29 12:04:14 I am talking about oe-core proper. Jul 29 12:04:20 no, it is a lot easier. Jul 29 12:04:20 no, and I'm not either Jul 29 12:04:40 why to have double factor? Jul 29 12:04:55 but yes, I agree that the whole git stuff is a bloated mess, and have to go to the trash. Jul 29 12:05:46 don't put words in my mouth Jul 29 12:06:14 I did not ? Jul 29 12:06:43 your last comment agrees with something that I never said, that's the very definition of putting words in my mouth Jul 29 12:06:55 could you please clarify where I said I agree with *you* Jul 29 12:07:06 or is it just a mistinterpretation Jul 29 12:10:32 is it always the latest version that is built out of the recipes for the same software? Jul 29 12:10:37 I mean by default. Jul 29 12:10:40 good morning everybody. Jul 29 12:10:52 several softwares have more than one recipes Jul 29 12:10:55 not occasional to have 3-4. Jul 29 12:11:04 I've a question regarding a own linux kernel recipe... Jul 29 12:11:43 g0hl1n: which is Jul 29 12:11:52 I'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? Jul 29 12:12:16 To be precise FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}/files:${THISDIR}/${PN}/patches:" Jul 29 12:12:32 SRC_URI = "git://${KSRC};protocol=file;branch=${KBRANCH};name=kernel file://defconfig" Jul 29 12:13:41 I 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 defconfig Jul 29 12:13:47 any ideas? Jul 29 12:15:19 g0hl1n: have you checked with make menuconfig Jul 29 12:15:24 whether your .config is right Jul 29 12:15:50 lpapp: which .config? the one in the Kernel tree? Jul 29 12:16:09 yes Jul 29 12:16:59 lpapp: shouldn't the build ignore the .config in the kernel source but use defconfig from SRC_URI ? Jul 29 12:20:43 g0hl1n: the kernel needs .config Jul 29 12:20:56 if the kernel tree does not have a .config, it will not build. Jul 29 12:21:31 lpapp: and whats the defconfig for? Jul 29 12:21:46 I cannot build u-boot separately for testing? o_O http://pastebin.com/NzKbyJCa Jul 29 12:21:54 g0hl1n: to generate the .config out of. Jul 29 12:21:58 g0hl1n: http://cgit.openembedded.org/openembedded-core/tree/meta/classes/kernel.bbclass#n216 Jul 29 12:22:30 g0hl1n: if it does not work for boot Jul 29 12:22:35 you need to check before the kernel build Jul 29 12:22:44 for which vim or preferably make menuconfig is better. Jul 29 12:23:12 ok, so I've no .config is present it will copy over defconfig... Jul 29 12:23:28 yes, which means always Jul 29 12:23:30 But that's the point. Jul 29 12:23:33 if you start from scratch. Jul 29 12:23:48 I've no .config in the kernel source tree but a defconfig in SRC_URI. Jul 29 12:23:59 have you checked? Jul 29 12:24:05 in build/tmp/work etc Jul 29 12:24:13 and when I boot into the kernel and zcat the /proc/config.gz it isn't the same as defconfig Jul 29 12:24:22 have you checked? Jul 29 12:24:23 in build/tmp/work etc Jul 29 12:26:00 g0hl1n: 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 well Jul 29 12:27:30 so u-boot is not buildable on its own with bitbake? :( Jul 29 12:27:45 g0hl1n: and see meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb Jul 29 12:28:41 lpapp: well, there is no "generic u-boot for this cpu architecture" Jul 29 12:29:08 lpapp: even.. for a specific SoC there is no.. this will always work config Jul 29 12:29:10 zecke: ? Jul 29 12:29:21 UBOOT_MACHINE is not set ? Jul 29 12:29:24 it is? Jul 29 12:29:26 UBOOT_MACHINE="omap3_beagle_config" bitbake u-boot Jul 29 12:29:29 ant_work: here's the recipe: http://pastebin.com/3KtdpAzh Jul 29 12:29:30 that is what I used. Jul 29 12:30:49 lpapp: "ERROR: u-boot was skipped: because UBOOT_MACHINE is not set" most of the time computers don't lie. Jul 29 12:31:06 zecke: so? Jul 29 12:31:18 suggestions, pls. Jul 29 12:31:23 not error message reporting. :) Jul 29 12:31:25 I can also read. Jul 29 12:31:54 g0hl1n: I suppose youhave to fix FILESEXTRAPATHS_prepend Jul 29 12:32:12 lpapp: you can't pass in variable values from the environment like that unless the variable is one of the set listed in BB_ENV_EXTRAWHITE Jul 29 12:32:16 lpapp: and blog ;) Jul 29 12:32:43 bluelightning: sounds like a feature request (another report) Jul 29 12:32:51 ant_work: what's wrong with it? Jul 29 12:32:53 lpapp: nope, we're not adding that variable Jul 29 12:33:03 now, that does not make sense. Jul 29 12:33:24 zecke: actually no. Jul 29 12:33:30 other people blog a lot more at social sites Jul 29 12:33:36 I have only 5-10 blogs a year usually. Jul 29 12:33:39 posts* Jul 29 12:34:11 g0hl1n: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-3.1:${THISDIR}/${PN}:${THISDIR}/files:" if you want a specific dir for this kernel Jul 29 12:34:15 it would be plain silly to say, "no, you cannot try to build u-boot on i ts own" Jul 29 12:34:31 which is exactly the use case when you are trying to get it work. Jul 29 12:35:49 lpapp: your machine.conf file should set this var Jul 29 12:36:08 ant_work: I am not sure you realize that I would like to invoke it from command line. Jul 29 12:36:21 and surely, meta/ already does set that. Jul 29 12:36:27 so whitelist the var but still you have a defective conf Jul 29 12:36:59 * lpapp not sure to whom that message goes ... Jul 29 12:37:05 UBOOT_MACHINE is deeply tied with MACHINE, doh Jul 29 12:37:26 which is exactly why I tried to specify the variable? Jul 29 12:37:39 you ought just to specify MACHINE Jul 29 12:37:50 resistance is futile Jul 29 12:38:03 there is no any resistenace? Jul 29 12:38:09 (with me) Jul 29 12:38:10 saying resistance when there is none is futile? Jul 29 12:38:44 same with machine Jul 29 12:38:51 MACHINE="qemuarm" bitbake u-boot Jul 29 12:38:55 it is just broken in here ... Jul 29 12:39:11 does qemuarm set UBOOT_MACHINE? no. Jul 29 12:39:19 use a machine that has the relevant uboot configuration Jul 29 12:39:25 as uboot is by defintion machine-specific Jul 29 12:39:39 already tried beagleboard Jul 29 12:39:46 besides, it should report missing MACHINE Jul 29 12:39:51 its not missing Jul 29 12:39:55 yes, it does. Jul 29 12:40:00 the log you pasted clearly stated MACHINE=qemuarm Jul 29 12:40:19 now a failure with MACHINE=beagleboard would be more interesting Jul 29 12:40:20 I think you should be investigating a bit more rather than chim in without the prior history. Jul 29 12:40:35 the log is public after all. Jul 29 12:40:51 lpapp: how do you think i knew what was in the bitbake log you posted? Jul 29 12:41:30 rburton: I believe you just did not read back, and you still do not have the proper context. Jul 29 12:41:31 lpapp: 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. Jul 29 12:41:46 again, *please* get the context Jul 29 12:41:54 you chim into the middle of the conversation Jul 29 12:41:59 and you refer to something that no one refers to. Jul 29 12:42:03 because you lack the context Jul 29 12:42:06 please go read it. :) Jul 29 12:42:14 * lpapp is filing a bugreport in the meantime. Jul 29 12:46:34 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4945 Jul 29 12:46:35 Bug 4945: normal, Undecided, ---, saul.wold, NEW , No reference to missing MACHINE when running u-boot through bitbake Jul 29 12:50:23 lpapp: note the defaults for the other vars http://cgit.openembedded.org/openembedded-core/tree/meta/classes/kernel.bbclass#n57 Jul 29 12:51:00 ant_work: I know. Jul 29 12:51:21 so typically you set all 3 like in this BSP i.e. http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/conf/machine/vexpressa9.conf?h=master#n36 Jul 29 12:51:24 ant_work: however it is pretty pointless. Jul 29 12:51:29 as it will be supplied to openocd anyway Jul 29 12:51:48 I have never understood those two variables... Jul 29 12:51:48 tbh I'm not following, there was th eidea of auto-calculating those addresses iirc Jul 29 12:51:51 and that why I would use it. Jul 29 12:52:19 you cannot auto calculate those. Jul 29 12:52:25 you need to supply it to openocd Jul 29 12:52:29 or whatever flasher you use anyway Jul 29 12:52:54 frankly, I am not sure why yocto has variables for those. :) Jul 29 12:53:44 see my other bugreport where I asked for documentation. Jul 29 12:53:46 kernel.bbclass #348 Jul 29 12:55:02 looks like a broken function Jul 29 12:55:11 * lpapp will try to patch out when getting some time ... Jul 29 12:56:21 make uImage should be used simply. Jul 29 12:56:59 but even then, there is no any need for the entry point like that Jul 29 12:57:01 nor the address. Jul 29 12:57:21 0: icu-native-51.2-r0 do_fetch (pid 10940) -> got stuck here for an hour Jul 29 12:57:28 how can I make sure it is doing *anything* Jul 29 12:58:14 probably there is a logfile somewhere. Jul 29 13:00:14 WARNING: 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. Jul 29 13:00:18 ERROR: Only one copy of bitbake should be run against a build directory Jul 29 13:00:19 why am I getting this for a dry-run try? Jul 29 13:00:33 I do not wanna build u-boot... I would just like to get the checksums to update the recipes... Jul 29 13:00:36 is that possible somehow? Jul 29 13:00:59 yes, md5sum and sha256sum the file in /downloads Jul 29 13:03:29 no no Jul 29 13:03:33 I do not wanna do them separately. Jul 29 13:03:40 I have been told bitbake can five both off-hand. Jul 29 13:03:47 give* Jul 29 13:05:31 unfortunately your other bitbake is stuck on do_fetch Jul 29 13:05:44 only one copy...blah Jul 29 13:06:33 not sure what you are talking about Jul 29 13:06:42 1) That was already cancelled. Jul 29 13:06:51 2) Dry-run should not interfere with a full fledged run. Jul 29 13:09:19 lpapp: 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 suggested Jul 29 13:09:40 you have them both on-screen and in the logs Jul 29 13:11:17 ant_work: no no, I have never updated the checksum of any recipe. Jul 29 13:11:23 this is the first time, I would need to do it. Jul 29 13:11:31 only thing, I have been told, bitbake can provide both checksums. Jul 29 13:11:37 but I do not really find an option for doing so. Jul 29 13:11:37 it does indeed Jul 29 13:11:41 how then? Jul 29 13:11:47 why do I need to repeat myself ? :D Jul 29 13:11:55 just update the SRC_URI, the new d/l will have different checksums Jul 29 13:12:10 and build will blatantly fail Jul 29 13:12:19 that is silly. Jul 29 13:12:21 verbosely Jul 29 13:12:23 sounds like another feature request. Jul 29 13:12:37 why do I even need to fail or even try not to fail? Jul 29 13:12:44 the whole point is that I am explicitely sure they are outdated. Jul 29 13:12:45 lpapp: you remember kernel sources have been hacked last year, do you? Jul 29 13:12:46 so gimme those. Jul 29 13:12:50 that is the user request. Jul 29 13:13:01 I do not wanna start building when I *explicitly* know it will not work. Jul 29 13:13:11 he he Jul 29 13:13:20 ant_work: I had been working on kernel security for 1-2 years. Jul 29 13:13:25 but I do not think it is relevant in here. Jul 29 13:13:38 don't be silly..then use md5sum and sha256sum before Jul 29 13:13:59 bitbake does a great service to the lazy developer Jul 29 13:14:23 who is silly is relative Jul 29 13:14:36 but no, I do not wanna run two tools, when one could do the jobs. Jul 29 13:14:45 that is what I call silly. Jul 29 13:14:51 if one can do, why bother with two. Jul 29 13:15:16 hm.. another d�j� vu... ah, itwas me telling you that an *human* must verify th eintegrity of the sources Jul 29 13:16:44 you can fully verify. Jul 29 13:17:00 anyway, so someone was a "liar" :) Jul 29 13:17:04 who told me bitbake can do it. Jul 29 13:17:11 in fact, the solution recommended then, is to use low-level tools. Jul 29 13:17:17 and do the job as many times as bitbake requires. Jul 29 13:18:03 if you cannot trust bitbake, you would be screwed up anyway already Jul 29 13:18:15 so it is *very* unlikely this checksum issue would be the only way of screwing up. Jul 29 13:18:26 since bitbake has to be a trusted source already anyway. Jul 29 13:18:34 pls just try once Jul 29 13:18:37 so your security concern is moot, respectively. Jul 29 13:19:01 it is not the matter of try once Jul 29 13:19:07 it is the matter of inconvenience for: Jul 29 13:19:27 md5sums downloads/foo/crap Jul 29 13:19:32 sha... downloads/foo/crap Jul 29 13:19:33 lpapp: there have been repositories changing the tarballs and keeping the same name Jul 29 13:19:34 instead of: Jul 29 13:19:44 bitbake crap -> done Jul 29 13:20:33 not to mention, I do not have u-boot inside downloads/ at all. Jul 29 13:21:29 also, why would I need 393 tasks for getting u-boot? o_O Jul 29 13:22:35 surely, u-boot does not have that many dependencies? Jul 29 13:26:36 like python-native for u-boot, really? Jul 29 13:26:45 * lpapp feels like another bugreport ... Jul 29 13:27:25 there should be a u-boot-minimal Jul 29 13:27:52 without the python tools. Jul 29 13:36:52 btw, why does u-boot have patches if they are not applied? Jul 29 13:36:58 what is the point of that, then? Jul 29 13:41:52 ERROR: QA Issue: external-sourcery-toolchain: Files/directories were installed but not shipped /usr/libexec /lib/libssl.so.1.0.0 Jul 29 13:42:24 http://pastebin.com/XQV71T6N -> here is the full error. Jul 29 13:46:35 is there any reason why I cannot find u-boot-2013.07.tar.bz2 in the build folder? Jul 29 13:46:39 it should download it, no? Jul 29 13:48:32 lpapp: if you have set it in SRC_URI. oe-core's u-boot is fetching .git Jul 29 13:50:11 ant_work: so? Jul 29 13:50:26 so there is no tarball Jul 29 13:50:40 that is very bad Jul 29 13:51:08 oh, actually there *is* tarball Jul 29 13:51:12 it is here: ./downloads/git2_git.denx.de.u-boot.git.tar.gz Jul 29 13:52:05 hmm, that is just the git meta info apparently, strange. Jul 29 13:52:22 my patch is not downloaded apparently either from the local golder. Jul 29 13:52:24 folder* Jul 29 13:52:33 well, it makes super hard to reproduce an issue Jul 29 13:53:14 how can I actually get the content? Jul 29 13:53:19 it is failing to apply a change. Jul 29 13:53:28 and I would like to get a clean content of the decompressed tarball. Jul 29 13:53:34 or cloned git stuff Jul 29 13:54:26 sorry, have to go. bbl Jul 29 13:55:16 what is the workflow for debugging a failed application of a change? Jul 29 13:55:20 present in files? Jul 29 13:56:07 bitbake -c unpack will unpack the sources. while "-c patch" will apply any potential patches Jul 29 13:56:49 there is nothing to unpack as noted above. Jul 29 13:58:26 when using .git or any other SCM, bitbake will fetch the entire 'tree', then checkout the right version, and create a tarball of that version. Jul 29 13:58:45 so next build, if the tarball is there, it's used. Jul 29 13:58:49 it is just the bare repository inside the tarball as noted above. Jul 29 13:59:02 which does not help in my case. Jul 29 13:59:35 ./tmp/work/foo-linux-gnueabi/u-boot-v2013.07+git13+19b54a701811220221fc4d5089a2bb18892018ca-r1/git/ Jul 29 13:59:38 seems it is in here Jul 29 13:59:44 * lpapp hates git when it is just about a release Jul 29 13:59:47 there is a tarball of the bare repo in git folder, iirc. but there should be a tarball of the right version too in downloads Jul 29 13:59:50 the whole situation would be sooo much easier with a tarball. Jul 29 14:00:35 patch does not seem to need checksum? Jul 29 14:00:37 because it is local? Jul 29 14:02:59 Prepare v2011.03 Jul 29 14:03:04 ah, it is downloading that u-boot... Jul 29 14:03:16 so is it guaranteed somehow that always the latest is picked up? Jul 29 14:03:44 ?? Jul 29 14:03:54 ? Jul 29 14:04:50 why in the hell does it pick up 2011.03? Jul 29 14:04:58 when it is 2013.07 inside the recipe? Jul 29 14:05:10 PV = "v2013.07+git${SRCPV}" Jul 29 14:05:10 PR = "r1" Jul 29 14:08:05 what does bitbake -s| grep u-boot tell you? it should tell you which uboot recipe/version is being used. Jul 29 14:08:13 are you on master or dylan? Jul 29 14:08:42 denzil Jul 29 14:08:47 as master and dylan suck huge balls Jul 29 14:09:06 denzil is the last sane release with an older toolchain. Jul 29 14:09:37 long live to denzil Jul 29 14:09:52 i don't see your PV line, in denzil. Jul 29 14:10:05 i see PV = "v2011.06+git${SRCPV}" Jul 29 14:10:06 lpapp: "suck huge balls". that is not very approriate language.. Jul 29 14:10:57 ndec: well, obviously, we have to ship it in our own layer Jul 29 14:11:02 that is what the bsp layer is for. Jul 29 14:11:28 so, that means you have 'something' in your layer, that prevent your uboot from being used. Jul 29 14:11:33 again, bitbake -s should help. Jul 29 14:11:49 it must be a 'preference' issue or something like that. Jul 29 14:12:04 it is really strange Jul 29 14:12:10 bitbake u-boot does not rebuild stuff Jul 29 14:12:19 although I deleted stuff from downloads and tmp/work, too. Jul 29 14:12:36 zecke: imagine your language there for "totally blocking our business" Jul 29 14:12:36 * zecke updates the ignore list Jul 29 14:13:27 ndec: we have higher priority in there. Jul 29 14:13:30 priority 6. Jul 29 14:14:19 bitbake -s will tell you the truth.. i can't tell you about something i can't see. Jul 29 14:15:03 i am tempted to say that you have DEFAULT_PREFERENCE = "-1" in your recipe... Jul 29 14:15:17 nope Jul 29 14:15:47 also, I already pasted this before:v2013.07+git14+62c175fbb8a0f9a926c88294ea9f7e88eb898f6c-r1 Jul 29 14:15:53 but 2011 content inside. Jul 29 14:17:01 I have no clue. Jul 29 14:17:31 also, bitbake u-boot does not build u-boot anymore. Jul 29 14:17:33 I have no idea why. Jul 29 14:17:39 I deleted the downloads and tmp/work contents Jul 29 14:17:45 I thought it should do a brand new stuff. Jul 29 14:18:49 * lpapp is about to dump the whole build folder content Jul 29 14:18:57 that seems to be the only reliable option most of the time. Jul 29 14:19:40 this package and job cashing usually goes crazy Jul 29 14:19:46 and results hard to debug issues like this. Jul 29 14:21:25 ndec: as I already wrote before, but here you go anyway: http://pastebin.com/bL65CY4x Jul 29 14:25:13 how can I force bitbake to redownload and rebuild u-boot from scratch? Jul 29 14:26:45 * lpapp will dump the build folder for real as it is better to waste 40 minutes than few hours of debugging Jul 29 14:27:33 lpapp: bitbake u-boot -c cleanall Jul 29 14:27:56 I already dumped Jul 29 14:28:30 lpapp: I should have bothered mentioning it for next time then... Jul 29 14:29:22 yeah, but not sure I can memorize it, really. :-) Jul 29 14:29:46