**** BEGIN LOGGING AT Mon Apr 11 02:59:58 2016 Apr 11 05:34:18 Hi is it possible to add some kind of check in my bbappend such that if something is defined abc binary gets packaged in the rootfs else something else gets packaged Apr 11 07:24:05 I want to modify build_boot_dd in boot-diretdisk.bbclass and I want to keep that modification in my own additional layer. what's the way to do this? Apr 11 07:31:43 good morning Apr 11 07:33:31 morning Apr 11 07:35:50 morning mckoan, leon-anavi Apr 11 07:36:30 doyu: probably just define your modified function in your own class which inherits boot-directdisk.bbclass and have your images inherit it Apr 11 08:14:02 bluelightning: which dir to store? it's bbclass originally. If I want to extend which one to use, own bbclass or some recipes-* under my layer? Apr 11 08:15:29 bluelightning: for exmaple, which one, "meta-mylayer/recipes-core/boot-directdisk.bb" or "meta-mylayer/classes/boot-directdisk.bbclass" or something else? Apr 11 08:28:57 doyu: if it's a class file, it can only go under meta-mylayer/classes within your layer Apr 11 08:29:17 bluelightning: ok, thx Apr 11 08:29:46 strictly speaking it's any directory along BBPATH, but the convention is that your layer's conf/layer.conf appends the layer directory to BBPATH Apr 11 08:55:40 bluelightning: in case you remember that question: https://www.linkedin.com/pulse/create-images-several-boot-devices-using-yocto-jens-rehsack Apr 11 08:56:15 I found a hopefully nice solution to build an image for eMMC, SD-Card or USB-Stick by setting a variable Apr 11 09:09:35 c Apr 11 09:32:06 hoi Apr 11 11:45:54 hello Apr 11 11:46:18 i'm reading a mailing list answer from Bruce on the yocto list. Apr 11 11:46:56 he mentions kernel fragments working only for kernels which inherit from linux-yocto Apr 11 11:47:38 i'm looking in the recipe for the kernel i'm using. It has a inherit kernel line. Apr 11 11:48:23 that is not a yocto inherit right? it would need to be inherit kernel-yocto for the fragments to work? Apr 11 11:57:08 correct Apr 11 11:57:43 thanks Apr 11 11:59:57 this tree has a bunch of different defconfigs in different dirs. Any idea how to determine which config is being used besides trying to add a append version string to each and then booting to see if the uname -a sticks? Apr 11 12:12:41 hmm. there is a routine in the the .bb file for the kernel which is called do_update_kernel_version(). I wonder if that is for the build system or it actually overwrites a .config or defconfig Apr 11 13:04:03 i tried to apply this patch from Ed Bartosh http://lists.openembedded.org/pipermail/openembedded-core/2015-November/113264.html Apr 11 13:04:17 to fix my libSDL problem Apr 11 13:04:24 but it did not work. Apr 11 13:05:06 there is another qemu.inc file in conf/machines/include/qemu.inc does it need to be patched as well? Apr 11 13:07:47 fwiw, after making the patch, I did bitbake -c clean qemu-native and then bitbake qemu-native and the same error where libSDL was not able to find even though its installed. Apr 11 13:09:41 davis: what release? Apr 11 13:09:46 fwiw, sudo apt-get install libsdl-1.2dev is reported as already the latest. Apr 11 13:10:07 what release of the poky? Apr 11 13:10:10 yeah Apr 11 13:10:36 poky-jethro-14.0.0 Apr 11 13:11:01 i checked to see iif the patch had already been applied, but it was not Apr 11 13:11:04 grab the relevant commits from the jethro branch in git, or wait for 2.0.2 to release Apr 11 13:11:09 that patch wasn't as it didn't work Apr 11 13:11:52 you want to grab "libsdl: expand PACKAGECONFIG and enable native builds" and "conf/local.conf.sample: comment out ASSUME_PROVIDED=libsdl-native" Apr 11 13:12:47 i found this via the bugzilla. is the one you mention linked from there? Apr 11 13:13:45 ie it was from here https://bugzilla.yoctoproject.org/show_bug.cgi?id=7469#c9 Apr 11 13:13:47 Bug 7469: normal, Medium+, 1.6.4, juro.bystricky, IN PROGRESS REVIEW , SDL package cannot be found on OpenSUSE 13.2 Apr 11 13:21:24 rburton: i think this is what you are pointing me to Apr 11 13:21:35 https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b407a8004ab47c0f101167ee384e66823a09aa78 Apr 11 13:26:30 Has anyone tried using gles2 (PACKAGECONFIG) instead of "gl" for qtbase ( master branch and also poky with master branch)? Apr 11 13:27:15 the machine name I refer here is qemuarm. Somehow I find that opengl examples of qtbase are failing to run Apr 11 13:27:46 any bets on toaster cloning layers for me? Apr 11 13:41:41 Crofton|work: i think that can be done with devtool. I'm new to this, but if you find a guide. I'd be interested in seeing what you did. Apr 11 13:42:07 I think i saw a youtube video by dave wold on using devtool to do this. Apr 11 13:49:03 * Crofton|work grumbles about people not testing versus distroless oe-core Apr 11 13:50:34 Crofton|work: the AB does a distroless build so it shouldnt massively break Apr 11 13:50:44 and poky has almost nothing in it anyway Apr 11 13:50:57 I'm being annoying and using oe-core and bitbake at smae level Apr 11 13:51:10 [balister@thuvia build]$ source toaster start Apr 11 13:51:10 bash: /home/balister/src/toaster/bitbake/bin/../../.templateconf: No such file or directory Apr 11 13:51:35 I promised belen I'd try to do some idiot like builds of complicated stuff :) Apr 11 13:51:55 heh Apr 11 13:53:26 [balister@thuvia toaster]$ find . -name toasterconf.json Apr 11 13:53:26 ./openembedded-core/meta/conf/toasterconf.json Apr 11 13:53:47 seems like the toaster code in bitbake assumes it is installed insode oe-core I bet Apr 11 14:05:48 * Crofton|work curses some moer Apr 11 14:07:15 $ INHERIT += "toaster" Apr 11 14:07:30 I assume the trailing is a mistake in th ewiki? Apr 11 14:09:11 yes Apr 11 14:09:49 Tools like toaster will get no traction in the larger community until they stop assuming poky Apr 11 14:18:59 * Crofton|work wonders if toaster is a component or part of the build system Apr 11 14:19:04 bugzilla wise Apr 11 14:33:17 * kergoth thinks about changing the default path prefix for native/cross to an invalid location, so any relocation issues are shown right away rather than only when used from sstate in another location Apr 11 14:37:05 kergoth: yeah ive wondered about that too - poison the native sysroot like we do for target Apr 11 14:37:27 also got an open bug for 2.2 to relocate native stuff like we can relocate the eSDK Apr 11 14:37:34 rburton: i applied that patch as well. I backed out the one I added previously. did a clean and build.. same error as before. Apr 11 14:37:52 davis: you'll need to comment out the ASSSUME_PROVIDED = libsdl-native bit in your local.conf (see the second patch) Apr 11 14:38:27 rburton: i thought about just using target paths for native, but then there'd be no identifiable string to search for to do the reloc fixups, so it has to be something :) Apr 11 14:39:10 * kergoth gets caffeine Apr 11 14:40:07 hmm. in my jacked up vendor provided yocto setup, I do not have an ASSUME_PROVIDED line in my local-config Apr 11 14:40:53 im guessing i need to do $find . -type f | xargs grep ASSUME_PROVIDED to find where it is located Apr 11 14:48:38 ok, skimmed toaster bugs and added my 2 cents Apr 11 14:48:44 avoided making a dupe Apr 11 14:49:46 rburton, after the config patch, https://gist.github.com/netskink/2de70a9d2c93b0a62865ebb283161c6e Apr 11 14:51:32 davis: oh yes, and " xorg-lib: allow native building without x11 DISTRO_FEATURES" Apr 11 14:51:59 (this is why i tend to endorse using the stable git branches, this has been fixed there for a month) Apr 11 14:52:14 rburton: i'm terribly sorry, but I am confused. Apr 11 14:52:21 davis: oh and " base: check for existing prefix when expanding names in PACKAGECONFIG" Apr 11 14:52:45 (all near the top of the jethro branch on poky) Apr 11 14:52:57 ok, let pull those. Apr 11 14:53:18 you said stable, is that not 14.04? Apr 11 14:53:40 erro, stable as in poky-jethro-14.0.0 Apr 11 14:54:16 yes Apr 11 14:54:36 so this is not a stable branch that I am using? Apr 11 14:54:44 you're using a tarball release Apr 11 14:54:55 whereas there's been a .1 already, and .2 is due any day now Apr 11 14:55:21 if you were tracking the branch in git then you'd be able to just move to a newer revision on the stable branch Apr 11 14:55:22 you are incredible! how did you know that? I thought it was using git. Apr 11 14:55:49 well if you have a git clone then that's awesome, just checkout origin/jethro Apr 11 14:56:08 poky-jethro-14.0.0 sounds a lot like the tarball name, that's all Apr 11 14:56:17 i guess you are correct, it ssays wget and tar -xf in the setup script Apr 11 14:57:06 you are correct. Apr 11 14:57:09 POKY_URL="http://downloads.yoctoproject.org/releases/yocto/yocto-2.0/${POKY_ARCHIVE}" Apr 11 14:57:16 that is the in the global_config Apr 11 14:57:44 i wonder if all this could be resolved, if I just changed the name of the tar ball. Apr 11 15:00:04 btw, were you at yoctodev day last week or the conference in general? Apr 11 15:02:49 i'm guessing you are Ross Burton from Intel. Your face doesn't look like one of the guys I met there though. I met a lot of knowedable folks. It was a good con. Apr 11 15:08:52 if there was ELC then i wasn't there. Apr 11 15:09:10 yes Apr 11 15:17:06 I might have to do that. Apr 11 15:17:17 err, switch to a git branch. Apr 11 15:33:32 hmm. I added those patches, but it fails again. I should just use the git to pull all these fixes. i'm thinking the original developers should have done this to begin with instead of using a tarball. Apr 11 15:47:59 hmm. i am looking through the yocto developer day slides. All these examples use tar files for the URL's. Is there a reference for showing how to switch POKY_URL to be a git branch instead of tarball? Apr 11 15:56:51 davis: it's quite common to use a recipe to pull from git not tarballs Apr 11 15:58:28 yes, I found a ref in the online doc. i was surprised the slids from last week did not give one. Apr 11 16:01:34 Hey guys I'm trying to build a minnowboard max image and I'm getting a "no recipes available for: " and it lists three bbappend files inside the meta-intel layer. Apr 11 16:08:11 tesla, layer version mismstches? Apr 11 16:20:20 Hi, I have build jethro core-image-minimal for beaglebone, having problems to boot from sdcard http://pastebin.com/yixnhQZK Apr 11 16:20:36 I have follow setup from https://www.yoctoproject.org/downloads/core/jethro201 Apr 11 16:43:52 hey so I made this recipe for rethinkdb which has its own wacky build system, provided a `do_configure` for it and that seemed to be all that was required (do_compile went off without a hitch), but nothing seems to be installed Apr 11 16:44:17 I know I probably need to manually install, but I had assumed there would be a default do_install which would pick up some files at least? Apr 11 16:44:25 no Apr 11 16:44:29 what would it do? Apr 11 16:44:36 `make install`? Apr 11 16:44:38 haha Apr 11 16:44:40 its still Makefile based Apr 11 16:44:52 how do you tell it where to actually install the files? Apr 11 16:45:08 DESTDIR is automake-specific Apr 11 16:45:29 you need to do make install ACTUALLY_INSTALL=/in/here Apr 11 16:45:40 ie for automake , make install DESTDIR=${D} Apr 11 16:45:47 ah sorry I should have been more specific, the configure actually accepts a number of install related paths Apr 11 16:45:54 sure, but not prefix Apr 11 16:46:00 the packaging staging path Apr 11 16:46:07 yes it does accept a prefix Apr 11 16:46:15 "${S}/configure --allow-fetch --with-system-malloc --prefix ${prefix} --sysconfdir ${sysconfdir} --localstatedir ${localstatedir}" Apr 11 16:46:56 does the generated makefile install directly to $prefix, or does it support an intermediate directory Apr 11 16:47:04 ie autotools installs all files to $DESTDIR$prefix Apr 11 16:47:10 yeah I gotcha, let me check Apr 11 16:48:55 well there's a good sign, no install target in the top level Makefile :) Apr 11 16:49:02 ;) Apr 11 16:49:06 i.e. prefix is /usr, we need to install to ${D}/usr, not /usr, unless you want to overwrite host files Apr 11 16:49:08 hah Apr 11 16:49:24 interesting use of the word "good" there Apr 11 16:49:46 this recipe has been a total pita, they include their own "mini packaging system" for fetching like 10 different projects, building them statically and linking them in Apr 11 16:49:54 wasn't very yocto friendly heh Apr 11 16:49:58 would be nice if 'do nothing' was an explicit class, and the default do_install errored out, instead Apr 11 16:50:03 mbroadst: ouch Apr 11 16:50:45 mbroadst: first rule of packaging: if the upstream maintainer can be "clever" and do something stupid, they will Apr 11 16:51:02 exhibit one being "autotools is overkill, I'll just use make" Apr 11 16:51:06 hah totally Apr 11 16:51:16 or "nobody cross compiles" Apr 11 16:51:35 imagine my excitement when random small things failed wrt cross compiling and I had to find some deeply nested log file in their custom directory structure Apr 11 16:51:47 sitting there thinking like "autotools and cmake just weren't good enough huh" Apr 11 16:52:25 hah Apr 11 16:52:26 oh interesting Apr 11 16:52:37 so they do have an included .mk that provides install, and it accepts a DESTDIR Apr 11 16:52:43 so I guess they modelled it after autotools Apr 11 16:52:47 can I just provide Apr 11 16:52:59 do_install() { autotools_install } or whatever that macro was Apr 11 16:53:14 ony if you've inherited autotools, and if its not really autotools then dont Apr 11 16:53:24 do_install() { oe_runmake install DESTDIR=${D} } Apr 11 16:53:39 alright Apr 11 16:54:43 silly question, but do I have access to variables like ${PV} within a do_install? Apr 11 16:58:14 yes Apr 11 17:05:20 the best presentation I saw at elc was the one on autotools. I'm familiar with configure/make/make install process, but I never got how to write an autotools generated makefile. I really enjoyed that guys talk. Apr 11 17:34:13 so for PNWHITELIST... if I whitelist a recipe, why doesn't it automatically whitelist all the dependencies? Apr 11 17:36:12 there's no such thing as PNWHITELIST. perhaps you meant PNBLACKLIST? Apr 11 17:39:17 Also, that would be kind of destructive. If something is masked by the build system, it's probably masked for a reason. Apr 11 17:40:01 Disabling a safety interlock should be a specific action, done on purpose. Apr 11 17:40:02 wyrm, entire layers can be blacklisted Apr 11 17:40:24 if the entire layer is blacklisted, and you want only one recipe from it, why not whitelist all the deps too? Apr 11 17:41:13 kergoth: perhaps PNWHITELIST_{layer name} is an ostro thing? I thought it was defined in whitelist.bbclass Apr 11 17:42:16 oh, yep. your right. blacklist.bbclass Apr 11 17:42:38 i have no idea what you're talking about Apr 11 17:43:13 This, possibly: http://patchwork.openembedded.org/patch/101787/ Apr 11 17:44:09 wyrm: yeh, that looks like it. Maybe it never made it upstream? Apr 11 17:45:10 it's not in oe-core, so i'd say not Apr 11 17:46:07 does seem interesting. but regardless, the answer to your question is likely "because bitbake isn't magic", and more specifically, the recipe blacklisting/whitelisting is done entirely in the metadata, not in bitbake, where there's no knowledge of the dependency graph Apr 11 17:47:02 read the class, a given recipe blacklists itself, it can't say "those other recipes are okay, don't skip them", because you can't change metadata in one recipe from another Apr 11 17:48:01 tripzero: I did notice a mention of PNWHITELIST_LAYERS = "layername" in that thread. If you have the whitelist class, you may have that option. Apr 11 17:48:32 wyrm, good point Apr 11 17:51:25 And kergoth raises a good point as to why large and cascading whitelists are a terrible idea. A recipe might mask itself for some very important reason, like "this version is suspected to sometimes wipe filesystems, ignite hardware, kill puppies, et cetera". Apr 11 17:51:45 indeed, best to be explicit, and make sure you're aware of what it is you're pulling in Apr 11 17:51:50 You don't want to blindly pull in that version when maybe another dependency will do. Apr 11 17:52:31 or maybe seeing it fail to build due to a missing dep will remind you to disable that dep entirely via PACKAGECONFIG :) Apr 11 17:53:15 That said, I can see why layer-wide blacklists would encourage that kind of bad behavior. Got any examples of blacklisted layers? Apr 11 17:53:24 RP: any thoughts on having something like printdiff which only examines STAMPS_DIR, for cases like what bitbake-whatchanged would handle in the past? Apr 11 17:54:03 wyrm: i expect pnwhitelist is intended for distros that want careful control over what's availble, only pulling in recipes to be available to build if they've tested them, for example. i could see meta-oe being a candidate for that, just due to the large number of recipes of varying quality Apr 11 17:54:24 i could certainly see commercial distros using something of that sort Apr 11 17:54:26 * kergoth shrugs Apr 11 18:02:23 I'm trying to track down why does opkg database gets removed from populate_sdk/meta-toolchain packages - any pointers? Apr 11 18:22:02 rburton, http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#sdk-setting-up-to-use-the-extensible-sdk Apr 11 18:22:11 hopefully this is accurate Apr 11 18:31:46 hmm, hopefully the extensible sdk no longer assumes poky in install Apr 11 19:11:35 kergoth: I like the idea. Keep wishing I could spend more time on printdiff :( Apr 11 19:12:31 denix i was looking at the bug list to see if anything popped up, but nothing seems to be relevant Apr 11 19:12:59 have you tried to look at the buglist? its here if you havent https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=opkg Apr 11 19:14:18 davis: not sure searching bugzilla will help - nothing breaks for normal use-cases, until you need opkg database in your SDK later on... Apr 11 19:31:38 rburton: So, I tried applying patches to fix the libSDL error, but that never worked after applying a few patches. Apr 11 19:32:19 rburton: so I figured, I would just grab the jethro-14.0.1 tarball and fix up the local files to use that dir. That resulted int he same error. Apr 11 19:33:34 rburton: so I thought well, maybe if I just git clone the poky repot I could use it and it would have all the latest patches but that fails immediately. it appears to be failing because it can not inherit file classes/qt4e.bbclass Apr 11 19:34:43 If I git clone should I pull from a specific branch? Apr 11 19:35:03 yes, jethro Apr 11 19:35:59 so git clone and then git checkout jethro? Apr 11 19:40:21 yes Apr 11 19:41:25 many thanks Apr 11 19:41:45 i have to keep deleteing tthis .build_dir used by this setup Apr 11 19:42:32 it gets parsing errors. i assume its not normal to have .build-yocto subdir when you source the equivalent of the original oe files. Apr 11 19:42:58 the nice thing is it is now using DISTOR_VERSION 2.0.1 Apr 11 19:48:52 never encountered this setup before Apr 11 19:52:10 rburton: yes, its a vendor enviroment i'm working with. But this new branch of poky might fix some of the issues I'm having with running on bare metal instead of a vm. Apr 11 20:11:21 hmm, can definitely tell a lot of combinations of packageconfigs haven't been tested. experimenting and finding lots of little issues Apr 11 20:29:05 if busybox hwclock is preferred over util-linux hwclock, even if util-linux is installed, with the rationale that it was "broken on nslu2", should we just fix the logic and assume it's been fixed in the previous god knows how many years? Apr 11 20:29:14 also is there such a thing as a good git blame browser Apr 11 20:29:48 (#9103) Apr 11 20:36:25 yep, 11 years old Apr 11 20:36:55 bitbake blame! Apr 11 20:37:29 from what i can tell blame needs files on disk, so you can't blame files that don't exist locally even if you give it a revision to start blaming from where the file exists Apr 11 20:38:08 I mean to show which line ends up in the file bb parses Apr 11 20:38:13 oh right Apr 11 20:38:16 pah Apr 11 20:38:19 bitbake -e is good enough Apr 11 20:38:35 unless you are chassing bbappend issues Apr 11 21:01:12 if I have PNBLACKLIST[foo]="I don't like you", how do I override that to unblacklist foo? Apr 11 21:02:41 * ulf` would like to know the answer as well Apr 11 21:02:52 pidge pidge pidge Apr 11 21:06:34 PNBLACKLIST[foo]="" Apr 11 21:06:56 tried that. didn't work Apr 11 21:07:56 so it is using whatever is been blocked in another place Apr 11 21:08:19 Hi all I'm trying to build an image for the minnowboard max. I'm using this as guide http://www.elinux.org/Minnowboard:MinnowMaxYoctoProject, Problem is that I get an error after entering: bitbake core-image-minimal, parsing the recipes: "No recipes available for: Apr 11 21:08:19 /home/tesla/Projects/meta-intel/common/recipes-bsp/gma500-gfx-check/gma500-gfx-check_1.0.bbappend Apr 11 21:08:19 /home/tesla/Projects/meta-intel/common/recipes-kernel/linux/linux-yocto_4.4.bbappend Apr 11 21:08:19 /home/tesla/Projects/meta-intel/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend Apr 11 21:08:20 /home/tesla/Projects/meta-intel/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend Apr 11 21:08:22 " Apr 11 21:08:23 how are you setting this var? Apr 11 21:08:25 what's in local.conf should override, though? at least one might think Apr 11 21:08:28 tesla_: *SLAP* Apr 11 21:08:48 ulf`, ? Apr 11 21:09:27 tesla_: out of date meta-intel? Apr 11 21:09:46 don't think so I just cloned it and is in branch jethro Apr 11 21:09:55 igor: it's set in a distro config. I'm trying to unset it in my local.conf Apr 11 21:10:03 tripzero, Apr 11 21:10:12 humm... Apr 11 21:10:13 tesla_: then maybe it's too new? Apr 11 21:10:32 did you use PNBLACKLIST[foo]:=""? Apr 11 21:10:39 tripzero, but shouldn't it be using the same branch as poky? Apr 11 21:10:46 no. just PNBLACKLIST[foo]="" Apr 11 21:11:01 maybe := work Apr 11 21:11:05 i'll try := Apr 11 21:11:19 but you shoud have your own distro.conf Apr 11 21:11:47 tesla_: maybe. You can search your meta and see if it has linux-yocto_4.4 Apr 11 21:11:52 you can include the distro.conf that you are using and change what you want Apr 11 21:11:56 if not, there's a mismatch Apr 11 21:12:58 igor: Ostro is supposed to be the distro Apr 11 21:14:21 but you want to make a custom image or something, so you can create your own distro using Ostro as include Apr 11 21:14:52 if I can't override it in my local.conf, why would I be able to in my cooldistro.conf? Apr 11 21:15:12 you reset the variable Apr 11 21:15:16 tripzero, just grep the entire meta layer? or is there a specific directory/file I should look for this? Apr 11 21:15:28 tesla_: recipes-kernel? Apr 11 21:15:32 your colldistro.conf will include ostro.conf and after set the PNBLACKLIST Apr 11 21:15:46 igor: okay. will try Apr 11 21:16:31 tripzero, yeap I see it Apr 11 21:17:06 tesla_: it's version 4.4? Apr 11 21:18:08 tripzero, oops I found my error. I cloned meta-intel on master branch. checked out jethro and they both have recipes for 4.1 Apr 11 21:18:39 tripzero, trying it again Apr 11 21:18:44 tesla_: :) Apr 11 21:19:12 tesla_: there's also ostroproject.org that supports minnowboard max out of zee box Apr 11 21:22:01 tripzero, is working now :) Apr 11 21:22:49 tripzero, what's the difference between ostro and yocto? doesn't ostro use yocto build system? Apr 11 21:24:01 ostro is built on top of yocto. has some extra stuff on top for device support and middleware libraries Apr 11 21:27:13 tripzero, mmm I'll have to give it a try sometime Apr 11 21:27:21 tripzero, thanks for the recommendation **** ENDING LOGGING AT Tue Apr 12 02:59:58 2016