**** BEGIN LOGGING AT Tue Jul 14 02:59:58 2015 Jul 14 04:32:57 does the FILES_${PN} variable work for native packages? Jul 14 04:33:47 I'm having an issue where after do_install I got some files inside the image directory Jul 14 04:34:09 but then they never end up in sysroot-destdir Jul 14 04:34:45 native recipes aren't packaged at all. Jul 14 04:34:52 so packaging variables aren't going to do a whole lot Jul 14 04:34:52 I figured its the installed vs shipped issue, but I think for native packages it works a little bit different Jul 14 04:34:57 hmm Jul 14 04:35:13 nope, its probably the fact that only certain paths are copied from ${D} into the sysroot Jul 14 04:35:16 at a guess Jul 14 04:35:22 you got any ideas why I dont get thos files inside sysroot-destdir? Jul 14 04:35:30 see staging.bbclass, sysroot_stage_all & friends Jul 14 04:35:44 image/include... Jul 14 04:35:47 image/lib/// Jul 14 04:35:47 either you're installing to incorrect paths, or you're trying to add something to a custom path that isn't deployed by default Jul 14 04:35:49 ...* Jul 14 04:35:52 yeah, that won't do squat Jul 14 04:35:56 use our variables Jul 14 04:35:59 ${includedir} Jul 14 04:36:03 ${libdir} or ${base_libdir} Jul 14 04:36:05 etc Jul 14 04:36:22 so basically i screwed up during config Jul 14 04:36:24 include is relative to prefix, so it'll end up being image/usr/include, for example, not image/include Jul 14 04:36:42 not sure what you mean by config, but it sounds like do_install needs to be fixed to install to the correct places with our variables, yes Jul 14 04:37:12 because I didnt use /usr as prefix Jul 14 04:37:23 when running ./configure Jul 14 04:37:41 oh ok Jul 14 04:37:48 kergoth: thanks! Jul 14 04:37:53 i'll give that a try Jul 14 08:02:59 morning all Jul 14 08:07:22 morning Jul 14 08:16:03 Hello, I have a build error while building glibc for an sdk Jul 14 08:16:04 http://pastebin.com/DgjFJAG5 Jul 14 08:16:13 does anyone have an idea how to solve this ? Thnx! Jul 14 11:47:25 Where does yocto put its log files for a specific recipe build? Jul 14 11:58:04 raykinsella781: the logs are in ${WORKDIR}/temp, you can run bitbake -e |grep 'WORKDIR=' to locate it Jul 14 12:13:39 When a package has PACKAGECONFIG[experimental] = "--enable-experimental,--disable-experimental,", how can I from my config enable experimental? Jul 14 12:17:15 specifically, how can I enable experimental from my local.conf ? Jul 14 12:18:22 sveinse: try PACKAGECONFIG_append_pn- = " experimental" Jul 14 12:19:44 bboozzoo: Like this: PACKAGECONFIG_append_5.32-bluez5 = "experimental" ? Jul 14 12:20:05 sveinse: PACKAGECONFIG_append_pn-bluez5 = " experimental" Jul 14 12:20:58 note the space after " and before experimental, I always whether it's append or += that adds whitespace Jul 14 12:21:09 += adds whitespace Jul 14 12:21:50 where can I find the compilation output of bluez5 ? Jul 14 12:26:28 good day everyone Jul 14 12:26:56 could somebody tell me how to build backport kernel drivers as modules in yocto? Jul 14 12:28:57 sveinse: the output (as in after make install) should be in ${WORKDIR}/image Jul 14 12:29:43 bboozzoo: No, the bitmake logs from building bluez5. I'm looking for verifying that my experimental setting actually works Jul 14 12:29:51 *bitbake Jul 14 12:39:50 sveinse: clean and rebuild (bitbake -v bluez5) and look through logs, or look for EXTRA_OECONF in recipe env (bitbake -e ..) Jul 14 12:46:25 Ox4: that's not something someone can give you a definitive how-to guide on, it's going to depend entirely on what the driver is and what kernel version you're backporting to Jul 14 12:47:41 Ox4: as far as our build system goes, pretty much everything you need to know about building the kernel and/or external kernel modules is in the kernel development manual: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html Jul 14 13:29:18 bluelightning: I am working on external kernel 2.6.37 Jul 14 13:29:51 and a kernel dev which I am working with made some backports for wireless drivers Jul 14 13:31:52 Ox4: ok, so it sounds like you have a patch from them and you know want to apply it? Jul 14 13:32:43 bluelightning: actually already knew, thank you for the document Jul 14 13:33:23 bluelightning: I have another problem. I have a bunch of directories in git repository, but I want to fetch and work with only one. How can I do that? Jul 14 13:34:14 Ox4: there is an option to do that that you can specify on the SRC_URI entry, called subpath Jul 14 13:34:29 Ox4: which version of the build system are you using? Jul 14 13:36:00 bluelightning: I use master branch of yocto Jul 14 13:36:22 Ox4: ok, I just wanted to check if you had a fix that was made to that a few months ago Jul 14 13:37:12 there is a caveat however - subpath will unpack only the directory you specify, however it will not reduce what is actually fetched from the git server, it will still fetch the whole repository Jul 14 13:39:30 bluelightning: subpath=Core/backports/;user... is it ok? Jul 14 13:40:50 I would advise removing that trailing / Jul 14 13:41:00 but otherwise yes Jul 14 13:45:53 bluelightning: here is the skeleton of bb files for modules: http://dpaste.com/2WXT37B.txt Jul 14 13:46:41 bluelightning: and from the kernel developer I received the following howto: http://dpaste.com/3XH2QNA Jul 14 13:48:24 Ox4: I'm not actually a kernel person I'm afraid Jul 14 13:48:33 hm Jul 14 13:48:38 and you still should drop that trailing / from the subpath value Jul 14 13:48:54 ok, I will correct that string Jul 14 13:54:25 bluelightning: it seems yocto doesn't fetch the folder with modules :-( Jul 14 13:54:51 Ox4: how are you determining that? Jul 14 13:55:52 bluelightning: I don't see the fetched files Jul 14 13:56:04 Ox4: where are you looking? Jul 14 13:58:26 bluelightning: in build/tmp/work/myboard/wireless-mod/0.1-r0 Jul 14 13:58:45 bluelightning: also I appended -vD flags to bitbake Jul 14 13:59:17 AFAIK, you should see a directory called backports there Jul 14 14:00:48 bluelightning: find -name 'backports' returns nothing Jul 14 14:07:50 Ox4: I just tested this trivial recipe here, and it unpacks to the matchbox2 subdirectory where I would expect it to: http://pastebin.com/YtEJv6FC Jul 14 14:10:12 so I'm a bit confused as to what might be happening in your case Jul 14 14:13:30 bluelightning: Sato is in the root of the repo? Jul 14 14:14:06 Ox4: yep: http://git.yoctoproject.org/cgit/cgit.cgi/matchbox-sato/tree/ Jul 14 14:26:40 bluelightning: fixed, I've forgotten to edit S variable. Thank you for the support Jul 14 14:27:02 so, the files were there then Jul 14 14:32:27 bluelightning: yes Jul 14 14:33:00 who has the permissions to make repository private on github.com/openembedded? Jul 14 14:33:20 We missed our date for oe-core/meta-oe repos removal on 4th July Jul 14 14:38:14 JaMa: I don't, FWIW Jul 14 14:38:21 khem may Jul 14 14:49:21 I'm attempting to move my project from Daisy (1.6) to Fido (1.8) and having problems with the linux kernel build. Why is the kernel now split between work & work-shared? Jul 14 14:49:39 My old kernel recipe is broken. Jul 14 14:51:14 nm it is all in tmp/work-shared, but why? Jul 14 14:52:20 T0mW: lots of different recipes want the kernel source, so that saves extracting it over and over Jul 14 14:52:27 (same rationale for gcc being in work-shared) Jul 14 14:52:32 yeah, okay. Jul 14 14:52:52 It built, but now I'm trying to find where the object files are. Jul 14 14:53:13 T0mW: if you haven't seen it: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#moving-to-the-yocto-project-1.8-release Jul 14 14:53:24 there is a very short bit in there about what needs changing in kernel recipes Jul 14 14:53:40 bluelightning: thanks, was looking for a doc about the new strategy Jul 14 14:54:17 we always write a migration section in the manual for new releases, so it's a good reference when you're upgrading Jul 14 15:00:27 hey all Jul 14 15:03:28 <[Sno]> rburton: just because I didn't get an answer to "how to submit (perl) patches" - writing a mail and appending some patches to it is fine? Jul 14 15:03:45 <[Sno]> or do they have to be inline as git send-email does? Jul 14 15:04:09 git-send-email is preferred as its easy for everyone to read, review, and apply Jul 14 15:04:26 configuring it is mostly trivial Jul 14 15:04:29 <[Sno]> but difficult to send Jul 14 15:04:57 <[Sno]> well, how to configure without storing (or re-entering) my gmail password? Jul 14 15:05:19 setup a local mta if that bothers you Jul 14 15:05:50 most linux distros can setup a relaying smtp that only listens to localhost in matter of seconds Jul 14 15:06:37 <[Sno]> this mta has to know the credentials for the gmail account either Jul 14 15:07:07 <[Sno]> it remains that the mails must be sent from my desktop, which is trusty enough Jul 14 15:07:16 <[Sno]> my desktop is MacOS X Jul 14 15:07:32 the mta can send directly to google Jul 14 15:07:48 or via your isp, or something. Jul 14 15:08:11 personally i write my credentials in the file and hope if someone steals my laptop the last thing they're interested in is my google password Jul 14 15:08:23 <[Sno]> you mean, mta sends to my gmail address, and I forward it? Jul 14 15:08:38 i just re-input my google password when i run send-email, not that terrible, not like i'm emailing patches 4 times a day Jul 14 15:08:55 depends on your setup. some of my machines have MTAs that forward to my ISP's relay Jul 14 15:09:06 <[Sno]> thing is, google is connected to so many other online services meanwhile, it's a desaster when one get's my google credentials Jul 14 15:10:07 just store the 2fa app password for send-email in 1password with everything else, copy/paste when i send-email Jul 14 15:10:09 * kergoth shrugs Jul 14 15:10:34 and with that being a 2fa password, its trivial to revoke if someone gets that one, its not the same as the regular pass Jul 14 15:10:36 <[Sno]> kergoth: I mean, if contributions are welcome, the way to contribute should be much easier than setting up an mta or trusting send-email doesn't "cache " the credentials somewhere Jul 14 15:10:58 if you think git is caching your credentials, you might as well give up using source control at all and put your crap in a zip file Jul 14 15:11:03 if you don't trust your tools, don't use them Jul 14 15:11:21 <[Sno]> well, ok - I don't use git send-email ^^ Jul 14 15:11:50 you're welcome to manually export your patches from git and somehow get them in emails, the rest of us will use what works and isn't a pain in the ass Jul 14 15:12:15 the problem is attaching patches to mails makes it very tricky to review them Jul 14 15:12:27 as you can't just write a comment after a line anymore Jul 14 15:12:38 <[Sno]> rburton: that's why I chose the github way - you can comment there if you want Jul 14 15:12:41 yeah, they really need to be inline Jul 14 15:12:58 yocto doesn't use github, the process is email, and that won't be changing anytime soon Jul 14 15:13:08 same with the underlying oe projects Jul 14 15:13:10 <[Sno]> well, then I keep my stuff Jul 14 15:13:13 <[Sno]> fine for me Jul 14 15:13:20 you're really that lazy? Jul 14 15:13:22 that's pretty sad Jul 14 15:13:28 <[Sno]> it's not lazy! Jul 14 15:13:30 * kergoth gets back to work Jul 14 15:13:34 <[Sno]> I do not trust git send-email Jul 14 15:13:37 ha Jul 14 15:13:40 * zeddii is with kergoth Jul 14 15:13:58 the thousands and thousands of patches and sends with it have never caused me any trouble. Jul 14 15:14:05 * zeddii also goes back to work. Jul 14 15:14:07 guys, can I add my own function in the bb file? Jul 14 15:14:48 Ox4: not sure exactly what you mean, but lets go with "yes" Jul 14 15:14:51 also, thousands of kernel devs use it, and its code is open and honestly fairly trivial. if you're that paranoid, read the send-email code and get on with your day Jul 14 15:15:20 kergoth: i'd be worried about apple injecting backdoors into its smtp implementations for the nsa Jul 14 15:15:47 <[Sno]> kergoth: and much many others use rt gnats and are happy with that Jul 14 15:15:57 <[Sno]> and even more send pull-requests via githun Jul 14 15:16:07 <[Sno]> what do you want to say? Jul 14 15:16:32 honestly, your paranoia is not our problem. either use it or don't Jul 14 15:17:02 <[Sno]> that's true - and I'm happy to push my local changes on my github fork whether you benefit from it or not Jul 14 15:17:09 <[Sno]> fair enough Jul 14 15:45:08 guys, I have git repo for needed wireless firmware binaries, how to install it to the image? Jul 14 15:48:31 you'll need to create a recipe for it which has that repo url in SRC_URI and which installs them to the appropriate place in do_install Jul 14 15:48:40 much like the existing firmware-wireless recipe Jul 14 16:09:51 kergoth: and append MACHINE_EXTRA_RDEPENDS += "firmware" to machine.conf file? Jul 14 16:10:30 that'd do, yeah Jul 14 16:12:10 btw, is there a way to see the list of packages which will be installed to image? Jul 14 16:12:15 damn, my recipetool_appendsrcfile test is hanging at the get_bb_var() :( Jul 14 16:12:56 Ox4: not directly. you can see what packages will be installed by examining PACKAGE_INSTALL in that recipe (e.g. bitbake -e yourimage), but obviously those packages will depend on others that aren't listed there Jul 14 16:13:10 but, after you create the image, a manifest is emitted so you can see wht was installed Jul 14 16:13:52 kergoth: thank you Jul 14 17:05:56 what are the typical workflows for getting images built with poky actually onto boards? Jul 14 17:06:31 i'm having troubel finding any concrete info in the manual about how to actually flash or otherwise install an image onto a baord Jul 14 17:07:08 that's completely dependent on the hardware in question. check the readme and whatnot in the bsp layer Jul 14 17:29:56 gahhh Jul 14 17:38:20 well, that was fun. Once I finally figured out the the config_prepend to 'make oldconfig' was no longer needed, the kernel build moved beyond 'do_configure'. Jul 14 17:38:57 It builds now. Jul 14 17:40:09 hmm, that should never have been needed, cml1.bbclass automatically runs that Jul 14 17:40:10 * kergoth shrugs Jul 14 17:41:01 yeah, I'm moving up from 1.6 (Daisy) Jul 14 17:41:26 my custom recipe for kernel build.. Jul 14 17:41:56 What's the bitbake syntax for referencing to a variable like `PACKAGECONFIG[dri3]` in a specific package (it doesn't appear `PACKAGECONFIG_pn-mesa[dri3]` works) Jul 14 17:42:03 oldconfig has been run for kernels automatically since we first wrote kernel.bbclass. guessing that must have been a workaround Jul 14 17:42:23 fishey1: why would you want to do that? Jul 14 17:42:31 what are you trying to accomplish, i should say Jul 14 17:42:46 so I can fix a bug in the mesa bitbake file without creating yet another bbappend Jul 14 17:42:49 kergoth: ^ Jul 14 17:43:04 sounds like what you want is a bbappend. Jul 14 17:43:12 Though in general I still want to know how to do it. Jul 14 17:43:18 you can't combine overrides with flags, not doable. you'd have to use anonymous python, which is uglier than the append would be Jul 14 17:43:38 aw Jul 14 18:54:22 gah, this intermittent parse hang is driving me nuts Jul 14 18:54:41 * kergoth looks into running python script introspection tools Jul 14 20:12:31 kergoth: the one at 96% or so? Jul 14 20:12:43 * fishey1 also has been in pain for many months Jul 14 20:13:08 I end up needing to manually kill bitbake from htop and then retry Jul 14 20:18:15 fishey1: thats wha ti keep doing too, need to diagnose Jul 14 20:20:27 keeps blockin gprogress on my tasks Jul 14 20:33:44 grr "cannot find -lgcc" (u-boot) Jul 14 22:13:36 does anyone know what the syntax is for SRC_URI to NOT unpack the tarfile? Jul 14 23:00:07 aehs291: wow! maybe rename it foo.tar.gz -> foo.not-a-tar-gz Jul 14 23:00:08 :-) Jul 14 23:01:30 aehs291: http://www.yoctoproject.org/docs/1.6/bitbake-user-manual/bitbake-user-manual.html#bb-the-unpack Jul 14 23:01:40 aehs291: add ";unpack=0", maybe? Jul 15 01:16:24 gabrbedd: thanks! Jul 15 01:16:33 gabrbedd: yeah that ";" is waht I was looking for **** ENDING LOGGING AT Wed Jul 15 02:59:58 2015