[yocto] Fwd: [meta-raspberrypi] Problem with adding udev rules

[Markus W]

Hi!

I want to append the rules in the
recipe-core/udev/udev-rules-rpi/99-com.rules with the rules below from
within my own recipe. I can´t figure out how to do that.

I have tried to add those rules as separate rules file in a recipe in
my own layer. After the build I can see that the rules file is in the
correct directory /etc/udev/rules.d (next to 99-com.rules) but the
rules didn't get applied. The groups below I have created by
inheriting the useradd class (GROUPADD_PARAM_${PN} = "-r spi; -r i2c;
-r gpio") in a different layer with a higher priority than the layer
with the rules recipe.

Not sure why this is not working. Any suggestions?

90-interfaces.rules file:

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770
/sys/devices/virtual/gpio;\
chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

Regards,
Markus
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] Added info for ovfm

[Dimitris Tassopoulos]

I've forgot to format...

>From 89711eb7143bd832fb150442b9ca63fdf80d53fb Mon Sep 17 00:00:00 2001
From: Dimitris Tassopoulos 
Date: Mon, 5 Nov 2018 23:18:25 +0100
Subject: [PATCH] Added description of the ovmf option in runqemu

The current documentation doesn't have any info for the ovmf option.
In case you build a QEMU image with the grub-efi bootloader, then the
qemu image needs the ovmf firmware to boot. Therefore, when using the
runqemu script you need to pass the ovmf option. I believe this is
needed as without this info there's no hint how to boot a UEFI image.

I've added a sample example with the other existing ones and the option
in the dev-manual-qemu.xml. I've also linked the grub-efi to the class,
so it's linked in the mega-manual. I've build the documentation:

$ make DOC=mega-manual

and tested the edit and that the link works.
---
 documentation/dev-manual/dev-manual-qemu.xml | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/documentation/dev-manual/dev-manual-qemu.xml
b/documentation/dev-manual/dev-manual-qemu.xml
index 4e7b5de4e..365b5c577 100644
--- a/documentation/dev-manual/dev-manual-qemu.xml
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -508,6 +508,7 @@
runqemu tmp/deploy/images/qemux86/qemuboot.conf
runqemu qemux86-64 core-image-sato ext4
runqemu qemux86-64 wic-image-minimal wic
+   runqemu qemux86-64 core-image-minimal wic ovmf
runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial
runqemu qemux86
iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz...
runqemu qemux86 qemuparams="-m 256"
@@ -678,6 +679,12 @@ qemux86" or "qemux86-64".
 publicvnc:
 Enables a VNC server open to all hosts.
 
+
+ovmf:
+Enables support for UEFI within QEMU. This option can
be used with the
+grub-efi
+class.
+
 
 
 
-- 

On Mon, Nov 5, 2018 at 11:22 PM Dimitris Tassopoulos 
wrote:

> Hi all, since I don't have permission to push, I'm sending the patch by
> email.
> This is the commit message and patch
>
> Added description of the ovmf option in runqemu
>
> The current documentation doesn't have any info for the ovmf option.
> In case you build a QEMU image with the grub-efi bootloader, then the
> qemu image needs the ovmf firmware to boot. Therefore, when using the
> runqemu script you need to pass the ovmf option. I believe this is
> needed as without this info there's no hint how to boot a UEFI image.
>
> I've added a sample example with the other existing ones and the option
> in the dev-manual-qemu.xml. I've also linked the grub-efi to the class,
> so it's linked in the mega-manual. I've build the documentation:
>
> $ make DOC=mega-manual
>
> and tested the edit and that the link works.
>
> index 4e7b5de4e..365b5c577 100644
> @@ -508,6 +508,7 @@
> runqemu tmp/deploy/images/qemux86/qemuboot.conf
> runqemu qemux86-64 core-image-sato ext4
> runqemu qemux86-64 wic-image-minimal wic
> +   runqemu qemux86-64 core-image-minimal wic ovmf
> runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial
> runqemu qemux86
> iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz...
> runqemu qemux86 qemuparams="-m 256"
> @@ -678,6 +679,12 @@ qemux86" or "qemux86-64".
>  publicvnc:
>  Enables a VNC server open to all hosts.
>  
> +
> +ovmf:
> +Enables support for UEFI within QEMU. This option can
> be used with the
> + linkend='ref-classes-grub-efi'>grub-efi
> +class.
> +
>  
>  
>  
>
>
> Regards,
> Dimitris
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][PATCH] Added info for ovfm

