Bug filed: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14916 Not sure if I put it in the right category, so feel free to move it around if needed

Hi all, is there a way to set the package metadata in a way that it would require one of the packages providing a tool via the ALTERNATIVE_ mechanism? E.g. sed for instance could be provided by busybo

Hi Matthias, you're right :( PYPA_WHEEL = "${S}/py-smbus/dist/smbus-*-*.whl" finally does it @Tim @Richard PYPA_WHEEL doesn't respect SETUPTOOLS_SETUP_PATH, which might be another issue to fix BR Konr

Dang - that's the second issue being open in this series... Try PYPA_WHEEL = "${PIP_INSTALL_DIST_PATH}/smbus-*-*.whl" instead - and it should really work

Hi Matthias, this is cause by merged PEP-517 changes. To make it build again just inject PIP_INSTALL_PACKAGE = "smbus" into the recipe or a bbappend. Mainly the python3-prefix of the recipe, makes the

Just out of curiosity: I thought the agreement was that neither PREFERRED_PROVIDER_* nor recipe/provider specific settings should be part of a layer.conf PREFERRED_PROVIDER_go-native as a hard assignm

Fairly easy, each distro creates an OVERRIDE by default, so you could do A:poky = "foo.service" A:yourdistro = "bar.service" SYSTEMD_PACKAGES = "${A}" do_install:append() { install -d ${D}${systemd_sy

The following I just found in local.conf.sample.extended # Enabling FORTRAN # Note this is not officially supported and is just illustrated here to # show an example of how it can be done # You'll als

I think the reason of that is that fortran support isn't enabled in default gcc-runtime recipe. from gcc-runtime.inc: RUNTIMETARGET = "${RUNTIMELIBSSP} libstdc++-v3 libgomp libatomic ${RUNTIMELIBITM}

Hi, according to my understanding BUILDNAME should not be used like that since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake. The variable should contain only references to other automatically d

You can either use BBMASK in your local.conf to remove the bbappend from the parsing tree or set BB_DANGLINGAPPENDS_WARNONLY in your specific build. both can be added to your specific kas yaml without

according to github 80805cabfcf57dd0454d47d7f86d43c6738ce629 is the tip. any specific reason to pick the commit before that?

The super yoctoish way would be to alter the packaging of the recipe to your needs. Let's assume recipe-a consists of the files foo bar and it would package both files into recipe-a pkg. In the actual

No there isn't - with the yocto project you can build your own distribution not mimic other already available distributions. If you want to build Ubuntu you have to ask canonical.

#ubuntu #distro

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb#n34 (and the next lines) might give you a hint what to do in this case. Although one could also con

If you're sure you only use standard python libs it's fairly easy. make a recipe (name it how ever you like) SCR_URI = "file://<your script>.py" do_install() { install -m 0755 <your script>.py ${bindi

The file in called COPYING.txt in this archive [1] not LICENSE [1]https://files.pythonhosted.org/packages/a9/d9/9fdfb0ac2354d059e466d562689dbe53a23c4062019da2057f0eaed635e0/pyinstaller-4.5.1.tar.gz

#yocto

Iirc there has been the same discussion already last year or the year before... and the agreement was to leave it as it is. IMHO most of the used projects still go with master instead of main, so a pa

According to [1] yes - you might want to consider back porting one of the more recent versions of numpy from [2], as you are using a pretty outdated one [1] https://stackoverflow.com/questions/5466584

#yocto #zeus #python

Well AFAIK your observation is correct, go-mod.bbclass doesn't work a in BB_NO_NETWORK-safe manner. What you could do is to provide all the dependencies manually and add them via DEPENDS, which is gra