**** BEGIN LOGGING AT Tue Sep 29 02:59:58 2015 Sep 29 03:58:45 where can i find a good yocto build tutorial? Sep 29 06:31:48 Hi.. does any one know why toaster has to depend on exact versions of e.g. django and south.. and has it been recently tried with e.g. ubuntu 14.04 LTs Sep 29 07:17:40 good morning Sep 29 07:42:38 morning all Sep 29 08:24:55 Is there a guide for creating a package from scratch? I'm trying to add a python package to a system, and it seems to be failing on do_rootfs (error: can't install packagegroup-$FOO: no package provides $BAR), where $BAR is the name of the package I'm writing Sep 29 08:26:53 my current suspicion is that I am missing something mandatory. Here is what I have in my recipe: http://pastebin.com/RpbWGvET Sep 29 08:27:57 <[Sno]> moin bluelightning ;) Sep 29 08:33:14 hi [Sno] Sep 29 08:33:38 <[Sno]> I though when noone responds to your nice morning greetings >:-) Sep 29 08:34:35 it's ok, if I don't get a response here I usually do in one of the other channels :) Sep 29 08:34:48 jonathanmaw: this may be helpful: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#new-recipe-writing-a-new-recipe Sep 29 08:35:07 bluelightning: ooh, thanks Sep 29 08:35:38 jonathanmaw: I suspect what's happening in your case is the package is ending up empty and thus is never produced - you probably need to inherit setuptools or distutils Sep 29 08:36:03 (and that will define a useful do_install, ensuring the files actually get installed to the right locations so they can then be packaged) Sep 29 08:48:04 <[Sno]> any hint how to create multiple base-files builds depending on device for target installation? Sep 29 08:48:27 <[Sno]> we have the situation, that /etc/fstab is installed from base-files recipe in poky/oe Sep 29 08:49:12 <[Sno]> this fstab file is replaced via a bbappend recipe modifier which installs /, /data and /boot based on WANTED_ROOT_DEV in local.conf Sep 29 08:50:28 <[Sno]> for some targets we have /dev/mmcblk2, /dev/mmcblk1 and /dev/sd? as sane boot device (/dev/mmcblk1p2 for / etc. in such a case) and for other targets eg. /dev/ubi0_2 as device for / (cause it's nand based ...) Sep 29 08:50:54 <[Sno]> any hints how to avoid complete rebuilds for base-files anytime one changes WANTED_ROOT_DEV? Sep 29 08:51:34 well, if you don't want base-files rebuilt then wouldn't you need to do the switching somehow at runtime? Sep 29 08:52:10 <[Sno]> read-only rootfs ;) Sep 29 08:52:37 hmm, well you're stuck then... base-files is already marked machine-specific at least so it'll only affect the one machine Sep 29 08:52:42 <[Sno]> is it possible to have a base-files-nand, base-files-usb, base-files-emmc ...? Sep 29 08:52:58 shouldn't you be setting WANTED_ROOT_DEV from the machine config? (or at least with a machine override)? Sep 29 08:53:11 AndersD: I guess you're the one I've to thank. Still digesting your answer before replying... waiting to bake an experiment Sep 29 08:53:14 <[Sno]> a machine can have several ones Sep 29 08:53:38 <[Sno]> bluelightning: as you can boot a device from internal emmc or from usb-stick Sep 29 08:54:09 hmm, well, this can't be a new problem but I have to admit I'm not sure of the proper solution Sep 29 08:56:38 <[Sno]> bluelightning: well, do you have an idea where to ask such a questions? mailing-list will float it (as seen in past) Sep 29 08:57:10 the mailing list is hit and miss, like a lot of things; sometimes you get a response, sometimes you won't Sep 29 08:57:51 <[Sno]> yeah ... so you mean, it's the right place and in doubt ask repeatedly? Sep 29 08:57:56 I think people do their best to reply when they have an idea of how to answer the question Sep 29 08:58:21 I'd say try the mailing list yes Sep 29 08:58:35 <[Sno]> ok, will do ;) Sep 29 08:58:37 <[Sno]> thanks Sep 29 09:05:31 IvanSB, Quite likely. Sep 29 11:27:13 Hello, I'm having trouble adding a file to my final tar.bz2 package, the file is a .dtb in the /boot/ dir and it's already in the ${IMAGE_ROOTFS} dir Sep 29 11:27:27 however it doesn't seem to go from there to the final tarball Sep 29 11:28:01 I imagine I'm missing an "install" line somewhere but am a bit lost, does anyone know how I move the file to my final build? Sep 29 11:54:59 gardarh: how is it entering the ${IMAGE_ROOTFS} directory? Sep 29 12:00:49 bluelightning: as a part of the imagedeploy job Sep 29 12:01:24 bluelightning: I copy it from the $DEPLOY_DIR_IMAGE to the $IMAGE_ROOTFS/boot during imagedeploy Sep 29 12:01:32 gardarh: I would recommend defining a function and then adding a call to that function to ROOTFS_POSTPROCESS_COMMAND Sep 29 12:01:43 gardarh: at the moment I suspect you are copying it in too late Sep 29 12:02:38 bluelightning: I have this at the bottom of this script: addtask imagedeploy after do_rootfs before do_build Sep 29 12:02:49 gardarh: yep, definitely too late Sep 29 12:03:03 the image is already compressed and written out by then Sep 29 12:03:04 bluelightning: So, you're saying that the critical moment is happening after do_rootfs and before do_imagedeploy Sep 29 12:03:34 bluelightning: Thanks, I'll look into this Sep 29 12:03:40 all of the image construction happens within do_rootfs... so anything you want to insert into the image has to happen within that task Sep 29 12:03:55 bluelightning: Ok, that explains it Sep 29 12:04:07 (or alternatively into a package that gets incorporated into the image, of course) Sep 29 12:11:24 bluelightning: Adding a function to ROOTFS_POSTPROCESS_COMMAND worked like a charm, thank you! Sep 29 12:12:16 gardarh: great, no problem :) Sep 29 12:20:04 Can someone provide any advise on how to debug a image dependency issue? it seems IMAGE_TYPEDEP_xxx is not working Sep 29 12:25:46 otavio: bitbake -g and bitbake -e would be my first tools for such an issue Sep 29 12:26:18 bluelightning: it seems it is generating images in parallel even if a dep is explicit Sep 29 12:37:19 bluelightning: what is failing is the compression Sep 29 14:50:07 halstead: still connected after overnight idle ;) Thanks! Sep 29 15:40:28 hmm, question, if both systemd and sysvinit are in distro features, and we build a systemd image, and systemd is built with sysv compat, which is the case by default, will it try to start the services twice, due to having both .services and /etc/init.d/ entries? I'm assuming the answer is yes, though maybe it checks for duplicates if hte names are the same? Anyone know? Sep 29 15:41:12 kergoth: I believe it does match them by name Sep 29 15:41:27 (and ignore the service file) Sep 29 15:41:49 okay, that's what i was hoping for, otherwise our images would be pretty screwed up when both features are enabled :) Sep 29 15:41:51 just got to wondering Sep 29 15:42:38 kergoth: it matches by name and ignores init scripts which have the same name as a unit Sep 29 15:42:53 whew, okay, thanks Sep 29 15:42:54 (if you look in oe-core around the time of the systemd merge, you'll see some patches to rename init scripts) Sep 29 15:43:03 makes ense Sep 29 15:43:04 sense Sep 29 17:04:39 Hello. Sep 29 17:06:00 qemu-native recipe is failing to build and the error suggests to install SDL devel. I have installed all SDL devel packages available on my distro but it still failing at the same point. Any clues? Sep 29 17:07:48 you must have missed a package. but if you want to, you can build qemu without sdl. read local.conf, there are 3 lines to comment out to disable sdl in qemu Sep 29 17:08:12 kergoth: well, I haven't selected any package, is just a default config. Sep 29 17:08:25 that doesn't even make sense Sep 29 17:08:30 THe only think I have changed is the MACHINE, in conf/local.conf Sep 29 17:08:38 you just said you installed all the sdl devel packages on your host, i said you must ahve missed one Sep 29 17:08:42 has nothing to do with configuration of the build Sep 29 17:08:52 but again, yes, sdl is used for qemu by default, and again, as i just said, you can disable that in local.conf Sep 29 17:09:02 kergoth: I will try it, thanks :-) Sep 29 17:12:01 kergoth: commenting those 3 lines fixed the problem. Anyway, do you think I miss some sdl-devel package? https://paste.kde.org/pd1o2jxr7 Sep 29 17:13:13 Hmm, not seeing anything obvious. I'm not an sdl expert, though. could always check the qemu docs to see what version of sdl it wants or what host sdl packages you should install. we're just building qemu, it's qemu that's checking for the sdl files and erroring Sep 29 17:13:57 kergoth: I will have a deeper look tomorrow. Sep 29 17:14:08 Thanks :-) Sep 29 17:17:37 happy bday joshuagl Sep 29 17:19:57 Hmm, would there be interest in adding a SYSTEMD_LOGLEVEL variable to alter the default loglevel in the systemd system configuration, or do folks think control via kernel cmdline is sufficient? distros may well care about bootup message verbosity Sep 29 18:33:10 is it possible to verify from a makefile (generated using autotools) not from recipe if systemd is used, in a yocto build environment Sep 29 18:50:09 hanthings: I guess the way to do that would be to export an environment variable into the build based on systemd being in DISTRO_FEATURES Sep 29 19:00:48 bluelightning: Thanks for answer. How exactly can I do that? Is there somewhere a similar example? Sep 29 19:02:38 I can't think of one off the top of my head but it would be something like: Sep 29 19:03:49 export VARNAME="${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '1', '0', d)}" Sep 29 19:03:56 (within the task function) Sep 29 19:07:19 when I say within the task function, it would be within do_compile() { ... } (or do_compile_prepend() { ... } if you haven't defined your own do_compile within the recipe) Sep 29 19:12:43 EXTRA_OEMAKE += "'VARNAME=${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '1', '0', d)}'" would be another alternative Sep 29 19:12:49 * kergoth yawns Sep 29 19:14:31 bluelightning, kergoth: Thanks both. this is what I needed Sep 29 19:15:14 kergoth: ah yes that would probably be better :) Sep 29 20:53:39 why do I get the error Files/directories were installed but not shipped [installed-vs-shipped] Sep 29 20:54:18 I know how to fix it, but I don't fully understand the reason of it Sep 29 20:56:27 it means what it says. files were installed (by do_install) but not included in any binary packages Sep 29 20:56:57 a recipe can emit any number of packages, as listed in PACKAGES, and the files included in FILES_ for each packagename go in the packages Sep 29 20:57:21 kergoth: :) I don't understand why I get the error only to some recepies Sep 29 20:57:23 so either you installed something to a wrong path, or you need to add those paths to the FILES vars to ensure they're included in the package want them in Sep 29 20:57:25 that doesn't make sense. Sep 29 20:57:41 if you get that message, it's a bug in the recipe Sep 29 20:58:01 that's true i want to install something in a different path /usr/libexec Sep 29 20:58:15 what's a wrong path? Sep 29 20:58:38 make sure you're obeying our path variables, for one. you'd wnat ${libexecdir} in this case Sep 29 20:58:49 the default FILES_ variables include the most common paths, that's all Sep 29 20:58:56 if you put things in places that aren't in the default, then you have to add to them Sep 29 20:58:57 it's not magic Sep 29 20:59:07 read meta/conf/bitbake.conf for the defaults Sep 29 21:03:04 in my situation I use the makefile to install the binary file in the /usr/libexec Sep 29 21:03:39 then you'd need to pass the right paths into the makefile Sep 29 21:03:42 so is not part of recipe Sep 29 21:04:35 I use in the makefile the path /usr/libexec Sep 29 21:05:13 it looks that yocto is mapping the libexec, by default, to /usrlib Sep 29 21:05:42 that's precisely what i meant by 'wrong path', not obeying our path variables :) Sep 29 21:05:57 you'll want to use EXTRA_OEMAKE to pass in the path variables so the makefile can obey them Sep 29 21:06:20 :) ok but i do want to install my binary to /usr/libexec Sep 29 21:06:32 and my makefile does that Sep 29 21:06:48 thinking you know better than the distro is almost always wrong Sep 29 21:06:58 but if you think you know better, add your path to the FILES variables as i described already Sep 29 21:07:08 but why yocto does consider /usr/libexec a non-standard path? Sep 29 21:08:00 In the past, /usr/libexec, while a common practice, wasn't FHS-compliant Sep 29 21:08:20 modern versions of FHS do allow it, but i don't htink we've updated to use it. rburton1 had a patch series toa ddrress it, but i'm not sure it went in Sep 29 21:08:24 see also http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html Sep 29 21:09:01 if your distro wants to use /usr/libexec, you can always set libexecdir differently, and that way all the recipes will use it, not just yours, and you can use our path variables in the recipe the way you should Sep 29 21:09:31 aha. according to FHS the /usr/libexec is the place for executable used by other programs Sep 29 21:09:51 regarding rburton1's patches, googling for '[OE-core] [RFC] Move libexecdir to $prefix/libexec' will probably find the emails Sep 29 21:09:52 kergoth: didn't get into 2.0, will push for 2.1 Sep 29 21:09:56 yes, but read the Rationale on that page Sep 29 21:10:04 "Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. [26] To accomodate this restriction, it became common practice to use /usr/lib instead." Sep 29 21:10:12 rburton1: ah, k, thanks Sep 29 21:10:17 i was curious about that myself Sep 29 21:10:26 FHS5 which supports /usr/libexec explicitly is very new Sep 29 21:10:36 iirc, poky-contrib:ross/libexec is my branch Sep 29 21:11:05 its basically just a matter of changing libexecdir in your distro conf Sep 29 21:11:17 kergoth: thanks a lot. really helpful Sep 29 21:11:40 i had to read rburton1's emails to remember why we used libdir/BPN myself, couldn't remember the details :) Sep 29 21:12:09 libdir/BPN was basically the worst option too, gnu coding style says "don't do this" :) Sep 29 21:12:22 rburton1: true. just wanted to understand the details Sep 29 21:12:48 * kergoth makes a note to adjust libexecdir in mel until 2.1 hits Sep 29 21:52:48 khem: your distutils3.bbclass uses MACHINE in HOST_SYS, which makes anything using it machine-specific. i'll note that distutils.bbclass doesn't need that, so is it really required? **** ENDING LOGGING AT Wed Sep 30 02:59:58 2015