**** BEGIN LOGGING AT Wed Apr 29 02:59:57 2020 Apr 29 04:40:14 heh, besides above issues with ca-certs noarch, there are also issues using mc::pkg in different do_task[depends], as it checks there should be a single ":" in there... Apr 29 04:45:55 Task 'depends' should be specified in the form 'packagename:task' Apr 29 05:06:54 Good morning everybody! Can anybody confirm that yoctoproject.org is down? Apr 29 05:32:01 Chrusel, yes it is. the certs are being updated Apr 29 06:15:29 armpit: thanks for confirmation! Apr 29 09:47:02 halstead: hello there! Hope you're doing fine. I don't know if you're in charge of openembedded.org as well but there is a huge time difference between cloning with https and git protocol for meta-openembedded from openembedded.org. Apr 29 09:47:20 halstead: 1min30+ for https, <10sec for git Apr 29 09:49:40 qschulz: yes I'm the person who can fix that. Https should be comparable or faster. I'll look into it. Apr 29 10:28:55 denix: you need mcdepends for that Apr 29 10:40:27 morning fellas, is there a way to run cleansstate "recursively"?, i.e. remove everything from the sstate-cache that would normally be populated during the build task for the given recipe? Apr 29 10:45:29 no Apr 29 10:45:44 its very rare to need to cleansstate, what are you actually trying to do Apr 29 10:48:30 if you want to force rebuilds there are better ways Apr 29 10:49:24 the "Exection of event handler 'sstate_eventhandler2' in sstate.bbclass failed with a python traceback saying "ValueError: not enough values to unpack (expected 3, got 1)" Apr 29 10:50:15 indicates something might be wrong with the sstate-cache and was looking for a solution other than wiping the entire sstate-cache directory Apr 29 10:57:43 I'm having a weird issue when building one of my images. I have a base image which contains all the basic system sw, and then another image which requires the base image and adds just one recipe, our custom piece of software. But when I try to build the base image, it says that some recipes cannot be build because they depend or our custom software. Any idea how standard packages could have a dependency of Apr 29 10:57:50 our custom software? Apr 29 11:01:24 iceaway: make sure you're actually building the image you think you're building. Is there any underscore, uppercase letter or weird character in the image recipe filename? do both image have a completely different filename? Apr 29 11:01:59 iceaway: pastebin of the error message would be helpful Apr 29 11:04:11 qschulz: I'm sure its the correct image. I can build the image that requires the base image, but not the base image itself. Pastebin coming up.. Apr 29 11:06:42 https://pastebin.com/HDe3pHhf Apr 29 11:09:54 iceaway: bitbake -e kodkod-image-base | grep anpr-sw Apr 29 11:10:31 if nothing there, then bitbake -g kodkod-image-base and inspect the .dot file manually to find who pull the anpr-sw Apr 29 11:10:43 yeah the key is Apr 29 11:10:44 - nothing provides anpr-sw >= 9.1.2b3 needed by gstreamer1.0-plugins-good-jpeg-1.14.4.imx-r0.1.aarch64_mx8 Apr 29 11:10:55 did you patch gstreamer-plugins-good? Apr 29 11:11:14 and presuambly anpr-sw is your special sauce Apr 29 11:13:36 or libgdiplus0-4.2-r0.0.aarch64_mx8 (first problem listed) Apr 29 11:14:19 that sounds like part of meta-mono? Apr 29 11:22:44 qschulz: The first command gave me a PREFERRED_VERSION statement, which I use in my distro configuration to select the correct version of anpr-sw. Could that be the issue? Apr 29 11:23:04 Even if that recipe/package is not included it the image? Apr 29 11:25:14 rburton: Not touching gstreamer just including it in my base image. anpr-sw is our custom stuff, correct. Apr 29 11:29:44 iceaway: no Apr 29 11:30:49 bitbake -e libgdiplus0 | grep anpr-sw Apr 29 11:31:21 or bitbake -e kodkod-image-base | grep libgdiplus0 I don't know, but use -g for the image and look which package is pulling your anpr-sw Apr 29 11:31:58 you want to find who has anpr-sw on the right side of the arrow Apr 29 11:32:22 Will try to fire up something to view the dot-files. Apr 29 11:32:49 Never looked at .dot-files before, any good tool to recommend? Apr 29 11:35:42 iceaway: vim or emacs Apr 29 11:36:01 qschulz: ah, cool, I thought you needed some special viewer. Apr 29 11:36:21 iceaway: you could use `dot` but it takes ages to create a png from a .dot file Apr 29 11:36:51 and it's often barely usable (especially for an image) Apr 29 11:39:00 qschulz: vim worked fine. I cannot see anpr-sw anywhere in the recipe-depends.dot file though. Apr 29 11:40:02 This feels like one of those things that will feel SO obvious once I find it... Apr 29 11:44:07 iceaway: you did -g on the image recipe right? Apr 29 11:45:48 qschulz: yes, I copied your command: bitbake -g kodkod-image-base Apr 29 11:59:23 iceaway: let me guess: old version of yocto? Apr 29 12:01:13 and i'm guessing anpr-sw contains a custom libjpeg implementation? Apr 29 12:01:36 so gstreamer found that in the sysroot instead of libjpeg, and happily built against it Apr 29 12:02:40 rburton: yeah :( stuck with Sumo for the time being unfortunately. Apr 29 12:02:42 ah the auto-rdepends, good guess! Apr 29 12:03:31 iceaway: can you confirm that anpr-sw contains at least a libjpeg implementation? Apr 29 12:03:52 rburton: It may, I am not 100% sure what goes in that package it detail, it is provided to me by other developers in the company. Apr 29 12:04:03 Let me have a look" Apr 29 12:05:12 sumo has recipe specific sysroots so the prime cause of random build dependencies is gone Apr 29 12:05:39 so *somehow* this anpr is being selected as a provider when building gstreamer Apr 29 12:05:51 but as its a black box and you can't say more, that's all we can tell Apr 29 12:05:58 rburton: libjpeg.so is present in the anpr-sw package. Apr 29 12:06:09 Anyway to tell gstreamer to NOT use the anpr-sw one? Apr 29 12:06:27 fwiw, this is why black box recipes containing a pile of replacements is a bad idea Apr 29 12:07:05 presumably you have a anpr-sw PROVIDES libjpeg somewhere Apr 29 12:07:06 rburton: yeah, it's not by my choosing :) Apr 29 12:07:42 rburton: not in the recipe, it provides some other libs but not libjpeg. Apr 29 12:10:01 well i'd recommend that you 1) split anpr-sw up eg libjpeg-anpr and others, then each of those can PROVIDE=libjpeg, and your distro can do PREFERRED_PROVIDER to pick Apr 29 12:10:22 you can't do that at an image level but you can at the distro level Apr 29 12:10:31 as switching provider will rebuild gstreamer etc Apr 29 12:11:09 rburton: thanks a lot! I will look into that. Apr 29 12:11:22 eg meta-intel has a custom zlib which has more tuning for IA hardware https://git.yoctoproject.org/cgit.cgi/meta-intel/tree/recipes-core/zlib/zlib-intel_1.2.11.1.jtkv6.3.bb Apr 29 12:12:00 and the BSP picks that for target zlib use https://git.yoctoproject.org/cgit.cgi/meta-intel/tree/conf/machine/include/meta-intel.inc#n10 Apr 29 12:17:28 rburton: excellent, I will check those examples! Apr 29 12:39:22 Hi! I'm moving from thud to zeus. Unfortunately, it broke my custom class which inherit from core-image. This class mainly add a ROOTFS_POSTPROCESS_COMMAND which, during builds for production, use "systemd disable" to "disable" a tty (serial-getty@ttyS0.service). Apr 29 12:39:24 How should I prevent systemd-serialgetty to open the serial port? I believe that I should not touch to SERIAL_CONSOLES because SERIAL_CONSOLES is machine specific. Apr 29 12:46:38 gourve_l: i believe that systemd doesnt create that service by default anymore Apr 29 12:46:46 but you might want to check for yourself Apr 29 12:47:19 also, you might want to consider moving to dunfell, which came out some days ago :) Apr 29 12:50:18 I missed the dunfell release. dunfell is still in dev according to https://wiki.yoctoproject.org/wiki/Releases but I'll move to it Apr 29 12:52:23 hmm, maybe I will wait for a "Moving to the Yocto Project 3.1 Release" section Apr 29 12:52:35 in the yocto's manual Apr 29 12:55:29 milloni: the recipe systemd-serialgetty.bb (poky/meta/recipes-core/systemd/) seems to create the service for every tty defined in SERIAL_CONSOLES Apr 29 13:06:19 gourve_l: wiki updated Apr 29 13:07:34 gourve_l: also do you mean https://www.yoctoproject.org/docs/3.1/mega-manual/mega-manual.html#moving-to-the-yocto-project-3.1-release Apr 29 13:11:59 Ah, I look at the "current" manual that's why I missed it. (https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html) Apr 29 13:12:04 thanks for the link Apr 29 13:12:47 rburton: you might want to update "current" ^ Apr 29 13:13:18 New news from stackoverflow: dependency of one recipe over other recipe Apr 29 13:13:27 halstead: can you fix the /current/ documentation link to point at 3.1 instead of 3.0? Apr 29 13:14:44 Yes I can rburton. Apr 29 13:14:47 Thanks. Apr 29 13:15:17 gourve_l: ah apologies - i might have got it mixed up with another service Apr 29 13:15:29 why can you not change SERIAL_CONSOLES? Apr 29 13:16:53 because, if I'm right, I would have only 1 .ipk for systemd-getty but 2 different builds (my-image-dev.rootfs.ext3 with serialgetty@ttyS0.service enabled and my-image-build.rootfs.ext3 with serialgetty@ttyS0.service disabled). The content of the .ipk would be the content created during the last build Apr 29 13:18:44 i dont think that's necessarily a problem Apr 29 13:19:21 as far as i can tell, if you have two MACHINEs (-dev and regular), you will end up with 2 ipk's for systemd-serialgetty Apr 29 13:20:27 which should be fine unless you're insistent on having a single ipk Apr 29 13:20:40 rburton, Done. Apr 29 13:20:41 but that will limit the range of things you can do severely Apr 29 13:20:43 they are not 2 different machines Apr 29 13:20:53 otherwise, yes I would have done that Apr 29 13:21:27 ah, i see, so it's a single MACHINE and DISTRO but 2 different images? Apr 29 13:22:17 yes, with small tricks during the rootfs post process Apr 29 13:22:57 i would recommend using a separate distro or machine for dev builds Apr 29 13:23:13 otherwise you're severely limiting yourself in the range of things you can Apr 29 13:23:35 that seems to be the standard practice Apr 29 13:25:14 ok, so with standard practice you have something like build/tmp/deploy/my-machine-dev and build/tmp/deploy/my-machine-prod ? Apr 29 13:25:56 when i say it seems standard practice i just mean that this solution has been recommended to me by at least one person from the yocto team :) Apr 29 13:26:13 but yeah, that's what i would do Apr 29 13:27:09 another option that i have more experience with is having a separate layer that you switch on and off depending on whether you need a dev or prod build, but i found this solution very cumbersome and i dont recommend it Apr 29 13:28:42 i *think* (might be wrong about this) that yocto zeus/dunfell has a feature where it run a build for multiple machines at the same time which is very cool :) Apr 29 13:28:55 s/it run/it can run/ Apr 29 13:29:39 nice feature, I have to take a look at it Apr 29 13:30:26 but, with 1 machine for dev and 1 for prod, do you build the linux kernel 2 times, even if you have the same defconfig? Apr 29 13:32:18 i'm not sure Apr 29 13:32:48 my guess would be no, it will reuse sstate cache because the inputs are the same Apr 29 13:33:32 maybe it will re-run do_deploy etc but that should be negligible Apr 29 13:33:44 full disclosure: i dont know anything about sstate caching though Apr 29 13:42:00 thanks, I will do some tests. If the kernel is only built 1 time that would be wonderful because I already have 7 different machines and 4 "flavors" (dev, prod, test, demo). Apr 29 13:45:36 oh wow, yeah, that might get messy Apr 29 13:59:28 kanavin_home: -next looks better apart from the ubuntu1604 segfault :( Apr 29 14:02:10 Hi, is there a (simple) way to get an openssl binary into yocto? Apr 29 14:04:31 GeneralStupid: IMAGE_INSTALL += "openssl" in your image recipe Apr 29 14:06:57 milloni: it does not create a binary afaik Apr 29 14:07:18 ah Apr 29 14:07:34 in only deploys the shared library? Apr 29 14:08:56 it* Apr 29 14:09:04 GeneralStupid: wild guess, openssl-bin? Apr 29 14:09:49 qschulz: no -.- Apr 29 14:10:22 GeneralStupid: which version of yocto? Apr 29 14:10:38 openssl-bin works for me Apr 29 14:16:19 RP: I guess ubuntu 16.04 has to join the tarball gang Apr 29 14:16:32 and minimum gcc bumped to 6.x Apr 29 14:16:32 gourve_l: 2.6 i guess Apr 29 14:17:59 kanavin_home: but why? :/ Apr 29 14:20:09 http://dpaste.com/24J35TJ Apr 29 14:20:19 Its actually not true. I dont have any binary -.- Apr 29 14:20:47 GeneralStupid: openssl-bin is a package not a recipe. bitbake is for building recipes Apr 29 14:21:45 qschulz: this is really confusing me all the time Apr 29 14:23:36 recipe = a set of rules to build packages Apr 29 14:23:51 package = contains binary outputs Apr 29 14:24:26 a recipe can generate 1 or more packages one of these output packages can be same name as recipe Apr 29 14:24:32 hope that helps Apr 29 14:25:41 Where would a good place to add that package? Apr 29 14:25:49 GeneralStupid: in your image, with IMAGE_INSTALL Apr 29 14:26:45 GeneralStupid: also, DEPENDS is on recipes, RDEPENDS is on packages Apr 29 14:27:39 Ok :) Apr 29 14:34:20 Thanks this is working Apr 29 15:17:32 kanavin_home: since you like 'fun' problems, have you any ideas on the cmake/expat dependency problem? Apr 29 15:17:51 kanavin_home: I really don't like the patch proposed Apr 29 15:17:55 kanavin_home: I've push the SDL change to master-next in meta-mingw Apr 29 15:18:26 RP: regarding ubuntu 16.04, my best guess is that openmp parallel code in rpm is incorrectly compiled by gcc 5.x, and segfaults. Upstream has changed how it works quite a bit from my original patches. Apr 29 15:19:01 JPEW: thanks - that means the virgl enablement can proceed now. Apr 29 15:20:04 kanavin_home: that would explain it. I guess forcing the min version is easiest :/ Apr 29 15:20:50 RP: can I see where the cmake/expat problem is? Apr 29 15:21:00 ah, patch proposed Apr 29 15:21:51 kanavin_home: the patch explains it at least :) Apr 29 15:29:49 bootstrap is fun Apr 29 15:30:22 could just delay it by not switching to cmake for expat Apr 29 15:43:49 New news from stackoverflow: dependency of one recipe over other recipe [closed] Apr 29 15:44:08 rburton: that is what the patch does but it will mean two different versions of expat eventually Apr 29 15:44:35 yeah Apr 29 15:49:35 kanavin_home: should I go ahead and sent the patches for the gcc min version and adjust the autobuilder config? Apr 29 15:52:03 RP: I would first want to confirm that that would indeed solve the issue though, somehow. There is a chance it would still segfault even after gcc bump due to some other ubuntu-specific thing. Apr 29 15:53:16 some days i feel like we should give up and just require that an official container be used for the build, host support issues suck :) Apr 29 15:53:17 kanavin_home: how about we rerun this branch on the performance test worker with build tools temporarily applied there? Apr 29 15:53:57 kergoth: it is one of the values of the project, which makes this a tough one Apr 29 15:54:34 kergoth: there's definitely value in a known host setup Apr 29 15:54:38 yep, all the way back to the beginning it was a key feature, many other projects had more host requirements, specific distros, sudo, etc Apr 29 15:54:41 RP: yes, that should work Apr 29 15:54:45 still a pain in the ass though Apr 29 15:55:24 kergoth: it would be less of a pain, if old distros would be dropped more aggressively Apr 29 15:55:28 i do think there's more value in *not muckingw ith the user's host setup* than actually having to build on the same. using a wrapper with docker like pyrex makes the use of the container largely transparent Apr 29 15:55:42 kergoth: supporting multiple distros is not such a big problem in itself, if they're all reasonably recent Apr 29 15:55:53 kergoth: but some members want centos 7 or whatnot Apr 29 15:56:32 yeah, that's a pain. i used to have to carry like 12 extra bbappends in meta-mentor just for centos5 crap Apr 29 15:56:40 kanavin_home: we will be able to better do this now we have buildtools-extended Apr 29 15:57:12 RP: yeah, I tried that on centos 7, and it's pretty neat Apr 29 15:59:27 kanavin_home: test build running Apr 29 15:59:40 kanavin_home: gives us the best of both worlds, we can "support" old hosts but move forward more easily Apr 29 16:08:07 fyi openembedded developer happy hour: https://zoom.us/j/94557245630 Apr 29 16:09:53 mcfrisk: you do no corporate doesn't allow zoom? *scnr* Apr 29 16:20:28 neverpanic: I do, not using corporate things Apr 29 16:21:25 neverpanic: good to know our IT dept has little eyes and ears here too ;) Apr 29 16:23:33 mcfrisk: is comparing me to IT a deliberate or accidental insult? ;-) Apr 29 16:23:40 neverpanic: both Apr 29 16:23:55 I won't rat you out =) Apr 29 16:24:06 then join in the zoom thingy Apr 29 16:24:52 nope, busy doing GDP++ Apr 29 16:24:54 I had to unblock video from bios, fall back to distro kernel and install the scary .deb, but zoom works now Apr 29 16:32:37 is there a nice way to handle a postinst that depends on a service (my use case is docker and loading images into it) ... meta-openstack seems to just start postgres and wait for python-heat, but i'm concerned about if at some point there's a postinst for the dependent service and the start up mess that would ensue Apr 29 16:34:02 RP: good news, cmake has a copy of expat in its source tree, and an option to use it :) Apr 29 16:34:32 mcfrisk: thanks for postig here too! Apr 29 16:34:50 kanavin_home: that is horrible but would solve the problem I guess Apr 29 16:36:56 RP: only needs to be enabled for cmake-native, which is fine I think? Apr 29 16:45:43 kanavin_home: yes, good point. that helps Apr 29 17:45:06 Is there a way to control how the partitions are created with wks / wic? In creating an image with 5 partitions an extended partition is created as the 4th partition and two others are created within it. Is it possible to specify where the extended partition is created or switch to using GPT? Apr 29 18:11:39 updated bitbake and oe-core today and now i'm getting shitloads of 'server version is too old for client' messages Apr 29 18:11:46 hmmm Apr 29 18:51:49 and now i'm getting tons of attempted reconnects to the bitbake server, but this is non-persistent, so the auto-stated server must have crashed without giving any useful output? Apr 29 18:52:01 did something change in how bitbake clients and servers interact or are started recently? Apr 29 19:01:42 that sound new. if you can, could you open a defect? Apr 29 20:31:38 kergoth: check the cooker deamon log file as that should say what happened Apr 29 21:03:19 Hi, really basic question that I can't seem to find an answer for: how do I enforce a "tune" for a machine? let's say I "require conf/machine/include/tune-power9.inc" the defaulttune is ppc64p9le but I would like to force the new machine to use the ppc64p9 instead. Do I simply declare DEFAULTTUNE_mymachine = "ppc64p9"? Apr 29 21:14:56 answering myself: "DEFAULTTUNE = " in the machine conf does the job. Apr 29 21:16:28 at least seems to. tbh I find the name DEFAULTTUNE to be a bit misleading but ¯\_(ツ)_/¯ Apr 29 22:11:43 psrcode: that allows us to override the value correctly and keep a hierarchical structure for similar architectures and their features Apr 29 22:13:57 I was simply complexed with de "DEFAULT" part, i was expecting a "TUNE" parameter to set. Apr 29 22:18:43 psrcode: it all depends how you perceive it :/ Apr 29 22:18:49 yep Apr 29 22:19:20 as long as it works at the end of the day, I don't care much :) Apr 29 22:26:22 psrcode: yes you did it right way Apr 29 22:36:49 RP: thanks, I was able to use mcdepends successfully Apr 29 22:43:50 RP: btw, is there a way to use MC overrides w/o mcextend.bbclass? I see it adds a useful MCNAME variable as well. but it is via BBCLASSEXTEND. I wonder if w/o that class there's a way for recipe to determine it's being built w/ mc: prefix... Apr 29 22:45:48 denix: BB_CURRENT_MC iirc Apr 29 22:46:21 denix: but be careful since that would make the recipe MC specific Apr 29 22:48:56 RP: ok, BB_CURRENT_MC=default otherwise Apr 29 22:49:07 denix: right Apr 29 22:50:32 RP: this could work... thanks! Apr 30 00:56:59 hi , Im new in yocto , I have on question that maybe related to linux(not Only yocto). I build an Image and my board(PowerPC arch) boots up successfully , after booting I can see this output of "df -h" command : Apr 30 00:58:34 "/dev/root" 45M / Apr 30 00:58:52 devtmpfs 169M /dev Apr 30 00:59:11 tmpfs 208M /var/volatile Apr 30 00:59:30 tmpfs 208M /run Apr 30 01:01:04 I have a code that when I run It it needs more than 45M storage because of its database and Log files, and root partition become full very soon Apr 30 01:02:40 how I can increase this partition?????? I can decrese tmpfs partitions in fstab file! but I want to have more space in root , because my code use /myDir for example Apr 30 01:03:48 is there any one who explain my mistake or misunderstanding ?? Apr 30 01:08:04 when I define size of /dev/root in fstab, it doesnt any thing!!!!! **** ENDING LOGGING AT Thu Apr 30 02:59:57 2020