[Dimitris Tassopoulos]

Hi all, since I don't have permission to push, I'm sending the patch by
email.
This is the commit message and patch

Added description of the ovmf option in runqemu

The current documentation doesn't have any info for the ovmf option.
In case you build a QEMU image with the grub-efi bootloader, then the
qemu image needs the ovmf firmware to boot. Therefore, when using the
runqemu script you need to pass the ovmf option. I believe this is
needed as without this info there's no hint how to boot a UEFI image.

I've added a sample example with the other existing ones and the option
in the dev-manual-qemu.xml. I've also linked the grub-efi to the class,
so it's linked in the mega-manual. I've build the documentation:

$ make DOC=mega-manual

and tested the edit and that the link works.

index 4e7b5de4e..365b5c577 100644
@@ -508,6 +508,7 @@
runqemu tmp/deploy/images/qemux86/qemuboot.conf
runqemu qemux86-64 core-image-sato ext4
runqemu qemux86-64 wic-image-minimal wic
+   runqemu qemux86-64 core-image-minimal wic ovmf
runqemu path/to/bzImage-qemux86.bin path/to/nfsrootdir/ serial
runqemu qemux86
iso/hddimg/wic.vmdk/wic.qcow2/wic.vdi/ramfs/cpio.gz...
runqemu qemux86 qemuparams="-m 256"
@@ -678,6 +679,12 @@ qemux86" or "qemux86-64".
 publicvnc:
 Enables a VNC server open to all hosts.
 
+
+ovmf:
+Enables support for UEFI within QEMU. This option can
be used with the
+grub-efi
+class.
+
 
 
 


Regards,
Dimitris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi]

[Markus W]

Hi!

I want to append the rules in the
recipe-core/udev/udev-rules-rpi/99-com.rules with the rules below from
within my own recipe. I can´t figure out how to do that.

