**** BEGIN LOGGING AT Tue Feb 14 02:59:56 2012 Feb 14 07:14:31 hi there Feb 14 07:14:45 need to clarify one thing Feb 14 07:15:32 if I have 2 recipes providing same things it says that I need to set PREFERRED_PROVIDER Feb 14 07:15:49 If I set DEFAULT_PREFERENCE In one recipe will that work Feb 14 07:15:56 hi pb_ Feb 14 07:38:48 good morning Feb 14 07:39:27 morning. Feb 14 07:39:39 morning Feb 14 07:41:02 had anyone success with compiling and running firefox? my results are a white window, without any button/widgets inside. Feb 14 08:48:40 how can I change a .bb file, and then run bitbake console-image to include that change. Do I have to delete something in my build directory? Right now I don't know how to do it without deleting the whole build directory, which seems like an overkill Feb 14 08:59:55 mertsas: sounds like you are confused, please define "change a .bb file" Feb 14 09:03:02 mertsas: usually you change the version number in the bb file to make bitbake understand that it should rebuild the recipe Feb 14 09:03:46 * tasslehoffwrk is often confused and hopes he therefore understood mertsas Feb 14 09:04:24 so, normally increasing the number in PR Feb 14 09:16:57 : try bitbake -b /path/to/bbfile -c cleansstate ( with 2 "s" not cleanstate) Feb 14 09:17:31 and then rebuild your changed package Feb 14 09:41:47 morning all Feb 14 09:42:12 morning Feb 14 09:44:48 morning Feb 14 09:54:51 hi bluelightning Feb 14 09:55:06 hi JaMa|Off, anarsoul, Noor Feb 14 09:55:58 tasslehoffwrk: looks like what I was looking for. Either that or the tip by pwgen. Feb 14 10:06:17 is it possible to list the modules that will be built as dependencies of a module? Feb 14 10:19:34 I'm still using OE classic and I want to add Qt 4.8.0. Can I just copy the recipies from oe-core? Or is there a better way to get it working? Feb 14 10:25:18 morning bluelightning, florian, all Feb 14 10:25:30 hi pb_ Feb 14 10:25:39 hey pb_ Feb 14 10:25:44 hi florian Feb 14 10:25:54 kobe_: you can't Feb 14 10:26:44 well, in theory there's nothing stopping you copying the entire qt4 dir and classes/qt4*.bbclass Feb 14 10:26:52 but no guarantees it will work Feb 14 10:26:58 I tried this myself and it took me quite a while to get it working... Feb 14 10:28:22 ok, thanks Feb 14 10:32:49 How much work does it take to move a project with around 40 own recipies to the new openembedded? Will it require or full rewrite of most scripts or is it quite straightforward? Feb 14 10:33:27 I'll probably require some fiddling with the recipes but it is more time-consuming than difficult. Feb 14 10:33:42 kobe_: should be quite straightforward... shouldn't need any rewriting Feb 14 10:33:56 kobe_: are you using do_stage() anywhere? Feb 14 10:35:09 mertsas: for dependency graph you can use 'bitbake -g - u depexp ' Feb 14 10:36:25 No, I don't use do_stage. Feb 14 10:37:24 kobe_: ok, that removes one of the more annoying bits about migrating Feb 14 10:38:04 Is there documentation on the new oe somewhere? The site still seems to focus on the classic OE Feb 14 10:38:21 kobe_: the basics: http://www.openembedded.org/wiki/OpenEmbedded-Core#Required_changes_for_existing_metadata Feb 14 10:38:35 ok, thanks! Feb 14 10:39:01 kobe_: other than that you'd want to put any custom changes you made to OE metadata in the form of bbappends in your own layer Feb 14 10:39:27 and I guess there may possibly be cases where you need to adapt to recipe upgrades Feb 14 10:41:20 with OE metadata, you mean the recipies in OE? Feb 14 10:42:08 kobe_: yes, existing recipes Feb 14 10:42:20 ok, thanks. Feb 14 12:03:44 thanks icanicant Feb 14 12:45:39 Someone using OpenJDK with OE/Yocto? Feb 14 13:20:46 otavio: I'm trying these days unsuccessfully Feb 14 13:22:00 mckoan: I am using it; i fixed the last issues i had for building it Feb 14 13:22:14 mckoan: but now i am looking how to use gtk to make widgets look nicer Feb 14 13:32:03 otavio: are you using it in oe-classic? Feb 14 13:32:46 I haven't switched to oe-core(yocto) yet Feb 14 13:32:51 mckoan: no; oe-core Feb 14 13:33:02 mckoan: i'm moving all projects out of oe-classic Feb 14 13:49:23 In case anyone is interested, I've written up a few notes on using the meta-kirkwood layer for Kirkwood devices with OE Core: http://www.kelvinsthunderstorm.com/open-embedded-for-marvell-kirkwood/ Feb 14 13:52:18 icanicant: awesome, I will add a link to that on the layer index page Feb 14 13:52:53 icanicant: great, time to bitbake it Feb 14 13:53:10 icanicant: however btw it's OpenEmbedded rather than Open Embedded and it's probably not correct to say OpenEmbedded Linux either ;) Feb 14 13:54:33 bluelightning: pedant, but correct ;-) Feb 14 13:54:36 bluelightning: Pedantic is good. I'll fix it up, thanks :) The Linux bit I just added for those people who didn't know what OE was - I'll reword it. Feb 14 13:54:44 bluelightning: thanks a lot for buildhistory improvements, if you want more test data SHR builders are also using it for a while :) Feb 14 13:55:09 JaMa|Off: np Feb 14 13:55:16 JaMa|Off: ok, will check it out, thanks Feb 14 13:58:47 bluelightning: fixed, cheers! Feb 14 13:59:06 icanicant: ok, linked to the updated version :) great post, thank you Feb 14 14:01:43 is there a way to get a graph of the dependencies. bitbake -g -u depexp only gives me the dependendcies, not a tree which shows which dependencies pull in which other dependencies. Feb 14 14:02:01 I'm trying to figure out why my kernel builds libx11 Feb 14 14:02:03 icanicant: your Kelvin's Water Static Machine looks terrific Feb 14 14:02:30 I didn't know it Feb 14 14:04:32 mertsas: bitbake -g will produce some .dot files which can be visualised using the graphviz tools, however they are quite large Feb 14 14:05:06 mertsas: you may find you can pare them down to something sane with grep Feb 14 14:05:30 bluelightning: where do these files reside? in the build directory? Feb 14 14:05:49 mertsas: they are written to the current directory I think (which will probably be your build dir, so yes) Feb 14 14:06:14 mckoan: the image came from sparkmuseum.com. haven't quite got round to building my own yet :) Feb 14 14:06:15 they won't be written if you have -u depexp on the command line as well though... you want bitbake -g Feb 14 14:06:28 bluelightning: ok, thanks. I'll try that Feb 14 14:08:04 bluelightning: should it be possible to do graphviz pn-depend.dot then to get a graph? Feb 14 14:08:29 mertsas: I think the appropriate command is "dot" (which is part of graphviz) Feb 14 14:08:51 bluelightning: thanks. I'll try that out then. never use graphviz before:P Feb 14 14:09:08 mertsas: I hadn't played with it either until about a year ago :) Feb 14 14:10:11 and with the -u depexp it's a nightmare finding out where the bad dependencies are pulled in. Kind of weird to see that u-boot requires libx11 and some other x packages Feb 14 14:10:53 icanicant: maybe you missed the first step related to getting oe-core Feb 14 14:10:54 hmm, if we can improve these tools I'd really like to do so... it's just about figuring out how to analyse and display the information Feb 14 14:12:17 mckoan: i think Angstrom's oebb.sh step downloads the oe-core sources Feb 14 14:15:25 icanicant: uh, fine thx Feb 14 14:16:39 ./oebb.sh config sheevaplug Feb 14 14:16:48 bluelightning: do you know how dot works? seems to just output the file again when I do dot pn-depends.dot Feb 14 14:17:24 mertsas: I'm trying to see if I have the command line from the last time it was using it, hang on a sec Feb 14 14:17:33 thanks bluelightning Feb 14 14:19:20 mckoan: still haven't had a chance to try it on a sheevaplug yet, later this week i hope. works well on a netgear stora though. Feb 14 14:20:28 icanicant: build is in progress ;-) Feb 14 14:21:56 I think there must be many useless layers Feb 14 14:22:55 mckoan: for the first experience I don't suggest you to use many layers as done by that scripts Feb 14 14:23:14 (useless for sheevaplug console-image) Feb 14 14:23:50 mertsas: hmm, can't find it, but I think all you need to do is "dot -T filename.dot > outputfile" Feb 14 14:23:50 ant_work: unfortunately first experience is the one which scares new users Feb 14 14:24:03 mertsas: where can be png, pdf, svg etc. Feb 14 14:24:13 bluelightning: ok, thanks. I'll tru that Feb 14 14:24:15 try* Feb 14 14:24:30 mertsas: I usually just pipe the output to okular or some other image viewer that can read stdin (using - as the file) Feb 14 14:24:50 mertsas: unfortunately the size of the output image can be quite large :( Feb 14 14:25:14 ant_work: maybe now I'm having an enlightenment about the birth of oe-lite Feb 14 14:25:18 mckoan: some layers are more dangerous than others Feb 14 14:25:32 bluelightning: yeah, was extremely large. Need something better than feh to show this and scroll:P Feb 14 14:25:59 mertsas: as I mentioned earlier you might want to try paring down the dot file first with grep Feb 14 14:26:26 mckoan: imho in sight of less future maintainance the BSP layers should depend on oe-core only Feb 14 14:28:39 find: `/home/koan/yocto/setup-scripts/sources/meta-kirkwood': No such file or directory Feb 14 14:28:48 Setup for sheevaplug completed Feb 14 14:29:03 source ~/.oe/environment-core Feb 14 14:29:32 icanicant: source ~/.oe/environment-core Feb 14 14:29:32 bash: /home/koan/.oe/environment-core: No such file or directory Feb 14 14:29:46 missing step Feb 14 14:30:54 mckoan: you like the hard way ;) Again, look at this basic things https://wiki.yoctoproject.org/wiki/OpenEmbedded-Core Feb 14 14:31:18 icanicant: http://pastebin.com/sLxyH7fg Feb 14 14:31:26 (why the h. is the env-file in user home... :/) Feb 14 14:32:04 mertsas: my guess is it'll be dbus that's causing a build of libx11 Feb 14 14:32:16 mertsas: a somewhat annoying dependency chain :/ Feb 14 14:32:24 ant_work: I have no time to learn now, just o follow a step-by-step, I have to postpone it now :-( Feb 14 14:37:21 bluelightning: yeah, it is. both desktop-file-utils-native and pkgconfig depends on glib-2.0, which depends on dbus, which depends on libx11. Is there a reason pkgconfig and desktop-file-utils-native depends on glib? seems kind of strange Feb 14 14:38:03 at least since glib depends on pkgconfig, so I don't see why pkgconfig depends on glib at least Feb 14 14:38:12 desktop-file-utils-native I have no idea what is:P Feb 14 14:39:38 ant_work: i already tested that wiki, now I was testing this http://www.kelvinsthunderstorm.com/open-embedded-for-marvell-kirkwood/ Feb 14 14:41:07 mertsas: pkg-config requires glib unfortunately :/ Feb 14 14:41:57 mertsas: desktop-file-utils is a set of tools used to inspect .desktop files (used by desktops such as gnome and KDE to provide a way to launch applications) Feb 14 14:42:07 bluelightning: so it's not something that's just weird in oe? Do dbus also require libx11? Feb 14 14:42:35 mertsas: dbus can be built without it but in our default configuration it is configured to build with it Feb 14 14:43:01 mertsas: if you remove x11 from DISTRO_FEATURES you should be able to build an X-less system, however it depends on whether that's what you ultimately want or not Feb 14 14:44:17 bluelightning: ok, I'll to that then. Trying to build a minimal console image right now, just to get things up and running. Right now I build something, but it doesn't do anything after the kernel is loaded Feb 14 14:45:30 mertsas: bear in mind that if you change DISTRO_FEATURES you need to rebuild anything that checks the items you added/removed Feb 14 14:46:14 bluelightning: yeah, that's ok. It's just an intermediate step, so Feb 14 14:46:21 mckoan: I'd add the meta-kirkwood layer by hand Feb 14 14:46:51 on the top of a clean oe-core checkout Feb 14 14:49:05 though, I see the layer depends on both meta-openembedded and meta-angstrom Feb 14 14:49:34 mckoan: i'll try the steps on a fresh folder here. Feb 14 14:49:46 which is strange for a kernel Feb 14 15:00:21 ant_work: the README was originally borrowed from meta-ti which claims those dependencies, i'll sort it out Feb 14 15:04:29 icanicant: you've put together a very nice README. Will borrow soon ;) Feb 14 15:09:37 mckoan: my bad, looks like that layers.txt mod just works for my github account. it should be "meta-kirkwood,git://github.com/kelvinlawson/meta-kirkwood.git,master,HEAD". fixed the instructions now. Feb 14 15:20:52 icanicant: what about source ~/.oe/environment-core ? Feb 14 15:22:37 mckoan: does that not exist? possibly it's because the git clone failed and will work now. Feb 14 15:25:48 icanicant: is a typo : environment-oecore Feb 14 15:26:43 icanicant: bitbaking now ;-) Feb 14 15:27:54 mckoan: oops, typo fixed. ta! Feb 14 15:28:18 mckoan: can you tell you're the first person to follow the steps? ;) Feb 14 16:20:47 I'm getting a couple of these warnings: pam_cracklib.so links to something under exec_prefix, what do they mean? Are they something to care about? Feb 14 16:21:40 it's when someting e.g. in /bin links /usr/lib Feb 14 16:21:54 so such binary won't be usefull without /usr Feb 14 16:22:18 JaMa|Off: ok, so basically it mean that I have to make sure /usr is in my rootfs tarbal Feb 14 16:22:21 ? Feb 14 16:23:22 also have a similar warning with bash, where it finds a reference to /usr in bash/bin/bashbug and the message: WARNING: QA Issue: Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix Feb 14 16:31:13 mertsas: it's similar warning Feb 14 16:31:21 as long as you always have /usr around you're safe Feb 14 16:31:29 ok, thanks Feb 14 16:31:57 have some problems getting the rootfs up and running, so wondered if these might be the root of the problem Feb 14 16:32:03 if mount gets linked to something in /usr then it's much worse then if it's bashbug or something like that Feb 14 16:34:20 currently it's pam_cracklib, bashbug, libgudev udevd and pam_cgroup that throws this warning Feb 14 16:34:44 and systemd stuff Feb 14 16:37:02 hmmmm.... I got this though, for pam_systemd.so, where ldd reports: libsystemd-daemon.so.0 => not found, seems a bit more critical:P Feb 14 16:37:12 I have the same and many more.. but rootfs should work as you have /usr in the same filesystemd Feb 14 16:38:08 here it finds it fine libsystemd-daemon.so.0 => /lib/libsystemd-daemon.so.0 (0x40045000) Feb 14 16:38:55 maybe that's the reason I can't go into rootfs? Feb 14 16:42:12 or doesn't systemd have anything to do with init? Feb 14 16:42:40 systemd is init Feb 14 16:43:09 ok, so the fact that libsystemd-daemon is no where to be found should be a huge problem then:P Feb 14 16:43:47 is it nowhere or jsut ldd pam_systemd.so doesn't see it? Feb 14 16:43:55 try ldd /sbin/systemd :) Feb 14 16:44:10 not sure. I'll have to see when it finishes compiling Feb 14 16:44:32 hmm /bin/systemd is not linked to libsystemd-daemon Feb 14 16:45:16 ok, so if /bin/systemd exists on the system it should work? Feb 14 16:45:51 if /bin/systemd works then yet Feb 14 16:45:52 s Feb 14 16:46:42 can you tell me the order of things after the kernel is loaded btw? I'm quite unsure here, but as far as I understood the kernel runs /sbin/init when it's booted? what does this program do then? Feb 14 16:47:49 starts configured services (depends on used init, systemd finds enabled services in /etc/systemd/) Feb 14 16:48:29 sysvinit is more interested in /etc/inittab and /etc/rc.* Feb 14 16:50:27 so if I use sysvinit, it reads /etc/inittab, while systemd read /etc/systemd/ config files? Feb 14 16:51:15 + /etc/rc.* for sysvinit Feb 14 16:52:41 ok, where do one define if one should use sysvinit vs systemd? sound like I should be using sysvinit. Also get "not a dynamic executable" when doing ldd /mnt/rootfs/bin/systemd, so seems to be something wrong there Feb 14 16:52:58 have a nice rest of the day Feb 14 16:53:21 mertsas: you're using x86 ldd for arm binary or something like that? Feb 14 16:53:43 yeah, true. Damn Feb 14 16:53:46 mertsas: and used init is usually specified in some task-* recipe, depends on image Feb 14 16:54:03 and currently it's not easy to switch back and forth Feb 14 16:54:55 ok, thanks. I'll look around and see what I'm using. thanks for the help. Think I'm going home for now, and have a look at this tomorrow. Probably bugging you guys some more:P Feb 14 16:55:23 check ML there is couple of discussions about systemd/sysvinit Feb 14 16:56:46 I'll have a look Feb 14 16:56:49 thanks again Feb 14 18:02:39 Ah, it looks like the configme tool is responsible for pulling together the kernel config fragments depending on the KBRANCH and KMACHINE which get set by the linux-yocto*bb Feb 14 18:03:16 * kenws wonders what's required in order to configure the kernel for vexpress_defconfig Feb 14 20:32:53 hi guys Feb 14 20:33:05 need recipe guru asistance Feb 14 20:34:54 so i am trying to build libmp3splt library Feb 14 20:35:16 here is my recipe and what i am having on output Feb 14 20:35:17 http://pastebin.com/m7J5n3Mx Feb 14 20:35:32 what am i doing wrong? Feb 14 20:38:07 hello? Feb 14 20:38:23 everybody sleeps? Feb 15 01:05:08 oh; firefox 10.0.1 building Feb 15 01:05:10 :) **** ENDING LOGGING AT Wed Feb 15 02:59:57 2012