[yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc4)
A build flagged for QA (yocto-2.6.2.rc4) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc4 Build hash information: bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575 meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5 oecore: fddd3ca8490adaceab6491632cf249c2320e4fda poky: e7f0177ef3b6e06b8bc1722fca0241fef08a1530 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.pur...@linuxfoundation.org -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.6.2.rc4)
On Mon, 2019-04-15 at 08:27 +, pokybu...@fedora29-ty-1.yocto.io wrote: > A build flagged for QA (yocto-2.6.2.rc4) was completed on the > autobuilder and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-2.6.2.rc4 > > > Build hash information: > > bitbake: 7c1eb51d1e8a4c5f39bf9dddf05fb0b3598da72b > meta-gplv2: aabc30f3bd03f97326fb8596910b94639fea7575 > meta-intel: 27dadcfc7bc0de70328b02fecb841608389d22fc > meta-mingw: 6556cde16fbdf42c7edae89bb186e5ae4982eff5 > oecore: fddd3ca8490adaceab6491632cf249c2320e4fda > poky: e7f0177ef3b6e06b8bc1722fca0241fef08a1530 As discussed in the QA report thread, this is a respin of 2.6.2, one commit different to avoid the boost upgrade. The intent is to release this as 2.6.2 rather than rc3 if there is general agreement. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.rc2)
On Sun, 2019-04-14 at 23:48 +, pokybuild@centos7-ty-1.localdomain wrote: > A build flagged for QA (yocto-2.7.rc2) was completed on the > autobuilder and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-2.7.rc2 > > > Build hash information: > > bitbake: cb185efe9e88cfb12b7a3fd08f3086ca0b69c8e2 > meta-gplv2: 106ba6d2a4d08a276205c305f8485d701fe8a8f3 > meta-intel: cd2c3bfca97655999cbde645b73be712675dba92 > meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4 > oecore: f571b188177788d8ed0a7f3efe3569f153b1b0d3 > poky: 0e392026ffefee098a890c39bc3ca1f697bacb52 Note for QA: I was able to add the automated oe-selftests for the different qemu machines in this run as we discussed. This should reduce the amount of tests QA need to run. There was one failure: testseries | result_id : qemuppc | oeselftest_centos-7_qemuppc_20190414221329 runqemu.QemuTest.test_qemu_can_shutdown I believe this worked on the rc1 test run so it appears to be an intermittent failure which I'd not block release on. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] File synchronization on ubifs/xfs
Hi all, I stumbled into an file synchronization problem, and I am curious if there are more people using Yocto and ubifs/xfs/similar that have an interest of "fsync before rename"? When trying to atomically update a file a common flow is "create copy, edit copy, rename copy->original", but this does for some file systems not guarantee that the file is not empty after a power fail. A more correct flow is "create copy, edit copy, fsync copy, rename copy->original", at least according to file system developers. This has been discussed a lot and the general status seems to be that many file system developers think that applications that does not fsync before rename are broken, and many application developers think that fsync is implied at rename and this needs to be fixed in the file systems. (I am (trying to) not picking a side, and just trying to solve my problems :) ) Since some file systems common in embedded systems (UBIFS, XFS) does not implement automatic fsync before rename, this becomes a bit of a problem if applications in Yocto does not sync "correctly". One of these applications is sed (in-place edit), and I am currently working on a patch to add fsync before rename (as a feature). Busybox are not interested in the feature (as they are of the opinion that this should be solved in the file system), but I am curious if there is any interest in these kind of features in Yocto? Regards, Sebastian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependencies on other file system types for custom file system type
> Notice how the function names for squashfs are:
>
> do_image_squashfs_xz
>
> not
>
> do_image_squashfs-xz
>
> This is because shell functions/variables can't have "-" in their name.
> You need to change to us IMAGE_CMD_squashfs_xz_ubi.
I tried to basically change all "-" in the fs and variable names into "_",
but this didn't change the behaviour.
What I do not understand:
The filesystem type squashfs-xz (included in poky) uses "-",
among others also for the IMAGE_CMD name ("IMAGE_CMD_squashfs-xz").
Only the dependencies to squashfs tools are using "_":
do_image_squashfs_xz[depends] += "squashfs-tools-native:do_populate_sysroot"
In the case of squashfs_xz_ubi the IMAGE_TYPEDEP_ dependency
to sqashfs-xz is ignored.
(experimentally trying to change that dependency to squashfs
(a name without "-") does not help)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependencies on other file system types for custom file system type
On Mon, 2019-04-15 at 21:43 +0700, Eric Grunt wrote:
> > Notice how the function names for squashfs are:
> >
> > do_image_squashfs_xz
> >
> > not
> >
> > do_image_squashfs-xz
> >
> > This is because shell functions/variables can't have "-" in their
> > name.
> > You need to change to us IMAGE_CMD_squashfs_xz_ubi.
>
> I tried to basically change all "-" in the fs and variable names into
> "_",
> but this didn't change the behaviour.
> What I do not understand:
> The filesystem type squashfs-xz (included in poky) uses "-",
> among others also for the IMAGE_CMD name ("IMAGE_CMD_squashfs-xz").
> Only the dependencies to squashfs tools are using "_":
> do_image_squashfs_xz[depends] += "squashfs-tools-
> native:do_populate_sysroot"
>
> In the case of squashfs_xz_ubi the IMAGE_TYPEDEP_ dependency
> to sqashfs-xz is ignored.
> (experimentally trying to change that dependency to squashfs
> (a name without "-") does not help)
I think there is some translation code somewhere which probably
confuses things more as some bits have - and some have _. Does the
squashfs_xz image type actually work?
Cheers,
Richard
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependencies on other file system types for custom file system type
> I think there is some translation code somewhere which probably > confuses things more as some bits have - and some have _. Does the > squashfs_xz image type actually work? There is no squashfs_xz image type. squashfs-xz (by poky) works, squashfs_xz_ubi (custom type) also works, but needs to occasionally call IMAGE_CMD_squashfs-xz itself. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependencies on other file system types for custom file system type
> squashfs-xz (by poky) works, > squashfs_xz_ubi (custom type) also works To clarify, squashfs_xz_ubi was named squashfs-xz-ubi before, I renamed it in order to try to avoid using "-". -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Failed to execute GCC
Hi, I am building an image on Ubuntu 18.04 host, I got following error: unable to execute 'x86_64-linux-gnu-gcc': No such file or directory | error: command 'x86_64-linux-gnu-gcc' failed with exit status 1 I can see the x86_64-linux-gnu-gcc is available, but why it failed to find it? $ which x86_64-linux-gnu-gcc /usr/bin/x86_64-linux-gnu-gcc Thank you. Kind regards, - jh -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Yocto][meta-qt5][qtwayland]Qtwayland recipe fails with Yocto 2.5
The compilation of features.egl was failing because wayland-client.h was not found in Yocto 2.5 sysroot of QTbase. In yocto 2.2, the sysroot was common so qtbase was able to find this header even without dependencies. Adding DEPENDS=wayland in qtbase recipe is compiling qtbase and qtwayland successfully. The bitbake did not throw error for missing driver. It just printed it in logs. Warm Regards, Priyanshu Sharma On Mon, Apr 1, 2019 at 1:00 PM Priyanshu Sharma < ms.priyanshu.sha...@gmail.com> wrote: > The compilation of features.egl was failing because wayland-client.h was > not found in Yocto 2.5 sysroot of QTbase. In yocto 2.2, the sysroot was > common so qtbase was able to find this header even without dependencies. > Adding DEPENDS=wayland in qtbase recipe is compiling qtbase and qtwayland > successfully. > > The bitbake did not throw error for missing driver. It just printed it in > logs. > > Warm Regards, > Priyanshu Sharma > > On Wed, Mar 27, 2019 at 4:20 PM Priyanshu Sharma < > ms.priyanshu.sha...@gmail.com> wrote: > >> Found that the missing features.egl is provided by QTBase recipe. And in >> my case, qtbase is not compiling the feature "EGL" and thats why qtwayland >> fails to find it. >> >> egl is not included in PACKAGECONFIG of qtbase recipe. However, it used >> to be enabled with Yocto 2.2. >> Adding it PACKAGECONFIG[eg] of qtbase is not enabling it. How can egl be >> enabled in qtbase? >> >> Warm regards, >> Priyanshu Sharma >> >> On Tue, Mar 19, 2019 at 1:23 PM Priyanshu Sharma < >> ms.priyanshu.sha...@gmail.com> wrote: >> >>> Hi All, >>> >>> I'm consistently getting a build failure after upgrading Poky to 2.5 >>> from 2.2 on qtwayland >>> Yocto recipe from meta-qt5. >>> >>> The error looks like : >>> >>> | Running configuration tests... >>> | Checking for Wayland client library... yes >>> | Checking for Wayland cursor library... yes >>> | Checking for wayland-scanner... yes >>> | Checking for Wayland EGL library... yes >>> | Checking for wayland-server... yes >>> | Done running configuration tests. >>> | >>> | Configure summary: >>> | >>> | Qt Wayland Drivers: >>> | EGL no >>> | Raspberry Pi ... no >>> | XComposite EGL . no >>> | XComposite GLX . no >>> | DRM EGL no >>> | libhybris EGL .. no >>> | Qt Wayland Client yes >>> | Qt Wayland Compositor yes >>> | >>> | ERROR: Feature 'wayland-egl' was enabled, but the pre-condition >>> 'features.wayland-client && features.opengl && features.egl && >>> libs.wayland-egl' failed. >>> | >>> | ERROR: Feature 'wayland-egl' was enabled, but the pre-condition >>> 'features.wayland-server && features.opengl && features.egl && >>> libs.wayland-egl' failed. >>> | >>> | Check config.log for details. >>> | WARNING: exit code 1 from a shell command. >>> I've checked that only pre-condition "features.egl" is failing. >>> I've my own custom recipe which is providing virtual/egl and is set as >>> PREFERRED_PROVIDER also. >>> What is the missing dependency here when virtual/egl is provided? >>> What exactly is features.egl looking for? ( virtual/egl provides egl.pc ) >>> I've not changed anything in meta-qt5 layer. And the version is 5.9.2 QT5. >>> However, is fails with 5.12 also. >>> >>> >>> Warm Regards, >>> >>> Priyanshu Sharma >>> >>> >>> -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
