**** BEGIN LOGGING AT Thu Jun 04 03:06:25 2020 Jun 04 06:51:42 zeddii: i'm seeing something interesting in warrior (maybe it's fixed now?) i'm enabling 'KERNEL_DEVICETREE_BUNDLE = "1"' and the kernel+dtb is showing up in ${DEPLOYDIR}, but packages-split/kernel-image-zimage-bundle is always empty Jun 04 06:52:01 zeddii: it looks like packages-split/kernel-image-zimage-bundle isn't getting populated? Jun 04 07:46:43 Hi Jun 04 07:50:06 I have a small recipe to add a file into the image folder that is then used by the image recipe to build the final image. That is working if I clear the shared sate cache but not using it and I would like to be sure to do it properly. Jun 04 07:51:12 finally we have a YOP anthem. And even an honest one! https://youtu.be/c4LNJfFjEvw?t=140 Jun 04 07:52:05 I copy the file during my do_install into DEPLOY_DIR_IMAGE and add a depends on this task in my image recipe. Is it the way to go or did I break the sstate that way? I'm a bit confused by the documentation and I don't know if I have to do something special for standard tasks to use sstate Jun 04 07:52:49 ykrons: you break sstate, essentially :) Jun 04 07:53:00 ykrons: never rely on anything to be in DEPLOY_DIR_IMAGE Jun 04 07:54:06 ykrons: if your image needs something, then it is essentially a DEPENDS Jun 04 07:55:34 Letothe2nd: good news I will learn something today! Jun 04 07:55:58 ykrons: i mean, what is this "file" actually? Jun 04 08:10:39 I started getting out of the blue "do_rootfs: No manifest generated from: X", how to get rid of that? Jun 04 08:32:39 ykrons: use do_deploy to deploy in the DEPLOYDIR (or the one with the underscore, I neevr know, check the manual). This makes it okay with the sstate-cache. Then your image task should depend on the deploy task of that recipe to make sure it's always there. Jun 04 08:33:24 Letothe2nd: it has some use for example with u-boot binaries. By default you want them in deploy dir but some people also want to use it ina wic partition for example Jun 04 08:33:40 in that case, not part of the rootfs, but still needed for the image.\ Jun 04 08:35:37 qschulz: neede for the image, yes, but that is wic as you said. the OP explicitly asked for something need by the "image recipe" Jun 04 08:40:10 Letothe2nd,: That file is an archive of the content of a "data partition". The image then picks that archive, transforms it in filesystem image and include it in the final image package (tezi toradex image that included several fs images) Jun 04 08:40:31 I think the need is similar to uboot Jun 04 08:42:41 ykrons: wait. is it part of the real rootfs-image (e.g. part of the filesystem), or is it only to be included in some form of binary blob output (like fitimage, wic, whatever) but does not affect the filesystem that the build created? that really makes a difference here, and as you explicitly asked about the *recipe* i assumed the former. Jun 04 08:47:26 Letothe2nd: Not sure what you mean by real rootfs-image. It is only files to be stored in the "data partition" that contains default settings and will be mounted at startup, but they will never be part of the fs mount as / Jun 04 08:49:59 ykrons: then the latter. Jun 04 08:52:07 ykrons: yet that sounds very much like a custom thing (that tezi), and as i dont know about it i can't/won't comment further Jun 04 08:53:42 :( but as you said, I can follow the logic used for uboot Jun 04 08:56:04 Maybe a clarification between the do_install and do_deploy. The install is to store files in the rootfs using $D andthe deploy is to store files in the image folder using $DEPLOYDIR. Uboot have an install and deply because it can store its files in both location, in my case is it find to just have a do_deploy that store files in DEPLOYDIR (inherit deploy and properly add the task) ? Jun 04 08:57:51 ykrons: it depends... is this "data partition" actually to be used in the rootfs (libraries, data files, binaries, etc...) or just misc stuff (like u-boot or kernel.. something that will not be used in userspace) Jun 04 08:58:27 because if it is, then it is technically part of the rootfs, just in a different partition. Use wic to separate those files from / and put it into /data or something. That's possible Jun 04 08:59:38 ykrons: you do whatever you want with your recipe, if it does not produce a package (and/or cannot be used as a DEPENDS by other recipes or RDEPENDS by other packages, only do_deploy seems fine to me but you might be trying to follow an antipattern) Jun 04 09:00:02 qschulz: do antipatterns anti-matter? Jun 04 09:00:43 Letothe2nd: too meta for me Jun 04 09:01:55 qschulz: it is data files that will be used by userspace applications, so that means I have to install them in the rootfs and that then the rootfs will be split Jun 04 09:03:05 qschulz: time to listen to our new anthem! https://youtu.be/c4LNJfFjEvw?t=140 Jun 04 09:03:08 We don't use wic but I think it can be adapt to our image format. Is there an example of split rootfs available that I can study? Jun 04 09:10:32 ykrons: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#creating-partitioned-images-using-wic might have some hints Jun 04 09:55:39 qschulz: ok thanks. As we don't use wic, it will not be easy to intergrate. But in between I have found a recipe similar to mine, that I will use as a temporary solutionnot to break sstate (using do_deploy). For long term, I will try to split rootfs Jun 04 10:27:13 what's the impact of having a distro specific recipe ("normal" recipe) depend on a machine specific recipe. We are considering making sqlite machine specific but it's needed by a shit ton of other recipes which aren't machine specific. Jun 04 10:55:38 Hello there, I have built an image using yocto, it boots and works successfully. But I don't want any single character on screen when it booting, just the splash screen and then application screen. Googled it but couldn't find any solution. I can disable kernel output by adding quiet to cmdline.txt but when init(sysvinit) starts it prints some Jun 04 10:55:38 logs.. Jun 04 10:56:04 Is there any way to do it ? Jun 04 10:56:24 ilkmc2r: Are you using psplash? Jun 04 10:56:35 paulbarker: yes Jun 04 10:56:56 ilkmc2r: it depends. but usually something console= on the kernel cmdline defines where the output goes, which should be not your screen then. Jun 04 10:57:16 ilkmc2r: That should cover up most startup output. You could also move the console to a serial port Jun 04 10:57:27 Letothe2nd beat me to it. Jun 04 10:57:27 e.g. if you don't want a console there, do not set it up in the first point. Jun 04 10:57:59 paulbarker: nah. i never beat anybody. the worst thing i ever do is serve cheap liqour if i really really hate somebody. Jun 04 10:58:55 x Jun 04 10:59:24 Adding SERIAL_CONSOLES="" to local.conf will work ? Jun 04 10:59:46 ilkmc2r: depends. Jun 04 10:59:52 the machine is raspberrypi3 btw Jun 04 11:00:11 paulbarker: any thoughts on https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/1007 ? (step2d) ? Jun 04 11:01:14 paulbarker: nope Jun 04 11:01:23 RP: I spotted that on an overnight rebuild myself. I think it's a bug in the test case I added Jun 04 11:02:10 RP: That's really dumb. I see what I did Jun 04 11:04:11 `self.assertTrue(os.path.exists(target_path))` should be `self.assertTrue(glob.glob(target_path))` in the failing test Jun 04 11:05:06 That's what I get for sending patches after wine, sorry for the breakage. I'll send a v2 Jun 04 11:08:42 paulbarker: no problem, its why we do the testing, glad its straightforward to fix Jun 04 11:23:46 Hi, Is it possible to disallow specific licenses in the final image, but not as a native tool? Jun 04 11:23:59 *for the native tools Jun 04 11:35:23 berton: should be possible, me thinks. Jun 04 11:35:38 but no guarantees, better jsut try and find out. Jun 04 11:35:45 BoJonas: ^ Jun 04 11:35:53 qschulz: heh thanks. Jun 04 11:36:10 :) Jun 04 11:36:51 Letothe2nd: I just checked base.bbclass, and it looks like it is ignoring the check for -native and other packages.. Hmm.. I must be doing something wrong then Jun 04 11:43:14 BoJonas: isn't that just what you asked for? Jun 04 11:44:48 Letothe2nd: Yes exactly... My build was just complaining about a GPL3 package, but I only use it as a -native package.. That's why I wrote that I must be doing something wrong. Jun 04 11:44:55 Sorry for the confusion Jun 04 11:50:35 BoJonas: I admit I cannot follow. Jun 04 12:16:27 I have a problem that I have two cmake recipes and A depends on B, and sometimes B fails because it needs a boost library in the sysroot of A and cannot find it. Why it sometimes fails but after few tries succeeds again? Why is the file there sometimes but not at all times? Jun 04 12:17:30 I'm sure there is something wrong with my cmakelists but I'm so puzzled by this indeterministic behavior Jun 04 12:18:26 how can B fail because of something in A, when A depends on B? Jun 04 12:18:53 this essentially means that B always has to be built before A Jun 04 12:19:11 ok, sometimes A fails * Jun 04 12:19:35 stuom1: and the recipe properly states the DEPENDS on boost? Jun 04 12:19:50 stuom1: sounds like you're using an older release with a shared sysroot and sometimes boost is in it, and sometimes not Jun 04 12:20:00 if B needs boost, B should depend on boost Jun 04 12:20:12 both have boost in DEPENDS Jun 04 12:20:23 it is yocto 2.6 Jun 04 12:20:32 also the notion of B using something in the sysroot of A is wrong Jun 04 12:20:38 B cannot access A's sysroot Jun 04 12:20:53 there is generally something wrong with the complete error description, as far as i can see. Jun 04 12:20:54 A's sysroot may not even exist when B is building Jun 04 12:21:29 yeah it looks wrong but sometimes it might exist? Because it usually succeeds Jun 04 12:22:16 * Letothe2nd bet is on that there is some very essential piece of information missing Jun 04 12:22:33 how do you know B is refering to A's sysroot? if that's the case then that's the problem Jun 04 12:23:01 and if so then stop referring to other recipes sysroots Jun 04 12:23:34 note, cmake can make this deliberately tricky by hardcoding build paths were you don't expect it Jun 04 12:25:37 error is "ninja: error: '/path/to/packageA/0.1.1/recipe-sysroot/usr/lib/libboost_filesystem-mt.so', needed by 'packageB', missing and no known rule to make it" Jun 04 12:26:10 IIRC, the -mt was removed from the library name Jun 04 12:27:27 i suspect cmake but this problem only happens in yocto environment so i wanted to understand why, so i can fix it maybe Jun 04 12:28:47 i wish it gave this error always, but every time i fix something, it starts to work, and then few builds later it comes again Jun 04 12:29:43 stuom1: are you sure it's the path to PackageA? Jun 04 12:29:51 because in that case the path is wrong Jun 04 12:30:24 you cannot depend on a path from another recipe. You can only look within your sysroot Jun 04 12:30:39 yes it looks it from the wrong sysroot Jun 04 12:31:17 the file exists on its own sysroot but it still looks elsewhere Jun 04 12:31:55 (or atleast sometimes exists, i found it with find command, but sometimes i dont find it anywhere) Jun 04 12:50:12 stuom1: A is probably installing a cmake module file and its got build paths in Jun 04 12:53:50 @rburton yes it generates and installs package config so other modules can find it Jun 04 12:54:57 check the files, i bet they've got build dir paths in Jun 04 13:00:41 thanks, I'll look into them Jun 04 13:07:08 Hmm package B cmakelists has find_package(boost) and find_package(packageA) afterwards, maybe the order matters and it uses the paths found for boost with the latter packageA? Sorry, not really a yocto problem... Jun 04 13:08:20 -quit Jun 04 13:12:54 JaMa: Thanks for getting those python patches sent Jun 04 14:00:53 RP: Looks like it's not as simple as I thought, the test case `archiver.Archiver.test_archiver_mode_mirror_gitsm_shallow` succeeds when ran alone, fails when ran as part of the full test suite Jun 04 14:01:47 I may have to drop that test, it looks like the fetcher isn't creating git shallow mirror tarballs if full mirror tarballs already exist Jun 04 14:03:19 paulbarker: ah. Maybe set DL_DIR to a subdir for the test? That way we'd get caching but the test could work? Jun 04 15:14:30 RP: I have a fix now but those tests take a long time to run as I'm using ovmf as the test recipe (it's the only thing in oe-core which uses gitsm). Would it be better to setup a gitsm test recipe in meta-selftest which pulls a dummy git submodules repository? Jun 04 15:21:51 I see we already have http://git.yoctoproject.org/cgit/cgit.cgi/git-submodule-test/, looks like that's a better option to test than ovmf Jun 04 15:25:29 JPEW: np, it took me only 3 revisions to solve it at 3 AM :) Jun 04 15:44:47 this optee-os is PITA https://errors.yoctoproject.org/Errors/Details/415405/ Jun 04 15:45:24 jonmason: ^^ any ideas ? Jun 04 15:48:22 khem: ugh. No idea from a quick look. email the Linaro guys and cc meta-arm list Jun 04 15:48:41 maybe they'll fix it if you tell them about it, as they've been pretty responsive Jun 04 15:48:43 or perhaps drop meta-ti from layers Jun 04 15:48:57 that would make denix happy, right Jun 04 16:26:13 khem: PLATFORM=vexpress-qemu_armv8a how is that meta-ti related? :) Jun 04 16:41:57 well, I build qemuarm64 but I really dont need meta-arm for that since meta-ti depends on it thats why it is in my distro Jun 04 16:42:26 from meta-ti, I need beaglebone, which is also there in meta-yocto-bsp Jun 04 16:43:13 which looks a good option too given all these hiccups Jun 04 17:09:22 khem: growing pains? gcc10 upgrade had many more and much worse hiccups... :) Jun 04 17:09:54 jonmason, JPEW: we need to start testing meta-arm against musl Jun 04 17:29:27 denix: yes, thats on the todo list Jun 04 17:37:22 rburton: ok, great! as khem is becoming impatient... :) Jun 04 18:45:40 denix: rburton isn't joking, we put it on the list earlier today and it's fairly high as a priority. hopefully that will make khem happy Jun 04 19:07:41 Hi, still trying to workaround the git commit that bitbake makes. I can only see on place: `scripts/combo-layer` line #396 if that does that sound about right then the patch is to add `--no-gpg-sign` Jun 04 19:08:14 As best I can tell there is no git verify used. Jun 04 19:08:29 Also it does not seem that a minimal git version is checked. Jun 04 19:08:54 If that is all correct then it appears the patch is straightforward. Jun 04 19:09:19 Has this been considered and rejected previously? Jun 04 22:32:05 RP: I've got a lead on https://bugzilla.yoctoproject.org/show_bug.cgi?id=13724 , mind if I take it? Jun 04 22:35:57 JPEW: go for it! Jun 05 00:32:01 Hi I have a stupid question that has been driving me crazy the last couple of hours, I'm creating my own image that is inheriting from the core-image.bbclass Jun 05 00:32:16 I'm setting EFI_PROVIDER to systemd-boot Jun 05 00:32:30 however it never works when I set it in the image file Jun 05 00:32:56 but if I set it local.conf it works Jun 05 00:33:40 I traced it and it seems to be default set in packagegroup-core-boot.bb Jun 05 00:34:05 I just don't know why I can't override it in the image file Jun 05 00:44:53 * paulg will run once AgentA become AgentOrange Jun 05 00:52:27 leaves me a reasonable cushion of alphabet letters... Jun 05 01:14:37 AgentA: that behavior makes sense, setting it in an image recipe can't affect the value in another recipe (packagegroup-core-boot) **** ENDING LOGGING AT Fri Jun 05 02:59:57 2020