00:05 <khem> meta-qcom is your best bet

06:49 <mckoan> good morning

07:12 <lorenzoruffati[m> Good morning, I'm looking into deploying a python application on a yocto based device. I can get it running properly but I would also like to obtain the cross compiled wheels (for application updates or use in virtual environments). Is there a standard way to achieve this? At least for the packages I'm interested in the wheel is generated in the do_compile and used to install to the build. But it isn't exposed outright and it also has

07:12 <lorenzoruffati[m> incorrect metadata

07:12 <lorenzoruffati[m> * Good morning, I'm looking into deploying a python application on a yocto based device. I can get it running properly but I would also like to obtain the cross compiled wheels (for application updates or use in virtual environments). Is there a standard way to achieve this? At least for the packages I'm interested in the wheel is generated in the do_compile and used to install to the build. But it isn't exposed after that and it also

07:12 <lorenzoruffati[m> has incorrect metadata

07:18 <mckoan> lorenzoruffati[m: probably there are several solutions, however you can allow bitbake to drive you in the build directory using -c devshell

08:07 <lorenzoruffati[m> I have found the build directory and the built wheel file (that's how I was able to determine that the metadata is incorrect) I was wondering if there is any established way of building the package with the correct metadata and placing the wheel in a separate directory. At the moment my best idea is to create my own bbclass to replace setuptools3, but I am new to yocto/bitbake and this feels like a common enough task that I think I

08:07 <lorenzoruffati[m> might be missing a simpler way

08:36 <mckoan> lorenzoruffati[m: probably we don't have enough details to answer, anyone?

12:13 <Entei[m]> Any idea about this or anyone else getting the same error?... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/0ab48323638372fd2004e4a3cfa15619c4614998>)

12:13 <Entei[m]> I am using mickledore branch

12:20 <rburton> your 'rm' command is crashing

12:21 <rburton> you've bigger problems than 'yocto doesn't work', check your RAM

12:21 <rburton> _could_ be a pseudo bug if you're running a bleeding edge unsupported distro

14:18 <mason> He's been dis-rm'd.

14:39 <Peter[m]123> Hi again, we are currently looking into setting up a shared internal hash equivalence server. I wondered if you're able to share any deployment details of the Yocto public instance? E.g. IIUC, I think we probably actually need to launch two instances of bitbake-hashserv pointing at the same db file - one for the build jobs and a read-only one for shared use?

14:41 <rburton> halstead: ^^^ if you have a moment

15:58 <halstead> I can share that Peter[m]123 . I'll send you a link in a bit.

16:01 <paulg> Speaking of... Could use a bit of technical guidance on hiding dynamic data from hash checks.

16:03 <paulg> context is that future will require us to use dynamic UUIDs for partitions that rely on build output ; and similar in bootargs.

16:03 <rburton> paulg: vardepsexclude?

16:03 <paulg> (for use in wks.in files and similar)

16:04 <paulg> rburton, yep I was getting to that. Here is what I have so far, but it still yells at me.

16:04 <paulg> # These aren't known until we actually build the image.

16:04 <paulg> DM_VERITY_ROOT_HASH = "__not_set__"

16:04 <paulg> DM_VERITY_ROOT_UUID = "__not_set__"

16:04 <paulg> DM_VERITY_HASH_UUID = "__not_set__"

16:04 <paulg> BB_BASEHASH_IGNORE_VARS += "DM_VERITY_ROOT_HASH DM_VERITY_ROOT_UUID DM_VERITY_HASH_UUID"

16:04 <paulg> do_write_wks_template[vardepsexclude] = "DM_VERITY_ROOT_HASH DM_VERITY_ROOT_UUID DM_VERITY_HASH_UUID"

16:05 <paulg> ERROR: When reparsing /home/paul/poky/meta/recipes-core/images/core-image-minimal.bb:do_write_wks_template, the basehash value changed from 7c25319919703fd056e12de03029773848173f277e2a318177a9d253029ed7c6 to 115753bada69bd55f42be354a766f36570f6ad5ef01de4ee476c261d57ec77eb. The metadata is not deterministic and this needs to be fixed.

16:05 <paulg> This isn't my normal area of poking around, so I'm sure I'm doing something wrong.

16:08 <rburton> hm hm that's what I'd have thought would be right

16:09 <paulg> I wonder if it is the context of *where* I'm setting those lines above? meta-security/classes/dm-verity-img.bbclass

16:11 <kevinrowland> Speaking of images, image recipes are giving me some trouble right now. I want to write an image recipe that simply takes the existing WIC image, combines it with some other scripts, and tars / gzips it up. So I wrote a new BBCLASS, added it to IMAGE_CLASSES, and in that class I wrote a `do_image_foo`, with `addtask do_image_foo before

16:11 <kevinrowland> do_image_complete after do_image_wic`. and yet it doesn't run when I ask for an image with `bitbake <image-name>`. Am I missing something? Does IMAGE_CMD have to be involved?

16:13 <rburton> your addtask probably needs to say it runs before build, so make it happen in the default task

16:14 <rburton> image_cmd is used if you want to write little shell fragments to manipulate the image, so you could have an IMAGE_CMD which does your work then you set IMAGE_TYPES to wic.mything

16:14 <rburton> example: gz is a image command, so if you do wic.gz you get a compressed wic image

16:14 <paulg> FWIW, I did check and commented out my d.setVar() lines out, and the error goes away, so it definitely is tied to those three vars changing. Frustrating.

16:30 <rburton> abelloni: you only saw the gdbm no tests thing once, right?

16:31 <kevinrowland> Thanks rburton I'll give that a try, but to be clear: `addtask do_image_foo before do_image after do_image_wic`? Where `do_image` is the "build" task you're referring to?

16:31 <abelloni> rburton: yes

16:31 <rburton> kevinrowland: no, i literally mean the build task

16:33 <rburton> but convention would be to use an IMAGE_CMD instead of a new task, the wic one is a bit special

16:39 <kevinrowland> Oh it's just clicked - `do_build` - thanks again. Doesn't seem to be working but I can do some more debugging and might come back with a more specific question

16:41 <rburton> invoke it explicitly to check it works fine like that

16:41 <rburton> $ bitbake image -c image_foo

16:42 <khem> rburton: the gobject-introspection changes are causing this I think - https://errors.yoctoproject.org/Errors/Build/164148/

16:46 <rburton> yes, i think i have most of those fixes locally

16:46 <rburton> i'll check

17:06 <kevinrowland> So I just had to use `after do_image_complete`, because that's what moves `.wic.bz2` into `${DEPLOY_DIR_IMAGE}`, which is where I do my tarring

17:27 <khem> rburton: ok, I will look out for patches for meta-oe 🙂

17:42 <halstead> Peter[m]123: I had a few meetings. A simple write up is available at https://wiki.yoctoproject.org/wiki/Hash_Equivalence_Server. Please let me know if you have questions and feel free to edit the page if you spot any mistakes.

18:32 <JaMa> khem: I was able to reproduce the networkmanager issue you mentioned after adding gobject-introspection-data to my DISTRO_FEATURES, will send v2 after figuring out what's going on

18:33 <khem> OK

18:35 <vvn> khem: if I understand correctly, Qualcomm is not usually open minded regarding FOSS, and meta-qcom is a work from Linaro to push the openness regarding their SoC, is that correct?

18:37 <khem> vvn: I am not sure about details, but some of SBCs like dragonboards are supported via that layer, there might be other QCA chipsets which are not and perhaps supported by some proprietary layers I dont know

18:43 <vvn> khem: that's what I'm looking at at the moment, I'm still not certain if the Qualcomm Snapdragon 210 MSM8909 is supported by a Yocto layer or not (sometimes SoC/CPU have alternative names..)

18:52 <vvn> like it looks like it is compatible in a way with 8916 but I'm not sure