I have tried to add those rules as separate rules file in a recipe in
my own layer. After the build I can see that the rules file is in the
correct directory /etc/udev/rules.d (next to 99-com.rules) but the
rules didn't get applied. The groups below I have created by
inheriting the useradd class (GROUPADD_PARAM_${PN} = "-r spi; -r i2c;
-r gpio") in a different layer with a higher priority than the layer
with the rules recipe.

Not sure why this is not working. Any suggestions?

90-interfaces.rules file:

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770
/sys/devices/virtual/gpio;\
chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
'"

Regards,
Markus
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am to 8:30am on the first Tuesday (PDT)

[Jolley, Stephen K]

All,

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am 
PDT tomorrow.  We will continue the YP 2.7 Planning effort at this time.  If 
you wish to see the notes please request access to the google doc: 
https://docs.google.com/document/d/15jB6nUJU2wrtnu6w07L9RZpNlj6AoxSTPEX5aELts1g/edit?usp=sharing.
  I have posted my proposed release schedule in this document and we will 
discuss that first in the meeting.

Yocto Project Technical Team Meeting: We encourage people attending the meeting 
to logon and announce themselves on the Yocto Project IRC chancel during the 
meeting (optional):
Yocto IRC: http://webchat.freenode.net/?channels=#yocto

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

WhenMonthly from 8am to 8:30am on the first Tuesday Pacific Time
Where   Zoom Meeting: https://zoom.us/j/990892712

Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•Cell:  (208) 244-4460
• Email:stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Source Mirroring - Now working correctly

[Richard Purdie]

Hi,

At ELC-E/OEDEM there were reports of problems with the project's source
mirroring. We've also had reports of problems with people using http
only connections without access to git (e.g. being behind http only
proxies).

Michael and I have looked into it and there were some problems caused
by the new autobuilder changes and switches between NAS systems on that
infrastructure. Those are now resolved and all data has been updated.
The git mirroring issues were also resolved by tweaking some of the
mirroring commands.

In order to stop this regressing again without us noticing, I've also
written an oe-selftest which will ensure this continue to work as
intended and alert us if it doesn't.

If anyone does see any further oddities, please let Michael and myself
know.

Cheers,

Richard


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Install a pre-build ipkg package at build time

[Khem Raj]

On Mon, Nov 5, 2018 at 7:44 AM João Gonçalves
 wrote:
>
> Thanks, I didn't know that I could point SRC_URI to a ipk just like a 
> regullar tar file.
> I did that, pointed to our ipk server and it could download the ipk file.
> However during the do_rootfs task i got the following error:
>
> ERROR: kelvin-base-image-2.8b4-r0 do_rootfs: Error executing a python 
> function in exec_python_func() autogenerated:
>
> The stack trace of python calls that resulted in this exception/failure was:
> File: 'exec_python_func() autogenerated', lineno: 2, function: 
>  0001:
>  *** 0002:license_create_manifest(d)
>  0003:
> File: 
> '/home/joao/imx6/build/../layers/openembedded-core/meta/classes/license.bbclass',
>  lineno: 48, function: license_create_manifest
>  0044:pkg_dic = {}
>  0045:for pkg in sorted(image_list_installed_packages(d)):
>  0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR'),
>  0047:'runtime-reverse', pkg)
>  *** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
>  0049:
>  0050:pkg_dic[pkg_name] = 
> oe.packagedata.read_pkgdatafile(pkg_info)
>  0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
>  0052:pkg_lic_name = "LICENSE_" + pkg_name
> Exception: FileNotFoundError: [Errno 2] No such file or directory: 
> '/home/joao/imx6/build/tmp-glibc/pkgdata/apalis-imx6/runtime-reverse/python36'
>
> ERROR: kelvin-base-image-2.8b4-r0 do_rootfs: Function failed: 
> license_create_manifest
> ERROR: Logfile of failure stored in: 
> /home/joao/imx6/build/tmp-glibc/work/apalis_imx6-angstrom-linux-gnueabi/kelvin-base-image/2.8b4-r0/temp/log.do_rootfs.1303
> ERROR: Task 
> (/home/joao/imx6/layers/meta-kelvin/recipes-images/images/kelvin-base-image_0.2.bb:do_rootfs)
>  failed with exit code '1'
>
> I used "CLOSED" as license, i also tried put a MIT license the on "file:.." 
> of the recipe. I got the same error. Maybe it is because I do not have a 
> license file inside the ipk package, I'll test put a license file in a 
> package and try to install it.

hopefully this will fix it.

> I'am using a set of layers provided by our board vendor and they are using 
> rocko version.
>
> I could "hide" the problem by putting  the whole body of the 
> license_create_manifest function of the license.bbclass inside a try-except 
> block.
> It worked but that's not a solution.
>
> Khem Raj  escreveu no dia sexta, 2/11/2018 à(s) 16:50:
>>
>> On Fri, Nov 2, 2018 at 8:48 AM João Gonçalves
>>  wrote:
>> >
>> > Hi all,
>> >
>> > I have some pre-build opkg packages and I need to install them on my 
>> > target image, is this possible?
>> > I tried to use the bin_package class but I didn't found any example, I'm 
>> > also not sure if it can be used this way or just to install the data files 
>> > extracted from the ipkg file. Anyway I also tried to extract the binary 
>> > files form the package and use the bin_package class to install them, but 
>> > with no success.
>> >
>> > Does anyone have any example of this?
>> >
>>
>> once you point SRC_URI to your ipk
>> inherit bin_package should be then able to help in repackaging it
>> you have to post specific errors so we can see what might be going on
>>
>> > Thanks,
>> > João Gonçalves
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Unassigned Bugs - Help Needed

