**** BEGIN LOGGING AT Tue Jan 16 03:00:03 2018 Jan 16 08:58:36 hi everyone Jan 16 08:58:57 good morning Jan 16 09:00:36 I'm facing an issue with asterisk, they are using a bootstrap.sh to run aclocal autoconf ... and the configure fails because my recipe don't run the "bootstrap.sh" Jan 16 09:01:50 should I call the bootstrap.sh in a do_configure_append? or just override aclocal (how can I do that?) Jan 16 09:03:59 aurele: It may be a little early for the folks who could answer with authority Jan 16 09:04:42 xthunderheartx, I will try some things, and maybe come back later ;) Jan 16 09:05:20 At least US folks anyway. It will liven up in a few hours Jan 16 09:06:54 As an asterisk fan from *way back* I wish you luck ... you'll need it. Jan 16 09:07:32 Or awesome skillz ... those will do as well :) Jan 16 09:13:08 aurele: probably overriding the do_configure command does the trick. but better be absolutely sure that this magic script does not introduce any host dependencies. Jan 16 09:13:16 aurele: or prepending it. Jan 16 09:13:44 Hello everybody!! Jan 16 09:16:06 what is the purpose of sysroot ? Jan 16 09:16:18 Is it for kernel headers ? Jan 16 09:17:18 https://stackoverflow.com/questions/39920712/what-is-a-sysroot-exactly-and-how-do-i-create-one Jan 16 09:17:34 ranran: it has a couple of uses, the primary probably serving as sysroots for the compilers. this means the compilers use this as their root, instead of looking at the host. Jan 16 09:21:59 Is it that a package which depends on another one for the build, find the other package (header/library) in sysroot ? Jan 16 09:22:48 I mean, does the sysroot also used during build of packages to resolve dependency ? Jan 16 09:23:19 ranran: basically, yes. but what is it that you are *ACTUALLY* trying to do? Jan 16 09:24:07 How can I set the owner of the config files ? Jan 16 09:24:33 LetoThe2nd, I just try to have better understanding of sysroot. Is sysroot used for the build process or only for the sdk package ? Jan 16 09:24:52 ranran: it is especially used in the build process. Jan 16 09:25:20 cisasystems: meaning... what? Jan 16 09:25:33 ranran: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html Jan 16 09:26:36 Thank you. Jan 16 10:25:25 Good morning, Jan 16 10:25:33 I do have a question regarding devtool Jan 16 10:25:53 is it possible to have verbose output of devtool build ? Jan 16 10:26:07 something like bitbake -v Jan 16 10:26:44 I do find devtool as a good developer's tool, but I would like to see the detailed output of compilation - including errors and warnings Jan 16 11:03:50 lukma: maybe bitbake package -DDD ? Jan 16 11:17:43 hi, guys! Jan 16 11:42:45 hi again I have updated my layers and I have the folowing issue : https://pastebin.com/rBnFCYh8 Jan 16 11:43:16 "pseudo-native" doesn't compile for a strange reason... Jan 16 11:58:05 sorry for bothering everyone but a simple cleanall did the trick Jan 16 12:05:50 cleanall isn't simple, just clean would have worked Jan 16 12:14:26 rburton, I will try to remember for next time but sometimes clean is not enough and I try cleanall (and usually this doesn't fix the issue). So now I use cleanall directly Jan 16 12:25:12 aurele: cleanall will delete the working tree (same as clean), and all sstate objects (same as cleansstate), and all tarballs downloaded Jan 16 12:25:34 unless you want to remove objects from sstate, clean is sufficient Jan 16 13:26:18 anyone who uses cmake, i've just sent a RFC to the oe-core list Jan 16 13:53:58 ANyone know anything about any noteable changes in gobject / glib / dbus in rocko (vs pyro)? I just can't get my pygobject dbus listener script to work on rocko. I've spent many hours trying to debug it, and it boils down to something in so-land refusing to start Jan 16 13:54:46 (and gobject / glib is apparently not the easiest beast) Jan 16 13:55:35 sveinse: sounds like something we need to add to sanity testing... Jan 16 13:55:40 pastebin the error? Jan 16 13:55:41 rburton Jan 16 13:56:12 Geez ... connect fingers to brain Jan 16 13:56:59 rburton: So I have a working recipe for dbus-cxx and I be happy to submit it. Jan 16 13:57:55 One issue though, which you commented on yesterday is it looks like the upstream maintainer doesn't do much in the was of "maintaining" these days. Jan 16 13:59:03 The library version information seems to never change though the package version *has* been diligently updated. Jan 16 13:59:19 i'd just report a bug upstream to tell them to library version Jan 16 13:59:35 you can't do anything Jan 16 14:00:12 Yeah, I can do that. However the bug reporting mechanism is just a post to the list server and there have bee a total of 3 posting since 2014. Jan 16 14:00:29 Not sure it is getting much attention Jan 16 14:00:50 fork it! :) Jan 16 14:01:00 I thought about that ... Jan 16 14:02:12 I suspect that's because GLib users have dbusglib bindings for cxx and QT users have Qt bindings for cxx, I'd wager that not many people use/need dbus-cxx :-/ Jan 16 14:03:20 rburton, I will paste the error and what I've investigated. Hold on Jan 16 14:03:51 rburton: i added sanity.conf Jan 16 14:04:33 Well, I just need an IPC mechanism that supports signals and rpc for what we are doing and dbus-cxx seemed to fit the bill. Plus the examples worked and were easy to follow. Jan 16 14:05:28 indeed, dbus is good. its a shame dbus-cxx is unmaintained Jan 16 14:06:57 Well I've been taking from the Linux community for decades (literally). Maybe this would be an opportunity to give back. Lend a hand. Jan 16 14:09:20 a polite mail to the last known maintainer is nice, but i'd be throwing up a github clone and putting the out of tree build fix in there for a start Jan 16 14:09:27 then learn library versioning and do that Jan 16 14:10:42 dbus might be good, but alas I've been having my troubles with the event loops glib or gobject Jan 16 14:10:54 Yep, I figured I'd send an email to rvinyard. Go from there. Is there a defined process for submitting a recipe to OE? Jan 16 14:11:34 pick a layer (meta-oe sounds right), then submit a patch to the relevant list (openembedded-devel@lists.openembedded.org) Jan 16 14:11:50 I did smoke over library versioning lastnight and I think I have a grasp of the idea. Jan 16 14:13:15 Ross you are the Yocto dbus guy (maintainer) right? Jan 16 14:13:32 So you would likely review it? Jan 16 14:13:34 i certainly hope not Jan 16 14:14:01 i might glance at the odd patch for meta-oe but i don't review them all Jan 16 14:14:23 LOL! "Sato/GTK/Dbus - Ross Burton" ... not you? Jan 16 14:14:31 damnit where does it say that Jan 16 14:14:37 Come on now! Jan 16 14:14:44 RECIPE_MAINTAINER_pn-dbus = "Chen Qi " Jan 16 14:14:46 not me! :) Jan 16 14:15:05 Coffee just spewed out of my nose ... Jan 16 14:15:14 if thats from the web site then we know its out of date and there's a replacement on the way Jan 16 14:15:43 https://www.yoctoproject.org/about/governance/technical-leadership Jan 16 14:16:55 That's the top response to google "rburton yocto" Jan 16 14:17:09 Just assumed it was you. Jan 16 14:21:59 rburton: https://bpaste.net/show/be2b530702cc. Works on pyro, fails on rocko. Jan 16 14:23:01 I do have other differences in the manifests between these two versions, but nothing which stands out as being related to this. So it it is fully possible that the root cause is a missing dependency Jan 16 14:23:26 sveinse: presumably you're adding your own python-gobject? Jan 16 14:25:28 rburton: no. why? Jan 16 14:26:25 ah, there's a recipe in meta-oe still Jan 16 14:26:29 presumably you're using that then Jan 16 14:26:32 It's supposed to listen on dbus events from udisks Jan 16 14:26:39 sveinse: easy test: have you tried with py3? Jan 16 14:27:02 what with us doing everything we can to delete py2 from oe-core knowing if it works in py3 would be useful Jan 16 14:28:04 rburton: yes. it doesn't. It follows the same path as py2. But this time it doesnt mask the proper gi error, it reads: "ImportError: cannot import name GObject, introspection typelib not found" Jan 16 14:28:22 so... is the introspection typelib present? :) Jan 16 14:29:23 rburton: I honestly don't know what I'm looking for Jan 16 14:29:25 i guess gobject is a special one Jan 16 14:30:34 As the paste said, it fails because _gi.so lib returns [] on enumerate_versions() on rocko, while ['2.0'] on pyro. This is the same for py2 and py3 Jan 16 14:34:28 building stuff here now Jan 16 14:34:38 need to add a test case for this to ensure it doesn't regress Jan 16 14:35:13 I'm fine-reading the manifest-diff now Jan 16 14:36:12 most likely a proper bug and not a manifest issue Jan 16 14:40:50 meanwhile, I should perhaps see after other approaches for dbus access from python Jan 16 14:48:57 sveinse: >>> GObject.glib_version Jan 16 14:48:57 (2, 54, 2) Jan 16 14:48:59 works for me Jan 16 14:49:24 rburton: right. tested on what machine? Jan 16 14:49:34 x86-64 Jan 16 14:51:43 I need to get a qemu environment up so I can test too. I must read the docs how one does that Jan 16 14:52:09 set MACHINE=qemuwhatever when doing a build, then use runqemu Jan 16 14:53:45 New news from stackoverflow: How to package CMake Module in NativeSDK? Jan 16 15:06:58 i ran bitbake core-image-base -c fetchall but there are very few c and h files pulled in, also does not look like uboot was pulled in Jan 16 15:07:17 is there an image that would pull in uboot file? Jan 16 15:13:42 zarzar1: that image will, assuming you picked a machine which uses uboot Jan 16 15:14:36 rburton: hmmm, seems like very few source files were pulled in, not sure what the deal is Jan 16 15:14:48 where are you looking? Jan 16 15:15:00 rburton: https://pastebin.com/ZmP0z69B Jan 16 15:15:16 thats not where downloads go Jan 16 15:15:29 also downloads are tarballs, not unpacked Jan 16 15:15:43 oh ok Jan 16 15:15:45 look in whatever you've set DL_DIR to Jan 16 15:16:13 dang, i didn't set DL_DIR Jan 16 15:17:08 theres a default value Jan 16 15:19:54 ok Jan 16 15:22:25 rburton: so that's not good, tarballs of code, I mainly pulled code in order to use find and grep on the source files for uboot Jan 16 15:23:25 bitbake -c unpack u-boot ? Jan 16 15:23:55 Probably need some building to get there Jan 16 15:24:40 can i run unack on an image? like i did with fetchall Jan 16 15:25:14 building takes up too much disk space, trying to avoid a full build but just want to look at sources Jan 16 15:25:58 could i run a build then delete tmp folder without losing sources? Jan 16 15:26:50 not sure when bitbake populates the recipe's DEPENDS when building, so I'm not sure if do_unpack is run prior to this Jan 16 15:27:02 But are you using a shared sstate cache? Jan 16 15:28:55 no sahred sstate cache that i know of Jan 16 15:29:34 zarzar1: That will surely save you a ton and a half, both with respect to compile time and disk space Jan 16 15:31:17 Set SSTATE_DIR in local.conf to a location that can hold much data. This can be shared across MACHINES, DISTROs and Yocto versions. This way bitbake -c unpack u-boot will only take a few minutes to progress (given that all objects exists in the cache) Jan 16 15:40:29 devtool modify ? Jan 16 15:40:33 yeah that Jan 16 15:40:40 found that here: https://wiki.yoctoproject.org/wiki/TipsAndTricks/Patching_the_source_for_a_recipe Jan 16 15:40:45 you said you wanted all sources, so were told how to do that (fetchall) Jan 16 15:41:27 rburton: true, i did not know they would be tar ablled Jan 16 15:41:51 upstream sources are almost all either git repos or tarballs Jan 16 15:41:53 error: recipe is an image, and therefore is not supported by this tool Jan 16 15:41:56 dang Jan 16 15:42:05 yeah you can't modify images as they don't have sources Jan 16 15:42:10 you said uboot, so modify uboot Jan 16 15:42:27 oh ok Jan 16 15:42:54 that worked Jan 16 15:44:57 is it possible to find all recipes in an image? Jan 16 15:45:28 zarzar1: an image generates a manifest, that is the list of all packages installed in it Jan 16 15:45:57 what's the diff between package and recipe? Jan 16 15:46:02 is it possible to find all recipes in an image? Jan 16 15:46:05 a recipe generates packages Jan 16 15:46:26 for devtool modify i need recipes Jan 16 15:46:27 a recipe (say, glib) will generate many packages (libglib, libglib-dev, libglib-doc, libglib-locale-*, etc) Jan 16 15:46:42 i don't think i need packages for devtool modify Jan 16 15:46:48 correct, you tell it what recipe Jan 16 15:47:09 recipes make packages, images are collections of packages Jan 16 15:47:50 so can i get the recipes use by an image or no? Jan 16 15:49:04 bitbake imagename -g will write pn-buildlist, which lists all recipes it will be building to satisfy the requirements Jan 16 15:53:11 holy moly Jan 16 15:53:23 i'll just run a build and delete tmp after Jan 16 15:57:11 is there an email list for feature requests? Jan 16 16:07:00 Where can I check the list of packages upgraded on a new yocto version Jan 16 16:07:01 ? Jan 16 16:28:35 rburton: I found the issue. And it was mine. gobject-introspection-data was added to DISTRO_FEATURES_BACKFILL_CONSIDERED for some reason. Thank you very much for persuing the issue. Jan 16 16:39:05 Hmm, wonder why we don't pass —unity to meson by default, the docs say they recommend it for distro builds, since it's always from scratch rather than incremental Jan 16 16:54:19 sveinse: haha Jan 16 16:54:41 sveinse: yeah that would be it. want to send a patch to make python-pygobject abort in that case? Jan 16 16:55:19 kergoth: patches welcome! personally, never heard of that flag before Jan 16 17:46:39 http://mesonbuild.com/Unity-builds.html the potential crash issue probably makes it not worth enabling globally, though Jan 16 17:46:44 s/crash/clash/ Jan 16 17:48:39 Hello, Where can see the logs of functions which are run with a eventmask. example: do_app_setup[eventmask] = "bb.event.BuildStarted" Jan 16 17:48:56 where can I check what happened with do_app_setup ? Jan 16 17:49:55 do_app_setup[eventmask] is part of a bbclass and I have already looked at the logs of the recipe which inherits the bbclass. Jan 16 18:03:11 Let me rephrase the question: "Where can I check logs of even handlers?" Jan 16 18:03:21 *event handlers? Jan 16 18:04:29 event handlers most likely log to the bitbake console log only Jan 16 18:13:16 kergoth, rburton: Found this more informative: https://lists.yoctoproject.org/pipermail/yocto/2016-April/029579.html Jan 16 18:13:58 nice, that should probably go in the yocto docs somewhere if it isn't already Jan 16 18:14:48 Honestly I don't have a clue what introspection data is about. I see its mentioned in the dev manual (4.11), but the manual kind of gave the impression that its linked to qemu Jan 16 18:15:15 kergoth: Thanks for clarifying that. Jan 16 18:15:21 but that's clearly not the case. A little wiser today! Jan 16 18:15:38 afaik introspection is when it actually has to run the target binary to get info about the target binary, or something? Jan 16 18:15:44 possibly similar to help2man? Jan 16 18:15:48 no clue Jan 16 18:15:50 :) Jan 16 18:15:52 batman_: np Jan 16 18:15:58 batman_: so you should be able to find it in tmp/log/ Jan 16 18:16:15 might be worth improving event handler logging int he future, feel free to open an issue in bugzilla Jan 16 18:16:27 hmm Jan 16 18:19:07 I use gobject as an event loop in a dbus listener python app. Frankly I don't really care how it works and why it needs introspection-data. The API interface I'm interfacing is dbus. But that was evidently a too simple assumption. :) Jan 16 18:19:21 * kergoth nods Jan 16 18:21:11 But yes, python-pygobject should fail on backfilled gobject-instrospection-data. Or should it? Are there usecases where python-pygobject would work even without the introspection data? I have no clue Jan 16 18:21:54 rburton: Perhaps this should be discussed on the mail lists? Jan 16 18:24:48 Ahh, gobject-introspection-data requires qemu to be able to generate the data, so there are a number of archs where this package is problematic. Jan 16 18:26:41 Alas, the old assumption about that I can always run what I build. I think all sw devs should intern at least one half year with cross building for other targets. :P :D Jan 16 18:36:44 I need a way to make certain that the toolchain bitbake uses is a specific version. Jan 16 18:37:22 Basically because we need to build a FIPs 140-2 compliant image. Jan 16 18:37:52 The toolchain itself is not usually a requirement of FIPS 140-2.. Jan 16 18:38:04 it's the crypto itself that is the issue.. Jan 16 18:38:15 And how the crypto is built Jan 16 18:38:18 Are you focusing on a particular cryptographic engine (or engines)? Jan 16 18:38:55 OpenSSL crypto module is the easiest to build. But what we determined, for FIPS-140-2 support, is the only way to build it and conform the stated requirements was construct an SDK.. and then build it from the SDK following all of the rules in the guide.. Jan 16 18:39:27 The the build system itself could package the prebuilt binaries into the image.. but building it withint he YP/OE environment would not allow us to ensure that the user guide requirements were followed. Jan 16 18:39:57 Right. So then bitbake could use the toolchain in there right? Jan 16 18:40:15 Use bitbake to construct an SDK.. Jan 16 18:40:25 use the SDK to build the openssl-fips module, following the guide.. Jan 16 18:40:37 tar up the resulting binaries, as well as the logs for external verification.. Jan 16 18:41:00 create a recipe that replaces the OpenSSL package with one that includes the BINARY openssl w/ fips module.. Jan 16 18:41:18 the recipe just extracts the tarball, puts the thins in the right location and the package is created, which is used to popualte the FS image.. Jan 16 18:41:31 Hmmmm ... that makes sense. Jan 16 18:41:33 The binaries become immutable to OE/YP.. Jan 16 18:41:52 since you built them in a specific way, you know they meet the requirements and can pass the certifiations required. Jan 16 18:42:28 So our hardware vendor (Digi) is responsible getting their OE attached to one of the existing OpenSSL certs Jan 16 18:43:03 iMX6ul OE Jan 16 18:43:06 for the OpenSSL fips module certificate, you need a corresponding architecture, and compiler version (at a minimum).. Jan 16 18:43:20 there are ones that are in the list hat would be compatible with the i.mx6, but perhaps not as optimized.. Jan 16 18:43:38 Yep but old kernels Jan 16 18:43:39 if you want/need optimized there is a good chance you will have to run through your own certification (or better yet, work with the OpenSSL Foundation to request an update) Jan 16 18:44:00 The kernel does not matter for OpenSSL-fips.. (at least last time I checked) Jan 16 18:44:18 Yep, Digi is submitting to OpenSSL and paying the ransom Jan 16 18:44:44 yes, that is the right way to do this Jan 16 18:45:34 There is an OE on the cert now ... but it is Dizzy/Daisy kernel rev. (3.14) which fell off LTS in Octobe. Jan 16 18:45:41 The G don't like that. Jan 16 18:46:14 So Digi will submit the Morty kernel etc. Jan 16 18:46:35 Certing against teh YP is going to continue that to happen.. as the YP only supports for roughly 1 year at a time.. Jan 16 18:46:55 it's so weird to me hearing that digi is using OE, considering OE was started while I was working there in tech support, often did the early work on bitbake while waiting between calls :) Jan 16 18:46:57 you (and your supplier) should look at a commercial YP provider -- as you can get much longer support time frames (2-5 years typically).. Jan 16 18:47:40 There is another thing to be aware of teh OpenSSL-FIPS module certifiate will be expiring in I believe 2020, and it does not appear that it can be renewed as currently implemented.. (I may be a year or two early.. may be 2022)... Jan 16 18:48:52 (you can find the current cert on the FIPS website, and look at the expiration date...) Jan 16 18:49:20 that has been a problem for some of our customers, and they have choosen to certify there platform themselves to get a slightly later expiration date.. (and yes, that costs MUCH more) Jan 16 18:50:09 Yep though I doubt we care past this year. G funded prototype for evaluation. If the thing gets out of trial ... money will not be of prime consideration. Jan 16 18:50:24 The G never runs out of money. Jan 16 18:50:24 ok Jan 16 18:50:57 But those are good points and I will definitely push up to the Suits Jan 16 18:51:14 * fray works for a commercial YP vendor.. so I'm familiar with all of these problems.. Jan 16 18:51:41 but I'm not trying to advertise my company here..... just making clear commercial support may be a better long term option, assuming you need longer term then a year.. Jan 16 18:52:58 Dood, I love to store your 411. If the thing works, we may definitely need your help. Jan 16 18:55:02 So build the binaries using the rulez, stash them in a repo and pull them into the image with bitbake. Jan 16 18:55:34 yes, that is what i recommend.. it seems to be the easiest way to follow the user guide requirements, provide something to be certified (and verified logs), and show conformance with the requirements if requested Jan 16 19:21:33 kergoth: Yeah, Digi is doing a custom baseboard for us with their iMX6ul SOM. We've done non-YP Linux stuff for them in the past though I didn't work on that. Jan 16 19:22:41 In the context of that conversation I meant "Operational Environment" not OpenEmbedded, but yeah they provide YP based releases for their SOMs. Jan 16 19:24:13 I actually like Digi ... they have been pretty good so far even though we squeezed them on the budget. Jan 16 19:30:47 ah Jan 16 19:35:06 fray, out of curiosity, what does a commercial YP provider deliver exactly? Jan 16 19:35:22 long term support beyond the regular Yocto Project life cycle Jan 16 19:35:44 so if you want 2 years of support on a release, maybe 5.. or even say 15.. many of the commercial providers can do this Jan 16 19:36:30 if you are able to upgrade your product on a 6month or yearly basis.. then that may not be a big deal -- but, then there are other things like faster bug fixes.. (things not merged upstream would be availabel, QA'd and supported for you.. Jan 16 19:36:34 The company I work for make end-user products which makes the SW image on it using Yocto. The end-user is never directly involved in Yocto. We have a sub contractor which provides us with both the custom HW and the BSP plus a distro. Jan 16 19:36:50 We track poky releases more or less Jan 16 19:36:55 additional CVE fixes etc.. (We and any YP supplier who follows the general community rules will supply there patches to the tree during the YP support period...) Jan 16 19:37:51 it's all about having someone to fix a problem, if you have a problem... someone to track security issues on your behalf... and maintenance ability beyond the community.. Jan 16 19:38:01 one or all of those often justifies a commercial provider Jan 16 19:39:12 So a use case for our case would be to get a commercial YP from one source, while the HW vendor maintain the BSP. In a kind of threesome relationship? Jan 16 19:40:14 it can be... In my employers case, they have special ways to setup those agreements... Jan 16 19:40:34 a lot of our customers use COTS boards and skip the HW vendor part.. Jan 16 19:41:00 we offer a lot of COTs BSPs... but that doesn't always mean everything you want is supported on a particular BSP.. so thats part of the business discussion (or well should be) Jan 16 19:41:20 often things like camera modules, or specific GPIOs may not be supported without a specific use-case or customer need.. (in my employers case) Jan 16 19:42:04 fray: you don't happen to work for a Brazillian company? ;) Jan 16 19:42:10 nope Jan 16 19:42:22 I know we have customers in Brazil though.. Jan 16 19:43:30 anyhow, our volumes were far to high for COTS, thus the custom HW and subsequently BSP Jan 16 19:44:24 In our case, if the BSP follows the YP design. Often times we can incorporate support for the BSP as well. However, a lot of the time the BSP ignores the 'linux-yocto' kernel and provides it's own custom support.. We don't support that with our standard product offerings. (others might) Jan 16 19:44:31 In those cases, it usually requires a custom agreement Jan 16 19:46:24 My picture of a YP provider, is someone who maintains all middle-ware layers, excluding kernel (and BSP related packages) and customer applications. So essentially the distro in an extended sense Jan 16 19:48:58 Ya, the kernel is usually included as many defects are related to kernel bugs.. (specifically crashes and various device interactions) Jan 16 19:49:07 what is the "workspace" directory for? can i remove its contents? Jan 16 19:49:29 The alternative (for our customers) is that they must reproduce there bugs on a default kernel (often QEMU) and then we will work to resolve them.. Jan 16 19:49:42 that meets the needs of many folks, and avoids additional cost for 'custom' support Jan 16 19:50:07 (I don't know how my competitors work with this, but I'm sure they have different support requirements and models then the company I work for) Jan 16 19:50:27 (that is part of what makes the YP commercial ecosystem really good. It allows different companies to work together, as well as compete..) Jan 16 19:55:37 The output is a image that can be used for anything, right. Not images purpose built for a single-use (customer) application? Jan 16 19:55:49 correct.. Jan 16 19:55:55 it's the regular Yocto Project build environment, etc... Jan 16 19:56:13 so you can build 'anything' (within reason).. SDKs, images, kernels, etc.. Jan 16 20:00:11 zarzar1: its where devtool unpacks stuff Jan 16 20:26:30 oh ok Jan 16 20:26:57 rburton: i thought so, i removed it to clean up but bitbake complained Jan 16 22:32:58 Any thoughts on whether this commit is appropriate for a stable release like rocko? https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=rocko&id=aa5127d27933a2662ebaa054e35fb1f5262804bb Jan 16 22:34:22 A project I was working on was dependent on the previous behavior of the --label parameter with rawcopy sources so the commit broke it Jan 16 22:49:14 What's a good generic MACHINE for yocto? qmeux86? or are there native intel machines which is well suited? Preferrably out of box Jan 16 22:51:24 MACHINE ?= "genericx86-64" Jan 16 22:51:44 don't let the name confuse you. ;-) Jan 16 22:51:53 i'd suggest qemux86-64 Jan 16 22:52:16 the qemu machines have the advantage of a well defined target, the genericx86 ones are a bit vague Jan 16 22:52:36 also everyone has the qemu machine, only people with meta-yocto-bsp have genericx86 Jan 16 22:52:54 tldr: the genericx86* machines are lame, and i can say that as i wrote them Jan 16 22:53:07 yah, that latter point is probably the key. Jan 16 22:53:13 lol. thanks rburton Jan 16 22:53:48 sveinse: really depends what you mean by good and generic Jan 16 22:54:01 for build testing? the qemu machines are great. Jan 16 22:54:24 genericx86*'s goal is "at least boot on most x86 hardware" Jan 16 22:55:01 * paulg prefers using a crappy piece of bush era e-waste over using qemu. Jan 16 22:55:11 rburton: yeah, was a vague question. For build testing. For testing build artefacts. Not so much for running actually. Jan 16 22:55:15 and no, I can't justify that. Jan 16 22:55:40 paulg: i've discovered that systemd-nspawn will boot a intel-corei7-64 .wic image in about two seconds Jan 16 22:55:41 Or, perhaps my little gobject showdown should convince me to have a vanilla system running Jan 16 22:56:05 sveinse: definitely the qemu machines. trivial to test, solid base. Jan 16 22:56:11 great Jan 16 22:56:25 sveinse: oh i posted "python-pygobject: skip the package if gobject-introspection is disabled" earlier :) Jan 16 22:57:20 paulg: nspawn can read efi partition tables so does the right thing with a wic image, it's great Jan 16 22:57:55 userspace only, obviously, but good enough for "does python work" Jan 16 22:58:02 rburton: yea, I see that. I wasn't sure if pygobject had any other functions when gobject-introspect-data isn't installed Jan 16 22:58:07 the beauty of 2008 vintage e-waste is that I need not concern myself with uEFI boot. :) Jan 16 22:58:24 sveinse: preeeety sure its useless. you had it breaking with gobject, which is the lowest part of it Jan 16 22:59:10 can't do the test in gobject-introspection, as that is needed to build stuff, even if g-i is then disabled Jan 16 23:00:13 I'm not overy comforted that gobject-introspection-data requires a functional qemu to be able to generate the proper artefacts and that's why you can take it away Jan 16 23:27:09 does it exist any (good?) opengl libs for qmeu in yocto? Jan 16 23:41:30 sveinse: g-i *needs* to run code at build time. iirc it was only some mips that didn't work Jan 16 23:43:56 sveinse: as to gl in qemu Jan 16 23:44:06 mesa can go software rendering, which is lame but sort of works Jan 16 23:44:40 turn on llvmpipe and youll get better rendering, been meaning to do this for ages. the packageconfig exists, just needs to be turned on. Jan 16 23:45:12 if you actually want good performance then ask jama for his experiments with using the virtio patches to use the host GPU Jan 16 23:45:20 (but thats more work) Jan 16 23:45:26 llvmpipe should be the best bang-per-buck Jan 16 23:45:42 especially if you run qemux86-64 with kvm enabled Jan 16 23:48:07 rburton: that all requires x, right? Jan 16 23:48:24 shouldn't do Jan 16 23:49:44 Could be interesting to see if our Qt eglfs app would run on qemu. Of course llvmpipe is fast but if it works then I got what I need Jan 17 00:59:09 Hi, I do not see "bb.event.BuildStarted" event in my build. has anything changed in Roko? Jan 17 01:05:28 okay sorry for the insane delay but i finally have a patch for 11996 that i don't utterly hate Jan 17 01:49:29 hey so, i got some free cycles today, and i have merged all the pseudo patches I had in my inbox, and bumped version number to 1.9.0 in master branch. This has *not* been adequately tested against oe-core, though. Jan 17 01:50:35 seebs, thanks for what you can do though! Jan 17 01:51:14 i had that really horrible patch for 11996 and basically i hated it and it offended me Jan 17 01:51:31 so i finally got the cycles to properly rework it, and i think it should now actually work correctly and result in way less database garbage. Jan 17 01:51:36 those are always the worst Jan 17 01:51:58 without that, it turns out that open("/path/to/dir", ..., O_TMPFILE) would result in a bogus entry in the database under the name /path/to/dir, probably. Sometimes. Jan 17 01:52:36 So now O_TMPFILE is handled much more magically, and I think the net results will be better, and it does at least pass the obvious test of "if you run a program that uses O_TMPFILE, then linkat /proc/self/fd/N to a name, do you get something plausible". Jan 17 01:53:08 so thanks! as always, please remember to leave stacks of small, unmarked, nonsequential bills in a dufflebag at the usual location. :) Jan 17 01:54:34 but that gets you the epoll thing to handle the 1024-file case, and the O_TMPFILE thing, and a couple of others. Jan 17 01:54:43 y'all need to get with the game. No serial numbers on $2 coins. Jan 17 01:55:02 and while at it, ditch the stupid penny already. Jan 17 01:55:20 I also have a patch that is not yet ready which restores some of the reliability features from the original design, while preserving most of the speed enhancements from the FASTOP thing. Jan 17 01:56:06 you may, however, need assistance in lifting a giant sack of two dollar coins. Jan 17 02:00:14 then again y'all keep laughing at Kanuckistan for putting milk in bags, so maybe sacks of two dollar coins in bags is still a ways off... **** ENDING LOGGING AT Wed Jan 17 03:00:01 2018