**** BEGIN LOGGING AT Mon Feb 25 02:59:57 2019 Feb 25 03:11:08 how do you use ipk or get bitbake to generate ipk packages Feb 25 04:52:39 black_13: if you use yoe then ipk is default backend Feb 25 04:52:54 so you can do bitbake foo Feb 25 04:53:26 yoe_setup_feed_server Feb 25 04:53:41 yoe_feed_server Feb 25 04:53:50 this will start a feed server on your build machine Feb 25 04:54:14 now you can go to your target machine and do opkg update && opkg install foo Feb 25 04:54:26 provided you have n/w setup on your target Feb 25 09:01:19 JaMa: From what I remember do_install had to have the get_auto_pr else the PR values would be incorrect Feb 25 09:02:15 PKGR, right? but do_install doesn't seem to use them anywhere (other than WORKDIR where it's not expanded anyway) Feb 25 09:02:25 JaMa: yes, its the use of PKGR Feb 25 09:03:06 JaMa: I suspect back then it may have done but changed over time? Feb 25 09:03:22 I'll try to remove it to see if something breaks now Feb 25 09:04:16 JaMa: definitely worth looking at, it does seem an odd thing to do now... Feb 25 09:05:07 I've also replaced PKGR with PR to work around this (PKGR can be used in the symlink later) Feb 25 09:06:16 JaMa: you're effectively just reverting that commit then Feb 25 09:06:21 (?) Feb 25 09:08:05 only partially and with do_deploy_links task after do_deploy it can result in the same artifact names Feb 25 09:08:31 JaMa: but the artefact name itself would have the unexpanded PR? Feb 25 09:09:08 the goal is to have reusable do_deploy sstate, which is then hard linked with any filenames you want (which might mean expanded PKGR) Feb 25 09:09:44 JaMa: you are right, the use of TASKHASH in get_auto_pr means it has to be called consistently Feb 25 09:10:21 e.g. with DATETIME currently included in artifact names, you either have to re-execute do_deploy every single build (which means rebuild for builds with rm_work) or you have "old" datetime in deploy directory artifacts Feb 25 09:11:25 it's more annoying if you do "releases" by setting the version suffix e.g. from jenkins job -> again either you need to rebuild kernel or you might get different release number for kernel artifact in some builds (those where kernel checksums didn't change since previous release) Feb 25 09:12:09 JaMa: my main worry with this is that we then break "stacking" artefacts Feb 25 09:12:40 JaMa: the old OE behaviour was to generate a new image each run, the symlinks were then added to you could easily find "latest" Feb 25 09:12:54 in webOS we work around this by extra task (do_deploy_fixup) but it's quite error prone to do from "outside" in our layer, because every do_deploy needs to be wrapped with do_deploy_fixup and then the task dependencies which might depend on other recipe do_deploy need to be adjusted as well Feb 25 09:13:06 JaMa: with sstate we started letting it clean up previous output but left it so you could easily disable that Feb 25 09:13:18 this use case is still supported Feb 25 09:14:02 that's why the links are hardlinks (so whatever the version says you'll get) and the latest is the one without version Feb 25 09:14:24 JaMa: hmm, right Feb 25 09:15:49 maybe it could be simiplified even more and use just KERNEL_VERSION variable in do_deploy (as the latest one) like do_install does, but that will prevent people from renaming the "latest" one in deploy Feb 25 09:15:58 JaMa: I agree we need to do something to improve things Feb 25 09:16:55 I have something which works in most cases, once I test it on more combinations, I'll share it in the bugzilla to better show how it looks now and how it will look like in deploy dir Feb 25 09:17:53 JaMa: sounds good. I think explaining the change and the reasons behind it will be impoartant Feb 25 09:18:47 having the extra variables introduced in thud already helps with "external" sollution, but hopefully with good explanation people will agree to get it all in oe-core Feb 25 09:19:13 JaMa: yes Feb 25 09:21:16 * RP notes its technically 2.7 feature freeze today. We're nowhere near ready :( Feb 25 09:25:11 hello, I applied the preempt_rt patch and still see peaks of 15ms although normally it runs with 300µs. Do you also have such experience, and what is the best tool to analyze where that is reasoned? Feb 25 09:27:40 YokoOkto: probably better to ask the linux rt channel over at OFTC Feb 25 09:28:30 hmm ok thank you Feb 25 09:43:27 kanavin: around? Feb 25 09:47:36 * RP sends email **** BEGIN LOGGING AT Mon Feb 25 10:59:24 2019 Feb 25 11:02:57 kanavin: I've taken some bits of virtgl in so the patchset should reduce a bit more :) Feb 25 11:03:21 RP: thanks :) I did notice that debian 8 also fails the selftest with an unhelpful error message Feb 25 11:04:05 kanavin: right, two issues. the unhelpful message and the fact it fails :( Feb 25 11:04:18 probably should have a bug for the former Feb 25 11:04:25 RP: I suspect the actual testimage log might tell a bit more Feb 25 11:04:29 log file Feb 25 11:04:53 oh, massive update to master, finally! Feb 25 11:05:37 kanavin: this batch took quite a bit of sorting out Feb 25 11:08:48 we now have a working resulttool, buildhistory and auto updating repositories of all the data, hopefully Feb 25 11:10:44 hugo___: you need to source to use the sdk Feb 25 11:27:58 hugo___: And that's a feature, not a bug. ;-) Feb 25 11:31:18 rburton: jofr : Ok, need is a strong word ;P Feb 25 11:42:29 hugo___: bits of the sdk use environment variables exported by the setup script, so need is the correct word Feb 25 11:47:08 hugo___: it does not work without it. I'm sure you could wrap every binary in the SDK to set the right envvars to avoid sourcing but you'd still have to modify PATH to find said binaries and to do that you'd probably still have to source something Feb 25 12:17:51 RP: I'll send a patch that removes the _remove in qemu recipe in a moment Feb 25 12:27:48 Hey guys, I have still no review on my patch sent on the mailing list, shall I change something ? See mailing list thread : "Fixing devtool issue with kernel bbhappen do_patch recipe" Feb 25 12:36:11 kanavin: thanks Feb 25 12:36:59 RP: removing _remove is actually tricky, can you give me a suggestion? I'd like to ensure that gtk+ is not in the final value, but it seems impossible to override what is set in local.conf, other than through use of _remove Feb 25 12:37:28 yacar_, that should be looked at by Paul Eggleton Feb 25 12:37:54 kanavin: already poked him couple of days back, probably he forgot again :/ Feb 25 12:42:45 kanavin : do you have Paul's email address ? Feb 25 12:43:24 yacar_: its easy to find on the ML, and he's here as bluelightning. but just offline, due to timezone Feb 25 12:43:40 paul.eggleton@linux.intel.com Feb 25 12:43:53 Thanks! Feb 25 12:53:15 kanavin: hmm, that is harder than I was initially thinking Feb 25 12:53:43 RP: we can drop the qemu related bits from local.conf altogether, and enable gtk+ directly from the recipe Feb 25 12:54:01 kanavin: this is something users may want to configure Feb 25 12:54:14 kanavin: perhaps remove is the right thing :/ Feb 25 12:54:46 kanavin: it would only become a problem if someone works on enabling gtk on mingw/darwin Feb 25 12:55:41 but then they would adjust the recipe as a part of that Feb 25 12:55:50 to not do the remove Feb 25 12:55:54 * RP just reran a-full and its nearly completed in less than 1 hour 50 minutes with hot sstate Feb 25 12:56:28 remaining bits are ptest, mips, mips64 and qemuarm Feb 25 12:56:44 that is a pretty amazing build time Feb 25 12:58:09 RP: yeah, I was going to ask if we really need to run those very long mips target tests, or make them shorter somehow Feb 25 12:58:35 kanavin: we already did cut a few out Feb 25 12:59:14 kanavin: actually, I'm not sure you do need to change PACKAGECONFIG for mingw from local.conf Feb 25 12:59:29 kanavin: if the user configures gtk+ into a mingw build that is their own fault Feb 25 12:59:46 RP: but it's set for all nativesdk variants from local.conf Feb 25 13:00:08 and uncommented by default, which will break things on mingw Feb 25 13:00:33 ERROR: ParseError in configuration INHERITs: Could not inherit file classes/package_rpmpackage_ipk.bbclass Feb 25 13:00:41 what is this error from Feb 25 13:00:41 kanavin: hmm, I was thinking mingw has its own namespace but you're right Feb 25 13:01:03 black_13: misset PACKAGE_CLASSES variable (missing space) Feb 25 13:01:45 RP: you can give it special treatment via PACKAGECONFIG_mingw32_class-nativesdk though, but it would further bloat local.conf, and really shouldn't belong there Feb 25 13:02:08 kanavin: right, that is a level of ugliness the user doesn't need Feb 25 13:06:11 this is my local.conf : http://codepad.org/J4JeieU4 Feb 25 13:08:44 PACKAGE_CLASSES ?= " package_rpm" Feb 25 13:09:31 black_13: I strongly suspend something is appending to that without a space Feb 25 13:15:04 how do you instruct bitbake to use on the ipk package format and install the package manager Feb 25 13:15:16 what bothers me is i had this working Feb 25 13:21:33 black_13: the problem is those last two lines. Why not just set PACKAGE_CLASSES = "package_ipk" ? Feb 25 13:22:11 black_13: PACKAGE_CLASSES_append = " package_ipk" (with a space) would have worked Feb 25 13:23:24 i will check Feb 25 13:24:53 ok its bitbaking lets see what happens Feb 25 13:29:04 still buiding PACKAGE_CLASSES_append = "package_ipk" PACKAGE_CLASSES_remove = "package_rpm" Feb 25 13:29:19 sorry it is still build the rpm package manager Feb 25 13:32:28 black_13: whats wrong with setting PACKAGE_CLASSES ?= "package_ipk" Feb 25 13:32:40 or even more directly PACKAGE_CLASSES = "package_ipk" Feb 25 13:32:59 i did that i believe Feb 25 13:33:42 probably not, then Feb 25 13:34:09 bitbake -e $WHATEVER | less, and then search for PACKAGE_CLASSES Feb 25 13:37:25 http://codepad.org/JKQiuR1J Feb 25 13:39:21 black_13: then chances are that something that you do need rpm for other reasons Feb 25 13:40:15 it use rpm for other reason but will also have ipk packages available Feb 25 13:41:48 is that a statement or a question? Feb 25 13:52:10 a statement Feb 25 13:52:54 yocto being really late to the p3 party yes? Feb 25 13:52:56 you are saying that though it may build the rpm package management system it will have ipkg files available for use Feb 25 13:53:27 black_13: no, thats not what i am saying. Feb 25 13:53:50 LOL it needs both py2 and py3 Feb 25 13:54:07 black_13: i am saying that when you have package_ipk as the package_class, then this is what it will use to build the image and to provide packages. Feb 25 13:55:07 black_13: there can be packages that require the rpm tooling for other reasons, but that doesn't affect the image building and packaging process then. Feb 25 13:55:34 Hi, I have a problem with Yocto, I'm not sure how to approach. I want to build a Feb 25 13:55:34 few Yocto images, which are 99% identical, except for the couple of packages. Feb 25 13:55:34 Usually, I want to install one or two extra packages. Feb 25 13:55:37 Feb 25 13:55:40 I want to save some space on multiple rootfs images. Is there some way to produce one 'base' image and them install rpm package in the image on the host? Feb 25 13:55:43 Feb 25 13:56:56 LetoThe2nd: your correct i see multiple ipk files present in ./build/tmp/deploy/ipk/all Feb 25 13:57:12 lexa_`: you can have a base image recipe, and 99 other recipes that jsut include it and extend it by one or two packages. Feb 25 13:59:07 LetoThe2nd: But I don't want to build multiple images in Yocto. Maybe it is possible to install packages into pre-build rootfs? Feb 25 13:59:45 lexa_`: i don't get the point Feb 25 14:00:38 LetoThe2nd: save some diskspace by having one big image + packages which could be installed when needed. Feb 25 14:00:50 lexa_`: you want yocto to create a base image, and then run a whatever-something that takes this image, and makes it into 99 other images that only differ by a handful of packages. Feb 25 14:01:15 exactly! Feb 25 14:01:19 lexa_`: i mean, you explicitly wrote "install rpm package in the image on the host" Feb 25 14:01:31 so there's no diskspace saving in any case. Feb 25 14:01:55 or did you actually mean to create a base image + a package feed, and then install the add-ons in the TARGET? Feb 25 14:02:31 Usually, I don't want to have all images at the same moment, so I could have one base image and one base image with an extra package installed. Feb 25 14:03:43 LetoThe2nd: I wouldn't like to install packages on the host, because it implies RW rootfs. Feb 25 14:04:01 lexa_`: so what would be the difference to bitbake'ing the base-image and the special image? Feb 25 14:04:43 lexa_`: so then this was a freudian error now, you meant "I wouldn't like to install packages on the target, because it implies RW rootfs." Feb 25 14:04:48 ok, that makes perfect sense Feb 25 14:07:25 LetoThe2nd: The difference between base-image and a special image is that special image has a few packages extra. Feb 25 14:07:37 lexa_`: i understood that. Feb 25 14:08:22 LetoThe2nd: So, what was the question 'so what would be the difference to bitbake'ing the base-image and the special image?' Feb 25 14:08:36 lexa_`: but i don't see what "diskspace savings" you expect. if you bitbake special-image which depends on base-image, then bitbake will literally build only what those two images need, and assemble them Feb 25 14:08:49 the more they share, the better. Feb 25 14:10:04 anyone seeing illegal instructions from llvm when used with mesa on qemux86? Feb 25 14:11:53 kanavin: for me qemu-native doesn't work with gtk+, but works with sdl2, so it might be useful for people to configure Feb 25 14:11:55 LetoThe2nd: Oh, forgot to explain that. I didn't meant to save space in Yocto. I want to save space on the resulting images, because I have to share them over the Internt. Feb 25 14:12:22 lexa_`: sorry, but you're not making sense. Feb 25 14:13:09 lexa_`: if you have an image that you want to contain a defined set of things, where is the space saving opportunity? Feb 25 14:16:43 kanavin: any link to upstream where it shows that sdl is deprecated in favor of gtk+? Feb 25 14:18:23 LetoThe2nd: Compare: 5 images each 1Gb vs 1 image 1Gb + 5 packages of negligible size. Feb 25 14:18:41 and I have to share these images over the network. Feb 25 14:19:35 So, I'm not saving a diskspace, but a network throughput. Feb 25 14:19:54 lexa_`: ok. now i think i see the missing part. you mean, that you are kind of "development host 1". you produce the base image and feed and share it. "development host 2" receives things, and then creates the images. right? Feb 25 14:20:09 exactly! Feb 25 14:21:13 it would have been very helpful to mention that there are multiple "hosts". you did always only name "host" Feb 25 14:21:26 JaMa, I tried everything I could to make qemu work with sdl2, it would either refuse to start, crash on driver initialization or show a blank window when starting smth graphical Feb 25 14:21:55 LetoThe2nd: sorry, I forgot to mention that fact. Feb 25 14:21:57 if you have a branch somewhere which works for you, with precise instructions, I could give it a try Feb 25 14:22:13 JaMa, sdl is deprecated in favor of gtk+ in poky distro Feb 25 14:22:20 lexa_`: in that case, i don't know of any fitting solution. you can of course provide a base image plus a package feed, but the re-packaging of the image is something you'd probably have to script yourself. Feb 25 14:27:40 kanavin: "qemu: build target variant with gtk+, and nativesdk variant without sdl" this commit isn't poky specific and still it says sdl is deprecated Feb 25 14:27:52 LetoThe2nd: I guest I'll to script image re-packaging. Feb 25 14:29:08 kanavin: https://github.com/webosose-emulator/prebuilt-emulator Feb 25 14:30:03 JaMa, which version of qemu is that? Feb 25 14:30:49 the prebuilt one is 2.7.0 Feb 25 14:30:59 I was using http://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/qemu to build it with OE Feb 25 14:31:26 but my version of mesa-native was also depending on drm-native, so I wasn't using that much from host as your version Feb 25 14:32:08 yes, that was a trade-off in time needed to build all the drivers Feb 25 14:32:46 and my version still had some issues, like mesa loading the drm driver from the path in libdrm WORKDIR which of course didn't work after rm_work removed libdrm WORKDIR Feb 25 14:33:20 now I've built your version with both sdl and gtk+ support so I should be able to test both just by changing -display parameter Feb 25 14:33:32 yep, if you can make sdl work, that'd be great Feb 25 14:33:50 virgl enabled qemu in gentoo has the same issue (sdl works and gtk+ doesn't) Feb 25 14:34:24 fedora and opensuse have the opposite problem Feb 25 14:34:34 ubuntu doesn't have virgl enabled at all Feb 25 14:34:45 but there might be some new issue in either xubuntu (as guest) or newer qemu, because now with default display xubuntu fails to start graphics, it works only with passthrough gpu or qxl display (slowly) Feb 25 14:35:16 I have ubuntu packages rebuilt with sdl and virgl, but I haven't tried them with gtk display Feb 25 14:36:28 as in http://forum.webosose.org/t/pre-built-images-available/392/2 Feb 25 14:37:34 ah I didn't use GTK because "With GTK UI there are few more issues, the Feb 25 14:37:34 resolution isn't set correctly and the cursor isn't rendered inside QEmu Feb 25 14:37:35 window." Feb 25 15:03:53 i'm setting up my own distro, but when i bake virtual/kernel, it seems to ignore my preferred_provider Feb 25 15:04:01 how does one go about diagnosing that? Feb 25 15:04:31 varjag: bitbake -e Feb 25 15:04:32 i tried getting the dependencies graph for recipes, but it doesn't help Feb 25 15:04:55 varjag: chances are that COMPATIBLE_MACHINE or such is off Feb 25 15:04:55 aha.. Feb 25 15:14:26 thanks, it looks like my definition is getting overriden Feb 25 15:14:39 :-) Feb 25 15:17:46 New news from stackoverflow: Qt - Module "QtQuick.Controls" is not installed Feb 25 15:19:10 when is ${B} cleaned? Feb 25 15:19:49 if I do some file processing in there, should my recipe task start with a bunch of rm first, to not have stale files from the previous run? Feb 25 15:25:58 They stay there between runs, yes. In some cases you may need to remove stuff. Feb 25 15:28:12 ernstp: FWIW: I have a recipe that, among other things, creates a zip archive. When I originally created that recipe, I do recall that zip added my files into the old archive if they had a new name. So now I start by removing it so I don't have to do a -c cleanall before building that recipe. Feb 25 15:28:51 depends on the task being rerun Feb 25 15:45:00 kergoth: if I trigger compile to rerun Feb 25 15:45:19 should I always start with rm -rf ${B}* ? Feb 25 15:45:31 no Feb 25 15:45:33 rm -rf ${B}/* Feb 25 15:45:35 no Feb 25 15:45:51 so what's the idea? :-) Feb 25 15:46:32 Only the build artifact that would be added to incrementally. Feb 25 15:47:37 I discovered it because I had an intermediate file where I did >> instead of > Feb 25 15:47:43 Let's say you have something that does an "echo sumfink >> somefile" in your recipe. If you run that build over and over again, your "sumefile" will contain lots of "sumfink"s. Feb 25 15:47:53 indeed Feb 25 15:48:44 Hi! I'm trying to build an eSDK with SDK_INCLUDE_PKGDATA="1" and it keeps failing during populate_sdk_ext with "No such file or directory: '[...]/build/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-base/1.0-r0/recipe-sysroot/world-pkgdata/locked-sigs-pkgdata.inc'" Any ideas? Feb 25 15:49:18 So in this simple example you have two options. Either have the first echo do an overwrite ">" or have a build-step that first does a: rm -f somefile and then does you append-stuff. You don't want to erase everything to get rid of a single file. Feb 25 15:49:29 your* Feb 25 15:50:09 jofr: when do you want to keep old stuff around in ${B}?! Feb 25 15:50:41 When you build something more often than once in your lifetime. ;-) Feb 25 15:50:51 a assume a cmake recipe that triggers do_compile nukes the build directory? Feb 25 15:51:04 Nope Feb 25 15:51:38 Only if the upstream has changed and it needs to fetch again Feb 25 15:51:46 well there's the ccache, and when I work on something I compile it myself. I didn't expect yocto to do dirty buidls Feb 25 15:52:19 I mean sstate Feb 25 15:53:04 ok, fetch deletes B? Feb 25 15:56:10 I believe it does. If I'm wrong, I hope someone will correct me on that? :p Feb 25 15:58:17 I've only used ${B} once and that was for a temporary workaround that I'm not even using anymore. Feb 25 16:02:18 I guess this ties in with "B: By default, this directory is the same as the S directory" Feb 25 16:03:44 cmake has rm -rf ${B} mkdir -p ${B} in do_configure Feb 25 16:05:26 Yes. But doesn't it only do a configure when it needs to fetch new sources? Feb 25 16:06:32 yeah I guess it's quite rare to only trigger do compile, perhaps mostly happens when developing a recipe itself Feb 25 16:07:36 hi, is this the syntax of fetching from a local repo on the machine? SRC_URI = "file:///home/lpapp/foo;protocol=file;nocheckout=1;branch=topic \ Feb 25 16:09:24 lpapp: for git, no Feb 25 16:09:42 lpapp: SRC_URI = "git:///home/xxxx;protocol=file" Feb 25 16:09:50 oh ok, tried that, too, thanks Feb 25 16:10:11 file:// won't call out to git, it'll copy the file over Feb 25 16:10:24 hmm, that may be good enough as well Feb 25 16:10:41 you might think that git over ssh is ssh://path but it's git://path;protocol=ssh etc Feb 25 16:10:48 with git:/// -> unable to find revision Feb 25 16:11:13 WARNING: Failed to fetch URL git:///home/lpapp/foo;protocol=file, attempting MIRRORS if available Feb 25 16:11:34 ERROR: Fetcher failure: Unable to find revision b9e8d459764b211392089f4ea04ce003229ae0b9 in branch master even from upstream Feb 25 16:12:39 lpapp/foo/.git ? Feb 25 16:13:27 lpapp: Try adding: SRCREV = "${AUTOREV}" and PV = "1.0+git${SRCPV}" (you may want a different PV though) Feb 25 16:14:37 If you want to use the latest head, that is. Feb 25 16:19:47 no, it is not auto, sorry Feb 25 16:19:50 it is not the latest, etc Feb 25 16:20:19 so why is it failing to fetch given that git show b9e8d459764b211392089f4ea04ce003229ae0b9 is just fine in that local repo when I cd in? Feb 25 16:21:20 if I specify the branch, it is "better" Feb 25 16:24:14 thanks Feb 25 16:46:32 so COPY_LIC_DIRS puts all the licenses that are part of the image on the target rootfs, but is there a method to get a bundle outside the target? Feb 25 16:47:11 tmp/deploy/license/ just has licenses for everything compiled for some reason Feb 25 16:48:35 for a good reason: everything that gets built puts the license in deploy Feb 25 16:48:42 just like everythingt hat gets built put packages into deploy Feb 25 16:49:17 you can use the image manifest to get the package names, so you know what bits of the license folder to pick Feb 25 16:51:05 rburton: I mean everything compiled regardless of what triggered it :-) Feb 25 16:51:32 so it includes hosttools etc Feb 25 16:52:17 I'm thinking about stealing /usr/share/common-licenses from the target rootfs but that feels a bit backwards :-) Feb 25 16:57:02 ernstp: just copy what you need from deploy/licenses Feb 25 16:57:33 RP: alsa patch from tanu on the list if you didn't spot it Feb 25 17:05:51 rburton: i have to implement package to recipe mapping then, don't I have? feels like a lot of work duplication Feb 25 17:06:33 ernstp: oe-pkgdata-util can do that Feb 25 17:06:50 i even extended it recently to take a list for pretty much this purpose Feb 25 17:07:18 i'm assuming that license.bbclass can't generate a license manifest for you per-image Feb 25 17:07:20 maybe it can Feb 25 17:08:21 also ripping it out of the rootfs isn't that nasty tbh :) Feb 25 17:08:36 ensure you have the rootfs as a tar.gz and then you can just tar them out Feb 25 17:09:25 :-) Feb 25 17:09:39 do you actually what the license text, or just the names? Feb 25 17:09:41 my idea was to do it in a postprocess hook and nuke them from the image Feb 25 17:09:53 I want the text Feb 25 17:09:58 if you don't want them in the image, don't put them in the image... Feb 25 17:10:21 yeah but that was the available method to get them collected per image :-) Feb 25 17:11:05 so i'd turn off license_image, then take the image manifest, turn each package into a recipe, and grab the files from deploy/licenses/[recipe] Feb 25 17:11:40 $ oe-pkgdata-util lookup-pkg -r pkg [pkg ...] Feb 25 17:11:57 license.bbclass has quite a lot of code... Feb 25 17:12:06 or was it lookup-recipe Feb 25 17:12:11 yeah license.bbclass is arguably over-engineered Feb 25 17:12:16 visitor classes and what not Feb 25 17:12:44 no glory in rewriting something that works though ... Feb 25 17:14:20 cat tmp/deploy/images/machine/my-image-machine.manifest | awk '{ print $1 }' | xargs oe-pkgdata-util lookup-recipe | sort | uniq | xargs -i ls 'tmp/deploy/licenses/{}' -d Feb 25 17:14:46 ls returns without any errors so that looks good Feb 25 17:15:35 the long term fix would be to enhance imagelicence.bbclass so its behaviour is configurable: you want per-image license texts outside the image which is can almost but not quite do. Feb 25 17:17:07 the usecase is: no UI on device, licenses go on homepage/companion app, which I think is quite common Feb 25 17:17:15 yeah Feb 25 17:17:28 add some toggles to the class Feb 25 17:18:15 LICENSE_CREATE_IMAGE_ARCHIVE or something Feb 25 17:19:06 i could see it writing a directory of the licenses under deploy/images/[image name]/ Feb 25 17:19:12 rburton: I had, thanks Feb 25 17:19:33 kanavin: playing with virtgl locally, its not easy to use compared to sdl :( Feb 25 17:19:57 RP: how come? Feb 25 17:20:11 rburton: right, then you can archive it however you like Feb 25 17:20:18 exactly Feb 25 17:20:24 kanavin: I use X over ssh for example which no longer works :/ Feb 25 17:20:49 kanavin: I also just tried egl-headless here and it seems broken :( Feb 25 17:21:15 RP: does the oe-selftest pass for it? Feb 25 17:22:00 I wonder if I have waited long enough to ping you about https://bugzilla.yoctoproject.org/show_bug.cgi?id=12107 again... ;-) Feb 25 17:22:01 Bug 12107: normal, Medium, 2.7, JPEWhacker, NEW , useradd-staticids: groupadd: GID already exists Feb 25 17:22:40 kanavin: its skipped, I'll retry with better permissions Feb 25 17:23:23 RP: you need /dev/dri/render* with appropriate permissions Feb 25 17:23:25 lexander@alexander-box:~/development/mbient-virgl/build-qemu-spark$ ls -l /dev/dri/ Feb 25 17:23:25 total 0 Feb 25 17:23:25 drwxr-xr-x 2 root root 80 Feb 21 19:18 by-path Feb 25 17:23:25 crw-rw----+ 1 root video 226, 0 Feb 21 19:18 card0 Feb 25 17:23:25 crw-rw----+ 1 root video 226, 128 Feb 21 19:18 renderD128 Feb 25 17:23:35 kanavin: actually, X fails to start in my image with a GLSL compile failure :( Feb 25 17:24:20 kanavin: (with runqemu gl) Feb 25 17:25:04 RP: for me core-image-sato starts without problems, it adjusts to use Glamor X server automatically when it sees 'hardware' gl Feb 25 17:25:41 for weston, you need to 'fix' the config file to use dri instead of fbdev Feb 25 17:25:55 kanavin: this was core-image-sato ;( Feb 25 17:41:48 kanavin: the headless selftest passes but running it with runqemu just "hangs" Feb 25 17:42:14 kanavin: running the qemu command on the console I see errors to do with bad dri driver paths by the looks of it Feb 25 17:42:24 RP: you don't get anything when you connect to qemu with vnc? Feb 25 17:45:46 kanavin: there is no vnc to connect to, qemu dies afaict Feb 25 17:45:53 kanavin: I'm probably doing something wrong Feb 25 17:46:19 but egl-headless only makes sense if you also enable vnc, if you actually want to see the output Feb 25 17:46:48 kanavin: right, it doesn't pass in that option though so I need to do that Feb 25 17:46:49 ? Feb 25 17:47:05 yes :) Feb 25 17:47:41 runqemu kvm egl-headless publicvnc Feb 25 17:47:56 kanavin: its confusing as runqemu just appears to hang, bad error handling? Feb 25 17:48:39 it starts, but renders its output into nothing. if it has an ssh server, you can log into it. Feb 25 17:48:58 publicvnc option lets you see the output Feb 25 17:49:20 kanavin: here, if I run the qemu command from the console that runqemu claims to be running, I just get errors Feb 25 17:49:46 gbm: failed to open any driver (search paths /media/build1/poky/build/tmp/work/x86_64-linux/mesa-native/2_18.3.4-r0/recipe-sysroot-native/usr/lib/dri) Feb 25 17:50:21 kanavin: what is worrying me more is that a) the headless test passes and b) I'm not seeing errors from runqemu Feb 25 17:50:56 RP: runqemu does special magic to use the host dri drivers: Feb 25 17:50:57 dripath = subprocess.check_output("PATH=/bin:/usr/bin:$PATH pkg-config --variable=dridriverdir dri", shell=True) Feb 25 17:51:04 os.environ['LIBGL_DRIVERS_PATH'] = dripath.decode('utf-8').strip() Feb 25 17:51:32 so I think it works as it should Feb 25 17:52:19 assuming host has libdrm-dev? Feb 25 17:52:33 rburton, yes Feb 25 17:52:47 kanavin: earlier it warned me about missing dri.pc, the reality was pkg-config wasn't installed :/ Feb 25 17:53:07 kanavin: right, so my expectation of being able to copy and paste the command is now invalid Feb 25 18:44:50 RP: fwiw, just tried core-image-sato here, plain gl works fine, egl-headless also works fine via vncviewer. Feb 25 19:52:31 rburton: RP Sorry for late reply. I currently support multiple toolchains for multiple platforms in the embedded space. I currently update them when theres a bump in the Poky SDK, which sometimes means a change in specific compiler flags. Most of the time, its not really an issue, as the sdk stays consistent. The reason I do this is to let the developers use the same editor but switch toolchain and reconfigure Cmake. We do not Feb 25 19:52:31 NEED to source for this to work. It would be great if yocto could export the toolchain in the setup step, as it now know the path of the sdk on the host. Feb 25 19:54:23 This is something I could do as a custom build step when we generate the sdk, just wondering before hand so I don't do unnecessary work :) Anyone have a pointer to the code where the current Cmake toolchain is compiled? Feb 25 21:52:10 kanavin: I'm just not getting a good vibe about this being usable as it stands. I can't quite put a finger on why, just lots of odd things happening and things which don't quite work. Thinking we might mark this as experimental for 1.7 Feb 25 21:52:13 2.7 Feb 25 22:11:28 ernstp: Sorry I missed your question on YOCTO #12107. I haven't had a chance to look at it yet :( Feb 25 23:19:32 is tere something that is even smaller than core-image-minimal Feb 25 23:22:27 can I enable two systemd services from one bb file? I added a second one to SYSTEMD_SERVICE_${PN} but that didn't seem to enable it Feb 25 23:38:26 you can Feb 25 23:38:39 what does service look like ? is it there in image Feb 26 00:23:21 halstead, any issues on the AB nfs mounts? Feb 26 00:23:37 my build failed for: Feb 26 00:23:40 mv: preserving times for ‘/home/pokybuild/git/trash/1551139983-97940/a-full-75’: No such file or directory Feb 26 00:23:40 mv: failed to preserve ownership for ‘/home/pokybuild/git/trash/1551139983-97940/a-full-75’: No such file or directory Feb 26 00:23:40 mv: setting attribute ‘system.nfs4_acl’ for ‘system.nfs4_acl’: No such file or directory Feb 26 00:23:40 mv: preserving permissions for ‘/home/pokybuild/git/trash/1551139983-97940/a-full-75’: No such file or director Feb 26 00:24:14 https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/75/steps/11/logs/stdio Feb 26 00:25:50 armpit, Not sure. I'm quite sick today. Looking now. Feb 26 00:33:39 armpit, The NAS looks okay. It seems that maybe the destination directory was removed before the system was ready for that. Feb 26 00:34:56 huh switching mesa to use meson *slowed down* the compile Feb 26 00:35:43 (cputime) Feb 26 00:35:55 walltime, sure, good win Feb 26 00:39:13 rburton: I can see one regression where its not respecting the code to install KHR/khrplatform.h Feb 26 00:39:33 khem: reply now or forever hold your peace Feb 26 00:39:33 or not to install it when egl and gles is disabled Feb 26 00:40:07 now you know Feb 26 00:40:49 I remove egl gles2 from PACKAGECONFIG especially with mesa-gl which should not install that header atleast that was the behavior Feb 26 00:41:24 that led to another problem for which I sent a patch to ml already Feb 26 00:41:30 bugs everywhere Feb 26 01:10:56 halstead, sorry to hear. Get well. **** ENDING LOGGING AT Tue Feb 26 02:59:57 2019