Re: [yocto] where is useradd-example.bb

[Greg Wilson-Lindberg]

Well this is embarrassing, apparently my searches of the Yocto source tree 
weren't very good. I tried again after sending out my question and found it 
under sources/poky/meta-skeleton.


Sorry for the noise,

Greg


From: yocto-boun...@yoctoproject.org  on behalf 
of Greg Wilson-Lindberg 
Sent: Monday, April 23, 2018 4:15:47 PM
To: yocto@yoctoproject.org
Subject: [yocto] where is useradd-example.bb


I'm trying to understand adding a user in a recipe and in the documentation it 
says to consult meta-skeleton/recipes-skeleton/useradd/useradd-example.bb. the 
meta-skeleton directory doesn't exist and I can't find the file anywhere else. 
I've done a search on the net and I don't get any hits on the file either, lots 
of references in the manuals, bot not the file.


Can anyone tell me where to find it?


Regards,

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

[yocto] where is useradd-example.bb

[Greg Wilson-Lindberg]

I'm trying to understand adding a user in a recipe and in the documentation it 
says to consult meta-skeleton/recipes-skeleton/useradd/useradd-example.bb. the 
meta-skeleton directory doesn't exist and I can't find the file anywhere else. 
I've done a search on the net and I don't get any hits on the file either, lots 
of references in the manuals, bot not the file.


Can anyone tell me where to find it?


Regards,

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

[yocto] Initializing mysql/mariadb

[Greg Wilson-Lindberg]

I'm including mysql/mariadb in to our Yocto build. I need to initialize the 
initial mysql user (the mysql recipe creates a Linux user mysql) & password and 
also the starting database. Is there any documentation on how to do this inside 
the Yocto framework?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] sdk package build question

[Janne Karhunen]

Hi,

Quick question - is the sdk compiler supposed to be able to create
executables that can be executed while the sdk package build is
ongoing?

Reason I'm asking is that my package nativesdk build errors out saying
'C compiler cannot create executables'. Reason for that seems to be
that the output (say a.out) generated by x86_64-pokysdk-linux-gcc
requests runtime linker from the SDKs final resting place
(/opt/poky..) and not from the location where the sysroot lies during
the build. How is that supposed to work?


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

[yocto] Yocto Project Technical Team Meeting

[Cetola, Stephano]

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Pacific Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN="Cetola, Stephano":MAILTO:stephano.cet...@intel.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=yocto@yoct
 oproject.org:MAILTO:yocto@yoctoproject.org
DESCRIPTION;LANGUAGE=en-US:When: Tuesday\, May 01\, 2018 8:00 AM-9:00 AM. (
 UTC-08:00) Pacific Time (US & Canada)\nWhere: Bridge Info Enclosed\n\n*~*~
 *~*~*~*~*~*~*~*\n\nhttps://www.yoctoproject.org/monthly-technical-call/\n\
 nThis month we will be discussing 2.6 planning. Please join us to help gui
 de the direction of the Yocto Project.\n\nFor more details\, see the annou
 ncement here:\n\nhttp://lists.openembedded.org/pipermail/openembedded-core
 /2018-April/150040.html\n\nCheers\,\nStephano\n\n\n
SUMMARY;LANGUAGE=en-US:Yocto Project Technical Team Meeting
DTSTART;TZID=Pacific Standard Time:20180501T08
DTEND;TZID=Pacific Standard Time:20180501T09
UID:A83D3268-7AB8-4FC9-A9D7-130A16B94237
RECURRENCE-ID;TZID=Pacific Standard Time:20180501T08
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20180423T172717Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:3
LOCATION;LANGUAGE=en-US:Bridge Info Enclosed
X-MICROSOFT-CDO-APPT-SEQUENCE:3
X-MICROSOFT-CDO-OWNERAPPTID:2116163324
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-DISALLOW-COUNTER:TRUE
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
END:VALARM
END:VEVENT
END:VCALENDAR
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW17’18

[Jordan, Robin L]

Current Dev Position: YP 2.5 M4 final close out.

Next Deadline: YP 2.5 M4 release is 4/27/18


SWAT Team Rotation:

SWAT lead is currently: Tracy.

SWAT team rotation: Stephano -> Maxin on April 27, 2018

SWAT team rotation: Maxin -> Rebecca on March 4, 2018

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

  *   Several key uninative issues were identified and fixed which should mean 
uninative is much more reliable than previously as there were some rare but 
problematic corner cases which are now fixed.
  *   Other potentially 2.5 blocking changes such as timezone issues were fixed.
  *   We have documented sstate mirror setup for poky as opt-in, not by default 
and will monitor the usage of this to see how sustainable it is.
  *   Assuming the current test build succeeds, 2.5 rc1 will be built today.
  *   An email about 2.6 planning was sent out and people are invited to the 
next monthly technical call 
(https://www.yoctoproject.org/monthly-technical-call/). The email details the 
planning process we will be following along with some of the possible ideas for 
2.6. The email is: 
http://lists.openembedded.org/pipermail/openembedded-core/2018-April/150040.html
  *   We are now tracking patch status in the tracking metrics below. The 
percentage of patches with Upstream-Status should stay at 100% now with our 
monitoring. Over time we want to reduce the percentage in the “Pending” state 
and the overall number of patches.


Planned upcoming dot releases:

YP 2.3.4 (Pyro) will be built after 2.5

YP 2.2.4 (Morty) will be built after 2.5

YP 2.4.3 (Rocko) is planned for post YP 2.5


Key YP 2.5 Dates are:

YP 2.5 M4 cut off of 4/2/18

YP 2.5 M4 release of 4/27/18


Tracking Metrics:

  *   WDD 2486 (last week 2573) 
(https://wiki.yoctoproject.org/charts/combo.html)
  *   Patches
 *   Total patches found: 1635
 *   Percentage of patches in the Pending State: 46%


Key Status Links for YP:

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features


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!]

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

Re: [yocto] Starting Hardware

[Chris Simmonds]

Hi Alejandro,

There are only a few platforms supported by Android Things, one of which
is the Raspberry Pi, so that is the obvious choice.

The RPi is well supported by Yocto Project/OpenEmbedded. You will need
the meta-raspberrypi layer, which you can find, along with many other
meta layers, at http://layers.openembedded.org. The specific one you
need is at

http://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/

There are brief instructions on building it at

https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/about/

However, since you are just beginning on your journey with
Yocto/OpenEmbedded, I would advise that you start by building the
default qemux86 emulator target first, and then move on to building the
RPi images. That way you get to learn about adding meta layers and meta
layer dependencies after you have built your first Yocto Project image.

Enjoy!
Chris



On 23/04/18 16:00, Alejandro Ariel Fachini wrote:
> Hello:
> I'm an electronic engineer from argentina and I started to work for a
> company which is starting with embedded software. I also want to work
> for my self with this technology. I am about certificate android
> programing in google and want to start with android things and also
> embedded linux.
> For these reasons i want to purchase hardware that allows me to test
> both environments or at least proper hardware for both Android things
> and Linux.
> 
> So If i purchase Raspberry Pi 3 B+, will i be able to work with Yocto?
> OR do you recommend another more supported and "fiendly" Hardware for
> starting with yocto? I understand that yocto is for A TON of different
> hardwares, but im looking for very active and supported hardware with yocto.
> 
> Regards Alejandro.-
> 
> 


-- 
Chris Simmonds, Consultant, 2net Ltd
http://www.2net.co.uk
+44 (0)1962 869003
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Usage of yocto on different (production vs debug) scenarios

[Burton, Ross]

Very curious as to what book said that, because *any* example of that
happening is a bug in the recipe itself.  I wouldn't listen to it: the YP
autobuilder has a shared sstate for three distributions * four
architectures * two libc implementations and doesn't have problems.

Ross

On 23 April 2018 at 16:23, Iván Castell  wrote:

> Thanks a lot for all your replies. I am working on a solution trying to
> get the best option of all your answers. I will come back after deciding my
> solution to share it with the community.
>
>
> Related with that shared state cache, I found some information on a e-book
> (search the text on google to find the source):
>
> "Sharing a shared state cache is possible; however, it needs to be
> approached with care. Not all changes are detected by the shared state
> cache implementation, and when this happens, some or all of the cache needs
> to be invalidated. This can cause problems when the state cache is being
> shared. The recommendation in this case depends on the use case. Developers
> working on Yocto metadata should keep the shared state cache as default,
> separated per project. However, validation and testing engineers, kernel
> and bootloader developers, and application developers would probably
> benefit from a well-maintained shared state cache."
>
>
> After reading that I'm not sure to use it because I don't understand what
> kind of "problems" can be found, and if they can be easily detected or not.
>
>
> Does some of you have any experience using a shared sstate cache?
>
>
>
>
>
> 2018-04-23 17:10 GMT+02:00 Burton, Ross :
>
>> On 20 April 2018 at 11:47, Uwe Geuder  wrote:
>> > But can you share state between distros? Isn't the purpose of distros to
>> > use different options (variable settings) so the state would always be
>> > different?
>>
>> If the input to the recipe is different then the hashes would be
>> different so the content won't conflict.  You can definitely share
>> sstate between DISTROs.
>>
>> Ross
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
> --
>
>
>
>
> *NOTA LEGAL*
> Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
> contiene información de carácter confidencial exclusivamente dirigida a su
> destinatario y se encuentra protegido por Ley. Cualquier persona distinta
> de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
> o impresión total o parcial. Si ha recibido este correo electrónico por
> error, se ruega lo notifique de inmediato al remitente borrando el mensaje
> original juntamente con sus ficheros anexos. Gracias.
>
> De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza
> la adopción de las medidas necesarias para asegurar el tratamiento
> confidencial de los datos de carácter personal. Así mismo le informamos de
> la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
> SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
> la relación que mantenemos con usted. Si lo desea, puede ejercer sus
> derechos de acceso, rectificación, cancelación y oposición mediante un
> escrito a la siguiente dirección: i...@nayarsystems.com
>
> *LEGAL NOTE*
> This email and any attachments to it contains is confidential information
> exclusively intended for the recipients. Any divulgation, copy or
> distribution to third parties is prohibited without written permission of
> NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
> the sender immediately. In accordance with Law 15/1999 of 13 December on
> the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
> has adopted the necessary measures to ensure the confidential treatment of
> personal information. We also inform you that you can exercise your access,
> rectification, cancellation and opposition rights by send us a mail to:
> i...@nayarsystems.com
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Usage of yocto on different (production vs debug) scenarios

[Iván Castell]

Thanks a lot for all your replies. I am working on a solution trying to get
the best option of all your answers. I will come back after deciding my
solution to share it with the community.


Related with that shared state cache, I found some information on a e-book
(search the text on google to find the source):

"Sharing a shared state cache is possible; however, it needs to be
approached with care. Not all changes are detected by the shared state
cache implementation, and when this happens, some or all of the cache needs
to be invalidated. This can cause problems when the state cache is being
shared. The recommendation in this case depends on the use case. Developers
working on Yocto metadata should keep the shared state cache as default,
separated per project. However, validation and testing engineers, kernel
and bootloader developers, and application developers would probably
benefit from a well-maintained shared state cache."


After reading that I'm not sure to use it because I don't understand what
kind of "problems" can be found, and if they can be easily detected or not.


Does some of you have any experience using a shared sstate cache?





2018-04-23 17:10 GMT+02:00 Burton, Ross :

> On 20 April 2018 at 11:47, Uwe Geuder  wrote:
> > But can you share state between distros? Isn't the purpose of distros to
> > use different options (variable settings) so the state would always be
> > different?
>
> If the input to the recipe is different then the hashes would be
> different so the content won't conflict.  You can definitely share
> sstate between DISTROs.
>
> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: i...@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of Personal Data, the NAYAR SYSTEMS SL guarantees that it
has adopted the necessary measures to ensure the confidential treatment of
personal information. We also inform you that you can exercise your access,
rectification, cancellation and opposition rights by send us a mail to:
i...@nayarsystems.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Usage of yocto on different (production vs debug) scenarios

[Burton, Ross]

On 20 April 2018 at 11:47, Uwe Geuder  wrote:
> But can you share state between distros? Isn't the purpose of distros to
> use different options (variable settings) so the state would always be
> different?

If the input to the recipe is different then the hashes would be
different so the content won't conflict.  You can definitely share
sstate between DISTROs.

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

[yocto] Starting Hardware

[Alejandro Ariel Fachini]

Hello:
I'm an electronic engineer from argentina and I started to work for a
company which is starting with embedded software. I also want to work for
my self with this technology. I am about certificate android programing in
google and want to start with android things and also embedded linux.
For these reasons i want to purchase hardware that allows me to test both
environments or at least proper hardware for both Android things and Linux.

So If i purchase Raspberry Pi 3 B+, will i be able to work with Yocto? OR
do you recommend another more supported and "fiendly" Hardware for starting
with yocto? I understand that yocto is for A TON of different hardwares,
but im looking for very active and supported hardware with yocto.

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

[yocto] [meta-gplv2][sumo][rocko][pyro][PATCH 2/4] dosfstools: Update a patch to avoid fuzz

[Peter Kjellerstedt]

Signed-off-by: Peter Kjellerstedt 
---
 .../dosfstools/dosfstools/dosfstools-msdos_fs-types.patch   | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch 
b/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch
index 35abd1a..c04280e 100644
--- a/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch
+++ b/recipes-devtools/dosfstools/dosfstools/dosfstools-msdos_fs-types.patch
@@ -8,7 +8,7 @@ Signed-off-by: Scott Garman 
 --- dosfstools-2.10/dosfsck/dosfsck.h.org  2006-02-21 08:36:14.0 
-0700
 +++ dosfstools-2.10/dosfsck/dosfsck.h  2006-02-21 08:40:12.0 -0700
 @@ -22,6 +22,14 @@
-#undef __KERNEL__
+ # undef __KERNEL__
  #endif
  
 +#ifndef __s8
@@ -21,11 +21,11 @@ Signed-off-by: Scott Garman 
 +
  #include 
  
- /* 2.1 kernels use le16_to_cpu() type functions for CF_LE_W & Co., but don't
+ #undef CF_LE_W
 --- dosfstools-2.10/dosfsck/file.c.org 2006-02-21 08:37:36.0 -0700
 +++ dosfstools-2.10/dosfsck/file.c 2006-02-21 08:37:47.0 -0700
 @@ -23,6 +23,10 @@
-#undef __KERNEL__
+ # undef __KERNEL__
  #endif
  
 +#ifndef __s8
-- 
2.12.0

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

[yocto] [meta-gplv2][sumo][rocko][pyro][PATCH 1/4] sed: Update a patch to avoid fuzz

[Peter Kjellerstedt]

Signed-off-by: Peter Kjellerstedt 
---
 .../sed/sed-4.1.2/sed-4.1.2_fix_for_automake-1.12.patch   | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/recipes-extended/sed/sed-4.1.2/sed-4.1.2_fix_for_automake-1.12.patch 
b/recipes-extended/sed/sed-4.1.2/sed-4.1.2_fix_for_automake-1.12.patch
index c7c0aa0..86b64a1 100644
--- a/recipes-extended/sed/sed-4.1.2/sed-4.1.2_fix_for_automake-1.12.patch
+++ b/recipes-extended/sed/sed-4.1.2/sed-4.1.2_fix_for_automake-1.12.patch
@@ -27,11 +27,11 @@ Index: sed-4.1.2/po/Makefile.in.in
 --- sed-4.1.2.orig/po/Makefile.in.in
 +++ sed-4.1.2/po/Makefile.in.in
 @@ -29,7 +29,7 @@ gettextsrcdir = $(datadir)/gettext/po
- INSTALL = 
/srv/home/nitin/builds2/build0/tmp/sysroots/x86_64-linux/usr/bin/install -c
- INSTALL_DATA = ${INSTALL} -m 644
+ INSTALL = @INSTALL@
+ INSTALL_DATA = @INSTALL_DATA@
  mkinstalldirs = $(mkdir_p)
 -mkdir_p = @mkdir_p@
 +mkdir_p = @MKDIR_P@
  
- CC = i586-poky-linux-gcc  -m32   -march=i586 
--sysroot=/srv/home/nitin/builds2/build0/tmp/sysroots/qemux86
- GMSGFMT = 
/srv/home/nitin/builds2/build0/tmp/sysroots/x86_64-linux/usr/bin/msgfmt
+ CC = @CC@
+ GMSGFMT = @GMSGFMT@
-- 
2.12.0

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

[yocto] [meta-gplv2][sumo][rocko][pyro][PATCH 4/4] texinfo: Update a patch to avoid fuzz

[Peter Kjellerstedt]

Signed-off-by: Peter Kjellerstedt 
---
 recipes-extended/texinfo/texinfo-4.8/use_host_makedoc.patch | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-extended/texinfo/texinfo-4.8/use_host_makedoc.patch 
b/recipes-extended/texinfo/texinfo-4.8/use_host_makedoc.patch
index 5b7f32d..11e21aa 100644
--- a/recipes-extended/texinfo/texinfo-4.8/use_host_makedoc.patch
+++ b/recipes-extended/texinfo/texinfo-4.8/use_host_makedoc.patch
@@ -6,9 +6,9 @@ Index: texinfo-5.1/info/Makefile.am
 ===
 --- texinfo-5.1.orig/info/Makefile.am
 +++ texinfo-5.1/info/Makefile.am
-@@ -76,7 +76,7 @@ cmd_sources = $(srcdir)/session.c $(srcd
- # more than once.
- funs.h: makedoc$(EXEEXT) $(cmd_sources)
+@@ -67,7 +67,7 @@ cmd_sources = $(srcdir)/session.c $(srcdir)/echo-area.c 
$(srcdir)/infodoc.c \
+ # The $(EXEEXT) should be added by Automake, but isn't. Fine.
+ $(generated_sources): makedoc$(EXEEXT) $(cmd_sources)
rm -f $(generated_sources)
 -  $(top_builddir)/$(native_tools)/info/makedoc $(cmd_sources)
 +  makedoc $(cmd_sources)
-- 
2.12.0

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

[yocto] [meta-gplv2][sumo][rocko][pyro][PATCH 3/4] gnupg: Update a patch to avoid fuzz

[Peter Kjellerstedt]

Signed-off-by: Peter Kjellerstedt 
---
 recipes-support/gnupg/gnupg-1.4.7/long-long-thumb.patch | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-support/gnupg/gnupg-1.4.7/long-long-thumb.patch 
b/recipes-support/gnupg/gnupg-1.4.7/long-long-thumb.patch
index 2855cab..c3c361d 100644
--- a/recipes-support/gnupg/gnupg-1.4.7/long-long-thumb.patch
+++ b/recipes-support/gnupg/gnupg-1.4.7/long-long-thumb.patch
@@ -15,5 +15,4 @@ Upstream-Status: Inappropriate [configuration]
 +#if defined (__arm__) && W_TYPE_SIZE == 32 && !defined(__thumb__)
  #define add_ss(sh, sl, ah, al, bh, bl) \
__asm__ ("adds %1, %4, %5\n"  \
-  "adc  %0, %2, %3"\
-
+  "adc  %0, %2, %3"\
-- 
2.12.0

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

Re: [yocto] [meta-gplv2][sumo][rocko][pyro][PATCH] coreutils: Update a patch to avoid fuzz

[Burton, Ross]

Merged, thanks.

Ross

On 23 April 2018 at 11:56, Peter Kjellerstedt
 wrote:
> Change-Id: I86ca76ca762da515fb6dfc95e2afd14cfe802fff
> Signed-off-by: Peter Kjellerstedt 
> ---
>  recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch 
> b/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch
> index 58074c0..b9cd52e 100644
> --- a/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch
> +++ b/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch
> @@ -8,8 +8,8 @@ Signed-off-by: Mark Hatle 
>
>  --- coreutils-5.2.1/src/who.c.overflow 2005-05-25 09:59:06.0 +0100
>  +++ coreutils-5.2.1/src/who.c  2005-05-25 10:00:31.0 +0100
> -@@ -75,7 +75,7 @@
> - # define NEW_TIME 0
> +@@ -78,7 +78,7 @@
> + # define UT_TYPE_NEW_TIME(U) false
>   #endif
>
>  -#define IDLESTR_LEN 6
> --
> 2.12.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Linux Files needed for PXE network boot

[Raymond Yeung]

Thanks for all who extended helping hands.  I finally resolved my issues, and 
the target PXE-boot'ed up.  I'd like to provide some updates, for reference to 
someone that may run into this in the future.


I'm able to use legacy mode (in BIOS) instead of UEFI mode.  While I haven't 
worked out the canonical form, it seems two things are important on BIOS side - 
there are a number of options that have UEFI vs. legacy choices.  Select 
"legacy" mode for all of them.  This is in the "CSM & Option ROM" Advanced 
setting.  Some of the logging options under "Event Logs" tab might have helped 
turned on more diagnostic messages.


After the above adjustment, the error messages on the BIOS console guided me to 
pick up missing files, including ldlinux.c32, libutil.c32, lib com.c32 that are 
not mentioned anywhere that I looked so far.


Now, I'm onto investigating how I could (re)create partitions on SSD, load the 
kernel there, and boot from that.


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

[yocto] [meta-gplv2][sumo][rocko][pyro][PATCH] coreutils: Update a patch to avoid fuzz

[Peter Kjellerstedt]

Change-Id: I86ca76ca762da515fb6dfc95e2afd14cfe802fff
Signed-off-by: Peter Kjellerstedt 
---
 recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch 
b/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch
index 58074c0..b9cd52e 100644
--- a/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch
+++ b/recipes-core/coreutils/coreutils-6.9/coreutils-overflow.patch
@@ -8,8 +8,8 @@ Signed-off-by: Mark Hatle 
 
 --- coreutils-5.2.1/src/who.c.overflow 2005-05-25 09:59:06.0 +0100
 +++ coreutils-5.2.1/src/who.c  2005-05-25 10:00:31.0 +0100
-@@ -75,7 +75,7 @@
- # define NEW_TIME 0
+@@ -78,7 +78,7 @@
+ # define UT_TYPE_NEW_TIME(U) false
  #endif
  
 -#define IDLESTR_LEN 6
-- 
2.12.0

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

Re: [yocto] [meta-gplv2][sumo][rocko][pyro][PATCH] coreutils: Avoid warnings due to update-alternatives for man pages

[Burton, Ross]

Pushed, thanks.

On 23 April 2018 at 11:23, Peter Kjellerstedt
 wrote:
> The man pages for this package was disabled in 46349e1a with the result
> that the following warnings appeared:
>
>   WARNING: coreutils-6.9-r0 do_package: coreutils: alternative target
>   (/usr/share/man/man1/su.1 or /usr/share/man/man1/su.1.coreutils) does
>   not exist, skipping...
>   WARNING: coreutils-6.9-r0 do_package: coreutils: alternative target
>   (/usr/share/man/man1/hostname.1 or
>   /usr/share/man/man1/hostname.1.coreutils) does not exist, skipping...
>   WARNING: coreutils-6.9-r0 do_package: coreutils: NOT adding
>   alternative provide /usr/share/man/man1/su.1:
>   /usr/share/man/man1/su.1.coreutils does not exist
>   WARNING: coreutils-6.9-r0 do_package: coreutils: NOT adding
>   alternative provide /usr/share/man/man1/hostname.1:
>   /usr/share/man/man1/hostname.1.coreutils does not exist
>   WARNING: coreutils-6.9-r0 do_package: coreutils: alt_link ==
>   alt_target: /usr/share/man/man1/su.1 == /usr/share/man/man1/su.1
>   WARNING: coreutils-6.9-r0 do_package: coreutils: alt_link ==
>   alt_target: /usr/share/man/man1/hostname.1 ==
>   /usr/share/man/man1/hostname.1
>
> This change removes the update-alternatives for the man pages that no
> longer exists.
>
> Change-Id: If79bb634e05db48462265c6e65291db27169fa51
> Signed-off-by: Peter Kjellerstedt 
> ---
>  recipes-core/coreutils/coreutils_6.9.bb | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/recipes-core/coreutils/coreutils_6.9.bb 
> b/recipes-core/coreutils/coreutils_6.9.bb
> index 31e5c7e..0d236b2 100644
> --- a/recipes-core/coreutils/coreutils_6.9.bb
> +++ b/recipes-core/coreutils/coreutils_6.9.bb
> @@ -90,10 +90,6 @@ ALTERNATIVE_PRIORITY = "100"
>
>  ALTERNATIVE_${PN} = "lbracket ${bindir_progs} ${base_bindir_progs} 
> ${sbindir_progs}"
>
> -ALTERNATIVE_${PN}-doc = "su.1 hostname.1"
> -ALTERNATIVE_LINK_NAME[su.1] = "${mandir}/man1/su.1"
> -ALTERNATIVE_LINK_NAME[hostname.1] = "${mandir}/man1/hostname.1"
> -
>  ALTERNATIVE_PRIORITY[uptime] = "10"
>  ALTERNATIVE_PRIORITY[hostname] = "10"
>
> --
> 2.12.0
>
> --
> ___
> 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] [meta-gplv2][sumo][rocko][pyro][PATCH] coreutils: Avoid warnings due to update-alternatives for man pages

[Peter Kjellerstedt]

The man pages for this package was disabled in 46349e1a with the result
that the following warnings appeared:

  WARNING: coreutils-6.9-r0 do_package: coreutils: alternative target
  (/usr/share/man/man1/su.1 or /usr/share/man/man1/su.1.coreutils) does
  not exist, skipping...
  WARNING: coreutils-6.9-r0 do_package: coreutils: alternative target
  (/usr/share/man/man1/hostname.1 or
  /usr/share/man/man1/hostname.1.coreutils) does not exist, skipping...
  WARNING: coreutils-6.9-r0 do_package: coreutils: NOT adding
  alternative provide /usr/share/man/man1/su.1:
  /usr/share/man/man1/su.1.coreutils does not exist
  WARNING: coreutils-6.9-r0 do_package: coreutils: NOT adding
  alternative provide /usr/share/man/man1/hostname.1:
  /usr/share/man/man1/hostname.1.coreutils does not exist
  WARNING: coreutils-6.9-r0 do_package: coreutils: alt_link ==
  alt_target: /usr/share/man/man1/su.1 == /usr/share/man/man1/su.1
  WARNING: coreutils-6.9-r0 do_package: coreutils: alt_link ==
  alt_target: /usr/share/man/man1/hostname.1 ==
  /usr/share/man/man1/hostname.1

This change removes the update-alternatives for the man pages that no
longer exists.

Change-Id: If79bb634e05db48462265c6e65291db27169fa51
Signed-off-by: Peter Kjellerstedt 
---
 recipes-core/coreutils/coreutils_6.9.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/recipes-core/coreutils/coreutils_6.9.bb 
b/recipes-core/coreutils/coreutils_6.9.bb
index 31e5c7e..0d236b2 100644
--- a/recipes-core/coreutils/coreutils_6.9.bb
+++ b/recipes-core/coreutils/coreutils_6.9.bb
@@ -90,10 +90,6 @@ ALTERNATIVE_PRIORITY = "100"
 
 ALTERNATIVE_${PN} = "lbracket ${bindir_progs} ${base_bindir_progs} 
${sbindir_progs}"
 
-ALTERNATIVE_${PN}-doc = "su.1 hostname.1"
-ALTERNATIVE_LINK_NAME[su.1] = "${mandir}/man1/su.1"
-ALTERNATIVE_LINK_NAME[hostname.1] = "${mandir}/man1/hostname.1"
-
 ALTERNATIVE_PRIORITY[uptime] = "10"
 ALTERNATIVE_PRIORITY[hostname] = "10"
 
-- 
2.12.0

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

Re: [yocto] [meta-gplv2][sumo][rocko][PATCH] bash: Provide /bin/{sh, bash} when usrmerge is used

[Burton, Ross]

Pushed, thanks.

Ross

On 21 April 2018 at 02:30, Peter Kjellerstedt
 wrote:
> Most shell scripts have '#!/bin/{sh,bash}' on the first line of the
> script, which triggers RPM to automatically add a runtime dependency
> on that path for any package that contains shell scripts.  However,
> when the usrmerge feature is enabled, the path will actually be
> /usr/bin/{sh,bash}.
>
> So, to satisfy the runtime dependencies, add '/bin/{sh,bash}' to what
> the bash package provides.
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  recipes-extended/bash/bash.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/recipes-extended/bash/bash.inc b/recipes-extended/bash/bash.inc
> index a05b987..0f0d679 100644
> --- a/recipes-extended/bash/bash.inc
> +++ b/recipes-extended/bash/bash.inc
> @@ -65,3 +65,5 @@ pkg_postinst_${PN} () {
>  pkg_postrm_${PN} () {
> printf "$(grep -v "^${base_bindir}/bash$" $D${sysconfdir}/shells)\n" 
> > $D${sysconfdir}/shells
>  }
> +
> +RPROVIDES_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'usrmerge', 
> '/bin/sh /bin/bash', '', d)}"
> --
> 2.12.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-selinux][PATCH] policycoreutils: remove oe_filter_out

[wenzong fan]

Jackie has sent a patch on 02/07/2018 for this:

[yocto] [meta-selinux][PATCH] policycoreutils.inc: use 
oe.utils.str_filter_out


It's still not merged yet.

Thanks
Wenzong

On 04/15/2018 06:33 AM, Armin Kuster wrote:

bb.data_smart.ExpansionError: Failure expanding variable WARN_QA[:=], 
expression was ${@oe_filter_out('unsafe-references-in-scripts', 'ldflags 
useless-rpaths rpaths staticdev libdir xorg-driver-abi textrel 
already-stripped incompatible-license files-invalid 
installed-vs-shipped compile-host-path install-host-path 
pn-overrides infodir build-deps unknown-configure-option 
symlink-to-sysroot multilib invalid-packageconfig 
host-user-contaminated uppercase-pn ', d)} which triggered 
exception NameError: name 'oe_filter_out' is not defined

Signed-off-by: Armin Kuster 
---
  recipes-security/selinux/policycoreutils.inc | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-security/selinux/policycoreutils.inc 
b/recipes-security/selinux/policycoreutils.inc
index 442b086..1842fd8 100644
--- a/recipes-security/selinux/policycoreutils.inc
+++ b/recipes-security/selinux/policycoreutils.inc
@@ -64,8 +64,8 @@ RDEPENDS_${BPN}-setsebool += "\
  "
  RDEPENDS_${BPN} += "selinux-python"
  
-WARN_QA := "${@oe_filter_out('unsafe-references-in-scripts', '${WARN_QA}', d)}"

-ERROR_QA := "${@oe_filter_out('unsafe-references-in-scripts', '${ERROR_QA}', 
d)}"
+WARN_QA_remove = " unsafe-references-in-scripts"
+ERROR_QA_remove = " unsafe-references-in-scripts"
  
  
  PACKAGES =+ "\



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