Thursday, 2013-03-07

*** evanp <evanp!~evan@> has quit IRC18:23
*** davest1 is now known as davest18:24
*** evanp <evanp!evan@nat/intel/x-pslsjelultotsgfi> has joined #yocto18:25
blloyd_thanks everyone on feedback.  Hadn't considered 3 partitions so always have one root partition that isn't being updated.  I had considered 2 where the running partition updated the other partition.18:26
*** darknighte is now known as darknighte_afk18:27
-yocto-ab-bot- build #280 of p1022ds is complete: Success [build successful] Build details are at
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC18:36
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto18:38
*** bdholt1_ <bdholt1_!~bdholt1@> has quit IRC18:39
-yocto-ab-bot- build #275 of nightly-x86-lsb is complete: Success [build successful] Build details are at
*** rcw <rcw!~rwoolley@> has quit IRC19:01
*** denisATeukrea <denisATeukrea!~GNUtoo@> has quit IRC19:05
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC19:06
*** RP <RP!> has joined #yocto19:09
*** JDuke128 <JDuke128!~kadirbaso@> has joined #yocto19:18
*** sameo_ <sameo_!samuel@nat/intel/x-tfkthqmrsruhzgaz> has quit IRC19:21
*** rcw <rcw!~rwoolley@> has joined #yocto19:38
*** smartin <smartin!> has quit IRC19:39
*** smartin <smartin!> has joined #yocto19:43
zibrirp: i've made some changes to the bb.fetch2.URI class, that among other things, addresses the issues we discussed during ELC. but otoh perhaps the whole idea was a bit naive on my part, perhaps too much work to use urlparse.19:48
zibriwill send it to the mailing list for comments, tomorrow or so.19:48
*** sameo <sameo!~samuel@> has joined #yocto19:56
*** ccssnet <ccssnet!~ccssnet@> has quit IRC20:01
*** ccssnet <ccssnet!~ccssnet@> has joined #yocto20:04
kergothdisabling the external toolchain causes my -natives to rebuild?20:17
* kergoth adds todo20:17
*** tor <tor!> has quit IRC20:22
*** JimNH2 <JimNH2!> has joined #yocto20:25
*** JimNH <JimNH!> has quit IRC20:27
*** sameo <sameo!~samuel@> has quit IRC20:42
*** RP <RP!> has quit IRC20:43
*** _Lucretia__ <_Lucretia__!> has joined #yocto20:45
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC20:46
Crofton|workok, I've relaized I just need to install this eclipse thing20:47
Crofton|worknow, I am trying to working out how to configure the sdk plugin to use the toolcahin in /usr/local20:47
* walters reads the comments in and laughs21:00
*** JDuke128 <JDuke128!~kadirbaso@> has quit IRC21:02
Crofton|workthose come fro the oe-classic recipe21:04
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC21:25
Garibald1Suppose that I'm generating an SDK using bitbake -c populate_sdk <target>.  How do I engineer a recipe to get included in the generated SDK?21:31
Garibald1I tried adding a line 'BBCLASSEXTEND = "nativesdk"' to my recipe, but the files associated with that package didn't get included in the SDK21:33
zibriwalters: haha... nice stuff :)21:34
Garibald1(and my package inherits 'native')21:37
Crofton|workarg, why isn't eclipse using the cross compiler21:39
*** bluelightning <bluelightning!> has joined #yocto21:45
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:45
rburtonwalters: lets just say there's a lot of legacy.  i found myself cleaning up a fontconfig recipe that was full of crazy, introduced by my misguided and innocent self 6 years ago21:50
*** mthalmei_away is now known as mthalmei21:50
kergothGaribald1: bbclassextend just makes a nativesdk version available, it won't magically also add that new recipe's packages to the sdk. populate_sdk operates based on the image target you select. you could set a variable, i forget what it's called, to adjust the package set just for the sdk, or you could just create a new image. the whole point of populate_sdk is to create an sdk corresopnding to an image, so its packages are governed primarily by that21:56
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC21:57
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto21:57
Garibald1kergoth: so I have a target that pulls in a native package, and some of my recipes are able to successfully use the content provided by the native package, but when I do 'bitbake -c populate_sdk <that_target>' the same content doesn't appear in the generated sdk.21:58
*** mthalmei is now known as mthalmei_away21:58
kergothGaribald1: and "pulls in" means what exactly?21:59
Garibald1kergoth: meaning the native package is installed21:59
Garibald1gets put in temp/sysroots/x86_64-linux22:00
*** zenlinux_ <zenlinux_!> has quit IRC22:00
kergothagain, populate_sdk has meaning when run based on an image, not a random recipe22:01
Garibald1hum... let me see if I can explain more clealry22:01
Garibald1I have a recipe core-image-foo that DEPENDS on my-package-native.  'bitbake core-image-foo' generates an image, using the tools provided by 'my-package-native'; 'my-package-native' files appear in tmp/sysroots/x86_64-linux.  'bitbake -c populate_sdk core-image-foo' generates an SDK, but that SDK doesn't include the 'my-package-native' content.22:04
Garibald1so my application of populate_sdk is on an image22:06
*** RP <RP!> has joined #yocto22:07
*** foerster <foerster!> has joined #yocto22:09
Garibald1ah, I should also mention that 'my-package-native' content also appears in tmp/work/x86_64-linux/my-package-native-1.0-r0/sysroot-destdir/absolute/path/to/where/tmp/sysroots/x86_64-linux/is/path/to/content22:09
kergothDEPENDS isn't what you want. populate_sdk populates an sdk based on *what goes into the image*22:09
kergoththe sysroots aren't relevant22:09
kergothe.g. if you want bash-nativesdk in populate_sdk, one way to get it is to add bash to IMAGE_INSTALL for tha timage.22:09
*** walters <walters!> has quit IRC22:10
kergothi think there's another variable to control it directly, but i can't recall it offhand, i'd suggest reading image.bbclass for details22:10
*** sameo <sameo!~samuel@> has joined #yocto22:14
Garibald1then I'm very confused.22:21
*** foerster <foerster!> has quit IRC22:21
Garibald1I thought the SDK was the toolchain used on the host to build apps for the distro22:21
kergothnope. the sdk is the production of a *standalone* development environment and toolchain which you use to build stuff outside of yocto22:22
Garibald1yeah, exactly22:22
kergothand that environment by default is produced based on what goes into the root filesystem of an image, as mentioned earlier22:22
kergoth(if you use populate_sdk, rather than an sdk recipe)22:22
Garibald1so if I have a distro for ARM, but I'm building on x86_64, I need a cross-compiler compiled for x86_64 that can compile images for arm22:23
Garibald1doesn't make sense that the SDK would include stuff that went into the arm distro22:23
kergothassuming you want to do builds outside of yocto, sure. the toolchain built internally to build recipes is separate from the sdk22:23
kergothno, let me try to explain again22:23
kergothlets say someone wants a rootfs that includes ncurses. doesn't it also makme sense they'd want to be able to link against ncurses to compile their software on the host?22:24
kergothso thats what i'm talking about.22:24
kergothpoulate_sdk populates an sdk based on what's in the rootfs for the image22:24
kergothonly they're nativesdk versions of the recipes22:24
*** ant_home <ant_home!> has joined #yocto22:24
kergoththat's my understanding of it, anyway. I've only rarely built with populate_sdk personally22:24
*** foerster <foerster!> has joined #yocto22:25
Garibald1but suppose someone wants a rootfs for a ARM processor.  Doesn't it make sense they'd need a native compiler that could produce ARM binaries.  Wouldn't that also go in the SDK?22:25
Garibald1and the distro might not even have a compiler22:25
kergothyes, the sdk also builds a toolchain, the packages for the toolchain are in the aforementioned separate variables to control what else goes into the sdk other than what went into the image22:26
kergothas i said, see image.bbclass for the exact variable names22:26
Garibald1ok, will do22:26
kergothspecifically, line 8 of image.bbclass and line 10 of populate_sdk_base.bbclass22:27
Garibald1(WRT the libs, isn't that why you also need a copy of the rootfs?  Doesn't the native tools pick up the libs from that rootfs and not from within the SDK itself?)22:27
kergoththe former being the target packages, the latter being the host packages22:27
*** rcw <rcw!~rwoolley@> has quit IRC22:27
Garibald1you mentioned ncurses22:27
kergothunless you're using montavista or something, no crosscompiler/sdk you find is going to include a rootfs22:27
kergoththe toolchain has its own sysroot(s)22:27
Garibald1wouldn't the ncurses libs be on the rootfs, not on the sdk?22:27
Garibald1s/on the sdk/in the sdk/22:28
kergothyes, it will be in the rootfs, and populate_sdk will also add it to the sdk, because the crosscompiler isn't going to magically look in a rootfs running on a remote device somewhere to find the lib22:28
Garibald1the sdk doesn't include the rootfs, you download it separately22:28
kergoththe rootfs goe son the device. the crosscompiler has *zero* knowledge of it22:28
kergoththe fact hat ncruses is in the rootfs isn't going to magically make you able to link against ncurses with the crosscompiler22:28
kergothlibncurses would have to go into the sdk for that22:29
kergothwhich is what populate_sdk *does*22:29
Garibald1the rootfs goes on the device, no doubt, but you can also use a copy of that on the host for libs and the like.  The Yocto ADT plugin for eclipse, for example, requires you to give it a path to a rootfs22:30
*** kmacleod <kmacleod!> has quit IRC22:30
kergothdon't know or care about the adt, personally. the sdk created by populate_sdk works with or without the adt22:30
kergothand works without a rootfs22:30
kergothbut regardless, the sdk creation process has multiple aspects. it builds nativesdk packages for the host, and it adds target packages to the sdk sysroot based on what goes into the image (IMAEG_INSTALL/PACKAGE_INSTALL)22:31
Garibald1well, I'll the variables you pointed me to22:31
kergoththe former is likely what you want, which means you likely want to add to the variabel i pointed you to earlier in populate_sdk_base22:31
Garibald1yeah, agreed22:31
Garibald1thanks for the suggestions22:32
jstashluk| Computing transaction...error: Can't install gst-plugins-gl-meta-0.10.3-r2@armv7a_vfp_neon: no package provides gst-plugins-gl-apps22:33
jstashlukMy do_rootfs for my image used to work, any ideas on what this means?22:34
*** kmacleod <kmacleod!> has joined #yocto22:37
*** jstashluk <jstashluk!~jstashluk@gateway/tor-sasl/jstashluk> has quit IRC22:41
*** himamura <himamura!> has quit IRC22:43
*** Bagder <Bagder!> has quit IRC23:05
*** Bagder <Bagder!> has joined #yocto23:06
*** eren <eren!~eren@unaffiliated/eren> has quit IRC23:06
ftonelloi don't understand why sometimes bitbake create packages different then PACKAGES variable23:16
ftonellowhy does that happens?23:16
kergothPACKAGES_DYNAMIC holds patterns of what packages other than PACKAGES may be created23:16
kergothit's used to handle creation of packages dynamically based on what comes out of the build23:17
kergothit's used for locales, etc23:17
ftonellothe problem is that it's not creating the ones that I want to.. is there anyway to disable that?23:18
kergothwhat do you mean by that?23:18
kergothevery package listed in PACKAGES will be created unless no files will go into it (unless ALLOW_EMPTY_<pkg> is defined, in which case it gets created even if empty)23:19
ftonelloi have a recipe which has several libraries (pre-built) I want to create a package for each library, i do it but the deploy-<package> direcotry inside the ${WORKDIR} lists one package, which in fact it's not in PACKAGES.23:19
ftonelloanother example, im appending the qt-mobility-x11 recipes23:20
ftonelloI have a PACKAGES += "${PN}-publishsubscribe" and I do a FILE_${PN}-publishsubscribe += "..." but it doesn't create it23:21
ftonelloalthough it creates a libqtpublishsubscribe1 package..23:22
ftonellowhich is definitely not what i want..23:22
ftonellois there any way to disable this dynamic package creation?23:22
ftonellofor a specific recipe23:22
kergothit's likely you're just encountering teh automatic package renaming based on shlibs23:23
kergoththe same packages are emitted, just with different names.23:23
*** jbaxter <jbaxter!> has quit IRC23:23
kergothsee debian.bbclass23:23
ftonelloin my case is rpm23:24
kergothpackage manager is irrelevent23:24
ftonellokergoth: but still.. its not the case.. the contents are different.. and when I saw the do_package_write_rpm log23:24
ftonelloit looks like it changes the ${PN}23:24
ftonelloNOTE: Creating RPM package for libqtpublishsubscribe123:25
kergothfirst of all, its FILES_, not FILE_23:25
ftonelloNOTE: Not creating empty RPM package for libqtpublishsubscribe-publishsubscribe23:25
kergothsecond, bitbake only emits the binary packages listed in packages and those created dynamically with do_split_packages, it doesn't pull them out of thin air23:25
kergothyes, that means your FILES doesn't match reality, as i said earlier, it doesn't create empty packages unless you set ALLOW_EMPTY23:25
kergothyou just need to use bitbake -e to make sure the variables are set to what you think they are23:25
ftonellokergoth: i know.. but when I do bitbake -e and I check the variables, they are correct23:26
kergothwell, bitbake isn't going to emit an empty package. fix your do_install, or fix your FILES variables.23:26
kergoththis is a lot simpler than you seem to think23:26
*** munch <munch!> has quit IRC23:26
ftonellook.. i will make sure of something23:27
kergothwhenever i see something seemingly inexplicable happening, it's almost always a mismatch between my expectations and reality, and bitbake -e and other similar mechanimss are invaluable for checking those assumptions23:27
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC23:28
*** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has joined #yocto23:29
*** kmacleod <kmacleod!> has quit IRC23:30
kergothif you're really curious about what's going on, you can always read the tasks in the bbclasses and see exactly what's going on. its easier if you know python, but you'll probably get the gist even without that23:30
ftonellokergoth: this is what is inside image/
*** kmacleod <kmacleod!> has joined #yocto23:32
kergothyeah, that's what do_install puts there. what about it?23:32
ftonelloi wnat to show you that the paths are correct23:33
kergothagain, debian.bbclass renames packages based on the shared library the package includes. if your package includes libqtpublishsubscribe, then yes, it will rename it to libqtpublishsubscribe1.23:33
ftonellothe packages shouldn't be empty23:33
kergothi just told you, either do_install is wrong *OR* the fiels variables are wrong23:33
kergothi didn't say i was going to figure out which wa sthe case for you23:33
ftonellobitbake -e
ftonelloim not asking that23:34
ftonelloim just trying to understand why this is not working23:34
*** michael_e_brown <michael_e_brown!~michaeleb@> has quit IRC23:40
evanpftonello: the libqtpublishsubscribe1 thing sounds like the debian package rename hook23:49
evanpftonello: meaning, it _is_ your ${PN}-publishsubscribe package23:50
evanpftonello: but the hook changed the file name23:50
ftonelloevanp: I tink the hook changed the ${PN} package file name23:50
ftonellosee the from the do_package_write_rpm23:50
evanpftonello: yes, exactly23:50
ftonelloNOTE: Not creating empty RPM package for libqtpublishsubscribe-publishsubscribe23:51
ftonellobut thats the thing23:51
ftonelloI don't want that behavior.. is there anyway to disable that?23:51
evanpyou mean you want it to create an empty package? like kergoth said, ALLOW_EMPTY23:53
evanpor do you mean you want your package to be named libqt-publishsubscribe? you'll have to figure out a way to change the debian rename hook to do that. disabling it globally'll probably break other stuff.23:54

Generated by 2.11.0 by Marius Gedminas - find it at!