**** BEGIN LOGGING AT Tue May 09 03:00:02 2017 May 09 07:47:52 RP: what's the right place to discuss "Yocto Compatible 2.0" - the Yocto mailing list or OE Architecture? May 09 07:48:09 It is related to Yocto, but the implications are more on OE... May 09 07:59:23 Hi all ! Is it easy to upgrade a device by wifi which is under yocto ? Like changing the software to make it up to date . May 09 07:59:31 Thanks by advance ! May 09 08:00:55 Interesting, it seems adding meta- paths to bblayers.conf does nothing unless recipes from those new layers are actually used in IMAGE_INSTALL or IMAGE_INSTALL_append definitions. May 09 08:00:56 I was expecting to see new RPM packages in build/tmp/deploy/rpm after adding new layers. May 09 08:01:18 I think I got that wrong? May 09 08:01:44 msvb-lab: for a properly designed layer that should be true May 09 08:02:15 msvb-lab: what should change if no configuration from it is pulled in and no recipe is being used? May 09 08:03:07 LetoThe2nd: The reason I'm asking relates to the use case where I want a small image file in build/deploy/images but a lot of RPM packages that I can optionally install in the image at runtime. May 09 08:04:09 msvb-lab: thats all fine, but how ist that related to adding a layer? if you want rpm packages to be created, you have to tell bitbake to do so. either thtough some form of dependency, or explicitly. May 09 08:04:40 (for the purpose of this discussion, i'd call 'bitbake world' explicit too) May 09 08:05:23 LetoThe2nd: So you confirm that by only adding meta- paths to bblayers.conf nothing new is built, and that if I want the extra packages I need to explicitly specify this to bitbake? May 09 08:06:28 LetoThe2nd: I know how to do that by adding package names to IMAGE_INSTALL or IMAGE_INSTALL_append, but is there another way to 'explicitly specify' this without increasing the resulting image size? May 09 08:06:49 msvb-lab: no, i said that for a properly designed layer, that if no recipe is used AND no configuration is pulled in, there should be no things built additionally. thats a huge difference. May 09 08:08:14 LetoThe2nd: So when I add a path to bblayers.conf, I'm not implicitly using new recipes (understood.) What do you mean by 'no configuration pulled in' though? May 09 08:08:26 LetoThe2nd: Is there a IMAGE_NOINSTALL_append or something similar that you're referring to? May 09 08:08:56 IMAGE_INSTALL_append = newrecipe May 09 08:09:13 ...clearly causes newrecipe in the new layer to be built. May 09 08:09:28 But it increases the image size as well, which I'm trying to avoid. May 09 08:09:39 msvb-lab: no, i'm referring to a .conf file being used. it should not be, but AFAIK nothing keeps layer.conf from doing dubios stuff, for example. May 09 08:10:39 msvb-lab: sounds like you either need to specify everything explicitly, or create some kind of meta target that depends and therefore triggers your image AND the packages to be built. May 09 08:11:50 ChrysD: there is no such thing built in, but a variety of options available. read up on meta-swupdate and/or mender.io, for example. May 09 08:12:12 msvb-lab: or just do bitbake world ;-) May 09 08:12:31 LetoThe2nd : Thanks May 09 08:13:30 LetoThe2nd: Right now I'm running bitbake which builds only the packages that these images-n depend on. May 09 08:13:51 LetoThe2nd: So your approach makes sense. May 09 08:14:12 msvb-lab: the explicit option would be running bitbake $image $package1 $package2 $package3 May 09 08:14:38 msvb-lab: but i'm not entirely sure that depending on a image works. you'd have to try. May 09 08:15:07 LetoThe2nd: I see, that's no good since I don't want to sift through the bb files to look for all the dozens of new recipes and write them on the command line. May 09 08:15:25 LetoThe2nd: But I may try building world and see if the results are too much. May 09 08:15:40 If I run bitbake world, then all the RPM packages will be built, but no images generated (I guess?) May 09 08:16:30 And following that I can run my old bitbake command to get the slim images. May 09 08:16:59 Best of both worlds it seems? Small images yet a ton of RPM packages available for post installation runtime integration. May 09 08:17:47 msvb-lab: what you're describing is that you're creating a distribution. May 09 08:18:07 msvb-lab: you can also look at what angstrom does, for example. its exactly their thing. May 09 08:18:24 LetoThe2nd: Yes, in fact. You can probably tell that I don't create many distributions. May 09 08:19:23 Seems quite okay how bitbake decides what to build according to layers, recipes, and dependencies. May 09 08:19:40 msvb-lab: kinda. i'd just suggest to look at what others are doing, probably their tooling can spare you reinventing everything. or maybe their solution already fits for you anyways. (plus, wind river certainly should have some experience there too, as you seem to be a customer( May 09 08:21:34 LetoThe2nd: I might look at Angstrom, thanks. Examining Wind River's github repository has limited value since the required information (about building world or custom package feeds for example) is not available. May 09 08:21:38 morning May 09 08:21:46 RP: hello May 09 08:21:57 pohly: I'd say the arch list but its s tricky one May 09 08:22:35 LetoThe2nd: Are there other pseudotargets like 'world' or a specific list that bitbake understands? May 09 08:22:51 ...nevermind, this is probably in the manual (which I'm checking out.) May 09 08:23:06 RP: I'll send you my email draft and let you decide where I should post it. May 09 08:24:13 pohly: ok, thanks. As you say, it has implications OE wide so I suspect arch will get the right set of people but I'll take a look May 09 08:25:09 Whoops, nothing in the 3465 line bitbake manual explaining 'world' builds. I guess this is in another manual? May 09 08:26:39 msvb-lab: world is a special target, there are only two bitbake understands that I can think of, world and universe May 09 08:27:51 RP: Thanks, I'll look for information on either of these. May 09 08:28:10 pohly: oe-arch is fine May 09 08:28:15 The 'Yocto Project Mega-Manual' weighs 24650 lines, and has not even one occurance of 'universe.' May 09 08:28:44 pohly: I also have a better way to write that file (I think) May 09 08:29:17 RP: let me send the email and you can improve it in your response. May 09 08:33:22 And the difference between 'world' and 'universe'? Obviously 'world' respects EXCLUDE_FROM_WORLD but I assume universe has it's own set of keyworlds? May 09 08:33:50 Typo, 'keywords'. May 09 08:42:20 pohly: replied... May 09 08:42:39 msvb-lab: universe ignores the exclude from world list, that is the main difference May 09 09:19:18 I wonder if bitbake world on a distro like Wind River produces terabytes of object files? May 09 09:19:19 Just building its images (and their dependencies) fills build/tmp to about 100GB. May 09 09:20:11 it certainly sums up. May 09 09:20:48 LetoThe2nd: Not to mention the time duration increase when building world. May 09 09:21:12 msvb-lab: well if you build more, you need more time. May 09 09:21:23 Maybe I should ask the friendly Wind River people to run a world build for me and compare the storage and time difference. May 09 09:22:23 I wish I still had access to a full rack build farm. May 09 09:22:30 msvb-lab: i fail to see your point. earlier you said you basically want to create a distribution, and now you wonder that acutally doing that might need computing time and storage. May 09 09:24:11 LetoThe2nd: I've built the distro already, using the method specified by Wind River. That costs 100BG and 15 hours. May 09 09:24:12 But changing to your idea of building world is what I want to do next, which might require a lot more (10x?) time and storage. May 09 09:25:07 The point is, it's senseless to start an expensive build if it's doomed to fail due to lack of resources. May 09 09:25:11 msvb-lab: hey it is not my idea to build all kinds of funny packages in advance to just have them ready for runtime install if you ever might need them. May 09 09:25:26 in fact, i strongly discourage non-monolithic builds. May 09 09:25:50 i just told you a way to do what you asked for :) May 09 09:26:42 LetoThe2nd: The priority lies in making this distro according to Wind River specs. Second priority is including small customizations (and this is finished.) May 09 09:27:23 But in order to avoid a full bitbake rebuild every time I see the need for a new package, I'd like to get it over with only once (by building world.) May 09 09:27:54 why would one need a "full bitbake rebuild" whenever one need a new package? May 09 09:28:16 You probably think I can leave the tmp dir there and just build a new package every once in a while when needed. That's not true, because I need to erase tmp in my limited system. May 09 09:28:26 it just builds whatever this package needs, given the assumption that the distribution is able to run it. May 09 09:29:02 If I need 'haskell' in 2 months, I won't have the tmp dir any more and will need to bitbake haskell (and all its dependencies.) May 09 09:29:29 But that's not a full build. If I make a monolithic build including haskell, it's a 15 hour loss. May 09 09:29:43 so there's a project that uses SVN externals without specifying their precise revisions (i.e. always pointing to the neweset revision). May 09 09:29:54 i feel like the bad guy, but it sounds like you want *everything*, without spending the resources needed to archieve it. May 09 09:30:23 How can I tell bitbake to stfu and *not* use the cache (neither svn/ nor .tar) and force it to execute 'svn up'? May 09 09:30:28 I want everything built once, and then store the results. May 09 09:30:38 e.g. "i want a full custom distro repository including all possible packages, but am not willing to spend the computing time and storage to actually do it" May 09 09:31:06 LetoThe2nd: I'm willing to spend the resources to build it but not if I need to buy a new computer. May 09 09:31:17 ...so yes there are conditions. May 09 09:31:56 of course, if you have a c2d with 2gb ram and a 250gb harddrive, you can't do bitbake world. but then there's no point to the discussion anyways. May 09 09:31:57 Unfortunately, my best guesses at how big the resource difference between bitbake and bitbake world, is based on very limited yocto experience. May 09 09:34:04 LetoThe2nd: I think my system can't build world, but your other idea of building a list of explicit packages is not bad if I can get a script to scrape out the recipes. May 09 09:36:03 LetoThe2nd: Have you built a lot of distros, or do you use yocto for other reasons? May 09 09:36:34 msvb-lab: i don't use yocto :-P May 09 09:37:07 msvb-lab: i do use OE and bits from the poky reference distribution however. but what would i do with it if not build custom distributions? May 09 09:37:32 (read that as: i fail to see the point of the question) May 09 09:38:36 LetoThe2nd: I'm assuming yocto is useful in broader make(1) or cmake(1) type situations. Like building a single LXC container is not really a distro. May 09 09:39:18 The point of the question is to satisfy curiosity and confirm that yocto is useful for other purposes rather than building distros. May 09 09:39:50 msvb-lab: i guess you are referring bitbake, not yocto. and no, bitbake is not an alternative to make or cmake. plus, building a container is actually building a custom distribution, albeit with a fixed kernel ABI. May 09 09:40:19 and yes, i have actually done that, and more, i'm certainly not the only one. May 09 09:42:34 Isn't bitbake one component under the yocto umbrella? Should I rather say 'use bitbake for ... reasons'? May 09 09:45:49 msvb-lab: well at least i personally prefer a concise wording. because most people say "i use yocto" when they actually mean "i use poky". some mean "i use OE", and some others mean "i use bitbake" May 09 09:46:17 ...and others mean 'I use toaster'? May 09 09:46:24 exactly. May 09 09:46:31 That's pretty wobbly. May 09 09:46:38 I'm trying to use the correct terms. May 09 09:47:01 thats why i never say "i use yocto", except in quotation marks for discussion purposes. May 09 09:47:12 :-) May 09 10:20:08 I know it's really far-fetched, but this discussion reminds me of the question: "Which one is better, AC or DC?" (as in alternating- vs. direct-current) May 09 10:34:58 What's the purpose of using Quilt/git am ? Isn't it better to have a .bbappend with a .patch file ? Thanks =) May 09 10:46:43 I've got in a file 'meta-openembedded/meta-intel-iot-middleware/recipes-connectivity/mosquitto/mosquitto_1.4.10.bb': May 09 10:46:48 PACKAGES += "libmosquitto1 libmosquittopp1 ${PN}-clients ${PN}-python May 09 10:47:05 ...and I'm succesfully building: $ bitbake mosquitto-clients May 09 10:47:17 But if I run $ bitbake mosquitto-python May 09 10:47:36 I get: ERROR: Nothing PROVIDES 'mosquitto-python'. May 09 10:48:07 Bizarre. Doesn't $PN resolve to 'package name' or 'mosquitto' in this case? May 09 10:48:24 And doesn't $PACKAGES refer to what a recipe provides for use on the bitbake(1) command line? May 09 10:49:39 The laer in question is https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/ May 09 10:58:10 PN does resolve to the package name by default May 09 11:03:34 So the line in a .bb file: PACKAGES += ${PN}-python expands to: PACKAGES += mosquitto-python May 09 11:04:03 ...and should not produce an error when building $ bitbake mosquitto-python May 09 11:04:41 I've looked around for reasons but not found any. There's a second set of mosquitto recipes in my configuration but they are nearly identical. May 09 11:04:50 That's why I write 'bizarre.' May 09 11:20:30 PACKAGES is the generated output, you don't bitbake a package you bitbake a recipe and that might create one or more packages May 09 11:20:42 s/is/are May 09 11:21:43 oh, msvb-lab is gone May 09 12:09:45 CTpollard: Sorry in case I missed any replies after 'bizarre.' My connection dropped. May 09 12:14:11 msvb-lab: you bitbake recipes, not packages May 09 12:16:35 rburton: Okay, what is the indicator for the recipe name? Is it the filename minus version, like 'mosquitto_1.4.10.bb' would indicate a recipe 'mosquitto'? May 09 12:17:06 yes May 09 12:17:23 I'm confused about this, because $ bitbake mosquitto-clients really builds a RPM package called 'mosquitto-clients*.rpm', but there is no file called 'mosquitto-clients*.bb' May 09 12:18:44 then the recipe probaby has PROVIDES=mosquitto-clients to make that work May 09 12:21:45 rburton: That's why I write 'bizarre.' There is no other incidence of '-clients' in the mosquitto_1.4.10.bb file other than the line starting with 'PACKAGES'. I've also checked for an include <*.inc> and nothing found. The file in question has no 'PROVIDES' keyword at all. May 09 12:21:47 https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/tree/recipes-connectivity/mosquitto May 09 12:22:08 ...but yet bitbake mosquitto-clients succeeds. May 09 12:23:01 rburton: So are you sure that the 'PACKAGES += mosquitto-clients' doesn't get parsed by bitbake as providing a target? May 09 12:24:37 There's also: ^FILES_${PN}-clients = "${bindir}/mosquitto_pub May 09 12:24:57 ...which surely isn't interpreted as a recipe target though. May 09 12:26:21 Maybe PACKAGE definitions are implicitly considered valid bitbake targets only when they install files (see the FILES_${PN}-clients line.) May 09 12:27:00 Oops, the mosquitto-python PACKAGE definition also has a similar FILES_ line. May 09 12:29:14 I guess there might be some sort of 'DONT_BUILD_MOSQUITTO_PYTHON' set to 'yes' in some other file that bitbake parses, but if so it's a wild goose chase to find it. May 09 12:29:57 msvb-lab: without having your layers i can't help, but bitbake takes recipe names (or follows preferred providers to find an alternative) May 09 12:30:11 ie bitbake virtual/kernel will build linux-intel.bb for me May 09 12:31:26 rburton: Okay fair enough. It's a sorting out the dependencies and definitions task, rather than an error. May 09 12:31:38 rburton: I'll keep working on it, but thanks for the ideas. May 09 12:31:50 so what's the problem now? May 09 12:33:06 rburton: I want to build a mosquitto-python package but can't do it. May 09 12:33:10 That's the problem. May 09 12:34:51 At least I assume from the line 'PACKAGES += ... mosquitto-python' that I'm supposed to be able to build a package of that name using bitbake? May 09 12:34:52 My guess is that there's a missing provides or I'm failing to configure something (local.conf?) properly. May 09 12:36:14 Some packages allow for options, like 'build all perl modules' or 'dont build python modules' so one possibility is I'm not providing an option that gets implicitly parsed by bitbake. May 09 12:48:52 what recipe includes the PACKAGES += ... mosquitto-python line? May 09 12:48:54 bitbake that May 09 12:50:59 joshuagl: The PACKAGES line is in 'mosquitto_1.4.10.bb' found in https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/tree/recipes-connectivity/mosquitto May 09 12:51:21 msvb-lab: and if you bitbake mosquitto there isn't a mosquitto-python package? May 09 12:51:26 joshuagl: And yes, I've tried bitbake mosquitto. That produces a bunch of RPM packages, but not mosquitto-python. May 09 12:53:08 Instead, I get: find tmp/deploy/ -name '*osquitto*rpm' ... everything defined on the line 'PACKAGES' except for mosquitto-python. May 09 12:53:27 There are no errors when building, either. May 09 12:53:46 To be honest, it's not a showstopper so I guess it's safe to ignore this. May 09 12:53:52 Quite bizarre though. May 09 12:56:43 I'm replicating here and tmp/work/core2-64-poky-linux/mosquitto/1.4.10-r0/packages-split/mosquitto-python/ is empty May 09 12:56:49 we don't create empty packages May 09 12:57:51 joshuagl: I think I saw that, so you mean it's at the package level? May 09 12:58:13 in my case that's because my Python is python3 and the site-packages directory is /usr/lib/python3.5/site-packages May 09 12:58:58 the recipe is wrong, the location in FILES_${PN}-python doesn't exist May 09 12:59:05 at least for me May 09 12:59:11 with a system using python3 May 09 12:59:17 joshuagl: Hmm, so if a dependency to python2 fails, then the package is silently not built. May 09 12:59:28 Like a soft depenency I guess. May 09 12:59:56 There are probably other reasons that packages don't get build from spec, but are part of a bb 'PACKAGES' definition still. May 09 13:00:30 are you still using newer oe-core with older layers from wr-core? May 09 13:01:29 joshuagl: Unfortunately there is a small number (2) of Wind River layers that I swapped for newer ones. May 09 13:01:49 I was having the mosquitto-python problem when I had only swapped one layer out (meta-cloud-services.) May 09 13:02:07 hmm, OK. The reason I ask is that meta-intel-iot-middleware appears not to be updated for latest OE-Core May 09 13:03:07 Once this number gets past one or two, it would make sense to abandon and go with jwessel's all master Pulsar8 build, but an all master cutting edge build sounds much less stable to me. May 09 13:03:40 joshuagl: I agree, there are things in the meta-intel-iot-middleware layer (like xdk-daemon) which are woefully out of date and fail to build due to old dependencies. May 09 13:04:41 However, the mosquitto that they specify is relatively fresh. At least newer than the one from 'meta-gateway'. May 09 13:04:53 I think meta-gateway is a Wind River maintained layer? May 09 13:05:24 my experience is that all master would be more stable than a frankenstein that uses different versions of layers. Layers are often closely aligned to a release of oe-core, many layers will need work to function correctly with master/pyro May 09 13:08:30 joshuagl: I'm starting to believe that, the hard way. I really wanted to stick to the well tested Pulsar8 branch. May 09 13:08:58 If it weren't for rabbitmq (a single package) I could stay with the Pulsar8 branch. May 09 13:10:05 On the other hand, things are moving along quite well with the frankenstein as long as I ditch mosquitto-python. May 09 13:10:29 probably easier just to write your own rabbitmq for pulsar8 May 09 13:10:37 ...since its only a frankenstein junior with 2 of 33 layers upgraded. May 09 13:11:25 jushuagl: It's true that a single package (rabbitmq in this case) doesn't excuse layer swaps. May 09 13:11:52 ...but anyone who knows rabbitmq has spent hours with erlang libraries because it's a dependency monster. May 09 13:12:44 So it doesn't fit the typical answer to roll a new package or make a new recipe, I wanted to reuse. May 09 13:25:23 Is it the case that rabbitmq has some wild amount of dependencies? May 09 13:35:58 it's common have some problems with centOS ? May 09 13:37:04 jwessel: I can't remember exactly what cost the most time, but rabbitmq has a plugin structure, composes several protocols, and depends on erlang. May 09 13:37:04 Using ubuntu I was compiling the libimxvpuapi (meta-freescale) normally, using CentOS I have problem with QA Issues May 09 13:37:12 WARNING: QA Issue: libimxvpuapi: Files/directories were installed but not shipped /usr/lib64 May 09 13:37:25 I'm using yocto dizzy May 09 13:37:36 It's the last one (erlang) that I think takes a long time to build and often fails along the way. May 09 13:37:48 caiortp: dizzy is super old, just so you know. ask freescale about your problems though. May 09 13:38:16 jwessel: Even worse is IoTivity, but that's a neat meta-oic recipe that's well behaved and well maintained. May 09 13:38:19 (dizzy was released in october 2014) May 09 13:38:59 rburton, yes , we freeze our dev in this version. May 09 13:39:04 Using bitbake to build IoTivity is a very refreshing departure from typical scons/boost/evenmore buildconf. May 09 13:39:09 froze* May 09 13:39:41 but ok May 09 13:48:22 Hi! Any clue what can have happened here? https://pastebin.com/wN8VYV9y This comes from a fresh install of a eSDK (built with current master) where I run 'devtool modify '. The specific output is for openssh recipe, but I get the same for any recipe I tried. This is from a project of mine: haven't had the time to try with poky alone, but hopefully anyone here can shed me some light... May 09 14:06:18 Hi, i need to invert the move a my mouse on my yocto image. I mean, When I move to the right I need that the mouse move the the left etc.. like a mirror. Someone know wich file I have to modify ? May 09 14:06:52 hamdyaea: just the mouse and not the entire display? May 09 14:07:04 not the entire display May 09 14:07:15 it's because I am working a touchscreen usb screen May 09 14:07:21 and the calibration is wrong May 09 14:07:26 recalibrate it then May 09 14:07:31 that's the fix May 09 14:07:34 rburton, : I need to invert it May 09 14:07:50 rburton, : There is a calibration tool only for windows May 09 14:08:03 tscalibrate will happily invert it through calibration. May 09 14:08:11 if you're really lucky the standard X calibration stuff will just work May 09 14:08:19 ah, usb crap. May 09 14:08:23 hamdyaea: Wouldn't there be something in X11.conf or similar that allows for mirror and such? May 09 14:08:24 I am looking in /etc/X11/ May 09 14:08:27 run xinput-calibrator May 09 14:08:30 or weston.ini if you're using weston May 09 14:08:37 ok i look May 09 14:11:12 Is bitbake smart enough to rebuild a whole layer's recipes if I 'mv layer layer-old && mv /tmp/layer-new layer' and then rebuild with the same bitbake command line? May 09 14:11:37 Or do I need to invalidate object files and RPM packages by do_clean manually? May 09 14:12:11 msvb-lab: if it doesn't affect MACHINE and DISTRO, you hopefully should be fine. May 09 14:15:00 LetoThe2nd: I'm hoping, so thanks for the optimism. Seems to me that even if bitbake keeps caches that it would read the new bb filenames at least and notice some are different than the recipes that got cached. May 09 14:16:10 msvb-lab: technically i would call it a bug if you run into problems. but tracking down sstate related ones is often painful May 09 14:19:13 rburton, RP: what is the Python search path? A .bbclass in my $TOPDIR/classes is found, but the corresponding .py in $TOPDIR/lib is not. May 09 14:19:44 pohly: good question. There is magic in base.bbclass relating to that May 09 14:20:11 pohly: bbclass is easy to answer and comes from BBPATH May 09 14:20:13 This is for a selftest which needs to set up a build dir with an additional .bbclass that gets INHERITed via local.conf. May 09 14:20:32 pohly: BBPATH != python search path May 09 14:20:34 pohly: if you're replacing a .py in a python package, rather than adding new, you need to copy the __init__.py from the main package into the corresponding path, so python can find the module vai the namespace package May 09 14:37:53 is there a way to explicitly require a specific version? I.e. not a "preferred version" ? May 09 14:40:53 https://lists.yoctoproject.org/pipermail/yocto/2013-August/015429.html only covers later package install it seems. May 09 14:42:03 I'm confused about the requirement to target QEMU instead of the a real architecture like Intel 64 bit. May 09 14:42:50 If I build a image targeting INtel 64 bit, shouldn't I be able to run it on a Windows hosting a Qemu session May 09 14:43:14 Smitty__: thats orthogonal. architecture is not the target machine, but only a part of it. May 09 14:43:29 *partially orthogonal May 09 14:43:58 and especially in the qemu case, it is really orthogonal :-P May 09 14:44:22 I don't understand what you are trying to say. May 09 14:45:02 Smitty__: that targetting qemu does not imply an architecture. qemu could also be arm, mips, powerpc... May 09 14:45:51 OK, let me rephrase the question. May 09 14:46:16 What is the purpose of targetting a virtualized environment ? May 09 14:46:31 That seems to defeat the purpose of the virtualization May 09 14:47:04 The whole point is to target the intended environment, then run inside a virtualized system that reproduces that enviroment May 09 14:47:39 Is it not ? May 09 14:47:41 Smitty__ : How can you virtualize architecture ? May 09 14:47:41 Smitty__: nope. you are targetting a specific machine. which is just what qemu also does: it emulates specific machine types. May 09 14:48:26 Smitty__: you are generalizing the fact that in the specific x86 case, a lot of the machine itself is abstracted away by the bios and a lot of HW detection May 09 14:48:55 OK, so why would I specify MACHINE ?= "qemux86-64" instead of MACHINE ??= "intel-corei7-64" ? May 09 14:49:35 I don't understand why I would need to specify that I am going to run in a virtualized enviroment. May 09 14:49:43 Smitty__: in the case that you want a kernel that actually can boot on qemu using the supported peripherals. its true that for x86, there probably is not that much of a difference. May 09 14:50:08 there is, since using the same device drivers under virtualization is just not wise. May 09 14:50:13 virtio is much more efficient May 09 14:50:47 Smitty__: what if your qemu is set to a simpler instruction set, like c2d, or even i686 equivalents? May 09 14:50:52 zeddii_home: agreed. May 09 14:51:07 not to mention, why build modules and configs for all the different north/south bridges, etc. Any h/w targetted machine should have optimizations in place, which are not useful on qemu, etc. May 09 14:51:20 Smitty__: you really have to free your mind from the specific x86+vritualization case. May 09 14:51:49 So, should I expect to encounter problems if I try to run intel-corei7-64 under QEMU running on a Intel Windows host ? May 09 14:51:55 having tried to maintain and boot h/w BSPs on qemu, I am of the opposite opinion. what do you expect to get from the BSP in virtualization. nothing. So just go with something that is targetted to the env. May 09 14:52:06 because it’ll be looking for an e1000, as an example. May 09 14:52:13 and if you let qemu emulation that, it is horrid and slow. May 09 14:52:17 But, then I am not really testing anything sensible, am I ? May 09 14:52:21 s/emulation/emulate/ May 09 14:52:31 you aren’t testing the BSP sensibly under qemu either. May 09 14:52:40 Smitty__: in emulation, you do not test real hardware. surprise, surprise. May 09 14:52:59 in emulation, you can test algorithms. May 09 14:53:00 I'm testing the behaviour under an environment that doesn't even pretend to be the target environment May 09 14:53:47 Smitty__: well set up your emulation to be like your target environment. its jsut that qemu does not fully emulate all possible platforms and combinations. May 09 14:54:18 Light Bulb !!! May 09 14:54:34 so if you complain about qemu not looking like your target environment, its up to you to change its looks. May 09 14:55:17 For me qemu do the job for testing kernel stability and rootfs, not less not more. I don't imagine how it is possible by software from computer to emulate an entire architecture with hardware emulation. Maybe I'm wrong. May 09 14:55:52 you need something with a different purpose than qemu, that is for sure. like simics, etc. May 09 14:56:49 OK, I guess it's a question of what I am actually testing then. I guess it's obvious that I can't expect to test any weird device drivers that aren't supported by QEMU, but, ........pondering the point of my current project May 09 14:56:52 exactly. thats why i keep repeating it: free your mind from the x86-specific virtualization case. qemu emulates a very specific *MACHINE*, not an *ARCHITECTURE* May 09 14:57:19 Why would you want a software that emulate the netire software instead of directly testing it to the board ? May 09 14:57:35 Good point - I'll ask my Project Manager that one May 09 14:57:38 pre-production boards, expensive boards, etc. May 09 14:57:46 ChrysD: oh theres a lot of such cases. hw being expenise, not available already, etc. May 09 14:57:54 *expensive. May 09 14:58:08 LetoThe2nd : Yeah but you can't expect a virtualization to fit to the hardware of a board. May 09 14:58:15 for me, qemu is for testing arch-generic parts of the kernel, and userspace. and obviously for running in the cloud, i.e. OpenStack. May 09 14:58:23 With simics you can. May 09 14:58:25 not qemu. May 09 14:58:36 and there are others, I’m just familiar with simics. May 09 14:58:49 “this is not a paid advertisement” :D May 09 14:58:49 ChrysD: *sigh* you can, given enough effort and the right emulation. it just doesn not apply for qemu in the most cases. May 09 14:59:17 if you need to test drivers, you probably want a proper simulator, but those aren't cheap May 09 14:59:19 * kergoth yawns May 09 14:59:33 emulation does also not necessarily mean software only. it could also be an fpga loaded with a specific core. May 09 14:59:56 * LetoThe2nd tries to throw little balls of paper into kergoths yawning May 09 15:00:04 eep May 09 15:00:20 LetoThe2nd : But it's strange to have full system simulator when it's very hard to have a good electronics circuit simulator... May 09 15:00:47 ChrysD: it always depends on your resources and problem to be solved. May 09 15:00:52 kergoth: :-D May 09 15:01:41 * kergoth has fond^Wterrible memories of dealing with simulation before we had actual hardware when working at TI May 09 15:01:44 :) May 09 15:02:32 kergoth: when it comes to stuff like that, i'm usually happy that i'm a long way down the food chain. but we're waiting for prototype board too etc. May 09 15:05:08 LetoThe2nd : I guess you need a powerfull computer to run on full system simulator May 09 15:05:32 ChrysD: it *depends* May 09 15:06:02 LetoThe2nd : Yeah it depends... if it is a headless device for example. May 09 15:07:09 LetoThe2nd : But I can't expect from my actual computer to simulate an entire system including the GPU board for generation of images ahah May 09 15:07:35 ChrysD: no, you're also thinking waaaaay to desktop like. you're assuming emulation speed being close to the speed of the target system. but who says that emulation cannot be precise and slow? May 09 15:07:37 LetoThe2nd : When the computer itself have difficulty to get 60fps for some rendering. May 09 15:08:17 LetoThe2nd : Yeah , as you say, *depends* of what you want to test. May 09 15:09:13 or on the other hand, who says that your target cannot be very small? like, an arm m0? May 09 15:09:27 LetoThe2nd : It *depends* May 09 15:09:37 LetoThe2nd : =D May 09 15:09:44 RP, rburton: are patches being accepted for 2.4 on master yet, or has it not yet diverged from pyro? If the latter, is there an estimated date? May 09 15:12:45 kergoth: very soon. i've been doing test builds so we'll be merging stuff this week. May 09 15:13:18 cool, thanks May 09 15:13:55 kergoth: right, its imminent. Just been putting it off a bit for a bit of a rest ;-) May 09 15:14:01 i don't blame you :) May 09 15:14:03 just checking status May 09 15:14:45 OK, So, when I grab a generic linux like Fedora Intel 64 bit - for example - and run it inside VMWare, it just works. But, If I create a Yocto Image targeting Intel 64, VMWare refuses to load it.. Why would that be May 09 15:15:10 Smitty__: "i create a yocto image." May 09 15:15:38 Smitty__: and certainly have booted poky-based iso images in vortualbox without hassles. May 09 15:15:44 *virtualbox May 09 15:15:45 Yeah, well, I just inheretied this project May 09 15:16:34 OK, I guess I have a lot of work to do May 09 15:17:08 Smitty__: i'm just trying to tell you that if you say "i created a yocto image", then nobody knows what you mean. guesses are that is poky based. but it does not mention image type and things like that, which are crucial for actually booting stuff. May 09 15:17:25 Smitty__ : You're not the only one. But from my understanding, when you put machine, you target to make it running to a specific machine. But the machine inself can run in other architecture. That's why QEMU. LetoThe2nd right ? May 09 15:22:44 huh? May 09 15:30:36 time to call it a day. cya May 09 15:42:28 LetoThe2nd: Thanks again, bye. May 09 16:00:59 In every bitbake build I do (for Wind River Pulsar8) I get this warning: May 09 16:01:03 NOTE: consider defining a PREFERRED_PROVIDER entry to match java2-runtime May 09 16:01:21 ...although my build-intel-x86/conf/local.conf has: May 09 16:01:25 PREFERRED_PROVIDER_java2-runtime = "openjdk-8" May 09 16:01:30 Wierd. May 09 16:02:06 It's the only PREFERRED_PROVIDER warning message I can't get rid of. May 09 16:36:22 It seems bitbake -c clean is an alias for do_clean? May 09 16:36:38 msvb-lab: -c is "run this task" May 09 16:36:43 so -c clean is "run do_clean" May 09 16:37:24 rburton: I'm trying to figure out if either of bitbake -c (clean|doclean) is the more correct syntax. May 09 16:37:51 After testing, it seems to me that either work? May 09 16:38:03 clean is preferrd May 09 16:38:06 I mean (clean|do_clean). May 09 16:38:09 bitbake will add do_ for you May 09 16:38:39 Okay, then I'll use 'clean' from now on (and the same with other commands, stripping 'do_' from them.) May 09 16:38:53 Thanks. Looks like I really need realclean instead though, hmm. May 09 16:39:00 what would that do May 09 16:40:05 Normally realclean erases not only object files but the targets too. Disclean goes yet a step further and removes automake things. May 09 16:40:54 Those meanings are valid for GNU autotools behaviour at least, not sure about bitbake. May 09 16:41:02 realclean isn't a automakeism May 09 16:41:13 anyway, clean removes the entire build tree May 09 16:41:57 but its only useful if the previous build was incomplete as bitbake will just pull the completed build from sstate if you bitbake it after a clean May 09 16:42:17 Oops, I meant 'cleanall' instead of 'realclean'. May 09 16:42:48 automake is clean (remove all build things), distclean (clean plus anything that is 'dist'), maintainerclean (distclean plus random stuff the maintainer said to clean) May 09 16:42:58 bitbake cleanall is overkill, it removes downloaded tarballs too May 09 16:43:05 so unless you enjoy downloading sources, don't use it May 09 16:43:11 The reason I think I need more than 'clean' is that after bitbake -c clean and bitbake it doesn't get rebuilt. Probably due to the sstate, thanks for the tip. May 09 16:43:16 yes May 09 16:43:20 bitbake foo -C unpack May 09 16:43:34 "build foo and mark unpack as needing to happen again" May 09 16:43:50 if unpack if forced to run then patch has to run, then configure, then compile ... May 09 16:44:04 rburton: Oh, nice. That's what I need in addition to clean then (-C unpack also) May 09 16:44:12 no need to clean too May 09 16:44:49 well actually there was a small bug for a bit, so you might be safer doing a clean first if you're not using something very recent May 09 16:46:09 I had already given -c clean. Cool, it's working. Thanks. May 09 16:47:57 what is yocto ? May 09 16:48:06 yoctoproject.orrg May 09 16:48:11 as mentioned in the subject of the channel May 09 16:48:32 thank you May 09 16:49:28 huh May 09 16:49:53 That was fast. May 09 17:03:55 well yocto is 10^24 in metric system May 09 17:04:13 khem: 10^-24 May 09 17:04:18 small difference May 09 17:04:20 ah yes May 09 17:04:40 planck is smallest mesaurable 10^-34 May 09 17:04:50 and I guess second smallest is yocto May 09 17:04:59 so we left some room for improvment there May 09 17:05:03 khem: planck project doesn't have the same ring :) May 09 17:05:24 ah there we go :) May 09 17:05:56 khem: even at 10^-34, its all about the uncertainty in the measurement :) May 09 17:06:26 exit off May 09 17:06:27 pretty much same problems like non-deterministic builds May 09 17:06:51 I guess Martin got annoyed :) May 09 17:06:53 khem: was just wondering about the connection :) May 09 17:09:18 RP: I mentioned about proposal to harden toolchain in 2.4 timeframe. Are you still interested May 09 17:09:55 khem: yes, definitely interested May 09 17:10:26 in this day and age I think PIC/PIE should be a good compromise for getting some secure code May 09 17:10:55 khem: does that have performance implications? May 09 17:11:59 PIC/PIE in general does have some May 09 17:12:29 but we are already using PIC so its not a big difference that PIE is going to bring May 09 17:12:35 khem: It does sound like doing this at the compiler level would be better than the current include file though May 09 17:12:44 right May 09 17:12:57 in the end we might make it a distro feature May 09 17:13:07 khem: that was what I was just wondering May 09 17:13:08 and decide if it should be default or not May 09 17:13:52 but I think it should become default otherwise it wont fly since there will be issues at hand to fix May 09 17:14:07 but debian has waded some winds already May 09 17:14:16 so there wont be all on us May 09 17:14:48 khem: If it replaces the .inc, we can at least use it for poky-lsb which is how we stop that regressing today May 09 17:15:08 I see, thats a good option May 09 17:15:23 or rename poky-lsb to poky-secure :) May 09 17:15:34 and you will have many users for it suddenly May 09 17:15:51 khem: with the changes to lsb, we need to rethink what that is doing but it can remain as a place to test this May 09 17:15:55 poky-hardened May 09 17:16:01 khem: Haven't fully figured out what it becomes yet May 09 17:16:51 yeah lsb is interesting dont know if it has lived upto its promise though May 09 19:00:45 hmm, both python-nose and python3-nose provide /usr/bin/nosetests, which breaks when both python versions are being installed on target May 09 19:01:32 should see how it's handled in debian. probably with 2/3 suffixes May 09 19:05:50 https://packages.debian.org/jessie/all/python3-nose/filelist - /usr/bin/nosetests3 May 09 19:47:00 yeah nosetests2 and nosetests3 May 09 19:47:24 would be the way to go where nosetests is a symlink to py2 version May 09 20:33:40 Hi all, I have a small problem with my small application and eclipse with the plugin installed. When I try and compile my program it seems like it fails with SDL May 09 20:34:36 I suspect that this is to do with linking as I can locate the headers, and the libSDL is in my ADT. is there something I am missing including the library? May 09 20:37:16 "undefined reference to `SDL_FillRect' display_class.cpp /cm-ipbx-fw/src line 341 C/C++ Problem" is the type of error I'm getting **** ENDING LOGGING AT Wed May 10 03:00:00 2017