**** BEGIN LOGGING AT Wed Nov 11 02:59:58 2015 Nov 11 07:52:01 hi guys Nov 11 07:53:56 i created an image recipe for my raspberry pi but i don't have any perl module. i just did a IMAGE_INSTALL_append = " perl" Nov 11 07:54:18 i thought i would have a lot of perl modules as it seems there is a lot in the perl recipe Nov 11 07:58:33 another thing is i have a lot of errors at each build: http://pastebin.com/BGTBr9LF Nov 11 08:15:06 good morning Nov 11 08:27:36 drou|: IMAGE_INSTALL is about packages, not recipes: a recipe can build multiple packages and installing one of those packages does not mean all of them are installed Nov 11 08:30:59 jku_: ok, so how can i get the appropriate package ? eg perl-module-socket Nov 11 08:34:42 drou|: appending exactly that should work (in a production setting your perl script recipe should of course depend on it instead) Nov 11 08:35:27 hum, i need to have a perl.bbappend that RDEPENDS on this particular module, right? Nov 11 08:35:39 drou|: alternatively "perl-modules" should give you all perl modules that can currently be built Nov 11 08:37:14 it tells nothing provies perl-modules, it is the same for perl-module-socket Nov 11 08:42:16 drou|: is this when you do IMAGE_INSTALL_append = " perl-module-socket" ? Nov 11 08:44:19 no, i thought it was better to have a recipes that RDEPENDS on this, instead of appending the IMAGE_INSTALL with this module. but in fact, it is working Nov 11 08:48:41 Morning, is there a way to do an 'addtask' depending on a machinoverride? Nov 11 08:48:54 Yocto blog doesn't mention 2.0/Jethro release - where's the best place to link to for that info? Surely not the mailing-list thread? Nov 11 08:49:53 drou|: yeah, depending is "better". It shouldn't be perl that depends on the module though, it should be the package that contains script that actually requires module-socket Nov 11 08:54:23 jku_: that is exactly what i did before, i did a RDEPENDS_${PN}_append = " perl-module-socket" but it didn't help. cant figure out why Nov 11 08:56:40 maybe this is something related to the lot of errors log i get Nov 11 08:59:55 drou| those seemed like broken configuration -- maybe double check conf/bblayers.conf ? Nov 11 09:03:15 jku_: yes, but it looks good: http://pastebin.com/GQJ5JLd4 Nov 11 09:05:57 drou|: I believe BB_PATH isn't what you think... it's literally the PATH variable used when the environment is initialized Nov 11 09:06:14 you can't use it to build BBLAYERS Nov 11 09:09:37 morning all Nov 11 09:11:00 hi bluelightning Nov 11 09:13:15 jku_: so i need to put the BBPATH variable to my build directory? Nov 11 09:14:14 drou|: I'd just try setting BBLAYERS with full paths Nov 11 09:14:43 i get it, BBPATH is ok, but the bblayers paths are not Nov 11 09:15:26 that's how it looks to me Nov 11 09:15:48 thanks! Nov 11 10:25:54 khem: seems there is a philosophical problem wrt. ldap dependency (eg. for samba 4) Nov 11 10:26:34 it might lead to a consensus discussing it qickly instead of shooting mails around over days Nov 11 10:26:59 same for sysvinit/lsb init scripts Nov 11 10:28:50 RP: I managed the Perl6 recipes - thanks for your guidance Nov 11 10:43:33 say that I have a layer that adds support for the machine "foo", and I want to make another layer that just changes a few things in the local.conf of that layer, but otherwise changes nothing. can I keep "foo" as the machine name in the new layer? Nov 11 10:43:54 more specifically, I want to build for the same machine but change some DISTRO_FEATURES Nov 11 10:46:46 or am I confusing layers with machines here Nov 11 10:50:52 well, a layer providing support for a machine shouldn't be touching DISTRO_FEATURES Nov 11 10:51:18 DISTRO_FEATURES is something that's intended to be set from a conf/distro/distroname.conf inside a distro layer Nov 11 10:51:25 (if you're doing things properly) Nov 11 10:51:53 this allows you to easily swap out the machine support should you need to in future and keep the rest of your configuration Nov 11 10:53:03 well I want to build for the same machine target but change a few distro features, I guess make two distros for the same machine Nov 11 10:53:53 distro features are being set from platform/foo/local.conf at the moment Nov 11 10:54:01 which maybe wrong then? Nov 11 10:54:54 there should be just one local.conf under your build directory... you might very well have a template in your distro layer Nov 11 10:56:39 local.conf is intended to just select the machine, distro and set local paths; most of the time if you want to set anything more than that it should go into the distro configuration (or if it's specific to providing support for the machine itself, and not about how you're using that machine, then the machine configuration file) Nov 11 10:57:19 so even if I fixed this I'd still have to edit the local.conf in order to select the other distro Nov 11 10:57:52 so I'd still need a hack that swapped out local.conf files depending on what distro I wanted to build Nov 11 11:01:03 which is kind of a bummer, really Nov 11 11:01:22 if I want to build one image version with wayland and another with x11 I can't do that without adding a hack editing my local conf Nov 11 11:01:25 'yay' Nov 11 11:01:43 or did I miss anything? Nov 11 11:06:12 xerent: sure you can, i do that all the time. bitbake core-image-sato core-image-weston builds an x11-based image and a wayland image in the same bitbake run. Nov 11 11:06:38 your just need to have both x11 and wayland in distro_features Nov 11 11:06:53 the issue is that I can't have both Nov 11 11:06:56 why not? Nov 11 11:07:01 because of conflicts in my BSP, and also because of space concerns Nov 11 11:07:11 adding x11 as a distro features expands the image by 100 MB Nov 11 11:07:12 space isn't a concern, distro features != what goes into the image Nov 11 11:07:29 funny how the image grows with the distro_features flag ONLY changing then ;) Nov 11 11:07:33 if your wayland image grows by 100m when you turn on x11, you've got stuff in your image which you should remove Nov 11 11:07:57 so.. remove it. Nov 11 11:08:04 ok, so it's just the freescale BSP incompatibility issues then Nov 11 11:08:19 have a go at freescale then Nov 11 11:08:44 i will, and I will probably fail at that Nov 11 11:08:47 otavio: meta-freescale can't handle both x11 and wayland distro features at the same time? Nov 11 11:09:04 meta-fsl-arm Nov 11 11:09:16 for iMX6 target Nov 11 11:12:04 is there a way to set variables matching on a prefix? for instance VARIALBE_pn-bla* = "xxx" would match all pn's starting with bla Nov 11 11:12:14 no Nov 11 11:12:31 well, you could do that from an anonymous python block Nov 11 11:14:44 i'm trying to reduce repetition in some of these rules https://gist.github.com/lessandro/950e394c1a3ba2ff19a4 Nov 11 11:18:00 rburton: why aren't all distro features always enabled? Nov 11 11:18:15 I mean, it doesn't affect image size or anything ;) Nov 11 11:18:33 because it can Nov 11 11:18:59 noted Nov 11 11:19:33 I will implement a hack as workaround for building two images with different distro features without affecting image size then Nov 11 11:19:37 thanks for your help! Nov 11 11:36:15 rburton: it cannot Nov 11 11:36:20 rburton: well, it will for 2.1 Nov 11 11:36:29 rburton: as we will be moving for xwayland Nov 11 11:39:55 otavio: what's the problem with enabling wayland and x11 in the same distro? Nov 11 11:40:56 otavio: poky builds images on the ab with x11 and wayland distro features enabled Nov 11 11:45:13 rburton: the Vivante GPU has support for one or another Nov 11 11:45:51 and you can't build both and have the packages be mutually exclusive? Nov 11 11:47:08 rburton: no; they install the gpu libraries for one or another Nov 11 11:47:22 laaaaame Nov 11 11:47:34 (two recipes?) Nov 11 11:47:42 rburton: what do you mean both and be mutually exclusive? Nov 11 11:48:33 driver recipe creates two driver packages, vivante-x11 and vivante-wayland, which conflict with each other as they contain the same files (but with different behaviour) Nov 11 11:48:50 just surprised that the driver makes you pick Nov 11 11:50:07 rburton: no; their code is build different as well Nov 11 11:50:16 rburton: the headers need different defines Nov 11 11:50:30 rburton: it is a disaster ;P Nov 11 11:51:08 otavio: yeah so build it twice Nov 11 11:51:19 closed gpu driver in being terrible shock!! Nov 11 11:51:21 rburton: no; let's say cairo Nov 11 11:51:35 rburton: it needs different defines for the build Nov 11 11:51:56 oh jesus Nov 11 11:52:02 rburton: yes; I know Nov 11 12:00:59 I spent some time trying to untangle it recently Nov 11 12:01:09 it drove me to drink ;-) Nov 11 12:01:46 * rburton is glad to be gone of EMGD Nov 11 12:02:23 I was checking mesa with fbdev EGL; JaMa was kind to point me to the discussion showing it has been removed. Nov 11 12:02:33 The question is: is there a replacement/ Nov 11 12:02:36 * nrossi is glad the chips he deals with don't even have framebuffers :) Nov 11 12:19:45 does anyone know if there is a simple command line that allows to send an email using gmail? Nov 11 12:26:40 drou|: I use ssmtp Nov 11 12:27:29 otavio: thanks, i'll take a look at it Nov 11 12:32:52 otavio: is there any existing recipe for this? Nov 11 12:37:01 I thought you were refering to the host Nov 11 12:37:03 dunno Nov 11 12:46:43 hi, i am using systemd/journal on a meta-raspberrypi based yocto image. Nov 11 12:46:50 i've enabled systemd support via Nov 11 12:46:53 DISTRO_FEATURES_append = " systemd" Nov 11 12:47:01 VIRTUAL-RUNTIME_init_manager = "systemd" Nov 11 12:47:11 DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" Nov 11 12:47:17 the resulting image works fine Nov 11 12:47:35 but i noticed that there are still klogd/syslogd running on the resulting system Nov 11 12:47:48 both started as a systemd unit Nov 11 12:47:55 i wonder if there is a good reason for that Nov 11 12:48:23 shouldn't journald be sufficientß Nov 11 12:48:24 ? Nov 11 12:54:27 fmeerkoetter: To enable systemd, I think you also need to add this line VIRTUAL-RUNTIME_initscripts = "" Nov 11 12:54:56 t0mmy: it is enabled Nov 11 12:55:25 i am only wondering why klogd/syslogd are still running on the resulting image Nov 11 12:57:36 fmeerkoetter: Otherwise maybe, It is possible that klogd/syslogd are added by a recipe dependency, check recipes you used. Nov 11 13:22:30 otavio: thanks for the info on the vivante driver :) I can manage with a workaround enabling distro features for one OR the other (x11 vs wayland) Nov 11 16:22:13 hi all Nov 11 16:23:15 I'm trying to compile external kernel module but need to pass some defines to module. I do it manually in Makefile by adding: ccflags-y :=, is there way in yocto to specify something like that (EXTRA_OEMAKE maybe?) Nov 11 16:37:30 khem: around? Nov 11 16:38:41 Hi, I have a question regarding linux kernel mainline recipes. Is this the correct channel? Nov 11 16:40:57 marek_: EXTRA_OEMAKE += "ccflags-y='value'" should work Nov 11 16:41:40 adtec_: possibly - ask your question and we'll try our best to answer Nov 11 16:43:57 bluelightning: many thanks it works Nov 11 16:44:19 marek_: np Nov 11 16:44:34 bluelighting: Thanks, it should be fairly straight forward. I need to rev my kernel to mainline linux version 4.1.13, but so far I have been unable to figure out the correct source path Nov 11 16:46:36 I am able to check out the 4.3 branch using "SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${SRCBRANCH}", where SRCBRANCH = "master" and SRCREV = "${AUTOREV}". Nov 11 16:47:05 But how can I fetch a different kernel version based on a commit number? Nov 11 16:47:52 adtec_: IIRC the stable kernels are at git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git Nov 11 16:48:56 adtec_: there are branches for the mainained versions, e.g. linux-4.1.y Nov 11 16:49:24 sno: Would I use "linux-4.1.y" as SRCBRANCH? Nov 11 16:49:41 adtec_: likely ;) Nov 11 16:49:59 don't nail me on that, but that would my first start Nov 11 16:50:37 sno: Thanks, I'll give it a try Nov 11 16:52:36 bluelightning: hmm sorry I was too fast it's not working :( Nov 11 16:53:10 I added #ifdef to code and also #warning but define is not defined Nov 11 16:55:46 marek_: bluelightning gives you the way how to pass values to make, when you need to pass from make to c-source, something like EXTRA_OEMAKE += "-DDEFKEY=VALUE" Nov 11 16:56:19 sno: but this is special makefile becaus eit's building external kernel module Nov 11 16:57:02 marek_: meta-fsl-arm has a special patch for galcore's module makefile and I have adopted the makefile for 8189es module, too Nov 11 16:57:32 unless we have access to your source, we don't know anything about the makefile can deal with Nov 11 16:58:15 sno: which recipe exactly in meta-fsl-arm? Nov 11 16:58:48 recipes-kernel/kernel-modules/kernel-module-imx-gpu-viv_5.0.11.p7.1+fslc.bb Nov 11 17:02:21 sno: OK, I'll look on that thanks Nov 11 17:03:42 is there a way to pick the kernel per image? E.g. creating default image, build full featured kernel - and for recovery image, build downsized one? Nov 11 17:04:24 I tried to override PREFERRED_PROVIDER_virtual/kernel in recover-image.bb - but still using the full featured one Nov 11 17:07:03 preferences are global Nov 11 17:08:31 Hi, could someone point me in the right direction to add wolf-ssl to my poky image? Nov 11 17:09:47 I found the meta-wolfssl layer, but I'm not having any luck adding it into my build Nov 11 17:10:12 sno: Thanks, that seemed to have done it. Nov 11 17:11:59 hello, I have a question, how do you fix pidgin's --SSL handshake failed-- when connecting to the lync service? Nov 11 17:12:33 is it via re-running userraws.py? Nov 11 17:12:42 kergoth: so I have to modify the machine setting for such a change? Nov 11 17:15:57 benjamirc: wrong channel I think... Nov 11 17:16:09 sno: you can't change what gets built on a per image basis, it just wouldn't make sense. the same package feed is used for all images, and what would happen if you 'bitbake image1 image2 image3'? not doable. deciding what recipes get built is a global configuration change, so distro/machine/etc Nov 11 17:19:44 In case anyone is interested the patch I just posted is worth a speed double for "bitbake -p" and a hot cache Nov 11 17:20:13 wow, nice Nov 11 17:20:54 kergoth: loading the codeparser cache three times in succession was just stupid... Nov 11 17:21:00 heh, indeed Nov 11 17:21:12 didn't realize it got initialized multiple times in a single build Nov 11 17:21:23 JaMa: your buildname patch doesn't apply to master Nov 11 17:21:25 kergoth: its as the config gets built by the UI :/ Nov 11 17:21:32 ah Nov 11 17:21:44 kergoth: turns features to the right settings and so on, annoying but kind of understandable Nov 11 17:22:13 JaMa: oh you sent a variation which does apply Nov 11 17:22:50 kergoth: I'm still not convinced its right but codeparser reloading is clearly wrong and killing performance so its the low hanging fruit Nov 11 17:23:20 (theory was that a core config reset was cheap I guess) Nov 11 17:30:04 kergoth: doable or not might lead us into a philosophic discussíon - for today it's enought that is not supported Nov 11 17:40:16 sno: yes Nov 11 17:41:28 RP: I use bitbake -p often and I tried it Nov 11 17:41:32 seems to be good Nov 11 17:52:30 RP: Does this patch work on top of 2.0? URL? Nov 11 17:58:21 khem: I thought the ldap/samba/lfs discussion could be faster here Nov 11 17:59:24 ulf`: yes if you apply it to bitbake; http://patchwork.openembedded.org/patch/107335/ Nov 11 18:02:08 someone building gtk+3 with wayland enabled? here it fails to find wayland-scanner | configure: error: Could not find wayland-scanner in your PATH Nov 11 18:03:25 whats the best way to share files between recipes? I'm trying to get the gutenprint recipe working again and it involves copying some natively compiled files from gutenprint-native Nov 11 18:04:03 var_x: stage them in sysroot Nov 11 18:05:00 JaMa: Thanks - Learning this as I go Nov 11 18:05:05 var_x: ensure the files go somewhere in the sysroot basically - but note that does not mean you should explicitly install them there - install them as normal in do_install into an appropriate path under ${D}, and then they'll be staged from there Nov 11 18:05:53 var_x: if the path you're installing under isn't staged (not all are by default) then you can extend that, but that needs to be done properly Nov 11 18:06:42 see the last lines of this recipe for an example: http://cgit.openembedded.org/cgit.cgi/openembedded-core/tree/meta/recipes-graphics/xorg-font/font-util_1.3.1.bb?h=master Nov 11 18:06:48 it's uncommon to need to do that though Nov 11 18:07:14 * bluelightning recently filed a bug about documenting this properly Nov 11 18:07:21 bluelightning: Thanks that helps ... do that mean that the native files I need copyed will be on the target sysroot though? I don't need the native files as the end result, gutenprint just needs them for the compiling ... it's not cross compiler friendly :/ Nov 11 18:07:51 var_x: no, you can refer to the native sysroot from a target recipe just fine Nov 11 18:08:01 aaah gotcha Nov 11 18:08:43 var_x: see the STAGING_.*_NATIVE variables defined in meta/conf/bitbake.conf Nov 11 18:09:43 difference in optimization between RDEPENDS and DEPENDS - can RDEPENDS be build parallel to requiring recipe (e.g. because RDEPENDS without DEPENDS guides to e.g. script sourcing, perl module using, ...), or does RDEPENDS results in the same strict order as DEPENDS? Nov 11 18:12:03 sno: RDEPENDS just means that it's going to be the packaging tasks of the recipe depending on those of the recipes producing the named packages, as opposed to DEPENDS where do_configure depends on do_populate_sysroot of the mentioned items Nov 11 18:13:48 bluelightning: thanks Nov 11 18:13:57 bluelightning: holy crap - so thats where everything is defined! That will help me so much. If I could kiss you through IRC i would. Nov 11 18:14:22 var_x: heh, well, I appreciate the sentiment :D Nov 11 18:14:42 var_x: you may also find bitbake -e | less (with / to search) useful Nov 11 18:15:16 that'll also pick up things defined elsewhere, since bitbake.conf doesn't define everything (and things defined there can be overridden later) Nov 11 18:16:19 bbl Nov 11 18:29:35 how can I find out which packages have packageX as a dependency aka. what pulled in a certain dependency? Nov 11 18:41:24 This is driving me crazy (all nighters and broken coffee machine doesn't help ;), I have a recipe that requires another recipe to fully build before bitbake processes it. What dependency do I make to hold off the build until the first finishes out? DEPENDS_${PN} = "blah" doesn't work, do I use RDEPENDS? Nov 11 18:45:01 define fully build Nov 11 18:45:04 what do you mean by fully build? Nov 11 18:45:06 rburton: :) Nov 11 18:46:55 kergoth: do_installs should have run to completion. Nov 11 18:47:51 there is a header file which needs to appear in the sysroots, the second recipe needs that to build its binary. Nov 11 18:47:53 that's what DEPENDS is for Nov 11 18:47:59 :/ Nov 11 18:48:01 yeah Nov 11 18:48:02 nearly every recipe sets it.. Nov 11 18:48:18 by default, for anything in DEPENDS, do_configure will depend on their do_populate_sysroot Nov 11 18:48:25 so we know their files from do_install are available in the sysroots Nov 11 18:48:25 DEPENDS / DEPENDS_${PN} in second recipe? Nov 11 18:48:30 no Nov 11 18:48:32 DEPENDS, period Nov 11 18:48:34 ok Nov 11 18:48:35 there is no DEPENDS_${PN} Nov 11 18:48:39 ah Nov 11 18:48:44 RDEPENDS is used for binary pcakages, and so is specific to the binary package name Nov 11 18:48:49 DEPENDS is build time, for the recipe, and so is now Nov 11 18:48:50 not Nov 11 18:50:38 kergoth: doh, working. Too much keyboard time and not enough sleep , thanks. Nov 11 18:50:43 np Nov 11 18:50:56 * T0mW needs less caffine Nov 11 20:25:48 hi Nov 11 20:29:01 i'm getting an error in the do_install step of my recipe, it tells i don't have the correct permissions to create a file: http://pastebin.com/CAdLMfqf Nov 11 20:29:30 you have to tell make to install the files into ${D} Nov 11 20:29:38 for autotools this is automatic, by setting DESTDIR Nov 11 20:29:53 for non-autotools make-based systems, not all of them support such a variable, in which case you'd have to patch it in Nov 11 20:29:57 here is my recipe: http://pastebin.com/Khuanu80 i tried to override the do_install step by adding install -d ${D}${sbindir} but it didnt help Nov 11 20:30:01 and set EXTRA_OEMAKE appropriately Nov 11 20:30:11 no, it's make install that's trying to write to the wrong path Nov 11 20:30:20 install -d isn't going to do anything Nov 11 20:30:43 that project uses autoconf, but not automake, so it doesn't comply with automake conventions like DESTDIR Nov 11 20:31:05 you'll have to patch its makefile to prepend $(DESTDIR) to the destination paths, and then pass it in with EXTRA_OEMAKE Nov 11 20:32:03 so basically in my EXTRA_OEMAKE i'll have += "DESTDIR= Nov 11 20:32:16 sorry, += "DESTDIR=${D}" Nov 11 20:39:21 actually in this case that part is already handled, since you're inheriting autotools-brokensep . i'd thought at first it was a custom make based setup before i looked at the recipe & source, but it's autoconf, so autotools.bbclass is already passing DESTDIR in do_install Nov 11 20:39:27 so you just need to patch the makefiel to obey it and you'll be set Nov 11 20:45:19 can anyone explain the meaning of ${prefix} ? Nov 11 20:45:50 i think it has a different semantic meaning than what CMAKE_INSTALL_PREFIX means Nov 11 20:46:09 but, cmake.bbclass sets CMAKE_INSTALL_PREFIX to ${prefix} anyway Nov 11 20:46:37 kergoth: alright thanks, i'll try to do that Nov 11 20:46:58 trip0: prefix is /usr in most systems. Nov 11 20:47:01 see bitbake.conf Nov 11 20:47:11 yep, looking at bitbake.conf now Nov 11 20:47:39 prefix is not the same as DESTDIR as in "make DESTDIR=/foo/bar install", right? Nov 11 20:48:17 correct. all our target path vars like prefix/bindir/etc are all *relative to* DESTDIR Nov 11 20:48:20 if prefix is set to /usr, and DESDIR is /foo/bar, a library will install in /foo/bar/usr/lib ... Nov 11 20:48:22 DESTDIR is an alternate / Nov 11 20:48:26 correct Nov 11 20:48:35 okay. there is a bug in cmake.bbclass then Nov 11 20:49:09 i think if it wasn't installing files to ${D} in its install, none of our cmake recipes would work at all Nov 11 20:49:19 maybe CMAKE_INSTALL_PREFIX should be set to ${base_prefix} ? Nov 11 20:50:17 kergoth, perhaps. this is what it baffles me. if CMAKE_INSTALL_PREFIX is set to /usr, a system config file would be installed to /usr/etc Nov 11 20:51:31 they are installing to ${D}, but cmake is appending $(prefix} to every file after that. Nov 11 20:51:53 so effectively ${D} becomes ${D}/${prefix} Nov 11 20:52:09 that does sound wrong Nov 11 20:52:57 what I'm seeing is that I'm telling cmake to install a systemd unit to /lib/systemd/, but cmake is prepending ${prefix} to that. so it always gets installed to /usr/lib/systemd Nov 11 20:53:04 which is wrong Nov 11 20:54:17 this particular recipe has a post install script that fixes it Nov 11 20:54:40 I'm guessing a lot of cmake recipies do as well Nov 11 20:55:10 so fixing cmake.bbclass will break a lot of cmake recipes :( Nov 11 20:55:15 sno: if only 3 months old... Nov 11 20:59:39 better to fix it properly in the class and adjust the recipes to remove their hacks, in that case, i'd think Nov 11 20:59:46 at least 2.0 is out now, so it could go to master Nov 11 21:04:10 kergoth, okay, i'll make the fix and submit to mailing list Nov 11 21:06:04 now is the perfect time for that - plenty of time for other layers to catch up Nov 11 21:06:23 * rburton wonders if we found a new cmake class maintainer Nov 11 21:07:21 * kergoth is currently working through mentor's queue of bits to submit Nov 11 21:07:23 trip0 ♥ cmake Nov 11 21:07:35 me too Nov 11 21:07:40  /quit Nov 11 21:07:55 yah, that's what I was saying trip0 - why not maintain the class? ;-) Nov 11 21:08:07 oh, heh. Nov 11 21:12:55 I'm puzzled by the use of the arm-poky-linux-gnueabi "triplet", with "poky" in the place of hardware vendor Nov 11 21:14:17 doesn't it already cause problems, with eg. SDL2 expecting "raspberrypi" as vendor for that platform ? Nov 11 21:14:58 kergoth, patch should go to openembedded-core mailing list? Nov 11 21:16:22 that's right trip0 Nov 11 21:17:21 thx, joseppc Nov 11 21:17:25 er joshuagl Nov 11 21:23:09 yann|work: buildsystems that make assumptions based on vendor are generally broken, or at the least worth beating into shape Nov 11 21:24:25 that's right trip0 Nov 11 21:24:41 bah, sorry - I appear to be repeating myself Nov 11 21:28:09 patch sent. let the breakage begin! Nov 11 21:41:41 kergoth: right, trying to convince the SDL guys ;) Nov 11 21:42:43 but OTOH, putting anything in the vendor field could be seen as broken as well, maybe encouraging some people to use it... Nov 11 21:42:46 vendor is an arbitrary string, depends on who built the toolchain you're using. it's not necessarily going to tell you anything about the target Nov 11 21:43:18 i can see why they might make assumptions based on it given knowledge of particular toolchains, but obviously that logic won't do squat for us, since we aren't htat toolchain Nov 11 21:43:23 as I read it, it is more for specifying a hardware vendor than a software one Nov 11 21:44:23 check the autoconf docs, it probably originated there, given thats where the --build/--host/--target notions come from Nov 11 21:44:24 * kergoth shrugs Nov 11 21:44:30 see e.g. build_vendor Nov 11 21:44:36 kergoth: in their case it's not even the toolchain, they hacked config.guess to return what they want Nov 11 21:45:30 well, naturally that won't be of much use to us, the whole notion of config.guess is to return a string about the build environment, not target, which breaks assumptions in the cross-compilation case Nov 11 21:46:23 regarding conditionals using the system type string, from the autoconf docs: Whenever you're tempted to use ‘$host’ it's worth considering whether some sort of probe would be better. New system types come along periodically or previously missing features are added. Well-written probes can adapt themselves to such things, but hard-coded lists of names can't. Nov 11 21:46:32 see 14.3 Using the System Type Nov 11 21:47:00 sounds like they're violating that recommendation, and its' biting us now, as you'd expect it to Nov 11 21:47:18 (you have to remember autoconf probes for such things as the length of a char.. and uint_8 :) Nov 11 21:47:48 true, but they're right about this, use info about what you need, not a hardcoded string from the system type Nov 11 21:47:55 agreed Nov 11 21:53:40 kergoth: the rpi is apparently often used for on-target compilation Nov 11 21:54:38 thx, you helped make my bugreport better ;) Nov 11 21:57:15 np Nov 11 22:10:21 is there a way to clean sysroot (and/or tmp/work) w/o cleaning images and packages in deploy? Nov 11 22:19:14 denix: you can use cleanall (sstate, srcs) or cleansstate over the recipe this causes to build again Nov 11 22:19:56 alimon1: not what I'm looking for Nov 11 22:20:26 denix: you can do a simply rm -r :D Nov 11 22:22:23 denix: angstrom host DEPLOY_DIR outside TMP_DIR thats something you can look at Nov 11 22:23:45 khem: per recipe, not completely Nov 11 22:24:16 and the trick is not angstrom specific - we used to do that back in classic days... Nov 11 22:24:45 bitbake -ccleanall Nov 11 22:24:50 doesnt that do that job ? Nov 11 22:25:05 khem: it also removes corresponding packages and images Nov 11 22:25:34 yes so what is your usecase ? Nov 11 22:25:44 sometimes you need to step back and redefine your problem Nov 11 22:25:46 khem: I just need to nuke sysroot for a specific recipe Nov 11 22:26:31 what is the end goal its achieving ? Nov 11 22:28:03 I'm just experimenting with something here, was just wondering if it was possible to preserve built artifacts for a recipe when cleaning it up Nov 11 22:28:28 afaik -c clean doesn't remove images, so don't really see the issue there Nov 11 22:28:42 khem`: -c cleanall != -c fetchall. cleanall still runs against one recipe, just also removes sources from DL_DIR Nov 11 22:28:48 inconsistency in our naming (one of many) Nov 11 22:29:14 you could create a task like fetchall which runs clean against the recipe and all its deps Nov 11 22:29:16 kergoth: I thought so too, but it seems to remove corresponding images in deploy and packages in ipks... :( Nov 11 22:29:17 would be just a few lines Nov 11 22:29:23 packages in ipks, of course Nov 11 22:29:31 but i thought DEPLOY_DIR_IMAGE was handled differently Nov 11 22:29:33 * kergoth shrugs Nov 11 22:29:59 ah Nov 11 22:30:05 denix: scripts/wipe-sysroot Nov 11 22:30:10 looks like it's probably just what you want Nov 11 22:32:11 With a SRC_URI=file Nov 11 22:32:20 Does bitbake know if that directory has been updated? Nov 11 22:32:21 kergoth: thanks! looking into it now Nov 11 22:32:38 Or does the recipe revision need to be updated? Nov 11 22:32:58 pumpernickel_: afaik it should be checksumming the input, recursively in the case of a directory, but i'm not certain Nov 11 22:33:06 that is, i know it handles files right, not sure about dirs offhand Nov 11 22:33:29 I could double-check, I was curious if there was any expectation of that though. Nov 11 22:33:40 kergoth: seems to be all of sysroot though... Nov 11 22:33:49 I've learned that I really won't understand bitbake without reading a bit of python. Nov 11 22:34:23 We're trying to do too many non-standard things with it. Nov 11 22:35:25 denix: wipe-sysroot in scripts will clean the sysroot and all relevant stamps Nov 11 22:36:08 kergoth: thanks Nov 11 22:36:26 rburton: I'm looking for cleaning a single recipe's sysroot. in other words, I want "bitbake recipe -c clean" to preserve packages and images - any quick ideas? Nov 11 22:37:25 rm_work? Nov 11 22:37:52 (presumably you meant the work directory, recipes don't have their own sysroot) Nov 11 22:38:04 rburton: as in bbclass? it removes tmp/work, not sysroot Nov 11 22:38:27 rburton: well, packages, not recipes :) but still Nov 11 22:38:32 not entirely sure i understand what you want to achieve then Nov 11 22:41:13 rburton: let's say I have 2 mutually exclusive packages that provide the same virtual/blah, I need to build them both (switching PREFERRED_PROVIDER and bitbake -cclean in between) and keep their ipk packages and images in deploy for binary feeds and such Nov 11 22:43:34 so, I'm fine cleaning corresponding sysroot, sstage, stamps, packagedata in between, as long as built artifacts are preserved... Nov 11 22:44:06 possible or am I crazy? Nov 11 22:45:16 kergoth: I understand that, the kind of clean denix might be needing could be done with -cclean or -ccleansstate iself Nov 11 22:45:44 khem: correct Nov 11 22:56:08 personally i'd just copy out the artifacts i need at the end of the build, wipe tmp between builds, and call it a day Nov 11 22:56:10 * kergoth shrugs Nov 11 23:06:15 denix: I think what you are needing is another kind of clean-withoout-deploydir Nov 11 23:06:30 not sure if thats a good idea Nov 11 23:06:36 khem: looks like it Nov 11 23:07:11 and whats the issue with ipk regneration ? Nov 11 23:07:31 it will be overwritten on rebuild anyway Nov 11 23:08:56 khem: why? Nov 11 23:10:58 if the content is same Nov 11 23:11:21 otherwise they are added Nov 11 23:15:02 khem: well, the content is mostly different - package1.ipk has file1.ext and package2.ipk has file2.ext, but both packages PROVIDE a common feature, selected with PREFERRED_PROVIDER Nov 11 23:17:35 denix: is this separable at DISTRO level ? Nov 11 23:17:45 I wonder if the issue is more fundamental usage Nov 11 23:18:34 what do you mean at DISTRO level? Nov 11 23:36:56 * akuster evil laugh to self Nov 11 23:51:58 * armpit wonders if e-pint is IoT ? **** ENDING LOGGING AT Thu Nov 12 02:59:58 2015