**** BEGIN LOGGING AT Tue Feb 24 02:59:58 2015 Feb 24 04:56:15 where can i see the definition of do_patch Feb 24 05:12:16 chankit: depends if you want the source or just want to see what its doing, if you want to see what its doing 'bitbake -e > temp', open temp and search for 'do_patch()' Feb 24 06:16:40 isn't there a do_patch log? Feb 24 06:18:20 work/blah/blah/temp/log.do_patch Feb 24 06:19:26 nerdboy: i think there is also a run.do_patch, but i thought that was some python that calls into bitbake Feb 24 06:20:15 there should be both logs and scripts Feb 24 06:23:04 its python Feb 24 06:23:08 so no logs Feb 24 06:23:16 unless something goes wrong Feb 24 06:25:47 May I know, yocto build engine is supported by jenkins? Feb 24 06:43:05 kanupatar: it is in a way Feb 24 06:43:33 its agnostic to autobuilders Feb 24 06:45:22 khem`: means? Feb 24 06:45:56 mean you can use buildbot jenkins, your own scripts Feb 24 06:45:59 doesnt matter Feb 24 06:47:16 i would use the bash script window in jenkins to start... Feb 24 06:47:41 unless somebody made a plugin maybe Feb 24 07:26:22 how do I set yocto to run kernel 3.19 in http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/ ? I tried setting PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev" in local.conf but it only checks out 3.17 Feb 24 08:09:50 how do I set yocto to run kernel 3.19 in http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/ ? I tried setting PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev" in local.conf but it only checks out 3.17 Feb 24 08:34:02 Morning gentlemen Feb 24 08:34:50 If someone has some time to spare, I have a question about how to add a custom driver to my yocto image Feb 24 08:36:47 I think I have figured out how to add a hello world program, using the yocto build flow (not 100% sure it is correct though) but it seems that it's a different approach when it comes to drivers. Feb 24 08:38:53 Anyone knows what steps I should take to accomplish this? Like good documents to read or available examples? Feb 24 08:41:25 hmm, is EFI_PROVIDER more of an image or distro thing? Feb 24 08:53:01 BlauskaerM: can i assume you mean kernel driver? Feb 24 08:53:18 nerdboy: Yeah Feb 24 08:54:05 http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html#working-with-out-of-tree-modules Feb 24 08:54:46 docs are your friend, at least in the better open source projects Feb 24 08:54:58 shocking, i know... Feb 24 08:55:11 nerdboy: Looks good, can start with this and come back later :) Feb 24 08:55:39 nerdboy: but i think when it comes to scc and cfg files that won't work Feb 24 08:56:04 we saw yesterday some conversation here about that Feb 24 08:56:32 * nerdboy usually breaks the rules with kernel sources anyway Feb 24 08:56:59 can't get in trouble pointing at the official docs... Feb 24 08:57:03 better to do some patch and include this to the recipe-kernel/linxu* Feb 24 08:57:36 the linux-yocto kernel is the current "official" way to do it, but not the only way Feb 24 08:57:55 older model recipes are still there Feb 24 08:58:12 can also go back to previous doc releases for those Feb 24 08:58:30 sometimes you hack your own fix Feb 24 08:59:27 mostly i deploy manual-built kernels right now, so i probably can't be much help unless it becomes my problem at some point Feb 24 09:00:00 what i need for project isn't available in yocto kernels right now unless i make my own Feb 24 09:00:26 which i eventually will for beaglebone Feb 24 09:00:45 interesting, would have thought that getting "ConvertPages: failed to find range ..." from gummiboot is a fatal error, but after that it happily chugs along booting the kernel :D Feb 24 09:01:27 ericbutters: what is the machine in this case? Feb 24 09:02:07 and you are always free to bbappend the kernel recipe for whatever... Feb 24 09:03:12 nerdboy: it was some kind of sierra wireless thing.. i only read it here, where the question was similar to what BlauskaerM asked.. It was not my problem.. it was reported by someone else Feb 24 09:04:11 but anyway i think using a patch and scc/cfg files located in recipes-kernel/* is a good way Feb 24 09:04:25 custom firmware maybe? Feb 24 09:04:42 the config thing is the documented way Feb 24 09:04:54 older maybe, but still works Feb 24 09:05:11 some simple patch that provides the kernel driver and scc/cfg that brings the kernel configuration Feb 24 09:06:06 https://www.yoctoproject.org/training/kernel-lab Feb 24 09:06:22 that's 1.3/1/4 but still valid Feb 24 09:06:44 how do I set yocto to run kernel 3.19 in http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/ ? I tried setting PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-dev" in local.conf but it only checks out 3.17 Feb 24 09:06:53 ericbutters: it's in the lab Feb 24 09:07:23 chankit: did you also add preferred_version? Feb 24 09:07:56 nerdboy: no. how do I add it? Feb 24 09:08:13 is it something like PREFERRED_VERSION=3.19? Feb 24 09:09:32 that should work, but PREFERRED_VERSION_linux-mainline = "3.19%" is better Feb 24 09:10:05 sorry, paste error Feb 24 09:10:15 linux-yocto-dev in your case Feb 24 09:11:11 and spaces count Feb 24 09:11:53 nerdboy: Is the "%" symbol a wildcard? Feb 24 09:12:03 * nerdboy tired after 4 days conference and travel Feb 24 09:12:08 yup Feb 24 09:12:24 Noted Feb 24 09:13:19 if you want, you can check yocto crash course slides and see if they help Feb 24 09:13:37 we didn't get a short course, just an hour talk Feb 24 09:13:52 nerdboy: doesn't do good.. I got " preferred version 3.19% of linux-yocto-dev not available (for item virtual/kernel)" Feb 24 09:14:28 it has to be there Feb 24 09:14:41 the version needs to exist rather Feb 24 09:14:46 nerdboy: Have looked through them but it didn't really give me any clarity unfortunately =/ Feb 24 09:14:53 do a find in recipe tree Feb 24 09:15:00 https://github.com/VCTLabs/yocto-crash-course/tree/master/bin Feb 24 09:15:09 BlauskaerM: that one Feb 24 09:16:05 chankit: what is latest yocto-dev in poky master? Feb 24 09:16:32 * nerdboy flossing Feb 24 09:16:34 nerdboy: not sure but according to http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/ it has 3.19 Feb 24 09:16:54 nerdboy: Oh, haven't seen these before. Thanks :) Feb 24 09:17:15 Thought you meant the lab pdf Feb 24 09:17:45 that summarizes/explains the lab a little bit Feb 24 09:17:53 at least i hope it does... Feb 24 09:18:34 plus other stuff Feb 24 09:19:59 chankit: what machine? Feb 24 09:20:10 you might need to help it a little Feb 24 09:21:31 nerdboy: standard/common-pc-64/base Feb 24 09:21:43 grep COMPATIBLE_MACHINE Feb 24 09:22:07 from where should I grep that? Feb 24 09:22:08 might only support qemu machines Feb 24 09:22:30 you could set COMPATIBLE_MACHINE = "your machine" Feb 24 09:22:47 might need to set commit hash too Feb 24 09:23:09 in poky dir grep -R Feb 24 09:26:23 nerdboy: I got quite a lot of output ..what u looking for? Feb 24 09:27:25 in order to bump the kernel your machine must be supported by 3.19 recipe Feb 24 09:27:46 you can override with the above setting Feb 24 09:28:31 it's actually in the handout notes i just pointed at Feb 24 09:28:44 https://github.com/VCTLabs/yocto-crash-course/tree/master/bin Feb 24 09:29:22 * nerdboy needs another ploy so he can finish flossing/brushing... Feb 24 09:30:03 so I should set COMPATIBLE_MACHINE_linux-dev_yocto = "my machine" ? Feb 24 09:32:29 no, actually COMPATIBLE_MACHINE_machine = "machine" Feb 24 09:32:41 i know, kinda weird but... Feb 24 09:32:53 you're overriding it Feb 24 09:33:34 as in COMPATIBLE_MACHINE_beaglebone = "beaglebone" Feb 24 09:33:48 nerdboy: so I put that in local.conf right? Feb 24 09:34:34 yup that shoudl work Feb 24 09:34:57 morning all Feb 24 09:35:03 assuming you have a beaglebone or change it to your machine Feb 24 09:35:12 bluelightning: morning for you Feb 24 09:35:29 i'm still trying to brush my teeth... Feb 24 09:36:04 top-o-the-morning for you i hope? Feb 24 09:37:16 nerdboy: sorry to ruin your morning but that approach is negative Feb 24 09:37:59 nerdboy: I set my machine to genericx86-64 so there should be a 3.19 kernel available? Feb 24 09:38:29 sorry..not an expert in navigating linux-dev-yocto page Feb 24 09:39:18 and I set the compatible machine variable by COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64" Feb 24 09:39:25 so not sure if I'm doing it right Feb 24 09:42:35 nerdboy: I'm heading off now so I will check with you again later if you don't mind Feb 24 09:43:27 whatever your actual MACHINE is, use that Feb 24 09:43:56 and you should set it in local.conf with = Feb 24 09:44:28 i know this works because i just did it with beaglebone and linux-yocto Feb 24 09:44:35 trust me... Feb 24 09:45:12 on master in my case, but should also work on release branches Feb 24 11:18:27 Hi, can anyone help me to enable /proc on my device?? Feb 24 11:19:12 I have enabled the proc filesystem through the kernel configuration, but when i do ifconfig i get an error : "Warning: cannot open /proc/net/dev (No such file or directory). Limited output." Feb 24 11:24:21 have you mounted it? Feb 24 11:24:30 (the default fstab mounts it) Feb 24 13:13:59 Hmm.... Still can't get the module over to my image. Feb 24 13:14:32 Not 100 percent sure that it's getting compiled however Feb 24 13:15:32 BlauskaerM: remove some ";" -- that sould throw an error while compiling Feb 24 13:15:50 I followed the "instructions" from the manual (http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html#incorporating-out-of-tree-modules) but there is something that I'm missing Feb 24 13:15:54 ericbutters: Will try that Feb 24 13:16:21 BlauskaerM: does your module need a kernel confiuration (CONFIG_)? Feb 24 13:17:02 ericbutters: No I dont think so? Its just a simple module that should print some text when it is loaded Feb 24 13:17:20 So nothing complicated Feb 24 13:22:39 I really need a better computer to build on -_- Feb 24 13:37:11 Hmm, that was good news (and also bad) Feb 24 13:37:17 I removed some ; from the module source code but I didn't get any errors while running bitbake? Feb 24 13:37:55 bitbake doesn't know that you've changed the source and won't rebuild everything just in case Feb 24 13:38:20 kk Feb 24 13:38:32 bitbake myrecipe -C compile will force it to recompile the recipe Feb 24 13:38:32 Is there a command that I can use to clean? Feb 24 13:38:42 Ahh Feb 24 13:38:51 2 sec Feb 24 13:39:15 then rebuild the image or install the packages or whatever you want Feb 24 13:40:27 There we go Feb 24 13:40:29 Got the error Feb 24 13:41:00 So every time I change the code in the module, I need to recompile it with bitbake myrecipe -C compile? Feb 24 13:41:22 And then rebuild the image? Feb 24 13:41:46 yeah, but you can just copy the package with the changes in to the image and install that - much shorter cycle Feb 24 13:42:53 So after I have compiled the module I can just copy the .ko file from the tmp dir to the image? Feb 24 13:43:33 yeah Feb 24 13:43:59 Noted Feb 24 13:45:02 Will try to fix the module file (reinsert the ;) and then compile it again so see if I can find any .ko file in the tmp dir Feb 24 13:45:14 Because that is where all end up right? Feb 24 13:46:02 tmp/work/[machine]/[recipe]/deploy-* has the packages generated Feb 24 13:46:20 or packages-split has the packages before they were packaged up Feb 24 13:47:18 Will check that. Waiting for bitbake to terminate :P Feb 24 13:48:50 Found a directory for the module but it does not contain a deply dir? Feb 24 13:49:03 deploy* Feb 24 13:51:12 Maybe that is because the compile failed? Feb 24 14:17:54 probably, if the compile failed then it can't distribute anything Feb 24 14:29:58 rburton: Sounds like it. I appeared after I fixed the source file and recompiled :) Feb 24 14:33:29 hi guys.. while developing, should i clear out the tmp/cache dirs as i modify recipes in regards to making feeds? specifically, im wondering if the package-index recipe would hold multiple versions of a package for me, so i could install v1.0 of my package even if v1.1 was available.. Feb 24 14:34:12 or another way.. how do i ensure that Package.gz index files contain all the packages available on the feed? Feb 24 14:37:27 dgm816: bitbake package-index will update the feed immediately Feb 24 14:38:06 dgm816: however, note that when a newer version of a recipe is built and packaged, the older package is deleted Feb 24 14:38:55 bluelightning, ah, ok.. so i would need 2 feeds say one for unstable/devel and the other feed stable.. to deploy for testing? Feb 24 14:39:22 yes, you need to manage your own feeds to get that Feb 24 15:58:07 YPTM: Ready-Access Number: 8007302996/9139049836 Access Code: 2705751# Feb 24 15:58:41 YPTM: Stephen Joined Feb 24 15:58:55 YPTM: Saul is on Feb 24 15:59:01 YPTM: Joe Mac here. Feb 24 16:00:26 YPTM: Mark here Feb 24 16:00:26 YPTM: Cristian joined Feb 24 16:01:59 YPTM: AlexVaduva here Feb 24 16:02:26 YPTM: Paul Eggleton is on Feb 24 16:02:27 Richard joined Feb 24 16:03:14 Ross joined Feb 24 16:07:36 I'm assuming nobody heard me speaking... Feb 24 16:10:11 (something went weird with the bridge, but since rejoining it seems fine) Feb 24 16:11:30 bluelightning: the upgrade was stalling on a circular dependency in util-linux, i have a patch that drops the systemd dep from util-linux. i'll verify it is mostly harmless and post if so Feb 24 16:11:40 ok, cool, thanks Feb 24 16:12:54 I looked them over quickly.. looks intersting Feb 24 16:13:52 khem: you added distutils-tools.bbclass "for python3" but nothing seems to include it. can it be deleted or am i being blind? Feb 24 16:15:31 I need to jog my memory down the lane Feb 24 16:15:55 thanks :) Feb 24 16:18:10 does anyone know distutils well? Feb 24 16:20:25 YPTM is over. Feb 24 16:30:25 rburton: ok, it was a jnpr thing, there were tools packages which were slightly different Feb 24 16:30:42 some of them internal but some were external Feb 24 16:30:54 I dont remeber which were all external Feb 24 16:31:03 but I never got around to contribute them Feb 24 16:31:19 as of now it looks dead code Feb 24 16:31:26 ok,i'll blast it away Feb 24 16:31:27 thanks khem Feb 24 16:31:58 khem: an opinion on http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/distutils&id=4d15f590e8aeedf2e7c03cdaf02dd57ccbff5ef5 would be helpful too :) Feb 24 16:32:16 for a basic package it appears to work… just kicked a build of all of oe-core's python to see Feb 24 16:32:43 its a bit horrid in that you need to do "build —build-base install" to do an install Feb 24 16:32:53 hi Feb 24 16:35:19 rburton: looks ok Feb 24 16:35:31 you got the order of build-base and install right Feb 24 16:35:35 ok, needs to do a cd ${S} first Feb 24 16:35:40 IIRC there were issues when they were interchanged on cmdline in order Feb 24 16:36:13 yeah build-base is an option for build Feb 24 16:36:17 discovered that ten minutes ago :) Feb 24 16:36:31 let m find that bug Feb 24 16:36:39 here http://bugs.python.org/issue1011113 Feb 24 16:37:09 are we carrying these patches ? Feb 24 16:37:18 if not then I would suggest to backport them Feb 24 17:07:56 well distutils —build-base is nonsense isnt it Feb 24 17:11:39 i have 2 packages being built.. how to i specify to opkg that only one ipk can be installed? either one is fine (personal preference, provide same functionality), but i need to be sure only one or the other is installed.. can i do this from my bitbake recipe? anyone know of an example to look at? Feb 24 17:12:14 dgm816: RCONFLICTS_packagename1 = "packagename2" Feb 24 17:15:05 Guys, i am having trouble with Dependency Loop, after updating master repository. What is this ? Feb 24 17:16:40 realBigfoot: what is the dependency loop you are seeing exactly? Feb 24 17:17:15 from a recipe that i have changed for test proposal Feb 24 17:17:17 bluelightning, thank you again! Feb 24 17:17:50 the weird thing is that it was working quite fine Feb 24 17:18:31 realBigfoot: in general a dependency loop means that recipe A depends on recipe B depends on recipe A and therefore there is no way to satisfy the dependency relationship Feb 24 17:18:45 realBigfoot: without specifics I can't really advise further Feb 24 17:19:01 bluelightning, at runtime i would have to do "opkg remove package1; opkg install package2" to switch conflicting packages from one to another? Feb 24 17:19:04 bluelightning, I see, this is enough :) Feb 24 17:19:05 thanks Feb 24 17:19:19 dgm816: yes Feb 24 17:19:30 thank you Feb 24 17:21:55 bluelightning, do you know how to increase debug level to see more about where is the dependency loop ? I've tried with bitbake -D option but it was the same Feb 24 17:24:35 when is the error coming up exactly? Feb 24 17:25:22 bluelightning, when compiling systemd Feb 24 17:25:56 more specifically? i.e. in the middle of a task? before the build even gets started? Feb 24 17:27:03 bluelightning, before the build gets started Feb 24 17:27:41 helps if you say what the loop is… Feb 24 17:28:28 rburton, this is what i am trying to figure out... :( Feb 24 17:28:43 well what is the output of bitbake? Feb 24 17:28:52 rburton, ERROR: Unbuildable tasks were found. Feb 24 17:28:53 These are usually caused by circular dependencies and any circular dependency chains found will be printed below. Increase the debug level to see a list of unbuildable tasks. Feb 24 17:30:08 looking at the code, it reports the dependency loop as far as I can tell... Feb 24 17:30:52 can't be a dependency loop then i guess Feb 24 17:31:48 realBigfoot: does it say "Identifying dependency loops" after that ? Feb 24 17:32:58 bluelightning, sorry the delay i was pasting it here we go: Feb 24 17:33:00 ERROR: Feb 24 17:33:00 Dependency loop #1 found: Feb 24 17:33:00 Task 452 (/media/project/yocto/poky/meta/recipes-core/systemd/systemd_218.bb, do_packagedata) (dependent Tasks ['systemd, do_package']) Feb 24 17:33:01 Task 927 (/media/project/yocto/poky/meta/recipes-core/util-linux/util-linux_2.25.2.bb, do_package) (dependent Tasks ['pseudo, do_populate_sysroot', 'gcc-runtime, do_packagedata', 'rpm, do_populate_sysroot', 'glibc, do_packagedata', 'systemd, do_packagedata', 'util-linux, do_install', 'zlib, do_packagedata', 'file, do_populate_sysroot', 'libtool-cross, do_packagedata', 'opkg-utils, do_packagedata', 'ncurses, do_packagedata']) Feb 24 17:33:03 Task 924 (/media/project/yocto/poky/meta/recipes-core/util-linux/util-linux_2.25.2.bb, do_packagedata) (dependent Tasks ['util-linux, do_package']) Feb 24 17:33:06 Task 455 (/media/project/yocto/poky/meta/recipes-core/systemd/systemd_218.bb, do_package) (dependent Tasks ['pseudo, do_populate_sysroot', 'libcgroup, do_packagedata', 'libtool-cross, do_packagedata', 'util-linux, do_packagedata', 'libgcrypt, do_packagedata', 'glibc, do_packagedata', 'curl, do_packagedata', 'kmod, do_packagedata', 'opkg-utils, do_packagedata', 'systemd, do_install_ptest_base', 'systemd, do_install', 'initscripts, do_packagedata', Feb 24 17:33:11 'gcc-runtime, do_packagedata', 'libidn, do_packagedata', 'glib-2.0, do_packagedata', 'acl, do_packagedata', 'xz, do_packagedata', 'lz4, do_packagedata', 'rpm, do_populate_sysroot', 'readline, do_packagedata', 'file, do_populate_sysroot', 'dbus, do_packagedata', 'libcap, do_packagedata']) Feb 24 17:33:26 realBigfoot: please use pastebin next time Feb 24 17:33:32 sorry Feb 24 17:34:58 bluelightning: did you get all the donuts? Feb 24 17:35:12 nerdboy: not even one :p Feb 24 17:35:43 that's poopy Feb 24 17:35:50 bluelightning, rburton do you know what could be the problem ? or any clue what it says ? Feb 24 17:36:05 realBigfoot: have you applied a systemd 218 upgrade? that's not in master... Feb 24 17:36:46 yeah, that's what i was going to say Feb 24 17:36:59 bluelightning, i have changed... something like I said before.... but it was working, I would sent it to you after i have finished Feb 24 17:37:01 bluelightning: going to ELC maybe? Feb 24 17:37:31 nerdboy: I think so yes Feb 24 17:38:43 realBigfoot: you've managed to add a circular dependency betwen util-linux and systemd Feb 24 17:39:01 rbuton that makes sense :) Feb 24 17:39:18 realBigfoot: which is why khem's series upgrading to 218 splits util-linux in half, and why i'm just cleaning up another series that disables systemd support in util-linux Feb 24 17:39:24 bluelightning: good, me too Feb 24 17:39:50 bluelightning: old speckled hen at a place down the street Feb 24 17:40:00 * nerdboy hopes he's still there Feb 24 17:41:01 * nerdboy working towards elc slide deadline Feb 24 17:42:13 rburton, thanks! It was the perfect tip.. it worked perfect Feb 24 17:42:24 s/perfect/perfectly/ Feb 24 17:44:00 people seemed to like yocto crash course talk at scale Feb 24 17:47:37 * nerdboy frowns at the meeting alarm Feb 24 17:50:51 Hi! Potential Yocto newbie here. I want to learn how to cross compile SW packages for BeagleBone running Angstrom 2012.12 so that I could install .ipk packages which are not readily available through opkg. Yocto (Poky) and BitBake came up a lot when searching the web. But always as a build system for complete Linux distributions. I only need to build a specific package . Is Yocto Project the right way to go or would you recommend an a Feb 24 18:13:02 Casper_: your message was cut off after "would you recommand an a" Feb 24 18:16:09 neverpanic: Was it indeed? Strange. I can see the whole message. Thanks for letting me know. The message goes on like this: "would you recommend an alternative approach? Thanks." Feb 24 18:16:39 Casper_: IRC has a maximum line length; the server truncates the message. Feb 24 18:17:48 bitbake can build .ipks. I'm not sure how they'd do compatibility-wise to your existing system, but if you use the same version or use an SDK you should be able to build a working package Feb 24 18:18:44 * kergoth likes irc clients that break up long messages automatically :) Feb 24 18:20:57 how would i list a recipe in a image recipe to be built, but not necessarily installed in the image? i can use DEPENDS (fake a build time depend) but that seems hacky Feb 24 18:21:46 dgm816: EXTRA_IMAGEDEPENDS += "..." Feb 24 18:22:45 ok, i saw that.. i thought that was only for bootloaders and such.. Feb 24 18:23:03 i guess that will make ipk's and just not install them within the image? Feb 24 18:26:10 dgm816: what are you trying to do exactly? Feb 24 18:27:03 i want to build package1 and package2.. but only 1 should be installed.. however, i want to put them both up on the feeds.. so i can 'opkg remove packag1; opkg install package2' if that one is preferred.. Feb 24 18:27:12 it relates to my earlier question really.. Feb 24 18:27:58 correction, only one installed in the image at a time.. Feb 24 18:29:37 ok, well in that case I would have to assume it's not the only package you want to be available alongside the image Feb 24 18:30:00 in which case, you should consider creating a meta recipe which depends on the other recipes you want packaged but not installed Feb 24 18:30:26 (basically just create a recipe that contains "inherit meta" and DEPENDS on all of the things that should build when you build it) Feb 24 18:31:45 neverpanic: you would want to build at least the metatoolchain target for the release on your beaglebone Feb 24 18:32:06 bluelightning, that sounds good.. i'll proceed that way.. thank you.. Feb 24 18:32:45 not sure what the image is, but ideally you can "bitbake image_name -c populate_sdk" Feb 24 18:32:53 nerdboy: you meant Casper_, right? Feb 24 18:33:13 yup Feb 24 18:33:24 scroll fail... Feb 24 18:33:39 bbl Feb 24 18:34:03 bluelightning, so i will create a meta-pkg-name which depends on my image recipe.. i'd then issue 'bitbake meta-pkg-name' and it should take care to build the image as well? Feb 24 18:34:50 and add "DEPENDS += 'package1 package2'" to the meta recipe Feb 24 18:35:30 Casper_: ^^ meta-toolchain will build you a toolchain with minimal sysroot, the other one is full sdk but needs an image target Feb 24 18:38:17 dgn816: You would actually want to use "RDEPENDS" for the packages, "DEPENDS" essentially means do_populate_sysroot() has ran for those recipes, "RDEPENDS" would be if you need the packaging routine to have ran Feb 24 18:39:34 dgm816: Whoops I mistyped your id ^^ applies to you :) Feb 24 18:40:14 rewitt, thank you.. i'll use RDEPENDS Feb 24 18:44:07 neverpanic & nerdboy: Thanks for your inputs. Not being familiar with Yocto the terms "full sdk" and "meta-toolchain" are unclear to me in the context of the Poky build system. I see I have some more research to do. However from your writing I see that using the Yocto project could be the way to go. You do not see a more suitable/easier solution? Feb 24 18:48:12 read the yocto quick start yet? Feb 24 18:48:38 toolchain is your cross-compiler/libc/headers Feb 24 18:49:30 "bitbake metatoochain" will make you a basic cross-compile setup with env script, etc Feb 24 18:49:53 er, meta-toolchain even Feb 24 18:52:56 Casper_: maybe look at this and use the reference links => https://github.com/VCTLabs/yocto-crash-course/blob/master/bin/yocto_scale_handout.pdf Feb 24 19:02:55 nerdboy: Thanks for the link. I will have a look at the pdf and at the Yocto docs, keeping an eye out for what you mentioned. I think I got my answer. Yocto is the way to go. Feb 24 19:14:18 hi, how can I avoid Yocto automatically putting my .so files into the -dev package? Feb 24 19:14:24 I want to get them into my ${PN} Feb 24 19:17:01 lpapp: you could do it like this Feb 24 19:17:01 FILES_SOLIBSDEV = "" Feb 24 19:17:03 SOLIBS = ".so" Feb 24 19:17:08 INSANE_SKIP_${PN} += "dev-so" Feb 24 19:17:24 but I would rather fix the component to generate versioned libs Feb 24 19:17:37 it has other benefits along with clean recipe Feb 24 19:18:01 but some thirdparty libs cant be done that way so I do understand that usecase Feb 24 19:18:22 well, I would rather not do big changes now in the pressure of release ;-) Feb 24 19:18:42 will the aforementioned idea work with dylan? Feb 24 19:18:59 it is not thirdparty lib, by the way, it is our own lib which I and my colleagues develop. Feb 24 19:19:09 we can do cosmethic changes later, that is fine. Feb 24 19:20:47 lpapp: ship it! Feb 24 19:20:53 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html Feb 24 19:20:59 cannot find FILES_SOLIBSDEV. Feb 24 19:21:08 nerdboy: if it only worked ... Feb 24 19:21:25 if only it worked*, hack, stress is not good for typing :) Feb 24 19:21:52 khem`: the so name is probably a quick fix though Feb 24 19:22:09 khem`: see, the architecture is relatively complex, we do not have time to establish proper layers in Yocto. Feb 24 19:22:21 I am happy to ship it as a bit more monoltythic than that. Feb 24 19:22:32 * nerdboy left the agile-train-to-hell last year Feb 24 19:22:49 nerdboy: I have never joined that train ;-) Feb 24 19:23:01 neither did i Feb 24 19:23:08 not having proper layers shouldn't impact the ability to create versioned libs :) Feb 24 19:23:16 more like a hijacking Feb 24 19:23:57 rewitt: that is exactly why I said I would do that. Feb 24 19:24:14 but thinking about package layering is comethic at this point. It is not simply my lib and my app. Feb 24 19:24:32 it is my kernel + my utils + my lib + my apps + mylibs + myapps, etc Feb 24 19:24:38 it is a quite complex stack ;-) Feb 24 19:25:12 you're supposed to grow it the right way... Feb 24 19:25:17 needs half a day to think about packaging, implementing it and testing. Feb 24 19:25:34 nerdboy: I am supposed to find a rich woman, too :D Feb 24 19:25:54 I am still surprised that FILES_SOLIBSDEV is undocumented. Feb 24 19:26:17 I will open a ticket for that. Feb 24 19:26:38 Doesn't Yocto only put .so files that are symlinks into -dev packages, anyway? Feb 24 19:26:47 it does Feb 24 19:26:56 but he wants to devoid that Feb 24 19:27:06 Then I really don't know why they would be needed at runtime. Feb 24 19:27:07 neverpanic: nope Feb 24 19:27:14 you can disable that. Feb 24 19:27:30 see above, the insake skips, I did that in the past, too. Feb 24 19:27:32 lpapp: you should really bite the bullet once and do it right in component Feb 24 19:27:42 good engineering goes long way Feb 24 19:27:47 khem`: like I wrote many times above, sure.. Now? No. Feb 24 19:28:00 khem`: well, you are used to Intel with shitload of money Feb 24 19:28:09 try a startup where you have to ship stuff asap to survive Feb 24 19:28:09 what ? Feb 24 19:28:15 cosmethic stuff will not be high priority :) Feb 24 19:28:32 lpapp: i am just giving you crap... i got stalled in the middle of restructuring my meta-alt layer and all the images Feb 24 19:28:39 I have been on both side as an ex-"nokian". Feb 24 19:28:43 sides* Feb 24 19:28:45 need get back to that someday... Feb 24 19:28:50 I notice the differences of the business stuff... Feb 24 19:29:45 lpapp: khem is juniper afaik, not intel Feb 24 19:30:00 still a nice place, not so big though Feb 24 19:30:08 nerdboy: Intel was just a name ... Feb 24 19:30:12 *big as intel Feb 24 19:30:17 the important bit is the focus you have to put on stuff. Feb 24 19:30:39 well, some of these guys do work at intel... Feb 24 19:31:01 you didn't notice the crap part? Feb 24 19:31:11 Would I like to do everything perfect like in my dreams? Sure! Can I afford that in a small company playing for survival? Absolutely not. Feb 24 19:31:34 there are layers above technical stuff... e.g. business. Feb 24 19:32:47 but it's really just making the .so a symlink and the real library have a .1 on the end of it. You don't even have to ever increment the version number if you don't want to. I guess I fail to see why that takes any more time than working around it. Feb 24 19:32:50 it is annoying that "yocto bugreport" does not give any good result on the first page of Google results. I am not joking! Feb 24 19:33:16 rewitt: that is the thing. You have not even understood the use case. Feb 24 19:33:23 if it was just like that, sure. Feb 24 19:33:29 but it is not.... Feb 24 19:33:49 * nerdboy glad to see nothing has changed too much... Feb 24 19:34:02 although even that requires gcc knowledge in the buildsystem how to do it properly with Makefiles, etc, which I simply do not have at this point. Feb 24 19:34:21 skills do not come for free. Feb 24 19:34:47 I still do not get why google cannot find me where to report bugs against Yocto. This is ... suboptimal. Feb 24 19:35:32 https://www.yoctoproject.org/tools-resources/bugs is the first hit on google for "yocto bugs" that page then has a link to the bugzilla Feb 24 19:35:46 http://lmgtfy.com/?q=yocto+bugs Feb 24 19:35:59 https://bugzilla.yoctoproject.org/show_bug.cgi?id=7358 Feb 24 19:36:01 Bug 7358: normal, Undecided, ---, david.c.stewart, NEW , FILES_SOLIBSDEV is not documented Feb 24 19:36:15 rewitt: I was not looking for that page. Feb 24 19:36:19 I was looking for the bugzilla. Feb 24 19:36:27 and yes, I know where to find it as I reported many bugs in the past. Feb 24 19:36:38 I am simply telling that it is not indexed properly by Google which is a fail. Feb 24 19:36:57 I do not know why it is happening though ... The Yocto project is the first where I see this failure on Google. Feb 24 19:37:38 e.g. type qt bugreport Feb 24 19:37:46 gnome bugreport Feb 24 19:38:15 khem: I'm curious did you figure out what was different in core-image-sato that was causing init to segfault? Feb 24 19:38:17 etc, I do not know why the Yocto bugzilla is not indexed. Feb 24 19:38:36 kde bugreport, etc, etc, g2g... Feb 24 19:38:47 rewitt: no time Feb 24 19:39:14 I use systemd so sysvinit is like a step child Feb 24 19:39:23 and it works with systemd Feb 24 19:39:38 khem: I agree it's really hard for me to switch back to sysvinit Feb 24 19:40:20 what branch? Feb 24 19:40:31 * rewitt off to lunch Feb 24 19:40:56 guess i should deploy a recent build... Feb 24 20:01:31 OK so kernel headers updated to 3.19 but conman was not fixed to take it Feb 24 20:01:49 from /home/ubuntu/work/bleeding/openembedded-core/build/tmp-glibc/work/core2-64-oe-linux/connman/1.28-r0/connman-1.28/src/tethering.c:39: Feb 24 20:02:05 :8: error: redefinition of 'struct in6_addr' Feb 24 20:06:13 huh works here Feb 24 20:28:15 rburton: It was a local cruft Feb 24 20:56:21 is there a way to set only the locales i want to generate in local.conf? Feb 24 20:57:26 * paulg notes that the python upgrade breaks build-appliance related stuff. Feb 24 20:58:03 .... Feb 24 20:58:04 File "/usr/lib/python2.7/ctypes/__init__.py", line 10, in Feb 24 20:58:05 from _ctypes import Union, Structure, Array Feb 24 20:58:05 ImportError: No module named _ctypes Feb 24 20:58:29 get the above when trying to invoke bitbake in the build appliance... Feb 24 21:03:13 To be fair, I am _guessing_ it is the python uprev. Feb 24 21:04:25 dgm816: yes set IMAGE_LINGUAS Feb 24 21:04:44 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-IMAGE_LINGUAS Feb 24 21:05:14 paulg: it seems it did not configure ctype.so Feb 24 21:05:22 khem`, aren't those only tne installed package locales into the image? i'd like to not even generate them to keep my Packages.gz smaller.. we will have to be updating over slow/unreliable links.. Feb 24 21:05:30 paulg: usually happens when python detects wrong CC Feb 24 21:06:00 dgm816: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-GLIBC_GENERATE_LOCALES Feb 24 21:06:48 http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ENABLE_BINARY_LOCALE_GENERATION Feb 24 21:06:54 is all you need to read Feb 24 21:11:52 khem`, zeddii and I were just looking at part of the recipe which looked to specifically error out if ctype wasn't configured.. Feb 24 21:12:05 but AFAIK that never tripped. Feb 24 21:26:41 dgm816: last time i messed with those settings it broke my X keyboard config Feb 24 21:29:52 i set IMAGE_LINGUAS = "en-us" in local.conf and it all went kablooey Feb 24 21:30:09 so obviously that's not all of it... Feb 24 21:59:03 paulg: ok that good Feb 24 22:31:53 has someone used make-native Feb 24 22:32:22 instead of host make Feb 24 22:38:53 bluelightning, just a heads up ; "populate_sdk_ext: add extensible SDK" somehow trips up the tab completion I'd added to git; we now try to find a nativesdk-bash-completion when building the native git, and that gives... Feb 24 22:40:48 ERROR: Nothing PROVIDES 'nativesdk-bash-completion' (but virtual:nativesdk:/home/paul/poky/meta/recipes-devtools/git/git_2.3.0.bb DEPENDS on or otherwise requires it). Close matches: Feb 24 22:40:54 Looking into it now.... Feb 24 22:55:06 paul_G: that happens just by doing a "bitbake git-native"? Feb 24 22:57:33 rewitt, as it turns out no.... just getting to the bottom of it this very minute. Feb 24 22:57:42 I had a local layer change that caused it... Feb 24 22:58:30 paul_G: ok, let me know the sdk patch series really does end up causing problems Feb 24 23:01:21 so, here is what broke. The part of the git tab completion that I didn't send upstream because bash-completion isn't (yet?) outside of meta-oe, was this, in a local bbappend for git. Feb 24 23:01:35 PACKAGECONFIG ?= "bash-completion" Feb 24 23:01:49 PACKAGECONFIG[bash-completion] = ",,bash-completion,bash-completion ${BPN}-bash-completion" Feb 24 23:02:25 but w/o meta-oe in your bblayers, you can't do that. Feb 24 23:04:28 It was just a fancy way to say use git tab completion if bash completion is present. That said, others may have similar constructs that now behave differently. Feb 24 23:05:36 rewitt, looking at your commit, it was over my head as to why the behaviour changed from it... Feb 24 23:06:22 I wouldn't expect the behavior to be any different unless you were actually trying to build an sdk Feb 24 23:06:29 I can easily drop my git bbappend and unconditionally call out bash-completion and git-completion in my packagelist Feb 24 23:06:46 rewitt, well it probably is beacuse git has this... Feb 24 23:07:13 BBCLASSEXTEND = "native nativesdk" Feb 24 23:07:28 so when I added tab completion, as this... Feb 24 23:07:43 PACKAGES =+ "${PN}-bash-completion" Feb 24 23:08:02 it was generally right in thinking a native one made sense. Feb 24 23:08:58 anyway, testing without the two PACKAGECONFIG lines quoted above and things are ok ; not failing looking for a native-bash-completion Feb 24 23:09:59 rewitt, and fwiw, I wasn't directly trying to build an sdk, but I am building a layer based on the build appliance, so it kind of / sort of is an sdk of sorts.... Feb 24 23:17:45 now, with that solved, do I feel brave enough to try and figure out why the python uprev broke build appliance.... Feb 25 02:13:53 saksl **** ENDING LOGGING AT Wed Feb 25 02:59:58 2015