**** BEGIN LOGGING AT Tue Aug 02 02:59:57 2016 Aug 02 07:25:24 morning Aug 02 08:07:45 good morning Aug 02 08:41:15 good morning all, I'm still working on dbus-cxx, my next idea was to simply overwrite the do_configure target and its wokring, I have now a working (complie ready) configuration in my directory Aug 02 08:41:31 But why is there no do_compile target inside the "autotools" class? Aug 02 08:41:44 https://github.com/01org/luv-yocto/blob/master/meta/classes/autotools.bbclass Aug 02 08:42:20 http://pastebin.com/4vF3XLsa Aug 02 08:49:07 HyP3r: current master does actually have a do_compile in autotools, but base.bbclass has a do_compile Aug 02 08:49:21 so that runs in the the previous releases Aug 02 08:49:56 "NOTE: nothing to compile" is from base_do_compile and means "you told me to run make, but there wasn't a makefile" Aug 02 08:50:13 this generally means you're using autotools on a recipe that does not in fact use autoconf+automake Aug 02 08:51:22 if its autoconf+hand-crafted makefiles when using autotools-brokensep should fix it. Aug 02 08:51:24 rburton: ah ok, the problem was that the whole run.do_compile script was not run in side the correct directory... no makefile no installation Aug 02 08:51:44 yeah, autotools.bbclass does out of tree builds, assuming the upstream supports them Aug 02 08:51:53 If the directroy which is changing before do_compile is called, I have to set S=? Aug 02 08:52:06 well, determine the problem first Aug 02 08:52:10 I allready had to fix that in my do_configure() routine Aug 02 08:52:22 If I'm in the correct directory I can compile it Aug 02 08:52:28 sounds like you really don't need autotools then Aug 02 08:52:35 what upstream is this? Aug 02 08:52:43 whats a upstream? Sorry Aug 02 08:52:47 what recipe Aug 02 08:52:58 custom - from me - called dbus-cxx Aug 02 08:53:11 My cowork did it, now its not working anymore Aug 02 08:53:45 And well, there is no good configure script aviable, but an configure.ac script, but yocto is calling - by default - autoreconf wrong so I overwrote the do_configure Aug 02 08:54:04 what's wrong about the invocation and why can it not be fixed Aug 02 08:54:11 http://pastebin.com/m3B8ifZV Aug 02 08:54:23 https://github.com/01org/luv-yocto/blob/master/meta/classes/autotools.bbclass#L290. Aug 02 08:54:48 If you remove "ACLOCAL="$ACLOCAL"" <- this everything works but _with_ this you cann't create a working configure script Aug 02 08:54:53 I don't really know why Aug 02 08:55:01 impressively broken upstream Aug 02 08:55:10 removing the cd will fix your build problem Aug 02 08:55:45 rburton: the cd was nessercary because something inside my script is ignoreing the setting of "S = ..." Aug 02 08:55:47 well, pasting what happens when you don't override do_configure will be interesting Aug 02 08:55:55 no, as i said, autotools assumes out of tree builds Aug 02 08:56:01 so you'll be in WORKDIR/build Aug 02 08:56:04 I don't really know why but its allways chaning in side the build directory Aug 02 08:56:14 ah you said it too Aug 02 08:56:20 look at autotools, you do an out-of-tree configure by invoking ${S}/configure Aug 02 08:57:11 the normal autotools class basically does cd ${S}, autoreconf, cd ${B}, ${S}/configure Aug 02 08:57:47 aclocal problems suggests that the dbus-cxx maintainers don't know what aclocal vs acinclude are for Aug 02 08:58:04 that could be Aug 02 08:58:14 oh they're putting macros at the top level instead of in m4/ Aug 02 08:58:17 "interesting" Aug 02 08:58:22 hehe Aug 02 08:58:27 extending ACLOCAL with -I${S} might help Aug 02 08:58:45 would you inherit autotools or remove it then`? Aug 02 08:58:53 You would keep it if I'm understanding you correct Aug 02 08:59:07 Do you need the output without overwritng do_configure? Aug 02 08:59:10 Should I post it? Aug 02 08:59:14 yeah please Aug 02 08:59:29 I posted it here yesterday but I'm generating it new :) Aug 02 08:59:29 dbus-cxx comes up every month, someone needs to get a working recipe that we can put in meta-oe and be done with Aug 02 08:59:48 ok? So I'm not alone? Aug 02 08:59:57 Maybe I find a wokring upstream in the internet? Aug 02 09:00:50 omfg, I readch the maximum amout of pastes in pastebin, wait I have to create an account :F Aug 02 09:01:23 oh god the last release was in 2013 Aug 02 09:01:32 yep 2013 with 0.8.0 Aug 02 09:03:29 there's been commits in 2015 so they likely need to roll a new release Aug 02 09:05:37 This recpie: http://pastebin.com/HRWLy5z0 give this output: http://pastebin.com/zbqgRKsz Aug 02 09:08:35 The Problem comes form this line: PKG_CHECK_MODULES(DBUS_VER,dbus-1 >= 1.2,AC_DEFINE(HAVE_DBUS_12,[],[If defined, dbus 1.2 or higher is present]),[AC_MSG_RESULT(dbus < 1.2)]) Aug 02 09:08:38 Inside the configure.ac Aug 02 09:09:00 But as I said ... its possible to gernate the configure file Aug 02 09:10:14 you're missing an inherit pkgconfig Aug 02 09:10:31 OOOOKay? Aug 02 09:10:34 Wait I'll try Aug 02 09:10:44 it uses pkgconfig, so you need the dependency Aug 02 09:11:37 i've got a cleaner recipe that i'm wrangling right now with my local security flags which cause libsigc++ to break Aug 02 09:12:26 Yes, now I'm in step install, wow its working, so easy :) Aug 02 09:13:12 would be nice if that error from autoconf was in any way obvious Aug 02 09:14:29 In this case I should be able to remove the "S = " Variable assing? Aug 02 09:14:32 *assign? Aug 02 09:15:04 let me pastebin my recipe Aug 02 09:15:20 you've got a load of non-deterministic behaviour in here btw Aug 02 09:15:30 presence of expat and glib and so on changes how it will buid Aug 02 09:16:16 and popt Aug 02 09:17:06 hm ok Aug 02 09:17:57 and oe-core master doesn't need boost as the gcc is good enough to have c++0x smart pointers Aug 02 09:18:17 http://pastebin.com/PwFuDuvj Aug 02 09:18:39 oh change DESCRIPTION to SUMMARY Aug 02 09:19:37 HyP3r: the readme says the "tools" (whatever they are) need popt, so you'll want that in depends i guess Aug 02 09:21:53 I don't really know the programm which need that library (simple c++ programm) is not written from me... Aug 02 09:21:58 I don't even know what popt is Aug 02 09:22:52 bin_PROGRAMS = dbus-cxx-xml2cpp dbus-cxx-introspect Aug 02 09:22:54 those tools Aug 02 09:23:16 ah disabled by default anyway Aug 02 09:23:18 so ignore the popt thing Aug 02 09:23:29 i think that recipe i pasted is good enough for now :) Aug 02 09:27:01 Yeah looks really good, thank you Aug 02 09:27:35 Now all my recpies from open embeded 2.3 are now working agin with 2.5 ... the next thing would be to write the image generating recipie. Aug 02 09:33:56 For that I copied the Image generating recpie 'console-trdx-image.bb' into my meta-layer and renamed it to 'console-trdx-image-racechip.bb' but now I want that all my packages e.g. dbus-cxx are inside thie rootfs Aug 02 09:34:18 My coworker solved that by partitially adding some of them to the image generating recpie with IMAGE_INSTALL Aug 02 09:34:27 yes, thats how you add stuff to images Aug 02 09:35:03 And some of them with bblayers.conf IMAGES_INSTALL_append Aug 02 09:35:23 This one is global and the other one is local correct Aug 02 09:36:01 bblayers.conf is really the wrong place for such things, use local.conf if you need to set something globally Aug 02 09:36:15 that is correct, but you usually never want to add stuff in bblayers.conf except layers Aug 02 09:36:25 I thought that allready... ok I will put everthing in my image generating recpie, I don't need something global Aug 02 09:36:46 and setting IMAGE_INSTALL globaly is usually wrong. why do you need to do that ? Aug 02 09:36:52 ok Aug 02 09:37:04 My co-worker did that, now hes gone,... Aug 02 09:37:36 Hi all Aug 02 09:37:56 I am getting crazy generating an initramfs image with jetrho and krogoth Aug 02 09:38:04 fido works ok Aug 02 09:38:13 the problem is the readme.txt into image directory Aug 02 09:38:18 any hint on debugging this ? Aug 02 09:38:32 usual rm of the cached directory already done ... Aug 02 09:40:01 pivi: i'm not sure I understand your problem... Aug 02 09:42:43 ERROR: The recipe .... is trying to install files into a shared area when those files already exist. Those files and their manifest location are: ... README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt Aug 02 09:43:00 the recipe is the kernel recipe Aug 02 09:43:21 readme is already there, I suppose installed while generating the rootfs cpio.gz Aug 02 09:44:00 I spend a full day moving around variable, checking my kernel recipe, but I was not able to find anything Aug 02 09:44:07 s/variable/variables/ Aug 02 09:44:28 the kernel image is an uImage, imx6 Aug 02 09:45:53 The this wireless network kernel module which I developed... called wf111.bb. Can I add this kernel module also with INSTALL_IMAGE? Aug 02 09:46:00 *IMAGE_INSTALL Aug 02 09:47:33 HyP3r: it's better to add it to a custom image-foo.bb in your own meta layer that is based on something like core-image-*.bb Aug 02 09:48:04 Switching to your own images pays off really fast. Aug 02 09:48:22 I have my console-trdx-image-racechip.bb which is base on 'image' Aug 02 09:48:37 And inside this script I have a IMAGE_INSTALL += ' ... '; Aug 02 09:49:16 HyP3r: yes you can, but IIRC the package is named kernel-module-wf111 (I had you add it yesterday in local.conf iirc) Aug 02 09:49:36 what? Aug 02 09:49:50 There is no mainline recpie, I wrote it by hand yesterday \o/ Aug 02 09:50:44 probably good to start with some 'mimimal set' of packages that first your needs & then extend Aug 02 09:52:41 HyP3r: yes, you did... I helped you yesterday, that's why I know the name of the generated package :P Aug 02 09:53:05 ah ok, I thought I have to writhe there the names of the bb files Aug 02 09:54:04 no, you have to put the name of the generated package, not the name of the recipe Aug 02 09:54:13 pivi: if t recipe's try to install the same file in ./deploy/images/$machine/ then it will bork. Did you try a few different kernel variations? You can remove them with `bitbake -c clean $recipe` - a last resort would be to `rm -rf ./tmp` - not removing your scene state in there is probably wise :) Aug 02 09:55:08 is there way to get this? E.g. print-generated-packages *.bb Aug 02 09:55:23 jubr: pivi: that's a bit extreme... something really weird is going on there, I have never seen any such conflicts with that file Aug 02 09:56:35 pivi: you aren't by chance trying to build two kernels in the same build? Aug 02 09:56:39 HyP3r: there is but I never can never remember it... it has to do with the too oe-pkgdata-utils but I don't know the exact syntax Aug 02 09:56:43 And another thing: can you recommend a good book about yocto, maybe I have then less dump questions Aug 02 09:56:48 bluelightning: that's what I was thinking Aug 02 09:57:15 bluelightning: not even the same build, consecutively will also complain Aug 02 09:57:59 jubr: right... it's actually explicitly blocked in current versions (you can't build any other provider of virtual/kernel than the preferred one) Aug 02 09:58:38 ah, nice Aug 02 10:02:22 HyP3r, boucman_work: oe-pkgdata-utils list-pkgs, iirc Aug 02 10:02:44 thx Aug 02 10:05:07 oe-pkgdata-util list-pkgs | sort | less Aug 02 10:08:21 hi Aug 02 10:08:36 rburton: nice one, tnx! Beats grepping ./pkgdata any day! Aug 02 10:09:33 what causes this message: "buildDir/poky-krogoth-15.0.0/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.1.bb.do_compile is tainted from a forced run" and who can i get rid of it? Aug 02 10:09:44 how Aug 02 10:10:17 Now while create the rootfs I get this message: http://pastebin.com/PWwKkpcn Aug 02 10:10:22 satisfy_dependencies_for: Cannot satisfy the following dependencies for wf111: Aug 02 10:10:29 kernel-module-unifi-sdio Aug 02 10:15:25 BlitzBlizz: do a `-c clean` and then a regular image build Aug 02 10:16:07 HyP3r: your package kernel-module-wf111 depends on another package kernel-module-unifi-sdio which hasn't been built Aug 02 10:16:26 i'm not sure how to fix that... I don't really know how the kernel infrastructure works... Aug 02 10:17:20 jubr: already tried removing tmp, deploy dir, everything without success Aug 02 10:17:34 bluelightning: as far as I can see only one kernel is present Aug 02 10:17:40 bluelightning: how can I check for sure? Aug 02 10:19:18 HyP3r: did you do a `bitbake -c menuconfig $kernel-recipe`? That .config is not saved, you need to make sure it persists in some way, either in the kernel-source repo, or in your recipe's SRC_URI as `defconfig` traditionally Aug 02 10:19:59 bluelightning, jubr : consider that I have two kernel for my specific machine. my distro is changing this: PREFERRED_PROVIDER_virtual/kernel Aug 02 10:20:51 what i had with fido is 2 different distro/image/kernels that were build a standard image, with separated rootfs, and one with initramfs buildin Aug 02 10:21:12 I am building on two separated work directories, separated sstate-cache, tmp and so on Aug 02 10:23:16 jubr: bitbake -c clean ? Aug 02 10:24:34 BlitzBlizz: bitbake -c clean linux-raspberrypi -- because that is the one that is tainted - for you my defconfig remark also might be relevant? Aug 02 10:27:40 jubr_ defconfig remark? Aug 02 10:39:47 BlitzBlizz: https://www.yoctoproject.org/irc/%23yocto.2016-08-02.log.html#t2016-08-02T10:19:19 Aug 02 12:17:06 I don't get it.... this Kernel Module Recpie http://pastebin.com/1VVjHDdG generates following packages: http://pastebin.com/K0jT4Wws if I take a look into those packages http://pastebin.com/MEbNZzL0 I can sse that wf111 depends on kernel-module-unifi-sdio and kernel-module-unifi-sdio on kernel-4.1.15-v2.5b3+ge6d111c Aug 02 12:17:11 So where is the problem Aug 02 12:20:00 boucman_work: you say that the kernel module kernel-module-unifi-sdio hasn't been built, but I thought that this is generated implicit by my wf111 package Aug 02 12:20:05 or recpie Aug 02 12:40:43 None? Aug 02 12:40:59 I think its a pretty obvious thing, but I have no idea Aug 02 12:47:25 HyP3r: IDK, could you check with "bitbake -c menuconfig virtual/kernel" what is the status of the unifi-sdio option in your kernel (y,n or m) Aug 02 12:47:38 don't change it yet, I'm just figuring out what's happening Aug 02 12:53:20 still working on my broken uimage with initramfs generation ... Aug 02 12:53:37 I removed any reference to initramfs in my local.conf Aug 02 12:53:48 now on deploy dir I have uImage and rootfs.cpio.gz Aug 02 12:54:15 now I should just add INITRAMFS_IMAGE_BUNDLE and INITRAMFS_IMAGE in local.conf Aug 02 12:54:20 and it should just work, right? Aug 02 12:55:15 boucman_work: if I search for unifi-sdio I don't find an entry. Aug 02 12:55:28 boucman_work: So I think that the kernel don't knows this kernel module Aug 02 12:55:46 boucman_work: it is a external module, why should the kernel config knows about that? Aug 02 12:55:54 HyP3r: exactly Aug 02 12:56:32 but how do I get my rootfs generated when there are such strange dependencys? Aug 02 12:57:24 HyP3r: $ oe-pkgdata-util list-pkgs kernel-module-u* Aug 02 12:57:28 is it in the list? Aug 02 12:58:50 HyP3r: $ oe-pkgdata-util lookup-recipe kernel-module-unify-sdio Aug 02 12:58:59 that should be your recipe then Aug 02 12:59:06 wf111 Aug 02 12:59:55 jubr: no Aug 02 13:00:08 ERROR: The following packages could not be found: kernel-module-unify-sdio Aug 02 13:00:51 as I said, this package was _implicit_ generated by my wf111 recpie Aug 02 13:02:51 well it should be found by these tools, so something went wrong there Aug 02 13:03:20 for instance: $ oe-pkgdata-util lookup-recipe kernel-module-cryptodev --> cryptodev-module Aug 02 13:03:53 * jubr has a meeting Aug 02 13:07:03 hm... thats strange yes Aug 02 13:08:15 HyP3r: just so I understand... unifi-sdio is not a standard kernel module, it's one of yours that was compiled by your wf111 recipe ? Aug 02 13:08:24 yes Aug 02 13:08:27 cd .. Aug 02 13:08:30 oops :P Aug 02 13:08:34 the wf111 is generating this driver Aug 02 13:09:33 ok Aug 02 13:09:36 second question Aug 02 13:10:00 I give you everything :) Aug 02 13:10:03 if you go to ${WORKDIR}/packages-split of your wf111 recipe Aug 02 13:10:17 is the .ko file somewhere in that subdir, and if yes, where ? Aug 02 13:15:41 here is the .ko file http://pastebin.com/aQQgqhuU Aug 02 13:16:04 Seems good for me Aug 02 13:16:24 yeah, but that's the sysroot, that's not what i'm interested in Aug 02 13:16:35 i'm trying to figure out in what package that file ended. Aug 02 13:16:48 so, please check if it's somewhere in the package-split of your recipe Aug 02 13:17:49 this: http://pastebin.com/da9S1sUy Aug 02 13:18:41 I can't fine the file unifi_sdio.ko somewhere else Aug 02 13:19:15 HyP3r: try adding "kernel-module-unifi-sdio" to the IMAGE_INSTALL variable Aug 02 13:19:29 (i'm suprised it's not done automatically, but let's see if that's the problem Aug 02 13:19:50 http://pastebin.com/pEHkmXHG Aug 02 13:20:07 Its allready inserted but its still not working Aug 02 13:28:48 boucman_work: ? Aug 02 13:41:08 mm, my problem seemfs related to a rootfs pre/post process command that is adding file to ${IMAGE_ROOTFS} Aug 02 13:41:13 does it make sense? Aug 02 14:10:26 rburton, boucman_work or jubr none of you has an idea? I would be really happy if you help me Aug 02 14:38:30 it seems that anything thats is modifying rootfs in a pre/post process command is breaking initramfs image deploy .... Aug 02 14:38:39 just adding INHERIT += "image-buildinfo" Aug 02 14:38:47 is enough to break everything Aug 02 14:44:55 And another question is how to patch the kernel device tree? I have no idea whats the best practise is Aug 02 14:45:06 I follow now this tutorial http://stackoverflow.com/a/34187967/5232865 Aug 02 14:55:03 YPTM - Armin in on Aug 02 14:57:22 oh! Aug 02 14:57:50 YPTM: Saul is on and Leading Yocto Project Technical Meeting Aug 02 14:58:29 Ready-Access Number: +1 8007302996 or +1 9139049836 Access Code:     2705751 Aug 02 14:59:00 YPTM: Joshua is on Aug 02 14:59:09 YPTM - Mark is on Aug 02 15:00:23 YPTM: belen is on Aug 02 15:00:27 David Wolfe from Bosch here. Aug 02 15:00:52 YPTM ross on Aug 02 15:03:29 YPTM: Richard joined, sorry I'm late Aug 02 15:04:18 Smart -probably- for 2.2.. DNF being investigated Aug 02 15:25:19 HyP3r: FILES_INFO: {} <-- that'[s a plroblem, means the pkg is empty Aug 02 15:31:01 jubr: ??? where do you have this information? Aug 02 15:34:01 Hello, can anyone help me a build error I am having -- i am trying to build NTP 4.2.8p8 using a .bb recipe i found online and am having the error Aug 02 15:34:10 fatal error: not a git repository Aug 02 15:34:27 I am not sure why, when i dont have a git repository -- nor do i need/want one Aug 02 15:34:38 pastebin more logs than that please Aug 02 15:34:39 i have the .tar.gz file locally Aug 02 15:35:26 test build ntp-4.2.8p8 Aug 02 15:35:26 NOTE: Handling BitBake files: - (6357/6357) [100 %] Aug 02 15:35:26 NOTE: Parsing finished. 6083 cached, 0 parsed, 274 skipped, 0 masked. Aug 02 15:35:26 NOTE: build 201608021035: started Aug 02 15:35:26 fatal: Not a git repository Aug 02 15:45:19 rburton: from what do you want to have logs? I can give you everything, but I slowly getting insane... Aug 02 15:46:27 guest_IRC: are you using http://cgit.openembedded.org/cgit.cgi/meta-openembedded/tree/meta-networking/recipes-support/ntp/ntp_4.2.8p8.bb?h=master? Aug 02 16:08:30 Here are all the logs about the do_rootfs runtime and the error at the end: http://pastebin.com/Gn6a5gcG http://pastebin.com/QPxNWrNe http://pastebin.com/jyBXDTX8 Aug 02 16:08:43 * satisfy_dependencies_for: Cannot satisfy the following dependencies for wf111: Aug 02 16:08:43 * kernel-module-unifi-sdio * Aug 02 16:09:31 And here is the recipe: http://pastebin.com/pcjjwBSe Aug 02 16:11:31 The recpie for the image: http://pastebin.com/Vc6wLCZB Aug 02 16:14:07 hi, if I update init-ipupdown with opkg, is opkg supposed to come back to me only after the network interface is available again? Aug 02 16:14:22 or does it not guarantee blocking for down and up? Aug 02 16:15:50 if the postinst for ifupdown is dropping networking then i'd be running it in a screen Aug 02 16:16:04 (if you're doing it over network) Aug 02 16:20:20 And a short overview: http://pastebin.com/LW4PEVeE Aug 02 16:21:46 rburton: you are right this FILES_INFO is empty Aug 02 16:36:17 Now it working, I just had to 'ignore' the *.ko file, so that it was able to import the kernel file Aug 02 16:45:50 HyP3r: I got it from your pastebin. rburton noticed as well. Aug 02 16:46:30 * jubr needs to leave work, see y'all tomorrow :) Aug 02 19:23:48 okay, i am now really confused by a thing. Aug 02 19:24:19 Apparently, there's a point at which bitbake is statting a file, then hardlinking to it, then changing the ownership and mode of the link to match the original. Aug 02 19:24:20 Whyyyyy. Aug 02 19:24:28 Aug 02 19:24:41 heh, i'm pretty generally confused. Aug 02 19:32:20 seebs: might be a kind of cheap copy that also preserves the file metadata Aug 02 19:34:30 But a hard link *always* has the same mode and ownership. Aug 02 19:34:53 So it doesn't make sense to request a permissions change to match the existing permissions. Aug 02 19:37:20 seebs: might be redundant if that's the case, yeah. i don't know off the top of my head if there are exceptions. Aug 02 19:38:03 And of course, because the original file wasn't tracked in pseudo, and pseudo "fixes" filesystem permissions (adds u+w, removes go+w) under the hood, this results in the original file's mode potentially changing. Aug 02 19:38:23 So I probably have to add tracking for files linked-to, which is slightly annoying, but it also may not come up if we don't make those calls. Aug 02 19:38:34 But it seems weird that those calls exist in the first place, and I assume it must have been done for a reason. Aug 02 19:39:03 historial reasons, possibly Aug 02 19:41:24 seebs: maybe the uid/gid of the inode will be changed if you hardlink it to a directory with the setuid/gid bit set and a different uid/gid. doubt it though. :P Aug 02 19:41:50 that seems too obscure as well Aug 02 19:44:41 Huh. I have no idea. I think those bits only apply to creation, though. Aug 02 19:45:49 yeah, creating a new link to an already existing file might not count **** ENDING LOGGING AT Wed Aug 03 02:59:58 2016