**** BEGIN LOGGING AT Mon Mar 04 02:59:57 2019 Mar 04 07:26:53 Hi there, anyone available? Mar 04 07:27:37 Got a question regarding the SDK generation which I cannot seem to solve (google didn't give the resolution either) Mar 04 07:31:11 Skye7707: just state your case of emergency and wait for rescue. if somebody knows, you will get an answer. if nobody knows, you'll get none ;-) Mar 04 07:31:49 Alright, thanks, it's not an emergency but would be nice to see how to solve it ;-) Mar 04 07:34:34 The situation is as follows: one of my recipes will compile two static libs (.a) along with an executable. It adds the executable to the image. What I want to achieve is have the static libs in the SDK. Now, I have google a bit and found the TOOLCHAIN_TARGET_TASK keyword to be added in the image recipe, which I did but when I try to populate_sdk I get "Unable to install packages". Mar 04 07:34:50 The entire line in the recipe is: TOOLCHAIN_TARGET_TASK_append = "some-lib-here-staticdev" Mar 04 07:36:09 in the lib's recipe I also added FILES_${PN}-staticdev = "\ ${APPLI_BIN_PATH}/*.a \ " which some believed would solve the issue but unfortunately didn't do so Mar 04 07:36:32 (the appli bin path points to the correct location where the .a files are) Mar 04 07:37:31 Skye7707: have you checked that the package some-lib-here-staticdev contains what you expect? Mar 04 07:38:04 Sorry, I'm quite new to Yocto, not sure what you meant Mar 04 07:39:59 FILES_${PN}-staticdev += "asdasdasd" means: "add asdasdasd to the package ${PN}-staticdev" Mar 04 07:40:27 with ${PN} being the automatically generated package name, extracted from the recipe name Mar 04 07:40:48 so the first thing would be to check if that package really contains what you expect Mar 04 07:42:26 Alright, so how would I do that? To give you some context, all I've done so far is adjusted some easy recipes and generated images, checking on what is in a package, I'm not sure how, do I compile the recipe and then check the output folder? Mar 04 07:43:40 Skye7707: oe-pkgdata-util list-pkg-files some-lib-here-staticdev should give you the contents Mar 04 07:44:08 Skye7707: and if there is nothing highly secret in there, it would be certainly helpful if you could put the recipe in question onto a pastebin Mar 04 07:44:54 the list cmd reveals that indeed the package seems e;pty Mar 04 07:44:55 empty Mar 04 07:45:36 sure, I'll redact it a bit, give me a minute Mar 04 07:45:44 also, APPLI_BIN_PATH is not something generic. so i kinda suspect that you are doing something fishy Mar 04 07:46:05 I figured I needed to point to where the .a files would be located Mar 04 07:46:11 so that's why I added that Mar 04 07:46:14 hang on Mar 04 07:48:39 https://pastebin.com/nuipArXt Mar 04 07:50:08 ok, there's a couple of things that are pretty wrong Mar 04 07:50:31 HSM_ROOT and HSM_HOSTSW_DIR should certainly not go in there Mar 04 07:50:56 if you totally believe you need externalsource, then don't inject it in the recipe itself Mar 04 07:51:40 if you are already using make, then be sure to revisit https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#sdk-adding-makefile-only-software Mar 04 07:52:11 disabling package_qa is almost always really bad, too Mar 04 07:52:59 and as your APPLI_BIN_PATH get indirectly constructed from the externalsource path, it will break definitively Mar 04 07:53:18 everything in FILES must be target-relative paths Mar 04 07:54:31 ok thanks for the feedback, let me see if I understand everything you just said Mar 04 08:04:54 ok, so, the static lib indeed is compiled with a makefile, and it is completely out of the OE build sys, so I believe the externalsrc is correct Mar 04 08:05:07 um, no Mar 04 08:05:13 ok, do explain Mar 04 08:05:27 externalsrc is a kind of emergency-trick for development Mar 04 08:05:39 oic Mar 04 08:05:52 to be used only if you develop on the source AND the recipe at the same time Mar 04 08:06:05 what would be the correct way of handling it? Mar 04 08:06:38 if you only work on the recipe, as you totally should, then provide a SRC_URI from where the sources are to be fetched Mar 04 08:07:09 usually this is kind of a git/svn/whatever repository, or a tarball from a ftp/something Mar 04 08:14:03 this for example is a really simple recipe with a tarball to get: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-extended/stress/stress_1.0.4.bb Mar 04 08:16:52 The lib is located in a repository so the SRC_URI should point to its location in the repo I assume? Mar 04 08:20:46 umm Mar 04 08:21:13 the lib sources I mean Mar 04 08:21:21 i seriously suggest to have a long, and thorough look at https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-writing-a-new-recipe and then https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#new-recipe-testing-examples Mar 04 08:21:53 alright Mar 04 08:22:02 as i have the feeling that you are missing some really basic concepts of a recipe... and we have excellent documentation for exactly that Mar 04 08:22:55 that's for sure true, I've just built on top of what was existing and from the looks of it, other people didn't exactly follow the way it should be written Mar 04 08:23:06 or ask whomever tasked you with that to give you a couple of introductory hours Mar 04 08:37:10 or ask whomever tasked you with that to give you a couple of introductory hours Mar 04 08:37:13 oops Mar 04 09:15:27 I would like to share some variables between recipes, so that I can create 'rootfs-app1-x.y.z' which contains app1 version x.y.z. I could make these variables available globally through local.conf or the DISTRO, but ideally I'd like this to just be a part of the image recipe. Is this possible? Mar 04 09:18:25 m314: no sharing of things between recipes, simple as is Mar 04 09:18:51 m314: you can create an include that you pull in at different places as a workaround, but thats about it Mar 04 09:21:11 LetoThe2nd: Could I build my application and rootfs in the same recipe? Mar 04 09:21:35 m314: no Mar 04 09:23:06 Ah well. Good to know. Thanks anyway :-) Mar 04 09:27:43 LetoThe2nd: I'm trying to get rid of the externalsrc for starters, let's assume that we have a local repo checked out at a given path where the sources and makefile are located that should be fetched in a recipe, when I point to them with SRC_URI = "file://...."in the do_compile step make doesn't find the Makefile, when do a find for it, the sources ended up in the workdir but in subfolders (i.e. /home/user/....) which I wouldn't exp Mar 04 09:28:15 as I'm pointing directly to the dir with sources, why is it reconstructing the entire path of that dir Mar 04 09:29:00 Skye7707: sorry, but wrong again Mar 04 09:29:16 I figured ;-) Mar 04 09:30:03 Skye7707: the fetch process works like this. either a) the sources are directly bundled with the recipes, in a directory called "files" right next to it or b) the sources ar pulled from some server automatically Mar 04 09:30:50 "hey see i have this checkout here please would you use that" is the externalsrc case. the case to be avoided unless, as i already told you, you are working on source and recipe at the same time. Mar 04 09:31:38 ok so I should SRC_URI point to the git repo Mar 04 09:31:47 how would that work with authentication? Mar 04 09:31:48 EEEEEEXACTLY Mar 04 09:31:58 I don't want to hardcode u/pw Mar 04 09:32:32 i'd really suggest to hardcode them for now until you get your recipe technically working. just don't commit it in the meantime Mar 04 09:32:41 see also https://wiki.yoctoproject.org/wiki/Building_your_own_recipes_from_first_principles#Build_an_example_package_based_on_a_remote_source_archive Mar 04 09:34:36 https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#git-fetcher Mar 04 09:34:47 or just grab a tarball, or whatever Mar 04 09:35:02 but hardcoding externalsrc into the recipe is the totally worst case Mar 04 10:00:56 SimoneNascivera - I just tried to resize "root" partition with external Ubuntu machine. Now the image does not boot up :( Mar 04 10:01:18 I don't think that is the way to enlarge root partition Mar 04 10:04:23 Maybe anyone else here knows how to to enlarge root partition of ready image? (RPI3 if it matters) Mar 04 10:05:14 Its original size is only about 700MB and there are about 15GB free on the micro sd card Mar 04 10:10:18 Hello, Can someone point out why this recipe is failing https://pastebin.com/QGJGZw9M ? I included the error which i assume is related to do_install function but I cannot see what would cause this error Mar 04 10:13:40 willie: i think it should be install from ${S}, not from ${WORKDIR} Mar 04 10:13:44 but might be mistaken Mar 04 10:13:59 LetoThe2nd: I'm checking out a git repo, added a subpath param to only check out the relevant path, in the workdir it only took the deepest dir and not the entire subpath Mar 04 10:15:20 Skye7707: so the problem is...? Mar 04 10:16:39 why? I expect either the content that gets pulled from git either in ${WORKDIR} or ${WORKDIR}/path/to/subdir, but it is in ${WORKDIR}/subdir (it ommits the higher dirs) Mar 04 10:17:37 Skye7707: i can't give an answer to the why in this case, as i've never used git subdirs in such a context Mar 04 10:17:45 iok Mar 04 10:17:46 ok Mar 04 10:23:01 LetoThe2nd: Tried got same error. I can see the script under tmp/build so that line "should" be ok. Could it be something else I'm missing? Mar 04 10:24:08 willie: ah wait. i misread. the message indicates that the package is not found altogether Mar 04 10:24:42 willie: what happens if you explicitly bitbake ked-project-start Mar 04 10:25:17 It builds Mar 04 10:25:39 :o Mar 04 10:25:45 willie: and have you also checked which packages it produces? Mar 04 10:27:19 The "package" directory is empty if that is what you ment, the script ends up directly under ked-project-start/1.0-r0/ Mar 04 10:28:55 willie: that indicates that the recipe gets built, but bitbake doesn't know about anything it should install and therefore does not build a package. hence, nothing to be found Mar 04 10:29:09 willie: i'm pretty sure you need to extend FILES_${PN} Mar 04 10:29:23 to include those two files Mar 04 10:33:37 LetoThe2nd: Something like "FILES_${PN} = "${WORKDIR}/ked-project-start.init? Also how does bitbake dont know what to do when there is a do_function? Mar 04 10:33:46 Does that not imply SRC_URI is wrong? Mar 04 10:37:56 I mean, i give it source files tell it what to do and it tells me it does not know what to do. Mar 04 10:38:25 willie: hum, no. Mar 04 10:38:38 willie: bitbake knows "here, this is do_install, execute it" Mar 04 10:38:57 willie: it does *NOT* look at every command inside to guess what you meant by it Mar 04 10:39:41 willie: so, if you don't give other defaults i think it packages /bin, /usr/bin, /usr/lib and some more generic locations. if you install to those, no more actions are needed. Mar 04 10:40:05 willie: if you install to other special locations, you have to explicitly tell bitbake to include those in the package Mar 04 10:40:29 willie: and SRC_URI on the other hand has totally nothing to do with what gets packages and what not. Mar 04 10:43:15 LetoThe2nd: Yes but the problem is that it does not find the .init file correct? And you are saying FILES_${PN} will include it Mar 04 10:43:24 willie: no Mar 04 10:43:34 I dont understand how I have such a hard time understand this xD Mar 04 10:44:04 willie: i am saying that bitbake does not see anything in the locations it expects the outputs of the recipe to be. and when it finds nothing, it packages nothing Mar 04 10:44:35 willie: so, by extending FILES_${PN} you are basically saying "add this to the package" Mar 04 10:45:31 willie: and pathes in FILES_ are rootfs-relative. see http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/ufw/ufw_0.33.bb#n45 Mar 04 10:45:35 for an example Mar 04 10:51:14 LetoThe2nd: Can you send that link again? my browser crashed :< Mar 04 10:51:56 http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-connectivity/ufw/ufw_0.33.bb#n45 Mar 04 10:52:01 Thx Mar 04 11:15:14 LetoThe2nd: I added : FILES_${PN} += " ${sysconfdir}/init.d \ ${sysconfdir}/init.d/ked-project-start/* \ ${datadir}/ked-project-start/* " But still gives the same error Mar 04 11:16:01 Willie2: well did you actually *CHECK* that the package gets created and contains what you expect? Mar 04 11:17:56 It is still empty, i also tried to compile only that recipe Mar 04 11:18:06 it still builds but nothing gets added into package Mar 04 11:19:00 Willie2: then you are still going wrong somewhere with FILES and do_install Mar 04 11:20:09 hmm Mar 04 11:20:37 if you get files-not-packaged then you've a problem with FILES. if you don't get that then you're not installing in do_install correctly. Mar 04 11:22:20 rburton: I'm getting : "ked-project-start not found in the base feeds" Mar 04 11:23:17 rburton: and i diagnosed that his recipe builds, but no package is created Mar 04 11:57:40 kanavin: mind if I do http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=92d3f6216ed981e761f104a7d83b4c68b8363a21 ? Mar 04 11:57:55 kanavin: also, we'll have to exclude debian 8 from the test, I can't get it to work :( Mar 04 12:05:28 RP: I don't mind, but it's virglrenderer, without the 't', and the other test (the headless one) needs a similar fix Mar 04 12:05:42 RP: did you install a more modern mesa from the backports? Mar 04 12:05:47 kanavin: yes Mar 04 12:05:52 kanavin: different failure :/ Mar 04 12:06:34 RP: :( I was hoping it would fix things. Debian 8 should be removed from the builders anyway, in my opinion. Mar 04 12:07:37 kanavin: oops on the typo, well spotted. Initially I was wondering how it could have worked but I can now I look at the patch Mar 04 12:07:51 yeah, it just add the needed option always Mar 04 12:08:57 RP: btw, people are excited about this stuff here. They want to run the various Daimler-produced UIs directly. Mar 04 12:09:21 kanavin: that is cool. I think this is very useful, we just need to be careful about breaking existing users Mar 04 12:09:22 directly, as in, directly on their desktops/laptops, yet within a full target environment Mar 04 12:09:38 kanavin: makes sense, there has always been a good use case for this Mar 04 12:11:10 RP: I'm itching to show you the demo videos I made, but they kind of have 'propritetary' stuff in them Mar 04 12:11:48 it's not just a spinning cube, but rather full car UI, with correct high resolution, mouse support, etc. Mar 04 12:15:25 ad emo of something useful? Mar 04 12:16:14 . Mar 04 12:16:44 there's a kmscube demo, but it's not as fancy https://www.youtube.com/watch?v=0YBuku3JESc&feature=youtu.be Mar 04 12:19:56 Crofton: demo != useful, as you should know Mar 04 12:30:03 LetoThe2nd: still having some trouble, I also think we misunderstood each other, currently when I do the list package command, I get the files that I want to be in the image, however what I want to achieve is to have the .a and .h files in the SDK package, afaik those are 2 different things? Mar 04 12:33:05 Skye7707: nope, because when you actually finished your recipe properly, the sdk builds from this Mar 04 12:36:16 ok, so I figure I need to add the .a files in the do_install part? Any predefined var that is close to where I want them? i.e. in the sysroot /opt/yogurt/i.MX6-PD15.3.0/sysroots/cortexa9hf-vfp-neon-phytec-linux-gnueabi/usr/lib Mar 04 12:37:20 .a go into $libdir just like .so Mar 04 12:37:39 Skye7707: nope, once everything builds fine, stick to the canonical rootfs locations Mar 04 12:38:00 so how would the install cmd look like? Mar 04 12:49:51 looks like I'm still missing some bits and pieces of the puzzle then Mar 04 12:50:42 adding something to the target image works but adding .a/.h files in the SDK, not sure how Mar 04 12:54:13 kanavin: the oe.lsb check in the runtime virgl.py test is wrong :( Mar 04 12:54:41 kanavin: its a permanent exception as you need to import oe.lsb, not oe Mar 04 12:55:22 kanavin: any idea which exception you really wanted to capture there? Mar 04 12:58:00 kanavin: I've tweaked http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next&id=22bfa6db5441792f75d720b2854d800244199b01 Mar 04 13:20:01 RP: I am not sure about the exception, I thought I basically copy-pasted code from elsewhere but can't find that elsewhere :-/ Mar 04 13:22:00 RP: ah, I found that code: check_supported_distro() in sanity.bbclass Mar 04 13:22:30 RP: how did the test skipping on centos 7 work? or maybe it didn't, which means we don't need to skip? Mar 04 13:34:21 RP: the fixup is fine, except the centos bit which may be unnecessary Mar 04 13:43:20 what does "unparsed line: 'SRC_URI = "file://cameraOptions.json'" mean when building a recipe Mar 04 13:45:00 black_13: same as the last time you asked Mar 04 13:45:29 i dont believe i ask that question Mar 04 13:46:49 http://codepad.org/BVRhCyUo is the code for this Mar 04 13:48:24 black_13: you need a \ at the end of the lines Mar 04 13:48:42 its sh-style \ to continue over multiple lines Mar 04 13:48:54 black_13: you asked the "almost" same question, last time it was different quotation marks Mar 04 13:49:53 but you acted exactly the same in both cases Mar 04 13:50:50 black_13: *sigh* sorry. but its really not your first time here, and i kinda expected that by now you would know the basic syntax. my bad, won't happen again. Mar 04 13:51:08 im sorry as well i have a lot on my plate Mar 04 13:51:18 and not everyone learns at the same rate Mar 04 13:51:45 I am making an effort and when I come here its after exhausting google and the texts I have Mar 04 13:52:40 black_13: try the bitbake manual https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#line-joining Mar 04 13:52:52 second section under "basic syntax" Mar 04 13:52:57 thanks Mar 04 13:53:16 basically the lines are python(ic) Mar 04 13:53:29 ... and looking at other recipes, theres lots and lots of them. poky and meta-openembedded have examples for almost everything. Mar 04 13:53:49 I started on this about 2 weeks Mar 04 13:53:51 ago Mar 04 13:54:25 and again not everyone learns at the same rate. Mar 04 14:05:12 How to enlarge root partition of image? I tried to extend it with external Ubuntu machine and now the image does not boot up Mar 04 14:06:05 I tried to add value to IMAGE_ROOTFS_EXTRA_SPACE inside bitbake.conf and after writing the image to micro sd-card - again, the machine does not boot up Mar 04 14:15:41 RP: somehow, 'import oe; oe.lsb.distro_identifier()' works fine here - maybe a python 3.6 innovation? Mar 04 14:15:49 kanavin: I'm not sure if the centos bit is needed or not, I suspect it hasn't worked Mar 04 14:16:06 kanavin: or oe.lsb was imported somewhere else in that context Mar 04 14:16:07 ? Mar 04 14:16:18 could be Mar 04 14:16:50 would be good to establish whether the centos bit is really needed, but I did see it fail a few times there Mar 04 14:17:21 kanavin: oh, I think I fixed that by installing missing bits on our servers Mar 04 14:17:33 kanavin: I'll drop it? Mar 04 14:17:57 RP: yes please :) I want to minimize all the special-case code Mar 04 14:19:14 kanavin: agreed. That leaves us with the debian 8 one but that has a finite life Mar 04 14:19:54 yeah, debian 9 works fine, and one could argue debian 8 is already EOL Mar 04 14:20:14 * LetoThe2nd bites keyboard hard to not make "case-sensitive" jokes Mar 04 14:21:05 RP: any idea why the headless test isn't able to run? (specifically, /dev/dri/ doesn't have render* entries) Mar 04 14:21:21 on the AB, all of them it seems Mar 04 14:21:58 kanavin: the AB workers have minimal installs so either something is missing or its permissions? Mar 04 14:22:13 kanavin: I've not see that run anywhere Mar 04 14:22:48 RP: the test does print the content of /dev/dri when it skips itself, and the files seem simply missing Mar 04 14:23:11 kanavin: kernel modules not loaded? Mar 04 14:23:15 which is odd, I thought either /dev/dri should be either fully populated, or altogether empty Mar 04 14:23:22 kanavin: I know little about this tbh Mar 04 14:24:22 same here, could be a missing kernel module, but I can't say which one Mar 04 14:28:17 kanavin: which files are present and which driver are you using? Mar 04 14:28:57 JPEWhacker, alexander@alexander-box:~/development/poky$ ls -l /dev/dri Mar 04 14:28:57 total 0 Mar 04 14:28:58 drwxr-xr-x 2 root root 80 Mär 1 14:42 by-path Mar 04 14:28:58 crw-rw----+ 1 root video 226, 0 Mär 1 14:42 card0 Mar 04 14:28:58 crw-rw----+ 1 root video 226, 128 Mär 1 14:42 renderD128 Mar 04 14:29:52 using nouveau here, but another laptop has intel/nvidia combo, and it's same except there are two cards and two render* files Mar 04 14:31:38 RP: the kernel driver should be called 'drm' Mar 04 14:32:37 kanavin: that looks correct to me... Mar 04 14:33:01 JPEWhacker, we are trying to figure out why on the autobuilder card0 is present but renderD128 is not Mar 04 14:34:08 ah. which driver is it using? Mar 04 14:35:08 I don't know, I thought the drm driver should set everything up without extra fuss Mar 04 14:35:19 I can't run commands on the AB Mar 04 14:36:17 kanavin: pokybuild@debian8-ty-1:~$ ls /dev/dri/ Mar 04 14:36:18 card0 controlD64 Mar 04 14:36:41 RP: that's debian 8, how about debian 9 :) Mar 04 14:36:55 ah. IIRC the drivers have a little more control over the behavior than that Mar 04 14:37:05 kanavin: same Mar 04 14:38:41 * RP is pleased to now have a multiconfig selftest Mar 04 14:40:17 RP: it might be that the hardware is something odd that wouldn't support that. what does lspci -v say? (on deb 9, to be sure :) Mar 04 14:40:20 here, I get: Mar 04 14:40:21 41:00.0 VGA compatible controller: NVIDIA Corporation GP108 [GeForce GT 1030] (rev a1) (prog-if 00 [VGA controller]) Mar 04 14:40:21 Subsystem: ASUSTeK Computer Inc. GP108 [GeForce GT 1030] Mar 04 14:40:21 Flags: bus master, fast devsel, latency 0, IRQ 68, NUMA node 1 Mar 04 14:40:21 Memory at ec000000 (32-bit, non-prefetchable) [size=16M] Mar 04 14:40:22 Memory at d0000000 (64-bit, prefetchable) [size=256M] Mar 04 14:40:24 Memory at e0000000 (64-bit, prefetchable) [size=32M] Mar 04 14:40:26 I/O ports at e000 [size=128] Mar 04 14:40:28 Expansion ROM at 000c0000 [disabled] [size=128K] Mar 04 14:40:30 Capabilities: Mar 04 14:40:34 Kernel driver in use: nouveau Mar 04 14:40:36 Kernel modules: nvidiafb, nouveau Mar 04 14:41:06 RP: multiconfig needs better 'promotion' :) Mar 04 14:41:40 kanavin: bingo. Its a server. It only has a Matrox Electronics Systems Ltd. G200eR2 Mar 04 14:41:57 according to https://01.org/linuxgraphics/gfx-docs/drm/drmExternals.html, the driver gets a control node automatically, but must explicitly say it supports render nodes Mar 04 14:42:01 RP: right, that sounds esoteric Mar 04 14:42:04 kanavin: no decent gpu in there Mar 04 14:42:37 kanavin: nice things like multiple 10GBit ethernet cards but no gpus Mar 04 14:42:58 "The G200 is a 2D, 3D, and video accelerator chip for personal computers designed by Matrox. It was released in 1998. " Mar 04 14:43:15 kanavin: now common in servers Mar 04 14:44:23 Kernel driver in use: mgag200 Mar 04 14:45:56 ya if that driver does not have the DRIVER_RENDER capability, it won't get a render node Mar 04 14:46:24 Also, mesa won't support it in any case: https://www.mesa3d.org/systems.html Mar 04 14:47:11 I guess the gtk test renders via mesa's software renderer, and the headless test does require a render node, so it won't run :( Mar 04 14:47:16 kanavin: of we find the budget for a server refresh I'll mention this as something to keep in mind (halstead ^^^) Mar 04 14:47:31 kanavin: right Mar 04 14:48:00 kanavin: we are due a hardware refresh which has been postponed due to budget issues Mar 04 14:48:15 kanavin: why does headless require host rendering support? Mar 04 14:48:42 kanavin: right now I don't even know if I have a job beyond the end of the month for budget reasons :/ Mar 04 14:49:16 JPEWhacker, qemu with -display egl-headless wants to open /dev/dri/render* and will refuse to continue otherwise Mar 04 14:49:53 RP: yes, it's unbelievable :-/ I think all the companies using Yocto are oblivious to the fact that there is no 'corporation' behind it Mar 04 14:50:26 kanavin: is there just a "headless" option that would force SW rendering? Mar 04 14:51:22 JPEWhacker, nope as far as I know Mar 04 14:53:23 kanavin: hoepfully with multiconfig bugs fixed and a testcase we can start to see people using it Mar 04 14:53:33 kanavin: -display=none ? Mar 04 14:54:11 says it keeps the GPU device, but doesn't do anything with the output Mar 04 14:54:36 JPEWhacker, we generally want to see the output :) egl-headless+publicvnc allows you to see it Mar 04 14:57:35 publicvnc running on the guest is different than the -display=vnc option in qemu I take it? Mar 04 14:58:45 * RP ponders what else need to be sorted for 2.7 M3 Mar 04 14:59:07 * zeddii is working on the new libc-headers and kernels. Mar 04 14:59:31 zeddii: was just thinking about that. qemuarm changes too. Need to have another try with those Mar 04 14:59:58 JPEWhacker, no, but -display none means there is no 'virtual drm-capable card' available to the qemu guests Mar 04 15:00:12 that kind of card is enabled with egl-headless, gtk or sdl Mar 04 15:00:32 just made it through the patch refresh/delete for the headers, building musl and then will generate 5.x -> boot qemu. Mar 04 15:01:59 RP: adding -src packages. should have patch later today Mar 04 15:03:15 JPEWhacker, just checked, with -display none you get '[ 0.357356] [drm] virgl 3d acceleration not supported by host' Mar 04 15:03:26 JPEWhacker, egl-headless, gtk and sdl all allow that Mar 04 15:05:27 kanavin: right, you won't get actual 3d acceleration with none, but you do get the drm nodes in the guest Mar 04 15:06:02 mess just does it all in SW Mar 04 15:06:24 JPEWhacker: thanks, that should make it in then :) Mar 04 15:06:42 zeddii: when the headers are ready I'd take that since that is a rebuild the world build Mar 04 15:07:19 ack’d. I was thinking that as well. I’m doing core-image* for the arches for both glibc and musl and then will send it. Mar 04 15:07:40 lttng is of course blowing up on 5.x, but I won’t pend non related things on that getting sorted. Mar 04 15:08:28 JPEWhacker, right, but that'd be very slow wouldn't and you won't be able to see the output Mar 04 15:08:59 zeddii: I improved lttng-tools ptest so its working fairly well now Mar 04 15:13:12 kanavin: ya it would be slow. I thought you were trying to find a headless option that worked regardless of acceleration for the AB... maybe I was mistaken Mar 04 15:13:46 JPEWhacker, I just checked with gtk frontend, even kmscube becomes 10 times slower :) Mar 04 15:14:43 JPEWhacker, I thought you were trying to find an accelerated headless option that wouldn't require presence of render nodes :) Mar 04 15:14:58 anyway, non-accelerated stuff is not really usable :-/ Mar 04 15:17:30 JPEWhacker, we want to test specifically accelerated headless configuration Mar 04 15:18:27 kanavin: ya makes sense. unaccelerated is not a very good test of virgl :) Mar 04 15:18:29 if that cannot be tested I'd rather skip the test than switch to non-accelerated software-only version Mar 04 15:22:03 RP: there are six patches left http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/qemu-split-virgl-gtk - how should we handle them? Mar 04 15:22:24 host libsdl removal can be dropped, I don't have any strong opinions Mar 04 15:22:44 virglrenderer and glx by default would be good to have Mar 04 15:23:08 I guess 'local.conf.sample: enable gtk+ frontend in addition to sdl' is the most controversial :) Mar 04 15:23:21 as it not only enables it but also makes it default Mar 04 15:23:35 but that's the upstream choice Mar 04 15:31:51 kanavin: I think these may need to wait for now. virglrenderer and glx by default is going to add to the build time a fair bit and doesn't make much sense without changing the options Mar 04 15:32:24 kanavin: I don't mind changing the target options Mar 04 15:35:00 RP: sure, shall I resend the whole set and you'll cherry pick? Mar 04 15:35:39 kanavin: well, there is just one and it doesn't pick cleanly :/ Mar 04 15:36:31 also this should be okay to take I think http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=akanavin/qemu-split-virgl-gtk&id=34591e0558ad8d8d0fdbf2d7c5796f2d9247b6d8 Mar 04 15:41:18 kanavin: hmm. Took me a while to work out which confusion you meant... Mar 04 16:51:06 New news from stackoverflow: Is it possible to bitbake a layer without without building entire core? Mar 04 17:08:35 zeddii: I can't seem to get the 'KMACHINE_qemuarm ?= "qemuarma15"' that you described in your email working Mar 04 17:08:59 Is there a trick more than just ading that line and removing all references to qemuarm? Mar 04 18:07:27 jonmason: sorry, was on a call. So you not seeing qemuarm match your definition for qemuarma15 in the kernel-cache. I wonder if the regex is bad. Let me have a closer look at get back to you. Mar 04 18:19:41 To edit recipes, config, etc in Eclipse Mar 04 18:29:26 zeddii: I think I misunderstood. I was adding that string to the meta/recipes-kernel/linux/linux-yocto_4.19.bb. Should it be in the bsp/qemuarma15/qemuarma15.scc? Mar 04 18:32:41 khem: RP: I’m seeing this with musl, x86-64 and my 5.0 libc-headers. Didn’t see it with glibc. Have either of you seen this before ? Mar 04 18:32:43 https://pastebin.com/mBijfWWv Mar 04 18:32:49 jonmason: nope. that’s the right place for it. Mar 04 18:33:21 the KMACHINE variable is what is used to search for a match in the descriptions, so if it is set to qemuarma15 for qemuarm “MACHINE”, it should find your new one. Mar 04 18:33:24 will spark up a test here. Mar 04 18:33:58 with glibc, I’m up and booting with the headers: Mar 04 18:33:59 root@qemux86-64:~# uname -a Mar 04 18:34:00 Linux qemux86-64 5.0.0-yocto-standard #1 SMP PREEMPT Mon Mar 4 17:14:03 UTC 2019 x86_64 GNU/Linux Mar 04 18:34:30 zeddii: I see it immediately try to compile for the qemuarm (as it has armv5 in the compile flags) Mar 04 19:20:04 zeddii: can you add DEPENDS += "gnu-config-native" in meta/recipes-devtools/binutils/binutils-cross.inc Mar 04 19:20:15 zeddii:this seems to be a latent issue Mar 04 19:47:26 khem: trying that! thanks. I found old patches for depends ,etc, but they didn’t help. I’m rm -rf’ing on tmp, and will restart now. Mar 04 20:33:07 khem: congrats/thanks for bumping comcast up to platinum Mar 04 20:39:58 rburton: I think execs are hopeful and believe that project is valuable Mar 04 21:12:47 khem: it is very cool :) Mar 04 22:37:24 Hmm, do we have a script for sanity checking distro/machine configs yet? I know we have the layer compliance check, and ross has some extra insane checks, iirc.. I'm wondering about checks for distro/machine best practices beyond making sure appends use overrides Mar 04 22:37:53 I'm thinking things like don't *set* recipe PACKAGECONFIGS, otherwise upgrades that add new packageconfigs can change default behavior, instead append/prepend/remove Mar 04 22:47:40 kergoth: I haven't seen anything Mar 04 22:47:53 k, figured, was just curious Mar 04 22:47:59 zeddii: that is very strange to see, it shouldn't do that Mar 04 22:48:04 someday.. Mar 04 22:49:40 huh, i kind of forgot recipe_sanity.bbclass exists. i wonder if it still works. also it has a check that's no longer valid, it warns if PACKAGES is set for native Mar 04 22:54:12 kergoth: I left it around as there were some interesting ideas in it Mar 04 22:54:37 as well as some horrific things iirc Mar 04 23:08:56 it's definitely useful to run checks for recipe conventions, non-fatal stuff. perhaps better as a recipetool subcommand, though Mar 04 23:12:22 kergoth: yes, there are a number of things we really need to re-implement as commands Mar 04 23:12:40 kergoth: harder than it would first seem to run against all recipes for example Mar 04 23:14:01 kergoth: the upgrade code has parallelisation issues which bitbake tasks make easy, although bluelightning and I have a plan for that Mar 04 23:15:24 good point Mar 04 23:15:50 kergoth: I do want to do that, its just the APIs aren't quite as good as we thought :/ **** ENDING LOGGING AT Tue Mar 05 02:59:57 2019