**** BEGIN LOGGING AT Wed Mar 06 02:59:57 2019 Mar 06 03:07:41 yep Mar 06 03:09:08 the snail in the hamster wheel instead of the hamster is a nice touch. Mar 06 03:14:15 right Mar 06 09:00:28 kergoth: nice :) Mar 06 11:45:39 JPEW, yes, but only today Mar 06 13:18:47 zeddii: looks like the runtime stap tests don't work on 5.x :( Mar 06 13:33:23 let's say i have a web server built in the image, buildroot-httpd, and i want to populate /srv/www with my content Mar 06 13:33:44 what's the right way of doing this? adding it in do_install_append feels wrong Mar 06 13:34:02 should it be a separate recipe Mar 06 13:34:03 ? Mar 06 13:34:29 varjag: have a recipe thats called "myfunkywebthing_1.0.bb" that installs everything, and itself depends on whatever httpd it is aimed at Mar 06 13:34:46 i see, thanks Mar 06 13:35:23 (busybox-httpd, not buildroot- ofc) Mar 06 13:36:44 varjag, we forgive you Mar 06 13:36:54 i do not. Mar 06 13:36:59 i am unfogiving Mar 06 13:37:04 * LetoThe2nd cranks up metallica. Mar 06 13:41:46 |..| Mar 06 14:03:51 RP: the qemuarm stuff works for you? Mar 06 14:06:35 jonmason: the qemuarm64 graphics does Mar 06 14:06:57 jonmason: I've not gotten to the a15 pieces Mar 06 14:07:19 jonmason: as such I'll merge the arm64 machine bits at least... Mar 06 14:07:32 jonmason: its tricky as we have the 5,0 kernel in the mix Mar 06 14:14:23 Question for the group: I'm using a SoM from a vendor that provides a yocto MACHINE definition but of course I' Mar 06 14:15:08 ...I'm adding my own hardware in addition. Is the typical way to implement this to create my own MACHINE based on the vendor's definition that adds my additional configurations/devicetrees/etc.? Mar 06 14:15:29 RP: okay, then I'll assume everything is fine. I'll open the bugs I mentioned in the 0/X patch then Mar 06 14:16:02 I've tried including the machine/*.conf file from my own MACHINE but some sanity checks and COMPATIBLE_MACHINE checks start to complain Mar 06 14:16:05 jtrimbl3: i personally would start with a copy of the provided file and then beat it into desired shape Mar 06 14:17:45 I'm getting a complaint from "OE-core's config sanity checker detected a potential misconfiguration: MACHINE=myprototype-imx6ul-var-dart is invalid. Please set a valid MACHINE in your local.conf..." Mar 06 14:19:02 well then probably is invalid` Mar 06 14:19:31 hehe yes but why Mar 06 14:20:02 jtrimbl3: no idea, thats not in the information you provided Mar 06 14:20:28 Ok, no worries. I can look into it -- just wanted to make sure that copying the machine config and making my own changes is the best practice. Mar 06 14:21:13 jtrimbl3: maybe you just dumped it at a non-canonical place, made a type, etc. Mar 06 14:21:16 check the obvious Mar 06 14:24:01 Since I'm basically taking the "upstream" machine and making changes I was starting by just saying "require conf/machine/imx6ul-var-dart.conf" at the top of the myprototype-imx6ul-var-dart.conf file -- any reason that shouldn't work? Mar 06 14:24:46 jtrimbl3: probably. Mar 06 14:25:03 and your file is located at conf/machine/... of a layer too? Mar 06 14:25:48 yes i made a new layer for it and put my file at conf/machine/myprototype-imx6ul-var-dart.conf Mar 06 14:27:34 jtrimbl3: wait. if you just require the original file, it does not change the machine name. Mar 06 14:27:48 jtrimbl3: so thats the very least thing you would have to do. Mar 06 14:28:47 ...methinks. Mar 06 14:28:52 not sure right now Mar 06 14:29:22 isn't the machine name just "MACHINE" (set to myprototype-imx6ul-var-dart in local.conf) which is what causes my .conf to be loaded anyway? Mar 06 14:30:16 or is there a separate "MACHINE_NAME" kinda like DISTRO vs DISTRO_NAME Mar 06 14:31:33 no, shouldn't be Mar 06 14:32:30 jtrimbl3: by the way, when doing WHAT bitbake complains? Mar 06 14:32:36 jonmason: looks like the graphics on qemuarm64 doesn't work with the 5.0 kernel :( Mar 06 14:32:46 jonmason: not looked at why as yet Mar 06 14:33:27 LetoThe2nd: When trying to run bitbake on any target (e.g. bitbake core-image-minimal) Mar 06 14:33:40 it doesn't even get as far as parsing the recipes it seems Mar 06 14:35:27 RP: in the recipe I gave you, I commented out the board mapping. If you uncomment that and try a rebuild, I'd be interested to see if it helps. I was running into a console boot issue with qemuarm, so I took it out for that initial 5.0 recipe. Mar 06 14:35:50 * zeddii tries to queue more patches. Mar 06 14:35:53 jtrimbl3: and if you change NOTHING besides switching the MACHINE back, it builds again? Mar 06 14:35:55 zeddii: did that apply for qemuarm64? Mar 06 14:36:03 ah. snap. sorry about that. Mar 06 14:36:15 just qemuarm would be impacted. Mar 06 14:36:32 so disregard my 'tip' :D Mar 06 14:36:49 LetoThe2nd: Yes -- I do nothing except change MACHINE= in my local.conf and it builds fine Mar 06 14:36:57 zeddii: :) Mar 06 14:37:07 once I get through my basic graphic boot test issues, I'll be able to help with that as well. Mar 06 14:37:07 I'm kinda wondering if maybe it expects that MACHINE must be of the form "*-*-*" Mar 06 14:37:17 zeddii: the old qemuarm, or did I screw something up? Mar 06 14:37:43 zeddii: qemuarm64 doesn't seem to boot at all on 5.0 :/ Mar 06 14:38:10 RP: I'd bet there is something needed in the config. Seems like some of the dependencies aren't always there :( Mar 06 14:38:45 jonmason: I did a quick diff of the defconfigs and nothing obvious Mar 06 14:38:48 I can take a quick stab at it, if you need the help Mar 06 14:39:24 jtrimbl3: i think something in your layer stack expects the machine to be imx6ul-var-dart, and can't build for your machine. Mar 06 14:39:30 probably the kernel Mar 06 14:39:58 jonmason: I'm sharing data at this point, not sure what zeddii is going to look at or where I'm at with anyting at all Mar 06 14:40:15 RP: i was able to boot it here (qemuarm64), let me go check it again. I'll summarize what is working in the series I'm about to send. Mar 06 14:40:20 no actually i'm just an idiot -- i accidentally did a remove-layer and forgot that it wasn't there anymore... Mar 06 14:40:42 aaaaah yes. Mar 06 14:41:11 notably, you get that error if it can't find the machine file in any layer at "conf/machine/${MACHINE}.conf" Mar 06 14:41:28 ok the world makes sense again Mar 06 14:41:34 thanks for humoring me, LetoThe2nd Mar 06 14:41:54 and it's good to know that i've got the general approach right Mar 06 14:42:32 RP: so to confirm, you are *not* able to boot even in nographics mode ? Mar 06 14:42:36 14:21 < LetoThe2nd> check the obvious ;-) Mar 06 14:42:36 root@qemuarm64:~# uname -a Mar 06 14:42:36 Linux qemuarm64 5.0.0-yocto-standard #1 SMP PREEMPT Wed Mar 6 05:07:25 UTC 2019 aarch64 GNU/Linux Mar 06 14:42:37 root@qemuarm64:~# Mar 06 14:42:50 not that "works for me" helps. I'm just trying to keep it all straight Mar 06 14:43:04 zeddii: sweet! Mar 06 14:46:01 zeddii: if I take out the -device VGA it appears to work Mar 06 14:46:39 jonmason, zeddii: trouble is I'm about to merge Jons changes to qemuarm64 after which it won't work for people with 5.x :/ Mar 06 14:47:36 hmm...can you confirm that the Bochs driver is in the kernel? Mar 06 14:47:54 CONFIG_DRM_BOCHS Mar 06 14:48:02 its possible a dependency is needed Mar 06 14:48:25 jonmason: yes, its in both Mar 06 14:48:30 :/ Mar 06 14:48:48 ahahah. and since I don't have it, that's why I'm up and running. Mar 06 14:48:49 hmm. Mar 06 14:49:01 maybe PCI isn't enabled Mar 06 14:49:28 zeddii: does lspci show anything? Mar 06 14:49:35 on the working one, that is Mar 06 14:50:10 * zeddii checks Mar 06 14:50:21 lspci isn't in my image :( Mar 06 14:50:46 the pci options do move in the defconfig, not sure if anything "went missing" Mar 06 14:51:05 rburton: RP: your branch ross/du did do the trick! Thanks also see bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=13216 for tracking this. Mar 06 14:51:06 Bug 13216: normal, Undecided, ---, richard.purdie, NEW , Failure on do_image_ext4 on zfs file system Mar 06 14:51:23 that's basically a dup of the other bug, one sec Mar 06 14:51:24 RP: is it jsut a black screen or is there nothing if you add serialstdio? Mar 06 14:51:41 jonmason: black screen and nothing appears on the network Mar 06 14:51:48 heh. I don't have lspci either and I'm booting core-image-kernel-dev, I''m going to add it in and rebuild. Mar 06 14:52:38 psrcode: please add any useful comments to https://bugzilla.yoctoproject.org/show_bug.cgi?id=8430 and mark you bug as a duplicate Mar 06 14:52:41 Bug 8430: enhancement, Medium, 2.99, ross.burton, ACCEPTED , Inaccurate 'du' usage in image.bbclass:get_rootfs_size Mar 06 14:53:00 I have pciutils and usbutils by default, from debugging the graphics stuff :) Mar 06 14:53:03 ah, I searched for do_image_ext4 ... sorry Mar 06 14:53:11 zeddii: btw, Jon's patch pins qemuarm64 to 4.19, I undid that Mar 06 14:54:26 psrcode: good to know that branch fixes it. Wish I could remember why we didn't merge that Mar 06 14:54:39 psrcode: np Mar 06 14:54:47 RP: it broke other bits Mar 06 14:54:50 never got around to chasing Mar 06 14:55:16 RP: iirc it was triggering images which were at the time 3.999GB to be 4.1GB, and thus breaking hddimg Mar 06 15:02:30 rburton: ah :( Mar 06 15:06:00 jonmason, zeddii: ls /sys/bus/pc/devices does show things Mar 06 15:06:41 and bochs-drm in /sys/bus/pci/drivers Mar 06 15:06:45 i have a recipe that DEPENDS on gtk+. is there a command I can run to the recipe for gtk+ ? Mar 06 15:07:20 LetoThe2nd: I think I'm in good shape -- running with my own MACHINE config now. I tweaked MACHINEOVERRIDES and MACHINE_ARCH to look the way they did from the "upstream" machine, and had to .bbappend a few recipes in order to tweak their COMPATIBLE_MACHINE regexes, but that wasn't too bad. Mar 06 15:07:33 Thanks again for the help Mar 06 15:07:45 \o/ Mar 06 15:07:46 have fun Mar 06 15:30:20 the SDK contains all the crosscompilers, yes? Mar 06 15:31:05 will the crosscompilers be portable across different linux distributions? Are they statically linked even (is that possible)? Mar 06 15:32:33 Piraty: the sdk brings along a complete sysroot Mar 06 15:33:31 Piraty: (for x86 hosts, that is)... so it is *fairly* portable. its not guaranteed, and if you run into troubles we'll try to help and fix them. Mar 06 15:34:16 in specific: would the compiler i produce on a glibc based distro run in an alpine container (which uses musl libc)? Mar 06 15:34:40 try and find out. Mar 06 15:34:47 don't have one yet. Mar 06 15:35:09 but yeah, i can ping back about it. Mar 06 15:37:50 yates: i think you're missing some words, that sentence doesn't parse Mar 06 15:39:58 khem: if I want a commit from master to be backported, do I need to cherry-pick it on the stable branch, fix any merge problem and send it with the proper email prefix or only send the master patch as is with the correct email prefix? Mar 06 15:40:12 psrcode: backport/test Mar 06 15:40:55 okai, the wiki wasn't super clear on that. thanks Mar 06 15:47:55 is there a command I can run to find the that would be used for gtk+ in a given image build? Mar 06 15:48:08 arg! is there a command I can run to find the recipe that would be used for gtk+ in a given image build? Mar 06 15:48:25 the actual .bb file location, that is? Mar 06 15:48:40 yates: oe-pkgutil probably Mar 06 15:48:48 stupid question (could not find answer on the wiki or just bad at searching), what would a typical "test" run be for openembedded-core? full build with ptest? selftest? Mar 06 15:50:50 https://www.openembedded.org/wiki/Testing:TestBuilder ? Mar 06 16:08:29 psrcode, for example https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/293 Mar 06 16:09:12 ptest failures are generally non-blocking, but build failures, oe-selftest failures and testimage/testsdk failures are Mar 06 16:15:24 kanavin: okai, thanks for the info Mar 06 16:15:52 psrcode, one more thing, you can find the build configurations here http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json Mar 06 16:15:52 JPEW: why do we need that ALLOW_EMPTY for ${PN}-src ? Mar 06 16:16:08 JPEW: I know for -dbg packages its there for dependencies but -src doesn't need that? Mar 06 16:16:44 kanavin: does third party (me) have access to the autobuilder? Mar 06 16:16:51 @RP: Ah, ya I forgot that ALLOW_EMPTY means "the package still exists even if empty" not "don't error out if the pacakge is empty". I'll remove it Mar 06 16:17:19 kanavin: aren't you expected to be offline in vacation? Mar 06 16:17:41 JPEW: thanks, I think that will be neater Mar 06 16:17:49 kanavin: based on I'll go with no.. https://autobuilder.yoctoproject.org/ Mar 06 16:19:48 psrcode: no, we don't have the resources to allow user triggered builds :( Mar 06 16:20:13 psrcode: usually we ask contributors to run a subset of tests suited to the change they're making Mar 06 16:20:59 LetoThe2nd, I am technically at work today, vacation really starts tomorrow Mar 06 16:21:09 RP: so let's say I want to test the backport of the patch from Khem about the glibc stuff, what should I test (appart from lttng-ust working :P) ? Mar 06 16:22:29 psrcode: that one is hard since it affects practically everything. I'd probably just test a couple of machines build, bonus marks for -c testimage (image boot testing under qemu) Mar 06 16:22:42 psrcode: Its not reasonable for you to test all the combinations there Mar 06 16:23:00 kanavin: :-( Mar 06 16:23:05 psrcode: the good news is that it worked cleanly with master and I suspect will work cleanly with the other branches Mar 06 16:23:23 LetoThe2nd, I'm not actually doing work, just having a coffee :) Mar 06 16:23:50 okai, so I'll make sure to at least build a core-image-minimal and boot it play around a bit. Mar 06 16:23:54 thanks Mar 06 16:25:00 psrcode: sato would be better than minimal just so you have some runtime in it! Mar 06 16:25:16 ok Mar 06 16:26:01 RP: got ptest for lttng-tools runnning, now the fun begin :P Mar 06 16:27:49 psrcode: I'm waiting for you to find the ptest piece of the lttng-tools recipe and then running away screaming! ;-) Mar 06 16:29:17 kanavin: \o/ for coffee Mar 06 16:31:05 zeddii: I pulled the arm64 graphics change into master so we have a new goalpost for that... Mar 06 16:34:07 RP: nothing a good cup of coffee can't fix Mar 06 16:37:12 RP: ack'd. I just sent my series to the list as well. Mar 06 16:49:18 zeddii: I just pulled a base set into master, risk taking :) Mar 06 16:49:48 zeddii: not changed the defaults but gets us the headers changed, hence fewer rebuilds Mar 06 16:49:57 agreed. Mar 06 16:50:21 easier to get more eyes on things this way, just a simple local.conf mod to build it. Mar 06 16:50:42 so the remaining issues are the arm64/arm64 graphics and the stap issue ? Mar 06 16:50:49 well, all that we know of now ? Mar 06 16:51:00 I just updated my builders and set them to compiling again. Mar 06 16:52:06 I'm heading home to finish things from there, back in about 15 mins. Mar 06 16:52:57 zeddii: yes, those two and the KMACHINE qemuarm thing Mar 06 16:58:32 psrcode: I think do your testing and propose, for releases it will also need testing on Yocto AB Mar 06 16:59:06 khem: +1 Mar 06 17:40:49 i'm using matchbox for my window manager with a touchscreen LCD display. i'm finding windows with transparent components created using wxWidgets which work under desktop linux do not work properly under matchbox/yocto Mar 06 17:41:21 has anyone experienced this kind of problem? Mar 06 17:41:25 yates: turn on compositing in matchbox Mar 06 17:41:38 rburton: do you know how to do that? Mar 06 17:41:56 its an option to mb-wm Mar 06 17:42:02 thats all i can remember Mar 06 17:42:21 ah - good! Mar 06 17:42:26 so you have seen this before? Mar 06 17:43:52 no but youre describing compositing windows failing, and mbwm is non-composited by default Mar 06 17:45:20 on my version of matchbox-window-manager, compositing is apparently a compile-time option. https://paste.fedoraproject.org/paste/KPpHLzxJmfwzYh-gcO6Y9w Mar 06 17:45:39 thanks rburton! Mar 06 17:52:44 patches welcome to add a packageconfig Mar 06 18:02:11 rburton: well remembered! Mar 06 18:44:40 rburton: well remembered! Mar 06 19:02:02 hwo do i modify the ./configure options for a recipe using devtool? Mar 06 19:02:43 edit the .bb or .bbappend in your devtool workspace Mar 06 19:03:03 as you would do normally, via adding EXTRA_OECONF and stuff Mar 06 19:03:18 khem: you mean in your /src/... folder? Mar 06 19:03:44 devtool creates a workspace Mar 06 19:03:55 where it has src as well as recipes dir Mar 06 19:23:53 there is no "recipes" or "recipe" folder under my folder Mar 06 19:25:07 i usualy do devtool -modify and edit source files under the /src/recipe-to-modify folder Mar 06 19:27:15 but i don't know how yocto translates configure options from the .bb file to ./configure options. Mar 06 19:28:24 like khem says, just set EXTRA_OECONF in the recipe or appen Mar 06 19:28:35 devtool isn't going to completely avoid needing to edit recipe files Mar 06 19:29:00 damn, oe-selftests can take a while Mar 06 19:29:07 even just running one module Mar 06 19:31:05 kergoth: you mean the original recipe? as in poky/meta/... ? Mar 06 19:31:16 i.e., modify the original recipe THERE? Mar 06 19:31:18 i don't understand the question Mar 06 19:31:32 if the layer is under your control, edit it. if not, bbappend it. as you would to make any changes to any recipe, ever Mar 06 19:31:36 see the yocto project documentation Mar 06 19:31:41 14:28 like khem says, just set EXTRA_OECONF in the recipe Mar 06 19:31:51 EXTRA_OECONF Isn't special, it's just another variable for a recipe Mar 06 19:32:32 it would help to have accurate answers.. Mar 06 19:32:57 khem: also said there is a recipes directory in the "devtool" workspace. NOT!. Mar 06 19:33:40 yes, see the WWW too... Mar 06 19:35:01 it's somewhere in the universe Mar 06 19:39:56 appends/ attic/ conf/ README recipes/ sources/ Mar 06 19:40:01 workspace uses it Mar 06 19:40:06 for devtool Mar 06 19:43:09 if you have no recipes in workspace, then you never ran devtool modify. Mar 06 19:43:39 and complaining about the answers doesn't make them any less correct Mar 06 19:44:08 and https://www.yoctoproject.org/docs/?section=developer-manuals is not hard to find Mar 06 19:44:14 one click from the main project page Mar 06 20:20:41 Tartarus: missing maintainer for vim-tiny :( Mar 06 20:22:38 RP: whoops. Mar 06 20:22:47 What's the self-test to run to catch that? Mar 06 20:23:26 Tartarus: oe-selftest -r distrodata.Distrodata.test_maintainers Mar 06 20:25:43 thanks, running Mar 06 20:30:14 ERROR: gitsm: submodule unpack failed: UnpackError Unpack failure for URL: 'gitsm://github.com/arfoll/doxygen2jsdoc.git;protocol=https;name=doxygen2jsdoc;subpath=doxygen2jsdoc;bareclone=1;nobranch=1'. No up Mar 06 20:30:14 to date source found: clone directory not available or not up to date: /data/kergoth/mel/yocto/scriptutils-log-improvements/build.selftest/downloads/git2/github.com.arfoll.doxygen2jsdoc.git; shallow clone Mar 06 20:30:14 not enabled Mar 06 20:30:26 ugh. can't get the devtool tests to complete due to irrelevent fetch/unpack failures Mar 06 20:31:21 kergoth: annoyingly yates left :) Mar 06 20:31:34 ah, indeed Mar 06 22:42:35 zeddii: we're seeing a few failures on the autobuilder. qemuppc+qemumips failing in kernelmodule.KernelModuleTest.test_kernel_module in core-image-sato-sdk, qemuarm64 failing in perl do_compile :/ Mar 06 22:44:39 Tartarus: thanks for the patch tweak :) Mar 06 22:59:18 * kergoth kicks oe-selftest Mar 06 22:59:48 kergoth: careful, it might bite back! ;-) **** ENDING LOGGING AT Thu Mar 07 02:59:57 2019