**** BEGIN LOGGING AT Wed Oct 09 03:01:40 2019 Oct 09 06:42:35 RP, JPEW, just out of curiosity, is there a way of finding out of how much sstate-cache could be reused thanks to hash equivalency ? Oct 09 06:43:27 and do all these "... now valid and being rerun" notes have anything to do with it ? Oct 09 06:47:48 (btw, shouldn't those notes be removed ?) Oct 09 07:57:22 Good morning! Oct 09 07:58:18 The SDK generated by meta-mingw doesn't contain the environment-* script anymore. Oct 09 08:00:51 Moreover I have some random Python exceptions: Exception: FileExistsError: [Errno 17] File exists: '/home/alessio.bogani/WIP/voltumna/build/tmp/sysroots-components/corei7-64/zlib-intel/usr/include/zlib.h' -> '/home/alessio.bogani/WIP/voltumna/build/tmp/work/corei7-64-voltumna-linux/rpcbind/1.2.5-r0/recipe-sysroot/usr/include/zlib.h' Oct 09 08:00:53 Has Someone already seen it? Oct 09 08:39:57 kroon: it is a bit too chatty at the moment Oct 09 08:40:18 kroon: finding out in advance may be hard, reporting at the end may be possible though Oct 09 09:04:58 RP: hey, about to go to bed, just wondering if you got my patch for the documentation fix on multiconfig Oct 09 09:05:30 both of them because actually one was to bitbake manual Oct 09 09:14:16 aehs29: I see two patches, not looked at themyet Oct 09 09:56:23 Good morning everybody Oct 09 10:00:00 to you too Oct 09 10:00:49 I'm trying to understand how to create a custom machine (actually based on a colibri-vf), to build b2qt for. Everything goes fine, but at completion of "bitbake b2qt-embedded-qt5-image" i cannot find any img or tar.gz file in deploy/image folder, just the conf ones. How can I get more information on what is doing the do_rootfs step? Oct 09 10:02:38 mous16: In the recipe's temp directory you can find logs in the log.do_rootfs* form. Oct 09 10:03:22 @alessioigor: thank's! I'll check it out immediatly Oct 09 10:03:55 mous16: In any case check for WKS_FILE variable: bitbake b2qt-embedded-qt5-image -e | grep WKS_FILE Oct 09 10:12:26 rburton, it's basically complete, my goal was to eliminate dependencies for a specific image used here in the project. I'm not sure what would be the 'definition of done' really :) Oct 09 10:14:33 @alessioigor: log.do_rootfs seems fine: it says that a big amount of packages are being installed in root fs (and rootfs folder seems ok), no errors reported. Maybe y problem regards do_image step. About WKS_FILE, I think i dont need to use wix files, because I have to flash like that: https://developer.toradex.com/knowledge-base/flashing-linux-on-vybrid-modules Oct 09 10:15:48 mous16: So you have to check for IMAGE_FSTYPES. Oct 09 10:20:41 @alessioigor: it reports IMAGE_FSTYPES="conf", and i presume it means that conf file rules. in my layer I have file mymachine.conf with IMAGE_FSTYPES += "ext4 tar.bz2" . Are my assumptions valid? Oct 09 10:22:02 IMAGE_FSTYPES="conf" sounds weird to wrong Oct 09 10:22:09 Indeed Oct 09 10:22:35 mous16: You have to go with tar.bz2 and similar. Oct 09 10:22:49 mous16: bitbake -e your image and search the output for IAMGE_FSTYPES to find out what sets that. Oct 09 10:28:03 @alessioigor: I'm thinking I'm wrong in include/set order: http://bit.ly/2LZdIm5 Oct 09 10:29:30 mous16: if boot2qt explicitly sets something, then you'll probably have to ask them why. they are doing things sometimes quite a bit different. Oct 09 11:04:29 kanavin: world builds working :) Oct 09 11:12:08 rburton, that is hardly realistic, as how would you build world without ever building bash for instance? Oct 09 11:12:18 ok maybe not a world build Oct 09 11:12:36 but a formal test case that didn't involve meta-gpl2 to exercise this would be *awesome* Oct 09 11:14:59 rburton, yep, I'm now trying to figure out how to disable licenses for specific images (e.g. check actual packages that were installed), rather than having a global disabling, which pretty much requires meta-gpl2 Oct 09 12:09:46 hi, anyone know how the systemd presets are supposed to be used with yocto 2.8? I see a default preset coming from systemd which disables everything. my recipes are just setting SYSTEMD_SERVICE_${PN} but that isn't working anymore except for services with @ character due to shell match in systemd_postinst(), line 36 of poky/meta/classes/systemd.bbclass Oct 09 12:43:20 RP: going to push aehs29's multiconfig docs change Oct 09 12:43:55 oh no i'm not, i can't push Oct 09 12:45:14 rburton: try pushing harder? Oct 09 12:45:17 Oct 09 12:50:16 dpm Oct 09 12:50:23 wow. fat fingered that Oct 09 12:55:38 rburton: I can probably fix that! Oct 09 12:56:12 sanity tested distros list is a bit out of date Oct 09 12:56:29 no ubuntu 19.04 (latest is 18.04) which i guess we should add as its on the ab and is latest release Oct 09 12:56:45 poky list needs updating, shall i just bump it to poky-2.8 poky-3.0? Oct 09 12:56:50 rburton: should work now Oct 09 12:57:06 yep can push now Oct 09 13:16:10 * RP builds 3.0 rc1 Oct 09 13:18:05 whoop whoop Oct 09 13:18:07 nice! Oct 09 13:19:55 alessioigor: What version of meta-mingw? We addeded QA tests so it *should* be working. Oct 09 13:23:11 JPEW: 9df4e11 Oct 09 13:23:15 RP: Sent the siggen unihash+taskhash patch. Sorry I didn't get it out yesterday. I'll let you decide if it needs to go in 3.0 :) Oct 09 13:23:43 JPEW: I just triggered 3.0 rc1 ;-) Oct 09 13:23:47 JPEW: I have just restart a entire build from scratch.... Oct 09 13:23:54 RP: Ya I saw that. Awesome Oct 09 13:25:19 alessioigor: Which environment scripts are missing? Oct 09 13:26:17 JPEW: all but relocate Oct 09 13:27:18 JPEW: I meant all scripts are missing except the relocate one. Oct 09 13:28:29 alessioigor: Strange Oct 09 13:37:31 Hi, i have build an sdk with containing modemmanager and libmm-glib but im getting the error ModemManager.h: No such file or directory Oct 09 13:41:02 hmw1: did you verify the sdk contains that file? Oct 09 13:41:12 did you use pkgconfig to get the path to modemmanager in your build? Oct 09 13:42:59 ModemManager.h is in usr/include/ModemManager/ Oct 09 13:43:06 but not in include Oct 09 13:43:12 that's right Oct 09 13:43:16 so you use pkgconfig to find it Oct 09 13:49:55 Tnx, had the same issue with mm-manager.h: but needed to include libmm-glib the same way Oct 09 13:51:12 uh that did not work for libmm-glib Oct 09 13:52:26 rburton, ERROR: core-image-minimal-1.0-r0 do_rootfs: Package bash has incompatible license GPLv3+ and cannot be installed into image. Oct 09 13:52:28 \0/ Oct 09 13:52:32 RFC patch is coming Oct 09 13:52:48 the use case is having better granularity for INCOMPATIBLE_LICENSE where it can be set per image Oct 09 13:56:16 error: libmm-glib development package not found Oct 09 14:05:17 RP, rburton: A patch that change image class logic to make as many images as items WKS_FILES contains would be ever considered for inclusion? Oct 09 14:09:01 alessioigor: so multiple wic images rather than just one? Oct 09 14:10:20 RP: Exactly a way to cope with need to have the same image on different size SD cards. Oct 09 14:10:59 its not going to make the code readable but I can understand why you might want it Oct 09 14:11:17 Unless comunity decides to use repartition on first boot approach. Oct 09 14:11:19 alessioigor: it really depends how messy the change gets I guess Oct 09 14:16:40 RP: In your opinion which approach is best fit for Yocto/OE? Resizing on first boot or multiple predefined size images generation? Oct 09 14:18:01 At the moment I made a recipe for any sd card size in use (myimage-4gb, my-image-8gb, myimage-16gb and so on). Oct 09 14:18:13 alessioigor: from a user perspective downloading an image multiple times for two different size SD cards is horrible Oct 09 14:18:46 so you'd get a better user experience with resizing Oct 09 14:19:43 alessioigor, RP: I agree. Resizing would be my preference: sometimes we don't really know what size flash our image is going to be put on at production time (or rather, we want to put the same image on multiple sizes) Oct 09 14:29:54 Googling I found https://github.com/bmit-pune/meta-toradex-yocto/blob/master/recipes-core/fs-init/fs-init.bb and https://github.com/96boards/meta-96boards/blob/master/recipes-bsp/96boards-tools/96boards-tools_0.12.bb. It would be great to have a "official" version. Oct 09 14:31:35 JPEW: Re mingw: Rebuilding from scratch makes scripts come back! Oct 09 14:32:12 alessioigor: That is really strange Oct 09 14:34:43 JPEW: Now I'm going to build from scratch all machines and images. I keep you updated (if you permit me). Oct 09 14:35:40 alessioigor: OK Oct 09 14:35:55 JPEW: Thank you **** BEGIN LOGGING AT Wed Oct 09 15:04:10 2019 Oct 09 15:09:25 alessioigor: if that fs-init works for you, just copy/paste and send a patch to oe-core Oct 09 15:10:45 kanavin_: just wondering with your patches for INCOMPATIBLE_LICENSE, 1) from now on we could put INCOMPATIBLE_LICENSE = "GPLv3" in an image recipe (or does it have to be INCOMPATIBLE_LICENSE_pn-myimage?) Oct 09 15:11:55 2) if in imageB.bb I require/include imageA.bb, can I actually have INCOMPATIBLE_LICENSE from imageA be taken (or in case of INCOMPATIBLE_LICENSE_pn-* can it be INCOMPATIBLE_LICENSE_pn-${IMAGE_BASENAME}[/${PN}])? Oct 09 15:12:00 pn-myimage would be the syntax for in local.conf, end result would be identical Oct 09 15:12:02 Just being curious Oct 09 15:12:11 ah, so still in local.conf Oct 09 15:13:15 Too risky for us, but I could see the use of INCOMPATIBLE_LICENSE being part of an image recipe Oct 09 15:14:18 rburton: thanks for the explanation Oct 09 16:15:21 hello folks Oct 09 16:15:37 is it feasible to add another option to BBCLASSEXTEND to support mingw targets? Oct 09 16:16:21 like now we have "target", "native" and "native-sdk" and then we also could do "customer", which is kind-of another target that generates customer applications, normally using mingw Oct 09 16:17:38 this way, supporting such things would not require creating a different config, but just a "machine-customer/" directory inside conf/ where the customer-machine is defined, with toolchain options Oct 09 16:20:45 litb: how is mingw not nativesdk Oct 09 16:21:37 rburton, the current meta-mingw is nativesdk.. but I'm looking for windows as another target Oct 09 16:22:12 the customer program that's used to access our device is a windows qt program. so when we publish another firmware and build it using yocto, we need to build another windows qt program aswell Oct 09 16:22:13 that would just be a MACHINE then Oct 09 16:22:34 rburton, ah. but if i select that MACHINE in local.conf, it overrides the firmware's machine Oct 09 16:22:52 sure, so this is where you either 1) use two build directories or 2) use multiconfig Oct 09 16:22:53 would be best if one could have two machines. one for the windows part, and one for the actual yocto part that goes into the device Oct 09 16:23:17 but you're saying "i want to build code for a windows target", so you need a windows MACHINE Oct 09 16:23:48 meta-mingw should provide most of the pieces to do that. *most*. don't know if anyone has actually done that. Oct 09 16:24:13 would it not work if I extend yocto with the possibility to say WINDOWSMACHINE=... and then one can say BBCLASSEXTEND += "windows" and it creates things into "recipe-sysroot-windows" ? Oct 09 16:24:32 it would look to me that the windows things are kind of secondary build artefacts Oct 09 16:25:57 litb: multiconfig is the path of least resistance to making that work Oct 09 16:26:16 ah, I see! Oct 09 16:26:25 litb: get it working as a normal build first Oct 09 16:27:34 Actually during the last two months I've managed to re-produce our debian firmware with yocto. at least to a point where it boots and starts the applications and the GUI comes up Oct 09 16:29:12 RP, I suspect I would need different patches than the normal yocto patches to the various packages. that's were BBCLASSEXTEND would break down, I suspect, because variants cannot change the patches list Oct 09 16:36:53 litb: variants could in theory do that fwiw Oct 09 16:37:07 litb: there's literally nothing special about windows as a target, it's just another target. if you want more than one in a single build use multiconfig. Oct 09 16:37:28 litb: overrides like SRC_URI_append_class-XXX = " Y" Oct 09 16:37:44 but as rburton says, its really multiconfig territory Oct 09 16:40:20 rburton: It is a very pity that I can't use systemd-growfs :( Oct 09 16:40:41 alessioigor: take the script you found in that other layer, write a little service file to call it. easy! Oct 09 16:41:17 you could write a patch for systemd to grow partitions too, but this is easier :) Oct 09 16:41:25 (and not tied to systemd) Oct 09 16:50:26 thanks folks, I will try multiconfig! Oct 09 16:50:51 rburton: RP thanks guys Oct 09 16:51:01 np Oct 09 16:51:10 litb: first start with a machine to target windows, that's the challenge Oct 09 16:51:12 I suspect I can also add INHERIT += nopackages for the windows config. Oct 09 16:52:13 aehs29: thanks for the fixes Oct 09 16:52:38 litb: the easy way would be to just package everything like normal but your final app recipe would have its own deploy tasks that just ship a statically linked binary or an installer or something Oct 09 16:53:43 ah, I see. Oct 09 16:54:09 again the hard bit is the actual machine, getting a cross compiler going etc Oct 09 16:57:23 probably I can just rip the most part out of MXE Oct 09 17:05:15 ls Oct 09 17:11:31 alessioigor: if you're talking about growing the rootfs on first boot, see the 96boards-tools recipe, includes a service for it Oct 09 17:11:33 * kergoth yawns Oct 09 17:15:50 kergoth: Is it the best implementation for this type of service? Oct 09 17:16:03 kergoth: In your opinion Oct 09 17:16:14 i haven't seen many functional ones at all, so tough to say Oct 09 17:19:30 kergoth: Thank you Oct 09 17:35:52 out of curiosity, why was systemd-growfs not viable? Oct 09 17:37:04 kergoth: As far as I understand it resizes only filesystem not the partition. Oct 09 17:37:14 ah Oct 09 17:37:33 rburton: Do I understand well? ^^^^ Oct 09 17:37:35 hmm Oct 09 17:38:07 I would be very happy to use systemd-growfs..... Oct 09 17:40:03 resize-helper uses resize2fs directly, which isn't ideal. it could use systemd-growfs for that piece, perhaps Oct 09 17:40:15 but it does work well for the common case Oct 09 18:02:05 <__angelo> hi, organized a distro with some submodules, one is poky, one is meta-ti. I pulled initially a sumo. What is the proper way to update those submodules ? Should i keep them to a fixed hash, or better to update to "sumo" ? Oct 09 18:04:13 __angelo: that's a matter of your own policy, whether to stay with tested snapshot of update to the latest "stable" Oct 09 18:09:33 <__angelo> denix, ok thanks Oct 09 18:10:02 yep, entirely depends on your requirements and how risk averse you are, the schedule you're under, etc. you'll have to figure that out Oct 09 18:10:31 <__angelo> kergoth, ok thanks Oct 09 18:44:00 does anyone know why this is happening or how to fix it? http://ix.io/1Yak Oct 09 18:46:13 it *seems* to exist.. /usr/lib# strings libstdc\+\+.so.6.0.25 |grep _ZTVN10__cxxabiv117__class_type_infoE Oct 09 18:46:15 _ZTVN10__cxxabiv117__class_type_infoE **** BEGIN LOGGING AT Thu Oct 10 02:25:38 2019 Oct 10 02:45:40 zeddii: why not Oct 10 02:46:02 we will have a lot of interesting things and you will be on hook for one of them Oct 10 02:46:38 and I like to volunteers absentees for Action Items :) **** ENDING LOGGING AT Thu Oct 10 02:59:57 2019