[Jolley, Stephen K]

All,



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 305 unassigned 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, "2.7", 
"2.8", "2.99" and "Future", the more pressing/urgent issues being in "2.7" and 
then "2.8".



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 
(stephen.k.jol...@intel.com) 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#Unassigned_Bugs


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 0/1] Module signing config

[Bruce Ashfield]

On 11/5/18 1:38 AM, Anuj Mittal wrote:

Hi Bruce,

This change adds features to enable module signing [1] when included.

CONFIG_MODULE_SIG_FORCE is included in a seprate force-signing.scc to be
used by BSPs that would want all modules to be validly signed and reject
the ones not signed or not signed using a valid key.

Please merge in 4.14 and beyond if this looks okay.


Looks fine to me. No concerns here.

   4c4a0c67fd78..dac0479ff81a  master -> master
   89791174e7f6..0f839b780ed3  yocto-4.14 -> yocto-4.14
   a28fd4843381..ed1978c99214  yocto-4.18 -> yocto-4.18
   f32f48feff9b..86fdeb05f63e  yocto-4.19 -> yocto-4.19




[1] https://www.kernel.org/doc/Documentation/admin-guide/module-signing.rst

Anuj Mittal (1):
   features/module-signing: add new feature

  features/module-signing/force-signing.cfg | 1 +
  features/module-signing/force-signing.scc | 6 ++
  features/module-signing/signing.cfg   | 4 
  features/module-signing/signing.scc   | 4 
  4 files changed, 15 insertions(+)
  create mode 100644 features/module-signing/force-signing.cfg
  create mode 100644 features/module-signing/force-signing.scc
  create mode 100644 features/module-signing/signing.cfg
  create mode 100644 features/module-signing/signing.scc



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] kernel-cache: edac: correct config

[Bruce Ashfield]

On 11/1/18 11:09 PM, Hongzhi.Song wrote:

Please merge to master/v4.19~v4.14



merged:

To ssh://g...@git.yoctoproject.org/yocto-kernel-cache
   277086f8d01e..4c4a0c67fd78  master -> master
   19c174f547e6..89791174e7f6  yocto-4.14 -> yocto-4.14
   8ae63963256e..a28fd4843381  yocto-4.18 -> yocto-4.18
   1a030a8254c6..f32f48feff9b  yocto-4.19 -> yocto-4.19



Hongzhi.Song (1):
   edac: Drop CONFIG_EDAC_MM_EDAC and add dependency

  features/edac/edac.cfg | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] of: Fix of_populate_phandle_cache compilation error

[Bruce Ashfield]

On 11/2/18 4:42 AM, He Zhe wrote:

When merging tag 'v4.18.10' into v4.18/standard/base, 05a9931 "of: fix phandle
cache creation for DTs with no phandles" from v4.18.10 introduces an undefined
label "out" and causes the follow compilation error.

drivers/of/base.c: In function 'of_populate_phandle_cache':
drivers/of/base.c:124:3: error: label 'out' used but not defined
goto out;
^~~~

This is because the base of 05a9931 has been modified by b75caf0 "of: allocate /
free phandle cache outside of the devtree_lock".

This patch picks a part of
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/commit/?h=
linux-4.18.y-rt=9866102318991051e5e99085d3c88d6483ee70d4
to fix this error, and can be dropped when rebasing above 9866102.


merged.

Bruce



Signed-off-by: He Zhe 
---
This error affects all arches building preempt-rt kernel with "of" by default.

  drivers/of/base.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ecb495df4aad..49da3726cda5 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -119,14 +119,14 @@ void of_populate_phandle_cache(void)
phandles++;
  
  	raw_spin_unlock_irqrestore(_lock, flags);

