**** BEGIN LOGGING AT Wed Mar 07 02:59:58 2012 Mar 07 05:52:28 where are the kernel sources in an oe/bitbake tree? Mar 07 05:52:53 i've built a whole image, several actually, and i'm trying to figure out where the kernel is hiding. Mar 07 05:55:43 ah, i found it: build/tmp-angstrom_2010_x-eglibc/sysroots/beaglebone/kernel/ Mar 07 06:10:13 hi Mar 07 06:10:22 i am using the latest version of OE Mar 07 06:11:28 I am having some issues with package libpng Mar 07 06:13:11 within the recipe file there is a parameter BBCLASSEXTEND Mar 07 06:13:32 BBACLASSEXTEND="native" Mar 07 06:16:52 in recipe it try to fetch the package and unpack in build/tmp/work/i586-linux/libpng-1.2.46-r3.0/ Mar 07 06:17:04 that's fine Mar 07 06:18:28 it will compile the package and install the package Mar 07 06:35:42 after that it fails Mar 07 06:35:46 plz find the log Mar 07 06:35:50 http://pastebin.com/6mUskUQ1 Mar 07 09:02:23 good morning Mar 07 09:48:25 I'm trying to replicate an OE build system but I am having trouble running ti_cgt_c6000_6.1.17_setup_linux_x86.bin does nothing to messages whereas on the existing system running this file starts to prompt me for actions. IS there somesort of licensing required to use the ti stuff? Mar 07 09:48:47 *no messages, Mar 07 10:01:27 morning all Mar 07 10:08:44 hi pb_ Mar 07 10:20:32 gm Mar 07 10:21:43 hi likewise Mar 07 10:24:46 Hi Jin^eLD Mar 07 10:25:03 (tab completion really helps here :) ) Mar 07 10:25:30 hehe Mar 07 10:30:47 good morning Mar 07 10:37:12 morning florian, mickey_office, all Mar 07 10:37:21 good morning likewise Mar 07 10:37:38 florian: didn't see you at EW2012, where you there? Mar 07 10:38:03 likewise: yes, the whole time... did you see Nils? Mar 07 10:38:32 florian: nope. I didn't have much time to wander around though, we had to man two demo stands. Mar 07 10:39:36 likewise: very good... similar problem here :) Mar 07 11:05:29 Hi All Mar 07 11:05:37 i want to compile opencv for ARM using BitBake/Openembedded Mar 07 11:05:45 can anyone guide me into right direction? Mar 07 11:25:59 no one? Mar 07 12:12:45 hi guys Mar 07 12:12:58 @ma1_: There is an opencv recipe, did you try that? Mar 07 12:31:15 @armin^: where can i find that opencv recipe? Mar 07 12:31:57 did you set up the oe environment? Mar 07 12:32:08 i have one in recipes/opencv Mar 07 12:32:41 not yet Mar 07 12:33:04 http://www.openembedded.org/wiki/Getting_started Mar 07 12:33:10 actually partially Mar 07 12:33:19 getting some issues with bitbake Mar 07 12:36:26 @armin^: thanks Mar 07 12:45:57 don't use it Mar 07 12:46:00 it's old Mar 07 12:46:41 and probably not so supported now Mar 07 12:47:09 ah, there's not, but not quite fat and big :) Mar 07 12:47:12 "This page is only applicable if you are using OE.dev (classic OpenEmbedded) For layer based openembedded architecture refer to OpenEmbedded-Core" Mar 07 12:47:46 s/there's not/there's note/ Mar 07 13:16:47 khem: u here? Mar 07 13:17:20 I have a dependency chain of udev->consolekit->gconf->gtk+->gdk-pixbuf, is this strictly necessery for every package which uses udev? Can I safely cut this dependency chain somewhere and still have X11? Mar 07 13:18:04 mertsas: imho, gdk-pixbuf is required for certain theme-engines, so I'd be careful Mar 07 13:18:50 (that's gtk-theme engines - so if you're using qt or sth, it should be ok) Mar 07 13:19:06 I'm using qt, so that shouldn't be a problem Mar 07 13:19:12 where could I safely cut the dependency chain? Mar 07 13:19:21 gconf Mar 07 13:19:50 so gconf don't have to depend on gtk+, or consolekit don't have to depend on gconf? Mar 07 13:20:12 everything after gconf should be unnecessary if you're using qt Mar 07 13:20:18 ok, thanks Mar 07 13:20:20 np Mar 07 13:46:10 hey. how can i prevent systemd.bbclass to start a service in the postinstall script? i need the service enabled, that's true, but since it's a shutdown-related service installing the package causes the system to shutdown as well... Mar 07 13:47:36 eeerm... could someone give me a quick walkthough on how to create a proper patch? I already pulled the maintenance-branch and made the modifications in the affected recipe – I'm not sure how the git-pull thing works Mar 07 14:08:24 I might have said it before, but I gotta say it again... DAMN oe got fat ;) Mar 07 14:10:28 hi. I am trying to build custom binutils (seems 2.20.51-based) and got error with -lz expanding to /usr/lib/libz.so during linking. Google said that this should be fixed by updating to libtool-2.4. How to do this update for binutils? How to create patch like libtool-2.4-update.patch in the OE-Core upstream? Mar 07 14:22:11 I love it when patches fail -_- are there any know issues with libstdc++v3 in the stable branch? a couple of patches just failed graciously Mar 07 15:00:53 do I need consolekit and pam_ck_connector etc. when using systemd? Mar 07 15:07:20 any one have an updated build file for gpsd by chance? latest is 3.4 and last one i have is 2.95 Mar 07 15:07:47 working with arm and angstrom Mar 07 15:25:10 does anyone know a media player in OE working directly on framebuffer? Mar 07 15:25:25 looks like mplayer needs X11 Mar 07 15:31:51 mplayer can be configured to use framebuffer Mar 07 15:32:27 http://www.mplayerhq.hu/DOCS/HTML/en/fbdev.html Mar 07 15:34:44 Zagor: thx Mar 07 16:17:07 khem: ping Mar 07 16:18:05 NOTE: Couldn't find shared library provider for libgcc_s.so.1 – it's just a notice, but should I start worrying? Mar 07 19:21:20 iv got an issue where i build my own updated package of scons, i have placed it in the user.collection folder, and it builds the correct version, however when i try to build my package that depends on scones i get an error telling me its finding the old version of scones Mar 07 19:21:41 i did a clean on both the scones package version 1.2 which is the reported old version, and on the package im trying to build Mar 07 19:21:45 suggestions? Mar 07 19:22:29 what is a user.collection folder? Mar 07 19:24:50 im using the suggeseted build env for gumstix hardware, they have you place your custom bb files in user.collection Mar 07 19:25:15 thats a pitty Mar 07 19:25:27 because the majority is using oe-core now Mar 07 19:25:39 and there it is a lot easier to make your own layer Mar 07 19:34:41 what is the right way of including iso8859-1 support on the image? Mar 07 19:42:55 woglinde: its not a layer issue really, issue is that i cant seem to get bitbake to realize that iv upgraded scones, the old version seems to keep being picked up by config Mar 07 19:43:58 TheX1le that would not happen with oe-core and layers Mar 07 19:44:29 woglinde: ill have to check it out, i just dont have time to try to move to a new build env, need this project running by sunday Mar 07 19:44:46 TheX1le the problem is no layer for overo so far Mar 07 19:44:52 most likely what im going to end up doing is telling it to rebuld my image Mar 07 19:45:07 and rebuilding all the packages should pick up the new version Mar 07 20:11:32 nschle85, hi did you ask for the mirroring of the certificate file? Mar 07 20:11:54 khem: ping Mar 07 20:14:16 GNUtoo: no, this is not i want Mar 07 20:14:37 ok Mar 07 20:15:05 GNUtoo: i want to get the build fixed Mar 07 20:15:22 ah? Mar 07 20:15:31 why would that fail to fix the build? Mar 07 20:15:45 because it will fail to fetch from official website and fallback to a mirror Mar 07 20:15:50 an oe mirror Mar 07 20:16:01 and then build will continue Mar 07 20:16:06 ah ok Mar 07 20:17:55 but i dont understand what the problem is to merge one of the patches... Mar 07 20:25:18 both patches have styles issues Mar 07 20:25:32 if you do a correct patch then it can be merged Mar 07 20:25:46 but the commit message of your patch doesn't seem ok Mar 07 20:25:49 at first sight Mar 07 20:26:09 the diff seem ok tough Mar 07 20:28:11 GNUtoo: how the commit message should be formated ? Mar 07 20:29:09 nschle85, it's documented well in the oe wiki Mar 07 20:29:17 ok Mar 07 20:29:24 there are several articles about it Mar 07 20:29:31 look for commit keyword Mar 07 20:29:35 and also for patch keyword Mar 07 20:37:49 Can I expect that simple recipes (for qmake + Qt based software) to be compatible across Yocto, OpenEmbedded Classic and OE with layers? Mar 07 20:49:39 can anyone comment on why libgcc-dev gets renamed to libgcc-s-dev when an rpm is made? Mar 07 20:58:23 msm: most likely the shared library package renaming process. read debian.bbclass Mar 07 20:59:15 kergoth: this goes for rpm's as well -right? Mar 07 20:59:35 it isn't specific to the package format in any way Mar 07 21:01:16 k Mar 07 21:01:29 i think the rename is not occuring properly for the multilib case Mar 07 21:01:32 perhaps this is fixed upstream Mar 07 21:01:46 * kergoth has no idea how the multilib package naming bits happen :) Mar 07 21:01:52 * kergoth should read that code at some point Mar 07 21:12:18 debian.bbclass looks scary Mar 07 21:12:20 =( Mar 07 21:14:27 heh, well, it has to go by the soname, so that means it has to get the soname :) Mar 07 21:24:21 i think im missing something - but why can't I see print statements I add to debian.bbclass? Mar 07 21:24:35 seems like it's obvious Mar 07 21:24:41 because task output never goes to the screen Mar 07 21:24:43 it goes to the logs Mar 07 21:24:52 if you want to see output, use the bb module functions Mar 07 21:24:55 error, warning, etc Mar 07 21:25:04 bb.note also goes to the logs, not the screen by default Mar 07 21:27:58 ugh Mar 07 21:28:00 that's what i tried Mar 07 21:28:06 (bb.note) Mar 07 21:28:18 try bb.warning, thats usually my printf of choice for debugging tasks Mar 07 21:28:23 er, bb.warn Mar 07 21:31:32 got it Mar 07 21:34:26 bb.warn is not working either Mar 07 21:35:29 warnings do hit the screen, must have something else going on Mar 07 21:38:14 they are not working from debian_package_name_hook Mar 07 21:41:20 no from package.bbclass either Mar 07 21:41:24 * msm is going crazy Mar 07 21:50:55 * mr_science setting up local feeds Mar 07 21:51:27 one feed url per *feed.conf file i presume? Mar 07 22:07:44 okay, feeds work, but how do i get the Packages.gz to update itself? Mar 07 22:11:26 kergoth: i think my problem is the step im adding debug info too is cached somehow? does the rename occur in the do_package step? Mar 07 22:11:53 not sure offhand, would have to check the classes Mar 07 22:16:12 kergoth: phew… seems to be the case Mar 07 23:18:32 oe-core, I've got foo/bar.sh and foo.bb with SRC_URI="file://bar.sh". When I bitbake, bar.sh is nowhere to be found. What did I do wrong? Mar 07 23:21:28 crickets. Mar 07 23:21:36 what do you mean by "nowhere to be found"? Mar 07 23:21:46 it should be in WORKDIR where everything else that gets unpacked goes Mar 07 23:21:58 I expect bar.sh to wind up in the WORKDIR Mar 07 23:22:41 well, there are plenty of recipes that do that just fine, so don't know what to tell you. Mar 07 23:23:39 hmm Mar 07 23:25:13 $ ls Mar 07 23:25:14 multilib_check.py opkg.conf opkg-sdk.conf pseudo rootfs rootfs.lock temp Mar 07 23:26:30 I'd start by checking your assumptions. use bitbake -e to verify SRC_URI is what you think it is, read the do_unpack log, etc Mar 07 23:29:54 temp has no log for do_unpack. does do_rootfs come before do_unpack? Mar 07 23:30:12 (is there a list of all these do_* and what order they are executed in?) Mar 07 23:31:11 do_unpack isn't going to be run for an image at all, you didnt' say foo.bb was an image Mar 07 23:31:14 read the classes Mar 07 23:31:17 grep for 'addtask' Mar 07 23:32:49 how does bitbake know it is an image? Mar 07 23:33:32 the big honking 'inherit image' or 'inherit core-image' in the recipe? Mar 07 23:33:38 you really need to read the metadata Mar 07 23:33:46 follow the include/require/inherit Mar 07 23:34:06 found it, "inherit image", 64 lines into the file. Mar 07 23:34:31 can you tell me what you mean by "read the metadata" ? Mar 07 23:34:42 if you don't know how to read, I'm not going to be able to help you Mar 07 23:34:48 when you see an inherit, go read the class it inherited Mar 07 23:34:52 if you see an include, read the file it included Mar 07 23:34:55 not rocket science here Mar 07 23:35:09 be nice. it should be clear to you that I know *how* to read, just not *what* to read. Mar 07 23:35:44 if you want to know what ar ecipe does, read the recipe and follow hte include/require/inherit, as i've said twice now Mar 07 23:35:57 if you want to grasp the bigger picture as well, read bitbake.conf and base.bbclass, whicha re both automatically parsed Mar 07 23:36:09 and there's also INHERIT, which is a list of classes which are inherited by all recipes Mar 08 00:14:45 Anyone else have any clues for me? adding "addtask do_unpack before do_rootfs" didn't seem to help Mar 08 00:23:18 addtask unpack before do_rootfs Mar 08 00:23:26 if you look at the other addtasks, you'll see that the do_ is implicit Mar 08 00:23:36 annoying inconsistency, i know, but we're stuck with it Mar 08 00:25:02 do I need to do anything to overcome the do_fetch[noexec] = "1" in image.bbclass? Mar 08 00:25:47 fetch isn't relevant here, but unpack definitely is, yes Mar 08 00:26:03 i suspect doing = "" would kill it, but i haven't tested it Mar 08 00:26:11 this seems like a very strange use case. Mar 08 00:26:26 you'd really be better off just having a separate recipe install the bits into the sysroot, and then run them in the do_rootfs Mar 08 00:26:32 I thought "fetch" handled the URI, and unpack did stuff like untar/compress,etc... Is this incorrect? Mar 08 00:26:38 fetch downloads Mar 08 00:26:43 file: urls don't get downloaded Mar 08 00:27:01 unpack is what takes the downloaded file and puts it in workdir in some fashion, whether that's a copy or tar or a git clone Mar 08 00:27:06 The bits don't wind up in sysroot. it's a script thatpostprocesses the image. Mar 08 00:27:11 yes, and? Mar 08 00:27:17 put the postprocess script into the sysroot. problem solved. Mar 08 00:27:22 now do_rootfs can run it that way Mar 08 00:35:33 no joy for "addtask unpack before do_rootfs". It says it is running the task, but the file still doesn't wind up in workdir. This recipe worked under oe-classic, and I'd like to change as little as possible to get it working again. In this particular case especially, since the rootfs has to fit in limited RAM. Mar 08 00:36:55 It seems to me like image.bbclass shouldn't set noexec on fetch/unpack if there's a SRC_URI in the recipe. Mar 08 00:37:31 to cover an extremely rare, non-standard usage of an image recipe? Mar 08 00:37:37 i'm sure if you implement that, somoene would accept the patch Mar 08 00:37:46 but i highly doubt anyone but you cares enough to implement it Mar 08 00:37:56 If someone sticks a SRC_URI in an image recipe, there's a reason for it; they expect their stuff to wind up in workdir. Mar 08 00:38:10 if someone sticks an SRC_URI in an image recipe, they're doing it wrong Mar 08 00:38:17 metaphor shear when it doesn't Mar 08 00:38:21 but by all means open a bug in the bug tracking system Mar 08 00:38:52 but i wouldn't hold my breath on the fix, due to other higher priority concerns Mar 08 00:39:55 * mr_science waves at kergoth Mar 08 00:40:05 hey Mar 08 00:40:21 long time, dude... Mar 08 00:41:16 been flogging the arago stuff a lot lately Mar 08 00:41:56 indeed. Mar 08 00:42:05 ah, that's the TI stuff right? Mar 08 00:42:15 yup Mar 08 00:42:18 cool Mar 08 00:42:21 afk, food Mar 08 00:42:32 apparently we're on their bleeding edge Mar 08 00:42:47 dm8168 davinci Mar 08 01:08:50 kergoth: solved it by copying the image.bbclass, removing the noexec on fetch/unpack/patch, and adding "addtask rootfs before do_build after do_patch", and using my new class. I'm sure there's a better way though. Mar 08 01:22:13 i take it setting the flags to "" didn't do it? **** ENDING LOGGING AT Thu Mar 08 02:59:58 2012