**** BEGIN LOGGING AT Wed May 15 02:59:57 2019 May 15 07:17:53 require ${@bb.utils.contains('DISTRO_FEATURES', 'virtualization', 'meta-virt-default-versions.inc', '', d)} May 15 07:17:53 this fails, can't find the inc file. had to move them to the same directory May 15 07:18:09 http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/conf/layer.conf?h=thud May 15 07:28:13 if it fails, then it sounds like something is wrong with the BBPATH. the BBPATH will check the current directory first, and then fall back to searching the various locations.. May 15 07:28:27 where is that file in the layer? You may need to include the conf/... directory as well May 15 07:35:33 Shouldn't the require line specify the "conf/distro/include/" part too? Like line 32 in the same file? May 15 07:36:02 If it's in the same directory, then the line should just have the anem.. if it's in a different directory, then yes.. I usually include the full path from the root of the layer May 15 07:37:34 The inc file is in a subdir, so not in the same dir. But it feels a bit weird that this is broken without anyone else noticing? May 15 07:40:18 subdirectory of the current dir, then it's: include subdir/file.inc May 15 08:18:18 fray, it's not in the same dir, it's in distro/include May 15 08:18:45 I am using this from toaster, maybe it does something with the paths that commandline builds don't May 15 08:19:04 sometimes I feel like I am the only person on earth that uses toaster May 15 08:19:10 conf/distro/include/.... May 15 08:19:24 let me look at an example quickly, just a second May 15 08:19:36 fray: now i totally misread that as conf/disco/include. and wondered. d'oh May 15 08:19:59 wrlinux-common.inc:require conf/distro/include/wrlinux-distro-settings.conf May 15 08:20:07 that file is in conf/distro May 15 08:20:39 so yes something in conf/distro to include something in a further include directory needs a reltive path from the beginning of the layer... May 15 08:20:56 so meta-virtualization is quite central, and it even has it's own mailing list under yocto, and the code hasn't been changed in that file for ages in that area May 15 08:20:57 only files in the same directory appear to not require a specific path May 15 08:21:03 so I am thinking it works somehow from cmdline May 15 08:22:15 http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/conf?h=thud May 15 08:22:59 it does the full path elsewhere May 15 08:23:05 require conf/distro/include/virt_security_flags.inc May 15 08:23:05 @ line 32 May 15 08:23:23 so why doesn't it do it at line 41? May 15 08:24:54 At one point that file was in that directory.. it's a bug.. May 15 08:24:56 just fix it May 15 08:25:43 ok! is this layer dead or should I use something else? May 15 08:25:49 since it's not pickedu p May 15 08:26:01 no.. meta-virtualization is definitely used.. heavily.. May 15 08:26:50 the change was made only a few weeks ago.. it may be that nobody has noticed, since they're not using the top of tree.. May 15 08:27:02 but it's a bug, the path in the layer.conf needs to have the distro/include part May 15 08:27:10 lol typical my luck May 15 08:27:23 thanks for helping, I thought I was insane May 15 08:28:32 btw, how is make menuconfig done on swupdate in a toaster build ? May 15 08:28:55 do I have to cd into whatever dir toaster has generated and do it there? May 15 08:30:26 hm my bad, seems like that's not related to yocto build May 15 08:48:58 * eyalgal say hi to all May 15 08:50:32 anyone build a daemon service for yocto ? assuming i do not have systemd installed (RC scripts are used) how can i make sure my executable is respawn if it dies ? May 15 08:51:15 we tried /etc/inittab but it is problematic cause opther scripts on the way may hang it and i think it also didn't work. May 15 08:51:22 you will need to either use the sysvinit inittab directly to monitor the resource, or you will have to have your own monitoring tool.. May 15 08:51:29 this is one of the reasons why systemd was created was to solve this problem May 15 08:55:36 fray: since you're around this time of the day, surprisingly... yesterday you suggested streaming on kernel dev etc. anything specifically you have in mind? configuration, working with upstream, patches... ? May 15 08:56:19 Customer I'm currently visiting was interested in a presentation explaing how the Yocto Project handles it's kernel.. and then on a 'tour' of the linux-yocto(-dev), yocto-kernel-cache and the recieps that use them.. May 15 08:56:37 this is something I could do once I'm done with my current work trip.. kind of do an informal presentation, walk through May 15 08:57:04 (I'm in Finland right now.. next week in Ulm.. then finally back home) May 15 08:57:31 fray: ah, i get it. i was just trying to think along those lines, and while i'm happy to give it a shot its really not an area where i have significant expertise May 15 08:57:59 fray: ulm is nice :) May 15 08:58:02 I've already written the presnetaiton (about 10 slides), but it involves a lot of going out and showing things in context for people.. May 15 08:58:13 ya, I still need to book my hotel and get the DB tickets from Munich to Ulm and back.. :P May 15 08:58:30 DB tickets shouldn't be a problem, but the two hotels I've tried have been sold out so far May 15 08:58:31 * LetoThe2nd mentally pokes fray to get in front of a webcam and show it on twitch :) May 15 08:58:48 heh, then you actually pass by me in 45km distance May 15 08:58:51 remind me in two weeks.. I'd need to try to get OBS installed.. May 15 08:59:32 fray: if you need assistance in ulm, i'm sure i can get some local information at least. May 15 09:00:01 I should be fine at this point, since work is paying Taxi's are 'easy' :) May 15 09:00:34 I fly into Munich on Saturday afternoon, spend the night there, and then will get myself to Ulm on Sunday.. opposite on Friday of that week.. May 15 09:00:57 the other guy I'm meeting in Ulm is coming in from Stuttgart.. but that would have been a lot more expensive for the plane ticket.. :( May 15 09:01:04 otherwise he'll have a rental car May 15 09:01:25 fray: yeah, german transportation is a bit different when it comes to flying vs. trains May 15 09:02:09 fray: sister of mine is dating a guy from the us, and when they went on weekend vacation with a like 3hr drive, he went "3hrs? why aren't we flying there?" May 15 09:02:55 fray: if you got spare time in ulm, get up the münster May 15 09:03:28 last time I was there I drove by it a few times on the way to where I'm going.. ;) May 15 09:03:36 but thats been as close as I've gotten.. ;) May 15 09:03:41 fray: thanks May 15 09:04:27 fray: its really not super important. but nice if you want to be tourist for an hour, or so. May 15 09:06:09 fray: and, drink all the beers that are way too expensive in finland May 15 09:57:20 the people at the toaster mailing list told me to make a defect but what's a defect, and in what system is it specified? bugzilla? May 15 10:16:17 Ad0 if you are still here.. bugzilla.yoctoproject.org May 15 10:16:31 yes alive and kicking May 15 10:17:14 "Create a Toaster defect. I will create the patch, share that with the Toaster mailing list, and submit it to bitbake-dev. May 15 10:17:14 " May 15 10:17:31 yup.. that bugzilla is yoctoproject one May 15 10:17:45 thanks May 15 10:17:52 I will do the same for the meta-virtualization May 15 10:17:54 todays todo: "create a toaster defect" May 15 10:17:59 thanks! May 15 10:18:01 * LetoThe2nd heads to the kitchen! May 15 10:18:04 _) May 15 10:18:27 https://www.youtube.com/watch?v=IPoJtt3X5SA May 15 10:18:30 If you do create the meta-virtualization on, let me know the number and I'll comment on it May 15 10:18:51 kk May 15 10:25:27 (should have said this earlier.. if you create a patch and send it to the meta-virtualization mailing list, then there actually is no reason to open a bug... but a bug helps track the issue for us to work on if you are not otherwise able to.) May 15 10:28:12 ok, how should I send the patch, using the GIT method ? May 15 10:28:23 make a local commit and send it as a patch ? May 15 10:31:40 typically use git.. May 15 10:32:08 so edit the file, git add ; git commit -s ... fill out commit log.. then git format-patch ... and send the info to the mailing list May 15 10:32:12 meta-virtualization list is: May 15 10:32:17 meta-virtualization@yoctoproject.org May 15 10:32:41 I guess I have to subscribe first May 15 10:32:53 not sure.. you may have rto May 15 10:35:04 ok will try tonight May 15 10:35:05 :) May 15 10:41:59 I have an issue understanding what's actually included in my yocto build, I want to include stuff from multiple layers, do I have to search for a package in a layer to explicitly include it? or does it magically get included? May 15 10:42:25 packages built = packages included? May 15 10:44:06 think of each layer as a bucket of lego. Collectively you have all of the buckets (listed in conf/bblayers) available to you. Dependencies are what selets the pieces to use when you build.. May 15 10:44:19 ok May 15 10:44:45 bitbake, like make, is dependeny based.. so if core-image-minimal requires busybox which requires glibc.. you must have something in that 'bucket' that provides glibc, and busybox.. but what is providing it doesn't really matter May 15 10:45:02 there are image recipes and software recipes May 15 10:45:22 all recipes are 'equal' from a dependency point of view.. what is different is their output format.. May 15 10:45:43 image recipes will generally NOT build software, but will output some type of image.. while a software recipe will usually build software and output a package.. May 15 10:45:48 ok May 15 10:45:49 but the dependencies between then remain the same May 15 10:46:54 I want to build an image with the meta-swupdate as the "master" image I guess since I want the partition layout of that for a 2 partition update May 15 10:47:57 meta-swupdte is the bucket.. but the image is constructed from packages.. So your dependency (IMAGE_INSTALL) needs to specify some packages that meta-swupdate is capable of producing.. May 15 10:48:10 I've not use meta-swupdate, so I'm not sure what specific packages you may need to include in your image May 15 10:48:10 I built swupdate-image but it produced no output, while core-image-full-cmdline produced image files etc. May 15 10:48:35 ok May 15 10:48:38 ya, that is down to the layers and docs that come with it. Sorry I can't help you more on that specific item May 15 10:49:30 thanks, no problem May 15 10:52:12 a lot of the configuration is set with bitbake vars. so I assume EXTRA_IMAGE_FEATURES in the Toaster web to append it, is EXTRA_IMAGE_FEATURES_append = " xxxx" ? May 15 10:52:25 seems like _append is used to do += May 15 10:52:52 yes that should May 15 10:53:08 _append is a 'late' binding change to a variable.. after everything else has ben processed "do this".. May 15 10:53:10 i.e. May 15 10:53:13 A = 1 May 15 10:53:16 A = 2 May 15 10:53:20 at the end A equals 2 May 15 10:53:23 A = 1 May 15 10:53:28 A += 2 May 15 10:53:29 A = 2 May 15 10:53:33 again A equals 2 May 15 10:53:36 A = 1 May 15 10:53:44 A_append = " 2" May 15 10:53:51 A = 2 May 15 10:53:56 A will be "2 2" May 15 10:54:00 right May 15 10:54:02 since the _append is applied late May 15 10:54:11 I guess there is no other way to do += from within Toaster May 15 10:54:37 correct. since processing order is not ensured for various reasonable, you end up needing the _append to get what you usually want May 15 10:54:42 or is Toaster like you can do basic stuff there but you have to manually edit layer.conf as well May 15 10:55:07 right May 15 10:55:30 http://variwiki.com/index.php?title=Yocto_Build_Release&release=RELEASE_PYRO_V1.0_VAR-SOM-MX6 May 15 10:58:50 I wonder if it will accept something like this: SWUPDATE_IMAGES_FSTYPES[core-image-full-cmdline] May 15 10:59:19 nope May 15 11:00:29 just trying to follow this one - https://sbabic.github.io/swupdate/building-with-yocto.html May 15 11:29:31 maybe I have to make my own local layer and import it into toaster, and run it ? May 15 12:02:41 Hi guys! May 15 12:03:59 I'm wondering which is the best way to manage several projects based on the same board from the Yocto point of view... May 15 12:04:41 malanecora: sounds like the generic reason why one should have separate machine, distro and application layers :) May 15 12:06:21 Yeah, indeed May 15 12:06:31 so there is your answer! May 15 12:07:42 But I can't clearly see what should be separate from what May 15 12:08:05 :/ May 15 12:08:41 malanecora: the machine layer generally contains the kernel, bootloader, driver recipes that are tied to the hardware, plus the machine.conf May 15 12:10:14 malanecora: you can share a distro layer if the applications bear some resemblance in software, or you can have two seperate distro layers, or mix that into the application layer, there it depends a bit on the actual projects. May 15 12:12:50 LetoThe2nd: Hmmm...I see. So, even the slightest required modification in the kernel/device tree would force me to build up a new layer? May 15 12:18:04 malanecora: given a common board, such changes are rather rare once bring up is finished, right May 15 12:18:24 malanecora: i mean, you explicitly stated "same board" May 15 12:21:58 LetoThe2nd: You're right. I just wanted to know it...haha. Nevertheless, you may need to enable/disable some kernel modules or features for some project. May 15 12:24:26 malanecora: you can always to that through an append, if needed. May 15 12:26:42 LetoThe2nd: Suppose so May 15 12:27:10 LetoThe2nd: Regarding the distro layer, would it make sense to have just different images (each image with different packages) and keep the same distro? Since the applications would be similar, someway. BTW, I'm not really sure if I totally understand which are the limits of the distro layer. May 15 12:28:45 malanecora: it can be different images, technically of course. but then you'd have a commit in the repo if you modify one image, and see the commit for the other images too May 15 12:47:55 malanecora: distro and images are "orthogonal" concepts. in distro you configure 'behavior' for the entire build. you set variables that will impact every recipe that you build, or every image that you will build. in image recipe you only define which binary package you include. an image recipe doesn't impact how recipes are 'built'. May 15 13:20:51 LetoThe2nd, ndec : Thank you guys! May 15 13:21:42 LetoThe2nd: The vory same would happen if I have several distros, wouldn't it? May 15 13:26:33 malanecora: what doyou mean? May 15 14:15:11 'lo! I'm having problems with "-c devshell".. I've set my OE_TERMINAL to "tmux-new-window" but when the new window is spawned it says "sort: cannot read: /dev/fd/63: No such file or directory" .. For this shell, the pseudo stuff is in /dev/fd/20 and 21. May 15 14:15:24 Anyone come a across this problem? May 15 14:15:37 It's sumo, btw. May 15 14:30:59 LetoThe2nd: "but then you'd have a commit in the repo if you modify one image, and see the commit for the other images too" May 15 14:32:34 malanecora: you would only share the distro across projects if the projects are suited for it. in that case, it would totally be fine if you see the commit everywhere. May 15 14:33:37 LetoThe2nd: Oh, ok, I got it. I misunderstood the sentence. Thank you! May 15 15:15:27 New news from stackoverflow: Configuration of spi slave in device tree files for imx8 board May 15 15:22:20 * armpit sigh need to resubmit dropped patches May 15 15:23:07 armpit: ? :/ May 15 15:24:19 there where a few more qa patches that got dropped when pybootchart hit the brakes May 15 15:25:30 I think one needs to be re-factored as only part of the patch was taken May 15 15:25:55 btw, I figured out the ptest issue May 15 15:27:24 * armpit gives me a chance to double check and run on AB May 15 15:28:58 armpit: right, that patch needed major other work anyway :/ May 15 15:29:50 armpit: they are on my todo list to come back to is/as/when I can May 15 15:29:53 ah, I am General Custer so I don't deal with Major stuff ; ) May 15 15:30:17 armpit: ;-) May 15 15:31:52 well let me run through them again May 15 15:32:36 armpit: what was the ptest issue? May 15 15:32:38 btw. ptest, do we still wont one monolithic raw log or its it good enough that info is in the testimage.json? May 15 15:33:16 ptest: loop (ptest-runner) n- times... did not pass the test name May 15 15:33:32 armpit: currently we put the monolithic log and the individual logs in the json separately . I did plan to drop the monolithic log when we were sure we were getting sane results May 15 15:33:57 getting sane ptest results has taken a bit of work :/ May 15 15:34:51 I am now saving raw logs on a per test bases May 15 15:35:22 easier to find errors May 15 15:39:00 Hi, it's probably a dumb question but if I call bitbake by setting first an environment variable `MY_VAR=1 && bitbake image`. How can I read the value of MY_VAR from a recipe ? xx = ${MY_VAR} ? May 15 15:47:41 armpit: the code splits the logs out per test May 15 15:48:04 armpit: you can likely just rely on that instead May 15 15:48:06 RP, as parsed summary May 15 15:48:19 armpit: no, for ptest it wasn't a summary May 15 15:55:10 hmm, the raw log has a bit more info in it other than pass/fail May 15 15:55:30 FAILED: wget--O-overrides--P May 15 15:55:59 raw: May 15 15:56:05 FAIL: wget--O-overrides--P May 15 15:56:05 + test x '!=' x May 15 15:56:05 + mkdir foo May 15 15:56:05 + busybox wget -q -O index.html -P foo http://www.example.org/ May 15 15:56:05 wget: bad address 'www.example.org' May 15 15:57:03 seems helpful to me May 15 15:57:56 in anycase, dropping it from testimage.json seems like a good thing May 15 15:59:05 armpit: we need an overhaul of some of the logging in general :/ May 15 16:00:46 true May 15 16:06:04 RP, do we want the ltp tests in Warrior? May 15 16:14:00 armpit: probably not worth it? May 15 16:14:10 armpit: not sure May 15 16:22:31 hmm, need to clarify QA then May 15 16:50:17 armpit: I guess it if helps QA testing then yes, we should May 15 16:54:06 armpit: loving the ptest results in https://autobuilder.yocto.io/pub/non-release/20190514-14/testresults/testresult-report.txt :) May 15 16:54:51 84/43000 failures May 15 19:53:39 fray, that meta-virtualization problem, people have been missing it for an entire year? May 15 20:08:00 Hmm.... I need a -native recipe to depend on a -cross recipe... May 15 20:09:31 JPEW: that sounds wrong May 15 20:10:09 Yes, it does..... what I really want is diffoscope-native to be able to use the cross binutils as helpers May 15 20:10:42 JPEW: I suspect binutils-native might have enough cross-fu ? May 15 20:11:09 JPEW: at the back of my mind is the thought we may be able to have one binutils these days... May 15 20:11:39 JPEW: I guess I can't remember how we configure binutils-native May 15 20:12:23 hmm, ya maybe. binutils-native doesn't have the target named tools (e.g. "arm-linux-readelf")... maybe thats not so imporant with binutils these days and invoking the bare "readelf" is fine? May 15 20:12:43 JPEW: it depends which targets were configured into it May 15 20:13:23 * RP slowly seems to be simplifying the toolchain May 15 20:14:17 Ah, --enable-targets=all in the -native case for binutils.... that will work May 15 20:14:39 JPEW: I had vague memories of writing that May 15 20:15:46 RP: Well, I have the test working now; of 4119 packages in core-image-minimal, 720 aren't reproducible May 15 20:16:07 Most of those seem to be -dbg packages May 15 20:19:11 JPEW: having numbers is a great start! May 15 20:19:38 JPEW: I'm a little surprised the dbg packages are showing issues, I thought we had that sorted :/ May 15 20:20:29 RP: Ya, I haven't dug into to it too much. It wouldn't suprise me if it's some common core problem that fixes most of them.... trying to get diffoscope to decode the elf files will help significanly May 15 20:20:59 JPEW: you're using the reproducible bbclass right? May 15 20:21:06 Yep May 15 20:21:19 ok. Hopefully something simple May 15 20:21:29 regardless, would be great to have tests and numbers May 15 20:26:41 RP, JPEW, thats what I've seen too in my buildhistory, in particular e2fsprogs-dbg having some strange diff churn inbetween rebuilds May 15 20:28:45 a rename /sbin/.debug/mkfs.ext2.e2fsprogs -> ./sbin/.debug/mke2fs.e2fsprogs for no apparent reason May 15 20:39:25 kroon: On mine it apparently decided to rename /sbin/.debug/fsck.ext3 -> /sbin/.debug/fsck.ext2 May 15 20:39:51 kroon: the rename is probably just bad matching of the various symlinks or hardlinks May 15 20:40:22 those should be the same file hardlinked May 15 20:40:57 probably a determinism issue related to directory ordering in buildhistory? May 15 20:42:07 JPEW, yeah, think I've seen that one too May 15 20:44:26 e2fsprogs is a little unique in that it has a load of files which are all hardlinked May 15 20:48:02 RP: ... but we split those hardlinks across multiple packages? May 15 20:48:26 Specifically, e2fsck is in it's own package from fsck.ext2 May 15 20:48:37 Oh, wait its not May 15 20:49:20 Nevermind :) May 15 21:08:16 has anyone figured out a way not to get cikced out of the room every now and then to authenticate again? May 15 21:08:22 or am I the only one with this problem May 15 21:08:43 kicked* May 15 21:08:49 How often? May 15 21:08:55 about every week May 15 21:09:00 Ya me too May 15 21:10:02 I usually attributed mine to my CPU being too loaded from doing an overnight build May 15 21:26:22 aehs29: my client has an auth plugin... May 15 21:27:41 RP: ok I'll look into that May 15 21:34:03 seebs: I pushed those SPDX headers fwiw May 15 21:34:30 seebs: we could probably simplify further and drop the COPYRIGHT files now if we wanted as things are simpler May 16 00:39:31 After adding 'tools-sdk tools-debug' to EXTRA_IMAGE_FEATURES I can no longer login to my board with root/nopassword.. am I doing something wrong? **** ENDING LOGGING AT Thu May 16 03:00:30 2019