+   kfree(shadow);
  
  	if (!phandles)

-   goto out;
+   return;
  
  	cache_entries = roundup_pow_of_two(phandles);

phandle_cache_mask = cache_entries - 1;
  
-	kfree(shadow);

shadow = kcalloc(cache_entries, sizeof(*phandle_cache), GFP_KERNEL);
  
  	if (!shadow)




--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Moving to Yocto 2.3 - recipe-specific sysroots - improving the documentation

[Burton, Ross]

On Tue, 30 Oct 2018 at 07:05, CHMIELARZ Radoslaw
 wrote:
> We have a custom recipe for openssh-server which among other things had a 
> line:
>
> EXTRA_OECONF += 
> "--with-ssl-dir=${STAGING_DIR}/${MACHINE}/usr/local/openssl-1.0"

Note that the documentation barely mentions STAGING_DIR and mainly
refers to STAGING_DIR_(TARGET/HOST_NATIVE), if you'd used one of those
the migration to recipe-specific-sysroots wouldn't have been a
problem.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Server Certificate Verification Failed

[Mohammad, Jamal M]

Thanks Ross, I don't know what happened, I am not getting ssl errors now..

-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: Monday, November 5, 2018 4:00 PM
To: Mohammad, Jamal M 
Cc: Yocto-mailing-list 
Subject: Re: [yocto] Server Certificate Verification Failed

*External Message* - Use caution before opening links or attachments

On Mon, 5 Nov 2018 at 10:24, Mohammad, Jamal M 
 wrote:
> I have time correct and ca-certificates installed. This is the message 
> I get when I access it over web:  
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.
> org_git_meta-2Dintel=DwIFaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N65q
> oDnmtsyGh_QYq3kPCn-Loy2L0LHnCs=PA2AQ19Quf9OrvBIryxr6r4LBcD3PmH361TVH
> sP4Gdc=3fUG387G3k5gsEs8Eipvs3eDiXiMyWKkp0SbEZFJJ-o=
>
> This 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__git.yoctoproject.o
> rg=DwIFaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N65qoDnmtsyGh_QYq3kPCn
> -Loy2L0LHnCs=PA2AQ19Quf9OrvBIryxr6r4LBcD3PmH361TVHsP4Gdc=ec0jRo36V
> nExAGq8qmN4m720OhSJ8fHGRSQptosTeL4= page can’t be found No webpage 
> was found for the web address: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.
> org_git_meta-2Dintel=DwIFaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N65q
> oDnmtsyGh_QYq3kPCn-Loy2L0LHnCs=PA2AQ19Quf9OrvBIryxr6r4LBcD3PmH361TVH
> sP4Gdc=3fUG387G3k5gsEs8Eipvs3eDiXiMyWKkp0SbEZFJJ-o=
> HTTP ERROR 404

$ git clone 
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_git_meta-2Dintel=DwIFaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N65qoDnmtsyGh_QYq3kPCn-Loy2L0LHnCs=PA2AQ19Quf9OrvBIryxr6r4LBcD3PmH361TVHsP4Gdc=3fUG387G3k5gsEs8Eipvs3eDiXiMyWKkp0SbEZFJJ-o=
Cloning into 'meta-intel'...
remote: Counting objects: 16480, done.
remote: Compressing objects: 100% (5294/5294), done.
remote: Total 16480 (delta 9783), reused 16208 (delta 9511) Receiving objects: 
100% (16480/16480), 4.61 MiB | 397.00 KiB/s, done.
Resolving deltas: 100% (9783/9783), done.

That URL doesn't show anything useful in a browser as it's a git repository, 
not a web page.
https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject.org_cgit_cgit.cgi_meta-2Dintel_=DwIFaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N65qoDnmtsyGh_QYq3kPCn-Loy2L0LHnCs=PA2AQ19Quf9OrvBIryxr6r4LBcD3PmH361TVHsP4Gdc=doeNUplj8cXnvAq07YtHmuMyjQes91x27XlDAPMfzSg=
 is the human-readable cgit frontend.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Server Certificate Verification Failed

