**** BEGIN LOGGING AT Tue Jan 19 02:59:58 2016 Jan 19 09:09:42 hi, how to I force a rebuild of the sdcard image? Jan 19 09:36:46 mwarning: I guess this should work: bitbake -c rootfs -f Jan 19 09:38:03 Hi yocto team Jan 19 09:38:29 i am facing issue in creating sdimage for raspberrypi on poky Jan 19 09:39:05 error it is showing is do_image_rpi-sdimg: not found Jan 19 09:42:10 @khem: any idea on this issue Jan 19 09:48:07 using the master branch? there was a patch submitted recently to fix that Jan 19 10:16:50 hello Jan 19 10:17:40 i've installed meta-toolchain-qt5 but i'm unable to compile programs that use webkit Jan 19 10:18:56 i think i need to update PACKAGECONFIG in some way Jan 19 11:13:16 Hi, is it possible to have two git uri in a recipe, as such that the second one is fetched and unpacked into the same work dir as the first? Jan 19 11:15:11 CTtpollard: yes, you just need to set destdir= on one or both of them; also specify name= on both and then you can set SRCREV separately for each one Jan 19 11:16:06 bluelightning: are you aware of any examples of this that I could look at? Jan 19 11:16:21 just looking for that now Jan 19 11:17:16 thanks :) I have a source that keeps its plugins in a separate repo, and needs to be present at compile time Jan 19 11:17:45 sorry, I meant to say destsuffix= Jan 19 11:18:09 meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_git.bb would be one example Jan 19 11:18:12 if there's any gstreamer git recipes Jan 19 11:18:15 oh yeah, there you go :) Jan 19 11:18:18 ;) Jan 19 11:19:42 cheers :) Jan 19 11:29:04 does someone of you know of a good tutorial about how to work with the devshell? Jan 19 11:32:39 it should e.g. also cover how to package a modified recipe Jan 19 11:35:16 or is it just bitbake -c devshell recipe -> bitbake -c build recipe ? Jan 19 11:51:47 jaeckel: if you're looking at modifying the source for a recipe and you're using 2.0+ I'd highly recommend looking at devtool - in particular devtool modify Jan 19 11:52:41 unfortunately I have to get some sleep, but there are basic docs here: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-devtool-in-your-workflow Jan 19 11:53:00 cool! thanks a lot Jan 19 11:53:02 and sleep well Jan 19 11:54:20 np Jan 19 11:54:22 thanks Jan 19 12:02:39 are there any efforts in creating&maintaining auto-completion scripts for bitbake and devtool? Jan 19 12:41:44 belen, any pointers at getting toaster to work with an existing OE setup? Jan 19 12:43:29 Crofton|work: have you emailed your set up to townxelliot? Jan 19 12:43:39 no Jan 19 12:43:43 I suppose I should Jan 19 12:44:04 I got past the template file problem Jan 19 12:44:32 and got the web interface started, but it didn't seem aware I alrady had a conf/bblayers Jan 19 12:45:18 I'm leaving for Berlin Saturday (weather willing) Jan 19 12:45:31 I ahve the monnow and the E310 running (very closely) the same image Jan 19 12:45:56 Crofton|work: we would need to understand how you are set up. It is very possible that there are some assumptions built in regarding location of certain files Jan 19 12:45:59 just missing toaster data to show with them Jan 19 12:46:13 yeah, I'll reply to the email you sent Jan 19 12:46:57 Crofton|work: I will be in Brussels Friday early afternoon. Worst case scenario we can try to built it together Friday or Saturday Jan 19 12:47:43 ok, I am in around 2PM staying in an airbnb across from St Nicks Jan 19 13:47:05 Hi, I am having a problem when building 'xen-image-minimal' Jan 19 13:47:19 "ERROR: QA Issue: xen: Files/directories were installed but not shipped in any package: Jan 19 13:47:22   /etc/init.d/xendriverdomain" Jan 19 13:47:41 bmg. there's a patch on the meta-virtualization list for that. it arrived about 15 minutes ago. Jan 19 13:47:58 zeddii: thank you ! Jan 19 13:48:27 I'm merging it right now. so if you pull in about 5 mins, it'll be there. Jan 19 13:58:56 If I write my own do_fetch and do_unpack - I suppose I have to write my own do_cleanall state to make sure my downloaded stuff gets trashed? Jan 19 14:00:36 ,and if I write my own do_cleanall, do I have to clean the shared state cache myself as well? Jan 19 14:00:50 (Since I'm overriding that default behavior) Jan 19 14:04:06 (Or is the thing to do to override do_clean, and leave cleanstate and cleanall as is Jan 19 14:33:30 Hi, I was trying to create a core image (valleyisland-64) using the meta-intel layer. I properly configured bblayers.conf and local.conf but bitbake returns an error saying that MACHINE name is not valid... any idea? Jan 19 14:37:08 zeddii: thanks, pulled and build further, but when finishing off do_rootfs I get the following error: Jan 19 14:37:12 http://pastebin.com/gL9LeRqX Jan 19 14:41:11 bmg. so some kernel modules didn't get built, are you using a custom kernel, or linux-yocto directly ? Jan 19 14:44:04 zeddii: just using the yocto kernel unmodified Jan 19 14:44:38 I have not cloned it specifically, as I assumed that I was not modifying Jan 19 14:44:54 hmm. so those should be present. this is all with up to date master branches (for everything) ? Jan 19 14:46:29 http://pastebin.com/9Wqd8Y0u Jan 19 14:46:41 are the steps that I have taken Jan 19 14:47:04 cloned most of the code yesterday, and just pulled the meta-virtualization patch that you made this afternoon Jan 19 14:47:19 so *should* be upto date Jan 19 14:54:21 Spulit: does bitbake-layers show-layers list meta-intel? Jan 19 14:54:33 bmg. hah. It would have built the 4.4 kernel if you used master, but xen only has a 4.1 configuration. I can clone the 4.1 config, to 4.4 and push it. but obviously that won't be tested. Jan 19 14:54:37 bmg. pushed. Jan 19 14:58:05 captain guinea pig at your service :) Jan 19 14:59:03 thank you, so I should stick to the fido branch to have a good config ? Jan 19 14:59:41 bmg. I'm not using the configs directly at the moment, so I can't say if fido was any better. I know people are using master, so that's where I'd suggest at the moment. Jan 19 15:00:08 you can always set a PREFERRED_VERSION for linux-yocto to 4.1, and that would use the 4.1 kernel and that tested set of configs. Jan 19 15:21:22 CTtpollard: Well, it seems not... I added it in bblayers.conf...maybe something's missing... Jan 19 15:22:52 CTtpollard: or better...it shows the meta-intel layer, but not the meta-valleyisland... Jan 19 15:24:00 Spulit: add a direct path to the meta-valleyisland in bbylayers and try again Jan 19 15:26:21 khem: good news: the musl branch appears to build fine :) Jan 19 15:26:53 phew Jan 19 15:27:09 I am now on my way to build an XFCE image Jan 19 15:27:09 :) Jan 19 15:27:15 that I will install on my desktop Jan 19 15:27:31 and eat my own dogfood Jan 19 15:28:09 nice Jan 19 15:41:13 CTtpollard: That's what I did... but it seems it is not recognising it...weird... Jan 19 15:45:50 CTtpollard: I even added it using bitbake-layers add-layer Jan 19 15:46:28 Spulit: what commit sha is this off meta-intel? master? Jan 19 15:46:31 *of Jan 19 15:52:53 belen, https://plus.google.com/101203797379542776446/posts/QxWKnqStumc Jan 19 15:53:04 CTtpollard: yes, I recently did a git clone Jan 19 15:53:56 Crofton|work: nice Jan 19 15:54:18 just so you know this isn't an academic exercise :) Jan 19 15:54:30 Crofton|work: you mean you do work?! Jan 19 15:54:39 sometimes Jan 19 15:55:14 Crofton|work: I like academic exercises, but whatever ;) Jan 19 15:55:20 heh Jan 19 15:55:52 always good to remind people that there are real world applications for this work :) Jan 19 15:56:30 life is more than autobulder reports and bug stats Jan 19 15:58:04 Spulit: what exactly have you put as the machine name in local.conf? Jan 19 16:02:37 CTtpollard: valleyisland-64 Jan 19 16:33:50 rburton: Jan 19 16:34:20 there are couple of more patches unrelated to musl Jan 19 16:34:40 that I will submit later this week Jan 19 17:51:15 zeddii: JaMa points out that linux-yocto-4.4.git is nearly 2x the size of linux-yocto-4.1.git; is that expected? Jan 19 17:53:28 hmm. no. not at all. Jan 19 17:53:46 zeddii: and as bluelightning mention this topic, why do you need separate repository for each version? unlike other kernel repositories? Jan 19 17:54:12 http://pastebin.com/sqSbxMfS Jan 19 17:54:38 because the patches are rebsed. Jan 19 17:54:50 same reason why Greg's -stable, and the -rt aren't in the same tree. Jan 19 17:55:21 isn't it enough to rebase them in different branches? Jan 19 17:55:32 while reusing majority of objects between all versions? Jan 19 17:55:35 you'd end up with a huge spew of branches. Jan 19 17:55:43 I could also archive old versions of the tree. Jan 19 17:55:53 now you have huge sped of branches in spew of repositories Jan 19 17:56:01 shrugs Jan 19 17:56:12 I can keep one master version of tree and rebase it. Jan 19 17:56:20 and we shuffle old ones off. that'll work as well. Jan 19 18:00:35 * armpit kernel maint is a lot of work.. is for what ever makes sense Jan 19 18:01:40 I'm seeing a slightly larger tree on my development box. Is there a way to trigger a server-side git-gc, or do I need halstead for that ? Jan 19 18:02:37 zeddii: are you referring to contrib? Jan 19 18:03:19 linux-yocto-4.4 itself. it's no different than other kernel trees. I'm not sure why it is coming in as 2x the 4.1 tree. Jan 19 18:03:37 halstead: we need to delete user branches which has been merged Jan 19 18:03:44 from contrib trees Jan 19 18:04:24 halstead: may be you should send a notification to mailing list to remind users to delete dead branches Jan 19 18:04:29 zeddii: I ran gc and prune when I set up 4.4. I can rerun with --aggressive Jan 19 18:04:41 ok. so it shouldn't be that then. Jan 19 18:04:46 zeddii: did you see JaMa 's message on OE channel ? Jan 19 18:04:55 nope. not on the oe channel. Jan 19 18:04:59 zeddii: 4.4 repo is quite big Jan 19 18:05:05 that's what we are discussing :) Jan 19 18:05:11 more features ; ) Jan 19 18:05:15 trying to figure out what it is. mine is showing about the same size. Jan 19 18:05:20 khem`: will do. I also will move old branches to archive. Jan 19 18:05:23 JaMa wondering why it's twice as big as other linux-yocto repos Jan 19 18:05:24 [09:44:58] 986964 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-3.19.git Jan 19 18:05:24 [09:44:58] 1022940 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.1.git Jan 19 18:05:24 [09:44:58] 1269560 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-dev.git Jan 19 18:05:26 [09:44:58] 2382760 /media/shr/OE/downloads/git2/git.yoctoproject.org.linux-yocto-4.4.git Jan 19 18:05:45 khem`: complete list is in pastebin couple lines above Jan 19 18:06:37 JaMa: I just joined here client doesnt have much history Jan 19 18:06:48 it could be some git fetcher screw-up, because it was also taking forever to fetch (cca 20 hours on my 200Mbit/s line) Jan 19 18:06:59 halstead: I would prefer for folks to delete the dead branches before you archive them Jan 19 18:06:59 interesting. my downloads shows 4.4 as slightly smaller. Jan 19 18:07:00 argh Jan 19 18:07:08 yow-bashfiel-d4 [/home/bruc...loads/git2]> du -sh git.yoctoproject.org.linux-yocto-4.4.git/ Jan 19 18:07:09 1.1G git.yoctoproject.org.linux-yocto-4.4.git/ Jan 19 18:07:09 yow-bashfiel-d4 [/home/bruc...loads/git2]> du -sh git.yoctoproject.org.linux-yocto-4.1.git Jan 19 18:07:09 1.2G git.yoctoproject.org.linux-yocto-4.1.git Jan 19 18:07:19 * zeddii should pastebin that. sorry. Jan 19 18:07:32 1G of junk. grr. Jan 19 18:07:42 pastebin removes the links after a while Jan 19 18:08:02 and irc logs loose vital info when referred to in future Jan 19 18:08:19 2-5 lines should be fine to paste Jan 19 18:08:33 * zeddii nods. Jan 19 18:09:03 anyway. will figure out what is going on. definitely not on purpose. Jan 19 18:09:08 just dont paste gcc -E output here when I ask for one :) Jan 19 18:09:12 heh Jan 19 18:09:20 * zeddii puts that on his TODO list! Jan 19 18:09:59 zeddii: btw. what all ppc machines support is good in kernel Jan 19 18:10:11 it looks like fetcher fault, see http://pastebin.com/wG0LiVhb there is couple big git.yoctoproject.org.linux-yocto-4.4.git/objects/pack/tmp_pack_* files which weren't in earlier versions Jan 19 18:10:33 khem. that's a small list. a dying breed to be sure. Jan 19 18:10:49 khem': and you are thinking in terms of qemu system emulation Jan 19 18:10:49 halstead: what git version do you run on git yp org Jan 19 18:11:02 zeddii: yes Jan 19 18:11:08 I saw your email about the instruction set to the oe-architecture list. Jan 19 18:11:20 I think 1.8.4. I'll need to verify Jan 19 18:11:33 halstead: hmm may be upgrade to 2.x Jan 19 18:11:35 there were rumours of a system emulated FSL machine, but I've never seen it work. all of the modern machines need ppc KVM to fill in the gaps. Jan 19 18:12:00 halstead: if you run ubuntu on those boxes then they have a separate feed repo for git Jan 19 18:12:17 zeddii: I am not sure if fsl would care any more Jan 19 18:12:29 there n/w chips are moving away from ppc Jan 19 18:13:39 halstead: gerrit exposed some issues in garbage collection IIRC Jan 19 18:14:11 Do you have a link? Jan 19 18:17:55 halstead: any progres with oe-commits ML? Jan 19 18:19:09 No. I did see your error which is helpful. Can I make a testing branch to do repeated tests on if I delete it after? Jan 19 18:44:50 JaMa, still using SHR disk for builds? Jan 19 18:51:31 fsdun: "disk"? I'm still using SHR distro for some builds Jan 19 18:51:54 khem`, Updated to 2.3.7 for now and doing some tests. We are using 1.8.3 everywhere else though. If anything odd happens that's what we will revert to. Jan 19 18:52:10 I have seen /media/shr in your pastebin Jan 19 18:52:43 fsdun: that's shr-chroot partition (minimalistic Gentoo chroot) Jan 19 18:53:14 http://git.shr-project.org/git/?p=shr-chroot.git;a=summary is still being updated Jan 19 18:53:24 ok :) Jan 19 18:55:41 any updates on SHR itself? Jan 19 19:02:38 zeddii, linux-yocto-4.4 is now 894M. Does that sound right? Jan 19 19:02:46 yep Jan 19 19:03:18 fsdun: I'm just keeping it building and upgrading stuff used elsewhere (like efl) Jan 19 19:03:38 fsdun: Bob recently started working on porting it to Galaxy Jan 19 19:04:35 fsdun: but I spent very little time on SHR specific stuff nowadays, meta-oe, LuneOS, WebOS taking most of my free time Jan 19 19:05:43 oh. WebOS is still WIP? Jan 19 19:06:26 I cannot build it at home. I'm quite lazy these days when I'm at home Jan 19 19:06:49 (my laptop is still 32-Bit based) Jan 19 19:06:51 the opensource part is alive only in LuneOS, but there is a lot of WebOS work inside LG Jan 19 19:06:57 so I cannot build webkit :P Jan 19 19:35:19 JaMa, is morphis still active for luneos? Jan 19 19:37:54 fsdun: also busy with other projects, so only a bit Jan 19 19:38:25 hmpf. DISK_SIGNATURE_GENERATED adds random bits to the signature of bootdirectdisk Jan 19 19:41:11 JaMa, I have some nice HW at work, so I don't do much at home Jan 19 19:41:50 I started a telepathy plugin for whispersystems, but it's already sleeping :( Jan 19 19:41:59 is it the cause for: ERROR: Bitbake's cached basehash does not match the one we just generated (/home/jenkins/oe/world/shr-core/meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb.do_image_cpio)! Jan 19 19:42:05 ERROR: The mismatched hashes were 7a4f4526036cf9bf551cab58e875b1f8 and 6aa63fdc98b3cd1705cd4.. Jan 19 19:42:24 maybe Jan 19 19:42:40 it generates a uuid Jan 19 19:43:41 maybe DISK_SIGNATUREDISK_SIGNATURE[vardeps-exclude] += "DISK_SIGNATURE_GENERATED" is required? Jan 19 19:46:00 JaMa, you can check by using bitbake -S printdiff after building Jan 19 19:47:00 fsdun: I know Jan 19 19:47:07 ok ;) Jan 19 19:49:47 it got broken someday after 21151114 when we had clean report: http://lists.openembedded.org/pipermail/openembedded-devel/2015-November/104638.html Jan 19 20:02:24 have to leave Jan 19 20:02:26 good night Jan 19 20:04:20 otavio: ?? Jan 19 20:04:47 is there a linux-fslc-4.x commit that fixes this? https://github.com/SolidRun/linux-imx6/commit/ab77dfaaabea44c831820cda38b386510d7e9aa9 Jan 19 20:05:26 i get no wifi at all on cubox-i with 4.4 kernel Jan 19 20:05:40 works fine on wand/udoo Jan 19 20:16:21 Hi guys, is there a way of modifying u-boot config without actually forking it? e.g. through a .bbapend or something, similar to how I change the kernel configuration. Jan 19 22:04:48 is there a variable for i586 vs i686? ${ARCH}? Jan 19 22:06:11 tripzero2: TARGET_ARCH I would think Jan 19 22:06:25 kk, will try Jan 19 22:06:26 tripzero2: you can use an override for that Jan 19 22:06:42 e.g. Jan 19 22:06:43 VARNAME_i586 = "the value for i586" Jan 19 22:06:46 VARNAME_i686 = "the value for i586" Jan 19 22:06:49 er Jan 19 22:06:55 VARNAME_i686 = "the value for i686" Jan 19 22:07:29 bluelightning: what about VARNAME_${TARGET_ARCH} = "blah" ? Jan 19 22:08:02 that's not going to help - that's equivalent to VARNAME = "blah" Jan 19 22:08:24 the override means "only apply this assignment if the specified override is in OVERRIDES" Jan 19 22:08:56 and ${TARGET_ARCH} is in the value of OVERRIDES Jan 19 22:09:09 well, actually ${TRANSLATED_TARGET_ARCH} Jan 19 22:09:31 (which is TARGET_ARCH with underscores converted to hyphens) Jan 19 22:10:23 thus you really want VARNAME_override = "desired value if override applies" Jan 19 22:10:38 i think i understand Jan 19 22:11:02 VARNAME_${TARGET_ARCH} wouldn't make for a very good arch-specific override :P Jan 19 22:11:14 not really no, it'd always apply :) Jan 19 22:27:58 otavio: there are a few things missing from the cubox-i device tree config Jan 19 22:28:25 not that i know exactly how to shoehorn them in... Jan 19 22:29:11 but they *are* defined in wandboard and udoo .dtsi files Jan 19 23:12:58 i m trying to run this command and getting some framebuffer issue can anyone help Jan 19 23:12:59 gst-launch-1.0 imxv4l2src device=/dev/video0 ! imxipuvideotransform ! imxipuvideosink framebuffer=/dev/fb1 Jan 19 23:13:15 Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. ERROR: from element /GstPipeline:pipeline0/GstImxIpuVideoSink:imxipuvideosink0: could not open /dev/fb1: No such device or address Additional debug info: ../src/common/blitter_video_sink.c(743): gst_imx_blitter_video_sink_open_framebuffer_device (): /GstPipeline:pipeline0/GstImxIpuVideoSink:imxipuvideosink0 Setting pipeline to NULL ... Freeing pipeline . Jan 19 23:14:27 http://pastebin.com/JRbssTGT Jan 19 23:15:26 @DarkNight, can yoy please help Jan 19 23:17:52 have anyone seen this issue? Jan 19 23:59:33 can anyone help on this? Jan 19 23:59:43 see pastebin for error Jan 19 23:59:44 http://pastebin.com/JRbssTGT Jan 20 00:24:14 Eric____: do you have the relevant device created by fb driver ? Jan 20 00:24:30 bluelightning: btw. another thing with devtool Jan 20 00:24:46 bluelightning: when I build one package for one machine and then switch machine Jan 20 00:25:02 it gets into issues Jan 20 00:25:33 since it tries to reuse the old .o files from this component since its under devtool workflow Jan 20 00:25:50 no clean helps Jan 20 00:26:23 I have to go into the externalsrc sources of the component Jan 20 00:26:23 that seems strange, externalsrc defaults to using a separate B from S, so B would just be wiped, no? Jan 20 00:26:29 and manually run make clean Jan 20 00:26:49 kergoth: in this case B = S Jan 20 00:27:03 since its a broken autotools Jan 20 00:27:43 doesn't autotools.bbclass auto-run make clean in that case? i thought it did Jan 20 00:27:55 but same will happen with non autotooled packages Jan 20 00:28:03 yeah, autotools_preconfigure has code specifically to handle it Jan 20 00:28:13 doesnt kick in Jan 20 00:28:40 may be its due to externalsrc confusion Jan 20 00:28:50 since now the B = externalsrc locaiton of S Jan 20 00:29:37 not sure whats happening since I am more focussed on fixing the package to build then the infra Jan 20 00:29:40 for this case Jan 20 00:29:51 the package fbset shows same problem Jan 20 00:30:03 sounds like this doesnt' have anything to do with devtol or its workflow and is just a bug in use of externalsrc without B Jan 20 00:30:07 open a bug Jan 20 00:30:26 yes will do Jan 20 00:30:58 whew, think I finally got my auto relocating sdk bits working for those who don't use shar. just saves the relocated path into a file and uses that for the next relocation if it gets moved, and checks that on every source of the env setup script Jan 20 00:31:00 I think devtool just is utilizing the underneath facilities so you are right Jan 20 00:40:30 filed https://bugzilla.yoctoproject.org/show_bug.cgi?id=8950 Jan 20 00:40:31 Bug 8950: normal, Undecided, ---, richard.purdie, NEW , Clean operation not done with externalsrc when S = B Jan 20 01:12:03 khem: I'd anticipated problems changing machine in the case of machine-specific patches but I hadn't thought of this kind of issue **** ENDING LOGGING AT Wed Jan 20 02:59:59 2016