**** BEGIN LOGGING AT Thu Dec 13 02:59:58 2012 Dec 13 08:13:30 good morning Dec 13 09:10:55 morning all Dec 13 09:47:48 man, this systemd/udev kay/lennart thing is exasperating Dec 13 09:49:26 I think everyone should have 2 weeks over the holidays of shut the hell up and do something productive Dec 13 10:01:50 jackmitchell: is some kind of flamewar going on at the moment or are you just talking about the general simmering one that never seems to end? Dec 13 10:05:04 bluelightning: the on-going one on G+ ignited by Greg KH set me off this frosty morning Dec 13 10:05:55 bluelightning: https://plus.google.com/u/0/111049168280159033135/posts/WSYEByD8xDp Dec 13 10:07:04 you know it's getting long in the tooth when LT The Messiah starts sticking his oar in Dec 13 10:12:33 gnar felipec Dec 13 10:36:48 jackmitchell: I've got to be honest, whilst I think the fight against libkmod is misguided, I do still have concerns about udev+systemd Dec 13 10:38:29 bluelightning: so we should engage politely with udev upstream to ensure that they don't forget that some people don't want systemd Dec 13 10:38:47 rburton: perhaps, but I think they should know that by now... Dec 13 10:38:58 I'll get popcorn ;-) Dec 13 10:39:11 bluelightning: sure, the key was "politely" so they don't forget :) Dec 13 10:39:17 (whilst also trying devtmpfs for deep embedded where udev is overkill) Dec 13 10:40:14 rburton: I've spoken to Lennart in person and what concerned me most is that he seemed to be talking in terms of udev and systemd as part of an integrated Gnome desktop OS; that is totally orthogonal to the needs of embedded systems Dec 13 10:41:09 of course they're not ignoring embedded but it does seem to be an afterthought Dec 13 10:42:52 agreed, their focus is clearly on an integrated whole. so they either acknowledge the needs of people who are not that integrated hole or accept forks. being generous, we need to ensure that our needs are accounted for by being in the community. Dec 13 10:43:02 not engaging and then moaning isn't going to work well Dec 13 10:44:42 agreed, the most productive thing to do would be to try to engage Dec 13 10:45:13 unfortunately forking is easier than engaging Dec 13 10:45:28 well this gentoo fork is forking for stupid reasons Dec 13 10:45:48 so they'd have trouble engaging Dec 13 10:45:52 from that post at least, it sounds like they tried engaging first Dec 13 10:46:30 Zagor: libkmod is just better, and the / split issue isn't something udev can do anything about Dec 13 10:46:35 systemd just throws a warning, and udev doesn't care Dec 13 10:47:04 rburton: unfortunately I don't know the details, having only read a few gkroah posts Dec 13 11:11:33 hello all Dec 13 11:54:37 bluelightning: ping Dec 13 11:59:50 Noor: hi Dec 13 11:59:59 bluelightning: hi Dec 13 12:00:11 do you know a bit about archiver calss? Dec 13 12:00:13 class Dec 13 12:00:24 not a lot I'm afraid, no Dec 13 12:00:42 I think we did document it a bit recently though, let me just check Dec 13 12:00:42 OK Dec 13 12:01:21 just wanna know that why we have pre/post functions in that class Dec 13 12:01:32 may be can answer in general way Dec 13 12:01:48 bluelightning: can we convert pre/post function in normal task Dec 13 12:01:59 or is there any logic behind it that we can't do Dec 13 12:34:36 JaMa: thanks for your fixes. now only 46 failures from world Dec 13 13:20:31 hrw: oe-core + meta-oe only? Dec 13 13:20:54 oecore + all meta-openembedded layers Dec 13 13:21:15 hrw: hmm I've only 43 with even more layers, so arm64 still causes some? Dec 13 13:21:27 and today it should be a bit less too Dec 13 13:23:33 JaMa: some recipes are too old or lack aarch64 porting Dec 13 13:36:31 I guess AX25 should be different feature in kernel Dec 13 13:37:03 I am referring to "features/" directory in yocto-kernel-cache Dec 13 13:37:58 additionally, it would be good to have ax25 in DISTRO_FEATURES, so when ax25 is referenced, ax25 configuration in kernel is activated Dec 13 13:50:39 eren: we don't really have DISTRO_FEATURES influencing the kernel config at the moment, although there is a bug open to look into that Dec 13 13:51:10 hmm Dec 13 13:52:53 hrw why cannt gnu-configize --force go to autotools.class? Dec 13 13:53:12 check oecore ml archive Dec 13 13:54:02 bluelightning: okie, no problem. I will try to be as modular as yocto kernel Dec 13 13:54:38 people just can copy/paste, and include related ax25 feature in their BSPs Dec 13 13:55:56 hrw so there is no short answer Dec 13 13:55:57 okay Dec 13 14:00:32 How do I uninstall something from sysroot the correct way? Dec 13 14:02:27 I mean without removing everything an compiling from the beginning. I was trying to package fglrx and it replaced the default libGL. Dec 13 14:03:05 what's the general workflow of trying kernel configurations? Suppose that I've built core-image-minimal and keyboard didn't work, I need to enable keyboard in kernel, compile it, and install it on the image. Is it done via package manager (only installing kernel on the image) or should I re-create the image? I guess bitbake does not build untouched packages and only builds linux kernel, calling do_rootfs Dec 13 14:03:07 afterwards? Dec 13 14:07:44 inch hm I think we have no concept for update-alternatives in sysroot Dec 13 14:10:39 Is there a way to force populate_sysroot on some package so I can get the original libGL.so back? Dec 13 14:14:25 inch: bitbake -c populate_sysroot -f recipename Dec 13 14:17:36 How do I find which recipe creates the package? libGL.so.1.2 is in libgl1 but Dec 13 14:17:37 (find sources/ -name \*.bb ; find sources/ -name \*.inc)|xargs grep PACKAGES.*libgl1 Dec 13 14:17:39 returns nothing Dec 13 14:18:01 inch: you can grep tmp/sstate-control Dec 13 14:19:36 Thanks. Dec 13 14:20:13 There is: build/tmp-eglibc/sstate-control/manifest-rwd-x86-mesa-dri.deploy-ipk Dec 13 14:22:06 bitbake -c populate_sysroot -f mesa-dri only tells me that nothing needs to be done. Dec 13 14:23:48 gm all Dec 13 14:24:19 morning likewise Dec 13 14:26:39 inch mesa Dec 13 14:26:42 ah Dec 13 14:26:44 hi likewise Dec 13 14:27:06 inch I think fglrx should not sysroot something Dec 13 14:27:33 inch we should do it like the debian way use mesa for compile and update-alternatives on the target-device Dec 13 14:28:07 inch try bitbake -c clean mesa-dri before Dec 13 14:37:01 * eren huh, linux-yocto is 628MB, my network connection is crying Dec 13 14:41:02 thats the price Dec 13 14:42:32 woglinde: :) Dec 13 14:43:32 woglinde: Thanks. Cleaning the msa-dir helped. I think fglrx needs to put some stuff to sysroot so that xvba-video will compile, but I hope ati version of libGL.so isn't needed for that. Dec 13 14:56:35 huh, cross compiling stuff Dec 13 14:57:02 I guess I need to wait for another 4 hours to complete building and start configuring kernel Dec 13 14:58:51 4 hours? Dec 13 15:01:50 bluelightning: yeah, on a laptop with 1.2ghz two-core cpu Dec 13 15:04:08 eren: ouch Dec 13 15:04:21 eren: and I sometime complain about having it rough! Dec 13 15:06:00 jackmitchell: complain about your build system? :) Dec 13 15:23:43 is it expected that after inheritting buildhistory a lot of garbage (set -x output + git status et.al) is printed to the console? Dec 13 15:24:26 resp. is there a way to make this silent? Dec 13 15:25:40 JaMa: do you remember what causes that? ^ Dec 13 15:28:02 Noor: in terms of implementation details it's probably best to post to the list about it Dec 13 15:32:05 eren: complain about waiting for compiles - but I can guarantee I wait 20 times less that you must on that system! Dec 13 15:36:44 inch ah hm yes xvba Dec 13 15:36:59 inch but wasnt that binary either? Dec 13 15:48:25 does exist a QA report for each of these layers? http://www.openembedded.org/wiki/LayerIndex Dec 13 15:49:10 looks like not all are reliable and successfully buildable Dec 13 15:59:21 mckoan: the intention I think was to have some OE autobuilders that would cover those; work is still ongoing to get those set up I think Dec 13 15:59:33 otherwise, no Dec 13 15:59:50 (well, other than distro autobuilders run by SHR / Angstrom etc.) Dec 13 16:02:37 meta-picosam9 is definitey broken Dec 13 16:03:03 now I'm trying meta-handheld MACHINE=akita just to test Dec 13 16:20:42 ensc_: bluelightning: I don't remember seeing that Dec 13 16:23:13 JaMa: I'm sure I remember you reporting it when you first started using it... Dec 13 16:27:19 it's possible but I don't remember it, sorry Dec 13 16:28:29 ok... np Dec 13 16:29:27 ops Dec 13 16:29:29 ERROR: No valid terminal found, unable to open devshell Dec 13 16:29:36 any ideas? Dec 13 16:30:08 bitbake linux-yocto -c menuconfig, failed Dec 13 16:30:31 do you have screen installed? Dec 13 16:30:46 yeah Dec 13 16:30:58 set the OE_TERMINAL = "screen" then Dec 13 16:30:59 I'm using tmux, though Dec 13 16:31:02 try again Dec 13 16:32:12 to build ttf-droid, OE clones git://github.com/android/platform_frameworks_base.git o_O Dec 13 16:33:34 fray: thanks, apperantly I didn't have screen installed Dec 13 16:33:41 fray: installing screen solved the problem Dec 13 16:33:46 cool Dec 13 16:37:56 should I compile AMD Geode framebuffer support as a module, or built-in? Dec 13 16:38:25 eren: heh, we should add tmux support :) Dec 13 16:38:28 * kergoth is a tmux fan also Dec 13 16:38:59 JaMa: do you have set BB_VERBOSE_LOGS? Dec 13 16:39:16 kergoth: hehe :) I'm running bitbake in tmux btw, installing screen solved the problem somehow Dec 13 16:39:43 eren, the system looks for one of a list of terminal types.. screen happens to be one of them Dec 13 16:40:13 oh okkie Dec 13 16:40:23 yeah, devshell tries a variety of terminals until it finds one it can use Dec 13 16:40:51 * kergoth adds a note to self to add a tmux class to it Dec 13 16:43:39 *g* Dec 13 16:44:01 eren, I suggest a 'bug' (enhancement request) in the bugzilla.yoctoproject.org Dec 13 16:47:58 fray: sure Dec 13 16:48:58 which component? Bitbake, oe-core? Dec 13 16:49:06 oe-core Dec 13 16:49:07 oe-core Dec 13 16:52:15 https://bugzilla.yoctoproject.org/3594 Dec 13 16:52:17 done Dec 13 16:53:59 hello. i need to run python code inside a recipe. this code must be ran before the do_install task, and sets the value of the PACKAGES variable, as well as the FILES and RDEPENDS values of each package. Dec 13 16:54:34 where should this run? unfortunately, I can't use do_install_prepend(), because there is already a do_install() defined, which is not python, but shell script Dec 13 16:55:07 dv_: populate_packages_prepend is where that sort of thing is usually done Dec 13 16:55:20 addtask do_my_python_task before do_install Dec 13 16:55:25 python do_my_python_task () { Dec 13 16:55:28 .... Dec 13 16:55:29 } Dec 13 16:55:30 ah thanks Dec 13 16:55:49 bluelightning: I tried that already, but the problem is that the python code also defines a list of files to install Dec 13 16:55:54 but ya.. if it needs to be run after install, and before packaging.. the do_package_prepend is more normal for that Dec 13 16:56:05 I'll try frays idea Dec 13 16:56:20 dv_ note what I put means it can run -anytime- before do_install.. Dec 13 16:56:28 thats fine Dec 13 16:56:38 if it relies on sources being present, or the configure/compile being done.. you need to add an 'after ' Dec 13 16:56:56 i.e. if you want it between compile and install.. after do_compile Dec 13 16:59:53 addtask do_initialize_package_lists after do_fetch before do_install , this should be fine, right? Dec 13 17:00:15 yup Dec 13 17:04:16 hmm it seems to ignore the task. bitbake -v prints a lot of information. is there a way to just print the tasks it would otherwise run? dry run (-n) seems to fit the bill, but using yocto, I dont see anything printed Dec 13 17:18:14 there are ethernet driver configs that get enabled and I failed to see a file that references all of the "CONFIG_NET_VENDOR_*" Dec 13 17:18:46 I'm including "ktypes/base" in alix3d3.scc file Dec 13 17:19:23 base.cfg file does not reference any NET_VENDO Dec 13 17:19:25 any idea? Dec 13 17:20:38 it most likely is coming from the board default or something.. Dec 13 17:21:55 board default? Dec 13 17:23:28 usually the board or your configuration has a default, and the .scc files just adjust that default.. Dec 13 17:23:43 so if the board config has 'too' many things, you'll need to turn off those items in your local one.. Dec 13 17:23:59 Zedd is the one you want to talk to, but he's traveling today.. so i don't think he's around.. Dec 13 17:24:15 fray: actually, I'm creating a BSP for alix3d3 Dec 13 17:24:35 the default that I use is provided by linux-yocto, I include it in my scc file Dec 13 17:24:40 ok Dec 13 17:24:52 it's "ktypes/base" Dec 13 17:25:06 and none of the files that I reference include "CONFIG_NET_VENDOR" Dec 13 17:25:27 all of the vendors in ethernet drivers are selected by default Dec 13 17:25:30 ok.. then it may be something else (what I don't know) Dec 13 17:40:28 have a working tmux termianl prototype Dec 13 17:40:43 should really rework the terminal code a little, i don't like the subclassing of Popen, better to compose it Dec 13 17:41:20 hrm Dec 13 18:17:15 things that make you go "hrm..." Dec 13 18:17:43 kergoth: do you need testing? Dec 13 18:18:05 let me know when it's ready for testing Dec 13 18:18:50 you can test it now if you like, just concatenate the attachment to meta/lib/oe/terminal.py Dec 13 18:19:00 okkie Dec 13 18:19:13 its default priority is just above screen Dec 13 18:19:25 can always specify it manually too of course, OE_TERMINAL = "tmux" Dec 13 18:21:21 in my custom python task, if I want to set a variable that shall be readable by other tasks (like do_install), what should I use? what I set with d.setVar() seems to get lost Dec 13 18:21:48 kergoth: I can see linux configuration utility without a problem. I'm not sure if screen is used as fallback Dec 13 18:21:50 ##########################################################################################################################| ETA: 00:00:00 Dec 13 18:21:53 ops sorry! Dec 13 18:22:08 OE_TERMINAL="tmux" bitbake linux-yocto -c menuconfig Dec 13 18:22:19 seems to work without a problem Dec 13 18:35:31 here is a copy of the recipe: http://pastie.org/private/lz6fi9nqwb0supxljhgsa Dec 13 18:35:59 it seems as if the variables I set in do_initialize_package_lists() dont exist afterwards anymore Dec 13 18:36:27 correct.. each task is transient.. Dec 13 18:36:44 what you will need to do is dump a file with your settings and then load those setitng sin the do_install Dec 13 18:37:47 somehow the gstreamer recipes can do what I want, but I dont understand why Dec 13 18:37:52 http://gitorious.org/angstrom/openembedded/blobs/56631534045bf91cb47253ba08d0dfcd93b68e69/recipes/gstreamer/gst-plugins-package.inc here is the relevant part Dec 13 18:38:25 for example, a gst-plugins-good-flac package is produced Dec 13 18:38:49 this is because the populate_packages_prepend runs at the same time as populate_packages.. Dec 13 18:38:57 so the var context doesnt' change Dec 13 18:39:26 ah. i see Dec 13 18:39:48 also, is there a difference between bb.data.setVar(... ,d) and d.setVar(...) ? Dec 13 18:40:05 use later Dec 13 18:40:07 the later is the right way to do it.. Dec 13 18:40:09 the former is the 'older' way Dec 13 18:40:12 okay Dec 13 18:40:32 one more thing, is it OK to define the value of the PACKAGES variable in populate_packages_prepend() ? or is it too late then? Dec 13 18:41:16 IMHO you need to define such packages ad PACKAGES_DYNAMIC Dec 13 18:41:19 s/ad/as Dec 13 18:42:04 SOme recent change the eglibc package has broken nativesdk-eglibc Dec 13 18:42:13 24: syntax error Dec 13 18:42:14 collect2: error: ld returned 1 exit status Dec 13 18:42:25 tmp-eglibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-eglibc/2.16-r19/build-x86_64-oesdk-linux/shlib.lds:2 Dec 13 18:42:26 24: syntax error Dec 13 18:43:05 heh looks like issue with make we had for target eglibc too Dec 13 18:43:27 what was the fix? Dec 13 18:43:37 use different make version Dec 13 18:43:57 https://bugzilla.yoctoproject.org/show_bug.cgi?id=2314 Dec 13 18:44:41 my make is 3.81.. but it just started happening.. no idea why.. Dec 13 18:45:05 it's race.. maybe something got a bit faster :) Dec 13 18:45:46 I touched the file and restarted the build Dec 13 18:46:06 same erorr Dec 13 18:46:34 turning off parallel make... Dec 13 19:02:51 failed again.. I even updated to make 3.82 Dec 13 19:05:06 * fray is slowly reverting code to see if I can find it.. Dec 13 19:05:13 check what exactly is on that line Dec 13 19:06:23 it's referring to debuginfo stuff in the linker script Dec 13 19:07:07 assuming my reverts work, I'll start re-applying and figure out where the failure is.. there are only two suspect patches so far.. the AArch64 and the eliminate bash one Dec 13 19:08:13 both reverted.. still failing.. going back further Dec 13 19:15:07 I'm beginning to think the problem isn't eglibc, but something else Dec 13 19:16:12 kergoth: if I don't specify OE_TERMINAL explicity, I get an error with tmux support. Dec 13 19:16:38 kergoth: http://pastebin.com/Gj1sYDpa Dec 13 19:18:22 eren: bitbake bug, it's fixed in master. see https://github.com/openembedded/bitbake/commit/a098ceb Dec 13 19:19:36 kergoth: okkie Dec 13 19:23:01 * fray experences the fun of git bisect.. :P Dec 13 19:25:19 It's more fun than "cvs update -D" Dec 13 19:26:04 anything should be more fun than "cvs *" ? Dec 13 19:30:26 I honestly am not sure if I can even remember how to do CVS.. ;) Dec 13 19:30:43 ok, back Dec 13 19:31:08 (I'm kind of happy to have forgotten CVS.. whenever I still need to use CVS, I always just import it into git) Dec 13 19:31:32 so to summarize, in my recipe, I should rename do_initialize_package_lists to populate_packages_prepend(), modify do_install to not depend on any previously generated values, and done? Dec 13 19:32:33 fray: I used it 1 time for checking out openssl repository Dec 13 19:32:35 hated it Dec 13 19:36:12 how does one disable kernel builds when building images? my images are based on core-image-minimal Dec 13 19:36:28 i would like to save some time omitting kernel builds since i build my kernels outside of oe-core Dec 13 19:37:13 oe assumes you have a 'machine'.. the machine may produce machine specific versions of some recipes.. Dec 13 19:37:23 AFAIK there is no way to build a -filesystem- without building a machine Dec 13 19:37:50 you can build individual packages through... as long as they don't require any machine specific components.. Dec 13 19:50:43 hm. the generated packages are empty :/ Dec 13 19:51:46 FILES_* variables I set in populate_packages_prepend() should be noticed by the package task, since the var context is the same, right? Dec 13 20:43:25 JaMa: is it T-850 in your avatar? :) Dec 13 20:44:22 that's photo from my first incarnation.. now I'm in enhanced version of T-1000 :) Dec 13 20:44:37 dv_: afaik that should be the case, yeah. you can look at PACKAGEFUNCS in package.bbclass to see how/where they're called Dec 13 20:46:12 JaMa: hehe, nice version with a lot of bugfixes + a support for online firmware upgrade via SkyNet :P Dec 13 21:08:38 eren: what about using bitbake syntax for .inc too? Dec 13 21:11:53 JaMa: bitbake.vim already defines it Dec 13 21:12:15 au BufNewFile,BufRead *.inc set filetype=bitbake Dec 13 21:13:01 Are there some restrictions on using ssh protocol with git in oe core Dec 13 21:13:29 i.e. ssh://:port/repo.git Dec 13 21:14:04 it's a bit problematic, though. Some templating (web) engines use *.inc, php can have .inc etc. You cannot know if an .inc file is bitbake. The more clear way would have been using .bbinc extension just as .bbclass or .bbappend Dec 13 21:17:32 JaMa: oh, are you asking about removing bitbake syntax for .inc? Dec 13 21:33:36 eren: ah then sorry, looking at that patch I didn't know it's used for .inc already Dec 13 21:46:28 JaMa: np Dec 13 21:46:38 need to sleep, good night all Dec 13 21:48:35 nite eren Dec 14 01:05:03 that might be a new record Dec 14 01:05:41 the push that broke the build for the second time was less than 2 minutes after my push that fixed the first breakage Dec 14 01:06:10 that's pretty fast... Dec 14 01:10:29 not fun Dec 14 01:44:58 yeah, it hasn't been my favorite day so far... Dec 14 01:45:28 exit Dec 14 01:45:53 wow, the focus jumped a whole display **** ENDING LOGGING AT Fri Dec 14 02:59:35 2012 **** BEGIN LOGGING AT Fri Dec 14 03:00:19 2012 Dec 14 06:03:45 morning Dec 14 08:45:59 good snowy morning Dec 14 08:49:30 hello mckoan Dec 14 09:09:03 morning all Dec 14 09:17:46 hi bluelightning, ant_work Dec 14 09:20:25 meta-openembedded/meta-oe/recipes-graphics/xorg-lib/pixman_0.27.2.bbappend Dec 14 09:20:33 meta-openembedded/meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.3.bbappend Dec 14 09:20:45 I get a ERROR: No recipes available for those :( Dec 14 09:21:38 blitz00: apply patches from patchwork Dec 14 09:25:41 bluelightning: MACHINE=akita ./oebb.sh bitbake console-image, worked smoothly Dec 14 09:26:01 mckoan: great, that's what I would expect :) Dec 14 09:26:19 bluelightning: as far as you know may meta-handheld work with yocto 8 danny too? Dec 14 09:26:36 because seems it won't Dec 14 09:26:44 hmm, why not? Dec 14 09:27:32 bluelightning: http://pastebin.com/uHq9pSwr Dec 14 09:27:56 I simply added the meta-handheld to yocto 8 Dec 14 09:28:05 mckoan: you need meta-initramfs Dec 14 09:28:19 doh, thx Dec 14 09:29:57 bluelightning: BTW how did you argue that? Dec 14 09:30:18 mckoan: what do you mean by argue it? Dec 14 09:32:06 bluelightning: how you understood that is meta-initramfs missing Dec 14 09:32:15 mckoan: klibc.bbclass is in that layer ;) Dec 14 09:33:08 ant_work: clear, thx Dec 14 09:33:19 mckoan: about that, I don't have direct experience building for arm9 Dec 14 09:33:59 bluelightning: if in Angstrom I have meta-openembedded/meta-initramfs, where would you put it in yocto? Dec 14 09:34:36 I wonder if there is any preferred meta* three where to put it Dec 14 09:34:41 s/three/tree Dec 14 09:36:01 mckoan: it's mentioned in the meta-handheld readme Dec 14 09:36:18 mckoan: just add it to bblayers.conf as with any other layer... Dec 14 09:36:23 the extreme use of layers allows you to make any kind of mess :-) Dec 14 09:38:51 bluelightning: apologize me, but in meta-handheld/README there is any hint about meta-initramfs nor where to put it Dec 14 09:39:25 I try to put it at the same level of meta-handheld Dec 14 09:39:42 mckoan: it doesn't matter where on disk the layer is, just that its full path is in bblayers.conf Dec 14 09:40:30 maybe I'm posing a problem that really does not matter Dec 14 09:40:53 was only a couriosity ;-) Dec 14 09:42:23 FWIW, it is mentioned in the (short) list of dependencies in the README file Dec 14 09:45:32 added meta-initramfs http://pastebin.com/4jvnYUN9 Dec 14 09:47:02 maybe I shouldn't try to mix oe and yocto metadatas and stay with oe Dec 14 09:52:49 bluelightning: another couriosity, did you successfully (try to) build meta-handheld with yocto 8 ? Dec 14 09:53:17 mckoan: the metadata in poky is the same as in OE-Core Dec 14 09:53:47 only difference is we add a distro config with some slight tweaks and include a copy of bitbake Dec 14 09:54:31 bluelightning: ok, so it isn's simply a matter of copy-paste metadata Dec 14 09:57:03 we have a tool to manage the repository (combo-layer) so that each commit applied to oe-core is applied to poky Dec 14 09:57:57 basically I am trying to discover an ARMv4/5 architecture building with no errors with Yocto, but is harder than expected Dec 14 10:01:57 mckoan: how can you get klibc-utils_1.5.25.bb is a mystery for me ... was removed long ago from meta-initramfs Dec 14 10:02:24 pls show your bblayers Dec 14 10:03:57 mckoan: we do build with "zarro errors" when using just that 3 layers Dec 14 10:23:50 gm Dec 14 12:10:57 when I was doing "bitbake linux-yocto -c menuconfig", only 362 tasks were run and some packages were compiled Dec 14 12:11:27 now I run "bitbake linux-yocto", I get 901 tasks that needs to be run and it seems that some additional native packages are built Dec 14 12:11:44 is it because DISTRO="poky" is set? Dec 14 12:17:18 yeah :( Dec 14 12:17:19 DISTRO_EXTRA_RDEPENDS += " ${POKY_DEFAULT_EXTRA_RDEPENDS}" Dec 14 12:50:49 hmm kexecboot error message "Can parse keyword LABEL " .. git is the git version on floating development ? Dec 14 12:51:42 pwgen: old cfg format Dec 14 12:52:06 http://kexecboot.org/node/27 Dec 14 12:52:09 ant_work: its a cut&paste from the wiki Dec 14 12:53:17 the raspberry ist booting the kernel, initrd, executing kexec. Dec 14 12:54:20 nice Dec 14 12:54:22 i have for short ( very short ) the frame buffer , and the it ends in kdb, seems my config is wrong .. Dec 14 12:54:30 pls check this: http://kexecboot.org/documentation/how_to_write_config Dec 14 12:55:07 doing that you can add more than one kernel Dec 14 12:55:54 yea i pasted the sample boot.cfg ( unfortunatly i do not have aspare usb keyboard, so i can not enter commands to the rasp ) Dec 14 12:56:18 besides of that, we did implement a workaround for broken framebuffer, th etext-ui Dec 14 12:57:39 i have seend the text ui before, how do i activate it ? kernel parameter ? or rtfc Dec 14 12:58:08 you can build text-ui only specifying config options Dec 14 12:58:23 but there is a sort of autodetection... hmm maybe is broken :/ Dec 14 13:02:01 any idea whats wrong with this boo.cfg ? http://pastebin.com/vdEMbwnc Dec 14 13:02:04 pwgen: that was http://kexecboot.org/node/26 Dec 14 13:03:23 ok i will first rey to get the kexecboot run from console , the i will do it with an initrd .. Dec 14 13:03:37 s/rey/try/ Dec 14 13:03:44 did you add USE_TEXTUI Dec 14 13:04:26 i compiledid it from angstrom oe without any changes . Dec 14 13:04:34 ah.. Dec 14 13:04:35 --enable-textui compile with text user interface [default=no] Dec 14 13:04:56 while there: --enable-debug enable debug output [default=no] Dec 14 13:05:50 you just have to change EXTRA_OECONF Dec 14 13:05:55 ... . ok wait , i have seen, i can start kexecboot from initd , now i will build one that works and boots, .. Dec 14 13:06:00 we do that http://cgit.openembedded.org/meta-handheld/tree/recipes-bsp/kexecboot/kexecboot-handhelds.inc Dec 14 13:06:06 with OE Dec 14 13:07:33 i needed to upgrade the kernel to 3.6 and used a custom kernel config to make it run. did someone seend djwiææis ? so that he can add a linux 3.6 recipe to meta-rasberry Dec 14 13:12:11 fyi it looks like next linux-yocto after 3.4 will be 3.8 Dec 14 13:25:44 isn't it possible to build linux-yocto for testing purposes without building 'packagegroup-core-boot' ? Dec 14 13:26:06 when I change DISTRO variable to "defaultsetup", I only get a NOTe from bitbake Dec 14 13:26:19 NOTE: Your conf/bblayers.conf has been automatically updated. Please re-run bitbake. Dec 14 13:36:02 eren: that is a slight bug Dec 14 13:36:37 triggered when you have created a build directory with meta-yocto in bblayers.conf and then removet meta-yocto Dec 14 13:37:20 to work around it, set LCONF_VERSION to 5 in bblayers.conf Dec 14 13:42:20 bluelightning: okkie, DISTRO='defaultsetup' is still valid, then? Dec 14 13:43:03 eren: that may work, but defaultsetup is really there to support DISTRO = "" so I would suggest you use that instead Dec 14 13:44:29 you mean, using 'poky' as distro? Dec 14 13:44:33 or leaving it blank? Dec 14 13:47:06 eren: I mean setting it to blank, if you want the basic default distro config from OE-Core Dec 14 13:47:20 oh okkie Dec 14 13:47:26 poky is also good too, depends what you want Dec 14 13:48:01 bluelightning: yes, since I'm preparing a BSP and making sure my kernel configs are OK, I don't need extra 'packagegroup-core-boot' right now Dec 14 13:48:35 I don't think DISTRO="" is going to help with that... Dec 14 13:49:08 in any case, I need to build packagegroup-core-boot then? Dec 14 13:49:24 I'm a bit confused because linux-yocto doesn't depend on packagegroup-core-boot, but most core images will Dec 14 13:50:11 bluelightning: yes, but when DISTRO='poky' is set, DISTRO_EXTRA_RDEPENDS is set to packagegroup-core-boot Dec 14 13:50:48 maybe, but that doesn't affect linux-yocto Dec 14 13:51:52 oh, bitbake now compiles cross tools again Dec 14 13:52:15 bluelightning: when I invoked "bitbake linux-yocto -c menuconfig" there were 375 tasks to be run Dec 14 13:52:23 it built the toolchain Dec 14 13:52:30 and I was presented with menuconfig Dec 14 13:52:58 when I attempted to build linux-yocto with "bitbake linux-yocto", suddently, the number of tasks need to be run was 970 Dec 14 13:53:06 yes changing DISTRO will force a lot of things to rebuild Dec 14 13:53:25 :( Dec 14 13:53:46 because DISTRO sets the vendor string which is used in a lot of paths Dec 14 13:53:48 that was the reason that I got the impression that DISTRO_EXTRA_RDEPENDS was the main cause Dec 14 13:53:53 it's not Dec 14 13:54:06 when you run bitbake linux-yocto you're really saying bitbake linux-yocto -c build Dec 14 13:54:21 so, what's the difference between "bitbake linux-yocto" and "bitbake linux-yocto -c menuconfig" Dec 14 13:54:34 and that means it also has to package the kernel which means it needs to build the packaging tools etc. Dec 14 13:54:48 nearly 600 tasks are introduced Dec 14 13:55:26 oh poor me, now I need to go with DISTRO=poky and start again Dec 14 13:55:37 * eren wait for another 3 hours Dec 14 13:55:41 no need to start again, when you set it back it will reuse whats there Dec 14 13:55:56 unless you deleted tmp and sstate-cache Dec 14 13:56:46 no, I didn't delete anything and didn't force bitbake to exist. Always waited bitbake to gracefully finish Dec 14 13:57:49 now, hit the bug twice Dec 14 13:57:49 you can ctrl+c once and it will finish whatever it is currently doing gracefully Dec 14 13:58:00 NOTE: Your conf/bblayers.conf has been automatically updated. Please re-run bitbake. Dec 14 13:58:11 setting LCONF_VERSION=5 doesn't help Dec 14 13:58:22 no, it needs to stay at 6 for poky Dec 14 13:58:54 oh okay Dec 14 13:59:04 maybe it's about time I fixed that properly Dec 14 13:59:44 parsing the recipes right now, let's see if anything will be compiled again Dec 14 14:01:47 oh, yay! Dec 14 14:02:05 so, extra 600 tasks come from packaging utilities, not from package-core-boot Dec 14 14:02:17 I will not bother waiting for them, then Dec 14 14:02:21 yes, that is almost certainly correct Dec 14 14:02:33 if all you want to do is compile the kernel, specify -c compile Dec 14 14:07:43 bluelightning: thanks Dec 14 14:13:22 we have libc6, libc6-dev, libc6-dbg but eglibc-staticdev - anyone know why debian_names do not do staticdev? Dec 14 14:27:19 hey. which recipe provides the nandwrite utility? Dec 14 14:28:56 mtd-utils Dec 14 14:30:17 ops Dec 14 14:30:20 116M vmlinux Dec 14 14:30:24 it's not stripped Dec 14 14:30:45 I failed to see any reference that strips vmlinux in {kernel,kernel-yocto}.bbclass Dec 14 14:31:08 ant_work, thanks Dec 14 14:31:16 yw Dec 14 14:31:30 any idea? Dec 14 14:34:42 hm yeah, it's get stripped while packaging I gues Dec 14 14:39:49 pwgen: any luck? Dec 14 15:19:29 hmm, what do I need to be able to use do_compile_append_class-ptest() ? I'm looking at native.bbclass but it's not obvious to me which bits are relevant. Dec 14 15:20:36 ant_work: my daughter is awaken, and needs more attention as the rasp........(:-(( Dec 14 15:21:27 pwgen: heh, sweet Dec 14 15:46:21 errordeveloper: 116M vmlinux is not that bad. We had 4GB ones in past Dec 14 16:14:01 Excess flood? Dec 14 16:14:12 it's been a long time I saw that message :) Dec 14 16:16:11 bzImage has been stripped to 2.8MB, which normal I guess Dec 14 16:17:07 has anyone attempted to go below 2.8MB ? Dec 14 16:19:27 omg, can anyone please warn vivijim Dec 14 16:19:54 he/she is connecting from a network allocated to intel Dec 14 16:20:46 * kergoth /ignore vivijim JOINS PARTS QUITS Dec 14 16:21:39 seems like he's running wifi on ios6 Dec 14 16:22:49 he is using bip purple irc Dec 14 16:23:31 he is probably not reading it, and will see when he is connected :) Dec 14 17:07:45 I am going to guess that a default oe-core build does not include the DISRO_FEATURE bluetooth? Dec 14 17:10:58 Crofton|work: see meta/conf/distro/include/default-distrovars.inc Dec 14 17:11:08 looks like it is included in the default value of DISTRO_FEATURES Dec 14 17:11:08 that would be to eay Dec 14 17:11:10 Thanks Dec 14 17:11:13 interesting Dec 14 17:12:47 wonder why it defines a seemingly unused OEINCLUDELOGS Dec 14 17:28:15 moin Dec 14 17:46:59 Outlook Express! Dec 14 17:48:50 you mean LookOut! Dec 14 17:49:36 OE - Outlook Express channel! whoo hoo! Dec 14 17:50:16 ? Dec 14 17:51:19 this is the #oe channel Dec 14 17:54:40 packagegroup-base and packagegroup-core-* Dec 14 17:54:41 lovely Dec 14 17:56:48 yes, that has become common now. I just installed similar ones for CentOS yesterday Dec 14 17:57:15 morning Dec 14 18:16:13 moin Dec 14 18:16:36 oh, wrong window/tab... Dec 14 18:17:56 evenin' Guvnor Dec 14 18:18:59 it's another fire-drill test day Dec 14 18:20:37 SDG Dec 14 18:21:24 ? Dec 14 18:26:56 Super Duper Groovy Dec 14 18:31:26 if "bluetooth" in distro_features and not "bluetooth" in machine_features an Dec 14 18:31:26 d Dec 14 18:31:37 I am having trouble understanding this lie Dec 14 18:31:38 line Dec 14 18:46:27 Crofton|work: if bt is supported by the distro, but not the machine. at a guess, that's the bits that pull in bt stuff even if your machinedoesn't have it, if you have a bus (pci/usb) that could expand to gain it Dec 14 18:46:31 * kergoth shrugs, going from memory Dec 14 18:47:31 yeah I am having trouble getting my head around it :) Dec 14 18:56:32 Crofton|work: is the board meeting today or not? Dec 14 18:56:36 If so, what time? Dec 14 18:59:50 I suggested 2000 UTC Dec 14 19:00:19 that is in the evening for likewise and I ahve not heard from him Dec 14 19:01:04 let sget together then anyway Dec 14 19:04:36 Crofton|work: k. I was wondering since we didn't see a response from likewise and since denix indicated he couldn't make that time. Dec 14 19:09:08 darknighte: yes, I missed my window - in meetings now... Dec 14 19:10:37 stupid meetings Dec 14 19:10:48 I should have thought that Friday night might be bad for likewise Dec 14 19:11:01 I suspect he is better off during eu day time Dec 14 19:12:28 how are ou guys on Monday? Dec 14 19:40:09 JaMa: for some reason still we get /lib and /usr/lib in the linker search paths, have you seen the same Dec 14 19:41:38 levonmaa check the makefiles Dec 14 19:42:42 levonmaa: yes for qtdeclarative Dec 14 19:42:55 levonmaa: it's that MODULEPATH Dec 14 19:44:43 woglinde: yes, thats were I see tehm Dec 14 19:45:17 JaMa: I'm seeing them also in recipes that try to use qtbase and qmake Dec 14 19:45:46 that are not qt modules Dec 14 19:46:05 let me find the exact name of that variable Dec 14 19:46:52 2012-12-12.log:20:13 < JaMa> looks like MODULE_LIBS is set to /usr/lib Dec 14 19:49:26 qt_functions.prf:58 MODULE_LIBS = $$eval(QT.$${1}.libs) Dec 14 19:54:49 Crofton|work: my Monday looks mostly open for now for a quick meeting... Dec 14 20:40:45 JaMa: somehow I dont think that the /usr/lib is coming from MODULE_LIBS Dec 14 20:40:57 JaMa: atleast I can not find any evidence for that Dec 14 20:58:32 JaMa: The cause is the .prl files under ${STAGING_LIBDIR} Dec 14 20:59:13 It gets picked up from there Dec 14 20:59:52 the question that I have is that why is it using them? Dec 14 20:59:54 levonmaa good you fond it Dec 14 21:00:14 google for it? Dec 14 21:06:27 levonmaa: I'm rebuilding it again, because something was indicating MODULE_LIBS in my log Dec 14 21:07:14 woglinde: meta-java pukes with sstate Dec 14 21:07:39 woglinde: some of the packages like jamvm hardcode staging paths into binaries for classpaths Dec 14 21:08:03 so when I use sstate to repopulate the build on a si differnet box in different dir Dec 14 21:08:08 it all breaks Dec 14 21:08:27 I dont see easy fixes here Dec 14 21:08:37 but may be you can add it to README Dec 14 21:08:41 for meta-java Dec 14 21:08:51 so people have right expectations Dec 14 21:10:00 hey. is it possible to build two images with different /etc/fstab contents at the same build? i was thinking to make different packages, but i remember that bitbake complains if more packages install the same file on the sysroots (i.e. /etc/fstab), and i am not sure if it will work correctly. any ideas? Dec 14 21:10:33 I don't believe you can do that currently.. Dec 14 21:10:57 we've talked about enhancing the ysstem to allow you to specify rootfs generation and image generation things, with them munging the etc/fstab for you to match your desired system.. Dec 14 21:10:58 khem hm Dec 14 21:11:01 but that is far from implemented Dec 14 21:11:03 so my only chance is the rootfs postprocessing? Dec 14 21:11:16 which also means upgrades should be handled in a proprietary form Dec 14 21:11:32 khem could you make a patch for the readme? Dec 14 21:11:56 rootfs post processing yes.. but on-target upgrades are fine from the feeds Dec 14 21:12:10 the /etc/fstab shouldn't be affected by that Dec 14 21:12:53 hmmm... i want to be able to update /etc/fstab if necessary Dec 14 21:13:37 that's why i was thinking of two different packages Dec 14 21:13:47 fstab is one of those things that you shouldn't update from a package.. it's meant to be system specific.. Dec 14 21:14:02 one option you have is to provide it in a 'machine' recipe.. and then choose different machines.. Dec 14 21:14:23 machine packages have a higher priority then regular packages Dec 14 21:14:34 ty fray; i'm having two different images for the same machine :) one for the NAND, one for the SD card Dec 14 21:15:08 and they each require different mount points Dec 14 21:15:17 define two different machine recipes that depend on a common recipe.. Dec 14 21:15:22 sorry not recipe. Dec 14 21:15:27 -configuration- Dec 14 21:15:35 then define machine specific -recipes- to define the fstab.. Dec 14 21:15:48 so basically, you're suggesting to have two machines Dec 14 21:16:21 as far as my understanding goes Dec 14 21:18:09 what about defining fstab as an alternative? Dec 14 21:19:35 you could do that as well.. but I suspect it's safe for the dual machine configurations.. Dec 14 21:21:00 fray, appreciate the talk - thanks Dec 14 21:21:15 np Dec 14 21:22:36 JaMa: right Dec 14 21:24:24 JaMa: so what think need to happen is manually sed atleast the prl files Dec 14 21:24:39 same might apply to pkg conf files as well Dec 14 21:25:21 and those .prl files are bad already in source? or are they mangled by our build? Dec 14 21:26:49 I dont think that they get mangled, they just get generated incorrectly... Dec 14 21:27:00 let mea ctually check the generatino Dec 14 21:27:20 if we can cleanly influence that stage Dec 14 21:50:36 JaMa: during installation some one combes the prl files and transfogrifies the paths Dec 14 21:51:16 as if you look at the /lib dir and compare that to where they installed Dec 14 21:51:19 the paths are different Dec 14 21:56:35 JaMa: even in the desktop world they sed them during installation... Dec 14 21:56:38 -$(SED) -e "s,/home/mikko/src/qtbase/include,/opt/qt/qt5/include,g" -e "s,/home/mikko/src/qtbase/lib,/opt/qt/qt5/lib,g" "../../lib/libQtCore.prl" >"$(INSTALL_ROOT)/opt/qt/qt5/lib/libQtCore.prl" Dec 14 21:59:15 That is from the Makefile under src/corelib Dec 14 21:59:27 did it change since qt4? Dec 14 21:59:37 JaMa: did nto compare Dec 14 21:59:39 maybe we had some fix for this behavior in qt4 Dec 14 21:59:50 yep, check qt4.inc Dec 14 21:59:57 do_install Dec 14 22:00:09 btu still the Makefile is generated by qmake Dec 14 22:00:48 which is a bigger PITA, qmake or cmake? discuss... Dec 14 22:01:41 waf kills them both laughing :) Dec 14 22:02:09 Its Friday and I want to have a nice weekend ;) Dec 14 22:10:55 JaMa: the sed matching and replacement is controlled by qt_module.prf Dec 14 22:11:08 192 lib_replace.match = $$[QT_INSTALL_LIBS/get] Dec 14 22:11:09 193: lib_replace.replace = $$[QT_INSTALL_LIBS/raw] Dec 14 22:13:09 JaMa: so actually we should tweak the qt.conf file generation in qtbase.inc Dec 14 22:13:47 JaMa: I'll give it a go and see what it breaks ;) Dec 14 22:16:37 great :) Dec 14 22:24:31 Crofton|work: Monday will work in the afternoon for me. Dec 14 22:25:38 K Dec 14 22:25:41 ER Dec 14 22:25:45 DEFINE AFTERNOON :) Dec 14 22:25:49 urg Dec 14 22:25:52 stupid kb Dec 14 22:34:24 that would be the hours between lunch and supper Dec 14 22:46:28 JaMa: not as simple as tweaking the Library value in qt.conf as that will screw up the install locations... **** ENDING LOGGING AT Sat Dec 15 02:59:58 2012