[Burton, Ross]

On Mon, 5 Nov 2018 at 10:24, Mohammad, Jamal M
 wrote:
> I have time correct and ca-certificates installed. This is the message I get 
> when I access it over web:  https://git.yoctoproject.org/git/meta-intel
>
> This git.yoctoproject.org page can’t be found No webpage was found for the 
> web address: https://git.yoctoproject.org/git/meta-intel
> HTTP ERROR 404

$ git clone https://git.yoctoproject.org/git/meta-intel
Cloning into 'meta-intel'...
remote: Counting objects: 16480, done.
remote: Compressing objects: 100% (5294/5294), done.
remote: Total 16480 (delta 9783), reused 16208 (delta 9511)
Receiving objects: 100% (16480/16480), 4.61 MiB | 397.00 KiB/s, done.
Resolving deltas: 100% (9783/9783), done.

That URL doesn't show anything useful in a browser as it's a git
repository, not a web page.
https://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/ is the
human-readable cgit frontend.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Recipes documentation

[Dimitris Tassopoulos]

Hi all,

this is a proposal for a feature, I hope it's the right way to do it.

It would be nice if there would be a standard way to document recipes and
then be able to read this documentation from the command line. Something
like the man pages.

For example, there could be either a variable in the recipe (e.g. MAN = "")
or
maybe better an additional file so there's no much "noise" in the recipe.
For
example it would be nice if there was an optional file like
.man
and there use preferably a markdown (or whatever) format to document the
recipe.

By documenting the recipe, I mean to have a short/long description how to
use
it properly or other valuable information.

As the yocto project gets bigger and more complicated, it would be nice if
there
was a facility like that.

There might be already and I'm not aware of that. In this case, can someone
please point me to the right direction?

Regards,
Dimitris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Server Certificate Verification Failed

[Mohammad, Jamal M]

I have time correct and ca-certificates installed. This is the message I get 
when I access it over web:  https://git.yoctoproject.org/git/meta-intel

This git.yoctoproject.org page can’t be found No webpage was found for the web 
address: https://git.yoctoproject.org/git/meta-intel
HTTP ERROR 404

Can you please check at your end whether you are able to access the website

Thanks and Regards,
Jamal



-Original Message-
From: Burton, Ross [mailto:ross.bur...@intel.com] 
Sent: Monday, November 5, 2018 3:49 PM
To: Mohammad, Jamal M 
Cc: Yocto-mailing-list 
Subject: Re: [yocto] Server Certificate Verification Failed

*External Message* - Use caution before opening links or attachments

On Mon, 5 Nov 2018 at 09:02, Mohammad, Jamal M 
 wrote:
> Fetching projects:  60% (3/5)  fatal: unable to access 
> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject
> .org_git_poky_=DwIBaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N65qoDnmts
> yGh_QYq3kPCn-Loy2L0LHnCs=2XE9zm23G_VokDDCU8pxNIKgRkDt7OH0CYapDuJ16_o
> =-6qzvrVhJNSFhN5zU9LZHfoYeSW_ig6mFGlUHTUvc2g=': server certificate 
> verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
> CRLfile: none
>
> fatal: unable to access 
> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__git.yoctoproject
> .org_git_meta-2Dintel_=DwIBaQ=gJN2jf8AyP5Q6Np0yWY19w=4h__2a8-7N6
> 5qoDnmtsyGh_QYq3kPCn-Loy2L0LHnCs=2XE9zm23G_VokDDCU8pxNIKgRkDt7OH0CYa
> pDuJ16_o=Su-QP1Q_v-DPQBFVexWNf8f_Mr8wNE5Mdg-OLw_lL0U=': server 
> certificate verification failed. CAfile: 
> /etc/ssl/certs/ca-certificates.crt CRLfile: none
>
> error: Cannot fetch poky
>
>
>
> I then tried to open the above link from website, I got a similar 
> message: NET::ERR_CERT_DATE_INVALID

