**** BEGIN LOGGING AT Fri May 08 02:59:59 2015 May 08 07:36:04 good morning May 08 07:38:19 morning May 08 08:29:20 morning all May 08 08:36:30 mornign May 08 08:46:58 im trying to find the addresses for the usb driver on my yocto system. in /sys/bus/pci/drivers/?hci_hcd May 08 08:47:10 but nothing shows up there, is this changed recently? May 08 08:47:29 bind module new_id remove_id uevent unbind May 08 08:47:57 those are there, but none of the 0000:02:00.0 0000:03:00.0 May 08 09:13:25 <[w00t]> Hi, I have a question that I'm hoping someone here can answer.. Is it possible to build a genericx86, core-minimal build without GPLv3? I'm running into dependency issues when using hob to build my image. It depends on initramfs-live-install which in turn depends on parted which is GPLv3. May 08 09:16:24 It's possible to build an image that does not use GPLv3 software. I'm not sure whether it is possible to build an image without GPLv3 tools, though. May 08 09:18:40 [w00t]: when you say parted is it explicitly mentioning parted-native in the error (as opposed to just parted) ? May 08 09:20:16 <[w00t]> bluelightning: "Nothing RPROVIDES 'parted' " ... "parted was skipped: incompatible with license GPLv3+" May 08 09:20:48 ah ok, so it really is parted May 08 09:21:10 <[w00t]> neverpanic: Thanks, I guess parted could be removed after the live-install? May 08 09:21:27 [w00t]: the problem is that it is attempting to build a live image, and that live image needs our install script that in turn needs parted May 08 09:21:56 unfortunately that is probably a bug that we need to fix, I don't think there is an immediate workaround unless you don't actually need to build a live image May 08 09:22:32 <[w00t]> bluelightning: How would I go about to create a normal (non-live) image? I'm on my first day using yocto :) May 08 09:23:00 [w00t]: which target machine did you select? May 08 09:23:18 <[w00t]> bluelightning: genericx86 May 08 09:23:38 [w00t]: ok, so the live image output type is being selected for you May 08 09:25:34 <[w00t]> bluelightning: What I'm looking for is a generic build for an x86 arch. I'm not in need of a live-image though an installer would be nice but I could do without May 08 09:25:53 [w00t]: you'll probably need to temporarily edit meta/conf/machine/include/x86-base.inc and comment out the IMAGE_FSTYPES += "live" line May 08 09:26:12 you'll need to close and restart hob as well May 08 09:26:18 (afterwards) May 08 09:26:38 <[w00t]> bluelightning: Ah, I see.. I'll try that May 08 09:27:44 <[w00t]> bluelightning: Thanks a lot for the help May 08 09:39:48 <[w00t]> bluelightning: I've removed the "live" from IMAGE_FSTYPES and restarted hob, I still get the same dependency issue though.. May 08 09:45:12 [w00t]: double-check you don't still have 'live' selected in Hob's configuration May 08 09:47:44 <[w00t]> bluelightning: Ok, where's that located? May 08 09:48:00 [w00t]: IIRC there is a button in the top right May 08 09:48:40 at the first screen, it's called "Settings" May 08 09:49:51 actually sorry May 08 09:50:05 [w00t]: it's under "Advanced configuration" which you see after selecting a base image May 08 09:51:42 <[w00t]> bluelightning: Ok, I only got two tabs, and none of those contain anything about live images May 08 09:52:06 [w00t]: it's called hddimg there, is that ticked? May 08 09:52:36 <[w00t]> bluelightning: Nope, got ext4 and tar.bz2 checked May 08 09:52:53 ok, I'm really not sure what's going on then :( May 08 09:53:13 there's nothing in local.conf that is adding "live" to IMAGE_FSTYPES ? May 08 09:54:46 <[w00t]> bluelightning: Nope May 08 09:55:19 sigh May 08 09:55:27 ok, close hob, run bitbake -e | less May 08 09:55:49 then search (with /) for IMAGE_FSTYPES May 08 09:56:25 once you find the entry for that variable itself, is there anything in the history for how it was set that says that "live" is being added? May 08 09:58:09 <[w00t]> # $IMAGE_FSTYPES [4 operations] May 08 09:58:10 <[w00t]> # set /home/dan/yocto/poky/build/conf/local.conf:261 May 08 09:58:10 <[w00t]> # "ext4 tar.bz2" May 08 09:58:10 <[w00t]> # append /home/dan/yocto/poky/meta/conf/machine/include/x86-base.inc:13 May 08 09:58:10 <[w00t]> # "" May 08 09:58:10 <[w00t]> # set /home/dan/yocto/poky/meta/conf/documentation.conf:214 May 08 09:58:10 <[w00t]> # [doc] "Formats of root filesystem images that you want to have created." May 08 09:58:11 <[w00t]> # set? /home/dan/yocto/poky/meta/conf/bitbake.conf:693 May 08 09:58:11 <[w00t]> # "tar.gz" May 08 09:58:12 <[w00t]> # pre-expansion value: May 08 09:58:12 <[w00t]> # "ext4 tar.bz2 " May 08 09:58:13 <[w00t]> IMAGE_FSTYPES="ext4 tar.bz2 " May 08 09:58:29 ok, so it's hob getting in the way then :/ May 08 09:58:45 my advice for now would be to stick to the command line May 08 09:59:07 <[w00t]> bluelightning: :) Ok, thanks May 08 09:59:09 not a great answer I know, but it's easier to debug May 08 10:00:04 <[w00t]> bluelightning: Does hob append anything, I thought it was just a fronten May 08 10:03:16 [w00t]: it does have some logic to set the configuration yes May 08 10:03:51 unfortunately in your case it appears to be doing it incorrectly May 08 10:05:40 <[w00t]> :) I need to run the builds through the command line either way, just thought hob was a neat place to start understanding the build process. Thank you so much for your help May 08 10:06:47 * bluelightning is really looking forward to the day we replace Hob with Toaster May 08 10:11:07 hi all! May 08 10:11:49 i have a question about qt creator, is there a way to deploy and debug c++ application on yocto in QEMU? May 08 10:37:06 bluelightning: hi, I just want to say thank you for pointing the thread out the other day. It seems that those two patches solved my kernel boot problems May 08 10:38:10 lpapp: \o/ May 08 10:38:43 we probably should have some kind of note in the migration section with pointers to those May 08 10:38:54 for people building their own older kernel versions May 08 10:39:09 could have saved me, yes :) May 08 10:39:41 as far as I understand it is a generic arm issue with newer libs, so anyone using old arm kernel would face it, which is probably a common platform on embedded. May 08 10:39:47 gcc* May 08 10:40:02 not sure how common it is to use old kernel though May 08 10:41:53 there is one more thing that I noticed after the boot May 08 10:42:03 which was not in there before. May 08 10:43:49 "Too many levels of symbolic links" May 08 10:46:00 hi lpapp May 08 10:47:58 hi rzr May 08 10:48:05 nice to see you here :) May 08 10:48:41 good pple are allways in good place ;) May 08 10:48:55 yea I am kinda new to yocto May 08 10:54:25 question how long could it take to get a patch merged into poky , mine was send week ago and no feedback yet May 08 10:54:56 have you checked the state whether it is merged? May 08 10:55:05 it happened to me several times that I got no replies and it was already merged May 08 10:55:15 so it is always the first thing to check IMHO if there is no reply :) May 08 10:56:26 yea I checked May 08 11:01:25 RzR: "If your patch has not had any feedback after a few days it may have been missed or the appropriate reviewers may not currently be around; it is perfectly fine to reply to it yourself with a "ping" / reminder request for feedback. " May 08 11:01:33 from: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Community_review May 08 11:01:58 this what i am doing now :) May 08 11:02:31 cool May 08 11:02:53 but there werent much trafic in poky lists lately ... so I'll may wait a bit more May 08 11:14:44 is it a poky change in question or more like openembedded core? May 08 11:36:34 lpapp, https://lists.yoctoproject.org/pipermail/poky/2015-April/010094.html May 08 11:36:56 bluelightning: is this a common symptom after the migration? https://paste.kde.org/pl4mjolr8 May 08 11:38:54 RzR: I see. It seems to be quite specific stuff, so perhaps include the author of the file in the CC? May 08 11:42:44 RzR: possibly the wrong list, I think you want oe-core for that May 08 11:53:56 joshuagl, dobrigado ! , I dont think that package belong to oe . those init scripts land in poky now May 08 11:56:43 RzR: meta/ is usually oe-core May 08 11:56:53 something like meta-yocto would be Poky, I assume. May 08 11:59:44 it is May 08 12:01:02 let me double check May 08 12:03:05 joshuagl, you're right http://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/wayland/weston-init/init May 08 12:03:12 joshuagl, sorry for the noise May 08 12:05:35 np May 08 12:09:59 without you it will have stayed there forever ;) May 08 12:10:35 lpapp: I've never seen that one before, sorry May 08 12:13:46 ok, looks like inittab is broken :) May 08 13:06:15 bluelightning: does Yocto create any symlink by default between /run and /var/run, etc? May 08 13:06:27 iirc, yes May 08 13:08:02 which way is it? May 08 14:11:27 so yesterday I had some questions about using my own defconfig May 08 14:12:33 I ended up having to put SRC_URI="file://defconfig-mine" in my recipe, as well as May 08 14:12:43 do_configure_prepend() { cp ${WORKDIR}/defconfig-mine ${WORKDIR}/defconfig} May 08 14:13:31 my goal is to just have this recipe inherit kernel, and SRC_URI="file://defconfig" in order to use the correct configuration file. May 08 14:16:07 do i need to inherit linux-yocto for this functionality? May 08 14:35:21 rschaef: no, this is provided by kernel.bbclass May 08 14:35:55 rschaef: if you use file://defconfig instead of file://fefconfig-mine, you should not need the do_configure_prepend at all May 08 14:36:22 so my original SRC_URI of file://defconfig should just work if my class inherites kernel May 08 14:36:54 but in the end, in the build directory, it is not the correct defconfig May 08 14:53:00 rschaef: is it completely wrong or are there just slight differences? May 08 14:54:07 completely wrong. I included a comment on the first line (# CORRECT CONFIG ) in order to determine if my defconfig was being used. May 08 14:54:29 are you looking at defconfig in workdir or .config in the build dir? May 08 14:54:34 oldconfig would likely remove any comments you added May 08 14:54:48 also, if your defconfi gisn't for that exact kernel version, it would change to add new config items that didn'te xist previously May 08 14:54:50 * kergoth yawns May 08 14:54:51 morning all May 08 14:54:59 even after I run a cleansstate and cleanall ? May 08 14:55:02 morning May 08 14:55:16 ? May 08 14:55:26 make oldconfig runs in do_configure after defconfig is copied to .config May 08 14:55:33 so it depends entirely on when you're checking and what you're checking May 08 15:16:54 okay yeah the comments were being removed by oldconfig, defconfig works fine. May 08 15:17:21 are config fragments handled in kernel.bbclass, or do I need linux-yocto? May 08 15:17:40 linux-yocto, or you can manually arrange to call the tools to use them May 08 15:22:38 okay. and if I use linux-yocto, will it still find my own defconfig by default? May 08 15:23:10 yep May 08 15:23:29 * zeddii_home is also re-working things so you don’t have to include linux-yocto, but that’s only in a month or so. May 08 15:23:52 it looks like it in kernel-yocot.bbclass:do_kernel_configmer() May 08 15:23:56 oh okay thanks! May 08 15:24:28 zeddii_home: are you planning on adding it natively to kernel.bbclass? May 08 15:24:33 that'd be lovely May 08 15:24:36 yep May 08 15:24:52 I have the meta data completely split out of the kernel tree itself, that’s step #1. May 08 15:25:04 then the tools aren’t tied to a particular kernel tree format. May 08 15:25:18 woot May 08 15:25:21 I’m doing the second parts now. hopefully a RFC soon. May 08 15:27:43 going to have the kern-tools-native dep conditionally added based on fragments existing in SRC_URI? May 08 15:42:21 now that you mention it. yes :) May 08 15:43:32 :) May 08 15:45:15 is there currently a yocto way of pointing to a previously built initramfs? basically just setting CONFIG_INITRAMFS_SOUCE? May 08 16:37:49 Is there a better way to include a pre-built initramfs in the kernel than using a config fragment for CONFIG_INITRAMFS_SOURCE with a hard-coded path to the initramfs.cpio.gz file? May 08 16:44:24 rschaef: see http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-INITRAMFS_IMAGE May 08 16:46:43 afaik INITRAMFS_IMAGE is for building an image, though, not using a prebuilt one May 08 16:46:50 that variable is used to build the initramfs as well correct? What if I just want to grab it from /files dir May 08 16:47:43 RP: rburton: I'd like to do a build on the AB - any objections? May 08 16:49:35 RP: rburton: fwiw the AB is currently very idle May 08 16:51:49 joshuagl: go for it May 08 16:52:27 thanks RP! May 08 16:52:38 * joshuagl presses the button May 08 18:44:05 Hi, I'm having a problem building any image using yocto 1.8. Bitbake is having a problem parsing a recipe inside the meta directory. Has anyone heard about this? This is the error message shown (paths were hidden): http://pastebin.com/UVJcFeJJ May 08 19:24:29 Just figured it out. One of my layers was improperly defining license files May 08 19:58:58 Anyone know of a clean way to take a list of git commits and reorder / sort them in the order they're in in the history? May 09 00:46:25 I have an application that checks uname -m (machine name; eg. x86, armv7l, etc.) against a configuration file. Is there a way at build time to know the target systems machine type? Otherwise I'll just create an init.d script to sed the config file at first boot or something May 09 00:48:25 i don't know of a variable that perfectly matches uname -m, most likely TARGET_ARCH or PACKAGE_ARCH would be closest. you'd probably want to maintain a case statement or mapping between the oe info and what it expects May 09 00:50:55 Thanks for the info kergoth! I'll take a look. **** ENDING LOGGING AT Sat May 09 02:59:59 2015