From: Kevin Hao
The struct v4l2_input::name is an array, so the checking of
(mxc_capture_inputs[cam->current_input].name != NULL) always return
true. The issue was introduced by commit 5b1aeb69cf15 ("media: capture:
add mxc v4l2 capture driver").
Signed-off-by: Kevin Hao
---
Hi Bruce,
Please
From: Paul Gortmaker
This reverts commit 4591766ff6552339fbaa3d3c71814faef1988c2f.
This (3/5) is a part of a fix from the v6.6.7 content. However
during repeated boot testing on qemu-x86 (32 and 64) with NFS
root it hangs during the verbose printk of the PCI register layout
map. The v6.6.6
From: Paul Gortmaker
Pretty much everything is documented here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15463
...other than I have since put the reverts onto the v6.6/standard/base
(v6.6.23-118-g2d01bc1d4eea) and ran boot tests on that for 150
iterations w/o issue.
We'll still need
From: Paul Gortmaker
This reverts commit f259af26ee04f11cb2c3af0a6873a6bcb67dd338.
This (5/5) is a part of a fix from the v6.6.7 content. However
during repeated boot testing on qemu-x86 (32 and 64) with NFS
root it hangs during the verbose printk of the PCI register layout
map. The v6.6.6
From: Paul Gortmaker
This reverts commit 239bff0171a86e1bafd7da03631d74df1dfec6f1.
This (1/5) is a part of a fix from the v6.6.7 content. However
during repeated boot testing on qemu-x86 (32 and 64) with NFS
root it hangs during the verbose printk of the PCI register layout
map. The v6.6.6
From: Paul Gortmaker
This reverts commit 34c686e5be2fa1c03ae09568159a9ef37d1c7cf5.
This (4/5) is a part of a fix from the v6.6.7 content. However
during repeated boot testing on qemu-x86 (32 and 64) with NFS
root it hangs during the verbose printk of the PCI register layout
map. The v6.6.6
From: Paul Gortmaker
This reverts commit 22ca647c8f880f21881e9b2d38070dc61196a39d.
This (2/5) is a part of a fix from the v6.6.7 content. However
during repeated boot testing on qemu-x86 (32 and 64) with NFS
root it hangs during the verbose printk of the PCI register layout
map. The v6.6.6
On Fri, Apr 19, 2024 at 7:29 AM Maik Vermeulen via lists.yoctoproject.org
wrote:
%< SNIP %<
> I've also tried using the useradd.bbclass in the recipes, which allows us
> to set permissions from within the do_install task, but that started
> causing trouble when we tried to start using
Hi,
I'm wondering what the best practice is for centrally creating and
configuring users and groups, and then having certain recipes installing
files with ownership according to those users and groups.
So far we've used EXTRA_USERS_PARAMS to create a bunch of users and groups,
to segregate their
* SRC_URI =
"git://${COMPANY_GIT_REPO}/path/to/project.git;protocol=https;user=token_name:${TOKEN}"
* The https+Token was working fine with Dunfell, now I have ported this
recipe to kirkstone but it is not working and I get this error
* fatal: could not read Password for
Hi Adrian,
Hi Yoann,
I have two project when is using dunfell and another one with using Kirkstone.
with the Dunfell project I was using one recipe with fetching from git repo
like this
SRC_URI = "git://${ COMPANY_GIT_REPO }/path/to/project.git;protocol=https;
*user=token_name:${TOKEN}"*
On Fri, 2024-04-19 at 00:18 +, Pokybuild User via
lists.yoctoproject.org wrote:
>
> A build flagged for QA (yocto-5.0.rc4) was completed on the
> autobuilder and is available at:
>
>
> https://autobuilder.yocto.io/pub/releases/yocto-5.0.rc4
>
>
> Build URL:
>
12 matches
Mail list logo