These are all problems with your machine: you don't have the CA certificates 
installed, and the latter suggests that your local clock is wrong.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Server Certificate Verification Failed

[Burton, Ross]

On Mon, 5 Nov 2018 at 09:02, Mohammad, Jamal M
 wrote:
> Fetching projects:  60% (3/5)  fatal: unable to access 
> 'https://git.yoctoproject.org/git/poky/': server certificate verification 
> failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
>
> fatal: unable to access 'https://git.yoctoproject.org/git/meta-intel/': 
> server certificate verification failed. CAfile: 
> /etc/ssl/certs/ca-certificates.crt CRLfile: none
>
> error: Cannot fetch poky
>
>
>
> I then tried to open the above link from website, I got a similar message: 
> NET::ERR_CERT_DATE_INVALID

These are all problems with your machine: you don't have the CA
certificates installed, and the latter suggests that your local clock
is wrong.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Server Certificate Verification Failed

[Mohammad, Jamal M]

Hi Guys,

I am getting the following error :

Fetching projects:  60% (3/5)  fatal: unable to access 
'https://git.yoctoproject.org/git/poky/': server certificate verification 
failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
fatal: unable to access 'https://git.yoctoproject.org/git/meta-intel/': server 
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
CRLfile: none
error: Cannot fetch poky

I then tried to open the above link from website, I got a similar message: 
NET::ERR_CERT_DATE_INVALID
Can you please look into this.

Thanks and Regards,
Jamal,
Software Specialist,
NCR Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to request a certain version of a recipes for an image?

[Patrick Boettcher]

On Sun, 4 Nov 2018 18:38:18 -0800
Andre McCurdy  wrote:

> On Sun, Nov 4, 2018 at 2:30 PM Patrick Boettcher
>  wrote:
> >
> > Hi list,
> >
> > I'm using the morty-release for my device.
> >
> > My sources consists of different layers. Some application
> > specific-layers (which contains a image-recipe), our
> > BSP-provider and tooling-layers.
> >
> > It now happens that in there is package (dt-utils) which has
> > recipes in two different layers, with different versions.
> >
> > In my image-file I request the package via
> >
> > IMAGE_INSTALL += "dt-utils"
> >
> > How do I force the version of dt-utils for this image? By default it
> > selects the wrong one.
> >
> > Here's what I tried, by adding to the image-recipe:
> >
> > DEPENDS += "dt-utils (>= 2017.03.0)"
> >
> > and
> >
> > RDEPENDS += "dt-utils (>= 2017.03.0)"
> >
> > seems to have no effect. Adding the version-logic to the
> > IMAGE_INSTALL-line fails to build.
> >
> > What works is to add PREFERRED_VERSION to local.conf. But this is
> > not committable, so I'd like to avoid it.  
> 
> You can't directly influence the build of one recipe (ie dt-utils) by
> making a change in another recipe (ie the image recipe), so the
> DEPENDS and RDEPENDS style changes you have tried will not work.
> Variables in the image recipe are not visible when the dt-utils recipe
> is built.
> 
> Setting PREFERRED_VERSION from a global config file is a valid
> solution. In that case it's up to you to decide which global config to
> use - adding to local.conf, the machine config, the distro config, a
> meta layer config file will all work. Using either the distro or
> machine config would be the most typical approach - depending on
> whether you want to version preference to apply to one build
> configuration (ie one machine) or to all your builds (ie your distro).
> 
> An alternative solution would to be to change the priority of the
> recipes in the meta layer(s) which contains the dt-utils recipes. e.g.
> increasing BBFILE_PRIORITY_xxx in the layer.conf in the meta layer
> with the dt-utils recipe you want to use.

Thanks Andre, thanks Randy for clearing up my mis-conception of recipes
and conf-files. 

--
Patrick.


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto