**** BEGIN LOGGING AT Fri Apr 17 02:59:58 2015 Apr 17 07:11:11 good morning Apr 17 07:12:12 miandonmenmian, you there? Apr 17 07:12:21 good morning (evening here) Apr 17 07:18:36 kergoth: I am still looking for a workaround :-) Apr 17 07:41:41 hmm, it seems like I'm getting a dependency chain 'core-image-minimal-initramfs', 'initramfs-live-install', 'grub' even though I have EFI_PROVIDER set to gummiboot Apr 17 07:42:14 and the bootloader is most definitely gummi on the EFI partition Apr 17 07:49:24 is there a reason that linaro support is broken? (i.e. political,etc)? Apr 17 07:50:35 ugh, I completely missed the "-install" part, time to remove that from my image config Apr 17 08:22:08 is there any meta-layer search engine for yocto? Apr 17 08:22:34 yes Apr 17 08:22:41 http://layers.openembedded.org/ Apr 17 08:23:29 lpapp: thanks. i looked on that site, need to clean glasses(or get glasses):) Apr 17 08:23:55 ^_^ Apr 17 08:38:04 1 more question :) is there any easy way to convert a deb to bb?:) Apr 17 08:38:12 (easy = automagic) Apr 17 08:39:09 mrsan, in what sense? Apr 17 08:39:49 mrsan: I think they are not 1:1 mapping, so even if there was, you would still need to make sure what is good and what is bad and for that, you would need to know bitbake to a certain extent. Apr 17 08:40:26 lpapp: thanks again:) Apr 17 08:40:38 redengin: save time to not write the bb file manually.) Apr 17 08:41:05 do you just want to conver the bitbake toolchain to use deb? Apr 17 08:41:24 or are you trying to import a deb straight? Apr 17 08:42:16 mrsan: probably it would only work for the trivial cases (where writing the bb takes about 1 minute), but fail the complicated cases and then you'd invest the time in debugging. i doubt such a converter would do super useful things. Apr 17 08:43:09 mrsan: plus, AFAIK debs are not aware of the install/targetinstall duality for examlpe, hence there would always be some action needed Apr 17 08:44:13 LetoThe2nd, if he used deb as the bitbake pkg manager, he should be able to get away with a hackish do_install that puts the deb file in the right place Apr 17 08:44:48 redengin: but then he'd not build the deb through bitbake, which is the aim as iunderstand it. Apr 17 08:45:22 getting an oe-created rootfs to just *install* some deb is an entirely different story Apr 17 08:46:31 then just changing to deb packaging would work for him right? Apr 17 08:47:06 if the only aim is being able to install a deb that comes from whatever source, then yes. Apr 17 08:52:16 it won't be that simple either though... mixing in packages built elsewhere isn't really supported, not without hacking Apr 17 13:49:46 hi, a *.bb file overwrites do_patch() to do nothing. in my bbappend i want to call the normal do_patch() .. how to do this? Apr 17 13:54:27 hello all, I have a problem with gcc on my target qemux86 using core-image-lsb-sdk. Basically it seems that --sysroot is set the the toolchain for my host machine. Apr 17 13:55:24 I know I can override by putting --sysroot=/ but I am install ruby gems and it is picking up the --sysroot as it was defined during bitbake. Apr 17 13:56:01 I am not a c programmer. anyone have any ideas? Apr 17 13:59:05 ericbutters: something like "bb.build.exec_func('patch_do_patch', d)" in your bbappend might work, but maybe you should fix the original recipe instead? Apr 17 14:01:40 thanks ericbutters, i have a very simple build and I am not sure what is causing the issue. Thanks for the pointer, I will see what I can work out. Apr 17 14:01:49 appreciate your time. Apr 17 14:09:30 jku: that is what i am looking for, but i get error: ERROR: ExpansionError during parsing .. Failure expanding variable do_patch: ShellSyntaxError: LexToken(TOKEN,"'patch_do_patch',",0,0) Apr 17 14:10:25 LexToken(TOKEN,'d',0,0) Apr 17 14:11:12 i do not inlcude / inherit anything.. so maybe that is missing Apr 17 14:11:30 ericbutters: you'll have to do python do_patch() { } Apr 17 14:11:47 (with your code in it, naturally) Apr 17 14:12:29 sorry, the above was meant for rich_b ^ Apr 17 14:12:50 bluelightning: thanks! Apr 17 14:13:17 wait, I had it right in the first place Apr 17 14:13:31 maybe time to take a break :) Apr 17 14:15:41 :) Apr 17 14:19:42 i have a *.cfg file to patch the kernel config. in the cfg file i set a config to =y, but after configure kernel this is unset. so i think first bitbake is using my .cfg and then uses the defconfig.. does that makes sense? how to fix this? Apr 17 14:20:26 i do not want to change the kernel recipe of the vendor. so i use a bbappend, the driver is patched into the kernel source and the * Apr 17 14:20:48 .cfg also comes in. but then will be deactivated again Apr 17 14:22:58 i think it is because of this addtask here: http://paste.ubuntu.com/10838847/ Apr 17 14:31:40 ericbutters: if the recipe is slapping its own defconfig in right at the end there's not a heck of a lot we can do from our side ... Apr 17 14:35:45 thx Apr 17 14:36:56 FWIW, just adding the defconfig into SRC_URI is supposed to work, I'm not sure why a special function would have been needed Apr 17 14:39:18 what do you exactly mean with "i have a *.cfg file to patch the kernel config" Apr 17 14:39:20 ? Apr 17 14:39:49 is this a cfg fragment? Are you using a linux-yocto kernel ? Apr 17 14:41:43 adding cfg fragments in SRC_URI is not allowed for standard recipes (unless you add custom tasks) Apr 17 14:42:16 only linux-yocto recipes do manage that (see the respective classes) Apr 17 14:42:43 bluelightning: the vendor seems to not know yocto well and added own tasks to apply defconfig, not simple put it to the recipe foler etc.. so we will fix this.. Apr 17 14:55:32 bluelightning: could you pls take a look here: http://paste.ubuntu.com/10838987/ -- is it ok to have fragments beside a defconfig? Apr 17 14:58:12 ericbutters: this surely won't work. Maybe you meant SRC_URI += Apr 17 14:58:52 then as I said, this is a typical usecase for linux-yocto: you add a feature and it's config block Apr 17 14:59:11 it's better managed with an .scc Apr 17 14:59:47 ant_work: okay i give it a try.. on monday :) thanks Apr 17 15:00:27 for non-yocto the easier way is that you provide a patched defconfig Apr 17 15:00:34 and a patch Apr 17 15:01:32 ok Apr 17 16:52:46 linux-yocto aren't the only kernels that support config fragments, check the kernel recipe in question Apr 17 16:52:52 * kergoth yawns Apr 17 16:54:58 I'm seeing 'NOTE: preferred version 3.19% of linux-yocto not available (for item virtual/kernel) Apr 17 16:55:25 even though I've got linux-yocto-custom set as the provider for virtual/kernel :( Apr 17 16:57:12 use bitbake -e to make sure the preference is set the way you think it is (i.e. make sure no later config file overrides it)? Apr 17 16:57:13 * kergoth shrugs Apr 17 17:00:08 kergoth: will do, but I'm fairly sure it's already correct as the right kernel is being built & installed :). Just trying to get rid of a bunch of messages about linux-yocto that aren't relevent Apr 17 17:00:14 ah Apr 17 17:00:52 It is being set in the machine/foo.conf file to the value I'm expecting Apr 17 17:01:03 is it possible that some things are ignoring the machine config? Apr 17 17:06:16 kergoth: to add fragments you have to add your tasks like it was done in linux.inc Apr 17 17:06:27 all is possible if you know how Apr 17 17:08:09 that's assuming the vendor kernel recipe doesn't already do so. I just pointed out that he should check first. Apr 17 17:08:19 heh Apr 17 17:08:24 that said, it's not terribly difficult to add that capability to an existing kernel recipe, depending on how they manage the defconfig -> .config, I've done so from bbappends before. Apr 17 17:09:02 but I admit the .scc way is very clean Apr 17 17:09:46 it's just that linux-yocto is not 'vanilla' Apr 17 17:10:14 I once asked for a virgin branch Apr 17 17:10:29 w/out patches Apr 17 17:10:33 if all you want is fragments, not scc, it's trivial to implement with kernel-tools-native on a stock k.org kernel Apr 17 17:10:39 without any of the yocto repo structure Apr 17 17:10:47 just run merge_config.sh as appropriate Apr 17 17:10:58 just as our busybox recipe does Apr 17 17:11:13 ah, but what if you don't have a git repo for the kernel? Apr 17 17:11:32 I'm managing all in metadata Apr 17 17:12:29 doesn't matter Apr 17 17:12:31 I mean, a yocto KMACHINE Apr 17 17:12:40 merge_config is just a shell script that takes fragments and merges them into a .config Apr 17 17:12:48 not hard to run against all the .cfg files in SRC_URI Apr 17 17:13:10 right Apr 17 17:14:00 obviously doesn't have all the features that the rest of the linux-yocto tools provide, but certainly better than nothing. would be nice if all bsp kernels provided fragments support Apr 17 17:14:01 it's just that I encountered resistence vs. kern-tools by kernel devs Apr 17 17:14:04 :/ Apr 17 17:14:33 the kernel devs shouldn't have to care, it can be done entirely in the recipe metadata, unless they're also the ones maintaining the bsp layer Apr 17 17:19:03 broonie said there are apostles trying to wide-spread the framework ;) Apr 17 17:24:38 bbl Apr 17 18:22:03 * zeddii_home doesn’t think there’s anything extra to be provided to have fragments on any kernel recipe Apr 17 18:22:25 it just works everywhere, as is. I could hide the need to include of linux-yocto if that’s what people want Apr 17 18:22:37 but re-implementing and causing confusion is just … Apr 17 18:23:16 huh? Apr 17 18:23:31 fragments do *not* work everywhere. in every linux-yocto based recipe, yes Apr 17 18:23:54 my point being, I could just make them work everywhere. Apr 17 18:23:58 no need for anything parallel. Apr 17 18:26:02 that's the same thing i was saying, that making fragments support work for any given kernel recipe is trivial, so folks should do that rather than patching defconfigs Apr 17 18:26:14 ah ok. I agree. Apr 17 18:26:33 and I was offereing to distill some changes and make it transparent for any kernel. Apr 17 18:27:04 * zeddii_home is having a bad day with people being vague (not you, just my read) .. so I’m sensitive I guess. Apr 17 18:28:13 ah, yes, that would be nice. the problem is, currently the defconfig -> .config bits are not done the same way everywhere. kernel.bbclass provides a default from ${WORKDIR}/defconfig, but not everyone uses it. i think if we can get that consistent, then it'd be fairly easy to do the fragment handling for everybody Apr 17 18:28:44 hmm, Hmm, runtaskdeps changed from ['eglinfoeglinfo-fb_1.0.bb.do_package', 'eglinfoeglinfo-fb_1.0.bb.do_package'] ... wonder what the deal is with the lack of separator in the whatchanged output Apr 17 18:28:49 completely agree. I’ll make myself a 1.9 feature to see what I can do. there are easy parts to pull out. Apr 17 18:28:50 eglinfoeglinfo-fb_.. Apr 17 18:30:59 * zeddii_home runs off. there’s a giant trench being dug in his front lawn. Apr 17 18:42:27 Has anyone ever built an image with Hadoop? I found meta-redoop here [https://github.com/redoop/meta-redoop] but it hasn't been touched in over a year. Apr 17 18:42:58 Additionally if anyone has experience with building/deploying Java via Maven I'd love to ask you some questions. Apr 17 23:19:01 Anybody around? Apr 17 23:19:15 Got an issue on archlinux where qemu-native fails with: Apr 17 23:19:45 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/libgtk-x11-2.0.so: undefined reference to `g_type_check_instance_is_fundamentally_a' Apr 17 23:20:18 Anybody saw this before? Or is using archlinux successfully? **** ENDING LOGGING AT Sat Apr 18 02:59:59 2015