**** BEGIN LOGGING AT Tue Oct 30 02:59:58 2012 Oct 30 09:01:03 hi Oct 30 09:02:04 I'd like to integrate an rootfs image file into another rootfs image Oct 30 09:02:33 Can someone give me a hint on how to do that correctly? Oct 30 09:20:11 good morning Oct 30 09:26:49 morning all, I want to remove netbase my image as I am replacing it with connman Oct 30 09:27:16 now, netbase is set in packagroup-core-boot, which has some fairly useful stuff in it Oct 30 09:27:49 should I copy packagegroup-core-boot and keep a local copy in my layer to use, or is there a better way of removing netbase from the image? Oct 30 09:29:13 or should netbase possibly get its own VIRTUAL-RUNTIME_network which can be overridden? Oct 30 09:40:56 could someone explain me the relation between mysql5 and mysql5-native recipies here : http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/mysql ? Oct 30 09:41:59 mysql5_5.1.40.bb DEPENDS on it but then how is it supposed to user mysql-native over the mysql host installation ? Oct 30 09:42:08 to use* Oct 30 09:42:32 morning all Oct 30 09:42:37 morning bluelightning Oct 30 09:42:40 afournier: hi Oct 30 09:44:09 i understand -native recipies are recipies that provides tools and binaries for other recipies, but how a recipe can use it without using the system default ones ? Oct 30 09:44:50 afournier: I'm unclear on what of mysql-native is needed by mysql, but assuming it's native executables, the sysroot bin directories are before the host paths Oct 30 09:45:08 you can see this if you do bitbake -c devshell mysql and then echo $PATH within the devshell Oct 30 09:45:09 well Oct 30 09:45:29 let's try :) Oct 30 09:46:27 well, the main casuaklty for me in the storm is my email Oct 30 09:46:30 type mysqld_safe Oct 30 09:46:31 mysqld_safe is /spare/oe/tmp-eglibc/sysroots/i686-linux/usr/bin/mysqld_safe Oct 30 09:46:35 that's cool Oct 30 09:46:41 the datacenter that does my email is dead Oct 30 09:48:16 Crofton they just added some water cooling to it :p Oct 30 09:48:24 it's maintenance :p Oct 30 09:48:41 Crofton|work: gosh Oct 30 09:54:54 heh Oct 30 09:55:04 I do not know where the datacenter is even :) Oct 30 09:55:10 but they went pretty early Oct 30 10:15:48 hi Oct 30 10:15:58 I'd like to integrate a rootfs image file into another rootfs image Oct 30 10:15:59 Can someone give me a hint on how to do that correctly? Oct 30 10:16:28 hico: do you mean merge a rootfs image, or have an image in an image (which doesn't really make sense) Oct 30 10:16:41 I have a initrd image generated by an image recipe and the generated image should be in another rootfs image Oct 30 10:17:32 hico: so you want to include the initrd in a rootfs image? Oct 30 10:17:37 yes Oct 30 10:18:44 your initrd recipe should install the initrd image and then you should include that recipe in your image recipe, if that makes sense? Oct 30 10:19:32 yes that was my thought, too Oct 30 10:19:53 for building the initrd image I'm using the image class and its dependencies Oct 30 10:20:17 as far as I see there are no install() functions in this environment, so I will have to write them myself? Oct 30 10:20:28 or am I missing something Oct 30 10:21:01 hico: I'm not familiar with the image class, so unfortunately I can't help you there Oct 30 10:21:31 I actually just want to be clear, that there's not an "easy" way already included somewhere to do what I want to do Oct 30 10:21:39 ok, no problem jackmitchell. Oct 30 10:21:57 we do already do this for live images FYI Oct 30 10:22:30 see meta/classes/image-live.bbclass Oct 30 10:22:38 bluelightning: hm? so there are live image recipes that do this Oct 30 10:22:53 yes Oct 30 10:23:01 ah nice. ok bluelightning thanks, I'll have a look in there Oct 30 10:23:50 most of the actual logic is in meta/classes/bootimg.bbclass (which is inherited by image-live.bbclass) Oct 30 10:25:02 ok thx Oct 30 11:19:45 hi. I have found an issue with arm-oe-linux-gnueabi-g++. I'm trying to build and link my program. However I need to use a specific linker script. It seems the linker don't want to use my custom linker script. Oct 30 11:20:04 parameters: -Wl,-T,path_to_linker_script Oct 30 11:20:14 what could be the problem? Oct 30 11:31:11 bluelightning: i re-checked the PATH from the devshell and i understand why mysqld is not found in it, by default it goes to /usr/libexec Oct 30 11:31:12 :/ Oct 30 11:31:39 so libexec is not in the path, i don't know if it's an oe problem, or if mysqld should go in /usr/bin ... Oct 30 11:32:14 what issue are you attempting to solve exactly? Oct 30 11:32:28 FWIW, I'm able to build and run mysql5 here... Oct 30 11:32:36 i am trying to run mysqld from a recipe, but oe cannot find it because it's not in the path Oct 30 11:33:01 i know it builds, but i am making a custom recipe that uses mysqld Oct 30 11:33:27 ah, I see Oct 30 11:34:10 the configure scripts would let me change the libexecdir to /usr/bin, but i don't know if it's a good idea Oct 30 11:35:50 this should be easyest solution, and many distrib put the mysqld binary in /usr/sbin anyway Oct 30 11:37:14 brb Oct 30 11:56:58 afournier: if /usr/sbin is the commonly accepted place then that's probably where it should be Oct 30 12:25:06 I'm having trouble compiling a glib program using dbus, I get the linker error: undefined reference to `g_dbus_proxy_new_for_bus_sync' Oct 30 12:25:53 now, I am passing -lglib-20 as a library and the includes are resolving fine in eclipse, so I don't know what else to do? Does anyone have any suggestions? Oct 30 12:26:13 s/glib-20/glib-2.0 Oct 30 12:33:25 no worries, I fixed it - there is a libgio library within GLib that isn;t explained anywhere in the docs as far as I can see Oct 30 12:33:57 ignore, found the docs Oct 30 13:21:13 morning all Oct 30 13:27:01 hi pb_, all Oct 30 13:31:36 hi pb_, mckoan Oct 30 13:32:01 hi bluelightning, mckoan Oct 30 16:01:05 morning Oct 30 17:11:24 I am fairly new to bitbake and OE. I have an issue where a recipe calls on configure; but I want to change the way PATH looks when configure is invoked. Looking through the other recipes, its difficult to figure out how PATH is being aggregated. basically I want my local directory to end up as the first entry along PATH. but other things are aggregating before it. Oct 30 17:11:35 my question: is there a way to watch PATH as it is aggregated? like a debug output that will show each modification to PATH? Oct 30 17:11:47 so when I run bitbake i can watch PATH being built Oct 30 17:13:33 trying to modify PATH is almost certainly the wrong approach Oct 30 17:15:00 perhaps if I detail the problem.... our original build server is using gcc 4.1.2 and a 2.6.x kernel. when I created a new build server, it has gcc 4.7 and a 3.x kernel; this brreaks a lot of configure scripts that want a 1.x or 2.x kernel, and breaks them also because gcc 4.7 balks on the c code for various pedantic reasons. Oct 30 17:15:24 so i build a new toolchain for the "local" build, installed under /opt/gcc-4.x Oct 30 17:15:56 so that gets past the local compile stuff: i set the path before calling bitbake so that the /opt/gcc compiler gets used. Oct 30 17:16:41 but then we get to the configure scripts: they invoke uname -r and those report a 3.x workld, but the configure scripts aren't set up for that. so then I end up with endless patches added to recipes. that seems wrong. Oct 30 17:17:26 so i thought, what if I add a uname script earlier in the path, and have it report 2.x for the kernel; then everything will buidl with the 2.x rules; since we're using a fixed toolchain with its own /opt/gcc headers, that should be fine Oct 30 17:18:03 but bitbake is aggregating a path that inserts things before my special uname script, and that means it calls a uname binary that says "i'm a 3.x kernel" and that breaks the configure scripts. Oct 30 17:18:30 if I manually run the configures, I get the correct build with the toolchain. b ut when I use recipes, it breaks Oct 30 17:18:47 i'm open to suggestions. Oct 30 17:18:59 though being able to change the path would be fairly simple Oct 30 17:19:22 well, not the act of changing the path, but i mean that, were my special path in front of the others, I'd get the desired effect. Oct 30 17:19:27 and not 100+ patches Oct 30 17:22:57 ok, maybe a simpler question si this: I have a 2 year old version of OE, and I want it to work on a ubuntu 12.04 or centos 6.x. what is the simplest way to make that happen? Oct 30 17:24:42 do a build. wait for a failure. fix the failure. Oct 30 17:24:49 or better yet, don't use a 2 year old version of OE Oct 30 17:25:29 so... brand new, total regression on the embeded platform i'm delivering. tough sell to management. Oct 30 17:26:13 then like i said, fix each problem as you encounter it. there's no magic bullet that's going to fix every failing -native recipe Oct 30 17:26:50 are there really all that many recipes which break with a 3.x kernel? anything that expects "1.x or 2.x" must be way old by now. Oct 30 17:26:56 using an open source project but not tracking anywhere near current, you're not gaining the real value of using an open source project. you're not getting anyone elses fixes Oct 30 17:26:58 well, I sort of figured it was going to be the hard way (many patches), but thought I'd come in here and ask, first, just in case anyone had already made it happen. Oct 30 17:27:11 pb_: i suspect more eglibc 2.16 failures than kernel Oct 30 17:27:20 lets see... so far, dhcp breaks, apache2 breaks, perl breaks. Oct 30 17:27:27 erm, is 2.16 in 12.04? now i'm not sure Oct 30 17:27:30 * kergoth shrugs Oct 30 17:27:35 the patches are trivial, and all are centered on "uname -r" calls Oct 30 17:27:55 hm, why are dhcp and apache even inspecting your host kernel version? Oct 30 17:27:57 ah Oct 30 17:28:01 that does sound strange Oct 30 17:28:02 assuming you're not building -native versions of them, anyway Oct 30 17:28:05 yeah, my question exactly, but they are Oct 30 17:28:10 their configure script is Oct 30 17:28:25 which bit of the script? Oct 30 17:28:32 and those are the ones I know about and have patched. there are one heck of a lot more to go Oct 30 17:28:48 obviously, anything to do with perl is crazy and fucked up by definition, so I'm not so surprised about that one. Oct 30 17:29:39 unfortunately i inherited this from someone who could have been a bit more organized. the fruit of our builds produce a arm9 target, and a x64 target; they are almost identical, except that the arm version has our embedded board work in the kernel Oct 30 17:29:59 so there's local build for the arm, and a local build for the x64 Oct 30 17:30:07 oh, I see. so you really are building more or less everything for the host? Oct 30 17:30:09 and i tell you what, its hard to see the forest for the trees. Oct 30 17:30:14 yes Oct 30 17:30:34 the "right" way to fix that would probably have been to make a separate x84-64 target which was insulated from the vaguaries of your host environment. Oct 30 17:30:37 i mean, the target on both have tcpdump, top, and other nifties common to a full-fledged box Oct 30 17:30:45 kind of like qemux86 does in oe-core nowadays. Oct 30 17:30:50 it is separate. but its a real mess Oct 30 17:31:02 some switches for target are done outside of bitbake recipes in the actualy code. Oct 30 17:31:04 well, clearly it isn't all that separate if it's poking at "uname -r". heh. Oct 30 17:31:19 and using your host gcc, from what you said earlier Oct 30 17:31:26 some rely on super secret environment variables that get set up front, then some how trickle down to makefiles that decide to load one config versus another. Oct 30 17:31:51 it does sound as though you might just be in a world of pain with that one Oct 30 17:31:54 aside from the local stuff, we have a special gcc ARM toolchain, and a special gcc x64 toolchain Oct 30 17:32:00 so we are using 3 compilers. Oct 30 17:32:12 maybe you should just set up a VM and clone the old build environment into it. Oct 30 17:32:16 the arm and x64 are gcc 4.4 Oct 30 17:32:49 yeah, that was what I was hoping to avoid - the vm. lots of reasons, like hearding the cats (developers) I work with. (yes, I'm one of the cats, just got lucky when the build boss quit) Oct 30 17:33:14 or, burn your existing oe installation and set up a new project using a contemporary oe-core. I suspect either of those will be quicker and involve less hair loss than trying to fix up the old build to work in the new environment. Oct 30 17:33:17 the devs want the swanky, latest emacs Oct 30 17:33:23 I guess now you know why the last guy quit. :-} Oct 30 17:33:36 and a passel of other tools that are newest and bestest only on the latest centos/ubuntu. Oct 30 17:33:52 hah! yeah, I think so. Oct 30 17:34:18 well, they can still run their eleet new emacs on their own hosts, they just need to run compiles in the legacy vm Oct 30 17:34:39 oh, wait. you forget. some of them are MAC users, too. Oct 30 17:34:44 hah Oct 30 17:34:51 oh well, good luck Oct 30 17:34:56 from what I hear, MAC os is a REAL unix, not a toy like linux. Oct 30 17:35:30 i've been doing linux dev since 1995, and did unix before that from the 80's. Oct 30 17:36:18 didn't care much for the mac they put in my hands the first day I started working here. so i traded it in for a pc, installed linux (after wiping windows), and its been smooth sailing... until the build guy quit. Oct 30 17:36:44 ok, let me quit complaining and ask some good questions. Oct 30 17:36:49 i like the idea of moving to the latest OE Oct 30 17:37:00 well, like and hate it. but I'd rather move forward, not go back Oct 30 17:37:49 we are in bed with OE because of our arm9v5.... the recipes are configured to deliver a solid image for that type. Oct 30 17:38:19 so the old build guy leveraged that, modified it for the 2 targets (arm5v9, x64), added a arm toolchain and a x64 toolchain. Oct 30 17:38:54 both the arm and x64 targets are using a 2.6 kernel Oct 30 17:40:02 supposing now that I upgraded us to the latest OE, went through the total regression testing (hopefully doesn't turn into a nightmare), and then a year goes by. Oct 30 17:40:21 here's the question: what is the "best practices" for keeping OE up to date? Oct 30 17:40:34 seems to me that every time we updated, we'd have to do regression testing. Oct 30 17:42:28 you have to do regression testing when you update any piece of software you use, if you lpan on making sure it works Oct 30 17:42:37 I'd suggest updating more often than once every 2 years ;) Oct 30 20:42:31 re **** ENDING LOGGING AT Wed Oct 31 02:59:58 2012