|
# honister #systemd attempting to run script on boot...
#systemd
I am trying to make use of system to run a test script at boot…
I can exercise my test_script/test_script.service manually using systemctl commands and it appears to work as expects.
I created a recipe based on this, it builds clean (no errors/warnings), but it doesn’t appear to set things up correctly.
I have only recently begun working with honister, and new to systemd…
Could someone have look at my recipe & service file and see if they can spot anything ?
My recipe:
#
# This file is the my_test_script recipe.
#
SUMMARY = "Simple my_test_script application"
SECTION = "apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
inherit systemd
SRC_URI = "file://test_script.sh \
file://test_script.service"
S = "${WORKDIR}"
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_SERVICE_${PN} = "test_script.service"
SYSTEMD_AUTO_ENABLE:${PN} = "enable"
do_install() {
install -d ${D}${bindir}
install -m 0755 ${S}/test_script.sh ${D}${bindir}
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${S}/test_script.service ${D}${systemd_system_unitdir}
}
FILES_${PN} = "${bindir}"
FILES_${PN} += "${systemd_system_unitdir}"
REQUIRED_DISTRO_FEATURES="systemd"
---
My test script service file:
[Unit]
Description=Configure test
[Service]
Type=oneshot
ExecStart=/usr/bin/test_script.sh start
StandardOutput=journal+console
[Install]
WantedBy=multi-user.target
---
My test script:
#!/bin/bash
# description: Description comes here....
echo "*******************************"
echo "START: Hello PetaLinux World :)"
date +"%m/%d/%Y %H:%M:%S $HOSTNAME"
echo "*******************************"
Thanks,
Steve
|
|
|
Dealing with go dependencies in recipes - native docker-compose
Today I realized, that the docker-compose in the meta-virtualization layer is the old python3 based one and a native solution is available. I tried to make a recipe for it to get rid of python3 (no other packages uses it in our setup) and the current python3-docker-compose is broken: https://lore.kernel.org/yocto-meta-virtualization/49660EA1-CD22-40DB-98C7-C43F38A72CCA@ieee.org/I tried to build the native solution proposed in https://github.com/docker/compose/tree/v2.11.2. So my current recipe docker-compose_2.11.2.bb looks like this: LICENSE = "Apache-2.0" inherit go inherit go-mod GO_IMPORT = "github.com/docker/compose" SRC_URI = "git://${GO_IMPORT};protocol=https;branch=v2" # v2.11.2 SRCREV = "616777eb4ad4d1101622d6727d9b7adaeb7943bb" # S = "${WORKDIR}/git" DEPENDS = "docker-ce" RDEPENDS:${PN} = "docker-ce-cli" With this I run into the issue, that go want's to download stuff while compiling. Which is forbidden and breaks the reliable build proposal. Totally understandable. Looks similair to this: dial tcp: lookup proxy.golang.org: Temporary failure in name resolution I read about a proposal allowing this by adding do_compile[network] = "1" to meta/classes/go.bb: https://lore.kernel.org/all/20220228235433.3948994-1-andrei@gherzan.com/Of course, if this works, the reliable build thingy is gone, but while trying I discovered go loads external stuff, compiles it too. In my case (I have kirkstone with go-1.17) I run into modules demanding a go more recent: ASH[build k8s.io/client-go/applyconfigurations/autoscaling/v2beta2]: "file containerresourcemetricsource.go Mas4-HIX5lGBEQNTIo58\n" # github.com/docker/compose/v2/pkg/utils pkg/utils/slices.go:23:6: missing function body pkg/utils/slices.go:23:14: syntax error: unexpected [, expecting ( note: module requires Go 1.19 HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1] HASH[build k8s.io/client-go/applyconfigurations/certificates/v1beta1]: "go1.17.13" which could be worked around by moving to landsdale release. Which bothers me, because I too want to keep my build reliable. And I do not want to mess around outside our meta layer in the distribution! How do I do this properly? I see people pulling in each dependency by individual golang.org-x.bb recipes, how could such a recipe look like? I read https://lore.kernel.org/all/8132db85-5881-636e-c091-d84c47efe4fe@gmail.com/T/where Mike is not happy with this appraoch either and comes up with a working recipe I don't get why this could work at all. What am I missing here where is the missing link I did not get yet? Also, I am jealous about the buildroot guys sometimes, how do they do this in a 22 lines makefile including comments: https://git.busybox.net/buildroot/tree/package/docker-compose/docker-compose.mkRegards Konstantin -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Straße 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletschke@... http://www.inside-m2m.de Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig HRB: 111204, AG Hannover
|
|
|
Re: How to create symlink while installing binary in recipe?
Khem Raj
On Tue, Oct 11, 2022 at 9:36 AM Sourabh Hegde <hrsourabh011@...> wrote:
Hello All,
I have a simple recipe in which a binary is installed to /usr/bin/. Now, I want to establish a symlink to same binary also. I am using hardknott release
do_install () {
install -d ${D}${bindir}/
install -m 0755 ${WORKDIR}/test.sh ${D}${bindir}/test
lnr ${D}/usr/bin/test ${D}/usr/bin/test-x
}
Is this the correct approach? Or is there any better method?
Looks ok perhaps you want to double check using lnr we have dropped its usage in master but I am not sure if hardknott needs it or not. I would simily use ln -sf test ${D}/usr/bin/test-x and avoid using the lnr wrapper.
|
|
|
How to create symlink while installing binary in recipe?
Hello All, I have a simple recipe in which a binary is installed to /usr/bin/. Now, I want to establish a symlink to same binary also. I am using hardknott release
do_install () {
install -d ${D}${bindir}/
install -m 0755 ${WORKDIR}/test.sh ${D}${bindir}/test
lnr ${D}/usr/bin/test ${D}/usr/bin/test-x
}
Is this the correct approach? Or is there any better method?
|
|
|
Yocto Project Status 11 October 2022 (WW41)
Current Dev Position: YP 4.1 M4 (In TSC Review) Next Deadline: 28th October 2022 YP 4.1 Release Next Team Meetings: Key Status/Updates: - Richard Purdie is actually on holiday and expects to return on the 24th October.
- Patches for master are welcome on the mailing list and will be reviewed/tested, but will not be merged until RP has returned.
- YP 4.1 rc2 is now out of QA and will be reviewed by the TSC later today. Release is scheduled for the 28th but may happen earlier if the documentation is finalized.
- A bug related to the Extensible SDK has been found in YP 4.1 but this is potentially not a release blocker, and can be fixed in the first point release.
- Steve Sakoman to maintain Langdale (YP 4.1 - not an LTS)
- At release we released the core layer was still advertising kirkstone so this was removed. This did mean some simple changes were needed to layers to mark compatibility with the new release, we’ll aim to do this earlier in the next release.
- YP 3.1.20 rc2 has been built and is in QA now.
- YP 4.2 Proposed Timeline document is at: https://docs.google.com/document/d/1X5KM_3BiEsIrHBO93ULvYHQJ72NqS5U5jjwWo5bxTiY/edit?usp=sharing
- Help is very much welcome in trying to resolve our autobuilder intermittent issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT. In particular there is a long-standing qemuppc failure which needs investigating (https://bugzilla.yoctoproject.org/show_bug.cgi?id=14824)
Ways to contribute: YP 4.1 Milestone Dates: - YP 4.1 M4 is back from QA and in TSC Review
- YP 4.1 M4 Release date 2022/10/28
Upcoming dot releases: - YP 3.1.20 built and in QA
- YP 3.1.20 Release date 2022/10/21
- YP 4.0.5 build date 2022/10/31
- YP 4.0.5 Release date 2022/11/11
Tracking Metrics: The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at: https://wiki.yoctoproject.org/wiki/TSC The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|
|
Re: [meta-zephyr][kirkstone][PATCH] nrf52840-mdk-usb-dongle.conf: Add new machine from makerdiary
toggle quoted message
Show quoted text
-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of philippe.coval@...
Sent: Friday, October 7, 2022 4:57 PM
To: yocto@...
Cc: philippe.coval.pro+meta-zephyr-lists.yoctoproject.org@...;
Philippe Coval <philippe.coval@...>; Philippe Coval
<philippe.coval.ext@...>; Jon Mason <jon.mason@...>;
Saini, Naveen Kumar <naveen.kumar.saini@...>
Subject: [yocto] [meta-zephyr][kirkstone][PATCH] nrf52840-mdk-usb-
dongle.conf: Add new machine from makerdiary
From: Philippe Coval <philippe.coval@...>
It was tested with zephyr-openthread-rcp along Oniro's IoT gateway
blueprint
For the record deployment was done manually:
- Click on device button
- uf2conv.py "zephyr.hex" -c -f 0xADA52840
- and then copy to mounted "/dev/disk/by-label/MDK-DONGLE"
Support of unfree flashing tools might be added later (once double verified)
Forwarded: https://lists.yoctoproject.org/g/yocto/message/58142
Relate-to: https://gitlab.eclipse.org/eclipse/oniro-blueprints/transparent-
gateway/meta-oniro-blueprints-gateway/-/issues/6
Relate-to: https://wiki.makerdiary.com/nrf52840-mdk/zephyr/
Relate-to: https://gitlab.eclipse.org/pcoval/oniro-presentations/-
/wikis/openthread
Signed-off-by: Philippe Coval <philippe.coval.ext@...>
Tested-by: Jon Mason <jon.mason@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
Signed-off-by: Philippe Coval <philippe.coval@...>
---
meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf | 7
+++++++
1 file changed, 7 insertions(+)
create mode 100644 meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-
dongle.conf
diff --git a/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
b/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
new file mode 100644
index 0000000..67e407a
--- /dev/null
+++ b/meta-zephyr-bsp/conf/machine/nrf52840-mdk-usb-dongle.conf
@@ -0,0 +1,7 @@
+#@TYPE: Machine
+#@NAME: nrf52840-mdk-usb-dongle
+
+#@DESCRIPTION: Machine configuration for makerdiary's
+nrf52840-mdk-usb-dongle
+
+require conf/machine/include/nrf52.inc
+ARCH:nrf52840-mdk-usb-dongle = "arm"
--
2.34.1
|
|
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-4.1.rc2)
toggle quoted message
Show quoted text
-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Saturday, 1 October, 2022 6:50 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-4.1.rc2)
A build flagged for QA (yocto-4.1.rc2) was completed on the autobuilder and
is available at:
https://autobuilder.yocto.io/pub/releases/yocto-4.1.rc2
Build hash information:
bitbake: 074da4c469d1f4177a1c5be72b9f3ccdfd379d67
meta-agl: e7e9216ccead73fdf6054301e68396ab04710c6f
meta-arm: aa89fe3f08cb8406f9f1082c683bd71cd04628fb
meta-aws: 729928fb7ce4a74546b68dd31390a3f6057ab92c
meta-intel: 940218bd438776026398617033e09f288dae0137
meta-mingw: b0067202db8573df3d23d199f82987cebe1bee2c
meta-openembedded: 0782ea454af5b88cd686ac572c397d92e5912de4
meta-virtualization: 3fe3e0971d7d14cbd06f54cad942fa2ed86c5048
oecore: 744a2277844ec9a384a9ca7dae2a634d5a0d3590
poky: 5200799866b92259e855051112520006e1aaaac0
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
|
|
|
M+ & H bugs with Milestone Movements WW10
All,
YP M+ or high bugs which moved to a new milestone in WW41 are listed below: Priority | Bug ID | Short Description | Changer | Owner | Was | Became | Medium+ | 12723 | mysql requires unicode and char length filtering | david.reyna@... | david.reyna@... | 4.1 M4 | 4.2 M1 | | 13008 | toaster testing | david.reyna@... | david.reyna@... | 4.1 M4 | 4.2 M1 | | 13109 | Implement CPE to package to Release mapping | david.reyna@... | david.reyna@... | 4.1 M4 | 4.2 M1 | | 13103 | [Bug][QA 2.7 M1 rc1][Toaster] "Recipes" table  and  "machines" table are not getting populated after clicking on imported layer as well as after clicking Machines Tab on project page | david.reyna@... | david.reyna@... | 4.1 M4 | 4.2 M1 | | 14125 | busybox wget ssl is exposed to MitM attack due to CVE-2018-1000500 | randy.macleod@... | shachar@... | 4.1 M4 | 4.2 M1 | | 14814 | ncurses version of taskexp.py | david.reyna@... | david.reyna@... | 4.1 M4 | 4.2 M1 | | 14834 | Timeout issue with Toaster and bitbake | david.reyna@... | david.reyna@... | 4.1 M4 | 4.2 M1 |
Thanks, Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|
|
Enhancements/Bugs closed WW41!
All,
The below were the owners of enhancements or bugs closed during the last week! Who | Count | michael.opdenacker@... | 2 | randy.macleod@... | 1 | mhalstead@... | 1 | Grand Total | 4 |
Thanks, Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|
|
Current high bug count owners for Yocto Project 4.1
All,
Below is the list as of top 32 bug owners as of the end of WW41 of who have open medium or higher bugs and enhancements against YP 4.1. There are 13 possible work days left until the final release candidates for YP 4.1 needs to be released. Who | Count | ross.burton@... | 17 | randy.macleod@... | 16 | richard.purdie@... | 13 | michael.opdenacker@... | 11 | JPEWhacker@... | 9 | Aryaman.Gupta@... | 6 | bruce.ashfield@... | 6 | sakib.sajal@... | 6 | pavel@... | 5 | tim.orling@... | 4 | pgowda.cve@... | 3 | sundeep.kokkonda@... | 3 | jon.mason@... | 3 | akuster808@... | 3 | sgw@... | 2 | raj.khem@... | 2 | hongxu.jia@... | 2 | Qi.Chen@... | 2 | tvgamblin@... | 2 | open.source@... | 1 | Martin.Jansa@... | 1 | ptsneves@... | 1 | saul.wold@... | 1 | kai.kang@... | 1 | alexandre.belloni@... | 1 | martin.beeger@... | 1 | nicolas.dechesne@... | 1 | aehs29@... | 1 | thomas.perrot@... | 1 | mostthingsweb@... | 1 | david.reyna@... | 1 | ola.x.nilsson@... | 1 | Grand Total | 128 |
Thanks, Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|
|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 412 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “4.1”, “4.2”, “4.3”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs Thanks, Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|
|
Re: [meta-zephyr][PATCH 1/6] zephyr-bsp: add support for qemu-cortex-a9
While running qemu, it throws following error:
runqemu - ERROR - Failed to run qemu: qemu-system-arm: -device virtio-rng-pci,rng=rng0: No 'PCI' bus found for device 'virtio-rng-pci'
toggle quoted message
Show quoted text
-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Jon Mason
Sent: Friday, October 7, 2022 10:20 PM
To: Jon Mason <jon.mason@...>
Cc: yocto@...
Subject: Re: [yocto] [meta-zephyr][PATCH 1/6] zephyr-bsp: add support for
qemu-cortex-a9
FYI, the CI for this series can be seen at
https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/660400016
On Fri, Oct 07, 2022 at 10:11:58AM -0400, Jon Mason wrote:
Signed-off-by: Jon Mason <jon.mason@...>
---
.gitlab-ci.yml | 7 +++++++
ci/qemu-cortex-a9.yml | 10 ++++++++++
.../conf/machine/qemu-cortex-a9.conf | 20 +++++++++++++++++++
3 files changed, 37 insertions(+)
create mode 100644 ci/qemu-cortex-a9.yml create mode 100644
meta-zephyr-bsp/conf/machine/qemu-cortex-a9.conf
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 5752254..031b5c5
100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -90,6 +90,13 @@ qemu-cortex-a53:
- TOOLCHAIN: [default, zephyr-toolchain]
TESTING: testimage
+qemu-cortex-a9:
+ extends: .build
+ parallel:
+ matrix:
+ - TOOLCHAIN: [default, zephyr-toolchain]
+ TESTING: testimage
+
qemu-cortex-m0:
extends: .build
parallel:
diff --git a/ci/qemu-cortex-a9.yml b/ci/qemu-cortex-a9.yml new file
mode 100644 index 0000000..cc44730
--- /dev/null
+++ b/ci/qemu-cortex-a9.yml
@@ -0,0 +1,10 @@
+header:
+ version: 11
+ includes:
+ - ci/base.yml
+
+local_conf_header:
+ failing_tests: |
+ ZEPHYRTESTS:remove = "common queue"
+
+machine: qemu-cortex-a9
diff --git a/meta-zephyr-bsp/conf/machine/qemu-cortex-a9.conf
b/meta-zephyr-bsp/conf/machine/qemu-cortex-a9.conf
new file mode 100644
index 0000000..9dfee42
--- /dev/null
+++ b/meta-zephyr-bsp/conf/machine/qemu-cortex-a9.conf
@@ -0,0 +1,20 @@
+#@TYPE: Machine
+#@NAME: qemu-cortex-a9
+#@DESCRIPTION: Machine for Zephyr BOARD qemu_cortex_a9
+
+DEFAULTTUNE ?= "cortexa9"
+require conf/machine/include/qemu.inc require
+conf/machine/include/arm/armv7a/tune-cortexa9.inc
+
+TCLIBC = "newlib"
+
+# For runqemu
+QB_SYSTEM_NAME = "qemu-system-arm"
+QB_MACHINE = "-machine xilinx-zynq-a9"
+QB_CPU = "-cpu cortex-a9"
+QB_GRAPHICS = "-nographic -vga none"
+QB_OPT_APPEND = "-icount shift=3,align=off,sleep=off -rtc clock=vm"
+
+# Zephyr RTOS settings
+ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
+ARCH:qemu-cortex-a9 = "arm"
--
2.17.1
|
|
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.20.rc2)
Hi all,
Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.20.rc2. We are planning to execute following tests for this cycle:
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. NUC 7
3. NUC 6
4. Edgerouter
5. Beaglebone
ETA for completion this Friday, October 14.
Best regards,
Jing Hui
toggle quoted message
Show quoted text
-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Tuesday, 11 October, 2022 1:53 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.20.rc2)
A build flagged for QA (yocto-3.1.20.rc2) was completed on the autobuilder
and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.1.20.rc2
Build hash information:
bitbake: 048d682b031644fb9f0d41a489bacb873aa27bd7
meta-agl: da4775d226b2a231e27e8c8995c20fdd3c73f08a
meta-arm: 08c44df351ae1913f41de8388981b03e21235f09
meta-aws: 052c9a5f8532ed96487df37bae2f598c129d7d01
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: ed616c50ea329ba6fe68642cfc8bf8c6b8b61beb
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 6792ebdd966aa0fb662989529193a0940fbfee00
meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39
oecore: dbad46a0079843b380cf3dda6008b12ab9526688
poky: 7f9b7f912e13451a4cd03b10a8090a5def68dc39
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
|
|
|
Re: QA notification for completed autobuilder build (yocto-3.1.20.rc2)
We happened to hit another known autobuilder intermittent issue on the qemuppc build: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14824The worker happened to be heavily loaded at the time, and a subsequent run was successful: https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/5935Steve On Mon, Oct 10, 2022 at 7:53 AM Pokybuild User <pokybuild@...> wrote:
A build flagged for QA (yocto-3.1.20.rc2) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.1.20.rc2
Build hash information:
bitbake: 048d682b031644fb9f0d41a489bacb873aa27bd7
meta-agl: da4775d226b2a231e27e8c8995c20fdd3c73f08a
meta-arm: 08c44df351ae1913f41de8388981b03e21235f09
meta-aws: 052c9a5f8532ed96487df37bae2f598c129d7d01
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: ed616c50ea329ba6fe68642cfc8bf8c6b8b61beb
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 6792ebdd966aa0fb662989529193a0940fbfee00
meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39
oecore: dbad46a0079843b380cf3dda6008b12ab9526688
poky: 7f9b7f912e13451a4cd03b10a8090a5def68dc39
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
|
|
|
QA notification for completed autobuilder build (yocto-3.1.20.rc2)
Pokybuild User <pokybuild@...>
A build flagged for QA (yocto-3.1.20.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.20.rc2Build hash information: bitbake: 048d682b031644fb9f0d41a489bacb873aa27bd7 meta-agl: da4775d226b2a231e27e8c8995c20fdd3c73f08a meta-arm: 08c44df351ae1913f41de8388981b03e21235f09 meta-aws: 052c9a5f8532ed96487df37bae2f598c129d7d01 meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac meta-intel: ed616c50ea329ba6fe68642cfc8bf8c6b8b61beb meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 meta-openembedded: 6792ebdd966aa0fb662989529193a0940fbfee00 meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39 oecore: dbad46a0079843b380cf3dda6008b12ab9526688 poky: 7f9b7f912e13451a4cd03b10a8090a5def68dc39 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@...
|
|
|
Re: [PATCH yocto-autobuilder-helper] scripts: run-docs-build: make the workdir pristine between builds
Hi Quentin, On Wed, 5 Oct 2022 10:55:44 +0200 Quentin Schulz <quentin.schulz@...> wrote: Hi Luka,
On 10/4/22 22:54, Luca Ceresoli wrote:
Hi Quentin,
On Tue, 4 Oct 2022 10:15:20 +0200
Quentin Schulz <quentin.schulz@...> wrote:
Hi Luca,
On 10/3/22 23:15, Luca Ceresoli wrote:
Hi Quentin,
On Mon, 3 Oct 2022 19:04:01 +0200
"Quentin Schulz" <foss@...> wrote:
From: Quentin Schulz <quentin.schulz@...>
It happened that the git repositories were dirty and resulted in
incorrect files being used. Let's use git clean -ffdx to force a
completely clean git repositories before and after checking out a branch
so that nothing is left from or to another branch build
Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
scripts/run-docs-build | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index c6b3965..69e3257 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -61,6 +61,7 @@ for branch in 1.46 $(git branch --remote --contains "$first_sphinx_commit" --for
echo Building bitbake $branch branch
git checkout $branch
+ git clean -ffdx
git checkout origin/master releases.rst
make clean
SPHINXOPTS="-j auto" make publish
@@ -80,7 +81,7 @@ for branch in 1.46 $(git branch --remote --contains "$first_sphinx_commit" --for
fi
cp -r ./_build/final/* $outputdir/bitbake/$branch
- git reset --hard
+ git clean -ffdx Sure this is correct? 'git clean -ffdx' does not revert changes to
tracked files, be them staged or not.
Nope, not sure this is correct. I misread git clean manpage, we should
have a git reset --hard and git clean -ffdx. Now the question is when
those are necessary because with this patch we do it twice, before and
after the git checkout. I did this because I remember doing checkouts
between branches of U-Boot/kernel and while the pre-checkout branch was
not dirty, the after-checkout branch was dirty. I assume this might have
something to do with build artifacts of the pre-checkout build that
weren't .gitignored in the afer-checkout branch? Something that git
clean -ffdx should tackle I think.
Sooo, I guess only having git reset --hard and git clean -ffdx before a
checkout should be enough and we don't need them both before and after
the checkout like I did in this patch? I think 'reset --hard' + 'clean -ffdx' only before the checkout should
be enough. However I'm not sure whether there are corner cases such as
a file that is .gitignored in commit A and versioned in commit B or
similar. Perhaps worth trying with reset+clean only before, and see I guess it does not hurt to be on the safe side by having them before
and after the git checkout then? Since the current issue went unnoticed
for months... Sorry for the delayed reply. It took a while before I found a little time to look at the script code... Indeed cleaning before _and_ after would be safe, even though perhaps unneeded. what happens. However I don't know exactly the initial problem you're
trying to fix.
https://lore.kernel.org/yocto-docs/e50abe3c777e4a23a752a3ec25ad0b2a@axis.com/T/#t
Ah, interesting. Thanks for the link. Why not adding it to your commit message, for reference? Best regards. -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
|
|
|
Re: QA notification for completed autobuilder build (yocto-.rc1)
Richard let me know that a missing release number will result in a
broken build for QA, so I will run a 3.1.20-rc2 build with this
corrected.
Again, sorry for the confusion.
Steve
On Mon, Oct 10, 2022 at 4:10 AM Steve Sakoman via
lists.yoctoproject.org <steve=sakoman.com@...>
wrote:
toggle quoted message
Show quoted text
This was the 3.1.20 release build. I somehow neglected to fill in the
release number on the build form. Sorry for the confusion.
There was one failure in the build -- a known autobuilder intermittent issue:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14522
I reran this and it passed:
https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/5931
Steve
On Mon, Oct 10, 2022 at 2:18 AM Pokybuild User
<pokybuild@...> wrote:
A build flagged for QA (yocto-.rc1) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-.rc1
Build hash information:
bitbake: 048d682b031644fb9f0d41a489bacb873aa27bd7
meta-agl: da4775d226b2a231e27e8c8995c20fdd3c73f08a
meta-arm: 08c44df351ae1913f41de8388981b03e21235f09
meta-aws: 052c9a5f8532ed96487df37bae2f598c129d7d01
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: ed616c50ea329ba6fe68642cfc8bf8c6b8b61beb
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 6792ebdd966aa0fb662989529193a0940fbfee00
meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39
oecore: dbad46a0079843b380cf3dda6008b12ab9526688
poky: 7f9b7f912e13451a4cd03b10a8090a5def68dc39
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
|
|
|
Re: QA notification for completed autobuilder build (yocto-.rc1)
This was the 3.1.20 release build. I somehow neglected to fill in the release number on the build form. Sorry for the confusion. There was one failure in the build -- a known autobuilder intermittent issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14522I reran this and it passed: https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/5931Steve On Mon, Oct 10, 2022 at 2:18 AM Pokybuild User <pokybuild@...> wrote:
A build flagged for QA (yocto-.rc1) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-.rc1
Build hash information:
bitbake: 048d682b031644fb9f0d41a489bacb873aa27bd7
meta-agl: da4775d226b2a231e27e8c8995c20fdd3c73f08a
meta-arm: 08c44df351ae1913f41de8388981b03e21235f09
meta-aws: 052c9a5f8532ed96487df37bae2f598c129d7d01
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: ed616c50ea329ba6fe68642cfc8bf8c6b8b61beb
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 6792ebdd966aa0fb662989529193a0940fbfee00
meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39
oecore: dbad46a0079843b380cf3dda6008b12ab9526688
poky: 7f9b7f912e13451a4cd03b10a8090a5def68dc39
This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...
|
|
|
Re: Changing git url of qemu
Not really: I wanted to see your real name, the name of your company,
or your customer, and some kind of description or link to the product.
Since you are porting the app to vulkan, you have the source code, and
so do not have to build it for aarch64, at least initially. Keep in
mind the performance too.
Alex
toggle quoted message
Show quoted text
On Mon, 10 Oct 2022 at 15:23, PHIL <heideggm@...> wrote:
I have an OpenGLES 3.1 based app for Weston that runs on Aarch64 Linux. I can start it sucessfully in emulated Poky. Now I port this app to Vulkan so I need an Aarch64-Vulkan-Weston test suite.
If that is the info you wanted.
Am 10. Oktober 2022 15:04:18 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
You still have not introduced yourself.
I have reproduced; the key difference is that you are building for
qemuarm64. This does seem like a bug somewhere, but you can work
around it if you build for qemux86-64 - you should do this anyway
because otherwise the performance of the software renderer and
everything else in qemu (without kvm) will be appalling.
Alex
On Mon, 10 Oct 2022 at 09:49, PHIL <heideggm@...> wrote:
Sorry for being strenuous! I just really want to get this going and I've ran out of ideas. All I can do at the moment is to express my gratitude dor the time you've already invested.
I've gathered some data that hopefully has everything you need. This includes:
Poky Commit
My local recipe diff
Poky.conf
Output from bitbake layers and recipe
Output from bitbake core-image-weston
I can provide more if you give me the command!
Regards
Am 10. Oktober 2022 05:55:35 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
It works for me. If it does not work for you, you need to show the full content of your local modifications and full content of error messages, and precise revisions of all of the layers and poky. And keep in mind it’s volunteer help and no one is obliged to carry you to a solution, especially when you have not introduced yourself and your goal properly. It’s far easier to just stop answering.
Otherwise, commercial support is available. From my company (linutronix) as well.
Alex
On Mon 10. Oct 2022 at 0.29, PHIL <heideggm@...> wrote:
Any more ideas?
Am 30. September 2022 22:53:22 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
That depends on what is your target. If you're running qemu on a x86
host, it's better to not do software emulation and build for
qemux86_64 as well, and then run qemu with kvm, so it executes
directly on the host CPU.
Alex
On Fri, 30 Sept 2022 at 22:50, PHIL <heideggm@...> wrote:
X86-64 is right or do you mean arm?
Am 30. September 2022 22:39:44 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
You might want to try enabling gallium-llvm only for the target mesa:
PACKAGECONFIG:append:x86-64:pn-mesa = ' gallium-llvm'
Alex
On Fri, 30 Sept 2022 at 22:24, Edgar Mobile <heideggm@...> wrote:
I deleted the whole build directory, recreated it, only added the arm switch in local conf and your changes for mesa.inc.
After a few hours of building core-image-weston it again complains that it tries to copy llcm-config14.0.6 over itself. I don't know what to do anymore.
________________________________
From: Alexander Kanavin <alex.kanavin@...>
Sent: Thursday, September 29, 2022 10:46 AM
To: PHIL <heideggm@...>
Cc: Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Changing git url of qemu
You need to build mesa, not mesa-native. And please show exact changes you made.
Alex
On Thu 29. Sep 2022 at 12.28, PHIL <heideggm@...> wrote:
Tried in a sifferent machine with wednesday poky master
Building mesa-native gives the error
cp: '/media/user/SSD1TB/yoctoqemu/poky/build-virgl/tmp/work/x86_64-linux/mesa-native/2_22.2.0-r0/recipe-sysroot-native/usr/bin/llvm-config14.0.6' and '/media/user/SSD1TB/yoctoqemu/poky/build-virgl/tmp/work/x86_64-linux/mesa-native/2_22.2.0-r0/recipe-sysroot-native/usr/bin/llvm-config14.0.6' are the same file
Am 28. September 2022 13:37:05 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
Try latest poky master?
Alex
On Wed, 28 Sept 2022 at 13:23, PHIL <heideggm@...> wrote:
Mesa build fails. It complains that it copies llvm-config14.0.6 to the same file.
Am 28. September 2022 12:48:04 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
The following works for me. I get
tmp/work/core2-64-poky-linux/mesa/2_22.2.0-r0/packages-split/mesa-vulkan-drivers/usr/lib/libvulkan_intel.so
tmp/work/core2-64-poky-linux/mesa/2_22.2.0-r0/packages-split/mesa-vulkan-drivers/usr/lib/libvulkan_lvp.so
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -88,6 +88,7 @@ def strip_comma(s):
PACKAGECONFIG = " \
gallium \
+ gallium-llvm \
${@bb.utils.filter('DISTRO_FEATURES', 'x11 vulkan wayland', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl
gles gbm virgl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'dri3', '', d)} \
@@ -108,7 +109,7 @@ PACKAGECONFIG[dri3] = "-Ddri3=enabled,
-Ddri3=disabled, xorgproto libxshmfence"
# Vulkan drivers need dri3 enabled
# amd could be enabled as well but requires gallium-llvm with llvm >= 3.9
-VULKAN_DRIVERS = ""
+VULKAN_DRIVERS = "swrast"
VULKAN_DRIVERS:append:x86:class-target = ",intel"
VULKAN_DRIVERS:append:x86-64:class-target = ",intel"
VULKAN_DRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG',
'freedreno', ',freedreno', '', d)}"
Alex
On Wed, 28 Sept 2022 at 11:49, PHIL <heideggm@...> wrote:
Also vulkan-drivers is empty in meson generated by bitbake. If I add it manually it will complain that llvm is disabled. How would I enable it?
Am 28. September 2022 10:51:26 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
I think for software vulkan you need to pass in
-Dvulkan-drivers=swrast when building mesa for the target.
Alex
On Wed, 28 Sept 2022 at 10:44, PHIL <heideggm@...> wrote:
I asked the author so I assume he would have told me. Apparently the virglrenderer branch is obsolete.
Currently my only changes from poky master are adding vulkan opengl x11 to distro features and vulkan-samples vulkan-loader vulkan-tools virglrenderer to core image extra install in local.conf.
I also added virtio-experimental flag to mesa and virglrenderer meson recipes.
I still get ERROR_INCOMPATIBLE_DRIVER when running vulkaninfo.
What am I missing for Software Mode?
Am 28. September 2022 10:29:28 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
I would first check whether any of that work in the branch has meanwhile landed upstream. The post is from 2021.
Have you tried the software Vulkan in the guest?
Alex
On Wed 28. Sep 2022 at 10.21, PHIL <heideggm@...> wrote:
I try to enable vulkan according to this tutorial
https://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/
According to the author the modified qemu branch is still necessary so I want to enable that.
Am 28. September 2022 10:14:24 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
You need to clarify what you want to do exactly. Why can’t you use the existing recipe?
Alex
On Wed 28. Sep 2022 at 9.58, Edgar Mobile <heideggm@...> wrote:
Greetings,
I want to change the git repo url in order to test the Venus driver. Can someone tell me which variable in which recipe I'd have to set?
Regards
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
________________________________
Links: You receive all messages sent to this group.
View/Reply Online (#58196): https://lists.yoctoproject.org/g/yocto/message/58196
Mute This Topic: https://lists.yoctoproject.org/mt/93968127/1686489
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@...]
________________________________
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
|
|
Re: Changing git url of qemu
I have an OpenGLES 3.1 based app for Weston that runs on Aarch64 Linux. I can start it sucessfully in emulated Poky. Now I port this app to Vulkan so I need an Aarch64-Vulkan-Weston test suite. If that is the info you wanted. Am 10. Oktober 2022 15:04:18 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
You still have not introduced yourself.
I have reproduced; the key difference is that you are building for
qemuarm64. This does seem like a bug somewhere, but you can work
around it if you build for qemux86-64 - you should do this anyway
because otherwise the performance of the software renderer and
everything else in qemu (without kvm) will be appalling.
Alex
On Mon, 10 Oct 2022 at 09:49, PHIL <heideggm@...> wrote:
Sorry for being strenuous! I just really want to get this going and I've ran out of ideas. All I can do at the moment is to express my gratitude dor the time you've already invested.
I've gathered some data that hopefully has everything you need. This includes:
Poky Commit
My local recipe diff
Poky.conf
Output from bitbake layers and recipe
Output from bitbake core-image-weston
I can provide more if you give me the command!
Regards
Am 10. Oktober 2022 05:55:35 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
It works for me. If it does not work for you, you need to show the full content of your local modifications and full content of error messages, and precise revisions of all of the layers and poky. And keep in mind it’s volunteer help and no one is obliged to carry you to a solution, especially when you have not introduced yourself and your goal properly. It’s far easier to just stop answering.
Otherwise, commercial support is available. From my company (linutronix) as well.
Alex
On Mon 10. Oct 2022 at 0.29, PHIL <heideggm@...> wrote:
Any more ideas?
Am 30. September 2022 22:53:22 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
That depends on what is your target. If you're running qemu on a x86
host, it's better to not do software emulation and build for
qemux86_64 as well, and then run qemu with kvm, so it executes
directly on the host CPU.
Alex
On Fri, 30 Sept 2022 at 22:50, PHIL <heideggm@...> wrote:
X86-64 is right or do you mean arm?
Am 30. September 2022 22:39:44 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
You might want to try enabling gallium-llvm only for the target mesa:
PACKAGECONFIG:append:x86-64:pn-mesa = ' gallium-llvm'
Alex
On Fri, 30 Sept 2022 at 22:24, Edgar Mobile <heideggm@...> wrote:
I deleted the whole build directory, recreated it, only added the arm switch in local conf and your changes for mesa.inc.
After a few hours of building core-image-weston it again complains that it tries to copy llcm-config14.0.6 over itself. I don't know what to do anymore.
From: Alexander Kanavin <alex.kanavin@...>
Sent: Thursday, September 29, 2022 10:46 AM
To: PHIL <heideggm@...>
Cc: Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Changing git url of qemu
You need to build mesa, not mesa-native. And please show exact changes you made.
Alex
On Thu 29. Sep 2022 at 12.28, PHIL <heideggm@...> wrote:
Tried in a sifferent machine with wednesday poky master
Building mesa-native gives the error
cp: '/media/user/SSD1TB/yoctoqemu/poky/build-virgl/tmp/work/x86_64-linux/mesa-native/2_22.2.0-r0/recipe-sysroot-native/usr/bin/llvm-config14.0.6' and '/media/user/SSD1TB/yoctoqemu/poky/build-virgl/tmp/work/x86_64-linux/mesa-native/2_22.2.0-r0/recipe-sysroot-native/usr/bin/llvm-config14.0.6' are the same file
Am 28. September 2022 13:37:05 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
Try latest poky master?
Alex
On Wed, 28 Sept 2022 at 13:23, PHIL <heideggm@...> wrote:
Mesa build fails. It complains that it copies llvm-config14.0.6 to the same file.
Am 28. September 2022 12:48:04 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
The following works for me. I get
tmp/work/core2-64-poky-linux/mesa/2_22.2.0-r0/packages-split/mesa-vulkan-drivers/usr/lib/libvulkan_intel.so
tmp/work/core2-64-poky-linux/mesa/2_22.2.0-r0/packages-split/mesa-vulkan-drivers/usr/lib/libvulkan_lvp.so
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -88,6 +88,7 @@ def strip_comma(s):
PACKAGECONFIG = " \
gallium \
+ gallium-llvm \
${@bb.utils.filter('DISTRO_FEATURES', 'x11 vulkan wayland', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl egl
gles gbm virgl', '', d)} \
${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'dri3', '', d)} \
@@ -108,7 +109,7 @@ PACKAGECONFIG[dri3] = "-Ddri3=enabled,
-Ddri3=disabled, xorgproto libxshmfence"
# Vulkan drivers need dri3 enabled
# amd could be enabled as well but requires gallium-llvm with llvm >= 3.9
-VULKAN_DRIVERS = ""
+VULKAN_DRIVERS = "swrast"
VULKAN_DRIVERS:append:x86:class-target = ",intel"
VULKAN_DRIVERS:append:x86-64:class-target = ",intel"
VULKAN_DRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG',
'freedreno', ',freedreno', '', d)}"
Alex
On Wed, 28 Sept 2022 at 11:49, PHIL <heideggm@...> wrote:
Also vulkan-drivers is empty in meson generated by bitbake. If I add it manually it will complain that llvm is disabled. How would I enable it?
Am 28. September 2022 10:51:26 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
I think for software vulkan you need to pass in
-Dvulkan-drivers=swrast when building mesa for the target.
Alex
On Wed, 28 Sept 2022 at 10:44, PHIL <heideggm@...> wrote:
I asked the author so I assume he would have told me. Apparently the virglrenderer branch is obsolete.
Currently my only changes from poky master are adding vulkan opengl x11 to distro features and vulkan-samples vulkan-loader vulkan-tools virglrenderer to core image extra install in local.conf.
I also added virtio-experimental flag to mesa and virglrenderer meson recipes.
I still get ERROR_INCOMPATIBLE_DRIVER when running vulkaninfo.
What am I missing for Software Mode?
Am 28. September 2022 10:29:28 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
I would first check whether any of that work in the branch has meanwhile landed upstream. The post is from 2021.
Have you tried the software Vulkan in the guest?
Alex
On Wed 28. Sep 2022 at 10.21, PHIL <heideggm@...> wrote:
I try to enable vulkan according to this tutorial
https://www.collabora.com/news-and-blog/blog/2021/11/26/venus-on-qemu-enabling-new-virtual-vulkan-driver/
According to the author the modified qemu branch is still necessary so I want to enable that.
Am 28. September 2022 10:14:24 MESZ schrieb Alexander Kanavin <alex.kanavin@...>:
You need to clarify what you want to do exactly. Why can’t you use the existing recipe?
Alex
On Wed 28. Sep 2022 at 9.58, Edgar Mobile <heideggm@...> wrote:
Greetings,
I want to change the git repo url in order to test the Venus driver. Can someone tell me which variable in which recipe I'd have to set?
Regards
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Links: You receive all messages sent to this group.
View/Reply Online (#58196): https://lists.yoctoproject.org/g/yocto/message/58196
Mute This Topic: https://lists.yoctoproject.org/mt/93968127/1686489
Group Owner: yocto+owner@...
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [alex.kanavin@...]
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
|
|
