From jupiter.hce at gmail.com  Sat Jun  1 03:39:24 2019
From: jupiter.hce at gmail.com (JH)
Date: Sat, 1 Jun 2019 20:39:24 +1000
Subject: [yocto] How to extract files from wic.gz image?
In-Reply-To: <20190531132253.GC20781@bill-the-cat>
References: <CAA=hcWTwG4oo=qJvbrx04zaTXRy8u1H6HLEGV_J7r25jpzSVOA@mail.gmail.com>
	<20190531132253.GC20781@bill-the-cat>
Message-ID: <CAA=hcWQwSD4MLVJLbNz2nzv0SQAgMdkcnRPFfPCQN5NW+7XYhw@mail.gmail.com>

Thanks Zoran and Tom, I can use dd to install the image to SD card on
IMX EVK, now I need to install the image to NAND flash of a customized
IMX device via USB HID, it cannot use the dd, IMX provided UUU utility
which I am new to it and I have to decompose the image to
zImage-initramfs and  losetup -P does work, dd does not work either.

$ losetup -P dev-image-20190528085324.rootfs.wic
losetup: solar-dev-image-solarevk-20190518084330.rootfs.wic: failed to
use device: No such device

Thanks for your helps anyway.

Kind regards,

- jupiter

On 5/31/19, Tom Rini <trini at konsulko.com> wrote:
> On Fri, May 31, 2019 at 10:21:40PM +1000, JH wrote:
>> Hi,
>>
>> What command and tools to extract files from Yocto / bitbake image
>> such as dev-image-20190528085324.rootfs.wic.gz?
>>
>> I am using IMX UUU to install dev-image-20190528085324.rootfs.wic.gz
>> to IMX, I was advised to extract the archive and use "uuu <script
>> name>" or "uuu u-boot-dtb.imx" to get bootloader work first.
>
> A wic image is just another way of saying it's a raw disk image.
> Decompress it, losetup -P (generally useful, but not needed this time)
> and dd out the contents you want.
>
> --
> Tom
>

From morne at linux.com  Sat Jun  1 07:40:16 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Sat, 1 Jun 2019 16:40:16 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd package
Message-ID: <20190601144016.GA19383@archworkstation>

Hi

I created a new custom distribution and 
everything seems to work fine until the do_rootfs 
task is executed. It fails specifically when 
trying to install the hostapd package, with the 
error below (snippet from log.do_rootfs):

> Running scriptlet: hostapd-2.6-r0.aarch64
>
> usage: update-rc.d [-n] [-f] [-r <root>] <basename> remove update-rc.d
> [-n] [-r <root>] [-s] <basename> defaults [NN | sNN kNN]
> update-rc.d [-n] [-r <root>] [-s] <basename> start|stop NN runlvl [runlvl]
>
> error: %prein(hostapd-2.6-r0.aarch64) scriptlet failed, exit status 1

> error: hostapd-2.6-r0.aarch64: install failed

The hostapd package itself builds fine, it is 
just the installation to the rootfs that fails.

The hostapd package is specified in 
MACHINE_EXTRA_DEPENDS, if I remove it, then the 
build succeeds without any issues.

If I interpret the error correctly, it is the 
preinstall scriptlet that fails...but I am not 
sure where to start debugging this.

Any suggestions ?

		- Morn?

From marek.belisko at gmail.com  Sat Jun  1 08:43:25 2019
From: marek.belisko at gmail.com (Belisko Marek)
Date: Sat, 1 Jun 2019 17:43:25 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd
	package
In-Reply-To: <20190601144016.GA19383@archworkstation>
References: <20190601144016.GA19383@archworkstation>
Message-ID: <CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>

Hi,

On Sat, Jun 1, 2019 at 4:41 PM Morn? Lamprecht <morne at linux.com> wrote:
>
> Hi
>
> I created a new custom distribution and
> everything seems to work fine until the do_rootfs
> task is executed. It fails specifically when
> trying to install the hostapd package, with the
> error below (snippet from log.do_rootfs):
I would check run.do_rootfs and check it maybe there will be some more info.
Do you have some custom extension for hostapd? Thanks.
>
> > Running scriptlet: hostapd-2.6-r0.aarch64
> >
> > usage: update-rc.d [-n] [-f] [-r <root>] <basename> remove update-rc.d
> > [-n] [-r <root>] [-s] <basename> defaults [NN | sNN kNN]
> > update-rc.d [-n] [-r <root>] [-s] <basename> start|stop NN runlvl [runlvl]
> >
> > error: %prein(hostapd-2.6-r0.aarch64) scriptlet failed, exit status 1
>
> > error: hostapd-2.6-r0.aarch64: install failed
>
> The hostapd package itself builds fine, it is
> just the installation to the rootfs that fails.
>
> The hostapd package is specified in
> MACHINE_EXTRA_DEPENDS, if I remove it, then the
> build succeeds without any issues.
>
> If I interpret the error correctly, it is the
> preinstall scriptlet that fails...but I am not
> sure where to start debugging this.
>
> Any suggestions ?
>
>                 - Morn?
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

marek

From morne at linux.com  Sat Jun  1 11:25:56 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Sat, 1 Jun 2019 20:25:56 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd
 package
In-Reply-To: <CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
References: <20190601144016.GA19383@archworkstation>
	<CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
Message-ID: <20190601182556.GB19383@archworkstation>

>I would check run.do_rootfs and check it maybe 
>there will be some more info.

I checked it based on your suggestion, 
unfortunately found no relevant info.

>Do you have some custom extension for hostapd?

No, just the standard package.

		- Morn?

From mark.hatle at windriver.com  Sat Jun  1 15:50:10 2019
From: mark.hatle at windriver.com (Mark Hatle)
Date: Sat, 1 Jun 2019 17:50:10 -0500
Subject: [yocto] prelink-cross with -fno-plt
In-Reply-To: <CAEseUXm_CsT=3u6ro8+8WMh9TAzSVwVyj7ahgYhvdjeJNA25=A@mail.gmail.com>
References: <CAEseUX=OG1gVjXzBNAj=DiOMJ9eA9x58-ng7xDro0_arS1nXSw@mail.gmail.com>
	<50b3ec46-1c13-f0cb-64eb-bde7809db99d@gmail.com>
	<CAEseUXkdwLzK-r92SUMXVoMWFpVNVRNzVpjQGMzNLOJvx=jcbg@mail.gmail.com>
	<bb585fca-cdc0-1c2a-47db-cf854b23d850@gmail.com>
	<CAEseUX=g+C=15OVzc4G_1zWLwCsi+XzZR4p9jF5=b7ZYFANgow@mail.gmail.com>
	<74876fa3-2e5f-60a6-f5e7-2a4a6242bac1@gmail.com>
	<CAEseUX=BXTxMkvp_QpkWgoSvx9LMPj+mJ_dNc9Oj8uNDMfctTQ@mail.gmail.com>
	<CAMKF1sp0f2=f-kxi01dpRjnc3HQUXv3zi1B4tPwDNuL7+poUtw@mail.gmail.com>
	<CAEseUXmBKWFP_E84RfHnPJsAcROrVvgSqdyKu_YakY5FLOKYfg@mail.gmail.com>
	<1f06f439-6ce2-63b9-45e4-be211f6925c9@windriver.com>
	<CAEseUXm_CsT=3u6ro8+8WMh9TAzSVwVyj7ahgYhvdjeJNA25=A@mail.gmail.com>
Message-ID: <69690341-4b69-eeea-d003-75fd38ccc2f9@windriver.com>

Thanks, this shows that the prelinking is still working in this case.  I'll get
you patch queued up.  If you don't see any progress on it this coming week,
please feel free to remind me.

--Mark

On 5/29/19 1:42 PM, Shane Peelar wrote:
> Hi Mark,
> 
> Thank you for your reply and no problem -- I chose to benchmark ssh-add with
> it.? It contains no `.plt`.
> 
> The results are as follows:
> 
> Without prelink (ran prelink -auv):
> 
> ? ?? 26019:
> ? ? ?26019: ? ? runtime linker statistics:
> ? ? ?26019: ? ? ? total startup time in dynamic loader: 1321674 cycles
> ? ? ?26019: ? ? ? ? ? ? ? ? time needed for relocation: 797948 cycles (60.3%)
> ? ? ?26019: ? ? ? ? ? ? ? ? ? ? ?number of relocations: 624
> ? ? ?26019: ? ? ? ? ? number of relocations from cache: 3
> ? ? ?26019: ? ? ? ? ? ? number of relative relocations: 9691
> ? ? ?26019: ? ? ? ? ? ? ? ?time needed to load objects: 389972 cycles (29.5%)
> Could not open a connection to your authentication agent.
> ? ? ?26019:
> ? ? ?26019: ? ? runtime linker statistics:
> ? ? ?26019: ? ? ? ? ? ? ? ?final number of relocations: 630
> ? ? ?26019: ? ? final number of relocations from cache: 3
> 
> With prelink (ran prelink -av):
> 
> ? ? ? 1930:
> ? ? ? 1930: ? ? runtime linker statistics:
> ? ? ? 1930: ? ? ? total startup time in dynamic loader: 462288 cycles
> ? ? ? 1930: ? ? ? ? ? ? ? ? time needed for relocation: 48730 cycles (10.5%)
> ? ? ? 1930: ? ? ? ? ? ? ? ? ? ? ?number of relocations: 7
> ? ? ? 1930: ? ? ? ? ? number of relocations from cache: 134
> ? ? ? 1930: ? ? ? ? ? ? number of relative relocations: 0
> ? ? ? 1930: ? ? ? ? ? ? ? ?time needed to load objects: 286076 cycles (61.8%)
> Could not open a connection to your authentication agent.
> ? ? ? 1930:
> ? ? ? 1930: ? ? runtime linker statistics:
> ? ? ? 1930: ? ? ? ? ? ? ? ?final number of relocations: 9
> ? ? ? 1930: ? ? final number of relocations from cache: 134
> 
> I also tested against execstack, which for sure had the assertion fire on.
> Without prelink:
> 
> ? ?? 27736:
> ? ? ?27736: ? ? runtime linker statistics:
> ? ? ?27736: ? ? ? total startup time in dynamic loader: 1955954 cycles
> ? ? ?27736: ? ? ? ? ? ? ? ? time needed for relocation: 755440 cycles (38.6%)
> ? ? ?27736: ? ? ? ? ? ? ? ? ? ? ?number of relocations: 247
> ? ? ?27736: ? ? ? ? ? number of relocations from cache: 3
> ? ? ?27736: ? ? ? ? ? ? number of relative relocations: 1353
> ? ? ?27736: ? ? ? ? ? ? ? ?time needed to load objects: 710384 cycles (36.3%)
> /usr/bin/execstack: no files given
> ? ? ?27736:
> ? ? ?27736: ? ? runtime linker statistics:
> ? ? ?27736: ? ? ? ? ? ? ? ?final number of relocations: 251
> ? ? ?27736: ? ? final number of relocations from cache: 3
> 
> With prelink:
> 
> ? ? ? 3268:
> ? ? ? 3268: ? ? runtime linker statistics:
> ? ? ? 3268: ? ? ? total startup time in dynamic loader: 1421206 cycles
> ? ? ? 3268: ? ? ? ? ? ? ? ? time needed for relocation: 199396 cycles (14.0%)
> ? ? ? 3268: ? ? ? ? ? ? ? ? ? ? ?number of relocations: 3
> ? ? ? 3268: ? ? ? ? ? number of relocations from cache: 88
> ? ? ? 3268: ? ? ? ? ? ? number of relative relocations: 0
> ? ? ? 3268: ? ? ? ? ? ? ? ?time needed to load objects: 696886 cycles (49.0%)
> /usr/bin/execstack: no files given
> ? ? ? 3268:
> ? ? ? 3268: ? ? runtime linker statistics:
> ? ? ? 3268: ? ? ? ? ? ? ? ?final number of relocations: 5
> ? ? ? 3268: ? ? final number of relocations from cache: 88
> 
> So, it looks like prelink is working on these :)
> 
> On Tue, May 28, 2019 at 2:57 PM Mark Hatle <mark.hatle at windriver.com
> <mailto:mark.hatle at windriver.com>> wrote:
> 
>     Sorry for my delayed reply.? I was out on a business trip.
> 
>     Did you try this with the ld.so statistics to see if the relocations were indeed
>     reduced at runtime?
> 
>     One of my worries with these changes (since I am not an ELF expert either) is
>     that we make a change that doesn't actually do anything -- but people expect
>     it to.
> 
>     $ LD_DEBUG=help /lib/ld-linux.so.2
>     Valid options for the LD_DEBUG environment variable are:
> 
>     ? libs? ? ? ? display library search paths
>     ? reloc? ? ? ?display relocation processing
>     ? files? ? ? ?display progress for input file
>     ? symbols? ? ?display symbol table processing
>     ? bindings? ? display information about symbol binding
>     ? versions? ? display version dependencies
>     ? scopes? ? ? display scope information
>     ? all? ? ? ? ?all previous options combined
>     ? statistics? display relocation statistics
>     ? unused? ? ? determined unused DSOs
>     ? help? ? ? ? display this help message and exit
> 
>     To direct the debugging output into a file instead of standard output
>     a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
> 
>     I believe that it's the 'statistics' option.
> 
>     LD_DEBUG=statistics <executable that's been prelinked>
> 
>     Should result in something like:
> 
>     ? ? 128820:? ? ?runtime linker statistics:
>     ? ? 128820:? ? ? ?total startup time in dynamic loader: 1974661 cycles
>     ? ? 128820:? ? ? ? ? ? ? ? ?time needed for relocation: 354639 cycles (17.9%)
>     ? ? 128820:? ? ? ? ? ? ? ? ? ? ? number of relocations: 90
>     ? ? 128820:? ? ? ? ? ?number of relocations from cache: 3
>     ? ? 128820:? ? ? ? ? ? ?number of relative relocations: 1201
>     ? ? 128820:? ? ? ? ? ? ? ? time needed to load objects: 1303654 cycles (66.0%)
>     ? ? 128820:
>     ? ? 128820:? ? ?runtime linker statistics:
>     ? ? 128820:? ? ? ? ? ? ? ? final number of relocations: 94
>     ? ? 128820:? ? ?final number of relocations from cache: 3
> 
>     If prelink is working, the number of relocations (relative or otherwise) will be
>     significantly reduced from the original non-relocated version.
> 
>     If you can run this test, it would give me the assurance that the patch is safe,
>     and I'll get it incorporated into the prelink-cross sources.
> 
>     --Mark
> 
>     On 5/25/19 2:53 PM, Shane Peelar wrote:
>     > Patch is attached.? Thank you!
>     >
>     > On Sat, May 25, 2019 at 2:30 AM Khem Raj <raj.khem at gmail.com
>     <mailto:raj.khem at gmail.com>
>     > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>> wrote:
>     >
>     >? ? ?On Fri, May 24, 2019 at 6:58 PM Shane Peelar
>     <lookatyouhacker at gmail.com <mailto:lookatyouhacker at gmail.com>
>     >? ? ?<mailto:lookatyouhacker at gmail.com <mailto:lookatyouhacker at gmail.com>>>
>     wrote:
>     >? ? ?>
>     >? ? ?> Great!? Would you be willing to accept a patch that makes arch-x86_64.c
>     >? ? ?handle that condition like the other arches?
>     >? ? ?>
>     >
>     >? ? ?yes certainly.
>     >
>     >? ? ?> -Shane
>     >? ? ?>
>     >? ? ?> On Fri, May 24, 2019 at 12:27 PM Khem Raj <raj.khem at gmail.com
>     <mailto:raj.khem at gmail.com>
>     >? ? ?<mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>> wrote:
>     >? ? ?>>
>     >? ? ?>>
>     >? ? ?>>
>     >? ? ?>> On 5/24/19 8:10 AM, Shane Peelar wrote:
>     >? ? ?>> > I did some reading into the sources in other architectures.? The
>     closest
>     >? ? ?>> > match, arch_i386.c, makes the write conditional as you say.
>     >? ? ?>> > So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c,
>     >? ? ?>> > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||||||
>     >? ? ?>> > ||||||
>     >? ? ?>> > ||||||
>     >? ? ?>> > Notably, |||||||arch-cris.c||||||| has the same assert as
>     >? ? ?>> > |||||||arch-x86_64.c||||||| instead of the conditional.
>     >? ? ?>> >
>     >? ? ?>> > The code roughly looks like follows:||||||||||||||
>     >? ? ?>> > ||||||||||||||
>     >? ? ?>> > |||||||
>     >? ? ?>> > |||||||
>     >? ? ?>> > 1. Check for dso->info[DT_PLTGOT].? If it does not exist, return 0
>     >? ? ?>> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
>     >? ? ?>> > 3. Look for the section named ".plt" in the ELF.
>     >? ? ?>> > 4. If the section cannot be found, return 0
>     >? ? ?>> > 5. Otherwise, write the address of .plt + constant (dependent on
>     arch)
>     >? ? ?>> > to got[1]||||||||||||||
>     >? ? ?>> > ||||||||||||||
>     >? ? ?>> > |||||||
>     >? ? ?>> > |||||||
>     >? ? ?>> > In |||||||arch-x86_64.c and arch-cris.c|||||||, step (4) above is an
>     >? ? ?>> > assert:|||||||
>     >? ? ?>> >
>     >? ? ?>> > |||||||1. Check for dso->info[DT_PLTGOT].? If it does not exist,
>     return 0
>     >? ? ?>> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if error
>     >? ? ?>> > 3. Look for the section named ".plt" in the ELF.
>     >? ? ?>> > 4. Assert that the section was found
>     >? ? ?>> > 5. Write the address of .plt + constant (dependent on arch) to got[1]
>     >? ? ?>> >
>     >? ? ?>> > I tested out making the assert conditional and nothing seemed to
>     break
>     >? ? ?>> > at least.
>     >? ? ?>> > |||||||
>     >? ? ?>> > |||||||
>     >? ? ?>>
>     >? ? ?>> It seems ok to me.
>     >? ? ?>>
>     >? ? ?>> >
>     >? ? ?>> > On Fri, May 24, 2019 at 12:08 AM Khem Raj <raj.khem at gmail.com
>     <mailto:raj.khem at gmail.com>
>     >? ? ?<mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
>     >? ? ?>> > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
>     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>> wrote:
>     >? ? ?>> >
>     >? ? ?>> >
>     >? ? ?>> >
>     >? ? ?>> >? ? ?On 5/23/19 7:53 PM, Shane Peelar wrote:
>     >? ? ?>> >? ? ? > Any of them on the system pretty much, and yes they are also
>     >? ? ?>> >? ? ?built with
>     >? ? ?>> >? ? ? > -fno-plt.
>     >? ? ?>> >
>     >? ? ?>> >? ? ?OK, I think its better to them conditionally check for .plt
>     section,
>     >? ? ?>> >? ? ?can you describe more of whats going on when sections are
>     checked.
>     >? ? ?>> >
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >? ? ? > On Thu, May 23, 2019 at 9:59 PM Khem Raj
>     <raj.khem at gmail.com <mailto:raj.khem at gmail.com>
>     >? ? ?<mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
>     >? ? ?>> >? ? ?<mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
>     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>
>     >? ? ?>> >? ? ? > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
>     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
>     >? ? ?<mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
>     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>>> wrote:
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >? ? ? >? ? ?On 5/23/19 8:05 AM, Shane Peelar wrote:
>     >? ? ?>> >? ? ? >? ? ? > Hi Everyone @ the Yocto project,
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > I'm Shane Peelar, a PhD Candidate at the University of
>     >? ? ?>> >? ? ?Windsor.
>     >? ? ?>> >? ? ? >? ? ? > I'm writing to you about prelink-cross, as part of the
>     >? ? ?>> >? ? ?Yocto project.
>     >? ? ?>> >? ? ? >? ? ? > Specifically, I'm looking at using it with executables
>     >? ? ?>> >? ? ?built using
>     >? ? ?>> >? ? ? >? ? ? > `-fno-plt` under GCC.
>     >? ? ?>> >? ? ? >? ? ? > I wasn't quite sure where to send this email to, so I
>     >? ? ?>> >? ? ?figured I'd
>     >? ? ?>> >? ? ? >? ? ?try
>     >? ? ?>> >? ? ? >? ? ? > here.? If there's a better place to send this,
>     please let
>     >? ? ?>> >? ? ?me know.
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > Right now, prelink-cross seems to fail an assertion in
>     >? ? ?>> >? ? ? >? ? ?arch-x86_64.c,
>     >? ? ?>> >? ? ? >? ? ? > line 421, when
>     >? ? ?>> >? ? ? >? ? ? > using it with an executable built with `-fno-plt`:
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > ...
>     >? ? ?>> >? ? ? >? ? ? > assert (i < dso->ehdr.e_shnum)
>     >? ? ?>> >? ? ? >? ? ? > ...
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > This snippet seems to be looking for the ".plt"
>     section and,
>     >? ? ?>> >? ? ? >? ? ?since it
>     >? ? ?>> >? ? ? >? ? ? > can't find it, the assertion fires.? This makes sense
>     >? ? ?>> >? ? ?because in
>     >? ? ?>> >? ? ? >? ? ? > `-fno-plt` executables, the `.plt` section is missing
>     >? ? ?>> >? ? ?entirely.
>     >? ? ?>> >? ? ? >? ? ? > I'm not an expert on ELF stuff, although I am learning
>     >? ? ?>> >? ? ?quickly.? It
>     >? ? ?>> >? ? ? >? ? ? > looks like
>     >? ? ?>> >? ? ? >? ? ? > this code wants to write into GOT[1] the address of
>     ".plt"
>     >? ? ?>> >? ? ?+ 0x16 --
>     >? ? ?>> >? ? ? >? ? ? > since ".plt" doesn't
>     >? ? ?>> >? ? ? >? ? ? > exist, does it make sense to just change this
>     assert to an if
>     >? ? ?>> >? ? ? >? ? ?statement
>     >? ? ?>> >? ? ? >? ? ? > like so:
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > ...
>     >? ? ?>> >? ? ? >? ? ? >? ? ? ? if (i < dso->ehdr.e_shnum)
>     >? ? ?>> >? ? ? >? ? ? >? ? ? ? { ... }
>     >? ? ?>> >? ? ? >? ? ? > ...
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > and skip over that part?? Or is this a real error
>     >? ? ?>> >? ? ?condition for
>     >? ? ?>> >? ? ? >? ? ? > prelink-cross and it really should not continue?? The
>     >? ? ?>> >? ? ?executable in
>     >? ? ?>> >? ? ? >? ? ? > question is also non-PIE, if that makes a difference.
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >? ? ? >? ? ?what shared libs is this linking to ? are they also
>     built with
>     >? ? ?>> >? ? ? >? ? ?-fno-plt ?
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >? ? ? >? ? ? > Thanks for your time,
>     >? ? ?>> >? ? ? >? ? ? > Shane
>     >? ? ?>> >? ? ? >? ? ? >
>     >? ? ?>> >? ? ? >
>     >? ? ?>> >
>     >
>     >
> 


From lookatyouhacker at gmail.com  Sun Jun  2 21:50:03 2019
From: lookatyouhacker at gmail.com (Shane Peelar)
Date: Sun, 2 Jun 2019 21:50:03 -0700
Subject: [yocto] prelink-cross with -fno-plt
In-Reply-To: <69690341-4b69-eeea-d003-75fd38ccc2f9@windriver.com>
References: <CAEseUX=OG1gVjXzBNAj=DiOMJ9eA9x58-ng7xDro0_arS1nXSw@mail.gmail.com>
	<50b3ec46-1c13-f0cb-64eb-bde7809db99d@gmail.com>
	<CAEseUXkdwLzK-r92SUMXVoMWFpVNVRNzVpjQGMzNLOJvx=jcbg@mail.gmail.com>
	<bb585fca-cdc0-1c2a-47db-cf854b23d850@gmail.com>
	<CAEseUX=g+C=15OVzc4G_1zWLwCsi+XzZR4p9jF5=b7ZYFANgow@mail.gmail.com>
	<74876fa3-2e5f-60a6-f5e7-2a4a6242bac1@gmail.com>
	<CAEseUX=BXTxMkvp_QpkWgoSvx9LMPj+mJ_dNc9Oj8uNDMfctTQ@mail.gmail.com>
	<CAMKF1sp0f2=f-kxi01dpRjnc3HQUXv3zi1B4tPwDNuL7+poUtw@mail.gmail.com>
	<CAEseUXmBKWFP_E84RfHnPJsAcROrVvgSqdyKu_YakY5FLOKYfg@mail.gmail.com>
	<1f06f439-6ce2-63b9-45e4-be211f6925c9@windriver.com>
	<CAEseUXm_CsT=3u6ro8+8WMh9TAzSVwVyj7ahgYhvdjeJNA25=A@mail.gmail.com>
	<69690341-4b69-eeea-d003-75fd38ccc2f9@windriver.com>
Message-ID: <CAEseUXkfLj1K6ix0qA4JSGX6ACevwYXODYqpqUzjxEsoM0wOBg@mail.gmail.com>

Will do, thanks!

On Sat, Jun 1, 2019, 3:50 PM Mark Hatle, <mark.hatle at windriver.com> wrote:

> Thanks, this shows that the prelinking is still working in this case.
> I'll get
> you patch queued up.  If you don't see any progress on it this coming week,
> please feel free to remind me.
>
> --Mark
>
> On 5/29/19 1:42 PM, Shane Peelar wrote:
> > Hi Mark,
> >
> > Thank you for your reply and no problem -- I chose to benchmark ssh-add
> with
> > it.  It contains no `.plt`.
> >
> > The results are as follows:
> >
> > Without prelink (ran prelink -auv):
> >
> >      26019:
> >      26019:     runtime linker statistics:
> >      26019:       total startup time in dynamic loader: 1321674 cycles
> >      26019:                 time needed for relocation: 797948 cycles
> (60.3%)
> >      26019:                      number of relocations: 624
> >      26019:           number of relocations from cache: 3
> >      26019:             number of relative relocations: 9691
> >      26019:                time needed to load objects: 389972 cycles
> (29.5%)
> > Could not open a connection to your authentication agent.
> >      26019:
> >      26019:     runtime linker statistics:
> >      26019:                final number of relocations: 630
> >      26019:     final number of relocations from cache: 3
> >
> > With prelink (ran prelink -av):
> >
> >       1930:
> >       1930:     runtime linker statistics:
> >       1930:       total startup time in dynamic loader: 462288 cycles
> >       1930:                 time needed for relocation: 48730 cycles
> (10.5%)
> >       1930:                      number of relocations: 7
> >       1930:           number of relocations from cache: 134
> >       1930:             number of relative relocations: 0
> >       1930:                time needed to load objects: 286076 cycles
> (61.8%)
> > Could not open a connection to your authentication agent.
> >       1930:
> >       1930:     runtime linker statistics:
> >       1930:                final number of relocations: 9
> >       1930:     final number of relocations from cache: 134
> >
> > I also tested against execstack, which for sure had the assertion fire
> on.
> > Without prelink:
> >
> >      27736:
> >      27736:     runtime linker statistics:
> >      27736:       total startup time in dynamic loader: 1955954 cycles
> >      27736:                 time needed for relocation: 755440 cycles
> (38.6%)
> >      27736:                      number of relocations: 247
> >      27736:           number of relocations from cache: 3
> >      27736:             number of relative relocations: 1353
> >      27736:                time needed to load objects: 710384 cycles
> (36.3%)
> > /usr/bin/execstack: no files given
> >      27736:
> >      27736:     runtime linker statistics:
> >      27736:                final number of relocations: 251
> >      27736:     final number of relocations from cache: 3
> >
> > With prelink:
> >
> >       3268:
> >       3268:     runtime linker statistics:
> >       3268:       total startup time in dynamic loader: 1421206 cycles
> >       3268:                 time needed for relocation: 199396 cycles
> (14.0%)
> >       3268:                      number of relocations: 3
> >       3268:           number of relocations from cache: 88
> >       3268:             number of relative relocations: 0
> >       3268:                time needed to load objects: 696886 cycles
> (49.0%)
> > /usr/bin/execstack: no files given
> >       3268:
> >       3268:     runtime linker statistics:
> >       3268:                final number of relocations: 5
> >       3268:     final number of relocations from cache: 88
> >
> > So, it looks like prelink is working on these :)
> >
> > On Tue, May 28, 2019 at 2:57 PM Mark Hatle <mark.hatle at windriver.com
> > <mailto:mark.hatle at windriver.com>> wrote:
> >
> >     Sorry for my delayed reply.  I was out on a business trip.
> >
> >     Did you try this with the ld.so statistics to see if the relocations
> were indeed
> >     reduced at runtime?
> >
> >     One of my worries with these changes (since I am not an ELF expert
> either) is
> >     that we make a change that doesn't actually do anything -- but
> people expect
> >     it to.
> >
> >     $ LD_DEBUG=help /lib/ld-linux.so.2
> >     Valid options for the LD_DEBUG environment variable are:
> >
> >       libs        display library search paths
> >       reloc       display relocation processing
> >       files       display progress for input file
> >       symbols     display symbol table processing
> >       bindings    display information about symbol binding
> >       versions    display version dependencies
> >       scopes      display scope information
> >       all         all previous options combined
> >       statistics  display relocation statistics
> >       unused      determined unused DSOs
> >       help        display this help message and exit
> >
> >     To direct the debugging output into a file instead of standard output
> >     a filename can be specified using the LD_DEBUG_OUTPUT environment
> variable.
> >
> >     I believe that it's the 'statistics' option.
> >
> >     LD_DEBUG=statistics <executable that's been prelinked>
> >
> >     Should result in something like:
> >
> >         128820:     runtime linker statistics:
> >         128820:       total startup time in dynamic loader: 1974661
> cycles
> >         128820:                 time needed for relocation: 354639
> cycles (17.9%)
> >         128820:                      number of relocations: 90
> >         128820:           number of relocations from cache: 3
> >         128820:             number of relative relocations: 1201
> >         128820:                time needed to load objects: 1303654
> cycles (66.0%)
> >         128820:
> >         128820:     runtime linker statistics:
> >         128820:                final number of relocations: 94
> >         128820:     final number of relocations from cache: 3
> >
> >     If prelink is working, the number of relocations (relative or
> otherwise) will be
> >     significantly reduced from the original non-relocated version.
> >
> >     If you can run this test, it would give me the assurance that the
> patch is safe,
> >     and I'll get it incorporated into the prelink-cross sources.
> >
> >     --Mark
> >
> >     On 5/25/19 2:53 PM, Shane Peelar wrote:
> >     > Patch is attached.  Thank you!
> >     >
> >     > On Sat, May 25, 2019 at 2:30 AM Khem Raj <raj.khem at gmail.com
> >     <mailto:raj.khem at gmail.com>
> >     > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>> wrote:
> >     >
> >     >     On Fri, May 24, 2019 at 6:58 PM Shane Peelar
> >     <lookatyouhacker at gmail.com <mailto:lookatyouhacker at gmail.com>
> >     >     <mailto:lookatyouhacker at gmail.com <mailto:
> lookatyouhacker at gmail.com>>>
> >     wrote:
> >     >     >
> >     >     > Great!  Would you be willing to accept a patch that makes
> arch-x86_64.c
> >     >     handle that condition like the other arches?
> >     >     >
> >     >
> >     >     yes certainly.
> >     >
> >     >     > -Shane
> >     >     >
> >     >     > On Fri, May 24, 2019 at 12:27 PM Khem Raj <
> raj.khem at gmail.com
> >     <mailto:raj.khem at gmail.com>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>
> wrote:
> >     >     >>
> >     >     >>
> >     >     >>
> >     >     >> On 5/24/19 8:10 AM, Shane Peelar wrote:
> >     >     >> > I did some reading into the sources in other
> architectures.  The
> >     closest
> >     >     >> > match, arch_i386.c, makes the write conditional as you
> say.
> >     >     >> > So do other arches, including |arch_arm.c, |arch_sh.c,
> |arch-mips.c,
> >     >     >> > |arch-s390.c, |arch-s390x.c, and |arch-ia64.c.||||||
> >     >     >> > ||||||
> >     >     >> > ||||||
> >     >     >> > Notably, |||||||arch-cris.c||||||| has the same assert as
> >     >     >> > |||||||arch-x86_64.c||||||| instead of the conditional.
> >     >     >> >
> >     >     >> > The code roughly looks like follows:||||||||||||||
> >     >     >> > ||||||||||||||
> >     >     >> > |||||||
> >     >     >> > |||||||
> >     >     >> > 1. Check for dso->info[DT_PLTGOT].  If it does not exist,
> return 0
> >     >     >> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if
> error
> >     >     >> > 3. Look for the section named ".plt" in the ELF.
> >     >     >> > 4. If the section cannot be found, return 0
> >     >     >> > 5. Otherwise, write the address of .plt + constant
> (dependent on
> >     arch)
> >     >     >> > to got[1]||||||||||||||
> >     >     >> > ||||||||||||||
> >     >     >> > |||||||
> >     >     >> > |||||||
> >     >     >> > In |||||||arch-x86_64.c and arch-cris.c|||||||, step (4)
> above is an
> >     >     >> > assert:|||||||
> >     >     >> >
> >     >     >> > |||||||1. Check for dso->info[DT_PLTGOT].  If it does not
> exist,
> >     return 0
> >     >     >> > 2. Call addr_to_sec on dso->info[DT_PLTGOT], return 1 if
> error
> >     >     >> > 3. Look for the section named ".plt" in the ELF.
> >     >     >> > 4. Assert that the section was found
> >     >     >> > 5. Write the address of .plt + constant (dependent on
> arch) to got[1]
> >     >     >> >
> >     >     >> > I tested out making the assert conditional and nothing
> seemed to
> >     break
> >     >     >> > at least.
> >     >     >> > |||||||
> >     >     >> > |||||||
> >     >     >>
> >     >     >> It seems ok to me.
> >     >     >>
> >     >     >> >
> >     >     >> > On Fri, May 24, 2019 at 12:08 AM Khem Raj <
> raj.khem at gmail.com
> >     <mailto:raj.khem at gmail.com>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
> >     >     >> > <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>> wrote:
> >     >     >> >
> >     >     >> >
> >     >     >> >
> >     >     >> >     On 5/23/19 7:53 PM, Shane Peelar wrote:
> >     >     >> >      > Any of them on the system pretty much, and yes
> they are also
> >     >     >> >     built with
> >     >     >> >      > -fno-plt.
> >     >     >> >
> >     >     >> >     OK, I think its better to them conditionally check
> for .plt
> >     section,
> >     >     >> >     can you describe more of whats going on when sections
> are
> >     checked.
> >     >     >> >
> >     >     >> >      >
> >     >     >> >      > On Thu, May 23, 2019 at 9:59 PM Khem Raj
> >     <raj.khem at gmail.com <mailto:raj.khem at gmail.com>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
> >     >     >> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com
> >
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>
> >     >     >> >      > <mailto:raj.khem at gmail.com <mailto:
> raj.khem at gmail.com>
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>
> >     >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>
> >     <mailto:raj.khem at gmail.com <mailto:raj.khem at gmail.com>>>>> wrote:
> >     >     >> >      >
> >     >     >> >      >
> >     >     >> >      >
> >     >     >> >      >     On 5/23/19 8:05 AM, Shane Peelar wrote:
> >     >     >> >      >      > Hi Everyone @ the Yocto project,
> >     >     >> >      >      >
> >     >     >> >      >      > I'm Shane Peelar, a PhD Candidate at the
> University of
> >     >     >> >     Windsor.
> >     >     >> >      >      > I'm writing to you about prelink-cross, as
> part of the
> >     >     >> >     Yocto project.
> >     >     >> >      >      > Specifically, I'm looking at using it with
> executables
> >     >     >> >     built using
> >     >     >> >      >      > `-fno-plt` under GCC.
> >     >     >> >      >      > I wasn't quite sure where to send this
> email to, so I
> >     >     >> >     figured I'd
> >     >     >> >      >     try
> >     >     >> >      >      > here.  If there's a better place to send
> this,
> >     please let
> >     >     >> >     me know.
> >     >     >> >      >      >
> >     >     >> >      >      > Right now, prelink-cross seems to fail an
> assertion in
> >     >     >> >      >     arch-x86_64.c,
> >     >     >> >      >      > line 421, when
> >     >     >> >      >      > using it with an executable built with
> `-fno-plt`:
> >     >     >> >      >      >
> >     >     >> >      >      > ...
> >     >     >> >      >      > assert (i < dso->ehdr.e_shnum)
> >     >     >> >      >      > ...
> >     >     >> >      >      >
> >     >     >> >      >      > This snippet seems to be looking for the
> ".plt"
> >     section and,
> >     >     >> >      >     since it
> >     >     >> >      >      > can't find it, the assertion fires.  This
> makes sense
> >     >     >> >     because in
> >     >     >> >      >      > `-fno-plt` executables, the `.plt` section
> is missing
> >     >     >> >     entirely.
> >     >     >> >      >      > I'm not an expert on ELF stuff, although I
> am learning
> >     >     >> >     quickly.  It
> >     >     >> >      >      > looks like
> >     >     >> >      >      > this code wants to write into GOT[1] the
> address of
> >     ".plt"
> >     >     >> >     + 0x16 --
> >     >     >> >      >      > since ".plt" doesn't
> >     >     >> >      >      > exist, does it make sense to just change
> this
> >     assert to an if
> >     >     >> >      >     statement
> >     >     >> >      >      > like so:
> >     >     >> >      >      >
> >     >     >> >      >      > ...
> >     >     >> >      >      >        if (i < dso->ehdr.e_shnum)
> >     >     >> >      >      >        { ... }
> >     >     >> >      >      > ...
> >     >     >> >      >      >
> >     >     >> >      >      > and skip over that part?  Or is this a real
> error
> >     >     >> >     condition for
> >     >     >> >      >      > prelink-cross and it really should not
> continue?  The
> >     >     >> >     executable in
> >     >     >> >      >      > question is also non-PIE, if that makes a
> difference.
> >     >     >> >      >      >
> >     >     >> >      >
> >     >     >> >      >     what shared libs is this linking to ? are they
> also
> >     built with
> >     >     >> >      >     -fno-plt ?
> >     >     >> >      >
> >     >     >> >      >      > Thanks for your time,
> >     >     >> >      >      > Shane
> >     >     >> >      >      >
> >     >     >> >      >
> >     >     >> >
> >     >
> >     >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190602/4e69d965/attachment-0001.html>

From marek.belisko at gmail.com  Sun Jun  2 23:42:07 2019
From: marek.belisko at gmail.com (Belisko Marek)
Date: Mon, 3 Jun 2019 08:42:07 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd
	package
In-Reply-To: <20190601182556.GB19383@archworkstation>
References: <20190601144016.GA19383@archworkstation>
	<CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
	<20190601182556.GB19383@archworkstation>
Message-ID: <CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>

On Sat, Jun 1, 2019 at 8:26 PM Morn? Lamprecht <morne at linux.com> wrote:
>
> >I would check run.do_rootfs and check it maybe
> >there will be some more info.
>
> I checked it based on your suggestion,
> unfortunately found no relevant info.
>
> >Do you have some custom extension for hostapd?
>
> No, just the standard package.
Which startup system do you use (sysVinit or systemd)?
You can take a look at poky/meta/classed/update-rc.d.bbclass which
checks various parameters and try to debug it (by adding some
printouts).
By my guess is that some misconfiguration between systemd/sysvinit
must cause this issue. Thanks.
>
>                 - Morn?

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

From dimtass at gmail.com  Mon Jun  3 00:53:33 2019
From: dimtass at gmail.com (Dimitris Tassopoulos)
Date: Mon, 3 Jun 2019 09:53:33 +0200
Subject: [yocto] How to extract files from wic.gz image?
In-Reply-To: <CAA=hcWQwSD4MLVJLbNz2nzv0SQAgMdkcnRPFfPCQN5NW+7XYhw@mail.gmail.com>
References: <CAA=hcWTwG4oo=qJvbrx04zaTXRy8u1H6HLEGV_J7r25jpzSVOA@mail.gmail.com>
	<20190531132253.GC20781@bill-the-cat>
	<CAA=hcWQwSD4MLVJLbNz2nzv0SQAgMdkcnRPFfPCQN5NW+7XYhw@mail.gmail.com>
Message-ID: <CACKFPN0fDvi=G624dXNnEdegitvJ4jDUS0QzoYGrNEvjAs411A@mail.gmail.com>

Hi JH,

I believe the most important feature of the wic images is to be able to
flash your SD card faster than just extract and dd the full image on the
SD card. For that reason you can use the bmap-tool which already supports
the gz  compression (as also .bz2). To do that you also need the bmap file
for this image. If it's not already there then you can add it your in your
image
like this:

IMAGE_FSTYPES += "wic.bmap"

(see also here:
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#flashing-images-using-bmaptool
)

Then you can just run:

$ sudo bmaptool copy dev-image-20190528085324.rootfs.wic.gz /dev/sdX

and you copy the gz image on your SD much much faster.

Regards,
Dimitris

On Sat, Jun 1, 2019 at 12:40 PM JH <jupiter.hce at gmail.com> wrote:

> Thanks Zoran and Tom, I can use dd to install the image to SD card on
> IMX EVK, now I need to install the image to NAND flash of a customized
> IMX device via USB HID, it cannot use the dd, IMX provided UUU utility
> which I am new to it and I have to decompose the image to
> zImage-initramfs and  losetup -P does work, dd does not work either.
>
> $ losetup -P dev-image-20190528085324.rootfs.wic
> losetup: solar-dev-image-solarevk-20190518084330.rootfs.wic: failed to
> use device: No such device
>
> Thanks for your helps anyway.
>
> Kind regards,
>
> - jupiter
>
> On 5/31/19, Tom Rini <trini at konsulko.com> wrote:
> > On Fri, May 31, 2019 at 10:21:40PM +1000, JH wrote:
> >> Hi,
> >>
> >> What command and tools to extract files from Yocto / bitbake image
> >> such as dev-image-20190528085324.rootfs.wic.gz?
> >>
> >> I am using IMX UUU to install dev-image-20190528085324.rootfs.wic.gz
> >> to IMX, I was advised to extract the archive and use "uuu <script
> >> name>" or "uuu u-boot-dtb.imx" to get bootloader work first.
> >
> > A wic image is just another way of saying it's a raw disk image.
> > Decompress it, losetup -P (generally useful, but not needed this time)
> > and dd out the contents you want.
> >
> > --
> > Tom
> >
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190603/fd0c3075/attachment.html>

From morne at linux.com  Mon Jun  3 01:35:08 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Mon, 3 Jun 2019 10:35:08 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd
 package
In-Reply-To: <CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>
References: <20190601144016.GA19383@archworkstation>
	<CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
	<20190601182556.GB19383@archworkstation>
	<CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>
Message-ID: <20190603083508.GC26408@archworkstation>

>Which startup system do you use (sysVinit or 
>systemd)? You can take a look at 
>poky/meta/classed/update-rc.d.bbclass which 
>checks various parameters and try to debug it 
>(by adding some printouts). By my guess is that 
>some misconfiguration between systemd/sysvinit 
>must cause this issue.

I'm using systemd. I think you may be right, I'll 
have a look at update-rc.d.bbclass and see if I 
can debug it.

Thanks for the advice !

		- Morn?

From joaohf at gmail.com  Mon Jun  3 04:23:24 2019
From: joaohf at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Henrique_Freitas?=)
Date: Mon, 3 Jun 2019 13:23:24 +0200
Subject: [yocto] EMQ recipe
Message-ID: <CANFVK78ctFWHod+_T+f7McxR9vuSpKj7jghhipyJLe0R16BB6g@mail.gmail.com>

Hi,

I'm the author of a Yocto Project layer called meta-erlang. I would like to
announce that now is possible to use Yocto Project which build a embedded
Linux distro and on top of that install the EMQ (a mqtt broker) or EMQ
edge. I've created the recipe and all the patches necessary to do that.

My main target is to bring software made with Erlang/Elixir possible to run
in Yocto/Openembedded ecosystem.

Just in case, if you have a embedded project and are planing to run emq
edge, for example. This could be feasible for you.

Check it:

 - https://layers.openembedded.org/layerindex/branch/master/recipes/?q=emq
 - http://joaohf.github.io/meta-erlang/#/guides-emqx
 - https://github.com/joaohf/meta-erlang
 - https://www.yoctoproject.org/
 - https://www.emqx.io/

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190603/17b35f31/attachment.html>

From morne at linux.com  Mon Jun  3 07:05:46 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Mon, 3 Jun 2019 16:05:46 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd
 package
In-Reply-To: <CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>
References: <20190601144016.GA19383@archworkstation>
	<CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
	<20190601182556.GB19383@archworkstation>
	<CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>
Message-ID: <20190603140546.GA28701@archworkstation>

>Which startup system do you use (sysVinit or 
>systemd)? You can take a look at 
>poky/meta/classed/update-rc.d.bbclass which 
>checks various parameters and try to debug it 
>(by adding some printouts). By my guess is that 
>some misconfiguration between systemd/sysvinit 
>must cause this issue.

Adding DISTRO_FEATURES_remove += " sysvinit" to 
my distro conf file, solved the problem.

I also have DISTRO_FEATURES_BACKFULL_CONSIDERED = 
"sysvinit" in my config (also had it during the 
failed builds), I thought it would prevent 
sysvinit from being added/backfilled to the 
DISTRO features ? So I'm not sure why 
DISTRO_FEATURES_remove is also required in this 
case ?

		- Morn?

From ross.burton at intel.com  Mon Jun  3 08:30:33 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Mon, 3 Jun 2019 16:30:33 +0100
Subject: [yocto] do_rootfs fails while attempting to install hostapd
	package
In-Reply-To: <20190603140546.GA28701@archworkstation>
References: <20190601144016.GA19383@archworkstation>
	<CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
	<20190601182556.GB19383@archworkstation>
	<CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>
	<20190603140546.GA28701@archworkstation>
Message-ID: <CAJTo0Lab3g3xnpzSCo-Uu2_q7ujGzWEhrB-0WyBAs=zG=v7GaA@mail.gmail.com>

On Mon, 3 Jun 2019 at 15:06, Morn? Lamprecht <morne at linux.com> wrote:
> I also have DISTRO_FEATURES_BACKFULL_CONSIDERED =
> "sysvinit" in my config (also had it during the
> failed builds), I thought it would prevent
> sysvinit from being added/backfilled to the
> DISTRO features ? So I'm not sure why
> DISTRO_FEATURES_remove is also required in this
> case ?

The variable is DISTRO_FEATURES_BACKFILL_CONSIDERED, in case that
wasn't a typo when writing the mail.

Ross

From morne at linux.com  Mon Jun  3 09:54:06 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Mon, 3 Jun 2019 18:54:06 +0200
Subject: [yocto] do_rootfs fails while attempting to install hostapd
 package
In-Reply-To: <CAJTo0Lab3g3xnpzSCo-Uu2_q7ujGzWEhrB-0WyBAs=zG=v7GaA@mail.gmail.com>
References: <20190601144016.GA19383@archworkstation>
	<CAAfyv35XN0SiU8PQ0ZL9tXSk52FxkCsOjuXoxYM35egNL6DTxw@mail.gmail.com>
	<20190601182556.GB19383@archworkstation>
	<CAAfyv37b6xSxKE=HYEUkDOQkTYPP_fom73bpf-k07-jT0p6kuQ@mail.gmail.com>
	<20190603140546.GA28701@archworkstation>
	<CAJTo0Lab3g3xnpzSCo-Uu2_q7ujGzWEhrB-0WyBAs=zG=v7GaA@mail.gmail.com>
Message-ID: <20190603165406.GA24026@archworkstation>

On Mon, Jun 03, 2019 at 04:30:33PM +0100, Burton, Ross wrote:
>The variable is 
>DISTRO_FEATURES_BACKFILL_CONSIDERED, in case 
>that wasn't a typo when writing the mail.

It wasn't a typo, and that was exactly the 
problem.  Well spotted, everything in the world 
makes sense again :-)

		- Morn?

From zoran.stojsavljevic at gmail.com  Mon Jun  3 10:38:47 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Mon, 3 Jun 2019 19:38:47 +0200
Subject: [yocto] Potential (?) systemd YOCTO problems
Message-ID: <CAGAf8Lxb88uf_zw0Hzkc74zSD3GG4zQh-UwzQmBhMTLCxqRd5Q@mail.gmail.com>

Hello Folks,

I am a bit deeper to the systemd service investigation in YOCTO. I
installed systemd service, I also have network manager package.

I am using warrior. Here are the snippets of the HOST:
[user at fedora29-ssd build]$ bitbake --version
BitBake Build Tool Core version 1.42.0
[user at fedora29-ssd build]$ bitbake -s | grep networkmanager
networkmanager                                     :1.16.0-r0
networkmanager-openvpn                             :1.8.10-r0
python-networkmanager                                 :2.1-r0
[user at fedora29-ssd build]$ bitbake -s | grep systemd
python-systemd                                        :234-r0
python3-systemd                                       :234-r0
systemd                             1:241+AUTOINC+c1f8ff8d0d-r0
systemd-bootchart                   :233+gitAUTOINC+fe1c5e41e6-r0
systemd-bootconf                                     :1.00-r0
systemd-compat-units                                 :1.0-r29
systemd-conf                        :241+AUTOINC+c1f8ff8d0d-r0
systemd-machine-units                                :1.0-r19
systemd-serialgetty                                   :1.0-r5
systemd-systemctl-native                              :1.0-r6
[user at fedora29-ssd build]$

Still. I expected to see the following on the target (my BBB):
/etc/init.d/networking script, but I have the following:
root at beaglebone:/etc/init.d# pwd
/etc/init.d
root at beaglebone:/etc/init.d# ls -al
drwxr-xr-x    2 root     root          4096 Jun  3  2019 .
drwxr-xr-x   27 root     root          4096 May 30 23:46 ..
-rwxr-xr-x    1 root     root          1419 May 31  2019 socketcand
root at beaglebone:/etc/init.d#

The socketcand recipe is here:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/socketcand/socketcand.bb

Should I add something to the networkmanager recipe (to add some
inheritance)??? To have the component (network script) in
play/installed (in /etc/init.d/)?

The command: # systemctl restart systemd-networkd does work.

root at beaglebone:/etc/systemd# ls
coredump.conf   logind.conf     networkd.conf   sleep.conf
system.conf     user
journald.conf   network         resolved.conf   system
timesyncd.conf  user.conf
root at beaglebone:/etc/systemd# cd network
root at beaglebone:/etc/systemd/network# ls -al
drwxr-xr-x    2 root     root          4096 May 31 00:57 .
drwxr-xr-x    5 root     root          4096 Jun  3  2019 ..
root at beaglebone:/etc/systemd/network#

What I am doing wrong here?

Thank you,
Zoran
_______

From anibal.limon at linaro.org  Mon Jun  3 11:39:58 2019
From: anibal.limon at linaro.org (=?UTF-8?q?An=C3=ADbal=20Lim=C3=B3n?=)
Date: Mon,  3 Jun 2019 13:39:58 -0500
Subject: [yocto] [ptest-runner][PATCH] Add SPDX-License-Identifier:
	GPL-2.0-or-later to source files
Message-ID: <20190603183958.14830-1-anibal.limon@linaro.org>

Signed-off-by: An?bal Lim?n <anibal.limon at linaro.org>
---
 main.c             | 2 ++
 ptest_list.c       | 2 ++
 ptest_list.h       | 2 ++
 tests/main.c       | 2 ++
 tests/ptest_list.c | 2 ++
 tests/utils.c      | 2 ++
 utils.c            | 2 ++
 utils.h            | 2 ++
 8 files changed, 16 insertions(+)

diff --git a/main.c b/main.c
index e963efe..83cd8f2 100644
--- a/main.c
+++ b/main.c
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
diff --git a/ptest_list.c b/ptest_list.c
index 3e393d5..d48349f 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
diff --git a/ptest_list.h b/ptest_list.h
index 03d7539..b4b1ac6 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
diff --git a/tests/main.c b/tests/main.c
index cceda7d..c3b4da5 100644
--- a/tests/main.c
+++ b/tests/main.c
@@ -15,6 +15,8 @@
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
 *
+* SPDX-License-Identifier: GPL-2.0-or-later
+*
 * AUTHORS
 * 	An?bal Lim?n <anibal.limon at intel.com>
 */
diff --git a/tests/ptest_list.c b/tests/ptest_list.c
index 5c0036d..e0ec276 100644
--- a/tests/ptest_list.c
+++ b/tests/ptest_list.c
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
diff --git a/tests/utils.c b/tests/utils.c
index 2ccb1c0..3ba64d6 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
diff --git a/utils.c b/utils.c
index 05c2bfe..6e453a1 100644
--- a/utils.c
+++ b/utils.c
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
diff --git a/utils.h b/utils.h
index 5a3f44a..6175ed1 100644
--- a/utils.h
+++ b/utils.h
@@ -15,6 +15,8 @@
  * along with this program; if not, write to the Free Software
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
  *
+ * SPDX-License-Identifier: GPL-2.0-or-later
+ *
  * AUTHORS
  * 	An?bal Lim?n <anibal.limon at intel.com>
  */
-- 
2.20.1


From morne at linux.com  Mon Jun  3 12:07:11 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Mon, 3 Jun 2019 21:07:11 +0200
Subject: [yocto] Potential (?) systemd YOCTO problems
In-Reply-To: <CAGAf8Lxb88uf_zw0Hzkc74zSD3GG4zQh-UwzQmBhMTLCxqRd5Q@mail.gmail.com>
References: <CAGAf8Lxb88uf_zw0Hzkc74zSD3GG4zQh-UwzQmBhMTLCxqRd5Q@mail.gmail.com>
Message-ID: <20190603190711.GB24026@archworkstation>

On Mon, Jun 03, 2019 at 07:38:47PM +0200, Zoran Stojsavljevic wrote:
>Still. I expected to see the following on the 
>target (my BBB): /etc/init.d/networking script, 

I would have a look at the values of 
DISTRO_FEATURES_BACKFILL_CONSIDERED as well as 
VIRTUAL-RUNTIME_initscripts.

My understanding is that if the former is set to 
"sysvinit", it causes any redundant SysVinit 
scripts to be removed, and further, that if the 
latter is set to "", then all initscripts are 
removed from the image altogether.

		- Morn?

From richard.purdie at linuxfoundation.org  Mon Jun  3 15:38:08 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Mon, 03 Jun 2019 23:38:08 +0100
Subject: [yocto] [ptest-runner][PATCH] Add SPDX-License-Identifier:
 GPL-2.0-or-later to source files
In-Reply-To: <20190603183958.14830-1-anibal.limon@linaro.org>
References: <20190603183958.14830-1-anibal.limon@linaro.org>
Message-ID: <295ac49c8879f7c88e8ee6e8f6c6034ceeb844d9.camel@linuxfoundation.org>

On Mon, 2019-06-03 at 13:39 -0500, An?bal Lim?n wrote:
> Signed-off-by: An?bal Lim?n <anibal.limon at linaro.org>
> ---
>  main.c             | 2 ++
>  ptest_list.c       | 2 ++
>  ptest_list.h       | 2 ++
>  tests/main.c       | 2 ++
>  tests/ptest_list.c | 2 ++
>  tests/utils.c      | 2 ++
>  utils.c            | 2 ++
>  utils.h            | 2 ++
>  8 files changed, 16 insertions(+)
> 
> diff --git a/main.c b/main.c
> index e963efe..83cd8f2 100644
> --- a/main.c
> +++ b/main.c
> @@ -15,6 +15,8 @@
>   * along with this program; if not, write to the Free Software
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> MA  02110-1301, USA.
>   *
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + *
>   * AUTHORS
>   * 	An?bal Lim?n <anibal.limon at intel.com>
>   */

Looks good to me, thanks!

Cheers,

Richard


From mauro at faresoftware.it  Tue Jun  4 00:08:49 2019
From: mauro at faresoftware.it (Mauro Ziliani)
Date: Tue, 4 Jun 2019 09:08:49 +0200
Subject: [yocto] How to disable SIMD extensions (mmx, sse3, ...)?
Message-ID: <7e9f634a-175f-1e49-2d80-da364686d077@faresoftware.it>

Hi all.

I'm working with a Geode LX800, porting an old application Debian-based 
into Yocto Thud.

I need to disable some multimedia SIMD extensions for gcc compiler.

Where I can do this?

I suppose I have to disable SIMD extensions in 
conf/machine/geode_lx800.conf file (the machine descriptor file), but I 
cannot find any document about.


Can you help me?

MZ



From hongxu.jia at windriver.com  Tue Jun  4 00:54:06 2019
From: hongxu.jia at windriver.com (Hongxu Jia)
Date: Tue, 4 Jun 2019 15:54:06 +0800
Subject: [yocto] [meta-cgl][PATCH] resource-agents: improve reproducibility
Message-ID: <1559634846-13094-1-git-send-email-hongxu.jia@windriver.com>

Script ocf-binaries contains build path
$ grep tmp-glibc -rn image/
|image/usr/lib64/ocf/lib/heartbeat/ocf-binaries:11:: ${EGREP:="/buildarea1/hjia/
wrlinux-1019/build_master-wr_qemux86-64_2019053109/build/tmp-glibc/hosttools/grep -E"}
|image/usr/lib64/ocf/lib/heartbeat/ocf-binaries:16:: ${TEST:=/buildarea1/hjia/
wrlinux-1019/build_master-wr_qemux86-64_2019053109/build/tmp-glibc/hosttools/test}

Set grep/test path rather than using hosttools which refers
commit in oe-core [f6e7a3b libtool: Don't hardcode grep paths]

Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com>
---
 .../recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb     | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb
index 8b2b8e1..ba00a80 100644
--- a/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb
+++ b/meta-cgl-common/recipes-cgl/cluster-resource-agents/resource-agents_4.0.1.bb
@@ -44,6 +44,11 @@ RDEPENDS_${PN} += "bash perl lvm2 \
 
 inherit autotools systemd pkgconfig
 
+CACHED_CONFIGUREVARS += " \
+    ac_cv_path_GREP=grep \
+    ac_cv_path_TEST=test \
+"
+
 EXTRA_OECONF += "--disable-fatal-warnings \
                  --with-rsctmpdir=/var/run/heartbeat/rsctmp"
 
-- 
2.7.4


From jupiter.hce at gmail.com  Tue Jun  4 04:43:49 2019
From: jupiter.hce at gmail.com (JH)
Date: Tue, 4 Jun 2019 21:43:49 +1000
Subject: [yocto] How to build Yocto zImage ramdisk image format
Message-ID: <CAA=hcWSduw6wzQ_9pg1yT4jGwky0bfWypSS8tSJm72ZHh9Q+2w@mail.gmail.com>

Hi,

I build a zImage--imx.bin, dose it contains initramfs? I downloaded
the zImage to IMX using MfgTool, it got an error "Wrong Ramdisk Image
Format".

How to build a ramdisk image? Should it be a separate command or
should it use a ramdisk recipe?

I found a couple of initramfs.bb, such as
fsl-image-mfgtool-initramfs.bb, core-image-minimal-initramfs.bb, but
there is no ramdisk.bb.

Appreciate any examples to build a ramdisk image format.

Thank you.

- JH

From bunk at stusta.de  Tue Jun  4 04:45:51 2019
From: bunk at stusta.de (Adrian Bunk)
Date: Tue, 4 Jun 2019 14:45:51 +0300
Subject: [yocto] How to disable SIMD extensions (mmx, sse3, ...)?
In-Reply-To: <7e9f634a-175f-1e49-2d80-da364686d077@faresoftware.it>
References: <7e9f634a-175f-1e49-2d80-da364686d077@faresoftware.it>
Message-ID: <20190604114551.GB2249@localhost>

On Tue, Jun 04, 2019 at 09:08:49AM +0200, Mauro Ziliani wrote:
> Hi all.

Hi Mauro,

> I'm working with a Geode LX800, porting an old application Debian-based into
> Yocto Thud.

I assume you are aware that the Geode LX is should still work with the 
latest Debian releases.

> I need to disable some multimedia SIMD extensions for gcc compiler.

Why do you want to also disable MMX?
The AMD Geode LX does support MMX (and 3DNow!).

> Where I can do this?
> 
> I suppose I have to disable SIMD extensions in conf/machine/geode_lx800.conf
> file (the machine descriptor file), but I cannot find any document about.
> 
> Can you help me?

Passing -march=geode to the compiler should enable exactly the 
instructions supported by the CPU.

> MZ

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From richard.purdie at linuxfoundation.org  Tue Jun  4 07:13:43 2019
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Tue, 04 Jun 2019 15:13:43 +0100
Subject: [yocto] Yocto Project Status WW23'19
Message-ID: <6635a76b6f53140e31829e3b7e423e39736fe7e9.camel@linuxfoundation.org>

Current Dev Position: YP 2.8 M1Next Deadline: YP 2.8 Milestone 1 Cutoff
June 9th, 2019
SWAT Team Rotation: * SWAT lead is currently: Armin
 * SWAT team rotation: Armin -> Anuj on June 7, 2019
 * SWAT team rotation: Anuj -> Paul on June 14, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday June 6th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday June 4th at 8am PDT (
https://zoom.us/j/990892712) 
 * Twitch - Next event is Tuesday 11th June at 8am PDT (
https://www.twitch.tv/yocto_project)

Key Status/Updates: * 2.8 M1 is nearly upon us with just under a week
left for the remaining features/patches.
 * Stephen continues to be unavailable, please refer any queries to
Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. This shouldn?t impact users directly, more details will be sent
to the mailing lists before the transfer. THe Yocto Project lists will
move first, followed by OE, likely a week later.
 * We have a new ?newcomer? bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * Uninative 2.5 was released which supports gcc 9. This should fix
issues for fedora 30 builds and allow the bringup of fedora 30 workers
in the autobuilder too.
 * ARM native builds are now working on the autobuilder as well as KVM
accelerated ARM ptest and ltp testing.
 * There are ongoing concerns about perl module dependencies. Tim and
Richard have applied bandaids to solve some ptest issues but we really
need work in this area if there are any perl experts interested.
 * Many further ptests fixes have merged, thanks to all for the
contributions.

Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2507 (last week 2524) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
    * Total patches found: 1513 (last week 1525)
    * Patches in the Pending State: 646 (43%) [last week 649 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_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!]




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190604/6e0054ba/attachment-0001.html>

From quentin.schulz at streamunlimited.com  Tue Jun  4 08:11:55 2019
From: quentin.schulz at streamunlimited.com (Quentin Schulz)
Date: Tue, 4 Jun 2019 17:11:55 +0200
Subject: [yocto] Issue with INCOMPATIBLE_LICENSE
In-Reply-To: <20190531093143.r6ernips6l3yoevp@qschulz>
References: <20190531093143.r6ernips6l3yoevp@qschulz>
Message-ID: <20190604151155.vwoppnn6qlw3jyap@qschulz>

Hi all,

On Fri, May 31, 2019 at 11:31:43AM +0200, Quentin Schulz wrote:
> Hi all,
> 
> We're in the middle of an upgrade to Thud 2.6.2. While doing so, we
> blindly updated all upstream layers we use and we found out (during
> integration phase, no need to send lawyers :) ) that even though we have
> GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built.
> 
> conf/local.conf
> INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
> 
> https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb
> LICENSE = "GFDL-1.3 & BSD & ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 | The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | The-Qt-Company-Commercial )"
> 
> My understanding of the above LICENSE is that even though I have GPLv3
> blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the
> package got built. I'm not really happy with Qt doing that (no warning,
> no LICENSE_FLAGS). Quick question unrelated to the actual important
> question:
> 
> Would it be possible (theoritically, I know you've nothing to do with
> maintenance of meta-qt5; also not tested, just "pseudo-code") to have
> something like:
> python() {
> 	if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'):
> 		d.setVar("LICENSE_FLAGS", "commercial")
> }
> 
> so if we are blacklisting GPLv3, we have to add commercial_qtbase to
> LICENSE_FLAGS_WHITELIST to be able to build it.
> 
> So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as
> well and qtbase is still building. How so?
> 
> For me, it results in the following:
> LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 | not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which in the end looks like:
> LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which is basically:
> LICENSE = "not-compat"
> 
> Is there an error in this simplification?
> Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto?
> Have I missed something?
> Is there something actually buggy in the INCOMPATIBLE_LICENSE
> implementation?
> 
> Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as
> I wanted to exclude license "aliases" not being supported by
> INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what
> is said in the mega-manual).
> 
> I want to be sure to not be able to build qt >= 5.7, we're never too far
> from an unfortunate upgrade or people in the company not knowing we
> cannot use qt >= 5.7.
> 

It's actually a bit worse than I expected.

If I create a simple baz recipe with LICENSE = "FooLicense" and have
INCOMPATIBLE_LICENSE = "FooLicense" in conf/local.conf, `bitbake baz`
will NOT complain, and will be built.

Now, my understanding is that INCOMPATIBLE_LICENSE is passed[1] as an
argument to expand_wildcard_licenses[2] which returns a list of licenses
which have to be part of either SPDXLICENSEMAP or
SRC_DISTRIBUTE_LICENSES.

However, in the case of qtbase, The-Qt-Company-Commercial is nowhere to
be found in those variables.

Why do we filter INCOMPATIBLE_LICENSE to have only SPDX licenses or
their aliases (my understanding of respectively SRC_DISTRIBUTE_LICENSES
and SPDXLICENSEMAP)?
Is this actually expected?

If it is, can we please actually document it?

Also, how should one add a custom license? I could find this[3]
discussion on the ML but nothing "official". Can we document it? I
wouldn't know today what to do without having to read the source code
and the licensing is critical to most companies.

Let me know how and if I can help,
Thanks,
Quentin

[1] https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/base.bbclass#n524
[2] https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/license.bbclass#n265
[3] https://lists.yoctoproject.org/pipermail/yocto/2013-June/014366.html
-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.schulz at streamunlimited.com, www.streamunlimited.com

From alex.kanavin at gmail.com  Tue Jun  4 11:37:18 2019
From: alex.kanavin at gmail.com (Alexander Kanavin)
Date: Tue, 4 Jun 2019 20:37:18 +0200
Subject: [yocto] Issue with INCOMPATIBLE_LICENSE
In-Reply-To: <20190604151155.vwoppnn6qlw3jyap@qschulz>
References: <20190531093143.r6ernips6l3yoevp@qschulz>
	<20190604151155.vwoppnn6qlw3jyap@qschulz>
Message-ID: <CANNYZj9BzxqGVK959nddQeEquD6j553F4_Yra3vguZjnLzC4zQ@mail.gmail.com>

On Tue, 4 Jun 2019 at 17:12, Quentin Schulz <
quentin.schulz at streamunlimited.com> wrote:

> Why do we filter INCOMPATIBLE_LICENSE to have only SPDX licenses or
> their aliases (my understanding of respectively SRC_DISTRIBUTE_LICENSES
> and SPDXLICENSEMAP)?
> Is this actually expected?
>
> If it is, can we please actually document it?
>
> Also, how should one add a custom license? I could find this[3]
> discussion on the ML but nothing "official". Can we document it? I
> wouldn't know today what to do without having to read the source code
> and the licensing is critical to most companies.
>

Sending patches is far more efficient than asking questions; generally,
everyone is busy with their own problems. If you see a deficiency, and have
a clear idea how to make it better, please do contribute improvements.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190604/8888e915/attachment.html>

From andreea.volosincu at windriver.com  Tue Jun  4 12:39:08 2019
From: andreea.volosincu at windriver.com (Volosincu, Andreea S)
Date: Tue, 4 Jun 2019 19:39:08 +0000
Subject: [yocto] Yocto Project DevDay NA 2019 - Extend your Embedded Linux
 Conference Experience
Message-ID: <A084970538D2234B96D99D06FA9D974FC37CEE23@ALA-MBD.corp.ad.wrs.com>

Hello Everybody,

The registration for the Yocto Project DevDay NA 2019 is now open. Join our knowledgeable and engaging instructors to learn about creating custom-build Linux distributions using the Yocto Project infrastructure and tools, across multiple architectures.

Date: Tuesday, August 20, 2019
Time: 9:00 am - 5:00 pm
Location: Hilton San Diego Bayfront

There are two ways to register - by adding it your ELC registration or on the separate registration page.

Register now. <https://www.yoctoproject.org/yocto-project-dev-day-north-america-2019/>

Best regards,
Yocto Project Advocacy Team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190604/f549a4a9/attachment.html>

From zoran.stojsavljevic at gmail.com  Tue Jun  4 14:34:15 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Tue, 4 Jun 2019 23:34:15 +0200
Subject: [yocto] Fwd:  Potential (?) systemd YOCTO problems
In-Reply-To: <20190603190711.GB24026@archworkstation>
References: <CAGAf8Lxb88uf_zw0Hzkc74zSD3GG4zQh-UwzQmBhMTLCxqRd5Q@mail.gmail.com>
	<20190603190711.GB24026@archworkstation>
Message-ID: <CAGAf8LxXdZADK+ScSXLr1Ov-xAY24YsS2nZ-1-SpSKDbS3cBHw@mail.gmail.com>

> I would have a look at the values of
> DISTRO_FEATURES_BACKFILL_CONSIDERED as well as
> VIRTUAL-RUNTIME_initscripts.
>
> My understanding is that if the former is set to
> "sysvinit", it causes any redundant SysVinit
> scripts to be removed, and further, that if the
> latter is set to "", then all initscripts are
> removed from the image altogether.

I would like to thank you for the advice. I tried several combinations
without any success, and at the end I came up exactly what you have
suggested to me.

Local.conf looks something like this:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/experimental/local.conf_core-tools-profile

And the latest changes committed which I have tried following your
suggestion are:
https://github.com/ZoranStojsavljevic/bbb-yocto/commit/83c22e8ec516020206dc1b34e93276cca8f3f16b

I need to do more tests... But seems that initial tests show that all
scripts are in place, and systemd is used.

This also should be much better documented somewhere in YOCTO
documentation. My best guess (I did not find it anywhere in the
manuals, maybe I missed the paragraph - please, advice where it is?).

Thank you again,
Zoran
_______

On Mon, Jun 3, 2019 at 9:07 PM Morn? Lamprecht <morne at linux.com> wrote:
>
> On Mon, Jun 03, 2019 at 07:38:47PM +0200, Zoran Stojsavljevic wrote:
> >Still. I expected to see the following on the
> >target (my BBB): /etc/init.d/networking script,
>
> I would have a look at the values of
> DISTRO_FEATURES_BACKFILL_CONSIDERED as well as
> VIRTUAL-RUNTIME_initscripts.
>
> My understanding is that if the former is set to
> "sysvinit", it causes any redundant SysVinit
> scripts to be removed, and further, that if the
> latter is set to "", then all initscripts are
> removed from the image altogether.
>
>                 - Morn?
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From jupiter.hce at gmail.com  Tue Jun  4 19:32:35 2019
From: jupiter.hce at gmail.com (JH)
Date: Wed, 5 Jun 2019 12:32:35 +1000
Subject: [yocto] Yocto image types
Message-ID: <CAA=hcWRLVZXTeubkZwJtCRCBTGysUvkoPOoC3BPESOEUNoRpoA@mail.gmail.com>

Hi,

I built Yocto image, Could anyone explain what are files in
deploy/images directories?


modules--*.tgz

dev-image*rootfs.wic.gz

zImage*.bin

I guess modules--*.tgz is compressed file for all modules,
dev-image*rootfs.wic.gz is the rootfs image can be downloaded to SD
card, zImage*.bin is the compressed initramfs can be used by mfgtool
uuu for download to NAND flash, is it correct?

I currently has an error of for downloading zImage*.bin Wrong Ramdisk
Image Format. how can following recipes be used to add ramdisk format
to zImage?

meta-freescale/recipes-fsl/images/fsl-image-mfgtool-initramfs.bb
oe-core/meta/recipes-core/images/core-image-minimal-initramfs.bb

Thank you.

- JH

From martin.jansa at gmail.com  Wed Jun  5 00:56:02 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Wed,  5 Jun 2019 07:56:02 +0000
Subject: [yocto] [meta-gplv2][PATCH] elfutils: ignore new error from gcc-9
Message-ID: <20190605075602.599-1-Martin.Jansa@gmail.com>

Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
---
 recipes-devtools/elfutils/elfutils_0.148.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb
index a03b74e..1f07a28 100644
--- a/recipes-devtools/elfutils/elfutils_0.148.bb
+++ b/recipes-devtools/elfutils/elfutils_0.148.bb
@@ -57,6 +57,10 @@ SRC_URI += "\
 "
 inherit autotools gettext
 
+# There is a fix in 0.175 version (https://sourceware.org/bugzilla/show_bug.cgi?id=23884)
+# but 0.175 has different license, so to be safe don't backport the fix, just ignore the issue
+CFLAGS += "-Wno-error=missing-attributes"
+
 EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
 EXTRA_OECONF_append_class-native = " --without-bzlib"
 EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"
-- 
2.17.1


From dhanush.ks at gmail.com  Wed Jun  5 01:38:10 2019
From: dhanush.ks at gmail.com (Dhanush K.S)
Date: Wed, 5 Jun 2019 10:38:10 +0200
Subject: [yocto] -vfp arm tuning missing in builds and WORKDIR
Message-ID: <CAKPYHZ6AZWPxOahFhQVbKX=SDxh0WCA+f_XxzahY9cgso-hV9w@mail.gmail.com>

Currently the SDK that is being built, builds successfully but does not
contain the vfp arm tuning part included. Overriding the ?TARGET_FPU?
variable in the local.conf and setting it to *?vfp-neon?*, does reflect in
the Build Configuration section, but that still has no difference in the
SDK being built. The TARGET_FPU by default is been set to *?hard?. *This
was possible in the earlier versions on Yocto though. Setting the CFLAGS in
the machine configuration to -mfpu=vfp-neon also has taken no effect.


Would it have something to do with GCC itself?



In other words, the SDK currently being built is ?
poky-glibc-x86_64-my-meta-toolchain-cortexa8hf-neon-toolchain-2.5.sh? but
what is desired is ?
poky-glibc-x86_64-my-meta-toolchain-cortexa8hf-vfp-neon-toolchain-2.5.sh?



Below is my Build Config,

Build Configuration:

BB_VERSION           = "1.37.0"

BUILD_SYS            = "x86_64-linux"

NATIVELSBSTRING      = "universal-4.8"

TARGET_SYS           = "arm-poky-linux-gnueabi"

MACHINE              = "arm-cortex-a8"

DISTRO               = "poky"

DISTRO_VERSION       = "2.5"

TUNE_FEATURES        = "arm armv7a vfp neon callconvention-hard cortexa8"

TARGET_FPU           = "hard"

meta-bsp-ti

meta

meta-poky

meta-yocto-bsp

meta-my-common

meta-oe              = "<unknown>:<unknown>"



Did something change in the Sumo version of Yocto and Is there any other
way of achieving this?

Any leads in achieving and helping better understand is appreciated.


Thanks!


Best Regards,
Danny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190605/6fadbda8/attachment-0001.html>

From mans.zigher at gmail.com  Wed Jun  5 02:06:05 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 11:06:05 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
Message-ID: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>

Hi,

I am trying to build an SDK where I have multilib enabled in my
local.conf but I am encountering this error message

WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
/workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
(variant 'lib32')?
ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
lib32-alsa-lib in
virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk

I am currently using poky sumo could not see that anything have
changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
go through the code in both

./poky/meta/lib/oe/package_manager.py

and

./poky/meta/lib/oe/sstatesig.py

to see if I could understand why there is no manifest file created for
lib32-alsa-lib but without any luck. What task should I run to create
the Manifest file? Any other pointers to where I should look to
understand this issue is appreciated.

BR
M?ns Zigher

From pierluigi.greto at bisdn.de  Wed Jun  5 02:16:57 2019
From: pierluigi.greto at bisdn.de (Pierluigi Greto)
Date: Wed, 5 Jun 2019 11:16:57 +0200
Subject: [yocto] fitImage kernel compression type
Message-ID: <c4034430-bdf6-0324-9c7a-24257fb0327f@bisdn.de>

Hello everyone,

I'm building an fitImage and I would like to set the kernel compression 
type. Yocto is automatically creating the linux.bin but I cannot find 
any variable to specify the kernel compression type. I would like to 
have a gzip compressed kernel. Is possible to specify the compression 
type by using a variable? If not, there are other ways?

Thank you,
Pierluigi


From mans.zigher at gmail.com  Wed Jun  5 02:50:26 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 11:50:26 +0200
Subject: [yocto] fitImage kernel compression type
In-Reply-To: <c4034430-bdf6-0324-9c7a-24257fb0327f@bisdn.de>
References: <c4034430-bdf6-0324-9c7a-24257fb0327f@bisdn.de>
Message-ID: <CAEhQi8mqqHrC6-288e2TeFP+A-jfnTGXKvXhJdhPz3MzbQBJ5A@mail.gmail.com>

Have you looked at
https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/kernel-fitimage.bbclass?
I cannot see that there is an option for determining the compression.
It appears as if it looks specifically for bin-file. I am no expert
regarding fitimage format so I cannot say what the best solution is.

/M?ns

Den ons 5 juni 2019 kl 11:24 skrev Pierluigi Greto <pierluigi.greto at bisdn.de>:
>
> Hello everyone,
>
> I'm building an fitImage and I would like to set the kernel compression
> type. Yocto is automatically creating the linux.bin but I cannot find
> any variable to specify the kernel compression type. I would like to
> have a gzip compressed kernel. Is possible to specify the compression
> type by using a variable? If not, there are other ways?
>
> Thank you,
> Pierluigi
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From mans.zigher at gmail.com  Wed Jun  5 03:46:46 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 12:46:46 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
Message-ID: <CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>

When checking the build for lib32-alsa-lib there is no rpm package created

deploy-rpms/armv7ahf_neon_mx8mm# ls
lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm

it matches the alsa-lib build also when checking the list of packages by running

oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
list-pkg-files -p alsa-lib

there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
for this package? I would have thought that that should be the case?

/M?ns

Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> Hi,
>
> I am trying to build an SDK where I have multilib enabled in my
> local.conf but I am encountering this error message
>
> WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> (variant 'lib32')?
> ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> lib32-alsa-lib in
> virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
>
> I am currently using poky sumo could not see that anything have
> changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> go through the code in both
>
> ./poky/meta/lib/oe/package_manager.py
>
> and
>
> ./poky/meta/lib/oe/sstatesig.py
>
> to see if I could understand why there is no manifest file created for
> lib32-alsa-lib but without any luck. What task should I run to create
> the Manifest file? Any other pointers to where I should look to
> understand this issue is appreciated.
>
> BR
> M?ns Zigher

From mans.zigher at gmail.com  Wed Jun  5 04:00:17 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 13:00:17 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
	<CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
Message-ID: <CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>

I think this looks wrong
"manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
have not intentionally added lib32-alsa-lib to the nativesdk part so I
am not sure why it expects to find that?

/M?ns

Den ons 5 juni 2019 kl 12:46 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> When checking the build for lib32-alsa-lib there is no rpm package created
>
> deploy-rpms/armv7ahf_neon_mx8mm# ls
> lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
>
> it matches the alsa-lib build also when checking the list of packages by running
>
> oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> list-pkg-files -p alsa-lib
>
> there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> for this package? I would have thought that that should be the case?
>
> /M?ns
>
> Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
> >
> > Hi,
> >
> > I am trying to build an SDK where I have multilib enabled in my
> > local.conf but I am encountering this error message
> >
> > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > (variant 'lib32')?
> > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > lib32-alsa-lib in
> > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> >
> > I am currently using poky sumo could not see that anything have
> > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > go through the code in both
> >
> > ./poky/meta/lib/oe/package_manager.py
> >
> > and
> >
> > ./poky/meta/lib/oe/sstatesig.py
> >
> > to see if I could understand why there is no manifest file created for
> > lib32-alsa-lib but without any luck. What task should I run to create
> > the Manifest file? Any other pointers to where I should look to
> > understand this issue is appreciated.
> >
> > BR
> > M?ns Zigher

From mans.zigher at gmail.com  Wed Jun  5 04:39:58 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 13:39:58 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
	<CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
	<CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>
Message-ID: <CAEhQi8kPOsicUCWJTeVxUxuX93YAMsz-o6WWkQpcu9O77oxHLQ@mail.gmail.com>

I have the following manifest files

find . -name "manifest*-lib32-alsa-lib*"
./manifest-mimx8mm-lib32-alsa-lib.packagedata
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package

but find_sstate_manifest called from package_manager

./meta/lib/oe/package_manager.py:615:        manifest, d2 =
oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
multilibs)
./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
taskdata2, taskname, d, multilibcache):

will only look for

manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm

I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
file since this is not added to any other package when building it for
lib32.

/M?ns

Den ons 5 juni 2019 kl 13:00 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> I think this looks wrong
> "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> have not intentionally added lib32-alsa-lib to the nativesdk part so I
> am not sure why it expects to find that?
>
> /M?ns
>
> Den ons 5 juni 2019 kl 12:46 skrev M?ns Zigher <mans.zigher at gmail.com>:
> >
> > When checking the build for lib32-alsa-lib there is no rpm package created
> >
> > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> >
> > it matches the alsa-lib build also when checking the list of packages by running
> >
> > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > list-pkg-files -p alsa-lib
> >
> > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > for this package? I would have thought that that should be the case?
> >
> > /M?ns
> >
> > Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > >
> > > Hi,
> > >
> > > I am trying to build an SDK where I have multilib enabled in my
> > > local.conf but I am encountering this error message
> > >
> > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > > (variant 'lib32')?
> > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > > lib32-alsa-lib in
> > > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > >
> > > I am currently using poky sumo could not see that anything have
> > > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > > go through the code in both
> > >
> > > ./poky/meta/lib/oe/package_manager.py
> > >
> > > and
> > >
> > > ./poky/meta/lib/oe/sstatesig.py
> > >
> > > to see if I could understand why there is no manifest file created for
> > > lib32-alsa-lib but without any luck. What task should I run to create
> > > the Manifest file? Any other pointers to where I should look to
> > > understand this issue is appreciated.
> > >
> > > BR
> > > M?ns Zigher

From mans.zigher at gmail.com  Wed Jun  5 05:04:04 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 14:04:04 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8kPOsicUCWJTeVxUxuX93YAMsz-o6WWkQpcu9O77oxHLQ@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
	<CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
	<CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>
	<CAEhQi8kPOsicUCWJTeVxUxuX93YAMsz-o6WWkQpcu9O77oxHLQ@mail.gmail.com>
Message-ID: <CAEhQi8kLtWNVUNB3Zy6pC5xXJ_3pvroP9_QoPQDQSXE8aOXcuw@mail.gmail.com>

So running bitbake -e lib32-alsa-lib I can see the following

# $SSTATE_MANMACH [2 operations]
#   set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
#     "${SSTATE_PKGARCH}"
#   set sstate.bbclass:94
[__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
#     "armv7ahf-neon-mx8mm"
# pre-expansion value:
#   "armv7ahf-neon-mx8mm"
SSTATE_MANMACH="armv7ahf-neon-mx8mm"

So first the SSTATE_MANMACH variable is set to

SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"

at line 54 in sstate.bbclass but then it will be overwritten at line 94 to

d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

The code that results in this looks like

    if bb.data.inherits_class('native', d):
        d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
    elif bb.data.inherits_class('crosssdk', d):
        d.setVar('SSTATE_PKGARCH',
d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
    elif bb.data.inherits_class('cross', d):
        d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
    elif bb.data.inherits_class('nativesdk', d):
        d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
    elif bb.data.inherits_class('cross-canadian', d):
        d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
    elif bb.data.inherits_class('allarch', d) and
d.getVar("PACKAGE_ARCH") == "all":
        d.setVar('SSTATE_PKGARCH', "allarch")
    else:
        d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))

So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
not get to that else statement.

/M?ns

Den ons 5 juni 2019 kl 13:39 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> I have the following manifest files
>
> find . -name "manifest*-lib32-alsa-lib*"
> ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
>
> but find_sstate_manifest called from package_manager
>
> ./meta/lib/oe/package_manager.py:615:        manifest, d2 =
> oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> multilibs)
> ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> taskdata2, taskname, d, multilibcache):
>
> will only look for
>
> manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
>
> I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> file since this is not added to any other package when building it for
> lib32.
>
> /M?ns
>
> Den ons 5 juni 2019 kl 13:00 skrev M?ns Zigher <mans.zigher at gmail.com>:
> >
> > I think this looks wrong
> > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > am not sure why it expects to find that?
> >
> > /M?ns
> >
> > Den ons 5 juni 2019 kl 12:46 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > >
> > > When checking the build for lib32-alsa-lib there is no rpm package created
> > >
> > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > >
> > > it matches the alsa-lib build also when checking the list of packages by running
> > >
> > > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > > list-pkg-files -p alsa-lib
> > >
> > > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > > for this package? I would have thought that that should be the case?
> > >
> > > /M?ns
> > >
> > > Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > >
> > > > Hi,
> > > >
> > > > I am trying to build an SDK where I have multilib enabled in my
> > > > local.conf but I am encountering this error message
> > > >
> > > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > > > (variant 'lib32')?
> > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > > > lib32-alsa-lib in
> > > > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > > >
> > > > I am currently using poky sumo could not see that anything have
> > > > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > > > go through the code in both
> > > >
> > > > ./poky/meta/lib/oe/package_manager.py
> > > >
> > > > and
> > > >
> > > > ./poky/meta/lib/oe/sstatesig.py
> > > >
> > > > to see if I could understand why there is no manifest file created for
> > > > lib32-alsa-lib but without any luck. What task should I run to create
> > > > the Manifest file? Any other pointers to where I should look to
> > > > understand this issue is appreciated.
> > > >
> > > > BR
> > > > M?ns Zigher

From mans.zigher at gmail.com  Wed Jun  5 05:05:35 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 14:05:35 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8kLtWNVUNB3Zy6pC5xXJ_3pvroP9_QoPQDQSXE8aOXcuw@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
	<CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
	<CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>
	<CAEhQi8kPOsicUCWJTeVxUxuX93YAMsz-o6WWkQpcu9O77oxHLQ@mail.gmail.com>
	<CAEhQi8kLtWNVUNB3Zy6pC5xXJ_3pvroP9_QoPQDQSXE8aOXcuw@mail.gmail.com>
Message-ID: <CAEhQi8nhcSM=E3GveB4m6fqCf+dzMt6yYJHg6A3LW52uoe2pTg@mail.gmail.com>

Looking in the env dump I can see that meta-freescale is overwriting
the PACKAGE_ARCH in a alsa-lib_%.bbappend

PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"

/M?ns

Den ons 5 juni 2019 kl 14:04 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> So running bitbake -e lib32-alsa-lib I can see the following
>
> # $SSTATE_MANMACH [2 operations]
> #   set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
> #     "${SSTATE_PKGARCH}"
> #   set sstate.bbclass:94
> [__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
> #     "armv7ahf-neon-mx8mm"
> # pre-expansion value:
> #   "armv7ahf-neon-mx8mm"
> SSTATE_MANMACH="armv7ahf-neon-mx8mm"
>
> So first the SSTATE_MANMACH variable is set to
>
> SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
>
> at line 54 in sstate.bbclass but then it will be overwritten at line 94 to
>
> d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
>
> The code that results in this looks like
>
>     if bb.data.inherits_class('native', d):
>         d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
>     elif bb.data.inherits_class('crosssdk', d):
>         d.setVar('SSTATE_PKGARCH',
> d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
>     elif bb.data.inherits_class('cross', d):
>         d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
>     elif bb.data.inherits_class('nativesdk', d):
>         d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
>     elif bb.data.inherits_class('cross-canadian', d):
>         d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
>     elif bb.data.inherits_class('allarch', d) and
> d.getVar("PACKAGE_ARCH") == "all":
>         d.setVar('SSTATE_PKGARCH', "allarch")
>     else:
>         d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
>
> So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
> not get to that else statement.
>
> /M?ns
>
> Den ons 5 juni 2019 kl 13:39 skrev M?ns Zigher <mans.zigher at gmail.com>:
> >
> > I have the following manifest files
> >
> > find . -name "manifest*-lib32-alsa-lib*"
> > ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
> >
> > but find_sstate_manifest called from package_manager
> >
> > ./meta/lib/oe/package_manager.py:615:        manifest, d2 =
> > oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> > multilibs)
> > ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> > taskdata2, taskname, d, multilibcache):
> >
> > will only look for
> >
> > manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> > manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
> >
> > I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> > file since this is not added to any other package when building it for
> > lib32.
> >
> > /M?ns
> >
> > Den ons 5 juni 2019 kl 13:00 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > >
> > > I think this looks wrong
> > > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > > am not sure why it expects to find that?
> > >
> > > /M?ns
> > >
> > > Den ons 5 juni 2019 kl 12:46 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > >
> > > > When checking the build for lib32-alsa-lib there is no rpm package created
> > > >
> > > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > >
> > > > it matches the alsa-lib build also when checking the list of packages by running
> > > >
> > > > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > > > list-pkg-files -p alsa-lib
> > > >
> > > > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > > > for this package? I would have thought that that should be the case?
> > > >
> > > > /M?ns
> > > >
> > > > Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to build an SDK where I have multilib enabled in my
> > > > > local.conf but I am encountering this error message
> > > > >
> > > > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > > > > (variant 'lib32')?
> > > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > > > > lib32-alsa-lib in
> > > > > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > > > >
> > > > > I am currently using poky sumo could not see that anything have
> > > > > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > > > > go through the code in both
> > > > >
> > > > > ./poky/meta/lib/oe/package_manager.py
> > > > >
> > > > > and
> > > > >
> > > > > ./poky/meta/lib/oe/sstatesig.py
> > > > >
> > > > > to see if I could understand why there is no manifest file created for
> > > > > lib32-alsa-lib but without any luck. What task should I run to create
> > > > > the Manifest file? Any other pointers to where I should look to
> > > > > understand this issue is appreciated.
> > > > >
> > > > > BR
> > > > > M?ns Zigher

From mans.zigher at gmail.com  Wed Jun  5 05:44:42 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Wed, 5 Jun 2019 14:44:42 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8nhcSM=E3GveB4m6fqCf+dzMt6yYJHg6A3LW52uoe2pTg@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
	<CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
	<CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>
	<CAEhQi8kPOsicUCWJTeVxUxuX93YAMsz-o6WWkQpcu9O77oxHLQ@mail.gmail.com>
	<CAEhQi8kLtWNVUNB3Zy6pC5xXJ_3pvroP9_QoPQDQSXE8aOXcuw@mail.gmail.com>
	<CAEhQi8nhcSM=E3GveB4m6fqCf+dzMt6yYJHg6A3LW52uoe2pTg@mail.gmail.com>
Message-ID: <CAEhQi8nmgY7786+s4+u1g60-YDdbeDQBkp=Ngw3fAW5k3snSCA@mail.gmail.com>

So it looks like I should include armv7ahf-neon-mx8mm to
PACKAGE_EXTRA_ARCHS but I am unsure how to do that any ideas?

/M?ns

Den ons 5 juni 2019 kl 14:05 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> Looking in the env dump I can see that meta-freescale is overwriting
> the PACKAGE_ARCH in a alsa-lib_%.bbappend
>
> PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"
>
> /M?ns
>
> Den ons 5 juni 2019 kl 14:04 skrev M?ns Zigher <mans.zigher at gmail.com>:
> >
> > So running bitbake -e lib32-alsa-lib I can see the following
> >
> > # $SSTATE_MANMACH [2 operations]
> > #   set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
> > #     "${SSTATE_PKGARCH}"
> > #   set sstate.bbclass:94
> > [__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
> > #     "armv7ahf-neon-mx8mm"
> > # pre-expansion value:
> > #   "armv7ahf-neon-mx8mm"
> > SSTATE_MANMACH="armv7ahf-neon-mx8mm"
> >
> > So first the SSTATE_MANMACH variable is set to
> >
> > SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
> >
> > at line 54 in sstate.bbclass but then it will be overwritten at line 94 to
> >
> > d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> >
> > The code that results in this looks like
> >
> >     if bb.data.inherits_class('native', d):
> >         d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
> >     elif bb.data.inherits_class('crosssdk', d):
> >         d.setVar('SSTATE_PKGARCH',
> > d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
> >     elif bb.data.inherits_class('cross', d):
> >         d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
> >     elif bb.data.inherits_class('nativesdk', d):
> >         d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
> >     elif bb.data.inherits_class('cross-canadian', d):
> >         d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
> >     elif bb.data.inherits_class('allarch', d) and
> > d.getVar("PACKAGE_ARCH") == "all":
> >         d.setVar('SSTATE_PKGARCH', "allarch")
> >     else:
> >         d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> >
> > So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
> > not get to that else statement.
> >
> > /M?ns
> >
> > Den ons 5 juni 2019 kl 13:39 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > >
> > > I have the following manifest files
> > >
> > > find . -name "manifest*-lib32-alsa-lib*"
> > > ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
> > >
> > > but find_sstate_manifest called from package_manager
> > >
> > > ./meta/lib/oe/package_manager.py:615:        manifest, d2 =
> > > oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> > > multilibs)
> > > ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> > > taskdata2, taskname, d, multilibcache):
> > >
> > > will only look for
> > >
> > > manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> > > manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
> > >
> > > I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> > > file since this is not added to any other package when building it for
> > > lib32.
> > >
> > > /M?ns
> > >
> > > Den ons 5 juni 2019 kl 13:00 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > >
> > > > I think this looks wrong
> > > > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > > > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > > > am not sure why it expects to find that?
> > > >
> > > > /M?ns
> > > >
> > > > Den ons 5 juni 2019 kl 12:46 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > > >
> > > > > When checking the build for lib32-alsa-lib there is no rpm package created
> > > > >
> > > > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > >
> > > > > it matches the alsa-lib build also when checking the list of packages by running
> > > > >
> > > > > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > > > > list-pkg-files -p alsa-lib
> > > > >
> > > > > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > > > > for this package? I would have thought that that should be the case?
> > > > >
> > > > > /M?ns
> > > > >
> > > > > Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am trying to build an SDK where I have multilib enabled in my
> > > > > > local.conf but I am encountering this error message
> > > > > >
> > > > > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > > > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > > > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > > > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > > > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > > > > > (variant 'lib32')?
> > > > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > > > > > lib32-alsa-lib in
> > > > > > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > > > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > > > > >
> > > > > > I am currently using poky sumo could not see that anything have
> > > > > > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > > > > > go through the code in both
> > > > > >
> > > > > > ./poky/meta/lib/oe/package_manager.py
> > > > > >
> > > > > > and
> > > > > >
> > > > > > ./poky/meta/lib/oe/sstatesig.py
> > > > > >
> > > > > > to see if I could understand why there is no manifest file created for
> > > > > > lib32-alsa-lib but without any luck. What task should I run to create
> > > > > > the Manifest file? Any other pointers to where I should look to
> > > > > > understand this issue is appreciated.
> > > > > >
> > > > > > BR
> > > > > > M?ns Zigher

From maciej.pijanowski at 3mdeb.com  Wed Jun  5 06:04:24 2019
From: maciej.pijanowski at 3mdeb.com (Maciej Pijanowski)
Date: Wed, 5 Jun 2019 15:04:24 +0200
Subject: [yocto] git fetcher - AUTOREV and best practices
Message-ID: <192ab27f-b9e0-246f-63bf-c49bd49516f2@3mdeb.com>

Hello,

As explained in the mega manual [1], when using the git:// fetcher,
setting the
SRCREV to ${AUTOREV} will result in building the latest commit from
given git
branch (master, if not specified otherwise).

Using AUTOREV feature in recipe has following implications as far as I
can see:

- the same recipe might get built using different git commit, depending
on when
? the build was run, which breaks the reproducibility,
- it imposes some potential security risk - by specifying the exact
commit in
? the recipe, we can at least say that this revision of this package is fine
? and we want to build it; with AUTOREV we might not be aware of the
code we're
? fetching

I'm wondering whether there are any best practices or strict rules
written down
for recipes getting upstream to follow in this area. When inspecting some of
the layers from the git.yoctoprojects.org, it appears that the AUTOREV
feature
is almost not used, besides a few exceptions.

I'm wondering whether it would make sense to raise a warning when git
fetcher
with AUTOREV is used, so it would be easier to build on top OE / Yocto with
reproducibility / security in mind.

I understand that this feature is mostly meant for development purposes. I'm
just looking for a tools how one could easily make sure that each
fetched source code
is verified prior compilation.

I've already looked at the https:// fetcher (which is mostly used for
fetching tarballs).
It requires the recipe to contain valid md5 and sha256 sums. Even if we
suppress the
error in case checksum mismatch in the recipe by setting the
BB_STRICT_CHECKSUM
to 0, we are still getting the warning, which is the desired behavior I
believe.


[1]:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-AUTOREV
[2]:
https://www.yoctoproject.org/docs/2.0.1/bitbake-user-manual/bitbake-user-manual.html#var-BB_STRICT_CHECKSUM

-- 
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190605/95a66ef8/attachment.pgp>

From ross.burton at intel.com  Wed Jun  5 09:01:34 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Wed, 5 Jun 2019 17:01:34 +0100
Subject: [yocto] [meta-gplv2][PATCH] elfutils: ignore new error from
	gcc-9
In-Reply-To: <20190605075602.599-1-Martin.Jansa@gmail.com>
References: <20190605075602.599-1-Martin.Jansa@gmail.com>
Message-ID: <CAJTo0Lb0M+xcNjjsjfaNK5q7dKAnj+QEw-Vb5joY8OuRz_RhvQ@mail.gmail.com>

Pushed, thanks.

Ross

On Wed, 5 Jun 2019 at 08:56, Martin Jansa <martin.jansa at gmail.com> wrote:
>
> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> ---
>  recipes-devtools/elfutils/elfutils_0.148.bb | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb b/recipes-devtools/elfutils/elfutils_0.148.bb
> index a03b74e..1f07a28 100644
> --- a/recipes-devtools/elfutils/elfutils_0.148.bb
> +++ b/recipes-devtools/elfutils/elfutils_0.148.bb
> @@ -57,6 +57,10 @@ SRC_URI += "\
>  "
>  inherit autotools gettext
>
> +# There is a fix in 0.175 version (https://sourceware.org/bugzilla/show_bug.cgi?id=23884)
> +# but 0.175 has different license, so to be safe don't backport the fix, just ignore the issue
> +CFLAGS += "-Wno-error=missing-attributes"
> +
>  EXTRA_OECONF = "--program-prefix=eu- --without-lzma"
>  EXTRA_OECONF_append_class-native = " --without-bzlib"
>  EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc"
> --
> 2.17.1
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From morne at linux.com  Wed Jun  5 09:17:20 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Wed, 5 Jun 2019 18:17:20 +0200
Subject: [yocto] Fwd:  Potential (?) systemd YOCTO problems
In-Reply-To: <CAGAf8LxXdZADK+ScSXLr1Ov-xAY24YsS2nZ-1-SpSKDbS3cBHw@mail.gmail.com>
References: <CAGAf8Lxb88uf_zw0Hzkc74zSD3GG4zQh-UwzQmBhMTLCxqRd5Q@mail.gmail.com>
	<20190603190711.GB24026@archworkstation>
	<CAGAf8LxXdZADK+ScSXLr1Ov-xAY24YsS2nZ-1-SpSKDbS3cBHw@mail.gmail.com>
Message-ID: <20190605161720.GA9461@archworkstation>

On Tue, Jun 04, 2019 at 11:34:15PM +0200, Zoran 
Stojsavljevic wrote:
>(I did not find it anywhere in the manuals, 
>maybe I missed the paragraph - please, advice 
>where it is?).

This is where I found it previously:
https://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#using-systemd-exclusively

>Thank you again,

Glad I could help.

		- Morn?

From yocto.user.mailinglist at gmail.com  Wed Jun  5 13:50:08 2019
From: yocto.user.mailinglist at gmail.com (Robert Berger)
Date: Wed, 5 Jun 2019 22:50:08 +0200
Subject: [yocto] warning: #warning _FORTIFY_SOURCE requires compiling with
 optimization (-O)
Message-ID: <10b2ce1c-c264-aa9d-7185-a693bd0ed34e@gmail.com>

Hi,

I can see in some examples:

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O)

which can be fixed by passing the proper CFLAGS.

Unfortunately the warning is only visible in log files.

1) Is there a way to show compiler warnings when you bitbake on the 
console (without -DDD and/or -v and filtering for warning:)

2) How would you add a check for this to insane.bbclass?

Regards,

Robert

From Qi.Chen at windriver.com  Wed Jun  5 18:08:26 2019
From: Qi.Chen at windriver.com (Chen Qi)
Date: Thu, 6 Jun 2019 09:08:26 +0800
Subject: [yocto] [meta-anaconda][PATCH] anaconda_oe.py: add ldconfig to
	DISTRO_FEATURES
Message-ID: <1559783306-19974-1-git-send-email-Qi.Chen@windriver.com>

'ldconfig' is a required distro feature for anaconda, so add it
before running any builds, otherwise, we get build failure due to
lack of 'ldconfig'.

Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
---
 lib/oeqa/selftest/cases/anaconda_oe.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/oeqa/selftest/cases/anaconda_oe.py b/lib/oeqa/selftest/cases/anaconda_oe.py
index 9cc6de4..e568709 100644
--- a/lib/oeqa/selftest/cases/anaconda_oe.py
+++ b/lib/oeqa/selftest/cases/anaconda_oe.py
@@ -19,6 +19,7 @@ class TestAnacondaOE(OESelftestTestCase):
         features += 'VIRTUAL-RUNTIME_init_manager = "systemd"\n'
         features += 'DISTRO_FEATURES_append = " systemd"\n'
         features += 'DISTRO_FEATURES_append = " pam"\n'
+        features += 'DISTRO_FEATURES_append = " ldconfig"\n'
         features += 'DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " sysvinit"\n'
         self.write_config(features)
         self.logger.info('local.conf:\n%s' % features)
-- 
2.7.4


From mail at oripessach.com  Wed Jun  5 21:42:01 2019
From: mail at oripessach.com (Ori Pessach)
Date: Wed, 5 Jun 2019 22:42:01 -0600
Subject: [yocto] QA issue [configure-unsafe] when compiling vlc
Message-ID: <CAJekvNTjU=BLhEOpx8TG_Kfam+F+FCak7rS_vzeuasEgPepUvA@mail.gmail.com>

Hi,

I'm trying to compile vlc 3.0.6 as part of my image from the recipe found
here:

https://layers.openembedded.org/layerindex/recipe/4796/

When bitbake configures the source, I get the following error:

ERROR: vlc-3.0.6-r0 do_configure: QA Issue: This autoconf log indicates
errors, it looked at host include and/or library paths while determining
system capabilities.
Rerun configure task after fixing this. [configure-unsafe]
ERROR: vlc-3.0.6-r0 do_configure: Fatal QA errors found, failing task.
ERROR: vlc-3.0.6-r0 do_configure:
ERROR: vlc-3.0.6-r0 do_configure: Function failed: do_qa_configure
ERROR: Logfile of failure stored in:
/home/ori/projects/poky/build/tmp/work/core2-64-poky-linux/vlc/3.0.6-r0/temp/log.do_configure.14767
ERROR: Task
(/home/ori/projects/poky/meta-openembedded/meta-multimedia/recipes-multimedia/vlc/vlc_3.0.6.bb:do_configure)
failed with exit code '1'

I looked in the log, and the problem happens when checking for the
existence of live555 - the configure script outputs this:

configure:32517: x86_64-poky-linux-g++  -m64 -march=core2 -mtune=core2
-msse3 -mfpmath=sse -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security
--sysroot=/home/ori/projects/poky/build/tmp/work/core2-64-poky-linux/vlc/3.0.6-r0/recipe-sysroot
-E  -I/usr/include/liveMedia -I/usr/include/groupsock
-I/usr/include/BasicUsageEnvironment -I/usr/include/UsageEnvironment
conftest.cpp
cc1plus: warning: include location "/usr/include/liveMedia" is unsafe for
cross-compilation [-Wpoison-system-directories]
cc1plus: warning: include location "/usr/include/groupsock" is unsafe for
cross-compilation [-Wpoison-system-directories]
cc1plus: warning: include location "/usr/include/BasicUsageEnvironment" is
unsafe for cross-compilation [-Wpoison-system-directories]
cc1plus: warning: include location "/usr/include/UsageEnvironment" is
unsafe for cross-compilation [-Wpoison-system-directories]

I verified that the include directories are in /usr/include/ under the
sysroot specified above, and I, say, move /usr/include/liveMedia out of the
way, compilation fails when the compiler doesn't find the headers, so it
doesn't seem like it's even looking under sysroot.

Any idea how I can fix this?

Thanks,

Ori
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190605/d46f401d/attachment.html>

From zangrc.fnst at cn.fujitsu.com  Thu Jun  6 00:41:47 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Thu, 6 Jun 2019 15:41:47 +0800
Subject: [yocto] [meta-security][master][warrior][PATCH] bastille: solved
	the conflict with perl-module-text-wrap and base-files
Message-ID: <20190606074147.7632-1-zangrc.fnst@cn.fujitsu.com>

-Remove the link to perl5 to resolve the conflict with perl-module-text-wrap.

-Remove the operation on /var/lock to resolve the conflict with base-files.

Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
---
 recipes-security/bastille/bastille_3.2.1.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/recipes-security/bastille/bastille_3.2.1.bb b/recipes-security/bastille/bastille_3.2.1.bb
index 152c03a..e9accb5 100644
--- a/recipes-security/bastille/bastille_3.2.1.bb
+++ b/recipes-security/bastille/bastille_3.2.1.bb
@@ -41,8 +41,7 @@ S = "${WORKDIR}/Bastille"
 
 do_install () {
 	install -d ${D}${sbindir}
-	install -d ${D}${libdir}/perl/site_perl/Curses
-	ln -sf perl ${D}/${libdir}/perl5
+	install -d ${D}${libdir}/perl5/site_perl/Curses
 
 	install -d ${D}${libdir}/Bastille
 	install -d ${D}${libdir}/Bastille/API
@@ -51,7 +50,6 @@ do_install () {
 	install -d ${D}${datadir}/Bastille/OSMap/Modules
 	install -d ${D}${datadir}/Bastille/Questions
 	install -d ${D}${datadir}/Bastille/FKL/configs/
-	install -d ${D}${localstatedir}/lock/subsys/bastille
 	install -d ${D}${localstatedir}/log/Bastille
 	install -d ${D}${sysconfdir}/Bastille
 	install -m 0755 AutomatedBastille  ${D}${sbindir}
-- 
2.20.1




From david.reyna at windriver.com  Thu Jun  6 00:56:46 2019
From: david.reyna at windriver.com (Reyna, David)
Date: Thu, 6 Jun 2019 07:56:46 +0000
Subject: [yocto]  Minutes: Yocto Project Technical Team Meeting 6/4/2019
Message-ID: <5E53D14CE4667A45B9A06760DE5D13D0F3C9ABD7@ALA-MBD.corp.ad.wrs.com>

Yocto Project Technical Team Meeting
MINUTES: 6/4/2019

Attendees: Richard, Armin, JoshuaW, Bruce, Michael, Randy, Scott, Alejandro, RobW, Ross, MichaelH, Tim, Vineela, David, Trevor, Sajal

RP:
  * YP-2.6 M1 for this coming Monday
  * ptest dependencies are improving, and we are getting better results
  * M1 at risk for patchtest, RP and Paul are working on it
  * Key change for M1 is GCC9, and we working on a few regressions
  * Need people to work on the NEWCOMER defects
  * Joshua is working on the autobuilder
  * Randy: Kevin will be pinged on the QEMU issue (PPC?)

Armin: Fedora Core 30 for M!? RP: we could add workers today to test that host. RP: FYI, we did get funding for updated build servers.

Armin: Question about ?xe? support, issue with supporting two tarball compressions. Evidently some hosts, and especially some containers, do not have an tar that supports ?J (specifically Thud) or do not have ?xe?. RP mentions that the Thud documentation does require ?xe?.

Randy: PTest improvements a priority for M2? RP: GCC9, bluez, and acl priorities for fixing.

Scott: Any specific help he can provide 2.8? There was mention of SPDX headers done but not licenses, more ptest, ARM autobuilder.

RP: Want to achieve for 2.8:
  * Ptest
  * License
  * reproducibility
  * hash equivalency important, needs updates to runqueue to implement,

Hash equivalency only as good as builds are reproducible. Mention that simple changes to perl rdepends can have a deep cascade effect. The feature needs to look at what changed, know that nothing really changed, and then substitute same hash and save un-needed rebuild. For example ?perl-native? rebuilds, look to see that it is binary equivalent (bit by bit). Another more flexible (but probably later) technique could be elf symbol comparison for equivalency. RP: goal is to make the checker pluggable so that enhancements are easy. Richard mentioned that it might be worth taking a month off of his daily merge tasks just to get this feature done.

Randy: Is there idle time we can use? Perhaps in some timezone like China? RP: usually fires off builds at end of his day, so not real idle timezone.

RP: can use help in getting pull requests together

RP: Automated tests, provable reproducible builds important to our upstream cred.

Scott: Meta-agl-v2? It has become hard to maintain, stale dependencies, no security patching, obsolete components.

RP: anything we are missing? Randy touched on Rust. RP: nice for 2.9, but reproducibility more important.

Tim: Meta-virtualization into core? Perhaps for 2.9. Meta-python? Split off V2 support to separate repo.

- David


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/0fc623d9/attachment-0001.html>

From mans.zigher at gmail.com  Thu Jun  6 01:02:32 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Thu, 6 Jun 2019 10:02:32 +0200
Subject: [yocto] How to set PACKAGE_EXTRA_ARCHS
Message-ID: <CAEhQi8m3pJtUMMzSH0enBmLz5=x4CYnvV3LW-1W8BHJdMDGR_w@mail.gmail.com>

Hi,

I am facing an issue described here
https://lists.yoctoproject.org/pipermail/yocto/2019-June/045565.html.
I have come to the conclusion that I need to add armv7ahf-neon-mx8mm
to PACKAGE_EXTRA_ARCHS but it is not obvious how to do that based on
what is stated in the reference manual
https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-PACKAGE_EXTRA_ARCHS,
at least not for me. I have gone through the existing usage of the
PACKAGE_EXTRA_ARCHS in poky but in there it is always used in
combination with tune so for example

PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon  =
"${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon"

How can I make sure to get armv7ahf-neon-mx8mm added to the
PACKAGE_EXTRA_ARCHS variable and where should it be set local.conf,
machine configuration?

BR
M?ns Zigher

From jupiter.hce at gmail.com  Thu Jun  6 04:09:21 2019
From: jupiter.hce at gmail.com (JH)
Date: Thu, 6 Jun 2019 21:09:21 +1000
Subject: [yocto] Support NAND flash
Message-ID: <CAA=hcWSh9-DaYwFED5UpT_h1C0H22HG76LVd3d+aL4V+LBQQBA@mail.gmail.com>

Hi,

Has anyone used NAND? Does the MTD already support the NAND driver or
do you have to work our the detailed driver yourself? Could you share
your experiences how to build the image and to hand and access the
NAND if it is required?

Thank you.

Kind regards,

- JH

From jupiter.hce at gmail.com  Thu Jun  6 04:15:46 2019
From: jupiter.hce at gmail.com (JH)
Date: Thu, 6 Jun 2019 21:15:46 +1000
Subject: [yocto] Support NAND flash
In-Reply-To: <CAA=hcWSh9-DaYwFED5UpT_h1C0H22HG76LVd3d+aL4V+LBQQBA@mail.gmail.com>
References: <CAA=hcWSh9-DaYwFED5UpT_h1C0H22HG76LVd3d+aL4V+LBQQBA@mail.gmail.com>
Message-ID: <CAA=hcWSmDyqJ2_4zw7-gXZ8KeB-wUk9G7iNieCsMQDGL3V2+Dg@mail.gmail.com>

More specific, looks to me that the drivers are OS based, the eCos has
NAND I/O, the OpenWRT has some support NAND I/O as well, how does the
Yocto support?

Thank you.

Kind regards,

- JH

On 6/6/19, JH <jupiter.hce at gmail.com> wrote:
> Hi,
>
> Has anyone used NAND? Does the MTD already support the NAND driver or
> do you have to work our the detailed driver yourself? Could you share
> your experiences how to build the image and to hand and access the
> NAND if it is required?
>
> Thank you.
>
> Kind regards,
>
> - JH
>

From holzmayr at rsi-elektrotechnik.de  Thu Jun  6 04:59:52 2019
From: holzmayr at rsi-elektrotechnik.de (Josef Holzmayr)
Date: Thu, 6 Jun 2019 13:59:52 +0200
Subject: [yocto] Support NAND flash
In-Reply-To: <CAA=hcWSmDyqJ2_4zw7-gXZ8KeB-wUk9G7iNieCsMQDGL3V2+Dg@mail.gmail.com>
References: <CAA=hcWSh9-DaYwFED5UpT_h1C0H22HG76LVd3d+aL4V+LBQQBA@mail.gmail.com>
	<CAA=hcWSmDyqJ2_4zw7-gXZ8KeB-wUk9G7iNieCsMQDGL3V2+Dg@mail.gmail.com>
Message-ID: <20190606115951.uc36gymkoqiod325@jholzmayr.localdomain>

On Thu, Jun 06, 2019 at 09:15:46PM +1000, JH wrote:
> More specific, looks to me that the drivers are OS based, the eCos has
> NAND I/O, the OpenWRT has some support NAND I/O as well, how does the
> Yocto support?

This is not exactly a "how does the yocto" support-thing. Yocto is not
the OS. The OS by itself is the Linux kernel, which has extensive NAND
support in a lot of varieties. If you want to have a look, see
https://elixir.bootlin.com/linux/latest/source/drivers/mtd and
especially the nand subdirectory. In a nutshell it goes like this: if
you buy a board, ask whomever gave it to you for a kernel plus config
that works. Also, they are in most cases also obliged to tell you how to
write something to the (NAND-)flash.

For the userspace side, there is the mtd-utils suite:
http://www.linux-mtd.infradead.org which is already nicely packaged for
OE: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/mtd/mtd-utils_git.bb

So these are your starting points, you have to apply them to your
specific setup yourself. The only common things I can think of is:
1) make sure your kernel+config support the flash chip in use
2) install the mtd-utils for interacting with it.

Greetz.

> 
> Thank you.
> 
> Kind regards,
> 
> - JH
> 
> On 6/6/19, JH <jupiter.hce at gmail.com> wrote:
> > Hi,
> >
> > Has anyone used NAND? Does the MTD already support the NAND driver or
> > do you have to work our the detailed driver yourself? Could you share
> > your experiences how to build the image and to hand and access the
> > NAND if it is required?
> >
> > Thank you.
> >
> > Kind regards,
> >
> > - JH
> >
> -- 
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
???????????????
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
???????????????
Amtsgericht Ingolstadt ? GmbH: HRB 191328 ? KG: HRA 170393
Gesch?ftsf?hrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548 

_____________________________________________________________
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Gesch?ftsf?hrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548


From quentin.schulz at streamunlimited.com  Thu Jun  6 05:14:54 2019
From: quentin.schulz at streamunlimited.com (Quentin Schulz)
Date: Thu, 6 Jun 2019 14:14:54 +0200
Subject: [yocto] Issue with INCOMPATIBLE_LICENSE
In-Reply-To: <20190531093143.r6ernips6l3yoevp@qschulz>
References: <20190531093143.r6ernips6l3yoevp@qschulz>
Message-ID: <20190606121454.tmzqfwn65upqjilu@qschulz>

FYI,

On Fri, May 31, 2019 at 11:31:43AM +0200, Quentin Schulz wrote:
> Hi all,
> 
> We're in the middle of an upgrade to Thud 2.6.2. While doing so, we
> blindly updated all upstream layers we use and we found out (during
> integration phase, no need to send lawyers :) ) that even though we have
> GPLv3 in INCOMPATIBLE_LICENSE, qt5.11 was built.
> 
> conf/local.conf
> INCOMPATIBLE_LICENSE = "GPLv3 GPLv3+ LGPLv3 LGPLv3+"
> 
> https://github.com/meta-qt5/meta-qt5/blob/thud/recipes-qt/qt5/qtbase_git.bb
> LICENSE = "GFDL-1.3 & BSD & ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 | The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | The-Qt-Company-Commercial )"
> 
> My understanding of the above LICENSE is that even though I have GPLv3
> blacklisted, because I haven't blacklisted The-Qt-Company-Commercial the
> package got built. I'm not really happy with Qt doing that (no warning,
> no LICENSE_FLAGS). Quick question unrelated to the actual important
> question:
> 
> Would it be possible (theoritically, I know you've nothing to do with
> maintenance of meta-qt5; also not tested, just "pseudo-code") to have
> something like:
> python() {
> 	if "GPLv3" in d.getVar('INCOMPATIBLE_LICENSE'):
> 		d.setVar("LICENSE_FLAGS", "commercial")
> }
> 
> so if we are blacklisting GPLv3, we have to add commercial_qtbase to
> LICENSE_FLAGS_WHITELIST to be able to build it.
> 

+ LICENSE_FLAGS = "${@ "commercial" if (incompatible_license_contains('GPL-3.0', True, False, d) or \
+             incompatible_license_contains('The-Qt-Company-GPL-Exception-1.0', True, False, d) or \
+             (incompatible_license_contains('GPL-2.0+', True, False, d) and \       
+              incompatible_license_contains('LGPL-3.0', True, False, d))) \         
+              else ''}"

For qtbase_git.bb seems to work fine.

LICENSE is GFDL-1.3 & BSD & ( GPL-3.0 & The-Qt-Company-GPL-Exception-1.0 | The-Qt-Company-Commercial ) & ( GPL-2.0+ | LGPL-3.0 | The-Qt-Company-Commercial )
So it is commercial if
GPL-3.0 | The-Qt-Company-GPL-Exception-1.0 | (GPL-2.0+ & LGPL-3.0) is
False.

> So now, the actual issue. I've blacklisted The-Qt-Company-Commercial as
> well and qtbase is still building. How so?
> 
> For me, it results in the following:
> LICENSE = "GFDL-1.3 & BSD & ( not-compat & The-Qt-Company-GPL-Exception-1.0 | not-compat ) & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which in the end looks like:
> LICENSE = "GFDL-1.3 & BSD & not-compat & ( GPL-2.0+ | LGPL-3.0 | not-compat )"
> which is basically:
> LICENSE = "not-compat"
> 
> Is there an error in this simplification?
> Am I misunderstanding how INCOMPATIBLE_LICENSE is working in Yocto?
> Have I missed something?
> Is there something actually buggy in the INCOMPATIBLE_LICENSE
> implementation?
> 
> Also, please note that I tested with GPL-3.0 in INCOMPATIBLE_LICENSE as
> I wanted to exclude license "aliases" not being supported by
> INCOMPATIBLE_LICENSE (and since it's what's apparently tested from what
> is said in the mega-manual).
> 
> I want to be sure to not be able to build qt >= 5.7, we're never too far
> from an unfortunate upgrade or people in the company not knowing we
> cannot use qt >= 5.7.
> 

FYI, a patch was sent regarding this issue:
http://lists.openembedded.org/pipermail/openembedded-core/2019-June/283266.html

Quentin
-- 
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
quentin.schulz at streamunlimited.com, www.streamunlimited.com

From pierluigi.greto at bisdn.de  Thu Jun  6 06:37:37 2019
From: pierluigi.greto at bisdn.de (Pierluigi Greto)
Date: Thu, 6 Jun 2019 15:37:37 +0200
Subject: [yocto] arm yocto-linux custom defconfig not working
Message-ID: <421b2493-0fe5-c286-bf96-e6888264806a@bisdn.de>

Hi,

I have to create a custom 4.14.49 linux kernel. In my recipe I have 
added my defconfig 
<https://github.com/opencomputeproject/OpenNetworkLinux/blob/master/packages/base/any/kernels/4.14-lts/configs/armel-iproc-all/armel-iproc-all.config>, 
but yocto it's not taking in consideration the defconfig. Instead it's 
building the kernel using the default values. Also the compilation task 
is to fast for building the kernel. My target system is an arm 
architecture (DEFAULTTUNE ?= "cortexa9").
I have tried also to append this on my recipe but the result does not 
change:

do_compile_prepend() {
 ???? cp ${WORKDIR}/defconfig ${B}/defconfig
 ???? cp ${WORKDIR}/defconfig ${B}/.config
 ???? oe_runmake -C ${B} ARCH=${ARCH} ${S}/defconfig
}

If i try to "cheat" and add cp ${WORKDIR}/defconfig ${S}/.config on the 
do_compile_prependobviously make will not work: "kernel-source is not 
clean, please run 'make mrprop' ".

Any suggestions is very welcome.

Thank you,
Pierluigi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/e8593dfc/attachment-0001.html>

From bruce.ashfield at gmail.com  Thu Jun  6 06:47:22 2019
From: bruce.ashfield at gmail.com (Bruce Ashfield)
Date: Thu, 6 Jun 2019 09:47:22 -0400
Subject: [yocto] arm yocto-linux custom defconfig not working
In-Reply-To: <421b2493-0fe5-c286-bf96-e6888264806a@bisdn.de>
References: <421b2493-0fe5-c286-bf96-e6888264806a@bisdn.de>
Message-ID: <CADkTA4POtjuyzbwNLs3ZwwJwCbrY_4V7Ccp2+LcECnCzpphQ1Q@mail.gmail.com>

On Thu, Jun 6, 2019 at 9:38 AM Pierluigi Greto <pierluigi.greto at bisdn.de> wrote:
>
> Hi,
>
> I have to create a custom 4.14.49 linux kernel. In my recipe I have added my defconfig, but yocto it's not taking in consideration the defconfig. Instead it's building the kernel using the default values. Also the compilation task is to fast for building the kernel. My target system is an arm architecture (DEFAULTTUNE ?= "cortexa9").
> I have tried also to append this on my recipe but the result does not change:

Can you share your kernel recipe and layer(s) + defconfig ? Things are
working fine for me, but if I can see (and build) your recipes perhaps
something can be spotted.

Bruce

>
> do_compile_prepend() {
>      cp ${WORKDIR}/defconfig ${B}/defconfig
>      cp ${WORKDIR}/defconfig ${B}/.config
>      oe_runmake -C ${B} ARCH=${ARCH} ${S}/defconfig
> }
>
> If i try to "cheat" and add cp ${WORKDIR}/defconfig ${S}/.config on the do_compile_prepend obviously make will not work: "kernel-source is not clean, please run 'make mrprop' ".
>
> Any suggestions is very welcome.
>
> Thank you,
> Pierluigi
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

From gabbla.malist at gmail.com  Thu Jun  6 06:59:17 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Thu, 6 Jun 2019 15:59:17 +0200
Subject: [yocto] arm yocto-linux custom defconfig not working
In-Reply-To: <CADkTA4POtjuyzbwNLs3ZwwJwCbrY_4V7Ccp2+LcECnCzpphQ1Q@mail.gmail.com>
References: <421b2493-0fe5-c286-bf96-e6888264806a@bisdn.de>
	<CADkTA4POtjuyzbwNLs3ZwwJwCbrY_4V7Ccp2+LcECnCzpphQ1Q@mail.gmail.com>
Message-ID: <CAAx3WaCOq=vv6_RwZq=6LEvavh-U3dnt+aSe_eaPHA-ey4yd9g@mail.gmail.com>

Hi Pierluigi,

just to be clear, have you specified your defconfig in the SRC_URI of your
kernel recipe? You can write an append file (that I guess you already did)
and add:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append= " file://defconfig"

The above snippet assume that you are placing defconfig in files/

Gabriele

Il giorno gio 6 giu 2019 alle ore 15:47 Bruce Ashfield <
bruce.ashfield at gmail.com> ha scritto:

> On Thu, Jun 6, 2019 at 9:38 AM Pierluigi Greto <pierluigi.greto at bisdn.de>
> wrote:
> >
> > Hi,
> >
> > I have to create a custom 4.14.49 linux kernel. In my recipe I have
> added my defconfig, but yocto it's not taking in consideration the
> defconfig. Instead it's building the kernel using the default values. Also
> the compilation task is to fast for building the kernel. My target system
> is an arm architecture (DEFAULTTUNE ?= "cortexa9").
> > I have tried also to append this on my recipe but the result does not
> change:
>
> Can you share your kernel recipe and layer(s) + defconfig ? Things are
> working fine for me, but if I can see (and build) your recipes perhaps
> something can be spotted.
>
> Bruce
>
> >
> > do_compile_prepend() {
> >      cp ${WORKDIR}/defconfig ${B}/defconfig
> >      cp ${WORKDIR}/defconfig ${B}/.config
> >      oe_runmake -C ${B} ARCH=${ARCH} ${S}/defconfig
> > }
> >
> > If i try to "cheat" and add cp ${WORKDIR}/defconfig ${S}/.config on the
> do_compile_prepend obviously make will not work: "kernel-source is not
> clean, please run 'make mrprop' ".
> >
> > Any suggestions is very welcome.
> >
> > Thank you,
> > Pierluigi
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/ffeece8f/attachment.html>

From pierluigi.greto at bisdn.de  Thu Jun  6 07:06:00 2019
From: pierluigi.greto at bisdn.de (Pierluigi Greto)
Date: Thu, 6 Jun 2019 16:06:00 +0200
Subject: [yocto] arm yocto-linux custom defconfig not working
In-Reply-To: <CADkTA4POtjuyzbwNLs3ZwwJwCbrY_4V7Ccp2+LcECnCzpphQ1Q@mail.gmail.com>
References: <421b2493-0fe5-c286-bf96-e6888264806a@bisdn.de>
	<CADkTA4POtjuyzbwNLs3ZwwJwCbrY_4V7Ccp2+LcECnCzpphQ1Q@mail.gmail.com>
Message-ID: <18197114-5f5c-8ec5-691e-7f4e29bf2193@bisdn.de>

Hi,

thank you for the reply. In the attahcment the layer for the kernel and 
the layer with the machine configurations.

Pierluigi

On 06/06/19 15:47, Bruce Ashfield wrote:
> On Thu, Jun 6, 2019 at 9:38 AM Pierluigi Greto <pierluigi.greto at bisdn.de> wrote:
>> Hi,
>>
>> I have to create a custom 4.14.49 linux kernel. In my recipe I have added my defconfig, but yocto it's not taking in consideration the defconfig. Instead it's building the kernel using the default values. Also the compilation task is to fast for building the kernel. My target system is an arm architecture (DEFAULTTUNE ?= "cortexa9").
>> I have tried also to append this on my recipe but the result does not change:
> Can you share your kernel recipe and layer(s) + defconfig ? Things are
> working fine for me, but if I can see (and build) your recipes perhaps
> something can be spotted.
>
> Bruce
>
>> do_compile_prepend() {
>>       cp ${WORKDIR}/defconfig ${B}/defconfig
>>       cp ${WORKDIR}/defconfig ${B}/.config
>>       oe_runmake -C ${B} ARCH=${ARCH} ${S}/defconfig
>> }
>>
>> If i try to "cheat" and add cp ${WORKDIR}/defconfig ${S}/.config on the do_compile_prepend obviously make will not work: "kernel-source is not clean, please run 'make mrprop' ".
>>
>> Any suggestions is very welcome.
>>
>> Thank you,
>> Pierluigi
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meta-open-network-linux.zip
Type: application/zip
Size: 247645 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/58a2d910/attachment-0002.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: meta-accton-as4610-54.zip
Type: application/zip
Size: 1890 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/58a2d910/attachment-0003.zip>

From Isak.Lichtenstein at kistler.com  Thu Jun  6 07:16:59 2019
From: Isak.Lichtenstein at kistler.com (Isak Lichtenstein)
Date: Thu, 6 Jun 2019 14:16:59 +0000
Subject: [yocto] Necessary changes between SDK and eSDK builds
Message-ID: <cffd0aba14964a308553d1eaca51fde5@kistler.com>

Hi

I'm using yocto thud 2.6.1 always build & provide sdk's to our customers without problem.
Now a customer requested an eSDK instead.

According to the manual (https://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer), this should work identically by simply using "-c populate_sdk_ext".

Unfortunately the tasks do_populate_sdk_ext fails with the following error message:

....
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf.bak' -> '/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf'

ERROR: core-image-myboard-1.0-r0 do_populate_sdk_ext: Function failed: copy_buildsystem
ERROR: Logfile of failure stored in: /home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/temp/log.do_populate_sdk_ext.17712
ERROR: Task (/home/root/yocto/meta-evalboard/recipes-core/images/core-image-myboard.bb:do_populate_sdk_ext) failed with exit code '1'

What do I need to change in order to build the extensible SDK?

Best regards
Isak

From joaohf at gmail.com  Sun Jun  2 22:40:40 2019
From: joaohf at gmail.com (=?UTF-8?Q?Jo=C3=A3o_Henrique_Freitas?=)
Date: Mon, 3 Jun 2019 07:40:40 +0200
Subject: [yocto] EMQ recipe
Message-ID: <CANFVK78ymEGrUgqtr0sH+6F6vOzmwbuq75AqdYVqYhTDN9ro0g@mail.gmail.com>

Hi,

I'm the author of a Yocto Project layer called meta-erlang. I would like to
announce that now is possible to use Yocto Project which build a embedded
Linux distro and on top of that install the EMQ (a mqtt broker) or EMQ
edge. I've created the recipe and all the patches necessary to do that.

My main target is to bring software made with Erlang/Elixir possible to run
in Yocto/Openembedded ecosystem.

Just in case, if you have a embedded project and are planing to run emq
edge, for example. This could be feasible for you.

Check it:

 - https://layers.openembedded.org/layerindex/branch/master/recipes/?q=emq
 - http://joaohf.github.io/meta-erlang/#/guides-emqx
 - https://github.com/joaohf/meta-erlang
 - https://www.yoctoproject.org/
 - https://www.emqx.io/

Best regards,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190603/3dfabc98/attachment.html>

From rpurdie at rpsys.net  Tue Jun  4 09:02:32 2019
From: rpurdie at rpsys.net (Richard Purdie)
Date: Tue, 04 Jun 2019 17:02:32 +0100
Subject: [yocto] [patchtest-oe][PATCH] test_metadata_src_uri: new
 unittest detecting added patch files without modifying SRC_URI
In-Reply-To: <dd502bbb-d5a4-35fb-fb64-3af8af8a3ede@windriver.com>
References: <1551779999-231946-1-git-send-email-changqing.li@windriver.com>
	<3427a8c2-543e-f71c-9c10-fca3b5c0667e@windriver.com>
	<a42d5db8-1cae-008e-dd8f-d533662007d6@windriver.com>
	<46d05a5b-c884-0f87-5cee-02d005f04225@mvista.com>
	<dd502bbb-d5a4-35fb-fb64-3af8af8a3ede@windriver.com>
Message-ID: <0f6e55fc6305b3f5cb477af4f4aff4c2e67e2b00.camel@rpsys.net>

On Wed, 2019-05-29 at 10:28 +0800, Changqing Li wrote:
> On 5/28/19 10:53 PM, akuster wrote:
> > On 5/27/19 6:00 PM, Changqing Li wrote:
> > > ping
> > > 
> > > On 4/29/19 2:10 PM, Changqing Li wrote:
> > > > ping
> > > > 
> > Does this mean you have a working knowledge of patchtest?
> > 
> > The one used by the project appears to be off line.  Can you help?
> > 
> > kind regards,
> > Armin
> 
> I have do some work on this,  and can try to help,  but I don't have
> 
> access right of the server,  and I also don't have the admin account
> of the patchwork.  if  someone can  provide these info,  I am glad to
> help.

Help would be much appreciated, lets take this offlist and work with
Michael and Paul and see if we can figure out how to move forward.

Cheers,

Richard


From gokulraj.kana at gmail.com  Thu Jun  6 09:26:25 2019
From: gokulraj.kana at gmail.com (Gokul Raj)
Date: Thu, 6 Jun 2019 21:56:25 +0530
Subject: [yocto] Error in building new recipe for Jool network translator
Message-ID: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>

Hi All,

I'm new to yocto and I'm trying to create recipe for Jool network
translator package. Tried to compile this package in manually and I'm able
to compile with following steps.
*Manual Steps:*

./autogen.sh
./configure
make
make install

*Yocto Receipe: *

DESCRIPTION = "Jool is an Open Source IPv4/IPv6 Translator"
SECTION = "networking"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"

SRCREV = "v4.0.1"
SRC_URI = "git://github.com/NICMx/Jool.git;protocol=http"

DEPENDS = "libnl iptables"

S = "${WORKDIR}/git"

inherit autotools module

Getting following error message */bin/bash: line 20: cd: src/mod: No such
file or directory       *But, the src/mod is present in the source
directory. Help me resolve this issue.

*Yocto Build Error:*

ERROR: jool-4.0.1-r0 do_compile: oe_runmake failed
ERROR: jool-4.0.1-r0 do_compile: Function failed: do_compile (log file is
located at
/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
ERROR: Logfile of failure stored in:
/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423
Log data follows:
| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
| DEBUG: Executing shell function do_compile
| NOTE: make -j 6
KERNEL_SRC=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
KERNEL_PATH=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
KERNEL_VERSION=5.0.7-yocto-standard CC=arm-enigma-linux-gnueabi-gcc
 -mno-thumb-interwork -marm -fuse-ld=bfd
-fmacro-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0

 -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0

 -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot=

 -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot-native=
 -fdebug-prefix-map=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source=/usr/src/kernel
LD=arm-enigma-linux-gnueabi-ld.bfd   AR=arm-enigma-linux-gnueabi-ar
 O=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-build-artifacts
KBUILD_EXTRA_SYMBOLS=
| Making all in src/mod
| /bin/bash: line 20: cd: src/mod: No such file or directory
| Makefile:343: recipe for target 'all-recursive' failed
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
ERROR: Task (/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 570 tasks of which 563 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
  /home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

Source git link: *https://github.com/NICMx/Jool
<https://github.com/NICMx/Jool>*

Help me in fixing this issue.

Regards,
Gokul Raj K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/93b1f709/attachment-0001.html>

From ross.burton at intel.com  Thu Jun  6 09:30:59 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Thu, 6 Jun 2019 17:30:59 +0100
Subject: [yocto] Error in building new recipe for Jool network translator
In-Reply-To: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>
References: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>
Message-ID: <CAJTo0LYb7YDwOPS36q0Jo5RJXRwCx4p5e+xQ2J7KofODOVARJg@mail.gmail.com>

Sounds like the makefiles are broken and can't handle out-of-tree
builds.  Try replacing inherit autotools with inherit
autotools-brokensep (and if that fixes it, file a bug with jool as
their build is broken).


Ross

On Thu, 6 Jun 2019 at 17:27, Gokul Raj <gokulraj.kana at gmail.com> wrote:
>
> Hi All,
>
> I'm new to yocto and I'm trying to create recipe for Jool network translator package. Tried to compile this package in manually and I'm able to compile with following steps.
> Manual Steps:
>
> ./autogen.sh
> ./configure
> make
> make install
>
> Yocto Receipe:
>
> DESCRIPTION = "Jool is an Open Source IPv4/IPv6 Translator"
> SECTION = "networking"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>
> SRCREV = "v4.0.1"
> SRC_URI = "git://github.com/NICMx/Jool.git;protocol=http"
>
> DEPENDS = "libnl iptables"
>
> S = "${WORKDIR}/git"
>
> inherit autotools module
>
> Getting following error message /bin/bash: line 20: cd: src/mod: No such file or directory       But, the src/mod is present in the source directory. Help me resolve this issue.
>
> Yocto Build Error:
>
> ERROR: jool-4.0.1-r0 do_compile: oe_runmake failed
> ERROR: jool-4.0.1-r0 do_compile: Function failed: do_compile (log file is located at /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> ERROR: Logfile of failure stored in: /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423
> Log data follows:
> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32', 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 6 KERNEL_SRC=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source KERNEL_PATH=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source KERNEL_VERSION=5.0.7-yocto-standard CC=arm-enigma-linux-gnueabi-gcc  -mno-thumb-interwork -marm -fuse-ld=bfd -fmacro-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0                      -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0                      -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot=                      -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot-native=  -fdebug-prefix-map=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source=/usr/src/kernel LD=arm-enigma-linux-gnueabi-ld.bfd   AR=arm-enigma-linux-gnueabi-ar  O=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-build-artifacts KBUILD_EXTRA_SYMBOLS=
> | Making all in src/mod
> | /bin/bash: line 20: cd: src/mod: No such file or directory
> | Makefile:343: recipe for target 'all-recursive' failed
> | make: *** [all-recursive] Error 1
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> ERROR: Task (/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 570 tasks of which 563 didn't need to be rerun and 1 failed.
>
> Summary: 1 task failed:
>   /home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
> Source git link: https://github.com/NICMx/Jool
>
> Help me in fixing this issue.
>
> Regards,
> Gokul Raj K
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From gokulraj.kana at gmail.com  Thu Jun  6 09:46:33 2019
From: gokulraj.kana at gmail.com (Gokul Raj)
Date: Thu, 6 Jun 2019 22:16:33 +0530
Subject: [yocto] Error in building new recipe for Jool network translator
In-Reply-To: <CAJTo0LYb7YDwOPS36q0Jo5RJXRwCx4p5e+xQ2J7KofODOVARJg@mail.gmail.com>
References: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>
	<CAJTo0LYb7YDwOPS36q0Jo5RJXRwCx4p5e+xQ2J7KofODOVARJg@mail.gmail.com>
Message-ID: <CAFP4eQ_1fk7ZvafF7vxpmvx3x4ntnwpdBBMYUJGJCfG4mPtrEA@mail.gmail.com>

Hi Ross,

Thanks for the suggestion. I have tried with inheriting autotools-brokensep
bbclass. Now bitbake got the path for compilation. But, bitbake compilation
refering to native kernel src path for module compilation. For your
information this package comes with both kernel module and userspace
binary. Single makefile helps building both kernel module and userspace
binary. Attached log for your reference.

Any suggestion to compile this package.

Regards,
Gokul Raj K

On Thu, Jun 6, 2019 at 10:01 PM Burton, Ross <ross.burton at intel.com> wrote:

> Sounds like the makefiles are broken and can't handle out-of-tree
> builds.  Try replacing inherit autotools with inherit
> autotools-brokensep (and if that fixes it, file a bug with jool as
> their build is broken).
>
>
> Ross
>
> On Thu, 6 Jun 2019 at 17:27, Gokul Raj <gokulraj.kana at gmail.com> wrote:
> >
> > Hi All,
> >
> > I'm new to yocto and I'm trying to create recipe for Jool network
> translator package. Tried to compile this package in manually and I'm able
> to compile with following steps.
> > Manual Steps:
> >
> > ./autogen.sh
> > ./configure
> > make
> > make install
> >
> > Yocto Receipe:
> >
> > DESCRIPTION = "Jool is an Open Source IPv4/IPv6 Translator"
> > SECTION = "networking"
> > LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >
> > SRCREV = "v4.0.1"
> > SRC_URI = "git://github.com/NICMx/Jool.git;protocol=http"
> >
> > DEPENDS = "libnl iptables"
> >
> > S = "${WORKDIR}/git"
> >
> > inherit autotools module
> >
> > Getting following error message /bin/bash: line 20: cd: src/mod: No such
> file or directory       But, the src/mod is present in the source
> directory. Help me resolve this issue.
> >
> > Yocto Build Error:
> >
> > ERROR: jool-4.0.1-r0 do_compile: oe_runmake failed
> > ERROR: jool-4.0.1-r0 do_compile: Function failed: do_compile (log file
> is located at
> /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> > ERROR: Logfile of failure stored in:
> /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423
> > Log data follows:
> > | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
> > | DEBUG: Executing shell function do_compile
> > | NOTE: make -j 6
> KERNEL_SRC=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
> KERNEL_PATH=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
> KERNEL_VERSION=5.0.7-yocto-standard CC=arm-enigma-linux-gnueabi-gcc
> -mno-thumb-interwork -marm -fuse-ld=bfd
> -fmacro-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot=
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot-native=
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source=/usr/src/kernel
> LD=arm-enigma-linux-gnueabi-ld.bfd   AR=arm-enigma-linux-gnueabi-ar
> O=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-build-artifacts
> KBUILD_EXTRA_SYMBOLS=
> > | Making all in src/mod
> > | /bin/bash: line 20: cd: src/mod: No such file or directory
> > | Makefile:343: recipe for target 'all-recursive' failed
> > | make: *** [all-recursive] Error 1
> > | ERROR: oe_runmake failed
> > | WARNING: exit code 1 from a shell command.
> > | ERROR: Function failed: do_compile (log file is located at
> /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> > ERROR: Task
> (/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile)
> failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 570 tasks of which 563 didn't need to be
> rerun and 1 failed.
> >
> > Summary: 1 task failed:
> >   /home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:
> do_compile
> > Summary: There were 2 ERROR messages shown, returning a non-zero exit
> code.
> >
> > Source git link: https://github.com/NICMx/Jool
> >
> > Help me in fixing this issue.
> >
> > Regards,
> > Gokul Raj K
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/62ee2439/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.do_compile.65759
Type: application/octet-stream
Size: 57438 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190606/62ee2439/attachment-0001.obj>

From mark.hatle at windriver.com  Thu Jun  6 14:24:37 2019
From: mark.hatle at windriver.com (Mark Hatle)
Date: Thu, 6 Jun 2019 16:24:37 -0500
Subject: [yocto] Error in building new recipe for Jool network translator
In-Reply-To: <CAFP4eQ_1fk7ZvafF7vxpmvx3x4ntnwpdBBMYUJGJCfG4mPtrEA@mail.gmail.com>
References: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>
	<CAJTo0LYb7YDwOPS36q0Jo5RJXRwCx4p5e+xQ2J7KofODOVARJg@mail.gmail.com>
	<CAFP4eQ_1fk7ZvafF7vxpmvx3x4ntnwpdBBMYUJGJCfG4mPtrEA@mail.gmail.com>
Message-ID: <2f565e97-c162-4dba-3f7e-5f78e0039d43@windriver.com>

On 6/6/19 11:46 AM, Gokul Raj wrote:
> Hi Ross,
> 
> Thanks for the suggestion. I have tried with inheriting autotools-brokensep
> bbclass. Now bitbake got the path for compilation. But, bitbake compilation
> refering to native kernel src path for module compilation. For your information
> this package comes with both kernel module and userspace binary. Single makefile
> helps building both kernel module and userspace binary. Attached log for your
> reference.
> 
> Any suggestion to compile this package.

You will need to break this into two components.  The userspace compile is
likely what you have mostly working.  The kernel module compilation though needs
to be a 'machine specific' recipe, tied to the machine and kernel.

Look at the Yocto Project documentation about building out of tree kernel modules.

--Mark

> Regards,
> Gokul Raj K
> 
> On Thu, Jun 6, 2019 at 10:01 PM Burton, Ross <ross.burton at intel.com
> <mailto:ross.burton at intel.com>> wrote:
> 
>     Sounds like the makefiles are broken and can't handle out-of-tree
>     builds.? Try replacing inherit autotools with inherit
>     autotools-brokensep (and if that fixes it, file a bug with jool as
>     their build is broken).
> 
> 
>     Ross
> 
>     On Thu, 6 Jun 2019 at 17:27, Gokul Raj <gokulraj.kana at gmail.com
>     <mailto:gokulraj.kana at gmail.com>> wrote:
>     >
>     > Hi All,
>     >
>     > I'm new to yocto and I'm trying to create recipe for Jool network
>     translator package. Tried to compile this package in manually and I'm able
>     to compile with following steps.
>     > Manual Steps:
>     >
>     > ./autogen.sh
>     > ./configure
>     > make
>     > make install
>     >
>     > Yocto Receipe:
>     >
>     > DESCRIPTION = "Jool is an Open Source IPv4/IPv6 Translator"
>     > SECTION = "networking"
>     > LICENSE = "GPLv2"
>     > LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>     >
>     > SRCREV = "v4.0.1"
>     > SRC_URI = "git://github.com/NICMx/Jool.git;protocol=http
>     <http://github.com/NICMx/Jool.git;protocol=http>"
>     >
>     > DEPENDS = "libnl iptables"
>     >
>     > S = "${WORKDIR}/git"
>     >
>     > inherit autotools module
>     >
>     > Getting following error message /bin/bash: line 20: cd: src/mod: No such
>     file or directory? ? ? ?But, the src/mod is present in the source directory.
>     Help me resolve this issue.
>     >
>     > Yocto Build Error:
>     >
>     > ERROR: jool-4.0.1-r0 do_compile: oe_runmake failed
>     > ERROR: jool-4.0.1-r0 do_compile: Function failed: do_compile (log file is
>     located at
>     /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
>     > ERROR: Logfile of failure stored in:
>     /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423
>     > Log data follows:
>     > | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
>     'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
>     > | DEBUG: Executing shell function do_compile
>     > | NOTE: make -j 6
>     KERNEL_SRC=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
>     KERNEL_PATH=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
>     KERNEL_VERSION=5.0.7-yocto-standard CC=arm-enigma-linux-gnueabi-gcc?
>     -mno-thumb-interwork -marm -fuse-ld=bfd
>     -fmacro-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0?
>     ? ? ? ? ? ? ? ? ? ?
>     -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0?
>     ? ? ? ? ? ? ? ? ? ?
>     -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot=?
>     ? ? ? ? ? ? ? ? ? ?
>     -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot-native=?
>     -fdebug-prefix-map=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source=/usr/src/kernel
>     LD=arm-enigma-linux-gnueabi-ld.bfd? ?AR=arm-enigma-linux-gnueabi-ar?
>     O=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-build-artifacts
>     KBUILD_EXTRA_SYMBOLS=
>     > | Making all in src/mod
>     > | /bin/bash: line 20: cd: src/mod: No such file or directory
>     > | Makefile:343: recipe for target 'all-recursive' failed
>     > | make: *** [all-recursive] Error 1
>     > | ERROR: oe_runmake failed
>     > | WARNING: exit code 1 from a shell command.
>     > | ERROR: Function failed: do_compile (log file is located at
>     /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
>     > ERROR: Task
>     (/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile)
>     failed with exit code '1'
>     > NOTE: Tasks Summary: Attempted 570 tasks of which 563 didn't need to be
>     rerun and 1 failed.
>     >
>     > Summary: 1 task failed:
>     >? ?/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile
>     > Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>     >
>     > Source git link: https://github.com/NICMx/Jool
>     >
>     > Help me in fixing this issue.
>     >
>     > Regards,
>     > Gokul Raj K
>     >
>     > --
>     > _______________________________________________
>     > yocto mailing list
>     > yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>     > https://lists.yoctoproject.org/listinfo/yocto
> 
> 


From mhalstead at linuxfoundation.org  Thu Jun  6 16:46:56 2019
From: mhalstead at linuxfoundation.org (Michael Halstead)
Date: Thu,  6 Jun 2019 16:46:56 -0700
Subject: [yocto] [PATCH][yocto-docs] ref-manual: Corrected openSUSE
	essential packages
Message-ID: <20190606234656.28343-1-mhalstead@linuxfoundation.org>

Some packages were bumped onto the pip3 install line. Install them with zypper as before.

Signed-off-by: Michael Halstead <mhalstead at linuxfoundation.org>
---
 documentation/poky.ent | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/documentation/poky.ent b/documentation/poky.ent
index b5f600969..a436d9027 100644
--- a/documentation/poky.ent
+++ b/documentation/poky.ent
@@ -68,8 +68,8 @@
      python3-jinja2 SDL-devel xterm">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
-     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
-     $ sudo pip3 install GitPython libSDL-devel xterm">
+     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm
+     $ sudo pip3 install GitPython">
 <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
      $ sudo yum makecache
      $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
-- 
2.17.2


From akuster808 at gmail.com  Thu Jun  6 17:07:35 2019
From: akuster808 at gmail.com (akuster808)
Date: Thu, 6 Jun 2019 17:07:35 -0700
Subject: [yocto] [PATCH][yocto-docs] ref-manual: Corrected openSUSE
 essential packages
In-Reply-To: <20190606234656.28343-1-mhalstead@linuxfoundation.org>
References: <20190606234656.28343-1-mhalstead@linuxfoundation.org>
Message-ID: <1a8c9eb7-3866-4b98-ca7c-95fc00bf4989@gmail.com>



On 6/6/19 4:46 PM, Michael Halstead wrote:
> Some packages were bumped onto the pip3 install line. Install them with zypper as before.
with backport? ie is Warrior or Thud affected, I suspect so

- armin
>
> Signed-off-by: Michael Halstead <mhalstead at linuxfoundation.org>
> ---
>  documentation/poky.ent | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/documentation/poky.ent b/documentation/poky.ent
> index b5f600969..a436d9027 100644
> --- a/documentation/poky.ent
> +++ b/documentation/poky.ent
> @@ -68,8 +68,8 @@
>       python3-jinja2 SDL-devel xterm">
>  <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
>       diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
> -     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> -     $ sudo pip3 install GitPython libSDL-devel xterm">
> +     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm
> +     $ sudo pip3 install GitPython">
>  <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
>       $ sudo yum makecache
>       $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \


From jupiter.hce at gmail.com  Thu Jun  6 17:12:14 2019
From: jupiter.hce at gmail.com (JH)
Date: Fri, 7 Jun 2019 10:12:14 +1000
Subject: [yocto] Support NAND flash
In-Reply-To: <20190606115951.uc36gymkoqiod325@jholzmayr.localdomain>
References: <CAA=hcWSh9-DaYwFED5UpT_h1C0H22HG76LVd3d+aL4V+LBQQBA@mail.gmail.com>
	<CAA=hcWSmDyqJ2_4zw7-gXZ8KeB-wUk9G7iNieCsMQDGL3V2+Dg@mail.gmail.com>
	<20190606115951.uc36gymkoqiod325@jholzmayr.localdomain>
Message-ID: <CAA=hcWTmW1DZBeCo3mG8EnFSPrL=13+shB9h0HC27FritNMp5w@mail.gmail.com>

Thanks Josef for the response and links, the board is not off the
shelf product, it was designed by a hardware contractor, so I have do
as you advised to change kernel+config and to add mtd-utils recipe.

In my previous project working on a TI ARM processor with NOR Flash,
installed with Debian armhf, I did not recall any work to interface
MTD NOR Flash, it was booted like a normal Linux distribute. For NAND,
is the Linux be able to handle read / write NAND flash as in NOR?

Thank you very much.

Kind regards,

- JH

On 6/6/19, Josef Holzmayr <holzmayr at rsi-elektrotechnik.de> wrote:
> On Thu, Jun 06, 2019 at 09:15:46PM +1000, JH wrote:
>> More specific, looks to me that the drivers are OS based, the eCos has
>> NAND I/O, the OpenWRT has some support NAND I/O as well, how does the
>> Yocto support?
>
> This is not exactly a "how does the yocto" support-thing. Yocto is not
> the OS. The OS by itself is the Linux kernel, which has extensive NAND
> support in a lot of varieties. If you want to have a look, see
> https://elixir.bootlin.com/linux/latest/source/drivers/mtd and
> especially the nand subdirectory. In a nutshell it goes like this: if
> you buy a board, ask whomever gave it to you for a kernel plus config
> that works. Also, they are in most cases also obliged to tell you how to
> write something to the (NAND-)flash.
>
> For the userspace side, there is the mtd-utils suite:
> http://www.linux-mtd.infradead.org which is already nicely packaged for
> OE:
> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/mtd/mtd-utils_git.bb
>
> So these are your starting points, you have to apply them to your
> specific setup yourself. The only common things I can think of is:
> 1) make sure your kernel+config support the flash chip in use
> 2) install the mtd-utils for interacting with it.
>
> Greetz.
>
>>
>> Thank you.
>>
>> Kind regards,
>>
>> - JH
>>
>> On 6/6/19, JH <jupiter.hce at gmail.com> wrote:
>> > Hi,
>> >
>> > Has anyone used NAND? Does the MTD already support the NAND driver or
>> > do you have to work our the detailed driver yourself? Could you share
>> > your experiences how to build the image and to hand and access the
>> > NAND if it is required?
>> >
>> > Thank you.
>> >
>> > Kind regards,
>> >
>> > - JH
>> >
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> ???????????????
> Josef Holzmayr
> Software Developer Embedded Systems
>
> Tel: +49 8444 9204-48
> Fax: +49 8444 9204-50
>
> R-S-I Elektrotechnik GmbH & Co. KG
> Woelkestrasse 11
> D-85301 Schweitenkirchen
> www.rsi-elektrotechnik.de
> ???????????????
> Amtsgericht Ingolstadt ? GmbH: HRB 191328 ? KG: HRA 170393
> Gesch?ftsf?hrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
> Ust-IdNr: DE 128592548
>
> _____________________________________________________________
> Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
> Gesch?ftsf?hrer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
> USt-IdNr.: DE 128592548
>
>

From bruce.ashfield at gmail.com  Thu Jun  6 20:10:40 2019
From: bruce.ashfield at gmail.com (Bruce Ashfield)
Date: Thu, 6 Jun 2019 23:10:40 -0400
Subject: [yocto] arm yocto-linux custom defconfig not working
In-Reply-To: <18197114-5f5c-8ec5-691e-7f4e29bf2193@bisdn.de>
References: <421b2493-0fe5-c286-bf96-e6888264806a@bisdn.de>
	<CADkTA4POtjuyzbwNLs3ZwwJwCbrY_4V7Ccp2+LcECnCzpphQ1Q@mail.gmail.com>
	<18197114-5f5c-8ec5-691e-7f4e29bf2193@bisdn.de>
Message-ID: <CADkTA4Mk7YRJAEcOfq5FJuoMNNBfA-A8CaSiZvB-uZo65VGjvA@mail.gmail.com>

On Thu, Jun 6, 2019 at 10:06 AM Pierluigi Greto
<pierluigi.greto at bisdn.de> wrote:
>
> Hi,
>
> thank you for the reply. In the attahcment the layer for the kernel and
> the layer with the machine configurations.

Thanks for the layers. I was able to pull together a thud build env
and do some tests.

For me, I see the defconfig being used as expected. The key words
there may be "as expected".

How were you determining that the defconfig wasn't being used ?

There are always some minor differences between most defconfigs and
what ends up  the .config due to minor kernel version differences, or
the fact that by default, when a defconfig is fed through the
linux-yocto config process it assumes that the defconfig is fairly
complete and is intended to be a full specification .. as such, it
runs merge config with allnoconfig first, and then applies the
defconfig on top. So if something was perhaps being selected by an
option, or a default configuration was being assumed .. you will see
some minor deltas.

Bruce

>
> Pierluigi
>
> On 06/06/19 15:47, Bruce Ashfield wrote:
> > On Thu, Jun 6, 2019 at 9:38 AM Pierluigi Greto <pierluigi.greto at bisdn.de> wrote:
> >> Hi,
> >>
> >> I have to create a custom 4.14.49 linux kernel. In my recipe I have added my defconfig, but yocto it's not taking in consideration the defconfig. Instead it's building the kernel using the default values. Also the compilation task is to fast for building the kernel. My target system is an arm architecture (DEFAULTTUNE ?= "cortexa9").
> >> I have tried also to append this on my recipe but the result does not change:
> > Can you share your kernel recipe and layer(s) + defconfig ? Things are
> > working fine for me, but if I can see (and build) your recipes perhaps
> > something can be spotted.
> >
> > Bruce
> >
> >> do_compile_prepend() {
> >>       cp ${WORKDIR}/defconfig ${B}/defconfig
> >>       cp ${WORKDIR}/defconfig ${B}/.config
> >>       oe_runmake -C ${B} ARCH=${ARCH} ${S}/defconfig
> >> }
> >>
> >> If i try to "cheat" and add cp ${WORKDIR}/defconfig ${S}/.config on the do_compile_prepend obviously make will not work: "kernel-source is not clean, please run 'make mrprop' ".
> >>
> >> Any suggestions is very welcome.
> >>
> >> Thank you,
> >> Pierluigi
> >>
> >> --
> >> _______________________________________________
> >> yocto mailing list
> >> yocto at yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >
> >



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

From gokulraj.kana at gmail.com  Thu Jun  6 20:16:07 2019
From: gokulraj.kana at gmail.com (Gokul Raj)
Date: Fri, 7 Jun 2019 08:46:07 +0530
Subject: [yocto] Error in building new recipe for Jool network translator
In-Reply-To: <2f565e97-c162-4dba-3f7e-5f78e0039d43@windriver.com>
References: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>
	<CAJTo0LYb7YDwOPS36q0Jo5RJXRwCx4p5e+xQ2J7KofODOVARJg@mail.gmail.com>
	<CAFP4eQ_1fk7ZvafF7vxpmvx3x4ntnwpdBBMYUJGJCfG4mPtrEA@mail.gmail.com>
	<2f565e97-c162-4dba-3f7e-5f78e0039d43@windriver.com>
Message-ID: <CAFP4eQ_tKC0-Jt607gRmBUjTK--zU=NEgxzKF4vbLCTkJLcAjQ@mail.gmail.com>

Thanks Mark, I'll check them out.

Regards,
Gokul Raj K


On Fri, 7 Jun, 2019, 2:54 AM Mark Hatle, <mark.hatle at windriver.com> wrote:

> On 6/6/19 11:46 AM, Gokul Raj wrote:
> > Hi Ross,
> >
> > Thanks for the suggestion. I have tried with inheriting
> autotools-brokensep
> > bbclass. Now bitbake got the path for compilation. But, bitbake
> compilation
> > refering to native kernel src path for module compilation. For your
> information
> > this package comes with both kernel module and userspace binary. Single
> makefile
> > helps building both kernel module and userspace binary. Attached log for
> your
> > reference.
> >
> > Any suggestion to compile this package.
>
> You will need to break this into two components.  The userspace compile is
> likely what you have mostly working.  The kernel module compilation though
> needs
> to be a 'machine specific' recipe, tied to the machine and kernel.
>
> Look at the Yocto Project documentation about building out of tree kernel
> modules.
>
> --Mark
>
> > Regards,
> > Gokul Raj K
> >
> > On Thu, Jun 6, 2019 at 10:01 PM Burton, Ross <ross.burton at intel.com
> > <mailto:ross.burton at intel.com>> wrote:
> >
> >     Sounds like the makefiles are broken and can't handle out-of-tree
> >     builds.  Try replacing inherit autotools with inherit
> >     autotools-brokensep (and if that fixes it, file a bug with jool as
> >     their build is broken).
> >
> >
> >     Ross
> >
> >     On Thu, 6 Jun 2019 at 17:27, Gokul Raj <gokulraj.kana at gmail.com
> >     <mailto:gokulraj.kana at gmail.com>> wrote:
> >     >
> >     > Hi All,
> >     >
> >     > I'm new to yocto and I'm trying to create recipe for Jool network
> >     translator package. Tried to compile this package in manually and
> I'm able
> >     to compile with following steps.
> >     > Manual Steps:
> >     >
> >     > ./autogen.sh
> >     > ./configure
> >     > make
> >     > make install
> >     >
> >     > Yocto Receipe:
> >     >
> >     > DESCRIPTION = "Jool is an Open Source IPv4/IPv6 Translator"
> >     > SECTION = "networking"
> >     > LICENSE = "GPLv2"
> >     > LIC_FILES_CHKSUM =
> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
> >     >
> >     > SRCREV = "v4.0.1"
> >     > SRC_URI = "git://github.com/NICMx/Jool.git;protocol=http
> >     <http://github.com/NICMx/Jool.git;protocol=http>"
> >     >
> >     > DEPENDS = "libnl iptables"
> >     >
> >     > S = "${WORKDIR}/git"
> >     >
> >     > inherit autotools module
> >     >
> >     > Getting following error message /bin/bash: line 20: cd: src/mod:
> No such
> >     file or directory       But, the src/mod is present in the source
> directory.
> >     Help me resolve this issue.
> >     >
> >     > Yocto Build Error:
> >     >
> >     > ERROR: jool-4.0.1-r0 do_compile: oe_runmake failed
> >     > ERROR: jool-4.0.1-r0 do_compile: Function failed: do_compile (log
> file is
> >     located at
> >
>  /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> >     > ERROR: Logfile of failure stored in:
> >
>  /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423
> >     > Log data follows:
> >     > | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
> 'arm-32',
> >     'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi',
> 'common']
> >     > | DEBUG: Executing shell function do_compile
> >     > | NOTE: make -j 6
> >
>  KERNEL_SRC=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
> >
>  KERNEL_PATH=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
> >     KERNEL_VERSION=5.0.7-yocto-standard CC=arm-enigma-linux-gnueabi-gcc
> >     -mno-thumb-interwork -marm -fuse-ld=bfd
> >
>  -fmacro-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0
> >
> >
>  -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0
> >
> >
>  -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot=
> >
> >
>  -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot-native=
> >
>  -fdebug-prefix-map=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source=/usr/src/kernel
> >     LD=arm-enigma-linux-gnueabi-ld.bfd   AR=arm-enigma-linux-gnueabi-ar
> >
>  O=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-build-artifacts
> >     KBUILD_EXTRA_SYMBOLS=
> >     > | Making all in src/mod
> >     > | /bin/bash: line 20: cd: src/mod: No such file or directory
> >     > | Makefile:343: recipe for target 'all-recursive' failed
> >     > | make: *** [all-recursive] Error 1
> >     > | ERROR: oe_runmake failed
> >     > | WARNING: exit code 1 from a shell command.
> >     > | ERROR: Function failed: do_compile (log file is located at
> >
>  /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> >     > ERROR: Task
> >     (/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:
> do_compile)
> >     failed with exit code '1'
> >     > NOTE: Tasks Summary: Attempted 570 tasks of which 563 didn't need
> to be
> >     rerun and 1 failed.
> >     >
> >     > Summary: 1 task failed:
> >     >   /home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:
> do_compile
> >     > Summary: There were 2 ERROR messages shown, returning a non-zero
> exit code.
> >     >
> >     > Source git link: https://github.com/NICMx/Jool
> >     >
> >     > Help me in fixing this issue.
> >     >
> >     > Regards,
> >     > Gokul Raj K
> >     >
> >     > --
> >     > _______________________________________________
> >     > yocto mailing list
> >     > yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
> >     > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190607/2fd4744d/attachment.html>

From anuj.mittal at intel.com  Thu Jun  6 21:20:40 2019
From: anuj.mittal at intel.com (Mittal, Anuj)
Date: Fri, 7 Jun 2019 04:20:40 +0000
Subject: [yocto] Error in building new recipe for Jool network translator
In-Reply-To: <CAFP4eQ_1fk7ZvafF7vxpmvx3x4ntnwpdBBMYUJGJCfG4mPtrEA@mail.gmail.com>
References: <CAFP4eQ-pUhBiqESOk-5uNGcbRkHW+=+wOpi=dTZDQ55ygGgBJQ@mail.gmail.com>
	<CAJTo0LYb7YDwOPS36q0Jo5RJXRwCx4p5e+xQ2J7KofODOVARJg@mail.gmail.com>
	<CAFP4eQ_1fk7ZvafF7vxpmvx3x4ntnwpdBBMYUJGJCfG4mPtrEA@mail.gmail.com>
Message-ID: <bdb3d41992ea076fe671a15def259bd3cd9e24f7.camel@intel.com>

On Thu, 2019-06-06 at 22:16 +0530, Gokul Raj wrote:
> Hi Ross,
> 
> Thanks for the suggestion. I have tried with inheriting autotools-
> brokensep bbclass. Now bitbake got the path for compilation. But,
> bitbake compilation refering to native kernel src path for module
> compilation. For your information this package comes with both kernel
> module and userspace binary. Single makefile helps building both
> kernel module and userspace binary. Attached log for your reference.
> 
> Any suggestion to compile this package.

Looking at the Makefile, I think adding this might help:

EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_BUILDDIR}"'

From peter.t.smith at ge.com  Fri Jun  7 00:51:39 2019
From: peter.t.smith at ge.com (Smith, Peter1 (GE Renewable Energy))
Date: Fri, 7 Jun 2019 07:51:39 +0000
Subject: [yocto] [meta-security] AppArmor 2.11 no longer available on Ubuntu
 archive (sumo branch)
Message-ID: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>

We are building with meta-security (from sumo branch) which currently uses v2.11 of AppArmor, it seems overnight that the source archive has been removed from the Ubuntu archives. Does anyone know if this is a deliberate action, or if not who to contact to get it put back.

Peter Smith

Senior Emerging Technologies Engineer
Grid Solutions
GE Renewable Energy

-NON PUBLIC-



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190607/f37052a6/attachment.html>

From ross.burton at intel.com  Fri Jun  7 03:09:49 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Fri, 7 Jun 2019 11:09:49 +0100
Subject: [yocto] [meta-security] AppArmor 2.11 no longer available on
 Ubuntu archive (sumo branch)
In-Reply-To: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
References: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
Message-ID: <CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>

That is deliberate and by design, recipes shouldn't fetch from
Debian/Ubuntu archives for this reason.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
is a patch to master that needs to be backported to warrior/thud/sumo.

Ross

On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy)
<peter.t.smith at ge.com> wrote:
>
> We are building with meta-security (from sumo branch) which currently uses v2.11 of AppArmor, it seems overnight that the source archive has been removed from the Ubuntu archives. Does anyone know if this is a deliberate action, or if not who to contact to get it put back.
>
>
>
> Peter Smith
>
>
>
> Senior Emerging Technologies Engineer
>
> Grid Solutions
>
> GE Renewable Energy
>
>
>
> -NON PUBLIC-
>
>
>
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From peter.t.smith at ge.com  Fri Jun  7 03:21:29 2019
From: peter.t.smith at ge.com (Smith, Peter1 (GE Renewable Energy))
Date: Fri, 7 Jun 2019 10:21:29 +0000
Subject: [yocto] EXT: Re: [meta-security] AppArmor 2.11 no longer
 available on Ubuntu archive (sumo branch)
In-Reply-To: <CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
References: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
	<CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
Message-ID: <VI1P101MB0157F2FD088EDE4070F7892DDE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>

Many thanks, situation understood.

Peter Smith

Senior Emerging Technologies Engineer
Grid Solutions
GE Renewable Energy

-NON PUBLIC-



-----Original Message-----
From: Burton, Ross <ross.burton at intel.com> 
Sent: 07 June 2019 11:10
To: Smith, Peter1 (GE Renewable Energy) <peter.t.smith at ge.com>
Cc: yocto at yoctoproject.org
Subject: EXT: Re: [yocto] [meta-security] AppArmor 2.11 no longer available on Ubuntu archive (sumo branch)

That is deliberate and by design, recipes shouldn't fetch from Debian/Ubuntu archives for this reason.

http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
is a patch to master that needs to be backported to warrior/thud/sumo.

Ross

On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy) <peter.t.smith at ge.com> wrote:
>
> We are building with meta-security (from sumo branch) which currently uses v2.11 of AppArmor, it seems overnight that the source archive has been removed from the Ubuntu archives. Does anyone know if this is a deliberate action, or if not who to contact to get it put back.
>
>
>
> Peter Smith
>
>
>
> Senior Emerging Technologies Engineer
>
> Grid Solutions
>
> GE Renewable Energy
>
>
>
> -NON PUBLIC-
>
>
>
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From me at herrie.org  Fri Jun  7 03:27:36 2019
From: me at herrie.org (Herman van Hazendonk)
Date: Fri, 07 Jun 2019 12:27:36 +0200
Subject: [yocto] EXT: Re: [meta-security] AppArmor 2.11 no longer
 available on Ubuntu archive (sumo branch)
In-Reply-To: <VI1P101MB0157F2FD088EDE4070F7892DDE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
References: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
	<CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
	<VI1P101MB0157F2FD088EDE4070F7892DDE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
Message-ID: <b099465c475237bb362381f14c846f30@herrie.org>

Hi Peter,

You can find all tags at https://gitlab.com/apparmor/apparmor/tags and 
update the recipe in a similar way for your (sumo) build.

Hope this helps!

Herman

On 2019-06-07 12:21, Smith, Peter1 (GE Renewable Energy) wrote:
> Many thanks, situation understood.
> 
> Peter Smith
> 
> Senior Emerging Technologies Engineer
> Grid Solutions
> GE Renewable Energy
> 
> -NON PUBLIC-
> 
> 
> 
> -----Original Message-----
> From: Burton, Ross <ross.burton at intel.com>
> Sent: 07 June 2019 11:10
> To: Smith, Peter1 (GE Renewable Energy) <peter.t.smith at ge.com>
> Cc: yocto at yoctoproject.org
> Subject: EXT: Re: [yocto] [meta-security] AppArmor 2.11 no longer
> available on Ubuntu archive (sumo branch)
> 
> That is deliberate and by design, recipes shouldn't fetch from
> Debian/Ubuntu archives for this reason.
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
> is a patch to master that needs to be backported to warrior/thud/sumo.
> 
> Ross
> 
> On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy)
> <peter.t.smith at ge.com> wrote:
>> 
>> We are building with meta-security (from sumo branch) which currently 
>> uses v2.11 of AppArmor, it seems overnight that the source archive has 
>> been removed from the Ubuntu archives. Does anyone know if this is a 
>> deliberate action, or if not who to contact to get it put back.
>> 
>> 
>> 
>> Peter Smith
>> 
>> 
>> 
>> Senior Emerging Technologies Engineer
>> 
>> Grid Solutions
>> 
>> GE Renewable Energy
>> 
>> 
>> 
>> -NON PUBLIC-
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

From akuster808 at gmail.com  Fri Jun  7 09:02:07 2019
From: akuster808 at gmail.com (akuster808)
Date: Fri, 7 Jun 2019 09:02:07 -0700
Subject: [yocto] [meta-security] AppArmor 2.11 no longer available on
 Ubuntu archive (sumo branch)
In-Reply-To: <CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
References: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
	<CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
Message-ID: <09dc216d-63ab-2fba-2510-a538a079a181@gmail.com>



On 6/7/19 3:09 AM, Burton, Ross wrote:
> That is deliberate and by design, recipes shouldn't fetch from
> Debian/Ubuntu archives for this reason.
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
> is a patch to master that needs to be backported to warrior/thud/sumo.
should poke that maintainer ; )


>
> Ross
>
> On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy)
> <peter.t.smith at ge.com> wrote:
>> We are building with meta-security (from sumo branch) which currently uses v2.11 of AppArmor, it seems overnight that the source archive has been removed from the Ubuntu archives. Does anyone know if this is a deliberate action, or if not who to contact to get it put back.
>>
>>
>>
>> Peter Smith
>>
>>
>>
>> Senior Emerging Technologies Engineer
>>
>> Grid Solutions
>>
>> GE Renewable Energy
>>
>>
>>
>> -NON PUBLIC-
>>
>>
>>
>>
>>
>>
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto


From mhalstead at linuxfoundation.org  Fri Jun  7 16:19:01 2019
From: mhalstead at linuxfoundation.org (Michael Halstead)
Date: Fri, 7 Jun 2019 16:19:01 -0700
Subject: [yocto] [PATCH][yocto-docs] ref-manual: Corrected openSUSE
 essential packages
In-Reply-To: <1a8c9eb7-3866-4b98-ca7c-95fc00bf4989@gmail.com>
References: <20190606234656.28343-1-mhalstead@linuxfoundation.org>
	<1a8c9eb7-3866-4b98-ca7c-95fc00bf4989@gmail.com>
Message-ID: <CADfgfoaEqEV60KbQp2wEfJ5DrH64P=a1L8b30YKOvWrWJvbHpQ@mail.gmail.com>

On Thu, Jun 6, 2019 at 5:07 PM akuster808 <akuster808 at gmail.com> wrote:

>
>
> On 6/6/19 4:46 PM, Michael Halstead wrote:
> > Some packages were bumped onto the pip3 install line. Install them with
> zypper as before.
> with backport? ie is Warrior or Thud affected, I suspect so
>

Yes for Warrior. Thud is fine.

Is there anything I need to do for the Warrior backport?


>
> - armin
> >
> > Signed-off-by: Michael Halstead <mhalstead at linuxfoundation.org>
> > ---
> >  documentation/poky.ent | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/documentation/poky.ent b/documentation/poky.ent
> > index b5f600969..a436d9027 100644
> > --- a/documentation/poky.ent
> > +++ b/documentation/poky.ent
> > @@ -68,8 +68,8 @@
> >       python3-jinja2 SDL-devel xterm">
> >  <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git
> chrpath make wget python-xml \
> >       diffstat makeinfo python-curses patch socat python3 python3-curses
> tar python3-pip \
> > -     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> > -     $ sudo pip3 install GitPython libSDL-devel xterm">
> > +     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel
> xterm
> > +     $ sudo pip3 install GitPython">
> >  <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
> >       $ sudo yum makecache
> >       $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl
> patch \
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190607/0346c1dd/attachment.html>

From mauro at faresoftware.it  Sat Jun  8 06:06:00 2019
From: mauro at faresoftware.it (Mauro Ziliani)
Date: Sat, 8 Jun 2019 15:06:00 +0200
Subject: [yocto] qmake project and installed-vs-shipped QA
Message-ID: <9e07389d-c8e5-057b-2232-707adf39c971@faresoftware.it>

Hi all.

I built a project with qmake5

In my recipe I inherit qmake5

My application is well installed with "make install" (all file are 
installed correctly).


But bitbake tells me the this files are not shipped, but the application 
exectuable yes.

The executable is installed by "make install" as other files.

The solution is add in FILE_${PN} the? files not shipped.


But there is a way to ship files correctly installed without define 
FILES_${PN} inside the recipe?


Thanks all

MZ


From akuster808 at gmail.com  Sat Jun  8 15:46:33 2019
From: akuster808 at gmail.com (akuster808)
Date: Sat, 8 Jun 2019 15:46:33 -0700
Subject: [yocto] [PATCH][yocto-docs] ref-manual: Corrected openSUSE
 essential packages
In-Reply-To: <CADfgfoaEqEV60KbQp2wEfJ5DrH64P=a1L8b30YKOvWrWJvbHpQ@mail.gmail.com>
References: <20190606234656.28343-1-mhalstead@linuxfoundation.org>
	<1a8c9eb7-3866-4b98-ca7c-95fc00bf4989@gmail.com>
	<CADfgfoaEqEV60KbQp2wEfJ5DrH64P=a1L8b30YKOvWrWJvbHpQ@mail.gmail.com>
Message-ID: <dc977673-9e97-6bf9-a075-3512197f9ff1@gmail.com>



On 6/7/19 4:19 PM, Michael Halstead wrote:
>
>
> On Thu, Jun 6, 2019 at 5:07 PM akuster808 <akuster808 at gmail.com
> <mailto:akuster808 at gmail.com>> wrote:
>
>
>
>     On 6/6/19 4:46 PM, Michael Halstead wrote:
>     > Some packages were bumped onto the pip3 install line. Install
>     them with zypper as before.
>     with backport? ie is Warrior or Thud affected, I suspect so
>
>
> Yes for Warrior. Thud is fine.
>
> Is there anything I need to do for the Warrior backport?
nope. i will handle this.

thanks,
Armin
> ?
>
>
>     - armin
>     >
>     > Signed-off-by: Michael Halstead <mhalstead at linuxfoundation.org
>     <mailto:mhalstead at linuxfoundation.org>>
>     > ---
>     >? documentation/poky.ent | 4 ++--
>     >? 1 file changed, 2 insertions(+), 2 deletions(-)
>     >
>     > diff --git a/documentation/poky.ent b/documentation/poky.ent
>     > index b5f600969..a436d9027 100644
>     > --- a/documentation/poky.ent
>     > +++ b/documentation/poky.ent
>     > @@ -68,8 +68,8 @@
>     >? ? ? ?python3-jinja2 SDL-devel xterm">
>     >? <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++
>     git chrpath make wget python-xml \
>     >? ? ? ?diffstat makeinfo python-curses patch socat python3
>     python3-curses tar python3-pip \
>     > -? ? ?python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
>     > -? ? ?$ sudo pip3 install GitPython libSDL-devel xterm">
>     > +? ? ?python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
>     libSDL-devel xterm
>     > +? ? ?$ sudo pip3 install GitPython">
>     >? <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
>     >? ? ? ?$ sudo yum makecache
>     >? ? ? ?$ sudo yum install gawk make wget tar bzip2 gzip python
>     unzip perl patch \
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190608/fb6847ff/attachment.html>

From hschauhan at nulltrace.org  Sat Jun  8 20:22:48 2019
From: hschauhan at nulltrace.org (Chauhan, Himanshu)
Date: Sun, 9 Jun 2019 08:52:48 +0530
Subject: [yocto] Cannot link to custom library
Message-ID: <CAOkDQ3Wp9UmioB0-SL7UNhAE0wbRZ0_i6xw4WGx_hh+HvoL+Yw@mail.gmail.com>

Hi,

I have created a custom library which gets installed in /lib. Symlink
get created in /usr/lib and header file is copied to /usr/include

Then, I have another auto tool based application which should get
linked to the library mentioned above. During configure, the header
file is found but library is not found. I searched net but couldn't
find a definitive answer to the problem.

| checking whether to build shared libraries... yes
| checking whether to build static libraries... no
| checking libcli.h usability... yes
| checking libcli.h presence... yes
| checking for libcli.h... yes
| checking for library containing cli_init... no
| configure: error: required library libcli not found
| make: *** [config.status] Error 1
| ERROR: oe_runmake failed

-- 

Regards
[Himanshu Chauhan]

From isak.lichtenstein at gmail.com  Thu Jun  6 23:17:20 2019
From: isak.lichtenstein at gmail.com (Isak Lichtenstein)
Date: Fri, 7 Jun 2019 08:17:20 +0200
Subject: [yocto] Necessary changes between SDK and eSDK builds
Message-ID: <CAHSgvvtugt4h7eJ9u5DKjfqCOx9qK=v1s0TNES3fxKT=F6izfw@mail.gmail.com>

Hi



I?m using yocto thud 2.6.1 and always build & provide sdk?s to our
customers without problem.

Now a customer requested an eSDK instead.



According to the manual (
https://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer
<https://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#sdk-building-an-sdk-installer>),
this should work identically by simply using ?-c populate_sdk_ext?.



Unfortunately the tasks do_populate_sdk_ext fails with the following error
message:



?.

Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf.bak'
->
'/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/sdk-ext/image//opt/myboard/2.6.1/conf/local.conf'



ERROR: core-image-myboard-1.0-r0 do_populate_sdk_ext: Function failed:
copy_buildsystem

ERROR: Logfile of failure stored in:
/home/root/build/dev/tmp/work/myboard-poky-linux-gnueabi/core-image-myboard/1.0-r0/temp/log.do_populate_sdk_ext.17712

ERROR: Task
(/home/root/yocto/meta-evalboard/recipes-core/images/core-image-myboard.bb:do_populate_sdk_ext)
failed with exit code '1'



What do I need to change in order to build the extensible SDK?



Best regards

Isak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190607/a2ae4e0f/attachment.html>

From yocto at emagii.com  Sun Jun  9 15:11:24 2019
From: yocto at emagii.com (Ulf Samuelsson)
Date: Mon, 10 Jun 2019 00:11:24 +0200
Subject: [yocto] Multiple MACHINEs and DISTROs: When to use own build
 dir, SSTATE_DIR, DL_DIR ?
In-Reply-To: <CAJTo0Lb2dGk4rdX1cm83aDyEr8WxapH3+nAL6oVgSeO-hFZbiQ@mail.gmail.com>
References: <AM0PR10MB2658E98F7B370BD2FAEE187EC3330@AM0PR10MB2658.EURPRD10.PROD.OUTLOOK.COM>
	<CAJTo0Lb2dGk4rdX1cm83aDyEr8WxapH3+nAL6oVgSeO-hFZbiQ@mail.gmail.com>
Message-ID: <7ebe65af-7756-eee5-ec9e-9d7f8637d761@emagii.com>

Den 2019-05-09 kl. 11:56, skrev Burton, Ross:
> On Thu, 9 May 2019 at 10:47, Fabian Knapp <knapp at ambibox.de 
> <mailto:knapp at ambibox.de>> wrote:
> 
>     we have multiple MACHINEs and DISTROs and Im wondering for which
>     combinations I have to setup a dedicated build dir, SSTATE_DIR and
>     DL_DIR.
> 
>     Information in the form of:
> 
>     Each (change of) MACHINE needs its dedicated SSTATE_DIR and build
>     dir but can share DL_DIR.
> 
> 
> You can always share DL_DIR and SSTATE_DIR.
> 
> Ross
> 
When you have the same machine, and the recipes have variants
which are DISTRO dependent the SSTATE_DIR can be messed up

We never digged deep enough to find the cause,
but when we separated the SSTATE to only have one DISTRO
in the same SSTATE, the problem disappeared.

-- 
Best Regards
Ulf Samuelsson

From yocto at emagii.com  Sun Jun  9 15:19:32 2019
From: yocto at emagii.com (Ulf Samuelsson)
Date: Mon, 10 Jun 2019 00:19:32 +0200
Subject: [yocto] Installation help
In-Reply-To: <CADz_WD7w6WztQS1wCcnnkjdTDJ-LTHiqnfQWKqhQ13f_UsqbTg@mail.gmail.com>
References: <6bf22911-f264-f7b2-13a3-a914f9b3d2dd@gmail.com>
	<CADz_WD7TRFmcu9YQ+mJ6_nHbKQ5eXp8Fii_AK7ZPDJwhTOVX2A@mail.gmail.com>
	<CAJTo0LbEnsy_Ha5EOHuw8cgzFxH_Kj1U8O7ZsXOje+=y_XsVNA@mail.gmail.com>
	<2b04a1ee-d0a5-8525-7707-c4ff57ca6afe@gmail.com>
	<CAJTo0LaJxsg56pY9Fn5DTjFP5byrd0yFpNcXQAE4x9CPhjDOmw@mail.gmail.com>
	<CADz_WD7w6WztQS1wCcnnkjdTDJ-LTHiqnfQWKqhQ13f_UsqbTg@mail.gmail.com>
Message-ID: <ac5039f5-33d4-4aa7-51a7-deefa60d6137@emagii.com>

Den 2019-04-08 kl. 20:58, skrev Nataliya Korovkina:
> "example.com <http://example.com>" is not working. If someone needs to 
> check their connection this way, please use 
> CONNECTIVITY_CHECK_URIS="https://www.yoctoproject.org"
> 
I am pretty sure that my Linksys router defines example.com
in its hosts files :-(

BR
Ulf

> N
> 
> On Mon, Apr 8, 2019 at 2:50 PM Burton, Ross <ross.burton at intel.com 
> <mailto:ross.burton at intel.com>> wrote:
> 
>     There must be if example.com <http://example.com> can't be
>     downloaded from...
> 
>     On Mon, 8 Apr 2019 at 19:49, Karshi Hasanov
>     <karshi.hasanov at gmail.com <mailto:karshi.hasanov at gmail.com>> wrote:
>      >
>      > There is nothing wrong with my network network!
>      >
>      > For now the issue is resolved.
>      >
>      > Thanks any way.
>      >
>      >
>      > On 2019-04-08 1:10 p.m., Burton, Ross wrote:
>      > > The better fix is to fix your network.? If you need a proxy,
>     set it in
>      > > local.conf.
>      > >
>      > > Ross
>      > >
>      > > On Mon, 8 Apr 2019 at 18:09, Nataliya Korovkina
>      > > <malus.brandywine at gmail.com
>     <mailto:malus.brandywine at gmail.com>> wrote:
>      > >> Hello Karshi,
>      > >>
>      > >> I had the same message. I added:
>      > >>
>      > >> CONNECTIVITY_CHECK_URIS=""
>      > >>
>      > >> in conf/local.conf as a QUICK FIX. I hope someone has better
>     solution, please?
>      > >>
>      > >> Thanks,
>      > >> Nataliya
>      > >>
>      > >>
>      > >> On Mon, Apr 8, 2019 at 12:43 PM Karshi Hasanov
>     <karshi.hasanov at gmail.com <mailto:karshi.hasanov at gmail.com>> wrote:
>      > >>> Hi all,
>      > >>>
>      > >>> I have followed the
>      > >>>
>      > >>>
>     https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
>      > >>>
>      > >>> when issue the "bitbake core-image-minimal"
>      > >>>
>      > >>> I am keep getting this error:
>      > >>>
>      > >>> ERROR:? OE-core's config sanity checker detected a potential
>      > >>> misconfiguration.
>      > >>>? ? ? ?Either fix the cause of this error or at your own risk
>     disable the
>      > >>> checker (see sanity.conf).
>      > >>>? ? ? ?Following is the list of potential problems / advisories:
>      > >>>
>      > >>>? ? ? ?Fetcher failure for URL: 'https://www.example.com/'. URL
>      > >>> https://www.example.com/ doesn't work.
>      > >>>? ? ? ?Please ensure your host's network is configured correctly,
>      > >>>? ? ? ?or set BB_NO_NETWORK = "1" to disable network access if
>      > >>>? ? ? ?all required sources are on local disk.
>      > >>>
>      > >>> --
>      > >>> _______________________________________________
>      > >>> yocto mailing list
>      > >>> yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>      > >>> https://lists.yoctoproject.org/listinfo/yocto
>      > >>
>      > >>
>      > >> --
>      > >>
>      > >>
>      > >> Nataliya Korovkina
>      > >>
>      > >> --
>      > >> _______________________________________________
>      > >> yocto mailing list
>      > >> yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>      > >> https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> -- 
> 
> 
> Nataliya Korovkina
> 
> 


-- 
Best Regards
Ulf Samuelsson

From andreea.volosincu at windriver.com  Sun Jun  9 21:10:04 2019
From: andreea.volosincu at windriver.com (Volosincu, Andreea S)
Date: Mon, 10 Jun 2019 04:10:04 +0000
Subject: [yocto] Live Coding with Yocto Project - Tuesday, June 11
Message-ID: <A084970538D2234B96D99D06FA9D974FC37DA2D9@ALA-MBD.corp.ad.wrs.com>

Hello Everybody,
The next live coding session is coming soon.
When: Tuesday, June 11, 2019, 5:00 PM Europe/Berlin
Where: Yocto Project Twitch channel - https://lnkd.in/gruGi-H
What: Josef will show you how package dependencies work, especially package splitting
See you soon!
Yocto Project Advocacy Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190610/7beb21f8/attachment.html>

From zangrc.fnst at cn.fujitsu.com  Mon Jun 10 00:24:21 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Mon, 10 Jun 2019 15:24:21 +0800
Subject: [yocto] [meta-security][master][warrior][PATCH 0/3]
	python-scapy:solved the conflict with python3-scapy
Message-ID: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>

-Remove redundant sed operations.

-Rename conflicting files to resolve conflicts.


Zang Ruochen (3):
  [yocto][meta-security][master][warrior][PATCH 1/3] python-scapy: Remove
    redundant sed operations
  [yocto][meta-security][master][warrior][PATCH 2/3] python-scapy: solved
    the conflict with python3-scapy
  [yocto][meta-security][master][warrior][PATCH 3/3] python3-scapy: solved
    the conflict with python-scapy

 recipes-security/scapy/python-scapy.inc       | 7 -------
 recipes-security/scapy/python-scapy_2.4.2.bb  | 5 +++++
 recipes-security/scapy/python3-scapy_2.4.2.bb | 4 ++++
 3 files changed, 9 insertions(+), 7 deletions(-)

-- 
2.20.1




From zangrc.fnst at cn.fujitsu.com  Mon Jun 10 00:24:24 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Mon, 10 Jun 2019 15:24:24 +0800
Subject: [yocto] [meta-security][master][warrior][PATCH 3/3] python3-scapy:
	solved the conflict with python-scapy
In-Reply-To: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
References: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
Message-ID: <20190610072424.14779-4-zangrc.fnst@cn.fujitsu.com>

-Rename the following file to resolve the conflict with python-scapy:
	Rename /usr/bin/UTscapy to /usr/bin/UTscapy3
	Rename /usr/bin/scapy to /usr/bin/scapy3

Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
---
 recipes-security/scapy/python3-scapy_2.4.2.bb | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/recipes-security/scapy/python3-scapy_2.4.2.bb b/recipes-security/scapy/python3-scapy_2.4.2.bb
index 83c79f4..abcaeeb 100644
--- a/recipes-security/scapy/python3-scapy_2.4.2.bb
+++ b/recipes-security/scapy/python3-scapy_2.4.2.bb
@@ -3,3 +3,7 @@ require python-scapy.inc
 
 SRC_URI += "file://run-ptest"
 
+do_install_append() {
+        mv ${D}${bindir}/scapy ${D}${bindir}/scapy3
+        mv ${D}${bindir}/UTscapy ${D}${bindir}/UTscapy3
+}
-- 
2.20.1




From zangrc.fnst at cn.fujitsu.com  Mon Jun 10 00:24:23 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Mon, 10 Jun 2019 15:24:23 +0800
Subject: [yocto] [meta-security][master][warrior][PATCH 2/3] python-scapy:
	solved the conflict with python3-scapy
In-Reply-To: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
References: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
Message-ID: <20190610072424.14779-3-zangrc.fnst@cn.fujitsu.com>

-Rename the following file to resolve the conflict with python3-scapy:
	Rename /usr/bin/UTscapy to /usr/bin/UTscapy2
	Rename /usr/bin/scapy to /usr/bin/scapy2

Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
---
 recipes-security/scapy/python-scapy_2.4.2.bb | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/recipes-security/scapy/python-scapy_2.4.2.bb b/recipes-security/scapy/python-scapy_2.4.2.bb
index 98db1fd..982620e 100644
--- a/recipes-security/scapy/python-scapy_2.4.2.bb
+++ b/recipes-security/scapy/python-scapy_2.4.2.bb
@@ -4,3 +4,8 @@ require python-scapy.inc
 SRC_URI += "file://run-ptest"
 
 RDEPENDS_${PN} += "${PYTHON_PN}-subprocess"
+
+do_install_append() {
+        mv ${D}${bindir}/scapy ${D}${bindir}/scapy2
+        mv ${D}${bindir}/UTscapy ${D}${bindir}/UTscapy2
+}
-- 
2.20.1




From zangrc.fnst at cn.fujitsu.com  Mon Jun 10 00:24:22 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Mon, 10 Jun 2019 15:24:22 +0800
Subject: [yocto] [meta-security][master][warrior][PATCH 1/3] python-scapy:
	Remove redundant sed operations
In-Reply-To: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
References: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
Message-ID: <20190610072424.14779-2-zangrc.fnst@cn.fujitsu.com>

-Remove redundant sed operations.

Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
---
 recipes-security/scapy/python-scapy.inc | 7 -------
 1 file changed, 7 deletions(-)

diff --git a/recipes-security/scapy/python-scapy.inc b/recipes-security/scapy/python-scapy.inc
index 99f30a7..baa69b2 100644
--- a/recipes-security/scapy/python-scapy.inc
+++ b/recipes-security/scapy/python-scapy.inc
@@ -12,13 +12,6 @@ SRC_URI = "git://github.com/secdev/scapy.git"
 
 inherit ptest
 
-do_install_append() {
-    if [ "${PYTHON_PN}" = "python3" ]; then
-        sed -i -e 's/python/python3/' ${D}${bindir}/scapy
-        sed -i -e 's/python/python3/' ${D}${bindir}/UTscapy
-    fi
-}
-
 do_install_ptest() {
     install -m 0644 ${S}/test/regression.uts ${D}${PTEST_PATH}
     sed -i 's, at PTEST_PATH@,${PTEST_PATH},' ${D}${PTEST_PATH}/run-ptest
-- 
2.20.1




From bunk at stusta.de  Mon Jun 10 01:09:30 2019
From: bunk at stusta.de (Adrian Bunk)
Date: Mon, 10 Jun 2019 11:09:30 +0300
Subject: [yocto] [meta-security][master][warrior][PATCH 3/3]
 python3-scapy: solved the conflict with python-scapy
In-Reply-To: <20190610072424.14779-4-zangrc.fnst@cn.fujitsu.com>
References: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
	<20190610072424.14779-4-zangrc.fnst@cn.fujitsu.com>
Message-ID: <20190610080930.GA5894@localhost>

On Mon, Jun 10, 2019 at 03:24:24PM +0800, Zang Ruochen wrote:
> -Rename the following file to resolve the conflict with python-scapy:
> 	Rename /usr/bin/UTscapy to /usr/bin/UTscapy3
> 	Rename /usr/bin/scapy to /usr/bin/scapy3
> 
> Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
> ---
>  recipes-security/scapy/python3-scapy_2.4.2.bb | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/recipes-security/scapy/python3-scapy_2.4.2.bb b/recipes-security/scapy/python3-scapy_2.4.2.bb
> index 83c79f4..abcaeeb 100644
> --- a/recipes-security/scapy/python3-scapy_2.4.2.bb
> +++ b/recipes-security/scapy/python3-scapy_2.4.2.bb
> @@ -3,3 +3,7 @@ require python-scapy.inc
>  
>  SRC_URI += "file://run-ptest"
>  
> +do_install_append() {
> +        mv ${D}${bindir}/scapy ${D}${bindir}/scapy3
> +        mv ${D}${bindir}/UTscapy ${D}${bindir}/UTscapy3
> +}

A proper solution would require using alternatives so that installing 
either the python2 or the python3 version would provide the binary.

But given that python2 is reaching end of life I would suggest to just 
rename the python2 binaries and keep the python3 binaries that will stay
long-term at their upstream names.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From ross.burton at intel.com  Mon Jun 10 02:13:23 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Mon, 10 Jun 2019 10:13:23 +0100
Subject: [yocto] Multiple MACHINEs and DISTROs: When to use own build
 dir, SSTATE_DIR, DL_DIR ?
In-Reply-To: <7ebe65af-7756-eee5-ec9e-9d7f8637d761@emagii.com>
References: <AM0PR10MB2658E98F7B370BD2FAEE187EC3330@AM0PR10MB2658.EURPRD10.PROD.OUTLOOK.COM>
	<CAJTo0Lb2dGk4rdX1cm83aDyEr8WxapH3+nAL6oVgSeO-hFZbiQ@mail.gmail.com>
	<7ebe65af-7756-eee5-ec9e-9d7f8637d761@emagii.com>
Message-ID: <CAJTo0LaMhs4OEWVtvp5AKhwvCRGZ4MNBRHh+5CaCx1Bm7js0Dw@mail.gmail.com>

On Sun, 9 Jun 2019 at 23:19, Ulf Samuelsson <yocto at emagii.com> wrote:
> When you have the same machine, and the recipes have variants
> which are DISTRO dependent the SSTATE_DIR can be messed up
>
> We never digged deep enough to find the cause,
> but when we separated the SSTATE to only have one DISTRO
> in the same SSTATE, the problem disappeared.

The recipes were actively broken then, because DISTRO is in the hash.
If the DISTRO changes, the hash changes.

Ross

From richard.purdie at linuxfoundation.org  Mon Jun 10 04:41:42 2019
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Mon, 10 Jun 2019 12:41:42 +0100
Subject: [yocto] Multiple MACHINEs and DISTROs: When to use own build
 dir, SSTATE_DIR, DL_DIR ?
In-Reply-To: <7ebe65af-7756-eee5-ec9e-9d7f8637d761@emagii.com>
References: <AM0PR10MB2658E98F7B370BD2FAEE187EC3330@AM0PR10MB2658.EURPRD10.PROD.OUTLOOK.COM>
	<CAJTo0Lb2dGk4rdX1cm83aDyEr8WxapH3+nAL6oVgSeO-hFZbiQ@mail.gmail.com>
	<7ebe65af-7756-eee5-ec9e-9d7f8637d761@emagii.com>
Message-ID: <0a98d6545550da32b92a556dc2a516640a4ae0ea.camel@linuxfoundation.org>

On Mon, 2019-06-10 at 00:11 +0200, Ulf Samuelsson wrote:
> Den 2019-05-09 kl. 11:56, skrev Burton, Ross:
> > On Thu, 9 May 2019 at 10:47, Fabian Knapp <knapp at ambibox.de 
> > <mailto:knapp at ambibox.de>> wrote:
> > 
> >     we have multiple MACHINEs and DISTROs and Im wondering for
> > which
> >     combinations I have to setup a dedicated build dir, SSTATE_DIR
> > and
> >     DL_DIR.
> > 
> >     Information in the form of:
> > 
> >     Each (change of) MACHINE needs its dedicated SSTATE_DIR and
> > build
> >     dir but can share DL_DIR.
> > 
> > 
> > You can always share DL_DIR and SSTATE_DIR.
> > 
> > Ross
> > 
> When you have the same machine, and the recipes have variants
> which are DISTRO dependent the SSTATE_DIR can be messed up
> 
> We never digged deep enough to find the cause,
> but when we separated the SSTATE to only have one DISTRO
> in the same SSTATE, the problem disappeared.

The system is designed to work sharing DISTROs within sstate. If there
is a problem I would very much like to see the issue investigated and
fixed and can help with that.

Any such problems that have been filed in the bugzilla have been
addressed and there haven't really need any for quite a while.

Cheers,

Richard



From akuster808 at gmail.com  Mon Jun 10 07:47:52 2019
From: akuster808 at gmail.com (akuster808)
Date: Mon, 10 Jun 2019 07:47:52 -0700
Subject: [yocto] [meta-security] AppArmor 2.11 no longer available on
 Ubuntu archive (sumo branch)
In-Reply-To: <CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
References: <VI1P101MB01576372CF3A49D74933DBC3DE100@VI1P101MB0157.NAMP101.PROD.OUTLOOK.COM>
	<CAJTo0LY4BHK4zSLZCyaH_0nwG9MPcmgFaTbkOuWXZ6+NGN2AJA@mail.gmail.com>
Message-ID: <14d06afe-b53a-2fca-53c5-58845549b2b4@gmail.com>



On 6/7/19 3:09 AM, Burton, Ross wrote:
> That is deliberate and by design, recipes shouldn't fetch from
> Debian/Ubuntu archives for this reason.
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c
> is a patch to master that needs to be backported to warrior/thud/sumo.

working on propagating this change to the other branches.

- armin
>
> Ross
>
> On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy)
> <peter.t.smith at ge.com> wrote:
>> We are building with meta-security (from sumo branch) which currently uses v2.11 of AppArmor, it seems overnight that the source archive has been removed from the Ubuntu archives. Does anyone know if this is a deliberate action, or if not who to contact to get it put back.
>>
>>
>>
>> Peter Smith
>>
>>
>>
>> Senior Emerging Technologies Engineer
>>
>> Grid Solutions
>>
>> GE Renewable Energy
>>
>>
>>
>> -NON PUBLIC-
>>
>>
>>
>>
>>
>>
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto


From akuster808 at gmail.com  Mon Jun 10 07:48:48 2019
From: akuster808 at gmail.com (akuster808)
Date: Mon, 10 Jun 2019 07:48:48 -0700
Subject: [yocto] [meta-security][master][warrior][PATCH 0/3]
 python-scapy:solved the conflict with python3-scapy
In-Reply-To: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
References: <20190610072424.14779-1-zangrc.fnst@cn.fujitsu.com>
Message-ID: <9c97e3b7-ba23-028e-150d-fca628fb3e29@gmail.com>



On 6/10/19 12:24 AM, Zang Ruochen wrote:
> -Remove redundant sed operations.
>
> -Rename conflicting files to resolve conflicts.
merged to master.

working on warrior

thanks,
- armin
>
>
> Zang Ruochen (3):
>   [yocto][meta-security][master][warrior][PATCH 1/3] python-scapy: Remove
>     redundant sed operations
>   [yocto][meta-security][master][warrior][PATCH 2/3] python-scapy: solved
>     the conflict with python3-scapy
>   [yocto][meta-security][master][warrior][PATCH 3/3] python3-scapy: solved
>     the conflict with python-scapy
>
>  recipes-security/scapy/python-scapy.inc       | 7 -------
>  recipes-security/scapy/python-scapy_2.4.2.bb  | 5 +++++
>  recipes-security/scapy/python3-scapy_2.4.2.bb | 4 ++++
>  3 files changed, 9 insertions(+), 7 deletions(-)
>


From pokybuild at debian8.yocto.io  Mon Jun 10 14:38:14 2019
From: pokybuild at debian8.yocto.io (Poky Build User)
Date: Mon, 10 Jun 2019 21:38:14 +0000 (UTC)
Subject: [yocto] QA notification for completed autobuilder build
	(yocto-2.8_M1.rc1)
Message-ID: <20190610213814.BC1771A009F@debian8-ty-1.yocto.io>


A build flagged for QA (yocto-2.8_M1.rc1) was completed on the autobuilder and is available at:


    https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc1


Build hash information: 

bitbake: c4d90890547af642e99cc541af3415df3559563e
meta-gplv2: 168a5070bdf3bc45edb5bf2a1add9b7c081f5b64
meta-intel: c941d896c08d6d83694ba0af1fdf4f4dcb625e9f
meta-mingw: d17724b0eac76792a49e56213cba74e32edba48f
oecore: 86266dfcd70b8e3435d267538c3e6e4d69be829e
poky: 9910a3631ce953b8dd8f3d57d6e122c7fd8cb462



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie at linuxfoundation.org


 

From richard.purdie at linuxfoundation.org  Mon Jun 10 15:18:17 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Mon, 10 Jun 2019 23:18:17 +0100
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc1)
In-Reply-To: <20190610213814.BC1771A009F@debian8-ty-1.yocto.io>
References: <20190610213814.BC1771A009F@debian8-ty-1.yocto.io>
Message-ID: <41f4e149903ed82864c7160a558ba5d41b2074e3.camel@linuxfoundation.org>

On Mon, 2019-06-10 at 21:38 +0000, Poky Build User wrote:
> A build flagged for QA (yocto-2.8_M1.rc1) was completed on the
> autobuilder and is available at:
> 
> 
>     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc1
> 

I've triggered an rc2 since one of the autobuilder workers messed up
the mips builds.

Cheers,

Richard


From Qi.Chen at windriver.com  Mon Jun 10 18:14:20 2019
From: Qi.Chen at windriver.com (Chen Qi)
Date: Tue, 11 Jun 2019 09:14:20 +0800
Subject: [yocto] [meta-anaconda][PATCH] .gitignore: add *.pyc and *.pyo
Message-ID: <1560215660-13260-1-git-send-email-Qi.Chen@windriver.com>

The .gitignore needs to contain these two items, otherwise, we get
unstaged lib/oeqa/selftest/cases/__pycache__/ every time we run
oe-selftest.

Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index b093583..c01df45 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,5 @@
+*.pyc
+*.pyo
 /*.patch
 *.swp
 *.orig
-- 
2.7.4


From ee.peng.yeoh at intel.com  Mon Jun 10 18:51:58 2019
From: ee.peng.yeoh at intel.com (Yeoh, Ee Peng)
Date: Tue, 11 Jun 2019 01:51:58 +0000
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc1)
In-Reply-To: <41f4e149903ed82864c7160a558ba5d41b2074e3.camel@linuxfoundation.org>
References: <20190610213814.BC1771A009F@debian8-ty-1.yocto.io>
	<41f4e149903ed82864c7160a558ba5d41b2074e3.camel@linuxfoundation.org>
Message-ID: <9DDD2658D1FE414E99172D2DB1E4D043481E6A23@PGSMSX109.gar.corp.intel.com>

Richard,

Thanks for informing! 

Best regards,
Yeoh Ee Peng 

-----Original Message-----
From: richard.purdie at linuxfoundation.org [mailto:richard.purdie at linuxfoundation.org] 
Sent: Tuesday, June 11, 2019 6:18 AM
To: Poky Build User <pokybuild at debian8.yocto.io>; yocto at yoctoproject.org
Cc: otavio at ossystems.com.br; yi.zhao at windriver.com; Sangal, Apoorv <apoorv.sangal at intel.com>; Yeoh, Ee Peng <ee.peng.yeoh at intel.com>; Chan, Aaron Chun Yew <aaron.chun.yew.chan at intel.com>; Ang, Chin Huat <chin.huat.ang at intel.com>; akuster808 at gmail.com; sjolley.yp.pm at gmail.com; Jain, Sangeeta <sangeeta.jain at intel.com>
Subject: Re: QA notification for completed autobuilder build (yocto-2.8_M1.rc1)

On Mon, 2019-06-10 at 21:38 +0000, Poky Build User wrote:
> A build flagged for QA (yocto-2.8_M1.rc1) was completed on the 
> autobuilder and is available at:
> 
> 
>     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc1
> 

I've triggered an rc2 since one of the autobuilder workers messed up the mips builds.

Cheers,

Richard


From zhe.he at windriver.com  Mon Jun 10 20:06:50 2019
From: zhe.he at windriver.com (zhe.he at windriver.com)
Date: Tue, 11 Jun 2019 11:06:50 +0800
Subject: [yocto] [meta-dpdk][PATCH] dpdk: Fix do_compile failure for qemux86
	and qemux86-64
In-Reply-To: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>
References: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>
Message-ID: <1560222410-414851-2-git-send-email-zhe.he@windriver.com>

From: He Zhe <zhe.he at windriver.com>

DPDK_TARGET_MACHINE in bbappend in other layers forms the dpdk-internal variable
MACHINE_CFLAGS which is passed to dpdk compilation command line containing the
first -march parameter. And EXTRA_CFLAGS in dpdk.inc is passed to dpdk command
line containing the second -march parameter. By mistake, the first -march had
always overwritten the second one until the following commit of GCC v9.1.0
8c0f695d83d1 ("driver: Also prune joined switches with negation").

Since it was fixed, the second -march, which was core2 for qemux86-64 or
core2-32 for qemux86, began to take effect. But core2* does not have SSE4.2
feature which is required by some dpdk instruction optimization and thus cause
the following compilation failure.

9.1.0/include/smmintrin.h:179:1: error: inlining failed in call to always_inline
'_mm_blendv_epi8': target specific option mismatch
  179 | _mm_blendv_epi8 (__m128i __X, __m128i __Y, __m128i __M)
      | ^~~~~~~~~~~~~~~

This patch adds DPDK_EXTRA_CFLAGS to append appropriate -march, corei7 which is
minimum and clear and independent of host machine, to dpdk compilation command
line to overwrite all previous ones, without having to change dpdk source code.

Note that as we do not want to change the default tune core2* for qemux86*, this
patch just fixes the compilation error. It would probably not be able to run on
qemux86* with corei7 tune.

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 recipes-extended/dpdk/dpdk.inc | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-extended/dpdk/dpdk.inc
index a0e081a..0275e0c 100644
--- a/recipes-extended/dpdk/dpdk.inc
+++ b/recipes-extended/dpdk/dpdk.inc
@@ -61,6 +61,9 @@ DPDK_RTE_TARGET_x86-64 = "x86_64-native-linuxapp-gcc"
 DPDK_RTE_TARGET_x86 = "i686-native-linuxapp-gcc"
 DPDK_RTE_TARGET_aarch64 = "arm64-${DPDK_TARGET_MACH}-linuxapp-gcc"
 export RTE_TARGET = "${DPDK_RTE_TARGET}"
+DPDK_EXTRA_CFLAGS = ""
+DPDK_EXTRA_CFLAGS_qemux86 ?= "-march=corei7"
+DPDK_EXTRA_CFLAGS_qemux86-64 ?= "-march=corei7"
 
 # The list of intel Comms platforms and their target machine
 # process mapping. The supported target machine is listed under
@@ -100,18 +103,18 @@ do_compile () {
 
 	cd ${S}/${RTE_TARGET}
 	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu" \
-		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} -I${STAGING_INCDIR}" \
+		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
 		   CROSS="${TARGET_PREFIX}" \
 		   prefix=""  LDFLAGS="${TUNE_LDARGS}"  WERROR_FLAGS="-w" V=1
 
 	cd ${S}/examples/
 	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu -fuse-ld=bfd" \
-		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} -I${STAGING_INCDIR}" \
+		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
 		   CROSS="${TARGET_PREFIX}" O="${S}/examples/$@/"
 
 	cd ${S}/test/
 	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu -fuse-ld=bfd" \
-		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} -I${STAGING_INCDIR}" \
+		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
 		   CROSS="${TARGET_PREFIX}" O="${S}/test/$@/"
 }
 
-- 
2.7.4


From zhe.he at windriver.com  Mon Jun 10 20:06:49 2019
From: zhe.he at windriver.com (zhe.he at windriver.com)
Date: Tue, 11 Jun 2019 11:06:49 +0800
Subject: [yocto] [meta-dpdk][PATCH] dpdk: mk: disable warning for packed
	member pointer
Message-ID: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>

From: He Zhe <zhe.he at windriver.com>

Backport a patch from upstream to fix the following build failure.

x86_64-native-linuxapp-gcc/include/rte_ether.h:178:2: error:
converting a packed 'const struct ether_addr' pointer (alignment 1) to a 'unaligned_uint16_t' {aka 'const short
 unsigned int'} pointer (alignment 2) may result in an unaligned pointer value [-Werror=address-of-packed-member]
|   178 |  const unaligned_uint16_t *ea_words = (const unaligned_uint16_t *)ea;
|       |  ^~~~~

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 ...disable-warning-for-packed-member-pointer.patch | 48 ++++++++++++++++++++++
 recipes-extended/dpdk/dpdk_17.11.3.bb              |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch

diff --git a/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch b/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch
new file mode 100644
index 0000000..70a8dec
--- /dev/null
+++ b/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch
@@ -0,0 +1,48 @@
+From a385972c3675dd2b4792ab5b3cf7a536e6f9846c Mon Sep 17 00:00:00 2001
+From: Reshma Pattan <reshma.pattan at intel.com>
+Date: Thu, 2 May 2019 10:33:34 +0100
+Subject: [PATCH] mk: disable warning for packed member pointer
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+gcc 9 on Fedora 30 gives an error
+"taking address of packed member may result in an
+unaligned pointer value" warnings.
+
+For clang builds this warning is already disabled,
+so disable "-Waddress-of-packed-member" for gcc builds
+also.
+
+Snippet of build error:
+lib/librte_eal/linux/eal/eal_memalloc.c: In function ?alloc_seg_walk?:
+lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error:
+taking address of packed member of ?struct rte_mem_config? may result
+in an unaligned pointer value [-Werror=address-of-packed-member]
+  768 |  cur_msl = &mcfg->memsegs[msl_idx];
+      |            ^~~~~~~~~~~~~~~~~~~~~~~
+
+Signed-off-by: Reshma Pattan <reshma.pattan at intel.com>
+Tested-by: David Marchand <david.marchand at redhat.com>
+Upstream-Status: Backport
+Signed-off-by: He Zhe <zhe.he at windriver.com>
+---
+ mk/toolchain/gcc/rte.vars.mk | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/mk/toolchain/gcc/rte.vars.mk b/mk/toolchain/gcc/rte.vars.mk
+index d8b99fa..b852fcf 100644
+--- a/mk/toolchain/gcc/rte.vars.mk
++++ b/mk/toolchain/gcc/rte.vars.mk
+@@ -87,5 +87,8 @@ WERROR_FLAGS += -Wimplicit-fallthrough=2
+ WERROR_FLAGS += -Wno-format-truncation
+ endif
+ 
++# disable packed member unalign warnings
++WERROR_FLAGS += -Wno-address-of-packed-member
++
+ export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
+ export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
+-- 
+2.7.4
+
diff --git a/recipes-extended/dpdk/dpdk_17.11.3.bb b/recipes-extended/dpdk/dpdk_17.11.3.bb
index 7fc89d2..af42ad8 100644
--- a/recipes-extended/dpdk/dpdk_17.11.3.bb
+++ b/recipes-extended/dpdk/dpdk_17.11.3.bb
@@ -12,4 +12,5 @@ SRC_URI += "\
         file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch \
         file://dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch \
         file://dpdk-17.11-Fix-strncpy-error-for-GCC8.patch \
+        file://dpdk-17.11-mk-disable-warning-for-packed-member-pointer.patch \
 "
-- 
2.7.4


From pokybuild at debian9-ty-1.yocto.io  Mon Jun 10 20:32:20 2019
From: pokybuild at debian9-ty-1.yocto.io (pokybuild at debian9-ty-1.yocto.io)
Date: Tue, 11 Jun 2019 03:32:20 +0000
Subject: [yocto] QA notification for completed autobuilder build
	(yocto-2.8_M1.rc2)
Message-ID: <20190611033223.88C8BE00736@yocto-www.yoctoproject.org>


A build flagged for QA (yocto-2.8_M1.rc2) was completed on the autobuilder and is available at:


    https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2


Build hash information: 

bitbake: c4d90890547af642e99cc541af3415df3559563e
meta-gplv2: 168a5070bdf3bc45edb5bf2a1add9b7c081f5b64
meta-intel: c941d896c08d6d83694ba0af1fdf4f4dcb625e9f
meta-mingw: d17724b0eac76792a49e56213cba74e32edba48f
oecore: 86266dfcd70b8e3435d267538c3e6e4d69be829e
poky: 9910a3631ce953b8dd8f3d57d6e122c7fd8cb462



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie at linuxfoundation.org


 

From anuj.mittal at intel.com  Mon Jun 10 23:29:48 2019
From: anuj.mittal at intel.com (Mittal, Anuj)
Date: Tue, 11 Jun 2019 06:29:48 +0000
Subject: [yocto] [meta-dpdk][PATCH] dpdk: mk: disable warning for packed
 member pointer
In-Reply-To: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>
References: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>
Message-ID: <dba13bde0e9e8eff94bbb42e8fccc0afb693b95c.camel@intel.com>

Thanks, I have included this for 18.11 as well and merged.

Thanks,

Anuj

On Tue, 2019-06-11 at 11:06 +0800, zhe.he at windriver.com wrote:
> From: He Zhe <zhe.he at windriver.com>
> 
> Backport a patch from upstream to fix the following build failure.
> 
> x86_64-native-linuxapp-gcc/include/rte_ether.h:178:2: error:
> converting a packed 'const struct ether_addr' pointer (alignment 1)
> to a 'unaligned_uint16_t' {aka 'const short
>  unsigned int'} pointer (alignment 2) may result in an unaligned
> pointer value [-Werror=address-of-packed-member]
> >   178 |  const unaligned_uint16_t *ea_words = (const
> > unaligned_uint16_t *)ea;
> >       |  ^~~~~
> 
> Signed-off-by: He Zhe <zhe.he at windriver.com>
> ---
>  ...disable-warning-for-packed-member-pointer.patch | 48
> ++++++++++++++++++++++
>  recipes-extended/dpdk/dpdk_17.11.3.bb              |  1 +
>  2 files changed, 49 insertions(+)
>  create mode 100644 recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-
> warning-for-packed-member-pointer.patch
> 
> diff --git a/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-
> warning-for-packed-member-pointer.patch b/recipes-
> extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-
> pointer.patch
> new file mode 100644
> index 0000000..70a8dec
> --- /dev/null
> +++ b/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-
> packed-member-pointer.patch
> @@ -0,0 +1,48 @@
> +From a385972c3675dd2b4792ab5b3cf7a536e6f9846c Mon Sep 17 00:00:00
> 2001
> +From: Reshma Pattan <reshma.pattan at intel.com>
> +Date: Thu, 2 May 2019 10:33:34 +0100
> +Subject: [PATCH] mk: disable warning for packed member pointer
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +gcc 9 on Fedora 30 gives an error
> +"taking address of packed member may result in an
> +unaligned pointer value" warnings.
> +
> +For clang builds this warning is already disabled,
> +so disable "-Waddress-of-packed-member" for gcc builds
> +also.
> +
> +Snippet of build error:
> +lib/librte_eal/linux/eal/eal_memalloc.c: In function
> ?alloc_seg_walk?:
> +lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error:
> +taking address of packed member of ?struct rte_mem_config? may
> result
> +in an unaligned pointer value [-Werror=address-of-packed-member]
> +  768 |  cur_msl = &mcfg->memsegs[msl_idx];
> +      |            ^~~~~~~~~~~~~~~~~~~~~~~
> +
> +Signed-off-by: Reshma Pattan <reshma.pattan at intel.com>
> +Tested-by: David Marchand <david.marchand at redhat.com>
> +Upstream-Status: Backport
> +Signed-off-by: He Zhe <zhe.he at windriver.com>
> +---
> + mk/toolchain/gcc/rte.vars.mk | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/mk/toolchain/gcc/rte.vars.mk
> b/mk/toolchain/gcc/rte.vars.mk
> +index d8b99fa..b852fcf 100644
> +--- a/mk/toolchain/gcc/rte.vars.mk
> ++++ b/mk/toolchain/gcc/rte.vars.mk
> +@@ -87,5 +87,8 @@ WERROR_FLAGS += -Wimplicit-fallthrough=2
> + WERROR_FLAGS += -Wno-format-truncation
> + endif
> + 
> ++# disable packed member unalign warnings
> ++WERROR_FLAGS += -Wno-address-of-packed-member
> ++
> + export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
> + export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
> +-- 
> +2.7.4
> +
> diff --git a/recipes-extended/dpdk/dpdk_17.11.3.bb b/recipes-
> extended/dpdk/dpdk_17.11.3.bb
> index 7fc89d2..af42ad8 100644
> --- a/recipes-extended/dpdk/dpdk_17.11.3.bb
> +++ b/recipes-extended/dpdk/dpdk_17.11.3.bb
> @@ -12,4 +12,5 @@ SRC_URI += "\
>          file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch \
>          file://dpdk-17.02-dpdk-fix-installation-warning-and-
> issue.patch \
>          file://dpdk-17.11-Fix-strncpy-error-for-GCC8.patch \
> +        file://dpdk-17.11-mk-disable-warning-for-packed-member-
> pointer.patch \
>  "


From anuj.mittal at intel.com  Mon Jun 10 23:31:45 2019
From: anuj.mittal at intel.com (Mittal, Anuj)
Date: Tue, 11 Jun 2019 06:31:45 +0000
Subject: [yocto] [meta-dpdk][PATCH] dpdk: Fix do_compile failure for
 qemux86 and qemux86-64
In-Reply-To: <1560222410-414851-2-git-send-email-zhe.he@windriver.com>
References: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>
	<1560222410-414851-2-git-send-email-zhe.he@windriver.com>
Message-ID: <82c0e90ca18d0b5a2389a9fc608f3bab61492f7f.camel@intel.com>

On Tue, 2019-06-11 at 11:06 +0800, zhe.he at windriver.com wrote:
> From: He Zhe <zhe.he at windriver.com>
> 
> DPDK_TARGET_MACHINE in bbappend in other layers forms the dpdk-
> internal variable
> MACHINE_CFLAGS which is passed to dpdk compilation command line
> containing the
> first -march parameter. And EXTRA_CFLAGS in dpdk.inc is passed to
> dpdk command
> line containing the second -march parameter. By mistake, the first
> -march had
> always overwritten the second one until the following commit of GCC
> v9.1.0
> 8c0f695d83d1 ("driver: Also prune joined switches with negation").
> 
> Since it was fixed, the second -march, which was core2 for qemux86-64 
> or
> core2-32 for qemux86, began to take effect. But core2* does not have
> SSE4.2
> feature which is required by some dpdk instruction optimization and
> thus cause
> the following compilation failure.
> 
> 9.1.0/include/smmintrin.h:179:1: error: inlining failed in call to
> always_inline
> '_mm_blendv_epi8': target specific option mismatch
>   179 | _mm_blendv_epi8 (__m128i __X, __m128i __Y, __m128i __M)
>       | ^~~~~~~~~~~~~~~
> 
> This patch adds DPDK_EXTRA_CFLAGS to append appropriate -march,
> corei7 which is
> minimum and clear and independent of host machine, to dpdk
> compilation command
> line to overwrite all previous ones, without having to change dpdk
> source code.
> 
> Note that as we do not want to change the default tune core2* for
> qemux86*, this
> patch just fixes the compilation error. It would probably not be able
> to run on
> qemux86* with corei7 tune.

I don't think overriding arch values in recipe is appropriate. Also the
recipe is setting COMPATIBLE_MACHINE to be null because of this reason.
If the MACHINE that we're building for doesn't support the features
required, then we shouldn't be building dpdk for it in my opinion.

Thanks,

Anuj

> 
> Signed-off-by: He Zhe <zhe.he at windriver.com>
> ---
>  recipes-extended/dpdk/dpdk.inc | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-
> extended/dpdk/dpdk.inc
> index a0e081a..0275e0c 100644
> --- a/recipes-extended/dpdk/dpdk.inc
> +++ b/recipes-extended/dpdk/dpdk.inc
> @@ -61,6 +61,9 @@ DPDK_RTE_TARGET_x86-64 = "x86_64-native-linuxapp-
> gcc"
>  DPDK_RTE_TARGET_x86 = "i686-native-linuxapp-gcc"
>  DPDK_RTE_TARGET_aarch64 = "arm64-${DPDK_TARGET_MACH}-linuxapp-gcc"
>  export RTE_TARGET = "${DPDK_RTE_TARGET}"
> +DPDK_EXTRA_CFLAGS = ""
> +DPDK_EXTRA_CFLAGS_qemux86 ?= "-march=corei7"
> +DPDK_EXTRA_CFLAGS_qemux86-64 ?= "-march=corei7"
>  
>  # The list of intel Comms platforms and their target machine
>  # process mapping. The supported target machine is listed under
> @@ -100,18 +103,18 @@ do_compile () {
>  
>  	cd ${S}/${RTE_TARGET}
>  	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu" 
> \
> -		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> -I${STAGING_INCDIR}" \
> +		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
>  		   CROSS="${TARGET_PREFIX}" \
>  		   prefix=""  LDFLAGS="${TUNE_LDARGS}"  WERROR_FLAGS="-
> w" V=1
>  
>  	cd ${S}/examples/
>  	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu
> -fuse-ld=bfd" \
> -		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> -I${STAGING_INCDIR}" \
> +		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
>  		   CROSS="${TARGET_PREFIX}" O="${S}/examples/$@/"
>  
>  	cd ${S}/test/
>  	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu
> -fuse-ld=bfd" \
> -		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> -I${STAGING_INCDIR}" \
> +		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
>  		   CROSS="${TARGET_PREFIX}" O="${S}/test/$@/"
>  }
>  


From zhe.he at windriver.com  Tue Jun 11 00:00:57 2019
From: zhe.he at windriver.com (He Zhe)
Date: Tue, 11 Jun 2019 15:00:57 +0800
Subject: [yocto] [meta-dpdk][PATCH] dpdk: Fix do_compile failure for
 qemux86 and qemux86-64
In-Reply-To: <82c0e90ca18d0b5a2389a9fc608f3bab61492f7f.camel@intel.com>
References: <1560222410-414851-1-git-send-email-zhe.he@windriver.com>
	<1560222410-414851-2-git-send-email-zhe.he@windriver.com>
	<82c0e90ca18d0b5a2389a9fc608f3bab61492f7f.camel@intel.com>
Message-ID: <0f6a60c2-b3c0-e787-51f4-d77046f91b08@windriver.com>



On 6/11/19 2:31 PM, Mittal, Anuj wrote:
> On Tue, 2019-06-11 at 11:06 +0800, zhe.he at windriver.com wrote:
>> From: He Zhe <zhe.he at windriver.com>
>>
>> DPDK_TARGET_MACHINE in bbappend in other layers forms the dpdk-
>> internal variable
>> MACHINE_CFLAGS which is passed to dpdk compilation command line
>> containing the
>> first -march parameter. And EXTRA_CFLAGS in dpdk.inc is passed to
>> dpdk command
>> line containing the second -march parameter. By mistake, the first
>> -march had
>> always overwritten the second one until the following commit of GCC
>> v9.1.0
>> 8c0f695d83d1 ("driver: Also prune joined switches with negation").
>>
>> Since it was fixed, the second -march, which was core2 for qemux86-64 
>> or
>> core2-32 for qemux86, began to take effect. But core2* does not have
>> SSE4.2
>> feature which is required by some dpdk instruction optimization and
>> thus cause
>> the following compilation failure.
>>
>> 9.1.0/include/smmintrin.h:179:1: error: inlining failed in call to
>> always_inline
>> '_mm_blendv_epi8': target specific option mismatch
>>   179 | _mm_blendv_epi8 (__m128i __X, __m128i __Y, __m128i __M)
>>       | ^~~~~~~~~~~~~~~
>>
>> This patch adds DPDK_EXTRA_CFLAGS to append appropriate -march,
>> corei7 which is
>> minimum and clear and independent of host machine, to dpdk
>> compilation command
>> line to overwrite all previous ones, without having to change dpdk
>> source code.
>>
>> Note that as we do not want to change the default tune core2* for
>> qemux86*, this
>> patch just fixes the compilation error. It would probably not be able
>> to run on
>> qemux86* with corei7 tune.
> I don't think overriding arch values in recipe is appropriate. Also the
> recipe is setting COMPATIBLE_MACHINE to be null because of this reason.
> If the MACHINE that we're building for doesn't support the features
> required, then we shouldn't be building dpdk for it in my opinion.

This is largely a fix for those who want to test building qemux86* with dpdk.
It does no harm to the rest of the configuration, and can be use as a way to
append potential flags to dpdk building command line.

But it's fine to me to drop it if it does not make much sense to you.

Thanks,
Zhe

>
> Thanks,
>
> Anuj
>
>> Signed-off-by: He Zhe <zhe.he at windriver.com>
>> ---
>>  recipes-extended/dpdk/dpdk.inc | 9 ++++++---
>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>
>> diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-
>> extended/dpdk/dpdk.inc
>> index a0e081a..0275e0c 100644
>> --- a/recipes-extended/dpdk/dpdk.inc
>> +++ b/recipes-extended/dpdk/dpdk.inc
>> @@ -61,6 +61,9 @@ DPDK_RTE_TARGET_x86-64 = "x86_64-native-linuxapp-
>> gcc"
>>  DPDK_RTE_TARGET_x86 = "i686-native-linuxapp-gcc"
>>  DPDK_RTE_TARGET_aarch64 = "arm64-${DPDK_TARGET_MACH}-linuxapp-gcc"
>>  export RTE_TARGET = "${DPDK_RTE_TARGET}"
>> +DPDK_EXTRA_CFLAGS = ""
>> +DPDK_EXTRA_CFLAGS_qemux86 ?= "-march=corei7"
>> +DPDK_EXTRA_CFLAGS_qemux86-64 ?= "-march=corei7"
>>  
>>  # The list of intel Comms platforms and their target machine
>>  # process mapping. The supported target machine is listed under
>> @@ -100,18 +103,18 @@ do_compile () {
>>  
>>  	cd ${S}/${RTE_TARGET}
>>  	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu" 
>> \
>> -		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
>> -I${STAGING_INCDIR}" \
>> +		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
>> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
>>  		   CROSS="${TARGET_PREFIX}" \
>>  		   prefix=""  LDFLAGS="${TUNE_LDARGS}"  WERROR_FLAGS="-
>> w" V=1
>>  
>>  	cd ${S}/examples/
>>  	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu
>> -fuse-ld=bfd" \
>> -		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
>> -I${STAGING_INCDIR}" \
>> +		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
>> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
>>  		   CROSS="${TARGET_PREFIX}" O="${S}/examples/$@/"
>>  
>>  	cd ${S}/test/
>>  	oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu
>> -fuse-ld=bfd" \
>> -		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
>> -I${STAGING_INCDIR}" \
>> +		   EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
>> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
>>  		   CROSS="${TARGET_PREFIX}" O="${S}/test/$@/"
>>  }
>>  


From martin.jansa at gmail.com  Tue Jun 11 00:07:55 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Tue, 11 Jun 2019 07:07:55 +0000
Subject: [yocto] [meta-gplv2][PATCH] bc: use u-a for bc as well
Message-ID: <20190611070755.192-1-Martin.Jansa@gmail.com>

* bc can be provided by busybox as well (e.g. if you have your own
  defconfig and forget to explicitly disable it:
  ...
  *
  * Miscellaneous Utilities
  *
  adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
  bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
  bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
    Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
      Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)     Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) [N/y/?] n
  chat (6.3 kb) (CHAT) [N/y/?] n
  conspy (10 kb) (CONSPY) [N/y/?] n
  ...
  ), causing conflict in u-a:

  update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid since /usr/bin/bc exists and is not a link

  and then whole do_rootfs or do_populate_sdk to fail because busybox postinst is failing:

  do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
  then please place them into pkg_postinst_ontarget_${PN} (). Deferring to first boot via 'exit 1' is no longer supported.

Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
---
 recipes-extended/bc/bc_1.06.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
index d8c8a86..3de1b24 100644
--- a/recipes-extended/bc/bc_1.06.bb
+++ b/recipes-extended/bc/bc_1.06.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] = "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
 
 inherit autotools texinfo update-alternatives
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native"
-- 
2.17.1


From martin.jansa at gmail.com  Tue Jun 11 00:08:23 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Tue, 11 Jun 2019 07:08:23 +0000
Subject: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
Message-ID: <20190611070823.367-1-Martin.Jansa@gmail.com>

* bc can be provided by busybox as well (e.g. if you have your own
  defconfig and forget to explicitly disable it:
  ...
  *
  * Miscellaneous Utilities
  *
  adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
  bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
  bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
    Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
      Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)     Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) [N/y/?] n
  chat (6.3 kb) (CHAT) [N/y/?] n
  conspy (10 kb) (CONSPY) [N/y/?] n
  ...
  ), causing conflict in u-a:

  update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid since /usr/bin/bc exists and is not a link

  and then whole do_rootfs or do_populate_sdk to fail because busybox postinst is failing:

  do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
  then please place them into pkg_postinst_ontarget_${PN} (). Deferring to first boot via 'exit 1' is no longer supported.

Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
---
 recipes-extended/bc/bc_1.06.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
index d8c8a86..3de1b24 100644
--- a/recipes-extended/bc/bc_1.06.bb
+++ b/recipes-extended/bc/bc_1.06.bb
@@ -20,7 +20,7 @@ SRC_URI[sha256sum] = "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
 
 inherit autotools texinfo update-alternatives
 
-ALTERNATIVE_${PN} = "dc"
+ALTERNATIVE_${PN} = "bc dc"
 ALTERNATIVE_PRIORITY = "100"
 
 BBCLASSEXTEND = "native"
-- 
2.17.1


From mans.zigher at gmail.com  Tue Jun 11 01:23:29 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Tue, 11 Jun 2019 10:23:29 +0200
Subject: [yocto] How to set PACKAGE_EXTRA_ARCHS
In-Reply-To: <CAEhQi8m3pJtUMMzSH0enBmLz5=x4CYnvV3LW-1W8BHJdMDGR_w@mail.gmail.com>
References: <CAEhQi8m3pJtUMMzSH0enBmLz5=x4CYnvV3LW-1W8BHJdMDGR_w@mail.gmail.com>
Message-ID: <CAEhQi8k--Zpay4SAqfGru077+q1DDDWbtAWDJRNz149LzSP4cQ@mail.gmail.com>

Adding

PACKAGE_EXTRA_ARCHS = "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
armv7ahf-neon-mx8mm"

To my machine config solved my problem but I am not sure if it belongs
here or not.

BR

Den tors 6 juni 2019 kl 10:02 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> Hi,
>
> I am facing an issue described here
> https://lists.yoctoproject.org/pipermail/yocto/2019-June/045565.html.
> I have come to the conclusion that I need to add armv7ahf-neon-mx8mm
> to PACKAGE_EXTRA_ARCHS but it is not obvious how to do that based on
> what is stated in the reference manual
> https://www.yoctoproject.org/docs/2.4/ref-manual/ref-manual.html#var-PACKAGE_EXTRA_ARCHS,
> at least not for me. I have gone through the existing usage of the
> PACKAGE_EXTRA_ARCHS in poky but in there it is always used in
> combination with tune so for example
>
> PACKAGE_EXTRA_ARCHS_tune-armv7atb-neon  =
> "${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon"
>
> How can I make sure to get armv7ahf-neon-mx8mm added to the
> PACKAGE_EXTRA_ARCHS variable and where should it be set local.conf,
> machine configuration?
>
> BR
> M?ns Zigher

From mans.zigher at gmail.com  Tue Jun 11 01:24:05 2019
From: mans.zigher at gmail.com (=?UTF-8?B?TcOlbnMgWmlnaGVy?=)
Date: Tue, 11 Jun 2019 10:24:05 +0200
Subject: [yocto] [Yocto][multilib] No Manifest file generated from:
	lib32-alsa-lib
In-Reply-To: <CAEhQi8nmgY7786+s4+u1g60-YDdbeDQBkp=Ngw3fAW5k3snSCA@mail.gmail.com>
References: <CAEhQi8=9_SmqLtsUnb8fWan+3Z2SF0gQvovts=e+GCFg88PaRg@mail.gmail.com>
	<CAEhQi8ne31nyNVjp6rD+t_t86gyWH6cuy5-mU6EFzjkicyf75Q@mail.gmail.com>
	<CAEhQi8=Z4c-jqGoAW__3mqyrkhG2HZBkP4Nt+zOGrUzTJB3oig@mail.gmail.com>
	<CAEhQi8kPOsicUCWJTeVxUxuX93YAMsz-o6WWkQpcu9O77oxHLQ@mail.gmail.com>
	<CAEhQi8kLtWNVUNB3Zy6pC5xXJ_3pvroP9_QoPQDQSXE8aOXcuw@mail.gmail.com>
	<CAEhQi8nhcSM=E3GveB4m6fqCf+dzMt6yYJHg6A3LW52uoe2pTg@mail.gmail.com>
	<CAEhQi8nmgY7786+s4+u1g60-YDdbeDQBkp=Ngw3fAW5k3snSCA@mail.gmail.com>
Message-ID: <CAEhQi8nYdKh07z5-mqtUh7vrqF0NG4vRyxo38=sAcxSS2BBxLQ@mail.gmail.com>

Adding

PACKAGE_EXTRA_ARCHS = "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}
armv7ahf-neon-mx8mm"

to my machine config solved my problem but I am not sure if it belongs
there or not.

BR

Den ons 5 juni 2019 kl 14:44 skrev M?ns Zigher <mans.zigher at gmail.com>:
>
> So it looks like I should include armv7ahf-neon-mx8mm to
> PACKAGE_EXTRA_ARCHS but I am unsure how to do that any ideas?
>
> /M?ns
>
> Den ons 5 juni 2019 kl 14:05 skrev M?ns Zigher <mans.zigher at gmail.com>:
> >
> > Looking in the env dump I can see that meta-freescale is overwriting
> > the PACKAGE_ARCH in a alsa-lib_%.bbappend
> >
> > PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}"
> >
> > /M?ns
> >
> > Den ons 5 juni 2019 kl 14:04 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > >
> > > So running bitbake -e lib32-alsa-lib I can see the following
> > >
> > > # $SSTATE_MANMACH [2 operations]
> > > #   set? /home/extzig/Workspace/mozart-workspace/layers/poky/meta/classes/sstate.bbclass:54
> > > #     "${SSTATE_PKGARCH}"
> > > #   set sstate.bbclass:94
> > > [__anon_105__home_extzig_Workspace_mozart_workspace_layers_poky_meta_classes_sstate_bbclass]
> > > #     "armv7ahf-neon-mx8mm"
> > > # pre-expansion value:
> > > #   "armv7ahf-neon-mx8mm"
> > > SSTATE_MANMACH="armv7ahf-neon-mx8mm"
> > >
> > > So first the SSTATE_MANMACH variable is set to
> > >
> > > SSTATE_MANMACH ?= "${SSTATE_PKGARCH}"
> > >
> > > at line 54 in sstate.bbclass but then it will be overwritten at line 94 to
> > >
> > > d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> > >
> > > The code that results in this looks like
> > >
> > >     if bb.data.inherits_class('native', d):
> > >         d.setVar('SSTATE_PKGARCH', d.getVar('BUILD_ARCH', False))
> > >     elif bb.data.inherits_class('crosssdk', d):
> > >         d.setVar('SSTATE_PKGARCH',
> > > d.expand("${BUILD_ARCH}_${SDK_ARCH}_${SDK_OS}"))
> > >     elif bb.data.inherits_class('cross', d):
> > >         d.setVar('SSTATE_PKGARCH', d.expand("${BUILD_ARCH}_${TARGET_ARCH}"))
> > >     elif bb.data.inherits_class('nativesdk', d):
> > >         d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${SDK_OS}"))
> > >     elif bb.data.inherits_class('cross-canadian', d):
> > >         d.setVar('SSTATE_PKGARCH', d.expand("${SDK_ARCH}_${PACKAGE_ARCH}"))
> > >     elif bb.data.inherits_class('allarch', d) and
> > > d.getVar("PACKAGE_ARCH") == "all":
> > >         d.setVar('SSTATE_PKGARCH', "allarch")
> > >     else:
> > >         d.setVar('SSTATE_MANMACH', d.expand("${PACKAGE_ARCH}"))
> > >
> > > So I guess either PACKAGE_ARCH is screwed up for alsa-lib or I should
> > > not get to that else statement.
> > >
> > > /M?ns
> > >
> > > Den ons 5 juni 2019 kl 13:39 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > >
> > > > I have the following manifest files
> > > >
> > > > find . -name "manifest*-lib32-alsa-lib*"
> > > > ./manifest-mimx8mm-lib32-alsa-lib.packagedata
> > > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package_write_rpm
> > > > ./manifest-armv7ahf-neon-mx8mm-lib32-alsa-lib.package
> > > >
> > > > but find_sstate_manifest called from package_manager
> > > >
> > > > ./meta/lib/oe/package_manager.py:615:        manifest, d2 =
> > > > oe.sstatesig.find_sstate_manifest(c, taskdepdata[dep][2], taskname, d,
> > > > multilibs)
> > > > ./meta/lib/oe/sstatesig.py:372:def find_sstate_manifest(taskdata,
> > > > taskdata2, taskname, d, multilibcache):
> > > >
> > > > will only look for
> > > >
> > > > manifest-armv7at2hf-neon-lib32-alsa-lib.package_write_rpm
> > > > manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm
> > > >
> > > > I am not sure why the mx8mm is added to the lib32-alsa-lib manifest
> > > > file since this is not added to any other package when building it for
> > > > lib32.
> > > >
> > > > /M?ns
> > > >
> > > > Den ons 5 juni 2019 kl 13:00 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > > >
> > > > > I think this looks wrong
> > > > > "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I
> > > > > have not intentionally added lib32-alsa-lib to the nativesdk part so I
> > > > > am not sure why it expects to find that?
> > > > >
> > > > > /M?ns
> > > > >
> > > > > Den ons 5 juni 2019 kl 12:46 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > > > >
> > > > > > When checking the build for lib32-alsa-lib there is no rpm package created
> > > > > >
> > > > > > deploy-rpms/armv7ahf_neon_mx8mm# ls
> > > > > > lib32-alsa-conf-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > > lib32-alsa-server-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > > lib32-libasound2-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > > lib32-libasound-dbg-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > > lib32-libasound-dev-1.1.5-r0.armv7ahf_neon_mx8mm.rpm
> > > > > >
> > > > > > it matches the alsa-lib build also when checking the list of packages by running
> > > > > >
> > > > > > oe-pkgdata-util list-pkg-files -p lib32-alsa-lib and oe-pkgdata-util
> > > > > > list-pkg-files -p alsa-lib
> > > > > >
> > > > > > there is a package lib32-alsa-lib and alsa-lib so why is there no rpm
> > > > > > for this package? I would have thought that that should be the case?
> > > > > >
> > > > > > /M?ns
> > > > > >
> > > > > > Den ons 5 juni 2019 kl 11:06 skrev M?ns Zigher <mans.zigher at gmail.com>:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I am trying to build an SDK where I have multilib enabled in my
> > > > > > > local.conf but I am encountering this error message
> > > > > > >
> > > > > > > WARNING: strix-sdk-1.0-r0 do_populate_sdk: Manifest
> > > > > > > /workdir/builds/imx8mm/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm
> > > > > > > not found in mimx8mm aarch64-mx8mm armv7at2hf-neon armv7ahf-neon
> > > > > > > armv7at2hf-vfp armv7ahf-vfp armv6thf-vfp armv6hf-vfp armv5tehf-vfp
> > > > > > > armv5ehf-vfp armv5thf-vfp armv5hf-vfp allarch x86_64_x86_64-nativesdk
> > > > > > > (variant 'lib32')?
> > > > > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: No manifest generated from:
> > > > > > > lib32-alsa-lib in
> > > > > > > virtual:multilib:lib32:/workdir/layers/poky/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> > > > > > > ERROR: strix-sdk-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
> > > > > > >
> > > > > > > I am currently using poky sumo could not see that anything have
> > > > > > > changed in alsa-lib except bumping it to 1.1.6 in thud. I have tried
> > > > > > > go through the code in both
> > > > > > >
> > > > > > > ./poky/meta/lib/oe/package_manager.py
> > > > > > >
> > > > > > > and
> > > > > > >
> > > > > > > ./poky/meta/lib/oe/sstatesig.py
> > > > > > >
> > > > > > > to see if I could understand why there is no manifest file created for
> > > > > > > lib32-alsa-lib but without any luck. What task should I run to create
> > > > > > > the Manifest file? Any other pointers to where I should look to
> > > > > > > understand this issue is appreciated.
> > > > > > >
> > > > > > > BR
> > > > > > > M?ns Zigher

From richard.purdie at linuxfoundation.org  Tue Jun 11 01:50:55 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Tue, 11 Jun 2019 09:50:55 +0100
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc2)
In-Reply-To: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
References: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
Message-ID: <b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>

On Tue, 2019-06-11 at 03:32 +0000, pokybuild at debian9-ty-1.yocto.io
wrote:
> A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
> autobuilder and is available at:
> 
> 
>     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
>

Some notes for QA:

There was a failure in this build in qemux86 oe-selftest. It looks to
be a race issue where qemu was shutting down. This needs a bug and
looking into but is a minor issue which wouldn't block the milestone
release or further QA.

There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm
(#13368). These are also not going to block the milestone release. The
bluez5 issue is gcc9 related, mdadm was exposed by wider testing in
master. The acl issue needs a bug opening and investigation as that is
a regression.

There is a lot more testing happening under automation than in previous
builds, particularly on arm hosts/targets.

Cheers,

Richard


From hongzhi.song at windriver.com  Tue Jun 11 02:14:10 2019
From: hongzhi.song at windriver.com (Hongzhi, Song)
Date: Tue, 11 Jun 2019 17:14:10 +0800
Subject: [yocto] [PATCH] umip: remove umip bbappend
In-Reply-To: <271ecb4e-c9f9-3215-30a8-c3adc8cc04ba@windriver.com>
References: <1559183012-237328-1-git-send-email-hongzhi.song@windriver.com>
	<271ecb4e-c9f9-3215-30a8-c3adc8cc04ba@windriver.com>
Message-ID: <a935bcd9-10c7-b629-c232-5b5eef1fba00@windriver.com>

ping

Thanks,

--Hongzhi


On 5/30/19 10:26 AM, Hongzhi, Song wrote:
> This patch is for meta-cgl
>
> Thanks,
>
> --Hongzhi
>
>
>
> On 5/30/19 10:23 AM, Hongzhi.Song wrote:
>> umip has been removed, so its bbappend should be removed too.
>>
>> Signed-off-by: Hongzhi.Song <hongzhi.song at windriver.com>
>> ---
>> ? meta-cgl-common/recipes-extended/umip/umip_%.bbappend | 1 -
>> ? 1 file changed, 1 deletion(-)
>> ? delete mode 100644 
>> meta-cgl-common/recipes-extended/umip/umip_%.bbappend
>>
>> diff --git a/meta-cgl-common/recipes-extended/umip/umip_%.bbappend 
>> b/meta-cgl-common/recipes-extended/umip/umip_%.bbappend
>> deleted file mode 100644
>> index 2858472..0000000
>> --- a/meta-cgl-common/recipes-extended/umip/umip_%.bbappend
>> +++ /dev/null
>> @@ -1 +0,0 @@
>> -PARALLEL_MAKE = ""

From jupiter.hce at gmail.com  Tue Jun 11 03:38:37 2019
From: jupiter.hce at gmail.com (JH)
Date: Tue, 11 Jun 2019 20:38:37 +1000
Subject: [yocto] Download git source not the latest
Message-ID: <CAA=hcWRzPWecUL0-e2hhNYE2RzjbuL9=fCLqTyy7GRFD563yGQ@mail.gmail.com>

Hi,

I set up SRCREV = "${AUTOREV}" in the recipe of my application, but
too often it downloaded the old revision. How can I force the bitbake
to download the latest git source?

Thank you.

- jupiter

From richard.purdie at linuxfoundation.org  Tue Jun 11 07:44:56 2019
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Tue, 11 Jun 2019 15:44:56 +0100
Subject: [yocto] Yocto Project Status WW24'19
Message-ID: <da8baaeff554b5fd01205d0db9d2527215a99487.camel@linuxfoundation.org>

Current Dev Position: YP 2.8 M2Next Deadline: YP 2.8 Milestone 2 Cutoff
July 14th, 2019
SWAT Team Rotation: * SWAT lead is currently: Anuj
 * SWAT team rotation: Anuj -> Paul on June 14, 2019
 * SWAT team rotation: Paul -> Ross on June 21, 2019
 * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

Next Team Meetings: * Bug Triage meeting Thursday June 13th at 7:30am
PDT (https://zoom.us/j/454367603)
 * Monthly Project Meeting Tuesday July 2nd at 8am PDT (
https://zoom.us/j/990892712) 
 * Twitch - Next event is Tuesday 11th June at 8am PDT (
https://www.twitch.tv/yocto_project)

Key Status/Updates: * 2.8 M1 has been built and rc2 is now undergoing
QA (rc1 ran into an issue with a broken autobuilder worker).
 * Stephen continues to be unavailable, please refer any queries to
Richard
 * Mailing lists are moving to groups.io instead of our current mailman
setup. This shouldn?t impact users directly, more details will be sent
to the mailing lists before the transfer. THe Yocto Project lists will
move first, followed by OE, likely a week later.
 * We have a new ?newcomer? bug category which are bugs suited to
someone new to the project. These can be seen here: 
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
 * We?re seeing an increasing number of intermittent failures which
affect the autobuilder builds, causing problems for merging patches and
for release builds. One cause, a long standing problem with gpg signing
testing has finally been root caused and fixed. Several others keep
appearing. There is a backlog of them in the bugzilla and we?re opening
bugs for the new ones.
 * M1 isn?t of ideal quality, there are three ptest timeouts (2.7 had
none). The ptest failure rate is however much improved. There is nobody
actively working on some of the ptest timeout issues so holding the
milestone build wouldn?t have made much difference but its a worrying
sign for the project quality.
 * M1 also has a couple of MIPS issues with the gcc9 upgrade. There
doesn?t appear to be much interest in investigating and fixing these
which raises questions about supporting the architecture within the
project.
 * There was a Yocto Project related article in LWN: 
https://lwn.net/Articles/788626/

Planned Releases for YP 2.8: * M1 Cutoff June 9th
 * M1 Release June 21st
 * M2 Cutoff 14th July
 * M2 Release 26th July
 * M3 Cutoff (Feature Freeze) 25th Aug
 * M3 Release 6th Sept
 * M4 Cutoff 30th Sept
 * 2.8 (M4) Final Release 25th Oct

Planned upcoming dot releases: * YP 2.6.3 (Thud) is in planning
 * YP 2.7.1 (Warrior) is in planning

Tracking Metrics: * WDD 2478 (last week 2507) (
https://wiki.yoctoproject.org/charts/combo.html)
 * Poky Patch Metrics  
    * Total patches found: 1507 (last week 1513)
    * Patches in the Pending State: 641 (43%) [last week 646 (43%)]

Key Status Links for YP:
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Statushttps://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedulehttps://wiki.yoctoproject.org/wiki/Yocto_2.8_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!]





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190611/d68c905b/attachment-0001.html>

From sangeeta.jain at intel.com  Tue Jun 11 17:51:31 2019
From: sangeeta.jain at intel.com (Jain, Sangeeta)
Date: Wed, 12 Jun 2019 00:51:31 +0000
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc2)
In-Reply-To: <b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
References: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
	<b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
Message-ID: <015AB11D45F2C442929CB2765DAE738634E32E41@PGSMSX110.gar.corp.intel.com>




>-----Original Message-----
>From: richard.purdie at linuxfoundation.org <richard.purdie at linuxfoundation.org>
>Sent: Tuesday, 11 June, 2019 4:51 PM
>To: pokybuild at debian9-ty-1.yocto.io; yocto at yoctoproject.org
>Cc: otavio at ossystems.com.br; yi.zhao at windriver.com; Sangal, Apoorv
><apoorv.sangal at intel.com>; Yeoh, Ee Peng <ee.peng.yeoh at intel.com>; Chan,
>Aaron Chun Yew <aaron.chun.yew.chan at intel.com>; Ang, Chin Huat
><chin.huat.ang at intel.com>; akuster808 at gmail.com; sjolley.yp.pm at gmail.com;
>Jain, Sangeeta <sangeeta.jain at intel.com>
>Subject: Re: QA notification for completed autobuilder build (yocto-2.8_M1.rc2)
>
>On Tue, 2019-06-11 at 03:32 +0000, pokybuild at debian9-ty-1.yocto.io
>wrote:
>> A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
>> autobuilder and is available at:
>>
>>
>>     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
>>
>
>Some notes for QA:
Thanks Richard for sharing this.
>
>There was a failure in this build in qemux86 oe-selftest. It looks to be a race issue
>where qemu was shutting down. This needs a bug and looking into but is a minor
>issue which wouldn't block the milestone release or further QA.

We are analysing the failures and will file the bugs as suggested.
>
>There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm (#13368).
>These are also not going to block the milestone release. The
>bluez5 issue is gcc9 related, mdadm was exposed by wider testing in master. The
>acl issue needs a bug opening and investigation as that is a regression.

Looks like some disconnect here. In test result report, no timeout issue reported for acl ptest.
We are referring to test results at yocto-testresults under tag " master/54573-g9910a3631ce953b8dd8f3d57d6e122c7fd8cb462/1"
>
>There is a lot more testing happening under automation than in previous builds,
>particularly on arm hosts/targets.
Thanks for increased coverage.

>
>Cheers,
>
>Richard

Thanks & Regards,
Sangeeta Jain


From yi.zhao at windriver.com  Wed Jun 12 00:53:20 2019
From: yi.zhao at windriver.com (Yi Zhao)
Date: Wed, 12 Jun 2019 15:53:20 +0800
Subject: [yocto] [meta-selinux][PATCH] glib-2.0: fix configure error for
	meson build
Message-ID: <1560326000-21130-1-git-send-email-yi.zhao@windriver.com>

In glib 2.60.x, it turns selinux into a meson feature. We should use
'-Dselinux=enabled/disabled' rather than '-Dselinux=true/false' to
enable/disable the feature.

Add meso-enable-selinux.bbclass for this change and inherit it in
glib-2.0 bbappend to fix the configure error.

Signed-off-by: Yi Zhao <yi.zhao at windriver.com>
---
 classes/meson-enable-selinux.bbclass      | 4 ++++
 recipes-core/glib-2.0/glib-2.0_%.bbappend | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)
 create mode 100644 classes/meson-enable-selinux.bbclass

diff --git a/classes/meson-enable-selinux.bbclass b/classes/meson-enable-selinux.bbclass
new file mode 100644
index 0000000..91c2a2b
--- /dev/null
+++ b/classes/meson-enable-selinux.bbclass
@@ -0,0 +1,4 @@
+inherit selinux
+
+PACKAGECONFIG_append = " ${@target_selinux(d)}"
+PACKAGECONFIG[selinux] = "-Dselinux=enabled,-Dselinux=disabled,libselinux,"
diff --git a/recipes-core/glib-2.0/glib-2.0_%.bbappend b/recipes-core/glib-2.0/glib-2.0_%.bbappend
index e5d2f6f..39a0a3a 100644
--- a/recipes-core/glib-2.0/glib-2.0_%.bbappend
+++ b/recipes-core/glib-2.0/glib-2.0_%.bbappend
@@ -1 +1 @@
-inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'meson-selinux', '', d)}
+inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'meson-enable-selinux', '', d)}
-- 
2.7.4


From richard.purdie at linuxfoundation.org  Wed Jun 12 01:04:32 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Wed, 12 Jun 2019 09:04:32 +0100
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc2)
In-Reply-To: <015AB11D45F2C442929CB2765DAE738634E32E41@PGSMSX110.gar.corp.intel.com>
References: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
	<b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
	<015AB11D45F2C442929CB2765DAE738634E32E41@PGSMSX110.gar.corp.intel.com>
Message-ID: <678b31de26a70fb63f19c7ab005dac0d681c8ff0.camel@linuxfoundation.org>

On Wed, 2019-06-12 at 00:51 +0000, Jain, Sangeeta wrote:
> On Tue, 2019-06-11 at 03:32 +0000, pokybuild at debian9-ty-1.yocto.io
> > wrote:
> > > A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
> > > autobuilder and is available at:
> > > 
> > > 
> > >     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
> > > 
> > 
> > Some notes for QA:
> Thanks Richard for sharing this.
> > There was a failure in this build in qemux86 oe-selftest. It looks
> > to be a race issue where qemu was shutting down. This needs a bug
> > and looking into but is a minor issue which wouldn't block the
> > milestone release or further QA.
> 
> We are analysing the failures and will file the bugs as suggested.

Just for reference I did file some of the bugs.

> > There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm
> > (#13368).
> > These are also not going to block the milestone release. The
> > bluez5 issue is gcc9 related, mdadm was exposed by wider testing in
> > master. The
> > acl issue needs a bug opening and investigation as that is a
> > regression.
> 
> Looks like some disconnect here. In test result report, no timeout
> issue reported for acl ptest.

https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/testresult-report.txt

acl                          | 184         | 9        | 0         | 302 T

I hadn't spotted that dbus-test also has a timeout :(.

This timeout is also in the testresults file:

ERROR: Exit status is 9\nDURATION: 302\nTIMEOUT: /usr/lib/acl/ptest\n

in:

https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/qemux86-64-ptest/testresults.json

> We are referring to test results at yocto-testresults under tag "
> master/54573-g9910a3631ce953b8dd8f3d57d6e122c7fd8cb462/1"

You are right, there is no mention of this in the log at:

http://git.yoctoproject.org/cgit.cgi/yocto-testresults/tree/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/ptest-acl.log?id=56b1caa6044ce30e92a1895eae48d3935562b627
or
http://git.yoctoproject.org/cgit.cgi/yocto-testresults/commit/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/ptest-acl.log?id=ac623e13e3bc3a348b60fe3b884e6ae567b8230a

I suspect this is due to the information being filtered out as part of
the log processing. We probably shouldn't do that.

Looking at the individual logs in https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/qemux86-64-ptest/testresults.json, the timeout information looks to be truncated off there too.

I do however note that:

            "ptestresult.sections": {
                "acl": {
                    "duration": "302",
                    "exitcode": "9",
                    "timeout": true
                },

is in http://git.yoctoproject.org/cgit.cgi/yocto-testresults/tree/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/testresults.json?id=56b1caa6044ce30e92a1895eae48d3935562b627
so the timeout is recorded in the results.

Regards,

Richard



From sangeeta.jain at intel.com  Wed Jun 12 01:38:12 2019
From: sangeeta.jain at intel.com (Jain, Sangeeta)
Date: Wed, 12 Jun 2019 08:38:12 +0000
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc2)
In-Reply-To: <678b31de26a70fb63f19c7ab005dac0d681c8ff0.camel@linuxfoundation.org>
References: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
	<b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
	<015AB11D45F2C442929CB2765DAE738634E32E41@PGSMSX110.gar.corp.intel.com>
	<678b31de26a70fb63f19c7ab005dac0d681c8ff0.camel@linuxfoundation.org>
Message-ID: <015AB11D45F2C442929CB2765DAE738634E3371C@PGSMSX110.gar.corp.intel.com>



>-----Original Message-----
>From: richard.purdie at linuxfoundation.org <richard.purdie at linuxfoundation.org>
>Sent: Wednesday, 12 June, 2019 4:05 PM
>To: Jain, Sangeeta <sangeeta.jain at intel.com>; pokybuild at debian9-ty-
>1.yocto.io; yocto at yoctoproject.org
>Cc: otavio at ossystems.com.br; yi.zhao at windriver.com; Sangal, Apoorv
><apoorv.sangal at intel.com>; Yeoh, Ee Peng <ee.peng.yeoh at intel.com>; Chan,
>Aaron Chun Yew <aaron.chun.yew.chan at intel.com>; Ang, Chin Huat
><chin.huat.ang at intel.com>; akuster808 at gmail.com; sjolley.yp.pm at gmail.com
>Subject: Re: QA notification for completed autobuilder build (yocto-2.8_M1.rc2)
>
>On Wed, 2019-06-12 at 00:51 +0000, Jain, Sangeeta wrote:
>> On Tue, 2019-06-11 at 03:32 +0000, pokybuild at debian9-ty-1.yocto.io
>> > wrote:
>> > > A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
>> > > autobuilder and is available at:
>> > >
>> > >
>> > >     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
>> > >
>> >
>> > Some notes for QA:
>> Thanks Richard for sharing this.
>> > There was a failure in this build in qemux86 oe-selftest. It looks
>> > to be a race issue where qemu was shutting down. This needs a bug
>> > and looking into but is a minor issue which wouldn't block the
>> > milestone release or further QA.
>>
>> We are analysing the failures and will file the bugs as suggested.
>
>Just for reference I did file some of the bugs.
>
>> > There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm
>> > (#13368).
>> > These are also not going to block the milestone release. The
>> > bluez5 issue is gcc9 related, mdadm was exposed by wider testing in
>> > master. The acl issue needs a bug opening and investigation as that
>> > is a regression.
>>
>> Looks like some disconnect here. In test result report, no timeout
>> issue reported for acl ptest.
>
>https://autobuilder.yocto.io/pub/releases/yocto-
>2.8_M1.rc2/testresults/testresult-report.txt
>
>acl                          | 184         | 9        | 0         | 302 T
>
>I hadn't spotted that dbus-test also has a timeout :(.
>
>This timeout is also in the testresults file:
>
>ERROR: Exit status is 9\nDURATION: 302\nTIMEOUT: /usr/lib/acl/ptest\n
>
>in:
>
>https://autobuilder.yocto.io/pub/releases/yocto-
>2.8_M1.rc2/testresults/qemux86-64-ptest/testresults.json
>
>> We are referring to test results at yocto-testresults under tag "
>> master/54573-g9910a3631ce953b8dd8f3d57d6e122c7fd8cb462/1"
>
>You are right, there is no mention of this in the log at:
>
>http://git.yoctoproject.org/cgit.cgi/yocto-
>testresults/tree/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/ptest-
>acl.log?id=56b1caa6044ce30e92a1895eae48d3935562b627
>or
>http://git.yoctoproject.org/cgit.cgi/yocto-
>testresults/commit/runtime/poky/qemux86-64/core-image-sato-sdk-ptest/ptest-
>acl.log?id=ac623e13e3bc3a348b60fe3b884e6ae567b8230a
>
>I suspect this is due to the information being filtered out as part of the log
>processing. We probably shouldn't do that.
>
>Looking at the individual logs in https://autobuilder.yocto.io/pub/releases/yocto-
>2.8_M1.rc2/testresults/qemux86-64-ptest/testresults.json, the timeout
>information looks to be truncated off there too.
>
>I do however note that:
>
>            "ptestresult.sections": {
>                "acl": {
>                    "duration": "302",
>                    "exitcode": "9",
>                    "timeout": true
>                },
>
>is in http://git.yoctoproject.org/cgit.cgi/yocto-
>testresults/tree/runtime/poky/qemux86-64/core-image-sato-sdk-
>ptest/testresults.json?id=56b1caa6044ce30e92a1895eae48d3935562b627
>so the timeout is recorded in the results.

Thanks. Able to trace all time-out issues, including dbus-test !
>
>Regards,
>
>Richard
>

Thanks & Regards,
Sangeeta Jain

From richard.purdie at linuxfoundation.org  Wed Jun 12 02:47:18 2019
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Wed, 12 Jun 2019 10:47:18 +0100
Subject: [yocto] Download git source not the latest
In-Reply-To: <CAA=hcWRzPWecUL0-e2hhNYE2RzjbuL9=fCLqTyy7GRFD563yGQ@mail.gmail.com>
References: <CAA=hcWRzPWecUL0-e2hhNYE2RzjbuL9=fCLqTyy7GRFD563yGQ@mail.gmail.com>
Message-ID: <2c0a96e74f3acf0ac45f2bc55908df330fd85cab.camel@linuxfoundation.org>

On Tue, 2019-06-11 at 20:38 +1000, JH wrote:
> Hi,
> 
> I set up SRCREV = "${AUTOREV}" in the recipe of my application, but
> too often it downloaded the old revision. How can I force the bitbake
> to download the latest git source?

What did you set PV to?

You need to have SRCPV in PV for autorev to work properly.

Regards,

Richard


From alex.kanavin at gmail.com  Wed Jun 12 03:03:49 2019
From: alex.kanavin at gmail.com (Alexander Kanavin)
Date: Wed, 12 Jun 2019 12:03:49 +0200
Subject: [yocto] [meta-selinux][PATCH] glib-2.0: fix configure error for
 meson build
In-Reply-To: <1560326000-21130-1-git-send-email-yi.zhao@windriver.com>
References: <1560326000-21130-1-git-send-email-yi.zhao@windriver.com>
Message-ID: <CANNYZj_7JUwUu0WgtRS2C_bR8thJPDMwWvBg74cCKw763Lq6Vw@mail.gmail.com>

On Wed, 12 Jun 2019 at 09:54, Yi Zhao <yi.zhao at windriver.com> wrote:

> +PACKAGECONFIG[selinux] =
> "-Dselinux=enabled,-Dselinux=disabled,libselinux,"
>

This line should probably go into the oe-core recipe? It is fine to have
options that depend on things absent in oe-core, as long as those options
are disabled by default.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190612/302bd9d7/attachment.html>

From zoran.stojsavljevic at gmail.com  Wed Jun 12 03:58:51 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Wed, 12 Jun 2019 12:58:51 +0200
Subject: [yocto] [current stable poky kernel] linux-stable-5.0.21-r0
Message-ID: <CAGAf8LzGyxg63e19mWJT6rqOy5jv4vUs4-Py=872aWT5DPHHOA@mail.gmail.com>

Hello to all,

I did (an hour ago) quick git pull on the several git repos for my BBB
target platform.

But I still see that the poky kernel is still one of 5.0 series! Why?
There are already well known stable kernels series 5.1 (5.1.9).

Please, check kernel.org: https://www.kernel.org/

What is the problem (if any)? As I found building kernels of 5.1
series with built-in kernel source tree, there is a mismatch with the
/meta/recipes-kernel/lttng/ lttng package?!

Please, advise?

Thank you,
Zoran

From yi.zhao at windriver.com  Wed Jun 12 17:06:40 2019
From: yi.zhao at windriver.com (Yi Zhao)
Date: Thu, 13 Jun 2019 08:06:40 +0800
Subject: [yocto] [meta-selinux][PATCH] glib-2.0: fix configure error for
 meson build
In-Reply-To: <CANNYZj_7JUwUu0WgtRS2C_bR8thJPDMwWvBg74cCKw763Lq6Vw@mail.gmail.com>
References: <1560326000-21130-1-git-send-email-yi.zhao@windriver.com>
	<CANNYZj_7JUwUu0WgtRS2C_bR8thJPDMwWvBg74cCKw763Lq6Vw@mail.gmail.com>
Message-ID: <d27d5cb3-44be-796b-1bf5-f36d9726712c@windriver.com>


On 6/12/19 6:03 PM, Alexander Kanavin wrote:
> On Wed, 12 Jun 2019 at 09:54, Yi Zhao <yi.zhao at windriver.com 
> <mailto:yi.zhao at windriver.com>> wrote:
>
>     +PACKAGECONFIG[selinux] =
>     "-Dselinux=enabled,-Dselinux=disabled,libselinux,"
>
>
> This line should probably go into the oe-core recipe? It is fine to 
> have options that depend on things absent in oe-core, as long as those 
> options are disabled by default.


Thanks. I will test it and send a patch to oe-core


//Yi

>
> Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190613/e17e8005/attachment.html>

From leimaohui at cn.fujitsu.com  Wed Jun 12 20:02:46 2019
From: leimaohui at cn.fujitsu.com (Lei, Maohui)
Date: Thu, 13 Jun 2019 03:02:46 +0000
Subject: [yocto] [meta-security][PATCH] python3-fail2ban: Fix build
 error of xrange.
In-Reply-To: <1555646319-7243-1-git-send-email-leimaohui@cn.fujitsu.com>
References: <1555646319-7243-1-git-send-email-leimaohui@cn.fujitsu.com>
Message-ID: <1B56A49860EB2D45ADE3731B15C959FD01BF12B4A2@G08CNEXMBPEKD01.g08.fujitsu.local>

Hi,

Please merge this patch to warrior branch.

Best regards
Lei

> -----Original Message-----
> From: Lei, Maohui
> Sent: Friday, April 19, 2019 11:59 AM
> To: yocto at yoctoproject.org
> Cc: Lei, Maohui
> Subject: [yocto] [meta-security][PATCH] python3-fail2ban: Fix build error of
> xrange.
> 
> NameError: name 'xrange' is not defined
> 
> Signed-off-by: Lei Maohui <leimaohui at cn.fujitsu.com>
> ---
>  .../files/0001-To-fix-build-error-of-xrang.patch   | 28 ++++++++++++++++++++++
>  .../fail2ban/python3-fail2ban_0.10.4.0.bb          |  4 ++++
>  2 files changed, 32 insertions(+)
>  create mode 100644 recipes-security/fail2ban/files/0001-To-fix-build-error-of-
> xrang.patch
> 
> diff --git a/recipes-security/fail2ban/files/0001-To-fix-build-error-of-
> xrang.patch b/recipes-security/fail2ban/files/0001-To-fix-build-error-of-
> xrang.patch
> new file mode 100644
> index 0000000..7f0812c
> --- /dev/null
> +++ b/recipes-security/fail2ban/files/0001-To-fix-build-error-of-xrang.patch
> @@ -0,0 +1,28 @@
> +From fe3436d65518099d35c643848cba50253abc249c Mon Sep 17 00:00:00 2001
> +From: Lei Maohui <leimaohui at cn.fujitsu.com>
> +Date: Thu, 9 May 2019 14:44:51 +0900
> +Subject: [PATCH] To fix build error of xrange.
> +
> +NameError: name 'xrange' is not defined
> +
> +Signed-off-by: Lei Maohui <leimaohui at cn.fujitsu.com>
> +---
> + fail2ban/__init__.py | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/fail2ban/__init__.py b/fail2ban/__init__.py
> +index fa6dcf7..61789a4 100644
> +--- a/fail2ban/__init__.py
> ++++ b/fail2ban/__init__.py
> +@@ -82,7 +82,7 @@ strptime("2012", "%Y")
> +
> + # short names for pure numeric log-level ("Level 25" could be truncated by
> short formats):
> + def _init():
> +-	for i in xrange(50):
> ++	for i in range(50):
> + 		if logging.getLevelName(i).startswith('Level'):
> + 			logging.addLevelName(i, '#%02d-Lev.' % i)
> + _init()
> +--
> +2.7.4
> +
> diff --git a/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb b/recipes-
> security/fail2ban/python3-fail2ban_0.10.4.0.bb
> index 5c887e8..23ef027 100644
> --- a/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
> +++ b/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
> @@ -2,3 +2,7 @@ inherit setuptools3
>  require python-fail2ban.inc
> 
>  RDEPENDS_${PN}-ptest = "python3-core python3-io python3-modules python3-
> fail2ban"
> +
> +SRC_URI += " \
> +        file://0001-To-fix-build-error-of-xrang.patch \
> +"
> --
> 2.7.4




From zangrc.fnst at cn.fujitsu.com  Wed Jun 12 20:24:16 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Thu, 13 Jun 2019 11:24:16 +0800
Subject: [yocto] [meta-security][master][PATCH 1/2] python-fail2ban: solved
	the conflict with python3-fail2ban
In-Reply-To: <20190613032417.9855-1-zangrc.fnst@cn.fujitsu.com>
References: <20190613032417.9855-1-zangrc.fnst@cn.fujitsu.com>
Message-ID: <20190613032417.9855-2-zangrc.fnst@cn.fujitsu.com>

-Use update-alternatives class to resolve conflicts with python3-fail2ban.

Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
---
 recipes-security/fail2ban/python-fail2ban_0.10.4.0.bb | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/recipes-security/fail2ban/python-fail2ban_0.10.4.0.bb b/recipes-security/fail2ban/python-fail2ban_0.10.4.0.bb
index 17a7dd8..3eea365 100644
--- a/recipes-security/fail2ban/python-fail2ban_0.10.4.0.bb
+++ b/recipes-security/fail2ban/python-fail2ban_0.10.4.0.bb
@@ -1,4 +1,13 @@
-inherit setuptools
+inherit setuptools update-alternatives
 require python-fail2ban.inc
 
 RDEPENDS_${PN}-ptest = "python python-modules python-fail2ban"
+
+ALTERNATIVE_${PN} = "fail2ban-client fail2ban-regex fail2ban-server fail2ban-testcases"
+
+ALTERNATIVE_TARGET[fail2ban-client] = "${bindir}/fail2ban-client"
+ALTERNATIVE_TARGET[fail2ban-regex] = "${bindir}/fail2ban-regex"
+ALTERNATIVE_TARGET[fail2ban-server] = "${bindir}/fail2ban-server"
+ALTERNATIVE_TARGET[fail2ban-testcases] = "${bindir}/fail2ban-testcases"
+
+ALTERNATIVE_PRIORITY = "30"
-- 
2.20.1




From zangrc.fnst at cn.fujitsu.com  Wed Jun 12 20:24:15 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Thu, 13 Jun 2019 11:24:15 +0800
Subject: [yocto] [meta-security][master][PATCH 0/2] python-fail2ban: solved
	the conflict with python3-fail2ban
Message-ID: <20190613032417.9855-1-zangrc.fnst@cn.fujitsu.com>

-Use the update-alternatives class to resolve conflicts.

Zang Ruochen (2):
  [yocto][meta-security][master][PATCH 1/2] python-fail2ban: solved
    the conflict with python3-fail2ban
  [yocto][meta-security][master][PATCH 2/2] python3-fail2ban:
    solved the conflict with python-fail2ban

 recipes-security/fail2ban/python-fail2ban_0.10.4.0.bb | 11 ++++++++++-
 .../fail2ban/python3-fail2ban_0.10.4.0.bb             | 10 +++++++++-
 2 files changed, 19 insertions(+), 2 deletions(-)

-- 
2.20.1




From zangrc.fnst at cn.fujitsu.com  Wed Jun 12 20:24:17 2019
From: zangrc.fnst at cn.fujitsu.com (Zang Ruochen)
Date: Thu, 13 Jun 2019 11:24:17 +0800
Subject: [yocto] [meta-security][master][PATCH 2/2] python3-fail2ban: solved
	the conflict with python-fail2ban
In-Reply-To: <20190613032417.9855-1-zangrc.fnst@cn.fujitsu.com>
References: <20190613032417.9855-1-zangrc.fnst@cn.fujitsu.com>
Message-ID: <20190613032417.9855-3-zangrc.fnst@cn.fujitsu.com>

-Use update-alternatives class to resolve conflicts with python-fail2ban

Signed-off-by: Zang Ruochen <zangrc.fnst at cn.fujitsu.com>
---
 recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb b/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
index 23ef027..e01482c 100644
--- a/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
+++ b/recipes-security/fail2ban/python3-fail2ban_0.10.4.0.bb
@@ -1,4 +1,4 @@
-inherit setuptools3
+inherit setuptools3 update-alternatives
 require python-fail2ban.inc
 
 RDEPENDS_${PN}-ptest = "python3-core python3-io python3-modules python3-fail2ban"
@@ -6,3 +6,11 @@ RDEPENDS_${PN}-ptest = "python3-core python3-io python3-modules python3-fail2ban
 SRC_URI += " \
         file://0001-To-fix-build-error-of-xrang.patch \
 "
+
+ALTERNATIVE_${PN} = "fail2ban-client fail2ban-regex fail2ban-server fail2ban-testcases"
+ALTERNATIVE_TARGET[fail2ban-client] = "${bindir}/fail2ban-client"
+ALTERNATIVE_TARGET[fail2ban-regex] = "${bindir}/fail2ban-regex"
+ALTERNATIVE_TARGET[fail2ban-server] = "${bindir}/fail2ban-server"
+ALTERNATIVE_TARGET[fail2ban-testcases] = "${bindir}/fail2ban-testcases"
+
+ALTERNATIVE_PRIORITY = "60"
-- 
2.20.1




From sangeeta.jain at intel.com  Wed Jun 12 21:08:56 2019
From: sangeeta.jain at intel.com (Jain, Sangeeta)
Date: Thu, 13 Jun 2019 04:08:56 +0000
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc2)
In-Reply-To: <b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
References: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
	<b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
Message-ID: <015AB11D45F2C442929CB2765DAE738634E36081@PGSMSX110.gar.corp.intel.com>

Hello All,

Intel and WR YP QA is now working on QA execution for YP build 2.8 M1 RC2.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:

1. OE-Core
2. BSP-hw
3. BSP-Qemu

Runtime auto test for following platforms:

1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. MPC8315e-rdb
7. Beaglebone

ETA for completion is Friday, 15 June.


Thanks & Regards,
Sangeeta Jain

>-----Original Message-----
>From: richard.purdie at linuxfoundation.org <richard.purdie at linuxfoundation.org>
>Sent: Tuesday, 11 June, 2019 4:51 PM
>To: pokybuild at debian9-ty-1.yocto.io; yocto at yoctoproject.org
>Cc: otavio at ossystems.com.br; yi.zhao at windriver.com; Sangal, Apoorv
><apoorv.sangal at intel.com>; Yeoh, Ee Peng <ee.peng.yeoh at intel.com>; Chan,
>Aaron Chun Yew <aaron.chun.yew.chan at intel.com>; Ang, Chin Huat
><chin.huat.ang at intel.com>; akuster808 at gmail.com; sjolley.yp.pm at gmail.com;
>Jain, Sangeeta <sangeeta.jain at intel.com>
>Subject: Re: QA notification for completed autobuilder build (yocto-2.8_M1.rc2)
>
>On Tue, 2019-06-11 at 03:32 +0000, pokybuild at debian9-ty-1.yocto.io
>wrote:
>> A build flagged for QA (yocto-2.8_M1.rc2) was completed on the
>> autobuilder and is available at:
>>
>>
>>     https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2
>>
>
>Some notes for QA:
>
>There was a failure in this build in qemux86 oe-selftest. It looks to be a race issue
>where qemu was shutting down. This needs a bug and looking into but is a minor
>issue which wouldn't block the milestone release or further QA.
>
>There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm (#13368).
>These are also not going to block the milestone release. The
>bluez5 issue is gcc9 related, mdadm was exposed by wider testing in master. The
>acl issue needs a bug opening and investigation as that is a regression.
>
>There is a lot more testing happening under automation than in previous builds,
>particularly on arm hosts/targets.
>
>Cheers,
>
>Richard


From changqing.li at windriver.com  Thu Jun 13 00:45:25 2019
From: changqing.li at windriver.com (changqing.li at windriver.com)
Date: Thu, 13 Jun 2019 15:45:25 +0800
Subject: [yocto] [PATCH 1/2] patchtest: fix virtio-9p-pci is not a valid
	device
Message-ID: <1560411926-231994-1-git-send-email-changqing.li@windriver.com>

From: Changqing Li <changqing.li at windriver.com>

fix error during runqemu:
test_mount: 'virtio-9p-pci' is not a valid device model name

recipe qemu has been splited into qemu/qemu-native/qemu-sytem-native

Signed-off-by: Changqing Li <changqing.li at windriver.com>
---
 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend | 1 +
 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend               | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
 delete mode 100644 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend

diff --git a/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
new file mode 100644
index 0000000..a91ccb7
--- /dev/null
+++ b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
@@ -0,0 +1 @@
+PACKAGECONFIG_append = " virtfs"
diff --git a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
deleted file mode 100644
index 3ad9f03..0000000
--- a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-PACKAGECONFIG_append_pn-qemu-native = " virtfs"
-- 
2.7.4


From changqing.li at windriver.com  Thu Jun 13 00:46:03 2019
From: changqing.li at windriver.com (changqing.li at windriver.com)
Date: Thu, 13 Jun 2019 15:46:03 +0800
Subject: [yocto] [patchtest][PATCH 1/2] patchtest: fix virtio-9p-pci is not
	a valid device
Message-ID: <1560411964-388665-1-git-send-email-changqing.li@windriver.com>

From: Changqing Li <changqing.li at windriver.com>

fix error during runqemu:
test_mount: 'virtio-9p-pci' is not a valid device model name

recipe qemu has been splited into qemu/qemu-native/qemu-sytem-native

Signed-off-by: Changqing Li <changqing.li at windriver.com>
---
 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend | 1 +
 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend               | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100644 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
 delete mode 100644 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend

diff --git a/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
new file mode 100644
index 0000000..a91ccb7
--- /dev/null
+++ b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
@@ -0,0 +1 @@
+PACKAGECONFIG_append = " virtfs"
diff --git a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
deleted file mode 100644
index 3ad9f03..0000000
--- a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-PACKAGECONFIG_append_pn-qemu-native = " virtfs"
-- 
2.7.4


From changqing.li at windriver.com  Thu Jun 13 00:46:04 2019
From: changqing.li at windriver.com (changqing.li at windriver.com)
Date: Thu, 13 Jun 2019 15:46:04 +0800
Subject: [yocto] [patchtest][PATCH 2/2] patchtest: fix linux-yocto version
In-Reply-To: <1560411964-388665-1-git-send-email-changqing.li@windriver.com>
References: <1560411964-388665-1-git-send-email-changqing.li@windriver.com>
Message-ID: <1560411964-388665-2-git-send-email-changqing.li@windriver.com>

From: Changqing Li <changqing.li at windriver.com>

4.9 is not avaiable currently, preferred version changed
to 5.0, also correct the bbappend name

Signed-off-by: Changqing Li <changqing.li at windriver.com>
---
 .../linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend}       | 0
 scripts/create-guest-machine                                         | 5 +----
 2 files changed, 1 insertion(+), 4 deletions(-)
 rename meta-patchtest/recipes-kernel/linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} (100%)

diff --git a/meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend b/meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
similarity index 100%
rename from meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
diff --git a/scripts/create-guest-machine b/scripts/create-guest-machine
index 8dd6a2e..151d5c2 100755
--- a/scripts/create-guest-machine
+++ b/scripts/create-guest-machine
@@ -145,10 +145,7 @@ cat >> $POKY/build/conf/auto.conf << EOF
 $PTSMARK
 MACHINE = "$MACHINE"
 
-# The preferred kernel version in poky (4.10%, master) returns an error whilst
-# executing patchtest on guest. Changing the preferred version to 4.9% as it
-# is more suitable and does not present any errors.
-PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
+PREFERRED_VERSION_linux-yocto_qemux86-64 = "5.0%"
 
 PACKAGE_CLASSES = "package_ipk"
 IMAGE_FSTYPES = "ext4"
-- 
2.7.4


From yocto.user.mailinglist at gmail.com  Thu Jun 13 00:55:09 2019
From: yocto.user.mailinglist at gmail.com (Robert Berger)
Date: Thu, 13 Jun 2019 10:55:09 +0300
Subject: [yocto] [autobuilder] Y-AB in a docker container?
Message-ID: <e16f922e-947b-ee4f-01a5-ed87d1aa25b6@gmail.com>

Hi,

I use the good old yocto autobuilder in a docker container and it still 
serves me well, but I would like to move to the shiny new yocto autobuilder.

Before I start spending hours to do it myself I wonder if someone 
already did something like this and is willing to share the Dockerfile(s).

Regards,

Robert

From changqing.li at windriver.com  Thu Jun 13 01:02:28 2019
From: changqing.li at windriver.com (Changqing Li)
Date: Thu, 13 Jun 2019 16:02:28 +0800
Subject: [yocto] [PATCH 1/2] patchtest: fix virtio-9p-pci is not a valid
 device
In-Reply-To: <1560411926-231994-1-git-send-email-changqing.li@windriver.com>
References: <1560411926-231994-1-git-send-email-changqing.li@windriver.com>
Message-ID: <69b6adbd-a764-ce5c-9551-6ce5d57e3138@windriver.com>

Please ignore this one, I resend one.

On 6/13/19 3:45 PM, changqing.li at windriver.com wrote:
> From: Changqing Li <changqing.li at windriver.com>
>
> fix error during runqemu:
> test_mount: 'virtio-9p-pci' is not a valid device model name
>
> recipe qemu has been splited into qemu/qemu-native/qemu-sytem-native
>
> Signed-off-by: Changqing Li <changqing.li at windriver.com>
> ---
>   meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend | 1 +
>   meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend               | 1 -
>   2 files changed, 1 insertion(+), 1 deletion(-)
>   create mode 100644 meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
>   delete mode 100644 meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
>
> diff --git a/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
> new file mode 100644
> index 0000000..a91ccb7
> --- /dev/null
> +++ b/meta-patchtest/recipes-devtools/qemu/qemu-system-native_%.bbappend
> @@ -0,0 +1 @@
> +PACKAGECONFIG_append = " virtfs"
> diff --git a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend b/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
> deleted file mode 100644
> index 3ad9f03..0000000
> --- a/meta-patchtest/recipes-devtools/qemu/qemu_%.bbappend
> +++ /dev/null
> @@ -1 +0,0 @@
> -PACKAGECONFIG_append_pn-qemu-native = " virtfs"

-- 
BRs

Sandy(Li Changqing)


From bunk at stusta.de  Thu Jun 13 01:29:31 2019
From: bunk at stusta.de (Adrian Bunk)
Date: Thu, 13 Jun 2019 11:29:31 +0300
Subject: [yocto] [patchtest][PATCH 2/2] patchtest: fix linux-yocto
	version
In-Reply-To: <1560411964-388665-2-git-send-email-changqing.li@windriver.com>
References: <1560411964-388665-1-git-send-email-changqing.li@windriver.com>
	<1560411964-388665-2-git-send-email-changqing.li@windriver.com>
Message-ID: <20190613082931.GA15674@localhost>

On Thu, Jun 13, 2019 at 03:46:04PM +0800, changqing.li at windriver.com wrote:
> From: Changqing Li <changqing.li at windriver.com>
> 
> 4.9 is not avaiable currently, preferred version changed
> to 5.0, also correct the bbappend name

5.0 is already EOL upstream and will be removed soon.

>...
> --- a/scripts/create-guest-machine
> +++ b/scripts/create-guest-machine
> @@ -145,10 +145,7 @@ cat >> $POKY/build/conf/auto.conf << EOF
>  $PTSMARK
>  MACHINE = "$MACHINE"
>  
> -# The preferred kernel version in poky (4.10%, master) returns an error whilst
> -# executing patchtest on guest. Changing the preferred version to 4.9% as it
> -# is more suitable and does not present any errors.
> -PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
> +PREFERRED_VERSION_linux-yocto_qemux86-64 = "5.0%"
>...

This looks as if it was a temporary workaround for some problem with 
kernel 4.10.

If 5.0 works, then there is not really a reason for changing the 
preferred version here.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


From changqing.li at windriver.com  Thu Jun 13 01:36:49 2019
From: changqing.li at windriver.com (Changqing Li)
Date: Thu, 13 Jun 2019 16:36:49 +0800
Subject: [yocto] [patchtest][PATCH 2/2] patchtest: fix linux-yocto
	version
In-Reply-To: <20190613082931.GA15674@localhost>
References: <1560411964-388665-1-git-send-email-changqing.li@windriver.com>
	<1560411964-388665-2-git-send-email-changqing.li@windriver.com>
	<20190613082931.GA15674@localhost>
Message-ID: <fa6fc473-ffc7-858c-3cf5-ef0e24f4ebe8@windriver.com>


On 6/13/19 4:29 PM, Adrian Bunk wrote:
> On Thu, Jun 13, 2019 at 03:46:04PM +0800, changqing.li at windriver.com wrote:
>> From: Changqing Li <changqing.li at windriver.com>
>>
>> 4.9 is not avaiable currently, preferred version changed
>> to 5.0, also correct the bbappend name
> 5.0 is already EOL upstream and will be removed soon.
>
>> ...
>> --- a/scripts/create-guest-machine
>> +++ b/scripts/create-guest-machine
>> @@ -145,10 +145,7 @@ cat >> $POKY/build/conf/auto.conf << EOF
>>   $PTSMARK
>>   MACHINE = "$MACHINE"
>>   
>> -# The preferred kernel version in poky (4.10%, master) returns an error whilst
>> -# executing patchtest on guest. Changing the preferred version to 4.9% as it
>> -# is more suitable and does not present any errors.
>> -PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
>> +PREFERRED_VERSION_linux-yocto_qemux86-64 = "5.0%"
>> ...
> This looks as if it was a temporary workaround for some problem with
> kernel 4.10.
>
> If 5.0 works, then there is not really a reason for changing the
> preferred version here.
Thanks, I will remove this line.
>
> cu
> Adrian
>
-- 
BRs

Sandy(Li Changqing)


From changqing.li at windriver.com  Thu Jun 13 02:16:20 2019
From: changqing.li at windriver.com (changqing.li at windriver.com)
Date: Thu, 13 Jun 2019 17:16:20 +0800
Subject: [yocto] [patchtest][PATCH V2] patchtest: fix linux-yocto version
In-Reply-To: <20190613082931.GA15674@localhost>
References: <20190613082931.GA15674@localhost>
Message-ID: <1560417380-358445-1-git-send-email-changqing.li@windriver.com>

From: Changqing Li <changqing.li at windriver.com>

4.9 is not avaiable currently, so remove version from bbappend
and remove PREFERRED_VERSION.

Signed-off-by: Changqing Li <changqing.li at windriver.com>
---
 .../linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend}       | 0
 scripts/create-guest-machine                                         | 5 -----
 2 files changed, 5 deletions(-)
 rename meta-patchtest/recipes-kernel/linux/{linux-yocto_4.%.bbappend => linux-yocto_%.bbappend} (100%)

diff --git a/meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend b/meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
similarity index 100%
rename from meta-patchtest/recipes-kernel/linux/linux-yocto_4.%.bbappend
rename to meta-patchtest/recipes-kernel/linux/linux-yocto_%.bbappend
diff --git a/scripts/create-guest-machine b/scripts/create-guest-machine
index 8dd6a2e..8381ef8 100755
--- a/scripts/create-guest-machine
+++ b/scripts/create-guest-machine
@@ -145,11 +145,6 @@ cat >> $POKY/build/conf/auto.conf << EOF
 $PTSMARK
 MACHINE = "$MACHINE"
 
-# The preferred kernel version in poky (4.10%, master) returns an error whilst
-# executing patchtest on guest. Changing the preferred version to 4.9% as it
-# is more suitable and does not present any errors.
-PREFERRED_VERSION_linux-yocto_qemux86-64 = "4.9%"
-
 PACKAGE_CLASSES = "package_ipk"
 IMAGE_FSTYPES = "ext4"
 SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/dev/PATH"
-- 
2.7.4


From jupiter.hce at gmail.com  Thu Jun 13 03:56:57 2019
From: jupiter.hce at gmail.com (JH)
Date: Thu, 13 Jun 2019 20:56:57 +1000
Subject: [yocto] Download git source not the latest
In-Reply-To: <2c0a96e74f3acf0ac45f2bc55908df330fd85cab.camel@linuxfoundation.org>
References: <CAA=hcWRzPWecUL0-e2hhNYE2RzjbuL9=fCLqTyy7GRFD563yGQ@mail.gmail.com>
	<2c0a96e74f3acf0ac45f2bc55908df330fd85cab.camel@linuxfoundation.org>
Message-ID: <CAA=hcWRWf-JC3Mg2kmTJ22YjiQto0ixpfNUrnzdbn172nnDE0w@mail.gmail.com>

I set up for my release version which is nothing to do with the git
source, how could I link the PV to autorev?

VERSION_MAJOR = "1"
VERSION_MINOR = "0"
VERSION_BUILD = "0"
PV = "${VERSION_MAJOR}.${VERSION_MINOR}.${VERSION_BUILD}"

Thanks Richard,

- jupiter

On 6/12/19, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:
> On Tue, 2019-06-11 at 20:38 +1000, JH wrote:
>> Hi,
>>
>> I set up SRCREV = "${AUTOREV}" in the recipe of my application, but
>> too often it downloaded the old revision. How can I force the bitbake
>> to download the latest git source?
>
> What did you set PV to?
>
> You need to have SRCPV in PV for autorev to work properly.
>
> Regards,
>
> Richard
>
>

From jupiter.hce at gmail.com  Thu Jun 13 04:34:42 2019
From: jupiter.hce at gmail.com (JH)
Date: Thu, 13 Jun 2019 21:34:42 +1000
Subject: [yocto] Command to make zimage to ramdisk format
Message-ID: <CAA=hcWQQD-zc9LxQ5ft0fzUEuX-9wwA=rvjtVwoMRmCAG=Xfew@mail.gmail.com>

Hi,

I built the Yocto images:

dev-image-20190528085324.rootfs.wic.gz
zImage--xxxx.bin

I need to build zImage to ramdisk to run it on RAM in development.
What is the correct mkimage command can be used for add ramdisk to the
zimage?

$ mkimage -A arm -T ramdisk -C none -n uInitrd -d /path/to/initrd.img
/path/to/uInitrd

Thank you.

Kind regards,

- JH

From zoran.stojsavljevic at gmail.com  Thu Jun 13 05:33:01 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Thu, 13 Jun 2019 14:33:01 +0200
Subject: [yocto] Command to make zimage to ramdisk format
In-Reply-To: <CAA=hcWQQD-zc9LxQ5ft0fzUEuX-9wwA=rvjtVwoMRmCAG=Xfew@mail.gmail.com>
References: <CAA=hcWQQD-zc9LxQ5ft0fzUEuX-9wwA=rvjtVwoMRmCAG=Xfew@mail.gmail.com>
Message-ID: <CAGAf8Lzw+fe91ei+qcyO28030pCx5XWj0=ZXpVu7Og0yRQSC=w@mail.gmail.com>

Here is what you need (my best guess):
https://lists.yoctoproject.org/pipermail/yocto/2018-July/041680.html

Please, read carefully this thread.

Zoran
_______


On Thu, Jun 13, 2019 at 1:35 PM JH <jupiter.hce at gmail.com> wrote:
>
> Hi,
>
> I built the Yocto images:
>
> dev-image-20190528085324.rootfs.wic.gz
> zImage--xxxx.bin
>
> I need to build zImage to ramdisk to run it on RAM in development.
> What is the correct mkimage command can be used for add ramdisk to the
> zimage?
>
> $ mkimage -A arm -T ramdisk -C none -n uInitrd -d /path/to/initrd.img
> /path/to/uInitrd
>
> Thank you.
>
> Kind regards,
>
> - JH
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From wmills at ti.com  Thu Jun 13 07:31:31 2019
From: wmills at ti.com (William Mills)
Date: Thu, 13 Jun 2019 10:31:31 -0400
Subject: [yocto] YP sstate example conf file
Message-ID: <8f5ed5e0-c695-4db9-40dc-2075daa1210d@ti.com>

Hello,

>From poky warrior tip, file meta-poky/conf/local.conf.sample
"""
#
#SSTATE_MIRRORS ?= "file://.*
http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"
"""

Should that be 2.7??  Or are you relying on the intelligence of the user
to fix this up?

If the former then it needs to go on a checklist.
If the later then perhaps it would be better to use X.Y or something
that does not appear to work.  Some verbage to suggest the edit would
probably be good as well.

(and no, I did not run it like that. I'm slightly smarted than that.)

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample?h=warrior#n235

Thanks,
Bill

----------------
William A. Mills
Chief Technologist, Open Solutions, SDO
Texas Instruments, Inc.
20450 Century Blvd
Germantown MD 20878
240-643-0836

From martin.jansa at gmail.com  Thu Jun 13 07:46:24 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Thu, 13 Jun 2019 16:46:24 +0200
Subject: [yocto] YP sstate example conf file
In-Reply-To: <8f5ed5e0-c695-4db9-40dc-2075daa1210d@ti.com>
References: <8f5ed5e0-c695-4db9-40dc-2075daa1210d@ti.com>
Message-ID: <CA+chaQeT90YznR2uoxLZ9ioLFY5g-Vc3URTXycHBwiqnYMmCDQ@mail.gmail.com>

Good question.

I've one related to this as well.

It would be also good to document (if it isn't somewhere already) what
builds populate this mirror.

I assume it will be some autobuilder job with DISTRO = poky, but without
file listing enabled over http I cannot even guess which MACHINEs were
included.

It would be useful to provide one tarball with all sigdata files, which
could be manually downloaded to check what's available there and to debug
why the sstate cache from this mirror wasn't reused in local build.

Cheers,

On Thu, Jun 13, 2019 at 4:32 PM William Mills <wmills at ti.com> wrote:

> Hello,
>
> From poky warrior tip, file meta-poky/conf/local.conf.sample
> """
> #
> #SSTATE_MIRRORS ?= "file://.*
> http://sstate.yoctoproject.org/2.5/PATH;downloadfilename=PATH"
> """
>
> Should that be 2.7??  Or are you relying on the intelligence of the user
> to fix this up?
>
> If the former then it needs to go on a checklist.
> If the later then perhaps it would be better to use X.Y or something
> that does not appear to work.  Some verbage to suggest the edit would
> probably be good as well.
>
> (and no, I did not run it like that. I'm slightly smarted than that.)
>
>
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/local.conf.sample?h=warrior#n235
>
> Thanks,
> Bill
>
> ----------------
> William A. Mills
> Chief Technologist, Open Solutions, SDO
> Texas Instruments, Inc.
> 20450 Century Blvd
> Germantown MD 20878
> 240-643-0836
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190613/3bb432ba/attachment.html>

From Randy.MacLeod at windriver.com  Thu Jun 13 15:39:28 2019
From: Randy.MacLeod at windriver.com (Randy MacLeod)
Date: Thu, 13 Jun 2019 18:39:28 -0400
Subject: [yocto] [ptest-runner][PATCH] utils: ensure child can be session
	leader
Message-ID: <20190613223928.14424-1-Randy.MacLeod@windriver.com>

From: Sakib Sajal <sakib.sajal at windriver.com>

When running the run-execscript bash ptest as a user rather than root, a warning:
  bash: cannot set terminal process group (16036): Inappropriate ioctl for device
  bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!

The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.

Also add '-lutil' to Makefile. This lib is from libc and provides openpty.

Signed-off-by: Sakib Sajal <sakib.sajal at windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com>
---
 Makefile |   2 +-
 utils.c  | 100 +++++++++++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 91 insertions(+), 11 deletions(-)

diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
 all: $(SOURCES) $(EXECUTABLE)
 
 $(EXECUTABLE): $(OBJECTS)
-	$(CC) $(LDFLAGS) $(OBJECTS) -o $@
+	$(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
 
 tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
 
diff --git a/utils.c b/utils.c
index ad737c2..d8977c6 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
 /**
  * Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -22,23 +23,29 @@
  */
 
 #define _GNU_SOURCE 
+
 #include <stdio.h>
 
+#include <dirent.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <grp.h>
 #include <libgen.h>
-#include <signal.h>
 #include <poll.h>
-#include <fcntl.h>
+#include <pty.h>
+#include <signal.h>
+#include <stdlib.h>
+#include <string.h>
 #include <time.h>
-#include <dirent.h>
+#include <unistd.h>
+
+
+#include <sys/ioctl.h>
 #include <sys/resource.h>
+#include <sys/stat.h>
 #include <sys/types.h>
 #include <sys/wait.h>
-#include <sys/stat.h>
-#include <unistd.h>
-#include <string.h>
-#include <stdlib.h>
 
-#include <errno.h>
 
 #include "ptest_list.h"
 #include "utils.h"
@@ -346,6 +353,51 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 	return status;
 }
 
+/* get_slave_pty() returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) { 
+	int pty_master = -1;
+	int pty_slave = -1;
+	char pty_name[256];
+	struct group *gptr;
+	gid_t gid;
+	int slave = -1;
+
+	if (openpty(&pty_master, &pty_slave, pty_name, NULL, NULL) < 0) {
+		fprintf(fp, "ERROR: openpty() failed with: %s.\n", strerror(errno));
+		return -1;
+	}
+
+	if ((gptr = getgrnam(pty_name)) != 0) {
+		gid = gptr->gr_gid;
+	} else {
+		/* If the tty group does not exist, don't change the
+		 * group on the slave pty, only the owner
+		 */
+		gid = -1;
+	}
+
+	/* chown/chmod the corresponding pty, if possible.
+	 * This will only work if the process has root permissions.
+	 */
+	if (chown(pty_name, getuid(), gid) != 0) {
+		fprintf(fp, "ERROR; chown() failed with: %s.\n", strerror(errno));
+	}
+
+	/* Makes the slave read/writeable for the user. */
+	  if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+		fprintf(fp, "ERROR: chmod() failed with: %s.\n", strerror(errno));
+	}
+
+	slave = open(pty_name, O_RDWR);
+	return (slave);
+}
+
+
 int
 run_ptests(struct ptest_list *head, const struct ptest_options opts,
 		const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 	int timeouted;
 	time_t sttime, entime;
 	int duration;
+	int slave;
+	int pgid = -1;
 
 	if (opts.xml_filename) {
 		xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 			close(pipefd_stdout[1]);
 			break;
 		}
-
 		fprintf(fp, "START: %s\n", progname);
 		PTEST_LIST_ITERATE_START(head, p);
 			char *ptest_dir = strdup(p->run_ptest);
@@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 				break;
 			}
 			dirname(ptest_dir);
+			if (ioctl(0, TIOCNOTTY) == -1) {
+				fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
+			}
+
+			if ((pgid = getpgid(0)) == -1) {
+				fprintf(fp, "ERROR: getpgid() failed, %s\n", strerror(errno));
+			}
 
 			child = fork();
 			if (child == -1) {
@@ -395,13 +455,33 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 				rc = -1;
 				break;
 			} else if (child == 0) {
-				setsid();
+				close(0);
+				if ((slave = setup_slave_pty(fp)) < 0) {
+					fprintf(fp, "ERROR: could not setup pty (%d).", slave);
+				}
+				if (setpgid(0,pgid) == -1) {
+					fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
+				};
+
+				if (setsid() ==  -1) {
+					fprintf(fp, "ERROR: setsid() failed, %s\n", strerror(errno));
+				}
+
+				if (ioctl(0, TIOCSCTTY, NULL) == -1) {
+					fprintf(fp, "ERROR: Unable to attach to controlling tty, %s\n", strerror(errno));
+				}
+
 				run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
+
 			} else {
 				int status;
 				int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
 				FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;
 
+				if (setpgid(child, pgid) == -1) {
+					fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
+				};
+
 				sttime = time(NULL);
 				fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
 				fprintf(fp, "BEGIN: %s\n", ptest_dir);
-- 
2.17.0


From randy.macleod at windriver.com  Thu Jun 13 16:01:26 2019
From: randy.macleod at windriver.com (Randy MacLeod)
Date: Thu, 13 Jun 2019 19:01:26 -0400
Subject: [yocto] [ptest-runner][PATCH] utils: ensure child can be
 session leader
In-Reply-To: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
Message-ID: <d10c137d-d9c4-32dc-fb35-89938feb534e@windriver.com>

On 6/13/19 6:39 PM, Randy MacLeod wrote:
> From: Sakib Sajal <sakib.sajal at windriver.com>

Oops.

Sakib started on this and then had to work on something else
so I finished it up. If needed, I'll send a v2 with me as
the author, since "finishing up" was most of the work.
We're both down as SOBs so whatever works.
-- 
# Randy MacLeod
# Wind River Linux

From sangeeta.jain at intel.com  Thu Jun 13 23:17:20 2019
From: sangeeta.jain at intel.com (Jain, Sangeeta)
Date: Fri, 14 Jun 2019 06:17:20 +0000
Subject: [yocto] QA notification for completed autobuilder build
 (yocto-2.8_M1.rc2)
In-Reply-To: <b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
References: <20190611033223.498F7E00D73@yocto-www.yoctoproject.org>
	<b4ef68996131d5a09e26e597a5b9c76874a0b2a3.camel@linuxfoundation.org>
Message-ID: <015AB11D45F2C442929CB2765DAE738634E36E20@PGSMSX110.gar.corp.intel.com>

QA cycle report for 2.8 M1 RC2:

	1. No high milestone defects.  
	2. Test results are available at following location:
 		? For results of all automated tests, please refer to results at public AB [1]
		? For other test results, refer to git repo " yocto-testresults-contrib" [2]
		? For test report for test cases run by Intel and WR team, refer to git repo " yocto-testresults-contrib" [2]
            3. 3 new defects are found in this cycle, BSP HW - parselog issue [3], BSP HW - audio issue [4], qemux86 oe-selftest failure on AB [5] 
            4. ptests failing in this release which were passing in previous release - acl [6]. 3 timeout issues observed in ptests - acl [7], bluez5 [8]  and mdadm [9].
	Richard's comments on ptest failures:  There are three timeouts in ptest, acl, bluez5 (#13366) and mdadm (#13368). These are also not going to block the milestone release. The
                                                                                     bluez5 issue is gcc9 related, mdadm was exposed by wider testing in master. The acl issue needs a bug opening and investigation as that is a regression.
 	Summary of ptest in this build: 
	qemuarm64-ptest:
		Total : 435597
		Pass : 433344
 		 Fail :  65
		Skip : 2188
		Timeout issues in bluez5 and mdadm
            qemux86-64-ptest
            		Total : 45346
            		Pass : 43235
           		 Fail :  56
            		Skip : 2055
            		Timeout issues in acl, bluez5 and mdadm

        5. Summary of ltp test run in this build:
	qemuarm64-ltp
		Total : 1886
		Pass : 1759
 		 Fail :  127
              qemux86-64-ltp
		Total : 1879
                             Pass : 1825
                             Fail :  54

======= Links ========

[1] - https://autobuilder.yocto.io/pub/releases/yocto-2.8_M1.rc2/testresults/

[2] - git clone git at push.yoctoproject.org:yocto-testresults-contrib -b zeus

[3] - [QA 2.8 M1 RC1][BSP HW] parselogs.ParseLogsTest.test_parselogs failure on coffeelake
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13396

[4] - [QA 2.8 M1 RC1][BSP HW] audio is not playing on coffeelake and nuc7
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13397

[5] - [QA 2.8 M1 RC1] test_boot_machine_slirp is showing error for qemux86
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13399

[6] - [QA 2.8 M1 RC1] acl ptest failure
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13395

[7] - acl ptest timeout due to perl update
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13391

[8] - bluez5 ptest hangs with gcc 9
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13366

[9] - mdadm ptest times out
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13368


Thanks & Regards,
Sangeeta Jain


From Qi.Chen at windriver.com  Fri Jun 14 01:13:14 2019
From: Qi.Chen at windriver.com (ChenQi)
Date: Fri, 14 Jun 2019 16:13:14 +0800
Subject: [yocto] [meta-security][PATCH 1/2] oe-selftest: add running cve
 checker
In-Reply-To: <20190510030957.26040-1-akuster808@gmail.com>
References: <20190510030957.26040-1-akuster808@gmail.com>
Message-ID: <26b35a5c-4225-b4f0-3222-76a74e80688e@windriver.com>

Hi Armin,

I just noticed this selftest case.
Have you considered putting it into oe-core?

Best Regards,
Chen Qi

On 05/10/2019 11:09 AM, Armin Kuster wrote:
> Signed-off-by: Armin Kuster <akuster808 at gmail.com>
> ---
>   lib/oeqa/selftest/cases/cvechecker.py | 27 +++++++++++++++++++++++++++
>   1 file changed, 27 insertions(+)
>   create mode 100644 lib/oeqa/selftest/cases/cvechecker.py
>
> diff --git a/lib/oeqa/selftest/cases/cvechecker.py b/lib/oeqa/selftest/cases/cvechecker.py
> new file mode 100644
> index 0000000..23ca7d2
> --- /dev/null
> +++ b/lib/oeqa/selftest/cases/cvechecker.py
> @@ -0,0 +1,27 @@
> +import os
> +import re
> +
> +from oeqa.selftest.case import OESelftestTestCase
> +from oeqa.utils.commands import bitbake, get_bb_var
> +
> +class CveCheckerTests(OESelftestTestCase):
> +    def test_cve_checker(self):
> +        image = "core-image-sato"
> +
> +        deploy_dir = get_bb_var("DEPLOY_DIR_IMAGE")
> +        image_link_name = get_bb_var('IMAGE_LINK_NAME', image)
> +
> +        manifest_link = os.path.join(deploy_dir, "%s.cve" % image_link_name)
> +
> +        self.logger.info('CVE_CHECK_MANIFEST = "%s"' % manifest_link)
> +        if (not 'cve-check' in get_bb_var('INHERIT')):
> +            add_cve_check_config = 'INHERIT += "cve-check"'
> +            self.append_config(add_cve_check_config)
> +        self.append_config('CVE_CHECK_MANIFEST = "%s"' % manifest_link)
> +        result = bitbake("-k -c cve_check %s" % image, ignore_status=True)
> +        if (not 'cve-check' in get_bb_var('INHERIT')):
> +            self.remove_config(add_cve_check_config)
> +
> +        isfile = os.path.isfile(manifest_link)
> +        self.assertEqual(True, isfile, 'Failed to create cve data file : %s' % manifest_link)
> +



From Moritz.Porst at gmx.de  Fri Jun 14 01:15:16 2019
From: Moritz.Porst at gmx.de (Moritz Porst)
Date: Fri, 14 Jun 2019 10:15:16 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
Message-ID: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>

An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190614/8b1a744d/attachment.html>

From zoran.stojsavljevic at gmail.com  Fri Jun 14 02:00:24 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Fri, 14 Jun 2019 11:00:24 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
Message-ID: <CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>

> However if I abort the update while running (i.e. simulating a power cut)
> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
> unknown block". My understanding is that I should at least end up in a
> busybox or that the update is retried, but this does not happen.

You missed to attach failed dmesg while the system booted and aborted.
Nevertheless, I expect problem with your defconfig, which does NOT
have options set for initramfs. These ones:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs

Please, could you add these one to your current .config, this might
very well solve your problem.

Best Regards,
Zoran
_______

On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>
> Hello,
>
> I am currently having trouble to get swupdate working properly.
> My problem:
> I can execute swupdate -i normally and if the update fits I have no problem. However if I abort the update while running (i.e. simulating a power cut) and then reboot I end up in a kernel panic: "Unable to mount rootfs on unknown block". My understanding is that I should at least end up in a busybox or that the update is retried, but this does not happen.
> I receive 1 error when updating which does not stop the update: "Could not find MTD".
>
> My configuration:
> I have a single rootfs and a separate boot partition. I build the initramfs using:
> ---
> IMAGE_INSTALL = "base-files \
>                base-passwd \
>                swupdate \
>                busybox \
>                libconfig \
>                util-linux-sfdisk \
>                mtd-utils \
>                mtd-utils-ubifs \
>                ${@bb.utils.contains('SWUPDATE_INIT', 'tiny', 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>                 "
> ---
> This is taken from swupdate-image. I include the same packages (via _append) in my base image, is this necessary ?
> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>
> Can you see a mistake I made ?
>
> Best regards
> Moritz
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From jeremy.singy at gmail.com  Fri Jun 14 02:15:13 2019
From: jeremy.singy at gmail.com (=?UTF-8?B?SsOpcsOpbXkgU2luZ3k=?=)
Date: Fri, 14 Jun 2019 11:15:13 +0200
Subject: [yocto] Can't build SDK while shrinking shadow tools
In-Reply-To: <CAA42Xj5nygLnFp_ojTP5J59czFuG7f82c6bc_SLax+4+Ot2QVg@mail.gmail.com>
References: <CAA42Xj5nygLnFp_ojTP5J59czFuG7f82c6bc_SLax+4+Ot2QVg@mail.gmail.com>
Message-ID: <CAA42Xj5pNmu1BSVAd2FMTJvwO1fSbtckDfp+EOP9ELikG_=POw@mail.gmail.com>

Hi,

I'm facing a problem by trying to shrink the size of our root filesystem.
To avoid installing some unneeded tools such as adduser, groupadd,
nologin, etc. I just created as usual a shadow_%.bbappend in our layer
which removes the content using do_install_append:

    # do not install alternatives
    ALTERNATIVE_${PN} = ""
    ALTERNATIVE_${PN}-base = ""

    # remove unwanted files on target
    do_install_append_class-target () {
      rm -r ${D}${base_bindir}
      rm -r ${D}${base_sbindir}
      rm -r ${D}${bindir}
      rm -r ${D}${sbindir}
    }

Building an image with this works well and I got rid of the unwanted
tools but I get an error whenever I try to build the SDK for this image
with do_populate_sdk:

    WARNING: ceres-image-1.0-r0 do_populate_sdk:
nativesdk-util-linux.postinst returned 1, marking as unpacked only,
configuration required on target.
    ERROR: ceres-image-1.0-r0 do_populate_sdk: Postinstall scriptlets
of ['nativesdk-util-linux'] have failed. If the intention is to defer
them to first boot,
    then please place them into pkg_postinst_ontarget_${PN} ().
    Deferring to first boot via 'exit 1' is no longer supported.
    Details of the failure are in
/home/chsingj/yocto-thud/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/temp/log.do_populate_sdk.
    ERROR: ceres-image-1.0-r0 do_populate_sdk: Function failed: do_populate_sdk
    ERROR: Logfile of failure stored in:
/home/chsingj/yocto-thud/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/temp/log.do_populate_sdk.28331
    ERROR: Task
(/home/chsingj/meta-delta/recipes-core/images/ceres-image.bb:do_populate_sdk)
failed with exit code '1'
    NOTE: Tasks Summary: Attempted 2730 tasks of which 2729 didn't
need to be rerun and 1 failed.

The log file shows an error with update-alternatives (probably a
failing ln call):

    update-alternatives: Error: not linking
[BUILDPATH]/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/sdk/image/opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin
to /opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin.util-linux
since [BUILDPATH]/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/sdk/image/opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin
exists and is not a link

If I remove the bbappend, the SDK builds fine but of course my image
contains the unwanted files. I tried many other recipe tweaks but I
can't get over some build errors. I'd like to avoid a solution using
ROOTFS_POSTPROCESS_COMMAND in the image recipe as I would have to
explicitely list all shadow tools and it would blow up my recipe. Is
there any solution here? Is it maybe a bug that can be fixed? Thanks!

Regards,
Jeremy

From Moritz.Porst at gmx.de  Fri Jun 14 03:19:51 2019
From: Moritz.Porst at gmx.de (Moritz Porst)
Date: Fri, 14 Jun 2019 12:19:51 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
Message-ID: <trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>

An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190614/1151aeb5/attachment.html>

From sbabic at denx.de  Fri Jun 14 05:14:05 2019
From: sbabic at denx.de (Stefano Babic)
Date: Fri, 14 Jun 2019 14:14:05 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
Message-ID: <bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>

Hi Moritz,

On 14/06/19 12:19, Moritz Porst wrote:
> (Sorry, the answer should go to everyone)
> Thanks for your response, unfortunately it didn't work out for me.
> Because I am not 100% sure whether I did the correct thing I describe it:
> In my layer I went to recipes-kernel/kernel/files, here I added a file
> defconfig which I filled with the content of your config-initramfs
> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
> file added so it reads (in its entirety):
> ?
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0001-sdcard-power-management-off.patch"
> SRC_URI += "file://defconfig"
> ?
> However I *also* have a file called defconfig in meta-swupdate which is
> basically the swupdate config that comes from menuconfig. I let this
> untouched but since this is not the kernel defconfig I guess you didn't
> mean this file ?
> ?
> Additionally I can't mount the rootfs with the failed boot so I cannot
> access the dmesg log file. Any advice here ?
> ?
> Best regards
> Moritz
> ?
> ?
> ?
> *Gesendet:*?Freitag, 14. Juni 2019 um 11:00 Uhr
> *Von:*?"Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
> *An:*?"Moritz Porst" <Moritz.Porst at gmx.de>
> *Cc:*?"Yocto Project" <yocto at yoctoproject.org>
> *Betreff:*?Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>> However if I abort the update while running (i.e. simulating a power cut)
>> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
>> unknown block". My understanding is that I should at least end up in a
>> busybox or that the update is retried, but this does not happen.
> 
> You missed to attach failed dmesg while the system booted and aborted.
> Nevertheless, I expect problem with your defconfig, which does NOT
> have options set for initramfs. These ones:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
> 
> Please, could you add these one to your current .config, this might
> very well solve your problem.
> 
> Best Regards,
> Zoran
> _______
> 
> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>>
>> Hello,
>>
>> I am currently having trouble to get swupdate working properly.
>> My problem:
>> I can execute swupdate -i normally and if the update fits I have no
> problem. However if I abort the update while running (i.e. simulating a
> power cut) and then reboot I end up in a kernel panic: "Unable to mount
> rootfs on unknown block". My understanding is that I should at least end
> up in a busybox or that the update is retried, but this does not happen.
>> I receive 1 error when updating which does not stop the update: "Could
> not find MTD".
>>
>> My configuration:
>> I have a single rootfs and a separate boot partition. I build the
> initramfs using:

You have a *single* rootfs, you stop an upgrade (resulting of course in
a corrupted rootfs or worse), and you wonder that kernel cannot mount
it....your update concept is broken.

You *must* check the bootloader marker in U-Boot (default is the
"recovery_status" variable) and you *mus*t start again the updater (the
ramdisk) until the marker (it is a transaction flag) is set. It is
erased by SWUpdate only after a successful update. You are now starting
your board with a half-completed update.

Best regards,
Stefano Babic


>> ---
>> IMAGE_INSTALL = "base-files \
>> base-passwd \
>> swupdate \
>> busybox \
>> libconfig \
>> util-linux-sfdisk \
>> mtd-utils \
>> mtd-utils-ubifs \
>> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>> "
>> ---
>> This is taken from swupdate-image. I include the same packages (via
> _append) in my base image, is this necessary ?
>> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>>
>> Can you see a mistake I made ?
>>
>> Best regards
>> Moritz
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> 

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================

From elcapitanbrown at gmail.com  Fri Jun 14 06:52:40 2019
From: elcapitanbrown at gmail.com (Larry Brown)
Date: Fri, 14 Jun 2019 09:52:40 -0400
Subject: [yocto] dnf causing build failure
Message-ID: <CAOmL4Uj8+A=nXjyu198+XsTMsj6wTa5NgKi=nypLVDWQjix4xA@mail.gmail.com>

I've created a recipe that simply copies files into a folder of the image.
Basically in this form:

------------------------------------------------------

SUMMARY = "Some text"
HOMEPAGE = ""
LICENSE = "CLOSED"
LIC_FILES_CHKSUM = ""

DEPENDS = "openssl"

do_install () {
     install -m 0644 ${WORKDIR}/path/fileA ${B}/
     install -m 0644 ${WORKDIR}/path/fileB ${B}/
}

FILES_${PN}-ssh = "${sysconfdir}/path/fileA ${sysconfdir}/path/fileB"

-------------------------------------------------

When I build this I only want the files in the target image.  I don't need
an rpm built that could be used to deliver these files.  Now there might be
something I could do that would enable DNF to succeed, however I would like
to learn how to get the package installer to ignore/skip a recipe (
openssh-keys-install.bb in this case) that is only used during the initial
build.

Can someone shed some light here?

Also, if there is already a way built into the build process to retain a
set of keys for each device so they don't keep creating new keys, that
would be cool and appreciated, but I'm wanting to learn how to accomplish
this so it does not stop me when wanting to include other files elsewhere.

I'm assuming here that there is someone here that has dealt with this;
however, if I'm mistaken the following is the error that is generated when
building.  And by the way, the files do get placed into the correct folder
(after some bit of tweaking of the code).  But the error persists:

ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command
'...--nogpgcheck install base-passwd iptables openssh openssh-keys-install
packagegroup-core-boot run-postinsts shadow' returned 1:
DNF version:4.2.2
cachedir:
/stor/development/yocto/poky/trident-build/tmp/work/raspberrypi3_64-poky-linux/core-image-minimal/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from
/stor/development/yocto/poky/trident-build/tmp/work/raspberrypi3_64-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Thu 13 Jun 2019 09:13:54 PM UTC.
No module defaults found
No match for argument: openssh-keys-install
Error: Unable to find a match

ERROR: core-image-minimal-1.0-r0 do_rootfs:
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
....

TIA



-- 
Larry Brown
S/V Trident
Palm Harbor, FL
~~~~~~~~~~~~~~~~~_/)~~~~~~~~
    ~     ~          ~~           ~
~           ~~_/)    ~      ~ ~        ~
     ~                  _/)          ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190614/56aa8746/attachment-0001.html>

From alex.kanavin at gmail.com  Fri Jun 14 07:10:58 2019
From: alex.kanavin at gmail.com (Alexander Kanavin)
Date: Fri, 14 Jun 2019 16:10:58 +0200
Subject: [yocto] dnf causing build failure
In-Reply-To: <CAOmL4Uj8+A=nXjyu198+XsTMsj6wTa5NgKi=nypLVDWQjix4xA@mail.gmail.com>
References: <CAOmL4Uj8+A=nXjyu198+XsTMsj6wTa5NgKi=nypLVDWQjix4xA@mail.gmail.com>
Message-ID: <CANNYZj_ceD6FRuhn04Wz7XVgfLQ=QikWzdEORs80f924W8Y=KQ@mail.gmail.com>

Should be ${D}, not ${B} in do_install.

Alex

On Fri, 14 Jun 2019 at 15:53, Larry Brown <elcapitanbrown at gmail.com> wrote:

> I've created a recipe that simply copies files into a folder of the
> image.  Basically in this form:
>
> ------------------------------------------------------
>
> SUMMARY = "Some text"
> HOMEPAGE = ""
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
>
> DEPENDS = "openssl"
>
> do_install () {
>      install -m 0644 ${WORKDIR}/path/fileA ${B}/
>      install -m 0644 ${WORKDIR}/path/fileB ${B}/
> }
>
> FILES_${PN}-ssh = "${sysconfdir}/path/fileA ${sysconfdir}/path/fileB"
>
> -------------------------------------------------
>
> When I build this I only want the files in the target image.  I don't need
> an rpm built that could be used to deliver these files.  Now there might be
> something I could do that would enable DNF to succeed, however I would like
> to learn how to get the package installer to ignore/skip a recipe (
> openssh-keys-install.bb in this case) that is only used during the
> initial build.
>
> Can someone shed some light here?
>
> Also, if there is already a way built into the build process to retain a
> set of keys for each device so they don't keep creating new keys, that
> would be cool and appreciated, but I'm wanting to learn how to accomplish
> this so it does not stop me when wanting to include other files elsewhere.
>
> I'm assuming here that there is someone here that has dealt with this;
> however, if I'm mistaken the following is the error that is generated when
> building.  And by the way, the files do get placed into the correct folder
> (after some bit of tweaking of the code).  But the error persists:
>
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command
> '...--nogpgcheck install base-passwd iptables openssh openssh-keys-install
> packagegroup-core-boot run-postinsts shadow' returned 1:
> DNF version:4.2.2
> cachedir:
> /stor/development/yocto/poky/trident-build/tmp/work/raspberrypi3_64-poky-linux/core-image-minimal/1.0-r0/rootfs/var/cache/dnf
> Added oe-repo repo from
> /stor/development/yocto/poky/trident-build/tmp/work/raspberrypi3_64-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo
> repo: using cache for: oe-repo
> not found other for:
> not found modules for:
> not found deltainfo for:
> not found updateinfo for:
> oe-repo: using metadata from Thu 13 Jun 2019 09:13:54 PM UTC.
> No module defaults found
> No match for argument: openssh-keys-install
> Error: Unable to find a match
>
> ERROR: core-image-minimal-1.0-r0 do_rootfs:
> ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
> ....
>
> TIA
>
>
>
> --
> Larry Brown
> S/V Trident
> Palm Harbor, FL
> ~~~~~~~~~~~~~~~~~_/)~~~~~~~~
>     ~     ~          ~~           ~
> ~           ~~_/)    ~      ~ ~        ~
>      ~                  _/)          ~
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190614/9fd6395d/attachment.html>

From Randy.MacLeod at windriver.com  Fri Jun 14 07:48:50 2019
From: Randy.MacLeod at windriver.com (Randy MacLeod)
Date: Fri, 14 Jun 2019 10:48:50 -0400
Subject: [yocto] [ptest-runner][PATCH v2 1/4] utils: Ensure stdout/stderr
	are flushed
In-Reply-To: <20190614144853.25839-1-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
Message-ID: <20190614144853.25839-2-Randy.MacLeod@windriver.com>

From: Richard Purdie <richard.purdie at linuxfoundation.org>

There is no guarantee that the data written with fwrite will be flushed to the
buffer. If stdout and stderr are the same thing, this could lead to interleaved
writes. The common case is stdout output so flush the output pipes when writing to
stderr. Also flush stdout before the function returns.

Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
Upstream-Status: Pending [code being tested]
---
 utils.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/utils.c b/utils.c
index 6e453a1..9fab6f2 100644
--- a/utils.c
+++ b/utils.c
@@ -316,8 +316,11 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 			}
 
 			if (pfds[1].revents != 0) {
-				while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0)
+				while ((n = read(fds[1], buf, WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
+					fflush(fps[0]);
 					fwrite(buf, n, 1, fps[1]);
+					fflush(fps[1]);
+				}
 			}
 
 			clock_gettime(clock, &sentinel);
@@ -336,7 +339,7 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 			break;
 	}
 
-
+	fflush(fps[0]);
 	return status;
 }
 
-- 
2.17.0


From Randy.MacLeod at windriver.com  Fri Jun 14 07:48:51 2019
From: Randy.MacLeod at windriver.com (Randy MacLeod)
Date: Fri, 14 Jun 2019 10:48:51 -0400
Subject: [yocto] [ptest-runner][PATCH v2 2/4] use process groups when
	spawning
In-Reply-To: <20190614144853.25839-1-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
Message-ID: <20190614144853.25839-3-Randy.MacLeod@windriver.com>

From: Richard Purdie <richard.purdie at linuxfoundation.org>

Rather than just killing the process we've swawned, set the process group
for spawned children and then kill the group of processes.

Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
Upstream-Status: Pending [code being tested]
---
 utils.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/utils.c b/utils.c
index 9fab6f2..86dcdad 100644
--- a/utils.c
+++ b/utils.c
@@ -330,7 +330,7 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 			clock_gettime(clock, &time);
 			if ((time.tv_sec - sentinel.tv_sec) > timeout) {
 				*timeouted = 1;
-				kill(pid, SIGKILL);
+				kill(-pid, SIGKILL);
 				waitflags = 0;
 			}
 		}
@@ -392,6 +392,7 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 				rc = -1;
 				break;
 			} else if (child == 0) {
+				setsid();
 				run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
 			} else {
 				int status;
-- 
2.17.0


From Randy.MacLeod at windriver.com  Fri Jun 14 07:48:49 2019
From: Randy.MacLeod at windriver.com (Randy MacLeod)
Date: Fri, 14 Jun 2019 10:48:49 -0400
Subject: [yocto] [ptest-runner][PATCH v2] 3 old patches + utils: ensure
	child can be session leader
In-Reply-To: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
Message-ID: <20190614144853.25839-1-Randy.MacLeod@windriver.com>

My patch needs Richards previous 3 patches so I've added them here.

I've cleaned up the patch a bit since v1; mostly it's indentation and
other cosmetic changes. I have added a bit more error handling and
I've renamed get_slave_pty to setup_slave_pty to more accurately 
reflect what the function does. Also I've cleaned up the code to only
use open_pty() to get the tty name.

Care to release an update now that oe-core 2.8-M1 is in QA?

../Randy



From Randy.MacLeod at windriver.com  Fri Jun 14 07:48:53 2019
From: Randy.MacLeod at windriver.com (Randy MacLeod)
Date: Fri, 14 Jun 2019 10:48:53 -0400
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
	session leader
In-Reply-To: <20190614144853.25839-1-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
Message-ID: <20190614144853.25839-5-Randy.MacLeod@windriver.com>

When running the run-execscript bash ptest as a user rather than root, a warning:
  bash: cannot set terminal process group (16036): Inappropriate ioctl for device
  bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!

The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.

Also add '-lutil' to Makefile. This lib is from libc and provides openpty.

Signed-off-by: Sakib Sajal <sakib.sajal at windriver.com>
Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com>
---
 Makefile |   2 +-
 utils.c  | 102 +++++++++++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 92 insertions(+), 12 deletions(-)

diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
 all: $(SOURCES) $(EXECUTABLE)
 
 $(EXECUTABLE): $(OBJECTS)
-	$(CC) $(LDFLAGS) $(OBJECTS) -o $@
+	$(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
 
 tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
 
diff --git a/utils.c b/utils.c
index ad737c2..f11ce39 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
 /**
  * Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -22,23 +23,27 @@
  */
 
 #define _GNU_SOURCE 
+
 #include <stdio.h>
 
+#include <dirent.h>
+#include <errno.h>
+#include <fcntl.h>
+#include <grp.h>
 #include <libgen.h>
-#include <signal.h>
 #include <poll.h>
-#include <fcntl.h>
+#include <pty.h>
+#include <signal.h>
+#include <stdlib.h>
+#include <string.h>
 #include <time.h>
-#include <dirent.h>
+#include <unistd.h>
+
+#include <sys/ioctl.h>
 #include <sys/resource.h>
+#include <sys/stat.h>
 #include <sys/types.h>
 #include <sys/wait.h>
-#include <sys/stat.h>
-#include <unistd.h>
-#include <string.h>
-#include <stdlib.h>
-
-#include <errno.h>
 
 #include "ptest_list.h"
 #include "utils.h"
@@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 	return status;
 }
 
+/* Returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave pty file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) { 
+	int pty_master = -1;
+	int pty_slave = -1;
+	char pty_name[256];
+	struct group *gptr;
+	gid_t gid;
+	int slave = -1;
+
+	if (openpty(&pty_master, &pty_slave, pty_name, NULL, NULL) < 0) {
+		fprintf(fp, "ERROR: openpty() failed with: %s.\n", strerror(errno));
+		return -1;
+	}
+
+	if ((gptr = getgrnam(pty_name)) != 0) {
+		gid = gptr->gr_gid;
+	} else {
+		/* If the tty group does not exist, don't change the
+		 * group on the slave pty, only the owner
+		 */
+		gid = -1;
+	}
+
+	/* chown/chmod the corresponding pty, if possible.
+	 * This will only work if the process has root permissions.
+	 */
+	if (chown(pty_name, getuid(), gid) != 0) {
+		fprintf(fp, "ERROR; chown() failed with: %s.\n", strerror(errno));
+	}
+
+	/* Makes the slave read/writeable for the user. */
+	if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+		fprintf(fp, "ERROR: chmod() failed with: %s.\n", strerror(errno));
+	}
+
+	if ((slave = open(pty_name, O_RDWR)) == -1) {
+		fprintf(fp, "ERROR: open() failed with: %s.\n", strerror(errno));
+	}
+	return (slave);
+}
+
+
 int
 run_ptests(struct ptest_list *head, const struct ptest_options opts,
 		const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 	int timeouted;
 	time_t sttime, entime;
 	int duration;
+	int slave;
+	int pgid = -1;
 
 	if (opts.xml_filename) {
 		xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 			close(pipefd_stdout[1]);
 			break;
 		}
-
 		fprintf(fp, "START: %s\n", progname);
 		PTEST_LIST_ITERATE_START(head, p);
 			char *ptest_dir = strdup(p->run_ptest);
@@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 				break;
 			}
 			dirname(ptest_dir);
+			if (ioctl(0, TIOCNOTTY) == -1) {
+				fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
+			}
+
+			if ((pgid = getpgid(0)) == -1) {
+				fprintf(fp, "ERROR: getpgid() failed, %s\n", strerror(errno));
+			}
 
 			child = fork();
 			if (child == -1) {
@@ -395,13 +455,33 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
 				rc = -1;
 				break;
 			} else if (child == 0) {
-				setsid();
+				close(0);
+				if ((slave = setup_slave_pty(fp)) < 0) {
+					fprintf(fp, "ERROR: could not setup pty (%d).", slave);
+				}
+				if (setpgid(0,pgid) == -1) {
+					fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
+				}
+
+				if (setsid() ==  -1) {
+					fprintf(fp, "ERROR: setsid() failed, %s\n", strerror(errno));
+				}
+
+				if (ioctl(0, TIOCSCTTY, NULL) == -1) {
+					fprintf(fp, "ERROR: Unable to attach to controlling tty, %s\n", strerror(errno));
+				}
+
 				run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
+
 			} else {
 				int status;
 				int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
 				FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;
 
+				if (setpgid(child, pgid) == -1) {
+					fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
+				}
+
 				sttime = time(NULL);
 				fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
 				fprintf(fp, "BEGIN: %s\n", ptest_dir);
-- 
2.17.0


From Randy.MacLeod at windriver.com  Fri Jun 14 07:48:52 2019
From: Randy.MacLeod at windriver.com (Randy MacLeod)
Date: Fri, 14 Jun 2019 10:48:52 -0400
Subject: [yocto] [ptest-runner][PATCH v2 3/4] utils: Ensure pipes are read
	after exit
In-Reply-To: <20190614144853.25839-1-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
Message-ID: <20190614144853.25839-4-Randy.MacLeod@windriver.com>

From: Richard Purdie <richard.purdie at linuxfoundation.org>

There was a race in the code where the pipes may not be read after the process has exited
and data may be left behind in them. This change to ordering ensures the pipes are read
after the exit code has been read meaning no data can be left behind and the logs should
be complete.

Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org>
Upstream-Status: Pending [code being tested]
---
 utils.c | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/utils.c b/utils.c
index 86dcdad..ad737c2 100644
--- a/utils.c
+++ b/utils.c
@@ -285,6 +285,7 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 	struct pollfd pfds[2];
 	struct timespec sentinel;
 	clockid_t clock = CLOCK_MONOTONIC;
+	int looping = 1;
 	int r;
 
 	int status;
@@ -302,9 +303,23 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 
 	*timeouted = 0;
 
-	while (1) {
+	while (looping) {
 		waitflags = WNOHANG;
 
+		if (timeout >= 0) {
+			struct timespec time;
+
+			clock_gettime(clock, &time);
+			if ((time.tv_sec - sentinel.tv_sec) > timeout) {
+				*timeouted = 1;
+				kill(-pid, SIGKILL);
+				waitflags = 0;
+			}
+		}
+
+		if (waitpid(pid, &status, waitflags) == pid)
+			looping = 0;
+
 		r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
 		if (r > 0) {
 			char buf[WAIT_CHILD_BUF_MAX_SIZE];
@@ -324,19 +339,7 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
 			}
 
 			clock_gettime(clock, &sentinel);
-		} else if (timeout >= 0) {
-			struct timespec time;
-
-			clock_gettime(clock, &time);
-			if ((time.tv_sec - sentinel.tv_sec) > timeout) {
-				*timeouted = 1;
-				kill(-pid, SIGKILL);
-				waitflags = 0;
-			}
 		}
-
-		if (waitpid(pid, &status, waitflags) == pid)
-			break;
 	}
 
 	fflush(fps[0]);
-- 
2.17.0


From adam.yh.lee at gmail.com  Wed Jun 12 05:51:41 2019
From: adam.yh.lee at gmail.com (Adam Lee)
Date: Wed, 12 Jun 2019 08:51:41 -0400
Subject: [yocto] Build failure on kernel-devsrc
Message-ID: <CAFeBWL6Z0d-oEJh-x2BRZRJ2YaAzv5FBcR7aQKTQ2HRNQqDO9Q@mail.gmail.com>

At some point I noticed I *must* clean kernel-devsrc before I can
build my image with Kernel changes.
I suppose this isn't normal and expect it rebuild what's necessary as
part of the image build. Has anyone seen this before?

Build Configuration:
BB_VERSION           = "1.36.0"
BUILD_SYS            = "x86_64-linux"
NATIVELSBSTRING      = "ubuntu-18.04"
TARGET_SYS           = "arm-oe-linux-gnueabi"
MACHINE              = "solix"
DISTRO               = "jome"
DISTRO_VERSION       = "2018.06"
TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard"
TARGET_FPU           = "hard"
meta-arago-distro
meta-arago-extras    = "HEAD:61f5c7b578255a0ddff8046b060f8488157c0a0d"
meta-browser         = "HEAD:4c1d135a085fe4011fadd73bf1f7876d26eac443"
meta-qt5             = "HEAD:682ad61c071a9710e9f9d8a32ab1b5f3c14953d1"
meta-networking
meta-python
meta-oe
meta-gnome           = "HEAD:352531015014d1957d6444d114f4451e241c4d23"
meta-ti              = "HEAD:6f1740c8121daafc497e26834bee67e3eeae322c"
meta-jo              = "dev:914fe3bb19ec4ddad0c7286b6908eddddb82a5be"
meta-linaro-toolchain
meta-optee           = "HEAD:75dfb67bbb14a70cd47afda9726e2e1c76731885"
meta                 = "HEAD:931a52e8698f684ccbb26ddec18764ad9d9a3e8f"
workspace            = "<unknown>:<unknown>"

Initialising tasks: 100%
|###################################################################################################|
Time: 0:00:06
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: redpine: compiling from external source tree
/home/adam/test/build/workspace/sources/redpine/source/host
NOTE: lp8863-mod: compiling from external source tree
/home/adam/test/build/workspace/sources/lp8863-mod
ERROR: kernel-devsrc-1.0-r0 do_install: Function failed: do_install
(log file is located at
/home/adam/test/build/build/tmp-glibc/work/solix-oe-linux-gnueabi/kernel-devsrc/1.0-r0/temp/log.do_install.70443)
ERROR: Logfile of failure stored in:
/home/adam/test/build/build/tmp-glibc/work/solix-oe-linux-gnueabi/kernel-devsrc/1.0-r0/temp/log.do_install.70443
Log data follows:
| DEBUG: Executing python function extend_recipe_sysroot
| NOTE: Direct dependencies are
['virtual:native:/home/adam/test/poky/meta/recipes-devtools/pseudo/pseudo_1.8.2.bb:do_populate_sysroot',
'/home/adam/test/poky/meta/recipes-devtools/gcc/gcc-runtime_7.3.bb:do_populate_sysroot',
'/home/adam/test/poky/meta/recipes-devtools/quilt/quilt-native_0.65.bb:do_populate_sysroot',
'/home/adam/test/poky/meta/recipes-core/glibc/glibc_2.26.bb:do_populate_sysroot',
'virtual:native:/home/adam/test/poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2017.09.bb:do_populate_sysroot',
'virtual:native:/home/adam/test/poky/meta/recipes-extended/bc/bc_1.06.bb:do_populate_sysroot',
'/home/adam/test/poky/meta/recipes-kernel/kmod/kmod-native_git.bb:do_populate_sysroot',
'virtual:native:/home/adam/test/poky/meta/recipes-support/lzop/lzop_1.03.bb:do_populate_sysroot',
'/home/adam/test/poky/meta/recipes-devtools/binutils/binutils-cross_2.29.1.bb:do_populate_sysroot',
'/home/adam/test/poky/meta/recipes-devtools/gcc/gcc-cross_7.3.bb:do_populate_sysroot']
| NOTE: Installed into sysroot: []
| NOTE: Skipping as already exists in sysroot: ['pseudo-native',
'gcc-runtime', 'quilt-native', 'glibc', 'u-boot-mkimage-native',
'bc-native', 'kmod-native', 'lzop-native', 'binutils-cross-arm',
'gcc-cross-arm', 'linux-libc-headers', 'libgcc', 'openssl-native',
'gnu-config-native', 'gtk-doc-native', 'libtool-native',
'zlib-native', 'pkgconfig-native', 'autoconf-native',
'automake-native', 'texinfo-dummy-native', 'bison-native',
'flex-native', 'mpfr-native', 'xz-native', 'gmp-native',
'libmpc-native', 'lzo-native', 'makedepend-native',
'cryptodev-linux-native', 'm4-native', 'gettext-minimal-native',
'xproto-native', 'util-macros-native']
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing shell function do_install
| 0 blocks
| cpio: ./singletask.lock: Cannot stat: No such file or directory
| 0 blocks
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_install (log file is located at
/home/adam/test/build/build/tmp-glibc/work/solix-oe-linux-gnueabi/kernel-devsrc/1.0-r0/temp/log.do_install.70443)
ERROR: Task (/home/adam/test/poky/meta/recipes-kernel/linux/kernel-devsrc.bb:do_install)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 5488 tasks of which 5240 didn't need to
be rerun and 1 failed.
NOTE: Writing buildhistory

Summary: 1 task failed:
  /home/adam/test/poky/meta/recipes-kernel/linux/kernel-devsrc.bb:do_install
Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

From mtownsend1973 at gmail.com  Thu Jun 13 01:16:09 2019
From: mtownsend1973 at gmail.com (Martin Townsend)
Date: Thu, 13 Jun 2019 09:16:09 +0100
Subject: [yocto] nativesdk-expect configure error
Message-ID: <CABatt_zT5guZOOPS8hUkJ24RDTSMdjXJfe-OeC+UK-yk_uN6Ug@mail.gmail.com>

Hi,

I'm seeing the following do_configure error when building
nativesdk-expect, this is in Rocko but the recipe doesn't look like
it's changed much in master.

 checking for Tcl public headers... configure: error: tcl.h not found.
Please specify its location with --with-tclinclude
| NOTE: The following config.log files may provide further information.
| NOTE: /ws/rufilla/curtisswright/yocto-rocko/build/tmp/work/x86_64-nativesdk-cwrsdk-linux/nativesdk-expect/5.45-r1/build/config.log
| ERROR: configure failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at
/ws/rufilla/curtisswright/yocto-rocko/build/tmp/work/x86_64-nativesdk-cwrsdk-linux/nativesdk-expect/5.45-r1/temp/log.do_configure.31445)
ERROR: Task (virtual:nativesdk:/ws/rufilla/curtisswright/yocto-rocko/sources/poky/meta/recipes-devtools/expect/expect_5.45.bb:do_configure)
failed with exit code '1'

To fix it I added

TCL_INCLUDE_PATH_class-nativesdk = "--with-tclinclude=${STAGING_INCDIR}/tcl8.6"

Is anyone else seeing this with newer Yocto versions? if so shall I
submit a patch for this?

Best Regards,
Martin.

From elcapitanbrown at gmail.com  Fri Jun 14 12:10:38 2019
From: elcapitanbrown at gmail.com (Larry Brown)
Date: Fri, 14 Jun 2019 15:10:38 -0400
Subject: [yocto] dnf causing build failure
In-Reply-To: <CANNYZj_ceD6FRuhn04Wz7XVgfLQ=QikWzdEORs80f924W8Y=KQ@mail.gmail.com>
References: <CAOmL4Uj8+A=nXjyu198+XsTMsj6wTa5NgKi=nypLVDWQjix4xA@mail.gmail.com>
	<CANNYZj_ceD6FRuhn04Wz7XVgfLQ=QikWzdEORs80f924W8Y=KQ@mail.gmail.com>
Message-ID: <CAOmL4UiH3KAXzLWc5UXSo8+Q+q=EQVGcDsMoaVt0bfHVZgHcPQ@mail.gmail.com>

So I got the ${B} from the original openssh recipe so I'm not sure what
that variable equates to now.  But I changed to ${D} and had to change some
other aspects as well.  What I didn't understand is that the recipe is
installing the files into a folder (package folder) that is ultimately
packaged and then installed into the rootfs and that it is not installing
the files from a package folder into the rootfs directly by the script.  I
don't understand how the build system knows that the files in the install
directory need to be installed into the rootfs but I can only assume that
anything installed into a structure in the package directory will be
overlayed into the rootfs in the corresponding locations.  I'm guessing...

Well with the current layout working the DNF error went away.  Maybe it was
failing the file copy to begin with but quietly and only the DNF error was
displayed?  There is definitely a learning curve here...

Thanks so much,

Larry

On Fri, Jun 14, 2019 at 10:11 AM Alexander Kanavin <alex.kanavin at gmail.com>
wrote:

> Should be ${D}, not ${B} in do_install.
>
> Alex
>
> On Fri, 14 Jun 2019 at 15:53, Larry Brown <elcapitanbrown at gmail.com>
> wrote:
>
>> I've created a recipe that simply copies files into a folder of the
>> image.  Basically in this form:
>>
>> ------------------------------------------------------
>>
>> SUMMARY = "Some text"
>> HOMEPAGE = ""
>> LICENSE = "CLOSED"
>> LIC_FILES_CHKSUM = ""
>>
>> DEPENDS = "openssl"
>>
>> do_install () {
>>      install -m 0644 ${WORKDIR}/path/fileA ${B}/
>>      install -m 0644 ${WORKDIR}/path/fileB ${B}/
>> }
>>
>> FILES_${PN}-ssh = "${sysconfdir}/path/fileA ${sysconfdir}/path/fileB"
>>
>> -------------------------------------------------
>>
>> When I build this I only want the files in the target image.  I don't
>> need an rpm built that could be used to deliver these files.  Now there
>> might be something I could do that would enable DNF to succeed, however I
>> would like to learn how to get the package installer to ignore/skip a
>> recipe (openssh-keys-install.bb in this case) that is only used during
>> the initial build.
>>
>> Can someone shed some light here?
>>
>> Also, if there is already a way built into the build process to retain a
>> set of keys for each device so they don't keep creating new keys, that
>> would be cool and appreciated, but I'm wanting to learn how to accomplish
>> this so it does not stop me when wanting to include other files elsewhere.
>>
>> I'm assuming here that there is someone here that has dealt with this;
>> however, if I'm mistaken the following is the error that is generated when
>> building.  And by the way, the files do get placed into the correct folder
>> (after some bit of tweaking of the code).  But the error persists:
>>
>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Could not invoke dnf. Command
>> '...--nogpgcheck install base-passwd iptables openssh openssh-keys-install
>> packagegroup-core-boot run-postinsts shadow' returned 1:
>> DNF version:4.2.2
>> cachedir:
>> /stor/development/yocto/poky/trident-build/tmp/work/raspberrypi3_64-poky-linux/core-image-minimal/1.0-r0/rootfs/var/cache/dnf
>> Added oe-repo repo from
>> /stor/development/yocto/poky/trident-build/tmp/work/raspberrypi3_64-poky-linux/core-image-minimal/1.0-r0/oe-rootfs-repo
>> repo: using cache for: oe-repo
>> not found other for:
>> not found modules for:
>> not found deltainfo for:
>> not found updateinfo for:
>> oe-repo: using metadata from Thu 13 Jun 2019 09:13:54 PM UTC.
>> No module defaults found
>> No match for argument: openssh-keys-install
>> Error: Unable to find a match
>>
>> ERROR: core-image-minimal-1.0-r0 do_rootfs:
>> ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
>> ....
>>
>> TIA
>>
>>
>>
>> --
>> Larry Brown
>> S/V Trident
>> Palm Harbor, FL
>> ~~~~~~~~~~~~~~~~~_/)~~~~~~~~
>>     ~     ~          ~~           ~
>> ~           ~~_/)    ~      ~ ~        ~
>>      ~                  _/)          ~
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>

-- 
Larry Brown
S/V Trident
Palm Harbor, FL
~~~~~~~~~~~~~~~~~_/)~~~~~~~~
    ~     ~          ~~           ~
~           ~~_/)    ~      ~ ~        ~
     ~                  _/)          ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190614/99cf9088/attachment.html>

From andreea.volosincu at windriver.com  Fri Jun 14 16:03:28 2019
From: andreea.volosincu at windriver.com (Volosincu, Andreea S)
Date: Fri, 14 Jun 2019 23:03:28 +0000
Subject: [yocto] Early Registration Deadline: Yocto Project DevDay NA 2019
Message-ID: <A084970538D2234B96D99D06FA9D974FCA818F6C@ALA-MBD.corp.ad.wrs.com>

Time is almost up for the Yocto Project DevDay NA 2019 early registration. Register separately or add it to your OSS NA registration.

https://www.cvent.com/events/yocto-dev-day-north-america-2019/registration-cfa8da9b8d0b43bdb92f3e81493ca2ce.aspx?fqp=true

Thanks!
Yocto Project Advocacy Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190614/41fa0ae8/attachment.html>

From akuster808 at gmail.com  Fri Jun 14 16:48:32 2019
From: akuster808 at gmail.com (akuster808)
Date: Fri, 14 Jun 2019 16:48:32 -0700
Subject: [yocto] [meta-security][PATCH 1/2] oe-selftest: add running cve
 checker
In-Reply-To: <26b35a5c-4225-b4f0-3222-76a74e80688e@windriver.com>
References: <20190510030957.26040-1-akuster808@gmail.com>
	<26b35a5c-4225-b4f0-3222-76a74e80688e@windriver.com>
Message-ID: <2acd40e9-9bcd-915e-779b-b4a1e8e5efa9@gmail.com>

Chen,

On 6/14/19 1:13 AM, ChenQi wrote:
> Hi Armin,
>
> I just noticed this selftest case.
> Have you considered putting it into oe-core?
Yes I have. That was the first place I wanted to put it but Richard and
Ross have reservations about doing that so it sits in meta-security
until we can get it into core.

Regards,
armin


>
> Best Regards,
> Chen Qi
>
> On 05/10/2019 11:09 AM, Armin Kuster wrote:
>> Signed-off-by: Armin Kuster <akuster808 at gmail.com>
>> ---
>> ? lib/oeqa/selftest/cases/cvechecker.py | 27 +++++++++++++++++++++++++++
>> ? 1 file changed, 27 insertions(+)
>> ? create mode 100644 lib/oeqa/selftest/cases/cvechecker.py
>>
>> diff --git a/lib/oeqa/selftest/cases/cvechecker.py
>> b/lib/oeqa/selftest/cases/cvechecker.py
>> new file mode 100644
>> index 0000000..23ca7d2
>> --- /dev/null
>> +++ b/lib/oeqa/selftest/cases/cvechecker.py
>> @@ -0,0 +1,27 @@
>> +import os
>> +import re
>> +
>> +from oeqa.selftest.case import OESelftestTestCase
>> +from oeqa.utils.commands import bitbake, get_bb_var
>> +
>> +class CveCheckerTests(OESelftestTestCase):
>> +??? def test_cve_checker(self):
>> +??????? image = "core-image-sato"
>> +
>> +??????? deploy_dir = get_bb_var("DEPLOY_DIR_IMAGE")
>> +??????? image_link_name = get_bb_var('IMAGE_LINK_NAME', image)
>> +
>> +??????? manifest_link = os.path.join(deploy_dir, "%s.cve" %
>> image_link_name)
>> +
>> +??????? self.logger.info('CVE_CHECK_MANIFEST = "%s"' % manifest_link)
>> +??????? if (not 'cve-check' in get_bb_var('INHERIT')):
>> +??????????? add_cve_check_config = 'INHERIT += "cve-check"'
>> +??????????? self.append_config(add_cve_check_config)
>> +??????? self.append_config('CVE_CHECK_MANIFEST = "%s"' % manifest_link)
>> +??????? result = bitbake("-k -c cve_check %s" % image,
>> ignore_status=True)
>> +??????? if (not 'cve-check' in get_bb_var('INHERIT')):
>> +??????????? self.remove_config(add_cve_check_config)
>> +
>> +??????? isfile = os.path.isfile(manifest_link)
>> +??????? self.assertEqual(True, isfile, 'Failed to create cve data
>> file : %s' % manifest_link)
>> +
>
>


From akuster808 at gmail.com  Sun Jun 16 18:24:38 2019
From: akuster808 at gmail.com (akuster808)
Date: Sun, 16 Jun 2019 18:24:38 -0700
Subject: [yocto] [PATCH][yocto-docs] ref-manual: Corrected openSUSE
 essential packages
In-Reply-To: <20190606234656.28343-1-mhalstead@linuxfoundation.org>
References: <20190606234656.28343-1-mhalstead@linuxfoundation.org>
Message-ID: <36aa5271-6cd1-a22b-56bd-7a43b8ad09d3@gmail.com>



On 6/6/19 4:46 PM, Michael Halstead wrote:
> Some packages were bumped onto the pip3 install line. Install them with zypper as before.
>
> Signed-off-by: Michael Halstead <mhalstead at linuxfoundation.org>
> ---

is this too early to Ping?

is there an issue with this patch?

-armin
>  documentation/poky.ent | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/documentation/poky.ent b/documentation/poky.ent
> index b5f600969..a436d9027 100644
> --- a/documentation/poky.ent
> +++ b/documentation/poky.ent
> @@ -68,8 +68,8 @@
>       python3-jinja2 SDL-devel xterm">
>  <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
>       diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
> -     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1
> -     $ sudo pip3 install GitPython libSDL-devel xterm">
> +     python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm
> +     $ sudo pip3 install GitPython">
>  <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
>       $ sudo yum makecache
>       $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \


From changqing.li at windriver.com  Sun Jun 16 23:06:19 2019
From: changqing.li at windriver.com (Changqing Li)
Date: Mon, 17 Jun 2019 14:06:19 +0800
Subject: [yocto] [update-rc.d][PATCH V3] update-rc.d: support
 enable/disable options
In-Reply-To: <f35da20a-ae10-1b6e-da56-0b25af2887f6@windriver.com>
References: <b36da33b-df9e-2991-5444-cd45a4c3e2d1@windriver.com>
	<1556607386-98960-1-git-send-email-changqing.li@windriver.com>
	<1556607386-98960-2-git-send-email-changqing.li@windriver.com>
	<f35da20a-ae10-1b6e-da56-0b25af2887f6@windriver.com>
Message-ID: <f09679f5-77b3-4b86-719f-2c61f0070f44@windriver.com>

ping

On 5/28/19 8:59 AM, Changqing Li wrote:
> ping
>
> On 4/30/19 2:56 PM, changqing.li at windriver.com wrote:
>> From: Changqing Li <changqing.li at windriver.com>
>>
>> Add support of enable/disable options, refer
>> https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html
>>
>> With support of these options, the usr can never change an existing
>> configuration even after upgrading a package. The program will only
>> install links if none are present, otherwise, it will keep
>> the previous configuration.
>>
>> preinst in update-rc.d.bbclass will delete all the links under
>> rcrunlevel.d, this behavior now conflicts with enable/disable
>> options. so remove preinst from the update-rc.d.bbclass
>>
>> [Yocto 12955]
>>
>> Signed-off-by: Changqing Li <changqing.li at windriver.com>
>> ---
>> ? update-rc.d | 81 
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>> ? 1 file changed, 81 insertions(+)
>>
>> diff --git a/update-rc.d b/update-rc.d
>> index e07cf85..a7fb7bc 100644
>> --- a/update-rc.d
>> +++ b/update-rc.d
>> @@ -27,6 +27,7 @@ usage()
>> ? usage: update-rc.d [-n] [-f] [-r <root>] <basename> remove
>> ???????? update-rc.d [-n] [-r <root>] [-s] <basename> defaults [NN | 
>> sNN kNN]
>> ???????? update-rc.d [-n] [-r <root>] [-s] <basename> start|stop NN 
>> runlvl [runlvl] [...] .
>> +?????? update-rc.d [-n] [-r <root>] [-s] <basename> enable|disable 
>> [S|2|3|4|5]
>> ????????? -n: not really
>> ????????? -f: force
>> ????????? -v: verbose
>> @@ -101,6 +102,53 @@ makelinks()
>> ????? done
>> ? }
>> ? +# function to disable/enable init script link of one run level
>> +# $1 should be K/S, means to disable/enable
>> +# $2 means which run level to disable/enable
>> +renamelink()
>> +{
>> +??? local oldstartstop newstartstop lev oldnn newnn
>> +??? if [ "x$1" = "xS" ]; then
>> +??????? oldstartstop="K"
>> +??????? newstartstop="S"
>> +??? else
>> +??????? oldstartstop="S"
>> +??????? newstartstop="K"
>> +??? fi
>> +
>> +??? lev=$2
>> +??? # modifies existing runlevel links for the script 
>> /etc/init.d/name by renaming start links to stop link
>> +??????? # or stop link to start link with a sequence number equal to 
>> the difference of 100 minus the original sequence number.
>> +??? if ls ${etcd}${lev}.d/${oldstartstop}*${bn} >/dev/null 2>&1; then
>> +??????? oldnn=`basename ${etcd}${lev}.d/${oldstartstop}*${bn}|cut 
>> -c2-3`
>> +??????? newnn=$[100-$oldnn]
>> +??????? [ $verbose -eq 1 ] && echo "rename 
>> ${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} -> 
>> ${etcd}${lev}.d/${newstartstop}${newnn}${bn}"
>> +??????? if [ $notreally -eq 0 ];then
>> +??????????? mv ${etcd}${lev}.d/${oldstartstop}${oldnn}${bn} 
>> ${etcd}${lev}.d/${newstartstop}${newnn}${bn}
>> +??????? fi
>> +??????? if [ $dostart -eq 1 ] && [ $newstartstop = "S" ] && [ $lev = 
>> $RUNLEVEL ]; then
>> +??????????? $fn start || true
>> +??????? fi
>> +??? fi
>> +
>> +}
>> +
>> +# function to disable/enable init script link
>> +# $1 should be K/S, means to disable/enable
>> +# $2 run level [S|2|3|4|5], optional, If no start runlevel is
>> +# specified after the disable or enable keywords
>> +# the script will attempt to modify links in all start runlevels
>> +renamelinks()
>> +{
>> +??? if [ $# -eq 2 ]; then
>> +??????? renamelink $1 $2
>> +??? else
>> +??????? for i in 2 3 4 5 S; do
>> +??????????? renamelink $1 $i
>> +??????? done
>> +??? fi
>> +}
>> +
>> ? while [ $# -gt 0 ]; do
>> ????? case $1 in
>> ????????? -n)??? notreally=1
>> @@ -221,6 +269,13 @@ case $1 in
>> ????????? ;;
>> ? ????? start | stop)
>> +??????? if [ $# -lt 4 ]
>> +??????? then
>> +??????????? echo "Not enough arguments"
>> +??????????? usage
>> +??????????? exit 1
>> +??????? fi
>> +
>> ????????? while [ $# -gt 0 ]; do
>> ????????????? if [ $1 = "start" ]; then
>> ????????????????? letter=S
>> @@ -251,6 +306,32 @@ case $1 in
>> ????????? makelinks
>> ????????? ;;
>> ? +??? enable | disable)
>> +??????? if [ $1 = "enable" ]; then
>> +??????????? letter=S
>> +??????? elif [ $1 = "disable" ]; then
>> +??????????? letter=K
>> +??????? else
>> +??????????? usage
>> +??????????? exit 1
>> +??????? fi
>> +??????? shift
>> +??????? #
>> +??????? if [ $# -gt 0 ]
>> +??????? then
>> +??????????? case $1 in
>> +??????????????? S|2|3|4|5)
>> +??????????????????? renamelinks $letter $1
>> +??????????????????? ;;
>> +??????????????? *)
>> +??????????????????? usage
>> +??????????????????? exit 1
>> +??????????????????? ;;
>> +??????????? esac
>> +??????? else
>> +??????????? renamelinks $letter
>> +??????? fi
>> +??????? ;;
>> ????? *)
>> ????????? usage
>> ????????? exit 1
>
-- 
BRs

Sandy(Li Changqing)


From moritz.porst at gmx.de  Sun Jun 16 23:23:27 2019
From: moritz.porst at gmx.de (Moritz Porst)
Date: Mon, 17 Jun 2019 08:23:27 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
	<bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
Message-ID: <7935c256-d143-e826-8021-db787d98477c@gmx.de>

Hello Stefano,
Thanks very much for your answer

On 14.06.19 14:14, Stefano Babic wrote:
> Hi Moritz,
>
> On 14/06/19 12:19, Moritz Porst wrote:
>> (Sorry, the answer should go to everyone)
>> Thanks for your response, unfortunately it didn't work out for me.
>> Because I am not 100% sure whether I did the correct thing I describe it:
>> In my layer I went to recipes-kernel/kernel/files, here I added a file
>> defconfig which I filled with the content of your config-initramfs
>> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
>> file added so it reads (in its entirety):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>> SRC_URI += "file://0001-sdcard-power-management-off.patch"
>> SRC_URI += "file://defconfig"
>>
>> However I *also* have a file called defconfig in meta-swupdate which is
>> basically the swupdate config that comes from menuconfig. I let this
>> untouched but since this is not the kernel defconfig I guess you didn't
>> mean this file ?
>>
>> Additionally I can't mount the rootfs with the failed boot so I cannot
>> access the dmesg log file. Any advice here ?
>>
>> Best regards
>> Moritz
>>
>>
>>
>> *Gesendet:*?Freitag, 14. Juni 2019 um 11:00 Uhr
>> *Von:*?"Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
>> *An:*?"Moritz Porst" <Moritz.Porst at gmx.de>
>> *Cc:*?"Yocto Project" <yocto at yoctoproject.org>
>> *Betreff:*?Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>>> However if I abort the update while running (i.e. simulating a power cut)
>>> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
>>> unknown block". My understanding is that I should at least end up in a
>>> busybox or that the update is retried, but this does not happen.
>> You missed to attach failed dmesg while the system booted and aborted.
>> Nevertheless, I expect problem with your defconfig, which does NOT
>> have options set for initramfs. These ones:
>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>>
>> Please, could you add these one to your current .config, this might
>> very well solve your problem.
>>
>> Best Regards,
>> Zoran
>> _______
>>
>> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>>> Hello,
>>>
>>> I am currently having trouble to get swupdate working properly.
>>> My problem:
>>> I can execute swupdate -i normally and if the update fits I have no
>> problem. However if I abort the update while running (i.e. simulating a
>> power cut) and then reboot I end up in a kernel panic: "Unable to mount
>> rootfs on unknown block". My understanding is that I should at least end
>> up in a busybox or that the update is retried, but this does not happen.
>>> I receive 1 error when updating which does not stop the update: "Could
>> not find MTD".
>>> My configuration:
>>> I have a single rootfs and a separate boot partition. I build the
>> initramfs using:
> You have a *single* rootfs, you stop an upgrade (resulting of course in
> a corrupted rootfs or worse), and you wonder that kernel cannot mount
> it....your update concept is broken.
Well conceptually I want to go through the bootloader, I just fail to
understand how I tell swupdate to do this.
>
> You *must* check the bootloader marker in U-Boot (default is the
> "recovery_status" variable) and you *mus*t start again the updater (the
> ramdisk) until the marker (it is a transaction flag) is set. It is
> erased by SWUpdate only after a successful update. You are now starting
> your board with a half-completed update.

So I configured swupdate in menuconfig to work with grub which I set in
my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
work with grub ? (I prefer to stick to EFI because partitioning of
images works out of the box with .wic images)
When you say "you must start again the updater", that's where I'm lost.
 From the documentation I understand that I initiate an update using
"swupdate -i abc.swu" but this just runs the update without setting any
flag for the bootloader.
One more thing: swupdate complains that there is no grubenv file. I
defined a path in the config file and create this file using
"grub-editenv /path/as/in/config create". swupdate does not give an
error after I have done this.

>
> Best regards,
> Stefano Babic

Best regards
Moritz

>
>
>>> ---
>>> IMAGE_INSTALL = "base-files \
>>> base-passwd \
>>> swupdate \
>>> busybox \
>>> libconfig \
>>> util-linux-sfdisk \
>>> mtd-utils \
>>> mtd-utils-ubifs \
>>> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>>> "
>>> ---
>>> This is taken from swupdate-image. I include the same packages (via
>> _append) in my base image, is this necessary ?
>>> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>>>
>>> Can you see a mistake I made ?
>>>
>>> Best regards
>>> Moritz
>>> --
>>> _______________________________________________
>>> yocto mailing list
>>> yocto at yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/e1176810/attachment-0001.html>

From sbabic at denx.de  Mon Jun 17 00:19:32 2019
From: sbabic at denx.de (Stefano Babic)
Date: Mon, 17 Jun 2019 09:19:32 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <7935c256-d143-e826-8021-db787d98477c@gmx.de>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
	<bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
	<7935c256-d143-e826-8021-db787d98477c@gmx.de>
Message-ID: <68a5877c-3299-1ab2-a273-fe98ea5eb965@denx.de>

Hi Moritz,

On 17/06/19 08:23, Moritz Porst wrote:
> Hello Stefano,
> Thanks very much for your answer
> 
> On 14.06.19 14:14, Stefano Babic wrote:
>> Hi Moritz,
>>
>> On 14/06/19 12:19, Moritz Porst wrote:
>>> (Sorry, the answer should go to everyone)
>>> Thanks for your response, unfortunately it didn't work out for me.
>>> Because I am not 100% sure whether I did the correct thing I describe it:
>>> In my layer I went to recipes-kernel/kernel/files, here I added a file
>>> defconfig which I filled with the content of your config-initramfs
>>> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
>>> file added so it reads (in its entirety):
>>> ?
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>> SRC_URI += "file://0001-sdcard-power-management-off.patch"
>>> SRC_URI += "file://defconfig"
>>> ?
>>> However I *also* have a file called defconfig in meta-swupdate which is
>>> basically the swupdate config that comes from menuconfig. I let this
>>> untouched but since this is not the kernel defconfig I guess you didn't
>>> mean this file ?
>>> ?
>>> Additionally I can't mount the rootfs with the failed boot so I cannot
>>> access the dmesg log file. Any advice here ?
>>> ?
>>> Best regards
>>> Moritz
>>> ?
>>> ?
>>> ?
>>> *Gesendet:*?Freitag, 14. Juni 2019 um 11:00 Uhr
>>> *Von:*?"Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
>>> *An:*?"Moritz Porst" <Moritz.Porst at gmx.de>
>>> *Cc:*?"Yocto Project" <yocto at yoctoproject.org>
>>> *Betreff:*?Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>>>> However if I abort the update while running (i.e. simulating a power cut)
>>>> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
>>>> unknown block". My understanding is that I should at least end up in a
>>>> busybox or that the update is retried, but this does not happen.
>>> You missed to attach failed dmesg while the system booted and aborted.
>>> Nevertheless, I expect problem with your defconfig, which does NOT
>>> have options set for initramfs. These ones:
>>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>>>
>>> Please, could you add these one to your current .config, this might
>>> very well solve your problem.
>>>
>>> Best Regards,
>>> Zoran
>>> _______
>>>
>>> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>>>> Hello,
>>>>
>>>> I am currently having trouble to get swupdate working properly.
>>>> My problem:
>>>> I can execute swupdate -i normally and if the update fits I have no
>>> problem. However if I abort the update while running (i.e. simulating a
>>> power cut) and then reboot I end up in a kernel panic: "Unable to mount
>>> rootfs on unknown block". My understanding is that I should at least end
>>> up in a busybox or that the update is retried, but this does not happen.
>>>> I receive 1 error when updating which does not stop the update: "Could
>>> not find MTD".
>>>> My configuration:
>>>> I have a single rootfs and a separate boot partition. I build the
>>> initramfs using:
>> You have a *single* rootfs, you stop an upgrade (resulting of course in
>> a corrupted rootfs or worse), and you wonder that kernel cannot mount
>> it....your update concept is broken.
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>> You *must* check the bootloader marker in U-Boot (default is the
>> "recovery_status" variable) and you *mus*t start again the updater (the
>> ramdisk) until the marker (it is a transaction flag) is set. It is
>> erased by SWUpdate only after a successful update. You are now starting
>> your board with a half-completed update.
> 
> So I configured swupdate in menuconfig to work with grub which I set in
> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
> work with grub ?

Yes, but you have to set / configure yourself how Grub start, that is a
suitable grub.cfg where variables in grubenv are evalutated (do not
forget load_env in grub.cfg).

The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
variables, but it is duty of bootloader to evaluated them.

> (I prefer to stick to EFI because partitioning of
> images works out of the box with .wic images)
> When you say "you must start again the updater", that's where I'm lost.
> From the documentation I understand that I initiate an update using
> "swupdate -i abc.swu" but this just runs the update without setting any
> flag for the bootloader.

SWUpdate sets

> One more thing: swupdate complains that there is no grubenv file.

Then it does not work, you have to fix it...

> I
> defined a path in the config file and create this file using
> "grub-editenv /path/as/in/config create".

Grubenv is just a simple 1KB file, you can dump it.

> swupdate does not give an
> error after I have done this.

If the interface to bootloader (for grub, this means grubenv) is
specified and correct, SWUpdate will set the variable "recovery_status"
as transaction flag. You have to evaluate it in grub.cfg and start the
ramdisk again if the variable is set.

Best regards,
Stefano Babic

> 
>> Best regards,
>> Stefano Babic
> 
> Best regards
> Moritz
> 
>>
>>>> ---
>>>> IMAGE_INSTALL = "base-files \
>>>> base-passwd \
>>>> swupdate \
>>>> busybox \
>>>> libconfig \
>>>> util-linux-sfdisk \
>>>> mtd-utils \
>>>> mtd-utils-ubifs \
>>>> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>>> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>>>> "
>>>> ---
>>>> This is taken from swupdate-image. I include the same packages (via
>>> _append) in my base image, is this necessary ?
>>>> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>>>>
>>>> Can you see a mistake I made ?
>>>>
>>>> Best regards
>>>> Moritz
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
> 

From moritz.porst at gmx.de  Mon Jun 17 02:57:02 2019
From: moritz.porst at gmx.de (Moritz Porst)
Date: Mon, 17 Jun 2019 11:57:02 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <68a5877c-3299-1ab2-a273-fe98ea5eb965@denx.de>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
	<bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
	<7935c256-d143-e826-8021-db787d98477c@gmx.de>
	<68a5877c-3299-1ab2-a273-fe98ea5eb965@denx.de>
Message-ID: <a42b0c0a-bf68-92c0-1e91-d767485b7de8@gmx.de>

Hi Stefano

On 17.06.19 09:19, Stefano Babic wrote:
> Hi Moritz,
>
> On 17/06/19 08:23, Moritz Porst wrote:
>> Hello Stefano,
>> Thanks very much for your answer
>>
>> On 14.06.19 14:14, Stefano Babic wrote:
>>> Hi Moritz,
>>>
>>> On 14/06/19 12:19, Moritz Porst wrote:
>>>> (Sorry, the answer should go to everyone)
>>>> Thanks for your response, unfortunately it didn't work out for me.
>>>> Because I am not 100% sure whether I did the correct thing I describe it:
>>>> In my layer I went to recipes-kernel/kernel/files, here I added a file
>>>> defconfig which I filled with the content of your config-initramfs
>>>> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
>>>> file added so it reads (in its entirety):
>>>>
>>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>>> SRC_URI += "file://0001-sdcard-power-management-off.patch"
>>>> SRC_URI += "file://defconfig"
>>>>
>>>> However I *also* have a file called defconfig in meta-swupdate which is
>>>> basically the swupdate config that comes from menuconfig. I let this
>>>> untouched but since this is not the kernel defconfig I guess you didn't
>>>> mean this file ?
>>>>
>>>> Additionally I can't mount the rootfs with the failed boot so I cannot
>>>> access the dmesg log file. Any advice here ?
>>>>
>>>> Best regards
>>>> Moritz
>>>>
>>>>
>>>>
>>>> *Gesendet:*?Freitag, 14. Juni 2019 um 11:00 Uhr
>>>> *Von:*?"Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
>>>> *An:*?"Moritz Porst" <Moritz.Porst at gmx.de>
>>>> *Cc:*?"Yocto Project" <yocto at yoctoproject.org>
>>>> *Betreff:*?Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>>>>> However if I abort the update while running (i.e. simulating a power cut)
>>>>> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
>>>>> unknown block". My understanding is that I should at least end up in a
>>>>> busybox or that the update is retried, but this does not happen.
>>>> You missed to attach failed dmesg while the system booted and aborted.
>>>> Nevertheless, I expect problem with your defconfig, which does NOT
>>>> have options set for initramfs. These ones:
>>>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>>>>
>>>> Please, could you add these one to your current .config, this might
>>>> very well solve your problem.
>>>>
>>>> Best Regards,
>>>> Zoran
>>>> _______
>>>>
>>>> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>>>>> Hello,
>>>>>
>>>>> I am currently having trouble to get swupdate working properly.
>>>>> My problem:
>>>>> I can execute swupdate -i normally and if the update fits I have no
>>>> problem. However if I abort the update while running (i.e. simulating a
>>>> power cut) and then reboot I end up in a kernel panic: "Unable to mount
>>>> rootfs on unknown block". My understanding is that I should at least end
>>>> up in a busybox or that the update is retried, but this does not happen.
>>>>> I receive 1 error when updating which does not stop the update: "Could
>>>> not find MTD".
>>>>> My configuration:
>>>>> I have a single rootfs and a separate boot partition. I build the
>>>> initramfs using:
>>> You have a *single* rootfs, you stop an upgrade (resulting of course in
>>> a corrupted rootfs or worse), and you wonder that kernel cannot mount
>>> it....your update concept is broken.
>> Well conceptually I want to go through the bootloader, I just fail to
>> understand how I tell swupdate to do this.
>>> You *must* check the bootloader marker in U-Boot (default is the
>>> "recovery_status" variable) and you *mus*t start again the updater (the
>>> ramdisk) until the marker (it is a transaction flag) is set. It is
>>> erased by SWUpdate only after a successful update. You are now starting
>>> your board with a half-completed update.
>> So I configured swupdate in menuconfig to work with grub which I set in
>> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
>> work with grub ?
> Yes, but you have to set / configure yourself how Grub start, that is a
> suitable grub.cfg where variables in grubenv are evalutated (do not
> forget load_env in grub.cfg).

Ok I was not aware about this. my grub.cfg now reads:
entry {
load_env
linux ./bzImage [options...]
initrd microcode.cpio
}

>
> The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
> variables, but it is duty of bootloader to evaluated them.
>
>> (I prefer to stick to EFI because partitioning of
>> images works out of the box with .wic images)
>> When you say "you must start again the updater", that's where I'm lost.
>>  From the documentation I understand that I initiate an update using
>> "swupdate -i abc.swu" but this just runs the update without setting any
>> flag for the bootloader.
> SWUpdate sets

I have an update that is actually too large for the rootfs partition to
produce an update failure. SWUpdate then sets recovery_status=failed. On
boot I end up in a kernel panic
If I power off before the update finishes I get no recovery_status in
grubenv.
Manually adding recovery_status=in_progress also does not work (of
course maintaining the 1024 file size). "Does not work" means I end up
in a kernel panic.

>
>> One more thing: swupdate complains that there is no grubenv file.
> Then it does not work, you have to fix it...
>
>> I
>> defined a path in the config file and create this file using
>> "grub-editenv /path/as/in/config create".
> Grubenv is just a simple 1KB file, you can dump it.
>
>> swupdate does not give an
>> error after I have done this.
> If the interface to bootloader (for grub, this means grubenv) is
> specified and correct, SWUpdate will set the variable "recovery_status"
> as transaction flag. You have to evaluate it in grub.cfg and start the
> ramdisk again if the variable is set.

This confuses me. The only way I see of making swupdate set
"recovery_status" is to invoke swupdate -i updatefile.swu. However this
immediately invokes the update, no chance for me to intercept or "start
the ramdisk again".

I have a feeling that I misunderstand something about the ramdisk. To my
understanding this is the microcode.cpio file which is invoked lastly in
the grub entry. It then should execute the swupdate init scripts I guess
? They again should be able to understand the recovery_status variable
and interpret it.
Is this correct or am I entirely wrong about it ? Sorry for the trouble
but I feel a bit lost here.

Best regards
Moritz

>
> Best regards,
> Stefano Babic
>
>>> Best regards,
>>> Stefano Babic
>> Best regards
>> Moritz
>>
>>>>> ---
>>>>> IMAGE_INSTALL = "base-files \
>>>>> base-passwd \
>>>>> swupdate \
>>>>> busybox \
>>>>> libconfig \
>>>>> util-linux-sfdisk \
>>>>> mtd-utils \
>>>>> mtd-utils-ubifs \
>>>>> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>>>> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>>>>> "
>>>>> ---
>>>>> This is taken from swupdate-image. I include the same packages (via
>>>> _append) in my base image, is this necessary ?
>>>>> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>>>>>
>>>>> Can you see a mistake I made ?
>>>>>
>>>>> Best regards
>>>>> Moritz
>>>>> --
>>>>> _______________________________________________
>>>>> yocto mailing list
>>>>> yocto at yoctoproject.org
>>>>> https://lists.yoctoproject.org/listinfo/yocto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/3f9b49d9/attachment-0001.html>

From zoran.stojsavljevic at gmail.com  Mon Jun 17 03:55:42 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Mon, 17 Jun 2019 12:55:42 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <a42b0c0a-bf68-92c0-1e91-d767485b7de8@gmx.de>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
	<bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
	<7935c256-d143-e826-8021-db787d98477c@gmx.de>
	<68a5877c-3299-1ab2-a273-fe98ea5eb965@denx.de>
	<a42b0c0a-bf68-92c0-1e91-d767485b7de8@gmx.de>
Message-ID: <CAGAf8Ly+kKCeK5KVxh1qAQp8CRwOks5et+phN2Sju9PBhPORUA@mail.gmail.com>

> I have a feeling that I misunderstand something about the ramdisk.
> To my understanding this is the microcode.cpio file which is invoked
> lastly in the grub entry.

Being you, I would for the starters exclude swupdate layer and see if
everything works without swupdate: does normally work with initramfs
(from grub). Maybe it works already.

But this is only me with my hints.

Zoran
_______

On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst <moritz.porst at gmx.de> wrote:
>
> Hi Stefano
>
> On 17.06.19 09:19, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 17/06/19 08:23, Moritz Porst wrote:
>
> Hello Stefano,
> Thanks very much for your answer
>
> On 14.06.19 14:14, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 14/06/19 12:19, Moritz Porst wrote:
>
> (Sorry, the answer should go to everyone)
> Thanks for your response, unfortunately it didn't work out for me.
> Because I am not 100% sure whether I did the correct thing I describe it:
> In my layer I went to recipes-kernel/kernel/files, here I added a file
> defconfig which I filled with the content of your config-initramfs
> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
> file added so it reads (in its entirety):
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0001-sdcard-power-management-off.patch"
> SRC_URI += "file://defconfig"
>
> However I *also* have a file called defconfig in meta-swupdate which is
> basically the swupdate config that comes from menuconfig. I let this
> untouched but since this is not the kernel defconfig I guess you didn't
> mean this file ?
>
> Additionally I can't mount the rootfs with the failed boot so I cannot
> access the dmesg log file. Any advice here ?
>
> Best regards
> Moritz
>
>
>
> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
> *Von:* "Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
> *An:* "Moritz Porst" <Moritz.Porst at gmx.de>
> *Cc:* "Yocto Project" <yocto at yoctoproject.org>
> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>
> However if I abort the update while running (i.e. simulating a power cut)
> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
> unknown block". My understanding is that I should at least end up in a
> busybox or that the update is retried, but this does not happen.
>
> You missed to attach failed dmesg while the system booted and aborted.
> Nevertheless, I expect problem with your defconfig, which does NOT
> have options set for initramfs. These ones:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>
> Please, could you add these one to your current .config, this might
> very well solve your problem.
>
> Best Regards,
> Zoran
> _______
>
> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>
> Hello,
>
> I am currently having trouble to get swupdate working properly.
> My problem:
> I can execute swupdate -i normally and if the update fits I have no
>
> problem. However if I abort the update while running (i.e. simulating a
> power cut) and then reboot I end up in a kernel panic: "Unable to mount
> rootfs on unknown block". My understanding is that I should at least end
> up in a busybox or that the update is retried, but this does not happen.
>
> I receive 1 error when updating which does not stop the update: "Could
>
> not find MTD".
>
> My configuration:
> I have a single rootfs and a separate boot partition. I build the
>
> initramfs using:
>
> You have a *single* rootfs, you stop an upgrade (resulting of course in
> a corrupted rootfs or worse), and you wonder that kernel cannot mount
> it....your update concept is broken.
>
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>
> You *must* check the bootloader marker in U-Boot (default is the
> "recovery_status" variable) and you *mus*t start again the updater (the
> ramdisk) until the marker (it is a transaction flag) is set. It is
> erased by SWUpdate only after a successful update. You are now starting
> your board with a half-completed update.
>
> So I configured swupdate in menuconfig to work with grub which I set in
> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
> work with grub ?
>
> Yes, but you have to set / configure yourself how Grub start, that is a
> suitable grub.cfg where variables in grubenv are evalutated (do not
> forget load_env in grub.cfg).
>
> Ok I was not aware about this. my grub.cfg now reads:
> entry {
> load_env
> linux ./bzImage [options...]
> initrd microcode.cpio
> }
>
> The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
> variables, but it is duty of bootloader to evaluated them.
>
> (I prefer to stick to EFI because partitioning of
> images works out of the box with .wic images)
> When you say "you must start again the updater", that's where I'm lost.
> From the documentation I understand that I initiate an update using
> "swupdate -i abc.swu" but this just runs the update without setting any
> flag for the bootloader.
>
> SWUpdate sets
>
> I have an update that is actually too large for the rootfs partition to produce an update failure. SWUpdate then sets recovery_status=failed. On boot I end up in a kernel panic
> If I power off before the update finishes I get no recovery_status in grubenv.
> Manually adding recovery_status=in_progress also does not work (of course maintaining the 1024 file size). "Does not work" means I end up in a kernel panic.
>
>
> One more thing: swupdate complains that there is no grubenv file.
>
> Then it does not work, you have to fix it...
>
> I
> defined a path in the config file and create this file using
> "grub-editenv /path/as/in/config create".
>
> Grubenv is just a simple 1KB file, you can dump it.
>
> swupdate does not give an
> error after I have done this.
>
> If the interface to bootloader (for grub, this means grubenv) is
> specified and correct, SWUpdate will set the variable "recovery_status"
> as transaction flag. You have to evaluate it in grub.cfg and start the
> ramdisk again if the variable is set.
>
> This confuses me. The only way I see of making swupdate set "recovery_status" is to invoke swupdate -i updatefile.swu. However this immediately invokes the update, no chance for me to intercept or "start the ramdisk again".
>
> I have a feeling that I misunderstand something about the ramdisk. To my understanding this is the microcode.cpio file which is invoked lastly in the grub entry. It then should execute the swupdate init scripts I guess ? They again should be able to understand the recovery_status variable and interpret it.
> Is this correct or am I entirely wrong about it ? Sorry for the trouble but I feel a bit lost here.
>
> Best regards
> Moritz
>
> Best regards,
> Stefano Babic
>
> Best regards,
> Stefano Babic
>
> Best regards
> Moritz
>
> ---
> IMAGE_INSTALL = "base-files \
> base-passwd \
> swupdate \
> busybox \
> libconfig \
> util-linux-sfdisk \
> mtd-utils \
> mtd-utils-ubifs \
> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>
> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>
> "
> ---
> This is taken from swupdate-image. I include the same packages (via
>
> _append) in my base image, is this necessary ?
>
> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>
> Can you see a mistake I made ?
>
> Best regards
> Moritz
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From gabbla.malist at gmail.com  Mon Jun 17 04:31:27 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Mon, 17 Jun 2019 13:31:27 +0200
Subject: [yocto] Share SSTATE_DIR between instances
Message-ID: <CAAx3WaCCPCnnTmwtr6p=nZ1Z2CG=Ohq8JHzuGTcWZx-ZYrkxGA@mail.gmail.com>

Hi all,

is it a good idea to share the SSTATE_DIR between a docker container (used
with GitLab pipelines) and the local bitbake instance? They both work on
the same MACHINE.

Gabriele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/4c608d25/attachment.html>

From star at gmx.li  Mon Jun 17 05:03:01 2019
From: star at gmx.li (Arno Steffens)
Date: Mon, 17 Jun 2019 14:03:01 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
Message-ID: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>

I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
Target system is a Zynq7020 system.

From ross.burton at intel.com  Mon Jun 17 05:03:30 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Mon, 17 Jun 2019 13:03:30 +0100
Subject: [yocto] Share SSTATE_DIR between instances
In-Reply-To: <CAAx3WaCCPCnnTmwtr6p=nZ1Z2CG=Ohq8JHzuGTcWZx-ZYrkxGA@mail.gmail.com>
References: <CAAx3WaCCPCnnTmwtr6p=nZ1Z2CG=Ohq8JHzuGTcWZx-ZYrkxGA@mail.gmail.com>
Message-ID: <CAJTo0Laj3JiNaQTEg6sx=3xgJ3UM464XEqc+31opRvKYXaLV_Q@mail.gmail.com>

It's always a good idea to share sstate between builds.

Ross

On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri <gabbla.malist at gmail.com> wrote:
>
> Hi all,
>
> is it a good idea to share the SSTATE_DIR between a docker container (used with GitLab pipelines) and the local bitbake instance? They both work on the same MACHINE.
>
> Gabriele
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From gabbla.malist at gmail.com  Mon Jun 17 05:12:23 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Mon, 17 Jun 2019 14:12:23 +0200
Subject: [yocto] Share SSTATE_DIR between instances
In-Reply-To: <CAJTo0Laj3JiNaQTEg6sx=3xgJ3UM464XEqc+31opRvKYXaLV_Q@mail.gmail.com>
References: <CAAx3WaCCPCnnTmwtr6p=nZ1Z2CG=Ohq8JHzuGTcWZx-ZYrkxGA@mail.gmail.com>
	<CAJTo0Laj3JiNaQTEg6sx=3xgJ3UM464XEqc+31opRvKYXaLV_Q@mail.gmail.com>
Message-ID: <CAAx3WaDpj9CA9wYxApVEQaDZj9h2SJpq_nKQMG4Pnv5buLakgg@mail.gmail.com>

Cool, thanks!

Gabriele

Il giorno lun 17 giu 2019 alle ore 14:03 Burton, Ross <ross.burton at intel.com>
ha scritto:

> It's always a good idea to share sstate between builds.
>
> Ross
>
> On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri <gabbla.malist at gmail.com>
> wrote:
> >
> > Hi all,
> >
> > is it a good idea to share the SSTATE_DIR between a docker container
> (used with GitLab pipelines) and the local bitbake instance? They both work
> on the same MACHINE.
> >
> > Gabriele
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/22d0f4f9/attachment-0001.html>

From moritz.porst at gmx.de  Mon Jun 17 05:13:50 2019
From: moritz.porst at gmx.de (Moritz Porst)
Date: Mon, 17 Jun 2019 14:13:50 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <CAGAf8Ly+kKCeK5KVxh1qAQp8CRwOks5et+phN2Sju9PBhPORUA@mail.gmail.com>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
	<bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
	<7935c256-d143-e826-8021-db787d98477c@gmx.de>
	<68a5877c-3299-1ab2-a273-fe98ea5eb965@denx.de>
	<a42b0c0a-bf68-92c0-1e91-d767485b7de8@gmx.de>
	<CAGAf8Ly+kKCeK5KVxh1qAQp8CRwOks5et+phN2Sju9PBhPORUA@mail.gmail.com>
Message-ID: <fa201976-fef8-e2d5-533b-4528611aa931@gmx.de>

Hi Zoran

On 17.06.19 12:55, Zoran Stojsavljevic wrote:
>> I have a feeling that I misunderstand something about the ramdisk.
>> To my understanding this is the microcode.cpio file which is invoked
>> lastly in the grub entry.
> Being you, I would for the starters exclude swupdate layer and see if
> everything works without swupdate: does normally work with initramfs
> (from grub). Maybe it works already.

I see the bundle_initramfs task being executed if I do any changes. The
boot process works without swupdate in the image. If anything was wrong
with the initramfs the whole system shouldn't be able to boot properly.
I don't get what you suggest me to try.

Best regards

Moritz

>
> But this is only me with my hints.
>
> Zoran
> _______
>
> On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst <moritz.porst at gmx.de> wrote:
>> Hi Stefano
>>
>> On 17.06.19 09:19, Stefano Babic wrote:
>>
>> Hi Moritz,
>>
>> On 17/06/19 08:23, Moritz Porst wrote:
>>
>> Hello Stefano,
>> Thanks very much for your answer
>>
>> On 14.06.19 14:14, Stefano Babic wrote:
>>
>> Hi Moritz,
>>
>> On 14/06/19 12:19, Moritz Porst wrote:
>>
>> (Sorry, the answer should go to everyone)
>> Thanks for your response, unfortunately it didn't work out for me.
>> Because I am not 100% sure whether I did the correct thing I describe it:
>> In my layer I went to recipes-kernel/kernel/files, here I added a file
>> defconfig which I filled with the content of your config-initramfs
>> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
>> file added so it reads (in its entirety):
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>> SRC_URI += "file://0001-sdcard-power-management-off.patch"
>> SRC_URI += "file://defconfig"
>>
>> However I *also* have a file called defconfig in meta-swupdate which is
>> basically the swupdate config that comes from menuconfig. I let this
>> untouched but since this is not the kernel defconfig I guess you didn't
>> mean this file ?
>>
>> Additionally I can't mount the rootfs with the failed boot so I cannot
>> access the dmesg log file. Any advice here ?
>>
>> Best regards
>> Moritz
>>
>>
>>
>> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
>> *Von:* "Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
>> *An:* "Moritz Porst" <Moritz.Porst at gmx.de>
>> *Cc:* "Yocto Project" <yocto at yoctoproject.org>
>> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>>
>> However if I abort the update while running (i.e. simulating a power cut)
>> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
>> unknown block". My understanding is that I should at least end up in a
>> busybox or that the update is retried, but this does not happen.
>>
>> You missed to attach failed dmesg while the system booted and aborted.
>> Nevertheless, I expect problem with your defconfig, which does NOT
>> have options set for initramfs. These ones:
>> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>>
>> Please, could you add these one to your current .config, this might
>> very well solve your problem.
>>
>> Best Regards,
>> Zoran
>> _______
>>
>> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>>
>> Hello,
>>
>> I am currently having trouble to get swupdate working properly.
>> My problem:
>> I can execute swupdate -i normally and if the update fits I have no
>>
>> problem. However if I abort the update while running (i.e. simulating a
>> power cut) and then reboot I end up in a kernel panic: "Unable to mount
>> rootfs on unknown block". My understanding is that I should at least end
>> up in a busybox or that the update is retried, but this does not happen.
>>
>> I receive 1 error when updating which does not stop the update: "Could
>>
>> not find MTD".
>>
>> My configuration:
>> I have a single rootfs and a separate boot partition. I build the
>>
>> initramfs using:
>>
>> You have a *single* rootfs, you stop an upgrade (resulting of course in
>> a corrupted rootfs or worse), and you wonder that kernel cannot mount
>> it....your update concept is broken.
>>
>> Well conceptually I want to go through the bootloader, I just fail to
>> understand how I tell swupdate to do this.
>>
>> You *must* check the bootloader marker in U-Boot (default is the
>> "recovery_status" variable) and you *mus*t start again the updater (the
>> ramdisk) until the marker (it is a transaction flag) is set. It is
>> erased by SWUpdate only after a successful update. You are now starting
>> your board with a half-completed update.
>>
>> So I configured swupdate in menuconfig to work with grub which I set in
>> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
>> work with grub ?
>>
>> Yes, but you have to set / configure yourself how Grub start, that is a
>> suitable grub.cfg where variables in grubenv are evalutated (do not
>> forget load_env in grub.cfg).
>>
>> Ok I was not aware about this. my grub.cfg now reads:
>> entry {
>> load_env
>> linux ./bzImage [options...]
>> initrd microcode.cpio
>> }
>>
>> The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
>> variables, but it is duty of bootloader to evaluated them.
>>
>> (I prefer to stick to EFI because partitioning of
>> images works out of the box with .wic images)
>> When you say "you must start again the updater", that's where I'm lost.
>>  From the documentation I understand that I initiate an update using
>> "swupdate -i abc.swu" but this just runs the update without setting any
>> flag for the bootloader.
>>
>> SWUpdate sets
>>
>> I have an update that is actually too large for the rootfs partition to produce an update failure. SWUpdate then sets recovery_status=failed. On boot I end up in a kernel panic
>> If I power off before the update finishes I get no recovery_status in grubenv.
>> Manually adding recovery_status=in_progress also does not work (of course maintaining the 1024 file size). "Does not work" means I end up in a kernel panic.
>>
>>
>> One more thing: swupdate complains that there is no grubenv file.
>>
>> Then it does not work, you have to fix it...
>>
>> I
>> defined a path in the config file and create this file using
>> "grub-editenv /path/as/in/config create".
>>
>> Grubenv is just a simple 1KB file, you can dump it.
>>
>> swupdate does not give an
>> error after I have done this.
>>
>> If the interface to bootloader (for grub, this means grubenv) is
>> specified and correct, SWUpdate will set the variable "recovery_status"
>> as transaction flag. You have to evaluate it in grub.cfg and start the
>> ramdisk again if the variable is set.
>>
>> This confuses me. The only way I see of making swupdate set "recovery_status" is to invoke swupdate -i updatefile.swu. However this immediately invokes the update, no chance for me to intercept or "start the ramdisk again".
>>
>> I have a feeling that I misunderstand something about the ramdisk. To my understanding this is the microcode.cpio file which is invoked lastly in the grub entry. It then should execute the swupdate init scripts I guess ? They again should be able to understand the recovery_status variable and interpret it.
>> Is this correct or am I entirely wrong about it ? Sorry for the trouble but I feel a bit lost here.
>>
>> Best regards
>> Moritz
>>
>> Best regards,
>> Stefano Babic
>>
>> Best regards,
>> Stefano Babic
>>
>> Best regards
>> Moritz
>>
>> ---
>> IMAGE_INSTALL = "base-files \
>> base-passwd \
>> swupdate \
>> busybox \
>> libconfig \
>> util-linux-sfdisk \
>> mtd-utils \
>> mtd-utils-ubifs \
>> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>>
>> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>>
>> "
>> ---
>> This is taken from swupdate-image. I include the same packages (via
>>
>> _append) in my base image, is this necessary ?
>>
>> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>>
>> Can you see a mistake I made ?
>>
>> Best regards
>> Moritz
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/41ba6b03/attachment.html>

From zoran.stojsavljevic at gmail.com  Mon Jun 17 05:17:46 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Mon, 17 Jun 2019 14:17:46 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
Message-ID: <CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>

Hello Arno,

Your question, per say, has little to do with YOCTO forum. But I'll
try (as my best) to answer your question.

Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).

Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
question is what is T2? T2 is addition to the previous architecture
Cortexa9hf, and addition is Thumb-2 mode.

Hope this helps,

Zoran
_______

On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
>
> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> Target system is a Zynq7020 system.
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From zoran.stojsavljevic at gmail.com  Mon Jun 17 05:34:06 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Mon, 17 Jun 2019 14:34:06 +0200
Subject: [yocto] [meta-swupdate] failed update leads to kernel panic
In-Reply-To: <fa201976-fef8-e2d5-533b-4528611aa931@gmx.de>
References: <trinity-b159ef9f-c6c8-4d3e-bd0b-ca88d3c5596e-1560500116612@3c-app-gmx-bs53>
	<CAGAf8LzTzOPr8p0Jf61tOu2U50fVafFiwV1X3WTVtPEYtv+BXg@mail.gmail.com>
	<trinity-c1af16bc-9d60-4a88-a48b-24690878e39b-1560507591276@3c-app-gmx-bs22>
	<bf5c8bfd-87bd-ddf1-246b-4095c349fca3@denx.de>
	<7935c256-d143-e826-8021-db787d98477c@gmx.de>
	<68a5877c-3299-1ab2-a273-fe98ea5eb965@denx.de>
	<a42b0c0a-bf68-92c0-1e91-d767485b7de8@gmx.de>
	<CAGAf8Ly+kKCeK5KVxh1qAQp8CRwOks5et+phN2Sju9PBhPORUA@mail.gmail.com>
	<fa201976-fef8-e2d5-533b-4528611aa931@gmx.de>
Message-ID: <CAGAf8LxDmPf3uTH2+o6bHtRdydgiu6sfkhdzC1LnEkze4c_2Jg@mail.gmail.com>

> I see the bundle_initramfs task being executed if I do any
> changes. The boot process works without swupdate in the
> image. If anything was wrong with the initramfs the whole
> system shouldn't be able to boot properly. I don't get what
> you suggest me to try.

It is just Divide and Conquer strategy. If you have normal system
working with/transitioning via initramfs, I would assume that there
should be nothing wrong with your initramfs, other than if you cut
power while update is upgrading kernel, and upon (part of kernel
upgrade) it makes/builds new initramfs (it could be very lengthy
process).

My best guess is to exclude from swupdate layer ONLY kernel upgrade,
and see if this helps, and brings you to some better point where you
can understand the problem. Again, Divide and Conquer strategy.

Zoran
_______

On Mon, Jun 17, 2019 at 2:13 PM Moritz Porst <moritz.porst at gmx.de> wrote:
>
> Hi Zoran
>
> On 17.06.19 12:55, Zoran Stojsavljevic wrote:
>
> I have a feeling that I misunderstand something about the ramdisk.
> To my understanding this is the microcode.cpio file which is invoked
> lastly in the grub entry.
>
> Being you, I would for the starters exclude swupdate layer and see if
> everything works without swupdate: does normally work with initramfs
> (from grub). Maybe it works already.
>
> I see the bundle_initramfs task being executed if I do any changes. The boot process works without swupdate in the image. If anything was wrong with the initramfs the whole system shouldn't be able to boot properly. I don't get what you suggest me to try.
>
> Best regards
>
> Moritz
>
> But this is only me with my hints.
>
> Zoran
> _______
>
> On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst <moritz.porst at gmx.de> wrote:
>
> Hi Stefano
>
> On 17.06.19 09:19, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 17/06/19 08:23, Moritz Porst wrote:
>
> Hello Stefano,
> Thanks very much for your answer
>
> On 14.06.19 14:14, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 14/06/19 12:19, Moritz Porst wrote:
>
> (Sorry, the answer should go to everyone)
> Thanks for your response, unfortunately it didn't work out for me.
> Because I am not 100% sure whether I did the correct thing I describe it:
> In my layer I went to recipes-kernel/kernel/files, here I added a file
> defconfig which I filled with the content of your config-initramfs
> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
> file added so it reads (in its entirety):
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0001-sdcard-power-management-off.patch"
> SRC_URI += "file://defconfig"
>
> However I *also* have a file called defconfig in meta-swupdate which is
> basically the swupdate config that comes from menuconfig. I let this
> untouched but since this is not the kernel defconfig I guess you didn't
> mean this file ?
>
> Additionally I can't mount the rootfs with the failed boot so I cannot
> access the dmesg log file. Any advice here ?
>
> Best regards
> Moritz
>
>
>
> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
> *Von:* "Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
> *An:* "Moritz Porst" <Moritz.Porst at gmx.de>
> *Cc:* "Yocto Project" <yocto at yoctoproject.org>
> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>
> However if I abort the update while running (i.e. simulating a power cut)
> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
> unknown block". My understanding is that I should at least end up in a
> busybox or that the update is retried, but this does not happen.
>
> You missed to attach failed dmesg while the system booted and aborted.
> Nevertheless, I expect problem with your defconfig, which does NOT
> have options set for initramfs. These ones:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>
> Please, could you add these one to your current .config, this might
> very well solve your problem.
>
> Best Regards,
> Zoran
> _______
>
> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>
> Hello,
>
> I am currently having trouble to get swupdate working properly.
> My problem:
> I can execute swupdate -i normally and if the update fits I have no
>
> problem. However if I abort the update while running (i.e. simulating a
> power cut) and then reboot I end up in a kernel panic: "Unable to mount
> rootfs on unknown block". My understanding is that I should at least end
> up in a busybox or that the update is retried, but this does not happen.
>
> I receive 1 error when updating which does not stop the update: "Could
>
> not find MTD".
>
> My configuration:
> I have a single rootfs and a separate boot partition. I build the
>
> initramfs using:
>
> You have a *single* rootfs, you stop an upgrade (resulting of course in
> a corrupted rootfs or worse), and you wonder that kernel cannot mount
> it....your update concept is broken.
>
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>
> You *must* check the bootloader marker in U-Boot (default is the
> "recovery_status" variable) and you *mus*t start again the updater (the
> ramdisk) until the marker (it is a transaction flag) is set. It is
> erased by SWUpdate only after a successful update. You are now starting
> your board with a half-completed update.
>
> So I configured swupdate in menuconfig to work with grub which I set in
> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
> work with grub ?
>
> Yes, but you have to set / configure yourself how Grub start, that is a
> suitable grub.cfg where variables in grubenv are evalutated (do not
> forget load_env in grub.cfg).
>
> Ok I was not aware about this. my grub.cfg now reads:
> entry {
> load_env
> linux ./bzImage [options...]
> initrd microcode.cpio
> }
>
> The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
> variables, but it is duty of bootloader to evaluated them.
>
> (I prefer to stick to EFI because partitioning of
> images works out of the box with .wic images)
> When you say "you must start again the updater", that's where I'm lost.
> From the documentation I understand that I initiate an update using
> "swupdate -i abc.swu" but this just runs the update without setting any
> flag for the bootloader.
>
> SWUpdate sets
>
> I have an update that is actually too large for the rootfs partition to produce an update failure. SWUpdate then sets recovery_status=failed. On boot I end up in a kernel panic
> If I power off before the update finishes I get no recovery_status in grubenv.
> Manually adding recovery_status=in_progress also does not work (of course maintaining the 1024 file size). "Does not work" means I end up in a kernel panic.
>
>
> One more thing: swupdate complains that there is no grubenv file.
>
> Then it does not work, you have to fix it...
>
> I
> defined a path in the config file and create this file using
> "grub-editenv /path/as/in/config create".
>
> Grubenv is just a simple 1KB file, you can dump it.
>
> swupdate does not give an
> error after I have done this.
>
> If the interface to bootloader (for grub, this means grubenv) is
> specified and correct, SWUpdate will set the variable "recovery_status"
> as transaction flag. You have to evaluate it in grub.cfg and start the
> ramdisk again if the variable is set.
>
> This confuses me. The only way I see of making swupdate set "recovery_status" is to invoke swupdate -i updatefile.swu. However this immediately invokes the update, no chance for me to intercept or "start the ramdisk again".
>
> I have a feeling that I misunderstand something about the ramdisk. To my understanding this is the microcode.cpio file which is invoked lastly in the grub entry. It then should execute the swupdate init scripts I guess ? They again should be able to understand the recovery_status variable and interpret it.
> Is this correct or am I entirely wrong about it ? Sorry for the trouble but I feel a bit lost here.
>
> Best regards
> Moritz
>
> Best regards,
> Stefano Babic
>
> Best regards,
> Stefano Babic
>
> Best regards
> Moritz
>
> ---
> IMAGE_INSTALL = "base-files \
> base-passwd \
> swupdate \
> busybox \
> libconfig \
> util-linux-sfdisk \
> mtd-utils \
> mtd-utils-ubifs \
> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>
> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>
> "
> ---
> This is taken from swupdate-image. I include the same packages (via
>
> _append) in my base image, is this necessary ?
>
> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>
> Can you see a mistake I made ?
>
> Best regards
> Moritz
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From star at gmx.li  Mon Jun 17 06:00:07 2019
From: star at gmx.li (Arno Steffens)
Date: Mon, 17 Jun 2019 15:00:07 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
Message-ID: <trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>

Hello Zoran,
thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
But I want to keep all compatible to my previous tool-chain and settings.
The only file where I can found this "cortexa9t2hf" is
./meta/conf/machine/include/tune-cortexa9.inc
but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
Or have I been wrong the time before?

bitbake gives me in 2.5:

TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
TARGET_FPU           = "hard"

and in 2.7:
TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
TARGET_FPU           = "hard"

so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
Arno

>
> Hello Arno,
>
> Your question, per say, has little to do with YOCTO forum. But I'll
> try (as my best) to answer your question.
>
> Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
>
> Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> question is what is T2? T2 is addition to the previous architecture
> Cortexa9hf, and addition is Thumb-2 mode.
>
> Hope this helps,
>
> Zoran
> _______
>
> On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> >
> > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > Target system is a Zynq7020 system.
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>

From zoran.stojsavljevic at gmail.com  Mon Jun 17 07:05:15 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Mon, 17 Jun 2019 16:05:15 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
Message-ID: <CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>

Hello Arno,

Let me try to explain my point of view. Since here (my best guess) we
have some asynchronous bitbake code which went South upon introducing
T2 HW extension.

Point [1]: as far as I understand arm, cortexa9t2hf is is just a
superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
media coprocessor) exists in both of them. In other words:
cortexa9t2hf = cortexa9hf HW + T2 HW extension.

Point [2]:
> bitbake gives me in 2.5:
> TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> TARGET_FPU           = "hard"
>
> and in 2.7:
> TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> TARGET_FPU           = "hard"

These two lines are the same: you are able to use 32b arm mode, 16bit
thumb mode, using armv7 HW with neon HW extension, and using HW FP
extension as well. The Cortex in both cases is A9.

I expect that somebody somewhere in bitbake version 1.42 - 100% sure
(since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
and I have no idea if this is done intentionally or not.

Because of that I copied Alex and Ross to CC: into email, so they
should unveil this mystery (I would prefer "armv7" to stay in bitbake
1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).

Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
should return "armv7" as TUNE FEATURE.

Best Regards,
Zoran
_______


On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
>
> Hello Zoran,
> thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> But I want to keep all compatible to my previous tool-chain and settings.
> The only file where I can found this "cortexa9t2hf" is
> ./meta/conf/machine/include/tune-cortexa9.inc
> but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> Or have I been wrong the time before?
>
> bitbake gives me in 2.5:
>
> TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> TARGET_FPU           = "hard"
>
> and in 2.7:
> TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> TARGET_FPU           = "hard"
>
> so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> Arno
>
> >
> > Hello Arno,
> >
> > Your question, per say, has little to do with YOCTO forum. But I'll
> > try (as my best) to answer your question.
> >
> > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> >
> > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > question is what is T2? T2 is addition to the previous architecture
> > Cortexa9hf, and addition is Thumb-2 mode.
> >
> > Hope this helps,
> >
> > Zoran
> > _______
> >
> > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > >
> > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > Target system is a Zynq7020 system.
> > > --
> > > _______________________________________________
> > > yocto mailing list
> > > yocto at yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >

From gabbla.malist at gmail.com  Mon Jun 17 07:19:23 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Mon, 17 Jun 2019 16:19:23 +0200
Subject: [yocto] Running Yocto inside Docker
Message-ID: <CAAx3WaCUb18Yf6Qp33qQCu9O3s-qpa75uoSm+sKv89jR0FbZmQ@mail.gmail.com>

Hi all,

does anyone have a guide on how to setup Yocto to run inside docker? Right
now I managed to trigger the build from GitLab, but I'm facing an issue
related to ssh keys (some recipes from my meta layer are hosted on a
privare repository). Probably this is not the best mailing list to ask this
kind of question, but it may worth a try.

Thank you,
Gabriele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/ccccf414/attachment.html>

From martin.jansa at gmail.com  Mon Jun 17 07:29:09 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Mon, 17 Jun 2019 16:29:09 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
Message-ID: <CA+chaQc3qoGgfaCuxh15DmdNb3BuZJKEWcam6NkZX3auvOLtzA@mail.gmail.com>

See this oe-core commit (from 2.6 Thud):

commit c88304a78e528596ca481cabe273749c286c352a
Author: Andre McCurdy <armccurdy at gmail.com>
Date:   Fri May 18 15:50:40 2018 -0700

    arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above

which enabled Thumb2 by default, if you want to disable it as it was before
set ARM_INSTRUCTION_SET to "arm".

On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:

> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something
> wrong or what exactly does this t2 mean?
> Target system is a Zynq7020 system.
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/520091ad/attachment.html>

From matthias.schoepfer at googlemail.com  Mon Jun 17 08:25:56 2019
From: matthias.schoepfer at googlemail.com (Matthias Schoepfer)
Date: Mon, 17 Jun 2019 17:25:56 +0200
Subject: [yocto] General Question: Device specific value store
Message-ID: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>

Hi!

I have a general, maybe dumb question. Is there a smart, recommended way 
to deal with device specific data (i.e. serial number, credentials for 
backend access, you name it), that is specific for *one* device, and 
hence does not belong into the rootfs. I know, that there are (safe) 
hardware stores for it, but what, if your device does not have one. The 
current approach is to use an additional file system. Is there a good 
way to create huge numbers of such filesystems that just hold different 
values generated of a cvs file or such. What would be the yocto way 
without crafting scripts over scripts?!

Thanks and Regards,

 ?? Matthias


From zoran.stojsavljevic at gmail.com  Mon Jun 17 10:33:01 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Mon, 17 Jun 2019 19:33:01 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <CA+chaQc3qoGgfaCuxh15DmdNb3BuZJKEWcam6NkZX3auvOLtzA@mail.gmail.com>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CA+chaQc3qoGgfaCuxh15DmdNb3BuZJKEWcam6NkZX3auvOLtzA@mail.gmail.com>
Message-ID: <CAGAf8Ly9zs=oCrwRu1HvJJgnrAusKwut44grK3OmoQ_z774-Ug@mail.gmail.com>

> Because of that I copied Alex and Ross to CC: into email, so they
> should unveil this mystery (I would prefer "armv7" to stay in bitbake
> 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).

Sorry, my bad. A15 still belongs to armv7. And now I see/understand
why you removed "armv7". Well... Time Will Tell if this is a good
decision! ;-)

Zoran
_______

On Mon, Jun 17, 2019 at 4:29 PM Martin Jansa <martin.jansa at gmail.com> wrote:
>
> See this oe-core commit (from 2.6 Thud):
>
> commit c88304a78e528596ca481cabe273749c286c352a
> Author: Andre McCurdy <armccurdy at gmail.com>
> Date:   Fri May 18 15:50:40 2018 -0700
>
>     arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above
>
> which enabled Thumb2 by default, if you want to disable it as it was before set ARM_INSTRUCTION_SET to "arm".
>
> On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
>>
>> I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
>> Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
>> Target system is a Zynq7020 system.
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From star at gmx.li  Mon Jun 17 10:47:36 2019
From: star at gmx.li (Arno Steffens)
Date: Mon, 17 Jun 2019 19:47:36 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
	<CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
Message-ID: <trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>

Thanks for explaining this.
I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).

So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.

According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).
On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.

Thanks for you taking the time.
Arno

> Hello Arno,
>
> Let me try to explain my point of view. Since here (my best guess) we
> have some asynchronous bitbake code which went South upon introducing
> T2 HW extension.
>
> Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> media coprocessor) exists in both of them. In other words:
> cortexa9t2hf = cortexa9hf HW + T2 HW extension.
>
> Point [2]:
> > bitbake gives me in 2.5:
> > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > TARGET_FPU           = "hard"
> >
> > and in 2.7:
> > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > TARGET_FPU           = "hard"
>
> These two lines are the same: you are able to use 32b arm mode, 16bit
> thumb mode, using armv7 HW with neon HW extension, and using HW FP
> extension as well. The Cortex in both cases is A9.
>
> I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> and I have no idea if this is done intentionally or not.
>
> Because of that I copied Alex and Ross to CC: into email, so they
> should unveil this mystery (I would prefer "armv7" to stay in bitbake
> 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
>
> Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> should return "armv7" as TUNE FEATURE.
>
> Best Regards,
> Zoran
> _______
>
>
> On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
> >
> > Hello Zoran,
> > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > But I want to keep all compatible to my previous tool-chain and settings.
> > The only file where I can found this "cortexa9t2hf" is
> > ./meta/conf/machine/include/tune-cortexa9.inc
> > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > Or have I been wrong the time before?
> >
> > bitbake gives me in 2.5:
> >
> > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > TARGET_FPU           = "hard"
> >
> > and in 2.7:
> > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > TARGET_FPU           = "hard"
> >
> > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > Arno
> >
> > >
> > > Hello Arno,
> > >
> > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > try (as my best) to answer your question.
> > >
> > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > >
> > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > question is what is T2? T2 is addition to the previous architecture
> > > Cortexa9hf, and addition is Thumb-2 mode.
> > >
> > > Hope this helps,
> > >
> > > Zoran
> > > _______
> > >
> > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > > >
> > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > Target system is a Zynq7020 system.
> > > > --
> > > > _______________________________________________
> > > > yocto mailing list
> > > > yocto at yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> > >
>

From GWilson at sakuraus.com  Mon Jun 17 10:49:58 2019
From: GWilson at sakuraus.com (Greg Wilson-Lindberg)
Date: Mon, 17 Jun 2019 17:49:58 +0000
Subject: [yocto] Am not getting udev-extraconf automount to work
Message-ID: <c09affe2bbd247beb0bd1c82acbafd18@sakuraus.com>

I'm building for a RPi3B using the Qt supplied boot2qt framework on SUMO.
I've added udev-extraconf to pull in automount.rules.

When I plug in a USB thumb drive I get /dev/SDA & /dev/SDA1. I also get /tmp/.automount-sda1 with the time of insertion. I also get /run/media/sda1, and the /var/log/messages file has a message that 'Auto-mount of [/run/media/sda1] successful', but the output of the 'mount' program does?not show the thumb drive mounted, nothing in the output at /run/media/sda1' and the directory is?empty despite the thumb drives that I have tried having files on them.

Anyone have any experience with the automounter?
?

Greg Wilson-Lindberg? 
?

From rudolf.streif at ibeeto.com  Mon Jun 17 11:00:09 2019
From: rudolf.streif at ibeeto.com (Rudolf Streif)
Date: Mon, 17 Jun 2019 11:00:09 -0700
Subject: [yocto] Running Yocto inside Docker
In-Reply-To: <CAAx3WaCUb18Yf6Qp33qQCu9O3s-qpa75uoSm+sKv89jR0FbZmQ@mail.gmail.com>
References: <CAAx3WaCUb18Yf6Qp33qQCu9O3s-qpa75uoSm+sKv89jR0FbZmQ@mail.gmail.com>
Message-ID: <CAPxNcnfeBKEEn-fEW2evxd3O3uVxrFmuOJMb6quwZz=oGpXgYg@mail.gmail.com>

That's more of a Gitlab than Yocto question. I am doing this all the time
with my GL server on AWS. You need to add deploy a key to the repo you want
to access and then push the key to your Docker instance from gitlab-ci.yaml
from the repo that you are using with GL CI.

:rjs

On Mon, Jun 17, 2019, 07:20 Gabriele Zampieri <gabbla.malist at gmail.com>
wrote:

> Hi all,
>
> does anyone have a guide on how to setup Yocto to run inside docker? Right
> now I managed to trigger the build from GitLab, but I'm facing an issue
> related to ssh keys (some recipes from my meta layer are hosted on a
> privare repository). Probably this is not the best mailing list to ask this
> kind of question, but it may worth a try.
>
> Thank you,
> Gabriele
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/e92cbe80/attachment.html>

From samo_pogacnik at t-2.net  Mon Jun 17 11:51:22 2019
From: samo_pogacnik at t-2.net (Samo =?UTF-8?Q?Poga=C4=8Dnik?=)
Date: Mon, 17 Jun 2019 20:51:22 +0200
Subject: [yocto] Bash-based build tool/environment u2up-yocto
Message-ID: <cdb4c491aff4ee234638b33fd2b0d787abc204a8.camel@t-2.net>

Hi,

I am new to the yocto mailing list and i would like to share my bash-based
tool/environment to build a yocto-based linux distribution. The tool/environment
is called u2up-yocto and can be found here: https://github.com/spog/u2up-yocto

Using u2up-yocto, i tried to achieve a few goals:
1) being able to build some default poky machine/image targets out-of-the-box
without manually creating specific build configuration.

2) being able to extend default functionality by adding external/internal
layers, git repos and additional local configuration without modifying any
released u2up-yocto files.

You are welcome to check two sample projects, using u2up-yocto:
- https://github.com/spog/meta-u2up-homegw.git
- https://github.com/spog/meta-u2up-pc-installer.git

3) define a new distro name

4) provide a simple common (cross-projects) downloads and shared-sstate
configuration

best regards, samo




From sjolley.yp.pm at gmail.com  Mon Jun 17 16:29:19 2019
From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com)
Date: Mon, 17 Jun 2019 16:29:19 -0700
Subject: [yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed
Message-ID: <03bd01d52564$7d658460$78308d20$@gmail.com>

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

 

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

 

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 at gmail.com
<mailto:sjolley.yp.pm at gmail.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_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm at gmail.com
<mailto:sjolley.yp.pm at gmail.com> 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/bae4825b/attachment.html>

From stangerm2 at gmail.com  Mon Jun 17 16:54:30 2019
From: stangerm2 at gmail.com (matthew stanger)
Date: Mon, 17 Jun 2019 17:54:30 -0600
Subject: [yocto] devshell env in warrior
Message-ID: <CAGni2MiauEboBBr0qsqn1jB57AQoEEaOw3wRoavnuQX8TJGtNA@mail.gmail.com>

I'm trying to figure out why when running devshell in Warrior CC/CFLAGS are
not the same as do_compile for a recipe. For example.
devshell printenv yields:
CC=aarch64-poky-linux-gcc   -fuse-ld=bfd
-fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot=
-fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=
 -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel

do_compile() {
    /usr/bin/printenv | sort > debug.log
}
yields...
CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto
-fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
-Werror=format-security
--sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot

This causes some very different behavior out of the makefile. The recipe
I"m working with has no do_configure, and only calls a makefile through
do_compile. No appends/prepends or custom functions in the recipe. This
recipe is for a lovely Broadcom driver/userspace glob and I'm trying to
troubleshoot it with x64 but not being able to get a correct working env
makes life hard. Any idea's of where I might be going wrong?

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/922ce04f/attachment.html>

From alex.kanavin at gmail.com  Tue Jun 18 03:58:25 2019
From: alex.kanavin at gmail.com (Alexander Kanavin)
Date: Tue, 18 Jun 2019 12:58:25 +0200
Subject: [yocto] [meta-mono][PATCH] mono-5.xx: fix an issue with too
	long paths in doltlibtool
In-Reply-To: <c545bc49-effe-629d-213c-55d52adcf5c8@dynamicdevices.co.uk>
References: <20190513162531.45297-1-alex.kanavin@gmail.com>
	<CANNYZj8MvEUjB-w+JjBRtbTnjw=B--L36+nXOVDAjzf+suxtcw@mail.gmail.com>
	<c545bc49-effe-629d-213c-55d52adcf5c8@dynamicdevices.co.uk>
Message-ID: <CANNYZj8jy+r9k3WhgpbkzOBKtGoUdiM2PD5Sng_8GgiQ3Z_7sQ@mail.gmail.com>

Ping #2!

Alex

On Mon, 27 May 2019 at 12:22, Alex J Lennon <ajlennon at dynamicdevices.co.uk>
wrote:

>
> Thanks for the reminder Alex
> On 27/05/2019 11:16, Alexander Kanavin wrote:
>
> Ping?
>
> Alex
>
> On Mon, 13 May 2019 at 18:25, Alexander Kanavin <alex.kanavin at gmail.com> <alex.kanavin at gmail.com> wrote:
>
> When build directory is deeply nested, the shebang limit of 127
> characters is hit, which leads to doltlibtool failing to execute.
>
> Signed-off-by: Alexander Kanavin <alex.kanavin at gmail.com> <alex.kanavin at gmail.com>
> ---
>  recipes-mono/mono/mono-5.xx.inc | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
> index c36374c..dec2475 100644
> --- a/recipes-mono/mono/mono-5.xx.inc
> +++ b/recipes-mono/mono/mono-5.xx.inc
> @@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
>
>  # Workaround for observed race in `make install`
>  PARALLEL_MAKEINST=""
> +
> +# Otherwise the full path to bash is written to the first line of doltlibtool script
> +# which causes build failures with deeply nested build directories
> +CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
> --
> 2.17.1
>
>
> --
>
> [image: Dynamic Devices Ltd] <http://www.dynamicdevices.co.uk/>
>
> Alex J Lennon MA (Cantab) MIET MIOD / Director
> DoES Liverpool 1st Floor The Tapestry 68 ? 76 Kempston Street Liverpool L3
> 8HL, United Kingdom
>
> mobile: +44 (0)7478 346120
>
> [image: Linkedin] <http://www.linkedin.com/in/alexjlennon> [image: Skype]
> <http://www.daneurope.org/web/guest/registration?p_p_id=registration&p_p_lifecycle=0&p_p_mode=view&p_p_state=normal&_registration_struts_action=%2Fext%2Fregistration%2Fwizard&_registration_processType=2&_registration_partnerCode=517352>
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. Company Name is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190618/a5dc1789/attachment-0001.html>

From ayaka at soulik.info  Tue Jun 18 08:52:59 2019
From: ayaka at soulik.info (ayaka)
Date: Tue, 18 Jun 2019 23:52:59 +0800
Subject: [yocto] [PATCH 3/3] recipes-bsp/u-boot: update to the latest
 version
In-Reply-To: <CAHUNapTAAg_2iTYFDhX1HsyzDPMW1rTVpnqOt2Bg=peXzgLZFQ@mail.gmail.com>
References: <20190424145918.26040-1-ayaka@soulik.info>
	<20190424145918.26040-4-ayaka@soulik.info>
	<20190504030638.GB26588@linux-uys3>
	<15a392f0-fbec-cfce-980b-6904bf7e222c@soulik.info>
	<20190506133157.GA14979@linux-uys3>
	<4bfa5df9-dc5a-0ecb-c92f-5714ddaf2d89@soulik.info>
	<CAHUNapTAAg_2iTYFDhX1HsyzDPMW1rTVpnqOt2Bg=peXzgLZFQ@mail.gmail.com>
Message-ID: <cb5f9171-49ab-816c-e64a-8fa91a443bd7@soulik.info>


On 09/05/2019 01:30, Trevor Woerner wrote:
> a previous patch of yours did a:
> ??? require recipes-bsp/u-boot/u-boot-common.inc
> which defines this SRCREV
>
> my subtle point being: I don't get the impression you're testing your 
> patches, or at least not testing them correctly.

I did the test before but I forget to remove the variables in local.conf

Anyway I will start a clean build this time.

Now I met a problem with new gcc 9 on the latest oe, I will fix them 
then flush new patches later.

>
> the fact you're CCing Romain suggests your either using a very old 
> branch of https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/ or 
> that you're submitting patches to me for 
> https://github.com/rockchip-linux/meta-rockchip ?
> Unfortunately for me, when 
> https://github.com/rockchip-linux/meta-rockchip did a clone of 
> https://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/, they left 
> my and Romain's names as maintainers in the README (along with 
> instructions for github)
>
> On Wed, May 8, 2019 at 12:19 PM ayaka <ayaka at soulik.info 
> <mailto:ayaka at soulik.info>> wrote:
>
>
>     On 5/6/19 9:31 PM, Trevor Woerner wrote:
>     > On Sat 2019-05-04 @ 06:43:34 PM, ayaka wrote:
>     >> On 5/4/19 11:06 AM, Trevor Woerner wrote:
>     >>> On Wed 2019-04-24 @ 10:59:18 PM, Randy 'ayaka' Li wrote:
>     >>>> From: Randy Li <ayaka at soulik.info <mailto:ayaka at soulik.info>>
>     >>>>
>     >>>> Signed-off-by: Randy Li <ayaka at soulik.info
>     <mailto:ayaka at soulik.info>>
>     >>>> ---
>     >>>>? ? recipes-bsp/u-boot/u-boot-rockchip_git.bb
>     <http://u-boot-rockchip_git.bb> | 18 ++++++++++++++++++
>     >>>>? ? 1 file changed, 18 insertions(+)
>     >>>>? ? create mode 100644
>     recipes-bsp/u-boot/u-boot-rockchip_git.bb
>     <http://u-boot-rockchip_git.bb>
>     >>>>
>     >>>> diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb
>     <http://u-boot-rockchip_git.bb>
>     b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
>     <http://u-boot-rockchip_git.bb>
>     >>>> new file mode 100644
>     >>>> index 0000000..aa4b84d
>     >>>> --- /dev/null
>     >>>> +++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
>     <http://u-boot-rockchip_git.bb>
>     >>>> @@ -0,0 +1,18 @@
>     >>>> +# Copyright (C) 2019 SUMOMO Computer Assocation
>     >>>> +# Released under the MIT license (see COPYING.MIT for the terms)
>     >>>> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>     >>>> +
>     >>>> +include u-boot-rockchip.inc
>     >>>> +
>     >>>> +DESCRIPTION = "Rockchip U-Boot"
>     >>>> +
>     >>>> +LIC_FILES_CHKSUM =
>     "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
>     >>>> +
>     >>>> +SRC_URI = " \
>     >>>> +? git://github.com/rockchip-linux/u-boot.git;branch=release
>     <http://github.com/rockchip-linux/u-boot.git;branch=release>; \
>     >>>> +? file://binutils-2.28-ld-fix.patch \
>     >>>> +? file://gcc7_fixup.patch \
>     >>>> +? "
>     >>>> +
>     >>>> +S = "${WORKDIR}/git"
>     >>>> +PV = "v2019.01"
>     >>> This doesn't even get past the fetching stage:
>     >> I am sorry, I forget that ssh git protocol only work for those
>     users who
>     >> uploaded their key to the github, I would change it back to https.
>     >>>? ? ?WARNING: u-boot-rockchip-1_v2019.01-r0 do_fetch: Failed to
>     fetch URL
>     git://github.com/rockchip-linux/u-boot.git;branch=release
>     <http://github.com/rockchip-linux/u-boot.git;branch=release>;,
>     attempting MIRRORS if available
>     >>>? ? ?ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher
>     failure: Unable to find revision
>     3c99166441bf3ea325af2da83cfe65430b49c066 in branch release even
>     from upstream
>     >>>? ? ?ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Fetcher
>     failure for URL:
>     'git://github.com/rockchip-linux/u-boot.git;branch=release;
>     <http://github.com/rockchip-linux/u-boot.git;branch=release;>'.
>     Unable to fetch URL from any source.
>     >>>? ? ?ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch:
>     >>>? ? ?ERROR: u-boot-rockchip-1_v2019.01-r0 do_fetch: Function
>     failed: base_do_fetch
>     >>>? ? ?ERROR: Task
>     (/opt/oe/configs/z/build-master/meta-rockchip/layers/meta-rockchip/recipes-bsp/u-boot/u-boot-rockchip_git.bb:do_fetch)
>     failed with exit code '1'
>     > The problem is that it's trying to fetch commit 3c9916 which
>     doesn't exist on
>     > github.com/rockchip-linux/u-boot.git
>     <http://github.com/rockchip-linux/u-boot.git>. That revision is on
>     upstream U-Boot.
>     How comes? I didn't write any commit id there, it is based on the
>     branch
>     at all.
>

From raj.khem at gmail.com  Tue Jun 18 09:08:06 2019
From: raj.khem at gmail.com (Khem Raj)
Date: Tue, 18 Jun 2019 09:08:06 -0700
Subject: [yocto] devshell env in warrior
In-Reply-To: <CAGni2MiauEboBBr0qsqn1jB57AQoEEaOw3wRoavnuQX8TJGtNA@mail.gmail.com>
References: <CAGni2MiauEboBBr0qsqn1jB57AQoEEaOw3wRoavnuQX8TJGtNA@mail.gmail.com>
Message-ID: <CAMKF1so4oLnAugjsZ6PwUt-8xBLszbwy45dsgRH02S2y00aMXQ@mail.gmail.com>

On Mon, Jun 17, 2019 at 4:55 PM matthew stanger <stangerm2 at gmail.com> wrote:
>
> I'm trying to figure out why when running devshell in Warrior CC/CFLAGS are not the same as do_compile for a recipe. For example.
> devshell printenv yields:
> CC=aarch64-poky-linux-gcc   -fuse-ld=bfd -fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0 -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0 -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot= -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=  -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel
>
> do_compile() {
>     /usr/bin/printenv | sort > debug.log
> }
> yields...
> CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot
>
> This causes some very different behavior out of the makefile. The recipe I"m working with has no do_configure, and only calls a makefile through do_compile. No appends/prepends or custom functions in the recipe. This recipe is for a lovely Broadcom driver/userspace glob and I'm trying to troubleshoot it with x64 but not being able to get a correct working env makes life hard. Any idea's of where I might be going wrong?
>

Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
Makefiles I have seen doing that, you might see something like

CC = ${CROSS_COMPILE}gcc etc. which you should convert to weak defines
e.g. CC ?= ....

> Cheers
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From raj.khem at gmail.com  Tue Jun 18 09:16:30 2019
From: raj.khem at gmail.com (Khem Raj)
Date: Tue, 18 Jun 2019 09:16:30 -0700
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
	<CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
	<trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
Message-ID: <CAMKF1sqq0vxQUrayZzG02T8ciRe19JJ90-TkNy1Exa16Wz7vng@mail.gmail.com>

On Mon, Jun 17, 2019 at 10:48 AM Arno Steffens <star at gmx.li> wrote:
>
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).
>
> So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.
>
> According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).
> On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.
>
> Thanks for you taking the time.

While the gains/losses from using thumb2 ISA depends upon type of
loads you have and nature of code, in general this is most commonly
used ISA in linux distros, so most of the apps would have
been used compiled with this and probably optimized for as well. I
would advise that you do some bench-marking for your loads and then
decide if using thumb2 ISA is right choice for you or not.

if you want to drop thumb2 you can set appropriate default tune in
your machine config and that will do it

DEFAULTTUNE = "cortexa9hf-neon"


> Arno
>
> > Hello Arno,
> >
> > Let me try to explain my point of view. Since here (my best guess) we
> > have some asynchronous bitbake code which went South upon introducing
> > T2 HW extension.
> >
> > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > media coprocessor) exists in both of them. In other words:
> > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> >
> > Point [2]:
> > > bitbake gives me in 2.5:
> > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > TARGET_FPU           = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU           = "hard"
> >
> > These two lines are the same: you are able to use 32b arm mode, 16bit
> > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > extension as well. The Cortex in both cases is A9.
> >
> > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > and I have no idea if this is done intentionally or not.
> >
> > Because of that I copied Alex and Ross to CC: into email, so they
> > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> >
> > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > should return "armv7" as TUNE FEATURE.
> >
> > Best Regards,
> > Zoran
> > _______
> >
> >
> > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
> > >
> > > Hello Zoran,
> > > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > > But I want to keep all compatible to my previous tool-chain and settings.
> > > The only file where I can found this "cortexa9t2hf" is
> > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > > Or have I been wrong the time before?
> > >
> > > bitbake gives me in 2.5:
> > >
> > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > TARGET_FPU           = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU           = "hard"
> > >
> > > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > > Arno
> > >
> > > >
> > > > Hello Arno,
> > > >
> > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > try (as my best) to answer your question.
> > > >
> > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > >
> > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > question is what is T2? T2 is addition to the previous architecture
> > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > >
> > > > Hope this helps,
> > > >
> > > > Zoran
> > > > _______
> > > >
> > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > > > >
> > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > > Target system is a Zynq7020 system.
> > > > > --
> > > > > _______________________________________________
> > > > > yocto mailing list
> > > > > yocto at yoctoproject.org
> > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > >
> >
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From stangerm2 at gmail.com  Tue Jun 18 10:08:25 2019
From: stangerm2 at gmail.com (matthew stanger)
Date: Tue, 18 Jun 2019 11:08:25 -0600
Subject: [yocto] devshell env in warrior
In-Reply-To: <CAMKF1so4oLnAugjsZ6PwUt-8xBLszbwy45dsgRH02S2y00aMXQ@mail.gmail.com>
References: <CAGni2MiauEboBBr0qsqn1jB57AQoEEaOw3wRoavnuQX8TJGtNA@mail.gmail.com>
	<CAMKF1so4oLnAugjsZ6PwUt-8xBLszbwy45dsgRH02S2y00aMXQ@mail.gmail.com>
Message-ID: <CAGni2MjpuAQx3nCtgdiBAwB_ixRKyBDpMtZHRxUEkcxabU6JFQ@mail.gmail.com>

Hey Khem,

Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
> Makefiles I have seen doing that, you might see something like

In the recipe it's caused by 'inherit module', which is needed because part
of the recipe is building modules. I would understand this would unset
CFLAGS and such but am not sure why the devshell should be different that
the environment at the first line of do_compile?

On Tue, Jun 18, 2019 at 10:08 AM Khem Raj <raj.khem at gmail.com> wrote:

> On Mon, Jun 17, 2019 at 4:55 PM matthew stanger <stangerm2 at gmail.com>
> wrote:
> >
> > I'm trying to figure out why when running devshell in Warrior CC/CFLAGS
> are not the same as do_compile for a recipe. For example.
> > devshell printenv yields:
> > CC=aarch64-poky-linux-gcc   -fuse-ld=bfd
> -fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0=/usr/src/debug/ursr/18.3+AUTOINC+0a6fb7430f-0
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot=
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot-native=
> -fdebug-prefix-map=/home/matt/rdk_warrior/build/tmp/work-shared/tmobile-7271-kaon-mini/kernel-source=/usr/src/kernel
> >
> > do_compile() {
> >     /usr/bin/printenv | sort > debug.log
> > }
> > yields...
> > CC=aarch64-poky-linux-gcc  -mcpu=cortex-a53+crc+crypto
> -fstack-protector-strong  -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security
> -Werror=format-security
> --sysroot=/home/matt/rdk_warrior/build/tmp/work/tmobile_7271_kaon_mini-poky-linux/ursr/18.3+AUTOINC+0a6fb7430f-0/recipe-sysroot
> >
> > This causes some very different behavior out of the makefile. The recipe
> I"m working with has no do_configure, and only calls a makefile through
> do_compile. No appends/prepends or custom functions in the recipe. This
> recipe is for a lovely Broadcom driver/userspace glob and I'm trying to
> troubleshoot it with x64 but not being able to get a correct working env
> makes life hard. Any idea's of where I might be going wrong?
> >
>
> Check that Makefiles are not overriding CC/CXX/LD etc. some old crufty
> Makefiles I have seen doing that, you might see something like
>
> CC = ${CROSS_COMPILE}gcc etc. which you should convert to weak defines
> e.g. CC ?= ....
>
> > Cheers
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190618/8888afea/attachment-0001.html>

From martin.jansa at gmail.com  Tue Jun 18 10:13:45 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Tue, 18 Jun 2019 19:13:45 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
	<CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
	<trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
Message-ID: <20190618171345.GB1501@jama>

On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> Thanks for explaining this.
> I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
> And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).
> 
> So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.
> 
> According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).

I didn't say anything about changing the DEFAULTTUNE.

Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
(not "armv7a").

> On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.

The results should be almost the same, maybe slightly better, depends on
the actual code as Khem mentioned.

But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
then you should probably spend the time on your tooling instead of
replacing one hardcoded value with another.

Cheers,

> 
> Thanks for you taking the time.
> Arno
> 
> > Hello Arno,
> >
> > Let me try to explain my point of view. Since here (my best guess) we
> > have some asynchronous bitbake code which went South upon introducing
> > T2 HW extension.
> >
> > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > media coprocessor) exists in both of them. In other words:
> > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> >
> > Point [2]:
> > > bitbake gives me in 2.5:
> > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > TARGET_FPU           = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU           = "hard"
> >
> > These two lines are the same: you are able to use 32b arm mode, 16bit
> > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > extension as well. The Cortex in both cases is A9.
> >
> > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > and I have no idea if this is done intentionally or not.
> >
> > Because of that I copied Alex and Ross to CC: into email, so they
> > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> >
> > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > should return "armv7" as TUNE FEATURE.
> >
> > Best Regards,
> > Zoran
> > _______
> >
> >
> > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
> > >
> > > Hello Zoran,
> > > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > > But I want to keep all compatible to my previous tool-chain and settings.
> > > The only file where I can found this "cortexa9t2hf" is
> > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > > Or have I been wrong the time before?
> > >
> > > bitbake gives me in 2.5:
> > >
> > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > TARGET_FPU           = "hard"
> > >
> > > and in 2.7:
> > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > TARGET_FPU           = "hard"
> > >
> > > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > > Arno
> > >
> > > >
> > > > Hello Arno,
> > > >
> > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > try (as my best) to answer your question.
> > > >
> > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > >
> > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > question is what is T2? T2 is addition to the previous architecture
> > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > >
> > > > Hope this helps,
> > > >
> > > > Zoran
> > > > _______
> > > >
> > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > > > >
> > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > > Target system is a Zynq7020 system.
> > > > > --
> > > > > _______________________________________________
> > > > > yocto mailing list
> > > > > yocto at yoctoproject.org
> > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > >
> >
> -- 
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190618/d29323c0/attachment.pgp>

From zoran.stojsavljevic at gmail.com  Tue Jun 18 11:47:32 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Tue, 18 Jun 2019 20:47:32 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <20190618171345.GB1501@jama>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
	<CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
	<trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
	<20190618171345.GB1501@jama>
Message-ID: <CAGAf8LwYfO93pTwkKzsxHJPaJUz12vm9d+HBufyLS+bzDqR0hQ@mail.gmail.com>

> Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> (not "armv7a").

I think this is impossible for the current state of YOCTO affairs. I
do not think bitbake is able to determine type of arm silicon, since
it needs to implement the following instruction somewhere beneath (in
privileged mode):
asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );

But according to the variable MACHINE (example: MACHINE ??=
"beaglebone"), it is able to determine that the platform is a type of
armv7a.

My two cent worth thinking,
Zoran
_______


On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa <martin.jansa at gmail.com> wrote:
>
> On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > Thanks for explaining this.
> > I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
> > And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).
> >
> > So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.
> >
> > According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).
>
> I didn't say anything about changing the DEFAULTTUNE.
>
> Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> (not "armv7a").
>
> > On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.
>
> The results should be almost the same, maybe slightly better, depends on
> the actual code as Khem mentioned.
>
> But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
> then you should probably spend the time on your tooling instead of
> replacing one hardcoded value with another.
>
> Cheers,
>
> >
> > Thanks for you taking the time.
> > Arno
> >
> > > Hello Arno,
> > >
> > > Let me try to explain my point of view. Since here (my best guess) we
> > > have some asynchronous bitbake code which went South upon introducing
> > > T2 HW extension.
> > >
> > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > media coprocessor) exists in both of them. In other words:
> > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > >
> > > Point [2]:
> > > > bitbake gives me in 2.5:
> > > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > > TARGET_FPU           = "hard"
> > > >
> > > > and in 2.7:
> > > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > TARGET_FPU           = "hard"
> > >
> > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > > extension as well. The Cortex in both cases is A9.
> > >
> > > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > > and I have no idea if this is done intentionally or not.
> > >
> > > Because of that I copied Alex and Ross to CC: into email, so they
> > > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> > >
> > > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > > should return "armv7" as TUNE FEATURE.
> > >
> > > Best Regards,
> > > Zoran
> > > _______
> > >
> > >
> > > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
> > > >
> > > > Hello Zoran,
> > > > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > > > But I want to keep all compatible to my previous tool-chain and settings.
> > > > The only file where I can found this "cortexa9t2hf" is
> > > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > > > Or have I been wrong the time before?
> > > >
> > > > bitbake gives me in 2.5:
> > > >
> > > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > > TARGET_FPU           = "hard"
> > > >
> > > > and in 2.7:
> > > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > TARGET_FPU           = "hard"
> > > >
> > > > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > > > Arno
> > > >
> > > > >
> > > > > Hello Arno,
> > > > >
> > > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > > try (as my best) to answer your question.
> > > > >
> > > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > > >
> > > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > > question is what is T2? T2 is addition to the previous architecture
> > > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > > >
> > > > > Hope this helps,
> > > > >
> > > > > Zoran
> > > > > _______
> > > > >
> > > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > > > > >
> > > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > > > Target system is a Zynq7020 system.
> > > > > > --
> > > > > > _______________________________________________
> > > > > > yocto mailing list
> > > > > > yocto at yoctoproject.org
> > > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > > >
> > >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com

From martin.jansa at gmail.com  Tue Jun 18 12:03:43 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Tue, 18 Jun 2019 21:03:43 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <CAGAf8LwYfO93pTwkKzsxHJPaJUz12vm9d+HBufyLS+bzDqR0hQ@mail.gmail.com>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
	<CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
	<trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
	<20190618171345.GB1501@jama>
	<CAGAf8LwYfO93pTwkKzsxHJPaJUz12vm9d+HBufyLS+bzDqR0hQ@mail.gmail.com>
Message-ID: <20190618190343.GC1501@jama>

On Tue, Jun 18, 2019 at 08:47:32PM +0200, Zoran Stojsavljevic wrote:
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
> 
> I think this is impossible for the current state of YOCTO affairs. I
> do not think bitbake is able to determine type of arm silicon, since

Have you read the commit which enabled thumb by default for MACHINEs
which support it?

bitbake is still just a parser of the metadata and executor of our
tasks, it doesn't (and shouldn't) need to know anything about arm silicons.

DEFAULTTUNE is still set in the MACHINE config (through one of the .inc
files) and ARM_INSTRUCTION_SET is just another variable which says if
it should include -mthumb or -marm by default in TUNE_CCARGS, read
conf/machine/include/arm/feature-arm-thumb.inc

Cheers,

> it needs to implement the following instruction somewhere beneath (in
> privileged mode):
> asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );
> 
> But according to the variable MACHINE (example: MACHINE ??=
> "beaglebone"), it is able to determine that the platform is a type of
> armv7a.
> 
> My two cent worth thinking,
> Zoran
> _______
> 
> 
> On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa <martin.jansa at gmail.com> wrote:
> >
> > On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > > Thanks for explaining this.
> > > I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
> > > And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).
> > >
> > > So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.
> > >
> > > According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).
> >
> > I didn't say anything about changing the DEFAULTTUNE.
> >
> > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > (not "armv7a").
> >
> > > On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.
> >
> > The results should be almost the same, maybe slightly better, depends on
> > the actual code as Khem mentioned.
> >
> > But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
> > then you should probably spend the time on your tooling instead of
> > replacing one hardcoded value with another.
> >
> > Cheers,
> >
> > >
> > > Thanks for you taking the time.
> > > Arno
> > >
> > > > Hello Arno,
> > > >
> > > > Let me try to explain my point of view. Since here (my best guess) we
> > > > have some asynchronous bitbake code which went South upon introducing
> > > > T2 HW extension.
> > > >
> > > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > > media coprocessor) exists in both of them. In other words:
> > > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > > >
> > > > Point [2]:
> > > > > bitbake gives me in 2.5:
> > > > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > > > TARGET_FPU           = "hard"
> > > > >
> > > > > and in 2.7:
> > > > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > > TARGET_FPU           = "hard"
> > > >
> > > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > > > extension as well. The Cortex in both cases is A9.
> > > >
> > > > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > > > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > > > and I have no idea if this is done intentionally or not.
> > > >
> > > > Because of that I copied Alex and Ross to CC: into email, so they
> > > > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > > > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> > > >
> > > > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > > > should return "armv7" as TUNE FEATURE.
> > > >
> > > > Best Regards,
> > > > Zoran
> > > > _______
> > > >
> > > >
> > > > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
> > > > >
> > > > > Hello Zoran,
> > > > > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > > > > But I want to keep all compatible to my previous tool-chain and settings.
> > > > > The only file where I can found this "cortexa9t2hf" is
> > > > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > > > > Or have I been wrong the time before?
> > > > >
> > > > > bitbake gives me in 2.5:
> > > > >
> > > > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > > > TARGET_FPU           = "hard"
> > > > >
> > > > > and in 2.7:
> > > > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > > TARGET_FPU           = "hard"
> > > > >
> > > > > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > > > > Arno
> > > > >
> > > > > >
> > > > > > Hello Arno,
> > > > > >
> > > > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > > > try (as my best) to answer your question.
> > > > > >
> > > > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > > > >
> > > > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > > > question is what is T2? T2 is addition to the previous architecture
> > > > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > > > >
> > > > > > Hope this helps,
> > > > > >
> > > > > > Zoran
> > > > > > _______
> > > > > >
> > > > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > > > > > >
> > > > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > > > > Target system is a Zynq7020 system.
> > > > > > > --
> > > > > > > _______________________________________________
> > > > > > > yocto mailing list
> > > > > > > yocto at yoctoproject.org
> > > > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > > > >
> > > >
> > > --
> > > _______________________________________________
> > > yocto mailing list
> > > yocto at yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190618/04ec6dc7/attachment.pgp>

From zoran.stojsavljevic at gmail.com  Tue Jun 18 13:55:31 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Tue, 18 Jun 2019 22:55:31 +0200
Subject: [yocto] cortexa9t2hf instead of cortexa9hf
In-Reply-To: <20190618190343.GC1501@jama>
References: <trinity-1bbd10a3-ee46-4746-90c7-0b5a49a62f26-1560772981350@3c-app-gmx-bs08>
	<CAGAf8LyBsd9Ya+RV94FQj+19f5Um+AypitaAoO0pn5_w+rq+nA@mail.gmail.com>
	<trinity-90f4bc6a-aa89-4bf8-aa92-72aec6a019e5-1560776407716@3c-app-gmx-bs08>
	<CAGAf8LwnPTFedqXA6zwSF22bK_VPs2otSsVg5e=hDAXp+q5Csg@mail.gmail.com>
	<trinity-fe27ef88-5231-4c98-92a3-47d5fb327d83-1560793656274@3c-app-gmx-bs55>
	<20190618171345.GB1501@jama>
	<CAGAf8LwYfO93pTwkKzsxHJPaJUz12vm9d+HBufyLS+bzDqR0hQ@mail.gmail.com>
	<20190618190343.GC1501@jama>
Message-ID: <CAGAf8LyR-Ec9jh5OwjPKuF+AMDWU3DNt6TzsAiQYx+XKTL7QAQ@mail.gmail.com>

> bitbake is still just a parser of the metadata and executor of our
> tasks, it doesn't (and shouldn't) need to know anything about arm silicons.

You precisely formulated my latest thoughts in one sentence. :-)

Cheers,
Zoran
_______

On Tue, Jun 18, 2019 at 9:03 PM Martin Jansa <martin.jansa at gmail.com> wrote:
>
> On Tue, Jun 18, 2019 at 08:47:32PM +0200, Zoran Stojsavljevic wrote:
> > > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > > (not "armv7a").
> >
> > I think this is impossible for the current state of YOCTO affairs. I
> > do not think bitbake is able to determine type of arm silicon, since
>
> Have you read the commit which enabled thumb by default for MACHINEs
> which support it?
>
> bitbake is still just a parser of the metadata and executor of our
> tasks, it doesn't (and shouldn't) need to know anything about arm silicons.
>
> DEFAULTTUNE is still set in the MACHINE config (through one of the .inc
> files) and ARM_INSTRUCTION_SET is just another variable which says if
> it should include -mthumb or -marm by default in TUNE_CCARGS, read
> conf/machine/include/arm/feature-arm-thumb.inc
>
> Cheers,
>
> > it needs to implement the following instruction somewhere beneath (in
> > privileged mode):
> > asm volatile("mrc p15, 0, r0, c0, c0, 0" : "=r"(reg_value) );
> >
> > But according to the variable MACHINE (example: MACHINE ??=
> > "beaglebone"), it is able to determine that the platform is a type of
> > armv7a.
> >
> > My two cent worth thinking,
> > Zoran
> > _______
> >
> >
> > On Tue, Jun 18, 2019 at 7:13 PM Martin Jansa <martin.jansa at gmail.com> wrote:
> > >
> > > On Mon, Jun 17, 2019 at 07:47:36PM +0200, Arno Steffens wrote:
> > > > Thanks for explaining this.
> > > > I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects.
> > > > And mixing this causes time to switch processor mode. So, as I am not an expert in this and can't decide what ist best on per function base and speed is of highest priority, I think I better should use not thumb(2).
> > > >
> > > > So, do I get it right that with this cortexa9t2hf I just have the option to compile it for thumb2? But without using a dedicated compiler option it generates same "standard" arm code and the difference is just to adapt all the Makefiles for this suffix.
> > > >
> > > > According to Martin I can get the previous setting by just set ARM_INSTRUCTION_SET to "arm" instead of "armv7a". Mh - I just afraid that I lose other kinds of optimisation. (I am just a user not an expert in arm architecture).
> > >
> > > I didn't say anything about changing the DEFAULTTUNE.
> > >
> > > Just ARM_INSTRUCTION_SET to "arm" which will give you "cortexa9hf" again
> > > (not "armv7a").
> > >
> > > > On the other hand for those like me it is better go the standard way. Once I am sure compiler results will not become worse (see above) I go for the pain and renaming my toolchain/makefiles/stuff.
> > >
> > > The results should be almost the same, maybe slightly better, depends on
> > > the actual code as Khem mentioned.
> > >
> > > But if this causes you a lot of pain "renaming my toolchain/makefiles/stuff"
> > > then you should probably spend the time on your tooling instead of
> > > replacing one hardcoded value with another.
> > >
> > > Cheers,
> > >
> > > >
> > > > Thanks for you taking the time.
> > > > Arno
> > > >
> > > > > Hello Arno,
> > > > >
> > > > > Let me try to explain my point of view. Since here (my best guess) we
> > > > > have some asynchronous bitbake code which went South upon introducing
> > > > > T2 HW extension.
> > > > >
> > > > > Point [1]: as far as I understand arm, cortexa9t2hf is is just a
> > > > > superset of previous cortexa9hf (HW wise). NEON HW extension (NEON
> > > > > media coprocessor) exists in both of them. In other words:
> > > > > cortexa9t2hf = cortexa9hf HW + T2 HW extension.
> > > > >
> > > > > Point [2]:
> > > > > > bitbake gives me in 2.5:
> > > > > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > > > > TARGET_FPU           = "hard"
> > > > > >
> > > > > > and in 2.7:
> > > > > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > > > TARGET_FPU           = "hard"
> > > > >
> > > > > These two lines are the same: you are able to use 32b arm mode, 16bit
> > > > > thumb mode, using armv7 HW with neon HW extension, and using HW FP
> > > > > extension as well. The Cortex in both cases is A9.
> > > > >
> > > > > I expect that somebody somewhere in bitbake version 1.42 - 100% sure
> > > > > (since 2.5/Sumo uses bitbake 1.38) dropped "armv7a" as TUNE FEATURE,
> > > > > and I have no idea if this is done intentionally or not.
> > > > >
> > > > > Because of that I copied Alex and Ross to CC: into email, so they
> > > > > should unveil this mystery (I would prefer "armv7" to stay in bitbake
> > > > > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC).
> > > > >
> > > > > Bottom line: nothing to be done by you, Arno, seems that bitbake 1.42
> > > > > should return "armv7" as TUNE FEATURE.
> > > > >
> > > > > Best Regards,
> > > > > Zoran
> > > > > _______
> > > > >
> > > > >
> > > > > On Mon, Jun 17, 2019 at 3:00 PM Arno Steffens <star at gmx.li> wrote:
> > > > > >
> > > > > > Hello Zoran,
> > > > > > thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code.
> > > > > > But I want to keep all compatible to my previous tool-chain and settings.
> > > > > > The only file where I can found this "cortexa9t2hf" is
> > > > > > ./meta/conf/machine/include/tune-cortexa9.inc
> > > > > > but I can't see how I can control Yocto to generate "cortexa9hf-neon" as before.
> > > > > > Or have I been wrong the time before?
> > > > > >
> > > > > > bitbake gives me in 2.5:
> > > > > >
> > > > > > TUNE_FEATURES        = "arm armv7a vfp thumb neon callconvention-hard cortexa9"
> > > > > > TARGET_FPU           = "hard"
> > > > > >
> > > > > > and in 2.7:
> > > > > > TUNE_FEATURES        = "arm vfp cortexa9 neon thumb callconvention-hard"
> > > > > > TARGET_FPU           = "hard"
> > > > > >
> > > > > > so armv7a seem to be missing. In terms of thumb both is same. But is that the reason? Where to set it?
> > > > > > Arno
> > > > > >
> > > > > > >
> > > > > > > Hello Arno,
> > > > > > >
> > > > > > > Your question, per say, has little to do with YOCTO forum. But I'll
> > > > > > > try (as my best) to answer your question.
> > > > > > >
> > > > > > > Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit).
> > > > > > >
> > > > > > > Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the
> > > > > > > question is what is T2? T2 is addition to the previous architecture
> > > > > > > Cortexa9hf, and addition is Thumb-2 mode.
> > > > > > >
> > > > > > > Hope this helps,
> > > > > > >
> > > > > > > Zoran
> > > > > > > _______
> > > > > > >
> > > > > > > On Mon, Jun 17, 2019 at 2:03 PM Arno Steffens <star at gmx.li> wrote:
> > > > > > > >
> > > > > > > > I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name.
> > > > > > > > Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean?
> > > > > > > > Target system is a Zynq7020 system.
> > > > > > > > --
> > > > > > > > _______________________________________________
> > > > > > > > yocto mailing list
> > > > > > > > yocto at yoctoproject.org
> > > > > > > > https://lists.yoctoproject.org/listinfo/yocto
> > > > > > >
> > > > >
> > > > --
> > > > _______________________________________________
> > > > yocto mailing list
> > > > yocto at yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > --
> > > Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com

From sjolley.yp.pm at gmail.com  Tue Jun 18 14:22:31 2019
From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com)
Date: Tue, 18 Jun 2019 14:22:31 -0700
Subject: [yocto] Yocto Project Status WW25'19
Message-ID: <054e01d5261b$f0bd7be0$d23873a0$@gmail.com>

Current Dev Position: YP 2.8 M2

Next Deadline: YP 2.8 Milestone 2 Cutoff July 14th, 2019

 

SWAT Team Rotation:

*	SWAT lead is currently: Paul
*	SWAT team rotation: Paul -> Ross on June 21, 2019
*	SWAT team rotation: Ross -> Amanda on June 28, 2019
*	 <https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team>
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*	Bug Triage meeting Thursday June 20th at 7:30am PDT (
<https://zoom.us/j/454367603> https://zoom.us/j/454367603)
*	Monthly Project Meeting Tuesday July 2nd at 8am PDT (
<https://zoom.us/j/990892712> https://zoom.us/j/990892712) 
*	Twitch - Next event is Tuesday 9th July at 8am PDT (
<https://www.twitch.tv/yocto_project> https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*	2.8 M1 has been through QA and is waiting on responses from YP TSC
members on release readiness. It had more issues that would be ideal but
most were relatively minor and are being worked upon, several with known
causes now with fixes in master. As such its likely to be released.
*	Stephen is recovering from the accident and will now respond to
emails. We're pleased to have him back and wish him a continued speedy
recovery!
*	Mailing lists are proving to be a tricky subject. Some people are
having trouble with emails not making it to the lists which we recognise is
a serious issue. Equally, our groups.io plan isn't proving workable without
major user visible change due to the current domain structure we have. It is
being worked on as a priority to find a way forward.
*	We have a new "newcomer" bug category which are bugs suited to
someone new to the project. These can be seen here:
<https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs>
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
*	We're grateful to Sandy, WindRiver and Michael for helping get
patchtest back into operation. Its tests are looking like they could do with
a little improvement but it is catching some issues and great to see
progress with it again.
*	During M2 Richard plans to look into our options for changing
runqueue to better support more advanced sstate usage. This may have an
impact on how quickly patches merge as the work there is involved and needs
focus.
*	We'd like to remind people that where test suites exist, we'd
appreciate it if people would run them before they send patches, e.g.
"oe-selftest -r devtool" or "oe-selftest -r wic".

 

Planned Releases for YP 2.8:

*	M1 is built and out of QA
*	M2 Cutoff 14th July
*	M2 Release 26th July
*	M3 Cutoff (Feature Freeze) 25th Aug
*	M3 Release 6th Sept
*	M4 Cutoff 30th Sept
*	2.8 (M4) Final Release 25th Oct

 

Planned upcoming dot releases:

*	YP 2.7.1 (Warrior) is planned for build imminently now that 2.8 M1
is done
*	YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
before 2.8 M2

 

Tracking Metrics:

*	WDD 2479 (last week 2478) (
<https://wiki.yoctoproject.org/charts/combo.html>
https://wiki.yoctoproject.org/charts/combo.html)
*	Poky Patch Metrics  

*	Total patches found: 1511 (last week 1507)
*	Patches in the Pending State: 641 (43%) [last week 641 (43%)]

 

Key Status Links for YP:

 <https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status>
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

 <https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule>
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

 <https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features>
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features

 

The Status reports are now stored on the wiki at:
<https://wiki.yoctoproject.org/wiki/Weekly_Status>
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 Project Manager

*    Cell:                (208) 244-4460

* Email:               <mailto:sjolley.yp.pm at gmail.com>
sjolley.yp.pm at gmail.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190618/275e322d/attachment-0001.html>

From jupiter.hce at gmail.com  Wed Jun 19 03:30:13 2019
From: jupiter.hce at gmail.com (JH)
Date: Wed, 19 Jun 2019 20:30:13 +1000
Subject: [yocto] UBOOT_CONFIG for i.MX 6ULZ NAND
Message-ID: <CAA=hcWTUNXhFLYtUnTuUoEOHz3c5wSpe7cE-zw8TKC8SK++wsA@mail.gmail.com>

Hi,

I am using i.MX 6ULZ processor (MCIMX6Z0DVM09AB) with internal NAND
flash, will it be sufficient to config UBOOT_CONFIG = "nand" in
local.conf for downloading Linux kernel image to NAND and boot from
NAND?

Does it need to configure UBOOT_CONFIG["mfgtool] for using imx mfgtool uuu?

Thank you.

Kind regards,

- jupiter

From richard.purdie at linuxfoundation.org  Wed Jun 19 07:43:14 2019
From: richard.purdie at linuxfoundation.org (Richard Purdie)
Date: Wed, 19 Jun 2019 15:43:14 +0100
Subject: [yocto] [update-rc.d][PATCH V3] update-rc.d: support
 enable/disable options
In-Reply-To: <1556607386-98960-2-git-send-email-changqing.li@windriver.com>
References: <b36da33b-df9e-2991-5444-cd45a4c3e2d1@windriver.com>
	<1556607386-98960-1-git-send-email-changqing.li@windriver.com>
	<1556607386-98960-2-git-send-email-changqing.li@windriver.com>
Message-ID: <9c91416162466b6f8c7990804a9fd9c6689ad131.camel@linuxfoundation.org>

On Tue, 2019-04-30 at 14:56 +0800, changqing.li at windriver.com wrote:
> From: Changqing Li <changqing.li at windriver.com>
> 
> Add support of enable/disable options, refer
> https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html
> 
> With support of these options, the usr can never change an existing
> configuration even after upgrading a package. The program will only
> install links if none are present, otherwise, it will keep
> the previous configuration.
> 
> preinst in update-rc.d.bbclass will delete all the links under
> rcrunlevel.d, this behavior now conflicts with enable/disable
> options. so remove preinst from the update-rc.d.bbclass
> 
> [Yocto 12955]
> 
> Signed-off-by: Changqing Li <changqing.li at windriver.com>

Merged, thanks, sorry about the delay.

Richard


From randy.macleod at windriver.com  Wed Jun 19 10:49:43 2019
From: randy.macleod at windriver.com (Randy MacLeod)
Date: Wed, 19 Jun 2019 13:49:43 -0400
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <20190614144853.25839-5-Randy.MacLeod@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
Message-ID: <98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>

On 6/14/19 10:48 AM, Randy MacLeod wrote:
> When running the run-execscript bash ptest as a user rather than root, a warning:
>    bash: cannot set terminal process group (16036): Inappropriate ioctl for device
>    bash: no job control in this shell
> contaminates the bash log files causing the test to fail. This happens only
> when run under ptest-runner and not when interactively testing!
> 
> The changes made to fix this include:
> 1. Get the process group id (pgid) before forking,
> 2. Set the pgid in both the parent and child to avoid a race,
> 3. Find, open and set permission on the child tty, and
> 4. Allow the child to attach to controlling tty.
> 
> Also add '-lutil' to Makefile. This lib is from libc and provides openpty.


Hmmm, I was making the code compile cleanly under clang using
   -Weverything
when I noticed:

1. the 'make check' tests. They still work fine.
2. The './ptest-runner -d tests/data -t 1' tests
    which now generate loads of error like:
     ERROR: Unable to detach from controlling tty, Inappropriate ioctl 
for device

so while this change fixed the bash-ptest, the ptest-runner self-test
it did something wrong.... Ah, I'm calling:
    ioctl(0, TIOCNOTTY) == -1)
repeatedly in the parent so that's what's generating the extra logs.
Fixed locally and I'll send a patch but it's not urgent. Phew! :)

Anibal,

If you could reply to explain your plans for Richard's patches
that would help me figure out when to send the clang warning clean-ups
commits and what commit to base my work on.


../Randy

> 
> Signed-off-by: Sakib Sajal <sakib.sajal at windriver.com>
> Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com>
> ---
>   Makefile |   2 +-
>   utils.c  | 102 +++++++++++++++++++++++++++++++++++++++++++++++++------
>   2 files changed, 92 insertions(+), 12 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 1bde7be..439eb79 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
>   all: $(SOURCES) $(EXECUTABLE)
>   
>   $(EXECUTABLE): $(OBJECTS)
> -	$(CC) $(LDFLAGS) $(OBJECTS) -o $@
> +	$(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
>   
>   tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
>   
> diff --git a/utils.c b/utils.c
> index ad737c2..f11ce39 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -1,5 +1,6 @@
>   /**
>    * Copyright (c) 2016 Intel Corporation
> + * Copyright (C) 2019 Wind River Systems, Inc.
>    *
>    * This program is free software; you can redistribute it and/or
>    * modify it under the terms of the GNU General Public License
> @@ -22,23 +23,27 @@
>    */
>   
>   #define _GNU_SOURCE
> +
>   #include <stdio.h>
>   
> +#include <dirent.h>
> +#include <errno.h>
> +#include <fcntl.h>
> +#include <grp.h>
>   #include <libgen.h>
> -#include <signal.h>
>   #include <poll.h>
> -#include <fcntl.h>
> +#include <pty.h>
> +#include <signal.h>
> +#include <stdlib.h>
> +#include <string.h>
>   #include <time.h>
> -#include <dirent.h>
> +#include <unistd.h>
> +
> +#include <sys/ioctl.h>
>   #include <sys/resource.h>
> +#include <sys/stat.h>
>   #include <sys/types.h>
>   #include <sys/wait.h>
> -#include <sys/stat.h>
> -#include <unistd.h>
> -#include <string.h>
> -#include <stdlib.h>
> -
> -#include <errno.h>
>   
>   #include "ptest_list.h"
>   #include "utils.h"
> @@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char *run_ptest, pid_t pid,
>   	return status;
>   }
>   
> +/* Returns an integer file descriptor.
> + * If it returns < 0, an error has occurred.
> + * Otherwise, it has returned the slave pty file descriptor.
> + * fp should be writable, likely stdout/err.
> + */
> +static int
> +setup_slave_pty(FILE *fp) {
> +	int pty_master = -1;
> +	int pty_slave = -1;
> +	char pty_name[256];
> +	struct group *gptr;
> +	gid_t gid;
> +	int slave = -1;
> +
> +	if (openpty(&pty_master, &pty_slave, pty_name, NULL, NULL) < 0) {
> +		fprintf(fp, "ERROR: openpty() failed with: %s.\n", strerror(errno));
> +		return -1;
> +	}
> +
> +	if ((gptr = getgrnam(pty_name)) != 0) {
> +		gid = gptr->gr_gid;
> +	} else {
> +		/* If the tty group does not exist, don't change the
> +		 * group on the slave pty, only the owner
> +		 */
> +		gid = -1;
> +	}
> +
> +	/* chown/chmod the corresponding pty, if possible.
> +	 * This will only work if the process has root permissions.
> +	 */
> +	if (chown(pty_name, getuid(), gid) != 0) {
> +		fprintf(fp, "ERROR; chown() failed with: %s.\n", strerror(errno));
> +	}
> +
> +	/* Makes the slave read/writeable for the user. */
> +	if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
> +		fprintf(fp, "ERROR: chmod() failed with: %s.\n", strerror(errno));
> +	}
> +
> +	if ((slave = open(pty_name, O_RDWR)) == -1) {
> +		fprintf(fp, "ERROR: open() failed with: %s.\n", strerror(errno));
> +	}
> +	return (slave);
> +}
> +
> +
>   int
>   run_ptests(struct ptest_list *head, const struct ptest_options opts,
>   		const char *progname, FILE *fp, FILE *fp_stderr)
> @@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
>   	int timeouted;
>   	time_t sttime, entime;
>   	int duration;
> +	int slave;
> +	int pgid = -1;
>   
>   	if (opts.xml_filename) {
>   		xh = xml_create(ptest_list_length(head), opts.xml_filename);
> @@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
>   			close(pipefd_stdout[1]);
>   			break;
>   		}
> -
>   		fprintf(fp, "START: %s\n", progname);
>   		PTEST_LIST_ITERATE_START(head, p);
>   			char *ptest_dir = strdup(p->run_ptest);
> @@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
>   				break;
>   			}
>   			dirname(ptest_dir);
> +			if (ioctl(0, TIOCNOTTY) == -1) {
> +				fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno));
> +			}
> +
> +			if ((pgid = getpgid(0)) == -1) {
> +				fprintf(fp, "ERROR: getpgid() failed, %s\n", strerror(errno));
> +			}
>   
>   			child = fork();
>   			if (child == -1) {
> @@ -395,13 +455,33 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts,
>   				rc = -1;
>   				break;
>   			} else if (child == 0) {
> -				setsid();
> +				close(0);
> +				if ((slave = setup_slave_pty(fp)) < 0) {
> +					fprintf(fp, "ERROR: could not setup pty (%d).", slave);
> +				}
> +				if (setpgid(0,pgid) == -1) {
> +					fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
> +				}
> +
> +				if (setsid() ==  -1) {
> +					fprintf(fp, "ERROR: setsid() failed, %s\n", strerror(errno));
> +				}
> +
> +				if (ioctl(0, TIOCSCTTY, NULL) == -1) {
> +					fprintf(fp, "ERROR: Unable to attach to controlling tty, %s\n", strerror(errno));
> +				}
> +
>   				run_child(p->run_ptest, pipefd_stdout[1], pipefd_stderr[1]);
> +
>   			} else {
>   				int status;
>   				int fds[2]; fds[0] = pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
>   				FILE *fps[2]; fps[0] = fp; fps[1] = fp_stderr;
>   
> +				if (setpgid(child, pgid) == -1) {
> +					fprintf(fp, "ERROR: setpgid() failed, %s\n", strerror(errno));
> +				}
> +
>   				sttime = time(NULL);
>   				fprintf(fp, "%s\n", get_stime(stime, GET_STIME_BUF_SIZE, sttime));
>   				fprintf(fp, "BEGIN: %s\n", ptest_dir);
> 


-- 
# Randy MacLeod
# Wind River Linux

From richard.purdie at linuxfoundation.org  Wed Jun 19 12:24:39 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Wed, 19 Jun 2019 20:24:39 +0100
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
	<98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
Message-ID: <72d23534740d950d79479a4d7953ecbfa9213c4c.camel@linuxfoundation.org>

On Wed, 2019-06-19 at 13:49 -0400, Randy MacLeod wrote:
> On 6/14/19 10:48 AM, Randy MacLeod wrote:
> > When running the run-execscript bash ptest as a user rather than
> > root, a warning:
> >    bash: cannot set terminal process group (16036): Inappropriate
> > ioctl for device
> >    bash: no job control in this shell
> > contaminates the bash log files causing the test to fail. This
> > happens only
> > when run under ptest-runner and not when interactively testing!
> > 
> > The changes made to fix this include:
> > 1. Get the process group id (pgid) before forking,
> > 2. Set the pgid in both the parent and child to avoid a race,
> > 3. Find, open and set permission on the child tty, and
> > 4. Allow the child to attach to controlling tty.
> > 
> > Also add '-lutil' to Makefile. This lib is from libc and provides
> > openpty.
> 
> Hmmm, I was making the code compile cleanly under clang using
>    -Weverything
> when I noticed:
> 
> 1. the 'make check' tests. They still work fine.
> 2. The './ptest-runner -d tests/data -t 1' tests
>     which now generate loads of error like:
>      ERROR: Unable to detach from controlling tty, Inappropriate
> ioctl 
> for device

Aha.

Does this mean you get to own:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13409

:)

> 
> so while this change fixed the bash-ptest, the ptest-runner self-test
> it did something wrong.... Ah, I'm calling:
>     ioctl(0, TIOCNOTTY) == -1)
> repeatedly in the parent so that's what's generating the extra logs.
> Fixed locally and I'll send a patch but it's not urgent. Phew! :)
> 
> Anibal,
> 
> If you could reply to explain your plans for Richard's patches
> that would help me figure out when to send the clang warning clean-
> ups commits and what commit to base my work on.

I think he believed some of them unnecessary, they were a bit belt and
brances but I'm not sure that is a bad thing.

Cheers,

Richard


From randy.macleod at windriver.com  Wed Jun 19 12:54:33 2019
From: randy.macleod at windriver.com (Randy MacLeod)
Date: Wed, 19 Jun 2019 15:54:33 -0400
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <72d23534740d950d79479a4d7953ecbfa9213c4c.camel@linuxfoundation.org>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
	<98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
	<72d23534740d950d79479a4d7953ecbfa9213c4c.camel@linuxfoundation.org>
Message-ID: <4b739f27-c4e1-2b44-8bd8-009458d0ab34@windriver.com>

On 6/19/19 3:24 PM, richard.purdie at linuxfoundation.org wrote:
> On Wed, 2019-06-19 at 13:49 -0400, Randy MacLeod wrote:
>> On 6/14/19 10:48 AM, Randy MacLeod wrote:
>>> When running the run-execscript bash ptest as a user rather than
>>> root, a warning:
>>>     bash: cannot set terminal process group (16036): Inappropriate
>>> ioctl for device
>>>     bash: no job control in this shell
>>> contaminates the bash log files causing the test to fail. This
>>> happens only
>>> when run under ptest-runner and not when interactively testing!
>>>
>>> The changes made to fix this include:
>>> 1. Get the process group id (pgid) before forking,
>>> 2. Set the pgid in both the parent and child to avoid a race,
>>> 3. Find, open and set permission on the child tty, and
>>> 4. Allow the child to attach to controlling tty.
>>>
>>> Also add '-lutil' to Makefile. This lib is from libc and provides
>>> openpty.
>>
>> Hmmm, I was making the code compile cleanly under clang using
>>     -Weverything
>> when I noticed:
>>
>> 1. the 'make check' tests. They still work fine.
>> 2. The './ptest-runner -d tests/data -t 1' tests
>>      which now generate loads of error like:
>>       ERROR: Unable to detach from controlling tty, Inappropriate
>> ioctl
>> for device
> 
> Aha.
> 
> Does this mean you get to own:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13409
> 
> :)

Yes, that's likely my fault.
I've taken the defect.

../Randy 'belt and suspenders' MacLeod

> 
>>
>> so while this change fixed the bash-ptest, the ptest-runner self-test
>> it did something wrong.... Ah, I'm calling:
>>      ioctl(0, TIOCNOTTY) == -1)
>> repeatedly in the parent so that's what's generating the extra logs.
>> Fixed locally and I'll send a patch but it's not urgent. Phew! :)
>>
>> Anibal,
>>
>> If you could reply to explain your plans for Richard's patches
>> that would help me figure out when to send the clang warning clean-
>> ups commits and what commit to base my work on.
> 
> I think he believed some of them unnecessary, they were a bit belt and
> brances but I'm not sure that is a bad thing.
> 
> Cheers,
> 
> Richard
> 


-- 
# Randy MacLeod
# Wind River Linux

From raj.khem at gmail.com  Wed Jun 19 13:02:51 2019
From: raj.khem at gmail.com (Khem Raj)
Date: Wed, 19 Jun 2019 13:02:51 -0700
Subject: [yocto] Can't build SDK while shrinking shadow tools
In-Reply-To: <CAA42Xj5pNmu1BSVAd2FMTJvwO1fSbtckDfp+EOP9ELikG_=POw@mail.gmail.com>
References: <CAA42Xj5nygLnFp_ojTP5J59czFuG7f82c6bc_SLax+4+Ot2QVg@mail.gmail.com>
	<CAA42Xj5pNmu1BSVAd2FMTJvwO1fSbtckDfp+EOP9ELikG_=POw@mail.gmail.com>
Message-ID: <CAMKF1spO50-WtUOinnWO9wSqohTUXjBng-z_mFVtf0mbwbRP_A@mail.gmail.com>

On Fri, Jun 14, 2019 at 2:16 AM J?r?my Singy <jeremy.singy at gmail.com> wrote:

> Hi,
>
> I'm facing a problem by trying to shrink the size of our root filesystem.
> To avoid installing some unneeded tools such as adduser, groupadd,
> nologin, etc. I just created as usual a shadow_%.bbappend in our layer
> which removes the content using do_install_append:
>
>     # do not install alternatives
>     ALTERNATIVE_${PN} = ""
>     ALTERNATIVE_${PN}-base = ""


This is most probably the reason for your issue
You may want to remove the alternatives which you are deleting but not
everything

>
>
>     # remove unwanted files on target
>     do_install_append_class-target () {
>       rm -r ${D}${base_bindir}
>       rm -r ${D}${base_sbindir}
>       rm -r ${D}${bindir}
>       rm -r ${D}${sbindir}
>     }
>
> Building an image with this works well and I got rid of the unwanted
> tools but I get an error whenever I try to build the SDK for this image
> with do_populate_sdk:
>
>     WARNING: ceres-image-1.0-r0 do_populate_sdk:
> nativesdk-util-linux.postinst returned 1, marking as unpacked only,
> configuration required on target.
>     ERROR: ceres-image-1.0-r0 do_populate_sdk: Postinstall scriptlets
> of ['nativesdk-util-linux'] have failed. If the intention is to defer
> them to first boot,
>     then please place them into pkg_postinst_ontarget_${PN} ().
>     Deferring to first boot via 'exit 1' is no longer supported.
>     Details of the failure are in
>
> /home/chsingj/yocto-thud/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/temp/log.do_populate_sdk.
>     ERROR: ceres-image-1.0-r0 do_populate_sdk: Function failed:
> do_populate_sdk
>     ERROR: Logfile of failure stored in:
>
> /home/chsingj/yocto-thud/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/temp/log.do_populate_sdk.28331
>     ERROR: Task
> (/home/chsingj/meta-delta/recipes-core/images/ceres-image.bb:
> do_populate_sdk)
> failed with exit code '1'
>     NOTE: Tasks Summary: Attempted 2730 tasks of which 2729 didn't
> need to be rerun and 1 failed.
>
> The log file shows an error with update-alternatives (probably a
> failing ln call):
>
>     update-alternatives: Error: not linking
>
> [BUILDPATH]/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/sdk/image/opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin
> to
> /opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin.util-linux
> since
> [BUILDPATH]/tmp/work/ceres_con-oe-linux-gnueabi/ceres-image/1.0-r0/sdk/image/opt/ceres/sdk-2019.05-r1/sysroots/x86_64-delta-linux/sbin/nologin
> exists and is not a link
>
> If I remove the bbappend, the SDK builds fine but of course my image
> contains the unwanted files. I tried many other recipe tweaks but I
> can't get over some build errors. I'd like to avoid a solution using
> ROOTFS_POSTPROCESS_COMMAND in the image recipe as I would have to
> explicitely list all shadow tools and it would blow up my recipe. Is
> there any solution here? Is it maybe a bug that can be fixed? Thanks!
>
> Regards,
> Jeremy
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190619/6a913735/attachment.html>

From vineela.tummalapalli at intel.com  Wed Jun 19 15:18:09 2019
From: vineela.tummalapalli at intel.com (Tummalapalli, Vineela)
Date: Wed, 19 Jun 2019 22:18:09 +0000
Subject: [yocto] FW: [yocto-announce] [ANNOUNCEMENT] Milestone 1 for Yocto
 Project 2.8 (yocto-2.8_M1) now available
In-Reply-To: <363DC7214F94884BBF80916755E7D655206E04E7@ORSMSX107.amr.corp.intel.com>
References: <363DC7214F94884BBF80916755E7D655206E046A@ORSMSX107.amr.corp.intel.com>
	<363DC7214F94884BBF80916755E7D655206E04E7@ORSMSX107.amr.corp.intel.com>
Message-ID: <363DC7214F94884BBF80916755E7D655206E057D@ORSMSX107.amr.corp.intel.com>


From: yocto-announce-bounces at yoctoproject.org [mailto:yocto-announce-bounces at yoctoproject.org] On Behalf Of Tummalapalli, Vineela
Sent: Wednesday, June 19, 2019 2:35 PM
To: yocto-announce at yoctoproject.org; yocto at yocoproject.org
Subject: Re: [yocto-announce] [ANNOUNCEMENT] Milestone 1 for Yocto Project 2.8 (yocto-2.8_M1) now available

Hello,


We are pleased to announce the second milestone release for Yocto Project 2.8 (yocto-2.8_M1) is available for download now.



Download:



http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.8_M1/



bitbake: c4d90890547af642e99cc541af3415df3559563e

meta-gplv2: 168a5070bdf3bc45edb5bf2a1add9b7c081f5b64

meta-intel: c941d896c08d6d83694ba0af1fdf4f4dcb625e9f

meta-mingw: d17724b0eac76792a49e56213cba74e32edba48f

oecore: 86266dfcd70b8e3435d267538c3e6e4d69be829e

poky: 9910a3631ce953b8dd8f3d57d6e122c7fd8cb462



Test report:



http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.8_M1/testreport.txt



Thank you.



Vineela Tummalapalli

Yocto Project Build and Release
Vineela.tummalapalli at intel.com<mailto:Vineela.tummalapalli at intel.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190619/903a1bb0/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190619/903a1bb0/attachment-0001.txt>

From changqing.li at windriver.com  Wed Jun 19 19:05:00 2019
From: changqing.li at windriver.com (Changqing Li)
Date: Thu, 20 Jun 2019 10:05:00 +0800
Subject: [yocto] [update-rc.d][PATCH V3] update-rc.d: support
 enable/disable options
In-Reply-To: <9c91416162466b6f8c7990804a9fd9c6689ad131.camel@linuxfoundation.org>
References: <b36da33b-df9e-2991-5444-cd45a4c3e2d1@windriver.com>
	<1556607386-98960-1-git-send-email-changqing.li@windriver.com>
	<1556607386-98960-2-git-send-email-changqing.li@windriver.com>
	<9c91416162466b6f8c7990804a9fd9c6689ad131.camel@linuxfoundation.org>
Message-ID: <a6437aa9-d76f-b05c-2d3f-9d04a1520dae@windriver.com>

On 6/19/19 10:43 PM, Richard Purdie wrote:
> On Tue, 2019-04-30 at 14:56 +0800, changqing.li at windriver.com wrote:
>> From: Changqing Li <changqing.li at windriver.com>
>>
>> Add support of enable/disable options, refer
>> https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html
>>
>> With support of these options, the usr can never change an existing
>> configuration even after upgrading a package. The program will only
>> install links if none are present, otherwise, it will keep
>> the previous configuration.
>>
>> preinst in update-rc.d.bbclass will delete all the links under
>> rcrunlevel.d, this behavior now conflicts with enable/disable
>> options. so remove preinst from the update-rc.d.bbclass
>>
>> [Yocto 12955]
>>
>> Signed-off-by: Changqing Li <changqing.li at windriver.com>
> Merged, thanks, sorry about the delay.
>
> Richard
>
>
Thanks, Richard.

I see this patch have merged into repo update-rc.d.? But in this patch 
series,? there are

2 patches,? please also help to review the other one.? Maybe this patch 
series seems a little messy

in the mail.? I will reply on the other patch for you to pick it out easily.

-- 
BRs

Sandy(Li Changqing)


From changqing.li at windriver.com  Wed Jun 19 19:07:01 2019
From: changqing.li at windriver.com (Changqing Li)
Date: Thu, 20 Jun 2019 10:07:01 +0800
Subject: [yocto] [PATCH V3] update-rc.d: support enable/disable options
In-Reply-To: <1556607386-98960-1-git-send-email-changqing.li@windriver.com>
References: <b36da33b-df9e-2991-5444-cd45a4c3e2d1@windriver.com>
	<1556607386-98960-1-git-send-email-changqing.li@windriver.com>
Message-ID: <d344ac6a-5592-4c0d-6d4d-bb9899412c4e@windriver.com>

Please also help to review this patch, Thanks.

On 4/30/19 2:56 PM, changqing.li at windriver.com wrote:
> From: Changqing Li <changqing.li at windriver.com>
>
> * update-rc.d has added support of enable/disable options, which are
>    expected to keep the previous configuration even after upgrade the packages.
>    With support for these options, it will only create start/stop link
>    when there are none, or it will keep the previous configuration.
>
>    Our preinst uses "-f remove" to remove any links under the /etc/rcrunlevel.d
>    which is conflicting behavior with disable/enable options, so remove it.
>
>    For example, if a user disabled one service before upgrade,
>    then after upgrade the service could be started. This happens because during preinst,
>    all links have been deleted, then postinst may create the link to start service.
>
>    With this change, we remove preinst and therefore keep the previous links
>    so that after upgrade, if a link existed for the package, then the postinst
>    will not create new start/stop links.
>
> * remove '-f' for postinst. Previously, the keepalived recipe used 'remove'
>    during postinst, so we needed the -f, but now the keepalived recipe has fixed
>    this problem, so it's safe to remove '-f'.
>
> [Yocto #12955]
>
> Signed-off-by: Changqing Li <changqing.li at windriver.com>
> ---
>   documentation/ref-manual/ref-variables.xml |  2 +-
>   meta/classes/update-rc.d.bbclass           | 28 ++++------------------------
>   2 files changed, 5 insertions(+), 25 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
> index 536bd15..8fc48c3 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -7243,7 +7243,7 @@
>                       to the <filename>update-rc.d</filename> command.
>                       For more information on valid parameters, please see the
>                       <filename>update-rc.d</filename> manual page at
> -                    <ulink url='http://www.tin.org/bin/man.cgi?section=8&amp;topic=update-rc.d'></ulink>.
> +                    <ulink url='https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html'></ulink>.
>                   </para>
>               </glossdef>
>           </glossentry>
> diff --git a/meta/classes/update-rc.d.bbclass b/meta/classes/update-rc.d.bbclass
> index 265c4be..1366fee 100644
> --- a/meta/classes/update-rc.d.bbclass
> +++ b/meta/classes/update-rc.d.bbclass
> @@ -20,28 +20,14 @@ def use_updatercd(d):
>           return '[ -n "$D" -o ! -d /run/systemd/system ]'
>       return 'true'
>   
> -updatercd_preinst() {
> -if ${@use_updatercd(d)} && [ -z "$D" -a -f "${INIT_D_DIR}/${INITSCRIPT_NAME}" ]; then
> -	${INIT_D_DIR}/${INITSCRIPT_NAME} stop || :
> -fi
> -if ${@use_updatercd(d)} && type update-rc.d >/dev/null 2>/dev/null; then
> -	if [ -n "$D" ]; then
> -		OPT="-f -r $D"
> -	else
> -		OPT="-f"
> -	fi
> -	update-rc.d $OPT ${INITSCRIPT_NAME} remove
> -fi
> -}
> -
>   PACKAGE_WRITE_DEPS += "update-rc.d-native"
>   
>   updatercd_postinst() {
>   if ${@use_updatercd(d)} && type update-rc.d >/dev/null 2>/dev/null; then
>   	if [ -n "$D" ]; then
> -		OPT="-f -r $D"
> +		OPT="-r $D"
>   	else
> -		OPT="-f -s"
> +		OPT="-s"
>   	fi
>   	update-rc.d $OPT ${INITSCRIPT_NAME} ${INITSCRIPT_PARAMS}
>   fi
> @@ -79,7 +65,7 @@ python __anonymous() {
>   PACKAGESPLITFUNCS_prepend = "${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'populate_packages_updatercd ', '', d)}"
>   PACKAGESPLITFUNCS_remove_class-nativesdk = "populate_packages_updatercd "
>   
> -populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm updatercd_preinst updatercd_postinst"
> +populate_packages_updatercd[vardeps] += "updatercd_prerm updatercd_postrm updatercd_postinst"
>   populate_packages_updatercd[vardepsexclude] += "OVERRIDES"
>   
>   python populate_packages_updatercd () {
> @@ -95,7 +81,7 @@ python populate_packages_updatercd () {
>               d.appendVar('RDEPENDS_' + pkg, ' %sinitd-functions' % (mlprefix))
>   
>       def update_rcd_package(pkg):
> -        bb.debug(1, 'adding update-rc.d calls to preinst/postinst/prerm/postrm for %s' % pkg)
> +        bb.debug(1, 'adding update-rc.d calls to postinst/prerm/postrm for %s' % pkg)
>   
>           localdata = bb.data.createCopy(d)
>           overrides = localdata.getVar("OVERRIDES")
> @@ -103,12 +89,6 @@ python populate_packages_updatercd () {
>   
>           update_rcd_auto_depend(pkg)
>   
> -        preinst = d.getVar('pkg_preinst_%s' % pkg)
> -        if not preinst:
> -            preinst = '#!/bin/sh\n'
> -        preinst += localdata.getVar('updatercd_preinst')
> -        d.setVar('pkg_preinst_%s' % pkg, preinst)
> -
>           postinst = d.getVar('pkg_postinst_%s' % pkg)
>           if not postinst:
>               postinst = '#!/bin/sh\n'

-- 
BRs

Sandy(Li Changqing)


From akuster808 at gmail.com  Wed Jun 19 22:49:08 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Wed, 19 Jun 2019 22:49:08 -0700
Subject: [yocto] [meta-integrity][PATCH] ima-evm-utils: update to tip
Message-ID: <20190620054908.20554-1-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../recipes-security/ima-evm-utils/ima-evm-utils_git.bb         | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
index 929d853..623de09 100644
--- a/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
+++ b/meta-integrity/recipes-security/ima-evm-utils/ima-evm-utils_git.bb
@@ -7,7 +7,7 @@ DEPENDS += "openssl attr keyutils"
 DEPENDS_class-native += "openssl-native keyutils-native"
 
 PV = "1.0+git${SRCPV}"
-SRCREV = "0267fa16990fd0ddcc89984a8e55b27d43e80167"
+SRCREV = "782224f33cd711050cbf6146a12122cd73f9136b"
 SRC_URI = "git://git.code.sf.net/p/linux-ima/ima-evm-utils"
 
 # Documentation depends on asciidoc, which we do not have, so
-- 
2.17.1


From richard.purdie at linuxfoundation.org  Thu Jun 20 00:28:50 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Thu, 20 Jun 2019 08:28:50 +0100
Subject: [yocto] [PATCH V3] update-rc.d: support enable/disable options
In-Reply-To: <d344ac6a-5592-4c0d-6d4d-bb9899412c4e@windriver.com>
References: <b36da33b-df9e-2991-5444-cd45a4c3e2d1@windriver.com>
	<1556607386-98960-1-git-send-email-changqing.li@windriver.com>
	<d344ac6a-5592-4c0d-6d4d-bb9899412c4e@windriver.com>
Message-ID: <1fdd6cf809303377f2588b3aa07576e0a2398b86.camel@linuxfoundation.org>

On Thu, 2019-06-20 at 10:07 +0800, Changqing Li wrote:
> Please also help to review this patch, Thanks.

This patch needs to go to OE-Core for the bbclass part. The
documentation piece needs to be separated out as its a different 
repository. Also doesn't it depend on the change I just made to the
update-rc.d repo so there will be a SRCREV that needs to be updated
that this depends on?

Thanks,

Richard



From richard_allen at keysight.com  Wed Jun 19 08:19:08 2019
From: richard_allen at keysight.com (Richard Allen)
Date: Wed, 19 Jun 2019 15:19:08 +0000
Subject: [yocto] warrior with recipes AUTOREV,
	issues (and hangs bitbake on Centos )
Message-ID: <CY4PR17MB1479C3706CB1F51A70CEE45CF1E50@CY4PR17MB1479.namprd17.prod.outlook.com>

Hi, during our development process, many of our recipes use AUTOREV  to get latest bits

Under warrior ( bitbake 1.42?) , we are seeing failures with the follow structure
( from recipes not even used by the image, which recipe changes from bitbake to bitbake)

Traceback (most recent call last):
  File "/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/fetch2/__init__.py", line 1179, in srcrev_internal_helper(ud=<bb.fetch2.FetchData object at 0x7f43640bdc88>, d=<bb.data_smart.DataSmart object at 0x7f4364111588>, name='default'):
         if srcrev == "AUTOINC":
    >        srcrev = ud.method.latest_revision(ud, d, name)
     
  File "/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/fetch2/__init__.py", line 1574, in Git.latest_revision(ud=<bb.fetch2.FetchData object at 0x7f43640bdc88>, d=<bb.data_smart.DataSmart object at 0x7f4364111588>, name='default'):
             except KeyError:
    >            revs[key] = rev = self._latest_revision(ud, d, name)
                 return rev
  File "/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/persist_data.py", line 60, in SQLTable.wrap_func(*args=('XXXt', '1a969ebe1841690d0c5c36c174aa119175c90cd6'), **kwargs={}):
                             try:
    >                            return f(self, *args, **kwargs)
                             except sqlite3.OperationalError as exc:
  File "/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/persist_data.py", line 89, in SQLTable.wrap_func(*args=(XXX', '1a969ebe1841690d0c5c36c174aa119175c90cd6'), **kwargs={}):
                         with contextlib.closing(self.connection.cursor()) as cursor:
    >                        return f(self, cursor, *args, **kwargs)
                 return wrap_func
  File "/home/rcallen/tlo-warrior/sources/openembedded-core/bitbake/lib/bb/persist_data.py", line 197, in SQLTable.__setitem__(cursor=<sqlite3.Cursor object at 0x7f4364180ab0>, key= XXX't', value='1a969ebe1841690d0c5c36c174aa119175c90cd6'):
             else:
    >            cursor.execute("INSERT into %s(key, value) values (?, ?);" % self.table, [key, value])
     
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception IntegrityError: UNIQUE constraint failed: BB_URI_HEADREVS.key


Most times , no problems
If I set BB_SRCREV_POLICY = "cache" , never a problem..

When bitbake on a ubuntu, the error is created and bitbake recovers
On a Centos, the error is created AND bitbake HANGS ( A Ctrl C will break into the bitbake , but leaves a set of processes in memory,  need to manually kill the bitbake process and all its' children processes,
	- this behavior makes centos for warrior bitbaking pretty useless .

Wondering if others are seeing this?
If so, any known 'fixes' (besides not using AUTOREV ?)
If so, will this get fixed in 'warrior' or later?

Thanks
Richard C Allen




From changqing.li at windriver.com  Thu Jun 20 02:09:20 2019
From: changqing.li at windriver.com (Changqing Li)
Date: Thu, 20 Jun 2019 17:09:20 +0800
Subject: [yocto] [PATCH V3] update-rc.d: support enable/disable options
In-Reply-To: <1fdd6cf809303377f2588b3aa07576e0a2398b86.camel@linuxfoundation.org>
References: <b36da33b-df9e-2991-5444-cd45a4c3e2d1@windriver.com>
	<1556607386-98960-1-git-send-email-changqing.li@windriver.com>
	<d344ac6a-5592-4c0d-6d4d-bb9899412c4e@windriver.com>
	<1fdd6cf809303377f2588b3aa07576e0a2398b86.camel@linuxfoundation.org>
Message-ID: <7bef8b99-893e-9a6a-f8e8-4a2c161a5669@windriver.com>


On 6/20/19 3:28 PM, richard.purdie at linuxfoundation.org wrote:
> On Thu, 2019-06-20 at 10:07 +0800, Changqing Li wrote:
>> Please also help to review this patch, Thanks.
> This patch needs to go to OE-Core for the bbclass part. The
> documentation piece needs to be separated out as its a different
> repository. Also doesn't it depend on the change I just made to the
> update-rc.d repo so there will be a SRCREV that needs to be updated
> that this depends on?

I will? split?? the oe-core and document part.

without change in update-rc.d.bbclass, new function add in update-rc.d 
repo will not work.

since preinst in update-rc.d.bbclass will delete all the links under? 
rcrunlevel.d, this behavior

conflicts with enable/disable options.

and you're right,? I also need to update SRCREV of update-rc.d.bb in 
oe-core repo.

Thanks.

I will send it later.

> Thanks,
>
> Richard
>
>
>
-- 
BRs

Sandy(Li Changqing)


From ayaka at soulik.info  Thu Jun 20 04:14:07 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:14:07 +0800
Subject: [yocto] [meta-rockchip] [PATCH v2 0/3] fixup u-boot compiling error
Message-ID: <20190620111410.4573-1-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

Changelog
v2:
Fixed unset SRCREV stopped building in the previous time
Fixed compiler warning in GCC 9 of new oe

Randy 'ayaka' Li (2):
  recipes-bsp/u-boot: fixup build for gcc7
  recipes-bsp/u-boot: update build rules

Randy Li (1):
  recipes-bsp/u-boot: update to the latest version

 recipes-bsp/u-boot/u-boot-rockchip.inc        | 12 ++++++
 .../u-boot/u-boot-rockchip/gcc7_fixup.patch   | 38 +++++++++++++++++++
 .../u-boot-rockchip/gcc9-no-Werror.patch      | 13 +++++++
 .../u-boot/u-boot-rockchip_20171218.bb        |  4 ++
 recipes-bsp/u-boot/u-boot-rockchip_git.bb     | 19 ++++++++++
 5 files changed, 86 insertions(+)
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb

-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:14:08 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:14:08 +0800
Subject: [yocto] [PATCH v2 1/3] recipes-bsp/u-boot: fixup build for gcc7
In-Reply-To: <20190620111410.4573-1-ayaka@soulik.info>
References: <20190620111410.4573-1-ayaka@soulik.info>
Message-ID: <20190620111410.4573-2-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

Signed-off-by: Randy Li <randy.li at rock-chips.com>
Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 .../u-boot/u-boot-rockchip/gcc7_fixup.patch   | 38 +++++++++++++++++++
 1 file changed, 38 insertions(+)
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch

diff --git a/recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch b/recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
new file mode 100644
index 0000000..ccb709a
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip/gcc7_fixup.patch
@@ -0,0 +1,38 @@
+diff --git a/include/linux/log2.h b/include/linux/log2.h
+index aa1de63090..5526af036d 100644
+--- a/include/linux/log2.h
++++ b/include/linux/log2.h
+@@ -12,12 +12,6 @@
+ #include <linux/types.h>
+ #include <linux/bitops.h>
+ 
+-/*
+- * deal with unrepresentable constant logarithms
+- */
+-extern __attribute__((const, noreturn))
+-int ____ilog2_NaN(void);
+-
+ /*
+  * non-constant log of base 2 calculators
+  * - the arch may override these in asm/bitops.h if they can be implemented
+@@ -82,7 +76,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
+ #define ilog2(n)				\
+ (						\
+ 	__builtin_constant_p(n) ? (		\
+-		(n) < 1 ? ____ilog2_NaN() :	\
++		(n) < 2 ? 0 :			\
+ 		(n) & (1ULL << 63) ? 63 :	\
+ 		(n) & (1ULL << 62) ? 62 :	\
+ 		(n) & (1ULL << 61) ? 61 :	\
+@@ -145,10 +139,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
+ 		(n) & (1ULL <<  4) ?  4 :	\
+ 		(n) & (1ULL <<  3) ?  3 :	\
+ 		(n) & (1ULL <<  2) ?  2 :	\
+-		(n) & (1ULL <<  1) ?  1 :	\
+-		(n) & (1ULL <<  0) ?  0 :	\
+-		____ilog2_NaN()			\
+-				   ) :		\
++		1 ) :				\
+ 	(sizeof(n) <= 4) ?			\
+ 	__ilog2_u32(n) :			\
+ 	__ilog2_u64(n)				\
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:14:09 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:14:09 +0800
Subject: [yocto] [PATCH v2 2/3] recipes-bsp/u-boot: update build rules
In-Reply-To: <20190620111410.4573-1-ayaka@soulik.info>
References: <20190620111410.4573-1-ayaka@soulik.info>
Message-ID: <20190620111410.4573-3-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

Adding the missing recipes header file.
Fixing the compiler error after oe-core update.
Disabled the -Werror flag which would break the build due to
update of toolchain.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 recipes-bsp/u-boot/u-boot-rockchip.inc              | 12 ++++++++++++
 .../u-boot/u-boot-rockchip/gcc9-no-Werror.patch     | 13 +++++++++++++
 recipes-bsp/u-boot/u-boot-rockchip_20171218.bb      |  4 ++++
 3 files changed, 29 insertions(+)
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch

diff --git a/recipes-bsp/u-boot/u-boot-rockchip.inc b/recipes-bsp/u-boot/u-boot-rockchip.inc
index 5d89cd6..8815ac8 100644
--- a/recipes-bsp/u-boot/u-boot-rockchip.inc
+++ b/recipes-bsp/u-boot/u-boot-rockchip.inc
@@ -2,6 +2,7 @@
 # Copyright (C) 2017 Trevor Woerner <twoerner at gmail.com>
 # Released under the MIT license (see COPYING.MIT for the terms)
 
+require recipes-bsp/u-boot/u-boot-common.inc
 require recipes-bsp/u-boot/u-boot.inc
 
 DESCRIPTION = "Rockchip next-dev U-Boot"
@@ -14,6 +15,17 @@ DEPENDS = "dtc-native bc-native swig-native"
 # u-boot will build native python module
 inherit pythonnative
 
+do_configure () {
+	if [ -z "${UBOOT_CONFIG}" ]; then
+	    if [ -n "${UBOOT_MACHINE}" ]; then
+	        oe_runmake -C ${S} O=${B} ${UBOOT_MACHINE}
+	    else
+	        oe_runmake -C ${S} O=${B} oldconfig
+	    fi
+	    cml1_do_configure
+	fi
+}
+
 do_compile_prepend () {
 	export STAGING_INCDIR=${STAGING_INCDIR_NATIVE};
 	export STAGING_LIBDIR=${STAGING_LIBDIR_NATIVE};
diff --git a/recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch b/recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
new file mode 100644
index 0000000..198d846
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip/gcc9-no-Werror.patch
@@ -0,0 +1,13 @@
+diff --git a/Makefile b/Makefile
+index a2e1a09674..3697ece6fc 100644
+--- a/Makefile
++++ b/Makefile
+@@ -360,7 +360,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__ -D__UBOOT__
+ KBUILD_CFLAGS   := -Wall -Wstrict-prototypes \
+ 		   -Wno-format-security \
+ 		   -fno-builtin -ffreestanding
+-KBUILD_CFLAGS	+= -fshort-wchar -Werror
++KBUILD_CFLAGS	+= -fshort-wchar
+ KBUILD_AFLAGS   := -D__ASSEMBLY__
+ 
+ # Read UBOOTRELEASE from include/config/uboot.release (if it exists)
diff --git a/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb b/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb
index 4545f13..f4ecbae 100644
--- a/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb
+++ b/recipes-bsp/u-boot/u-boot-rockchip_20171218.bb
@@ -9,5 +9,9 @@ TAG = "release-${PV}"
 SRC_URI = " \
 	git://github.com/rockchip-linux/u-boot.git;tag=${TAG};nobranch=1; \
 	file://binutils-2.28-ld-fix.patch \
+	file://gcc7_fixup.patch \
+	file://gcc9-no-Werror.patch \
 "
 S = "${WORKDIR}/git"
+
+SRCREV = "release-20171218"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:14:10 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:14:10 +0800
Subject: [yocto] [PATCH v2 3/3] recipes-bsp/u-boot: update to the latest
	version
In-Reply-To: <20190620111410.4573-1-ayaka@soulik.info>
References: <20190620111410.4573-1-ayaka@soulik.info>
Message-ID: <20190620111410.4573-4-ayaka@soulik.info>

From: Randy Li <ayaka at soulik.info>

Signed-off-by: Randy Li <ayaka at soulik.info>
---
 recipes-bsp/u-boot/u-boot-rockchip_git.bb | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 recipes-bsp/u-boot/u-boot-rockchip_git.bb

diff --git a/recipes-bsp/u-boot/u-boot-rockchip_git.bb b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
new file mode 100644
index 0000000..5b04b62
--- /dev/null
+++ b/recipes-bsp/u-boot/u-boot-rockchip_git.bb
@@ -0,0 +1,19 @@
+# Copyright (C) 2019 SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+include u-boot-rockchip.inc
+
+DESCRIPTION = "Rockchip U-Boot"
+
+LIC_FILES_CHKSUM = "file://Licenses/README;md5=a2c678cfd4a4d97135585cad908541c6"
+
+SRC_URI = " \
+	git://github.com/rockchip-linux/u-boot.git;branch=release; \
+	file://gcc7_fixup.patch \
+	file://gcc9-no-Werror.patch \
+"
+SRCREV = "${AUTOREV}"
+
+S = "${WORKDIR}/git"
+PV = "v2019.01"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:02 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:02 +0800
Subject: [yocto] [meta-rockchip] [PATCH v3 0/9] add new SoCs support
Message-ID: <20190620111911.4736-1-ayaka@soulik.info>

Changelog
v2 Removing the settings applied for vendor kernel
v2 Adding some SoCs which are supported by the upstream kernel
v3 Adding new chip RK1808

Randy 'ayaka' Li (8):
  conf/machine: add support for rk3399
  conf/machine: add support for rk3328
  conf/machine: add support for rv1108
  conf/machine: add support for rk3036
  conf/machine: add support for rk312x
  conf/machine: add support for rk3326
  conf/machine: add support for rk3368
  conf/machine: add support for rk3308

Randy Li (1):
  conf/machine: add support for rk1808

 conf/machine/evb-rk3328.conf       | 11 +++++++++++
 conf/machine/evb-rv1108.conf       | 10 ++++++++++
 conf/machine/excavator-rk3399.conf | 12 ++++++++++++
 conf/machine/firefly-rk3399.conf   | 14 ++++++++++++++
 conf/machine/include/rk1808.inc    | 17 +++++++++++++++++
 conf/machine/include/rk3036.inc    | 16 ++++++++++++++++
 conf/machine/include/rk312x.inc    | 17 +++++++++++++++++
 conf/machine/include/rk3308.inc    | 17 +++++++++++++++++
 conf/machine/include/rk3326.inc    | 18 ++++++++++++++++++
 conf/machine/include/rk3328.inc    | 18 ++++++++++++++++++
 conf/machine/include/rk3368.inc    | 17 +++++++++++++++++
 conf/machine/include/rk3399.inc    | 17 +++++++++++++++++
 conf/machine/include/rv1108.inc    | 16 ++++++++++++++++
 conf/machine/kylin-rk3036.conf     | 12 ++++++++++++
 14 files changed, 212 insertions(+)
 create mode 100644 conf/machine/evb-rk3328.conf
 create mode 100644 conf/machine/evb-rv1108.conf
 create mode 100644 conf/machine/excavator-rk3399.conf
 create mode 100644 conf/machine/firefly-rk3399.conf
 create mode 100644 conf/machine/include/rk1808.inc
 create mode 100644 conf/machine/include/rk3036.inc
 create mode 100644 conf/machine/include/rk312x.inc
 create mode 100644 conf/machine/include/rk3308.inc
 create mode 100644 conf/machine/include/rk3326.inc
 create mode 100644 conf/machine/include/rk3328.inc
 create mode 100644 conf/machine/include/rk3368.inc
 create mode 100644 conf/machine/include/rk3399.inc
 create mode 100644 conf/machine/include/rv1108.inc
 create mode 100644 conf/machine/kylin-rk3036.conf

-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:03 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:03 +0800
Subject: [yocto] [PATCH v3 1/9] conf/machine: add support for rk3399
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-2-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RK3399 is a new generation powerful SoC from Rockchip, which has
Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/excavator-rk3399.conf | 12 ++++++++++++
 conf/machine/firefly-rk3399.conf   | 14 ++++++++++++++
 conf/machine/include/rk3399.inc    | 17 +++++++++++++++++
 3 files changed, 43 insertions(+)
 create mode 100644 conf/machine/excavator-rk3399.conf
 create mode 100644 conf/machine/firefly-rk3399.conf
 create mode 100644 conf/machine/include/rk3399.inc

diff --git a/conf/machine/excavator-rk3399.conf b/conf/machine/excavator-rk3399.conf
new file mode 100644
index 0000000..8506a50
--- /dev/null
+++ b/conf/machine/excavator-rk3399.conf
@@ -0,0 +1,12 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: EXCAVATOR 3399
+
+include conf/machine/include/rk3399.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-sapphire-excavator.dtb"
+UBOOT_MACHINE = "evb-rk3399_defconfig"
+
+GPTIMG_APPEND = "console=ttyS2,1500000n8 rw root=PARTUUID=B921B045-1DF0 rootfstype=ext4 init=/sbin/init"
diff --git a/conf/machine/firefly-rk3399.conf b/conf/machine/firefly-rk3399.conf
new file mode 100644
index 0000000..4e35c3d
--- /dev/null
+++ b/conf/machine/firefly-rk3399.conf
@@ -0,0 +1,14 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: Firefly RK3399
+#@DESCRIPTION: Firefly-RK3399 is a Six-Core 64-bit High-Performance Platform.
+#http://www.t-firefly.com/en/
+
+include conf/machine/include/rk3399.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-firefly.dtb"
+UBOOT_MACHINE = "evb-rk3399_defconfig"
+
+GPTIMG_APPEND = "console=ttyS2,1500000n8 rw root=PARTUUID=B921B045-1DF0 rootfstype=ext4 init=/sbin/init"
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
new file mode 100644
index 0000000..9237616
--- /dev/null
+++ b/conf/machine/include/rk3399.inc
@@ -0,0 +1,17 @@
+# Copyright (C) 2019 SUMOMO Computer Association
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3399"
+
+require conf/machine/include/tune-cortexa72.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:04 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:04 +0800
Subject: [yocto] [PATCH v3 2/9] conf/machine: add support for rk3328
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-3-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

The RK3328 is a SoC with Quad-core Cortex-A53 for Smart OTT/IPTV.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/evb-rk3328.conf    | 11 +++++++++++
 conf/machine/include/rk3328.inc | 18 ++++++++++++++++++
 2 files changed, 29 insertions(+)
 create mode 100644 conf/machine/evb-rk3328.conf
 create mode 100644 conf/machine/include/rk3328.inc

diff --git a/conf/machine/evb-rk3328.conf b/conf/machine/evb-rk3328.conf
new file mode 100644
index 0000000..ae2c0f8
--- /dev/null
+++ b/conf/machine/evb-rk3328.conf
@@ -0,0 +1,11 @@
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: EVB 3388
+
+include conf/machine/include/rk3328.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3328-evb.dtb"
+UBOOT_MACHINE = "evb-rk3328_defconfig"
+
+GPTIMG_APPEND = "console=ttyS2,1500000n8 rw root=PARTUUID=B921B045-1DF0 rootfstype=ext4 init=/sbin/init"
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..de5c9f4
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,18 @@
+# Copyright (C) 2017 Randy Li <ayaka at soulik.info>
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+# RK3228H is the same SoC as rk3328.
+SOC_FAMILY = "rk3328"
+
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:05 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:05 +0800
Subject: [yocto] [PATCH v3 3/9] conf/machine: add support for rv1108
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-4-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RV1108 is a SoC specific for video enhanced and
recording. It is embedded with a DSP for digital
process and an ARM Cortex-A7 single core processor
for system and application.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/evb-rv1108.conf    | 10 ++++++++++
 conf/machine/include/rv1108.inc | 16 ++++++++++++++++
 2 files changed, 26 insertions(+)
 create mode 100644 conf/machine/evb-rv1108.conf
 create mode 100644 conf/machine/include/rv1108.inc

diff --git a/conf/machine/evb-rv1108.conf b/conf/machine/evb-rv1108.conf
new file mode 100644
index 0000000..3e85d80
--- /dev/null
+++ b/conf/machine/evb-rv1108.conf
@@ -0,0 +1,10 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: EVB rv1108
+
+include conf/machine/include/rv1108.inc
+
+KERNEL_DEVICETREE = "rv1108-evb.dtb"
+UBOOT_MACHINE = "evb-rk3288_defconfig"
diff --git a/conf/machine/include/rv1108.inc b/conf/machine/include/rv1108.inc
new file mode 100644
index 0000000..c1bb584
--- /dev/null
+++ b/conf/machine/include/rv1108.inc
@@ -0,0 +1,16 @@
+# Copyright (C) 2019 Randy 'ayaka' Li <ayaka at soulik.info>
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rv1108"
+
+require conf/machine/include/tune-cortexa7.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+SPL_BINARY ?= "u-boot-spl-nodtb.bin"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:06 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:06 +0800
Subject: [yocto] [PATCH v3 4/9] conf/machine: add support for rk3036
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-5-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RK3036 is a SoC from Rockchip which has Dual-Core
ARM Cortex-A7 CPU, for low-end OTT TV Box.

Supporting video acceleration for the HEVC and AVC
up to 1080P video. With a HDMI sink.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
Signed-off-by: Randy Li <randy.li at rock-chips.com>
---
 conf/machine/include/rk3036.inc | 16 ++++++++++++++++
 conf/machine/kylin-rk3036.conf  | 12 ++++++++++++
 2 files changed, 28 insertions(+)
 create mode 100644 conf/machine/include/rk3036.inc
 create mode 100644 conf/machine/kylin-rk3036.conf

diff --git a/conf/machine/include/rk3036.inc b/conf/machine/include/rk3036.inc
new file mode 100644
index 0000000..196f5a3
--- /dev/null
+++ b/conf/machine/include/rk3036.inc
@@ -0,0 +1,16 @@
+# Copyright (C) 2018 Randy 'ayaka' Li <ayaka at soulik.info>
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3036"
+
+require conf/machine/include/tune-cortexa7.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "115200;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+SPL_BINARY ?= "u-boot-spl-nodtb.bin"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
diff --git a/conf/machine/kylin-rk3036.conf b/conf/machine/kylin-rk3036.conf
new file mode 100644
index 0000000..e47a3be
--- /dev/null
+++ b/conf/machine/kylin-rk3036.conf
@@ -0,0 +1,12 @@
+# Copyright (C) 2017 Fuzhou Rockchip Electronics Co., Ltd
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+#@TYPE: Machine
+#@NAME: Kylin rk3036
+
+include conf/machine/include/rk3036.inc
+
+KERNEL_DEVICETREE = "rk3036-kylin.dtb"
+UBOOT_MACHINE = "kylin-rk3036_defconfig"
+
+GPTIMG_APPEND = "console=ttyS2,115200n8 rw root=PARTUUID=69DAD710-2CE4 rootfstype=ext4 init=/sbin/init"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:07 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:07 +0800
Subject: [yocto] [PATCH v3 5/9] conf/machine: add support for rk312x
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-6-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RK312X are a serial called RK audio. All of them sharing
the simliar hardware configure. A quad-core ARM Cortex-A7
processor with separately Neon and FPU coprocessor, they
also share a 256KB L2 Cache.

All chips in this serial have a Mali 400 MP2 GPU.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/include/rk312x.inc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 conf/machine/include/rk312x.inc

diff --git a/conf/machine/include/rk312x.inc b/conf/machine/include/rk312x.inc
new file mode 100644
index 0000000..675c699
--- /dev/null
+++ b/conf/machine/include/rk312x.inc
@@ -0,0 +1,17 @@
+# Copyright (C) 2019 SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+# a serial of chips
+SOC_FAMILY = "rk312x"
+
+require conf/machine/include/tune-cortexa7.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "115200;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+SPL_BINARY ?= "u-boot-spl-nodtb.bin"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:08 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:08 +0800
Subject: [yocto] [PATCH v3 6/9] conf/machine: add support for rk3326
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-7-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RK3326 is a high-performance quad-core application processor,
it supports both H.264 and H.265 decoding up to 1920x1080 at 30fps.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/include/rk3326.inc | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)
 create mode 100644 conf/machine/include/rk3326.inc

diff --git a/conf/machine/include/rk3326.inc b/conf/machine/include/rk3326.inc
new file mode 100644
index 0000000..1208b65
--- /dev/null
+++ b/conf/machine/include/rk3326.inc
@@ -0,0 +1,18 @@
+# Copyright (C) 2019 SUMOMO Computer Association
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+# PX30 is the same SoC as rk3326.
+SOC_FAMILY = "rk3326"
+
+require conf/machine/include/tune-cortexa35.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:09 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:09 +0800
Subject: [yocto] [PATCH v3 7/9] conf/machine: add support for rk3368
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-8-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RK3368 is integrated with a qual-core Cortex-A53 processor
and separately NEON coprocessor.

RK3368 supports H.264 decoder up to 4Kx2K at 30fps, H.265
decoder by 4Kx2K at 60fps.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/include/rk3368.inc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 conf/machine/include/rk3368.inc

diff --git a/conf/machine/include/rk3368.inc b/conf/machine/include/rk3368.inc
new file mode 100644
index 0000000..1738f74
--- /dev/null
+++ b/conf/machine/include/rk3368.inc
@@ -0,0 +1,17 @@
+# Copyright (C) 2019 SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3368"
+
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:10 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:10 +0800
Subject: [yocto] [PATCH v3 8/9] conf/machine: add support for rk3308
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-9-ayaka@soulik.info>

From: Randy 'ayaka' Li <ayaka at soulik.info>

RK3308 is a high-performance quad-core application processor
designed for intelligent voice interaction.

Signed-off-by: Randy 'ayaka' Li <ayaka at soulik.info>
---
 conf/machine/include/rk3308.inc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 conf/machine/include/rk3308.inc

diff --git a/conf/machine/include/rk3308.inc b/conf/machine/include/rk3308.inc
new file mode 100644
index 0000000..81e4def
--- /dev/null
+++ b/conf/machine/include/rk3308.inc
@@ -0,0 +1,17 @@
+# Copyright (C) SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3308"
+
+require conf/machine/include/tune-cortexa35.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From ayaka at soulik.info  Thu Jun 20 04:19:11 2019
From: ayaka at soulik.info (ayaka)
Date: Thu, 20 Jun 2019 19:19:11 +0800
Subject: [yocto] [PATCH v3 9/9] conf/machine: add support for rk1808
In-Reply-To: <20190620111911.4736-1-ayaka@soulik.info>
References: <20190620111911.4736-1-ayaka@soulik.info>
Message-ID: <20190620111911.4736-10-ayaka@soulik.info>

From: Randy Li <randy.li at rock-chips.com>

RK1808 is an ARM processor with a neural network process unit,
which can acceleration the inference of deep learning.

Signed-off-by: Randy Li <randy.li at rock-chips.com>
---
 conf/machine/include/rk1808.inc | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 conf/machine/include/rk1808.inc

diff --git a/conf/machine/include/rk1808.inc b/conf/machine/include/rk1808.inc
new file mode 100644
index 0000000..6edd67c
--- /dev/null
+++ b/conf/machine/include/rk1808.inc
@@ -0,0 +1,17 @@
+# Copyright (C) SUMOMO Computer Assocation
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk1808"
+
+require conf/machine/include/tune-cortexa35.inc
+require conf/machine/include/soc-family.inc
+require conf/machine/include/rockchip-defaults.inc
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+KERNEL_IMAGETYPE = "Image"
+KBUILD_DEFCONFIG = "defconfig"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot-rockchip"
+
+IMAGE_FSTYPES = "rockchip-gpt-img"
+IMAGE_CLASSES = "rockchip-gpt-img"
-- 
2.21.0


From changqing.li at windriver.com  Thu Jun 20 19:04:56 2019
From: changqing.li at windriver.com (changqing.li at windriver.com)
Date: Fri, 21 Jun 2019 10:04:56 +0800
Subject: [yocto] [poky][PATCH] update-rc.d: update refer link
Message-ID: <1561082696-19845-1-git-send-email-changqing.li@windriver.com>

From: Changqing Li <changqing.li at windriver.com>

old referred link is not aligned with yocto's update-rc.d.
update it to align with current one

[Yocto #12955]

Signed-off-by: Changqing Li <changqing.li at windriver.com>
---
 documentation/ref-manual/ref-variables.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 12876e3..e5d6136 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -7243,7 +7243,7 @@
                     to the <filename>update-rc.d</filename> command.
                     For more information on valid parameters, please see the
                     <filename>update-rc.d</filename> manual page at
-                    <ulink url='http://www.tin.org/bin/man.cgi?section=8&amp;topic=update-rc.d'></ulink>.
+                    <ulink url='https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html'></ulink>.
                 </para>
             </glossdef>
         </glossentry>
-- 
2.7.4


From yocto at mindchasers.com  Thu Jun 20 20:24:51 2019
From: yocto at mindchasers.com (Bob Cochran)
Date: Thu, 20 Jun 2019 23:24:51 -0400
Subject: [yocto] Looking for a recommendation for the right Yocto dev board
 that supports MIPI CSI-2...
Message-ID: <86eeb8cf-ff2a-e782-c7a9-44fc4496bf62@mindchasers.com>

Hi,

I'm doing some work with MIPI cameras, and I need a development board 
with stable Yocto and MIPI CSI-2 support.?? At this point, I'm thinking 
i.MX, but I'm open to any suggestion.

I'm not sure what type of access I'll have to the D-PHY data streams.? 
Do they always terminate into a GPU??? However, I would like a board 
that gives me the most capability to control / route the data with open 
source drivers.

I suppose I want CSI-2 in and HDMI out.

Thank you,

Bob



From martin.jansa at gmail.com  Fri Jun 21 05:52:37 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Fri, 21 Jun 2019 14:52:37 +0200
Subject: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
In-Reply-To: <20190611070823.367-1-Martin.Jansa@gmail.com>
References: <20190611070823.367-1-Martin.Jansa@gmail.com>
Message-ID: <CA+chaQfFa0PyiDx78Qba1PnKYn+fDvKGS7TqGgGuzV-Mx+g9Sw@mail.gmail.com>

ping for warrior

On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa <martin.jansa at gmail.com> wrote:

> * bc can be provided by busybox as well (e.g. if you have your own
>   defconfig and forget to explicitly disable it:
>   ...
>   *
>   * Miscellaneous Utilities
>   *
>   adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
>   bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
>   bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
>     Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y]
> (NEW) y
>       Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)
>  Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4
> kb) (BEEP) [N/y/?] n
>   chat (6.3 kb) (CHAT) [N/y/?] n
>   conspy (10 kb) (CONSPY) [N/y/?] n
>   ...
>   ), causing conflict in u-a:
>
>   update-alternatives: Error: not linking /usr/bin/bc to
> /bin/busybox.nosuid since /usr/bin/bc exists and is not a link
>
>   and then whole do_rootfs or do_populate_sdk to fail because busybox
> postinst is failing:
>
>   do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If
> the intention is to defer them to first boot,
>   then please place them into pkg_postinst_ontarget_${PN} (). Deferring to
> first boot via 'exit 1' is no longer supported.
>
> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> ---
>  recipes-extended/bc/bc_1.06.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/
> bc_1.06.bb
> index d8c8a86..3de1b24 100644
> --- a/recipes-extended/bc/bc_1.06.bb
> +++ b/recipes-extended/bc/bc_1.06.bb
> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
> "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
>
>  inherit autotools texinfo update-alternatives
>
> -ALTERNATIVE_${PN} = "dc"
> +ALTERNATIVE_${PN} = "bc dc"
>  ALTERNATIVE_PRIORITY = "100"
>
>  BBCLASSEXTEND = "native"
> --
> 2.17.1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190621/e2e68a25/attachment.html>

From ross.burton at intel.com  Fri Jun 21 05:59:32 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Fri, 21 Jun 2019 13:59:32 +0100
Subject: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
In-Reply-To: <CA+chaQfFa0PyiDx78Qba1PnKYn+fDvKGS7TqGgGuzV-Mx+g9Sw@mail.gmail.com>
References: <20190611070823.367-1-Martin.Jansa@gmail.com>
	<CA+chaQfFa0PyiDx78Qba1PnKYn+fDvKGS7TqGgGuzV-Mx+g9Sw@mail.gmail.com>
Message-ID: <CAJTo0LbmgN2Zg9JBaoQdvqk0CsGy+tAbTFqJ+SxuAxiap1xYFA@mail.gmail.com>

Done, sorry.

Ross

On Fri, 21 Jun 2019 at 13:53, Martin Jansa <martin.jansa at gmail.com> wrote:
>
> ping for warrior
>
> On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa <martin.jansa at gmail.com> wrote:
>>
>> * bc can be provided by busybox as well (e.g. if you have your own
>>   defconfig and forget to explicitly disable it:
>>   ...
>>   *
>>   * Miscellaneous Utilities
>>   *
>>   adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
>>   bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
>>   bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
>>     Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
>>       Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)     Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) [N/y/?] n
>>   chat (6.3 kb) (CHAT) [N/y/?] n
>>   conspy (10 kb) (CONSPY) [N/y/?] n
>>   ...
>>   ), causing conflict in u-a:
>>
>>   update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid since /usr/bin/bc exists and is not a link
>>
>>   and then whole do_rootfs or do_populate_sdk to fail because busybox postinst is failing:
>>
>>   do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
>>   then please place them into pkg_postinst_ontarget_${PN} (). Deferring to first boot via 'exit 1' is no longer supported.
>>
>> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
>> ---
>>  recipes-extended/bc/bc_1.06.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
>> index d8c8a86..3de1b24 100644
>> --- a/recipes-extended/bc/bc_1.06.bb
>> +++ b/recipes-extended/bc/bc_1.06.bb
>> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] = "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
>>
>>  inherit autotools texinfo update-alternatives
>>
>> -ALTERNATIVE_${PN} = "dc"
>> +ALTERNATIVE_${PN} = "bc dc"
>>  ALTERNATIVE_PRIORITY = "100"
>>
>>  BBCLASSEXTEND = "native"
>> --
>> 2.17.1
>>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From martin.jansa at gmail.com  Fri Jun 21 06:18:24 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Fri, 21 Jun 2019 15:18:24 +0200
Subject: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
In-Reply-To: <CAJTo0LbmgN2Zg9JBaoQdvqk0CsGy+tAbTFqJ+SxuAxiap1xYFA@mail.gmail.com>
References: <20190611070823.367-1-Martin.Jansa@gmail.com>
	<CA+chaQfFa0PyiDx78Qba1PnKYn+fDvKGS7TqGgGuzV-Mx+g9Sw@mail.gmail.com>
	<CAJTo0LbmgN2Zg9JBaoQdvqk0CsGy+tAbTFqJ+SxuAxiap1xYFA@mail.gmail.com>
Message-ID: <CA+chaQfho=Jhrvt3ZfQW_wagonLb6Jc2dtZJg7+QEoVh4UA+9w@mail.gmail.com>

No problem, thanks for quick response.

Looks like this patch wasn't merged in master as well (I thought it was),
can you please push it as well.

Thanks

On Fri, Jun 21, 2019 at 2:59 PM Burton, Ross <ross.burton at intel.com> wrote:

> Done, sorry.
>
> Ross
>
> On Fri, 21 Jun 2019 at 13:53, Martin Jansa <martin.jansa at gmail.com> wrote:
> >
> > ping for warrior
> >
> > On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa <martin.jansa at gmail.com>
> wrote:
> >>
> >> * bc can be provided by busybox as well (e.g. if you have your own
> >>   defconfig and forget to explicitly disable it:
> >>   ...
> >>   *
> >>   * Miscellaneous Utilities
> >>   *
> >>   adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
> >>   bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
> >>   bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
> >>     Use bc code base for dc (larger, more features) (FEATURE_DC_BIG)
> [Y] (NEW) y
> >>       Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)
>  Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4
> kb) (BEEP) [N/y/?] n
> >>   chat (6.3 kb) (CHAT) [N/y/?] n
> >>   conspy (10 kb) (CONSPY) [N/y/?] n
> >>   ...
> >>   ), causing conflict in u-a:
> >>
> >>   update-alternatives: Error: not linking /usr/bin/bc to
> /bin/busybox.nosuid since /usr/bin/bc exists and is not a link
> >>
> >>   and then whole do_rootfs or do_populate_sdk to fail because busybox
> postinst is failing:
> >>
> >>   do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed.
> If the intention is to defer them to first boot,
> >>   then please place them into pkg_postinst_ontarget_${PN} (). Deferring
> to first boot via 'exit 1' is no longer supported.
> >>
> >> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
> >> ---
> >>  recipes-extended/bc/bc_1.06.bb | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/
> bc_1.06.bb
> >> index d8c8a86..3de1b24 100644
> >> --- a/recipes-extended/bc/bc_1.06.bb
> >> +++ b/recipes-extended/bc/bc_1.06.bb
> >> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
> "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
> >>
> >>  inherit autotools texinfo update-alternatives
> >>
> >> -ALTERNATIVE_${PN} = "dc"
> >> +ALTERNATIVE_${PN} = "bc dc"
> >>  ALTERNATIVE_PRIORITY = "100"
> >>
> >>  BBCLASSEXTEND = "native"
> >> --
> >> 2.17.1
> >>
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190621/a348d4cf/attachment-0001.html>

From ross.burton at intel.com  Fri Jun 21 06:48:24 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Fri, 21 Jun 2019 14:48:24 +0100
Subject: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
In-Reply-To: <CA+chaQfho=Jhrvt3ZfQW_wagonLb6Jc2dtZJg7+QEoVh4UA+9w@mail.gmail.com>
References: <20190611070823.367-1-Martin.Jansa@gmail.com>
	<CA+chaQfFa0PyiDx78Qba1PnKYn+fDvKGS7TqGgGuzV-Mx+g9Sw@mail.gmail.com>
	<CAJTo0LbmgN2Zg9JBaoQdvqk0CsGy+tAbTFqJ+SxuAxiap1xYFA@mail.gmail.com>
	<CA+chaQfho=Jhrvt3ZfQW_wagonLb6Jc2dtZJg7+QEoVh4UA+9w@mail.gmail.com>
Message-ID: <CAJTo0Lap0YwMvt20QykrkQz77hO2cvtZWBtyaEezmrMD1qqE+g@mail.gmail.com>

Whoops.  Done :)

On Fri, 21 Jun 2019 at 14:18, Martin Jansa <martin.jansa at gmail.com> wrote:
>
> No problem, thanks for quick response.
>
> Looks like this patch wasn't merged in master as well (I thought it was), can you please push it as well.
>
> Thanks
>
> On Fri, Jun 21, 2019 at 2:59 PM Burton, Ross <ross.burton at intel.com> wrote:
>>
>> Done, sorry.
>>
>> Ross
>>
>> On Fri, 21 Jun 2019 at 13:53, Martin Jansa <martin.jansa at gmail.com> wrote:
>> >
>> > ping for warrior
>> >
>> > On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa <martin.jansa at gmail.com> wrote:
>> >>
>> >> * bc can be provided by busybox as well (e.g. if you have your own
>> >>   defconfig and forget to explicitly disable it:
>> >>   ...
>> >>   *
>> >>   * Miscellaneous Utilities
>> >>   *
>> >>   adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
>> >>   bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
>> >>   bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
>> >>     Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y] (NEW) y
>> >>       Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)     Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4 kb) (BEEP) [N/y/?] n
>> >>   chat (6.3 kb) (CHAT) [N/y/?] n
>> >>   conspy (10 kb) (CONSPY) [N/y/?] n
>> >>   ...
>> >>   ), causing conflict in u-a:
>> >>
>> >>   update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid since /usr/bin/bc exists and is not a link
>> >>
>> >>   and then whole do_rootfs or do_populate_sdk to fail because busybox postinst is failing:
>> >>
>> >>   do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
>> >>   then please place them into pkg_postinst_ontarget_${PN} (). Deferring to first boot via 'exit 1' is no longer supported.
>> >>
>> >> Signed-off-by: Martin Jansa <Martin.Jansa at gmail.com>
>> >> ---
>> >>  recipes-extended/bc/bc_1.06.bb | 2 +-
>> >>  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
>> >> index d8c8a86..3de1b24 100644
>> >> --- a/recipes-extended/bc/bc_1.06.bb
>> >> +++ b/recipes-extended/bc/bc_1.06.bb
>> >> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] = "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
>> >>
>> >>  inherit autotools texinfo update-alternatives
>> >>
>> >> -ALTERNATIVE_${PN} = "dc"
>> >> +ALTERNATIVE_${PN} = "bc dc"
>> >>  ALTERNATIVE_PRIORITY = "100"
>> >>
>> >>  BBCLASSEXTEND = "native"
>> >> --
>> >> 2.17.1
>> >>
>> > --
>> > _______________________________________________
>> > yocto mailing list
>> > yocto at yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto

From elcapitanbrown at gmail.com  Fri Jun 21 10:46:21 2019
From: elcapitanbrown at gmail.com (Larry Brown)
Date: Fri, 21 Jun 2019 13:46:21 -0400
Subject: [yocto] Creating my own bsp
Message-ID: <CAOmL4UhzAiin-LzbTQjgFbnKw8KOS=7EbktWcByVsXacB1JhpA@mail.gmail.com>

I've come across references to "yocto-bsp" script that should help build a
bsp.  I'm starting from scratch with an arm 7M and trying to use the
raspberrypi bsp as a reference.  There is so much complexity I'm not sure
where to start.

After setting up the files for the Linux kernel I'm using already on the
board and the config, it first complained about TUNE_ARCH not being
present.  This is not present in the meta-raspberrypi content but based on
something I came across this just wants arm.  Then it complains
TUNE_PKGARCH is not set.  I don't know what this is looking for and I'm not
getting effective hits searching for it.  I'm guessing there are going to
be a lot more after these two complaints.  It would be nice to read what
went into a simple bsp that worked under for an arm board.

PS I'm using the warrior release as it worked for bringing up the raspberry
pi.

Any help would be greatly appreciated.

-- 
Larry Brown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190621/e49efc11/attachment.html>

From akuster808 at gmail.com  Sat Jun 22 09:59:19 2019
From: akuster808 at gmail.com (akuster808)
Date: Sat, 22 Jun 2019 09:59:19 -0700
Subject: [yocto] update-rc.d 0.9 request
Message-ID: <4f64137b-5a26-9799-0fff-f524e786941d@gmail.com>

Is is possible to bump the version of update-rc.d
<https://git.yoctoproject.org/cgit/cgit.cgi/update-rc.d/> to 0.9 ? New
functionality was added after 0.8 and a simple hash makes version
control harder.

- Armin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190622/ad08a9ad/attachment.html>

From balazovic.peter at gmail.com  Thu Jun 20 09:01:27 2019
From: balazovic.peter at gmail.com (Peter Balazovic)
Date: Thu, 20 Jun 2019 18:01:27 +0200
Subject: [yocto] Warrior, extended SDK
Message-ID: <CAFq4t4gy3vRzfR00sz8PPS3VUGE_YXu2tJYD8KWnEvUBk4DhEg@mail.gmail.com>

Hello guys

I'm trying to generate extended SDK under Yocto-Warrior and getting error
such as

ERROR: image-qt5-1.0-r0 do_sdk_depends: The file
/usr/include/tensorflow/contrib/lite/string_util.h is installed by both
tensorflow and tensorflow-lite, aborting
ERROR: image-qt5-1.0-r0 do_sdk_depends:
ERROR: image-qt5-1.0-r0 do_sdk_depends: Function failed:
extend_recipe_sysroot

can you help me identify an issue on this fail?

Thanks.
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190620/18ade7ae/attachment.html>

From b at halonis.de  Fri Jun 21 15:08:28 2019
From: b at halonis.de (Benjamin)
Date: Sat, 22 Jun 2019 00:08:28 +0200
Subject: [yocto] Running Yocto inside Docker
In-Reply-To: <CAPxNcnfeBKEEn-fEW2evxd3O3uVxrFmuOJMb6quwZz=oGpXgYg@mail.gmail.com>
References: <CAAx3WaCUb18Yf6Qp33qQCu9O3s-qpa75uoSm+sKv89jR0FbZmQ@mail.gmail.com>
	<CAPxNcnfeBKEEn-fEW2evxd3O3uVxrFmuOJMb6quwZz=oGpXgYg@mail.gmail.com>
Message-ID: <61eed6bb-10f6-e46a-7735-431934ace662@xunit.de>

Hej,

I use for this secret variables and store the access tokens or ssh keys
in in one of this. A script running inside of the docker container uses
sed magic for replacing string, when ever the direct usage of the secret
variables is not possible. The ssh key is then written in a first step
with something like

echo "$SECRET_PRIVATE_SSH" > ~/.ssh/id_ecdsa && chmod 600 ~/.ssh/id_ecdsa

gitlab will not print the secret variables in clear format.

https://docs.gitlab.com/ee/ci/variables/#via-the-ui

Whenever possible you should use a deploy token, best would be to add
this as well as the above mentioned ui variables. With the protected
feature you can even prevent non privileged developers from stealing
this secrets.

https://docs.gitlab.com/ee/user/project/deploy_tokens/#creating-a-deploy-token


Am 17.06.19 um 20:00 schrieb Rudolf Streif:
> That's more of a Gitlab than Yocto question. I am doing this all the
> time with my GL server on AWS. You need to add deploy a key to the
> repo you want to access and then push the key to your Docker instance
> from gitlab-ci.yaml from the repo that you are using with GL CI.
>
> :rjs
>
> On Mon, Jun 17, 2019, 07:20 Gabriele Zampieri <gabbla.malist at gmail.com
> <mailto:gabbla.malist at gmail.com>> wrote:
>
>     Hi all,
>
>     does anyone have a guide on how to setup Yocto to run inside
>     docker? Right now I managed to trigger the build from GitLab, but
>     I'm facing an issue related to ssh keys (some recipes from my meta
>     layer are hosted on a privare repository). Probably this is not
>     the best mailing list to ask this kind of question, but it may
>     worth a try.
>
>     Thank you,
>     Gabriele
>     -- 
>     _______________________________________________
>     yocto mailing list
>     yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>     https://lists.yoctoproject.org/listinfo/yocto
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190622/f389dd0b/attachment.html>

From piotr.betlej at googlemail.com  Sun Jun 23 01:46:53 2019
From: piotr.betlej at googlemail.com (Piotr Betlej)
Date: Sun, 23 Jun 2019 10:46:53 +0200
Subject: [yocto] dnf fail in do_rootfs cannot find shared library
Message-ID: <CAPLYstDpCM=6uwF=0gzA9u-C=LU0zfPnbWNsh-V9M0GL+g2wtw@mail.gmail.com>

Hi all,

this happens if one compiles a plain makefile project, since there is no
-Wl,-soname,my_library.so.1 linker option added automatically as it is in
case of using autotools or cmake for recipe.
DNF checks content of the so file and if it does not have SONAME inside, it
refuses to continue rootfs processing displaying confusing message "nothing
provides my_lib.so ...". There should be a better warning message or some
clean policy for it.

Regards

Piotr Betlej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190623/99e6639f/attachment.html>

From adim at jfrog.com  Sun Jun 23 06:15:48 2019
From: adim at jfrog.com (Adi Malca)
Date: Sun, 23 Jun 2019 16:15:48 +0300
Subject: [yocto] OPKG Spec
Message-ID: <CAM483UybQzjLoxaa6M25stxwf7xWXa-xW9Q6WxHz=PjwimaT3A@mail.gmail.com>

Hello,

I'm looking for the current official OPKG spec with spelling and case
sensitive.
For example:

*Package*:

*Version*:

*Description*:

*Section*:

*Priority*:

*Maintainer*:

*License*:

*Architecture*:

*OE*:

*Homepage*:

*Depends*:

*Source*:

*Filename*:

*SHA1*:

*SHA256*:


Best Regards,
Adi

-- 
 <https://support.jfrog.com/>

-- 
 
<https://swampup.jfrog.com/?utm_source=signature&utm_medium=email&utm_campaign=swampUP&utm_term=event&utm_content=all_06_19>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190623/6263cf71/attachment-0001.html>

From akuster808 at gmail.com  Sun Jun 23 11:15:10 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:10 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 1/9] runtime: tpm2 fix
	names in packagecheck
Message-ID: <20190623181518.19564-1-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 meta-tpm/lib/oeqa/runtime/cases/tpm2.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/lib/oeqa/runtime/cases/tpm2.py b/meta-tpm/lib/oeqa/runtime/cases/tpm2.py
index 240a9b3..c6f9d92 100644
--- a/meta-tpm/lib/oeqa/runtime/cases/tpm2.py
+++ b/meta-tpm/lib/oeqa/runtime/cases/tpm2.py
@@ -16,9 +16,9 @@ class Tpm2Test(OERuntimeTestCase):
         if expected_endlines:
             self.fail('Missing expected line endings:\n  %s' % '\n  '.join(expected_endlines))
 
-    @OEHasPackage(['tpm2.0-tss'])
+    @OEHasPackage(['tpm2-tss'])
     @OEHasPackage(['tpm2-abrmd'])
-    @OEHasPackage(['tpm2.0-tools'])
+    @OEHasPackage(['tpm2-tools'])
     @OEHasPackage(['ibmswtpm2'])
     @OETestDepends(['ssh.SSHTest.test_ssh'])
     def test_tpm2_sim(self):
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:11 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:11 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 2/9] tpm2 images: create
	tpm2 image and fix packagegroup
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-2-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../recipes-core/images/security-tpm2-image.bb | 18 ++++++++++++++++++
 .../packagegroup/packagegroup-security-tpm2.bb |  5 ++++-
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 meta-tpm/recipes-core/images/security-tpm2-image.bb

diff --git a/meta-tpm/recipes-core/images/security-tpm2-image.bb b/meta-tpm/recipes-core/images/security-tpm2-image.bb
new file mode 100644
index 0000000..7e047d1
--- /dev/null
+++ b/meta-tpm/recipes-core/images/security-tpm2-image.bb
@@ -0,0 +1,18 @@
+DESCRIPTION = "A small image for building a tpm2 image for testing"
+
+IMAGE_FEATURES += "ssh-server-openssh"
+
+IMAGE_INSTALL = "\
+    packagegroup-base \
+    packagegroup-core-boot \
+    packagegroup-security-tpm2 \
+    os-release \
+"
+
+IMAGE_LINGUAS ?= " "
+
+LICENSE = "MIT"
+
+inherit core-image
+
+export IMAGE_BASENAME = "security-tpm2-image"
diff --git a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
index 5ded3a2..9296d99 100644
--- a/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
+++ b/meta-tpm/recipes-core/packagegroup/packagegroup-security-tpm2.bb
@@ -5,17 +5,20 @@ LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda
 
 inherit packagegroup
 
-PACKAGES = "packagegroup-security-tpm2"
+PACKAGES = "${PN}"
 
 SUMMARY_packagegroup-security-tpm2 = "Security TPM 2.0 support"
 RDEPENDS_packagegroup-security-tpm2 = " \
     tpm2-tools \
     trousers \
+    tpm2-tss \
     libtss2 \
+    libtss2-mu \
     libtss2-tcti-device \
     libtss2-tcti-mssim \
     tpm2-abrmd \
     tpm2-pkcs11 \
+    ibmswtpm2 \
     cryptsetup-tpm-incubator \
     "
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:14 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:14 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 5/9] tpm2-tcti-uefi: update
	to tip
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-5-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 meta-tpm/recipes-tpm2/tpm2-tcti-uefi/tpm2-tcti-uefi_0.9.9.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tcti-uefi/tpm2-tcti-uefi_0.9.9.bb b/meta-tpm/recipes-tpm2/tpm2-tcti-uefi/tpm2-tcti-uefi_0.9.9.bb
index 815691d..43854c4 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tcti-uefi/tpm2-tcti-uefi_0.9.9.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tcti-uefi/tpm2-tcti-uefi_0.9.9.bb
@@ -7,7 +7,7 @@ DEPENDS = "libtss2-dev gnu-efi-native gnu-efi pkgconfig"
 SRC_URI = "git://github.com/tpm2-software/tpm2-tcti-uefi.git \
            file://configure_oe_fixup.patch \
           "
-SRCREV = "131889d12d2c7d8974711d2ebd1032cd32577b7f"
+SRCREV = "7baf1eebfeb56a896bdd5d677fb24377d619eb9d"
 
 S = "${WORKDIR}/git"
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:13 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:13 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 4/9]
	tpm2-pkcs11/tpm2-pkcs11: update to tip
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-4-akuster808@gmail.com>

license-check-sum: Add SPDX format

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_0.9.9.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_0.9.9.bb b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_0.9.9.bb
index 9031e63..222bb6d 100644
--- a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_0.9.9.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_0.9.9.bb
@@ -2,7 +2,7 @@ SUMMARY = "A PKCS#11 interface for TPM2 hardware"
 DESCRIPTION = "PKCS #11 is a Public-Key Cryptography Standard that defines a standard method to access cryptographic services from tokens/ devices such as hardware security modules (HSM), smart cards, etc. In this project we intend to use a TPM2 device as the cryptographic token."
 SECTION = "security/tpm"
 LICENSE = "BSD-2-Clause"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=b748af41ef1300c98e105b3b7ec4ecc1"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=93645981214b60a02688745c14f93c95"
 
 DEPENDS = "autoconf-archive pkgconfig dstat sqlite3 openssl libtss2-dev tpm2-tools"
 
@@ -10,7 +10,7 @@ SRC_URI = "git://github.com/tpm2-software/tpm2-pkcs11.git \
            file://bootstrap_fixup.patch \
           "
 
-SRCREV = "3107d89b406ecd9c007884613733c9a344ef6d39"
+SRCREV = "9eed9df823a960da481327468a73d477241befdb"
 
 S = "${WORKDIR}/git"
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:12 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:12 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 3/9] tpm image: split out
	tpm2
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-3-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 meta-tpm/recipes-core/images/security-tpm-image.bb | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/meta-tpm/recipes-core/images/security-tpm-image.bb b/meta-tpm/recipes-core/images/security-tpm-image.bb
index a337076..dbdd309 100644
--- a/meta-tpm/recipes-core/images/security-tpm-image.bb
+++ b/meta-tpm/recipes-core/images/security-tpm-image.bb
@@ -1,14 +1,13 @@
-DESCRIPTION = "A small image for building meta-security packages"
+DESCRIPTION = "A small image for building a tpm image for testing"
 
 IMAGE_FEATURES += "ssh-server-openssh"
 
 IMAGE_INSTALL = "\
     packagegroup-base \
     packagegroup-core-boot \
-    ${@bb.utils.contains('MACHINE_FEATURES', 'tpm',  'packagegroup-security-tpm',  '', d)} \
-    ${@bb.utils.contains('MACHINE_FEATURES', 'tpm2', 'packagegroup-security-tpm2', '', d)} \
+    packagegroup-security-tpm \
     os-release \
-    ${CORE_IMAGE_EXTRA_INSTALL}"
+"
 
 IMAGE_LINGUAS ?= " "
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:15 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:15 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 6/9] tpm2-tools: update to
	3.2.0
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-6-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../tpm2-tools/{tpm2-tools_3.1.3.bb => tpm2-tools_3.2.0.bb}     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta-tpm/recipes-tpm2/tpm2-tools/{tpm2-tools_3.1.3.bb => tpm2-tools_3.2.0.bb} (86%)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_3.1.3.bb b/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_3.2.0.bb
similarity index 86%
rename from meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_3.1.3.bb
rename to meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_3.2.0.bb
index 1f1f5c6..b6f1be0 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_3.1.3.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tools/tpm2-tools_3.2.0.bb
@@ -6,7 +6,7 @@ SECTION = "tpm"
 
 DEPENDS = "pkgconfig tpm2-tss openssl curl autoconf-archive"
 
-SRCREV = "74ba065e5914bc5d713ca3709d62a5751b097369"
+SRCREV = "a17daa948fc67685651bf3b7a589ed341080ddd3"
 
 SRC_URI = "git://github.com/tpm2-software/tpm2-tools.git;branch=3.X"
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:16 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:16 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 7/9] tpm2-tss: update to
	2.2.3
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-7-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../tpm2-tss/{tpm2-tss_2.2.1.bb => tpm2-tss_2.2.3.bb}           | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta-tpm/recipes-tpm2/tpm2-tss/{tpm2-tss_2.2.1.bb => tpm2-tss_2.2.3.bb} (97%)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.2.1.bb b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.2.3.bb
similarity index 97%
rename from meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.2.1.bb
rename to meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.2.3.bb
index 78bdeeb..cf93159 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.2.1.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_2.2.3.bb
@@ -6,7 +6,7 @@ SECTION = "tpm"
 
 DEPENDS = "autoconf-archive-native libgcrypt openssl"
 
-SRCREV = "eb69e13559f20a0b49002a685c6f4a39be9503e2"
+SRCREV = "36b1539c82bf675265d6f6a6cd808a189b6971f4"
 
 SRC_URI = "git://github.com/tpm2-software/tpm2-tss.git;branch=2.2.x"
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:17 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:17 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 8/9] tpm2-totp: update to
	offical release v0.1.1
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-8-akuster808@gmail.com>

Clean up recipe to match actual app

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../recipes-tpm2/tpm2-totp/tpm2-totp_0.1.1.bb  | 18 ++++++++++++++++++
 .../recipes-tpm2/tpm2-totp/tpm2-totp_0.9.9.bb  | 17 -----------------
 2 files changed, 18 insertions(+), 17 deletions(-)
 create mode 100644 meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.1.1.bb
 delete mode 100644 meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.9.9.bb

diff --git a/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.1.1.bb b/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.1.1.bb
new file mode 100644
index 0000000..d47b756
--- /dev/null
+++ b/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.1.1.bb
@@ -0,0 +1,18 @@
+SUMMARY = "Attest the trustworthiness of a device against a human using time-based one-time passwords"
+
+LICENSE = "BSD-3-Clause"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=ed23833e93c95173c8d8913745e4b4e1"
+
+SECTION = "security/tpm"
+
+DEPENDS = "autoconf-archive libtss2-dev qrencode"
+
+PE = "1"
+
+SRCREV = "2807a509a9da383e14dc0f759e71fd676db04ab1"
+SRC_URI = "git://github.com/tpm2-software/tpm2-totp.git;branch=v0.1.x \
+           file://litpm2_totp_build_fix.patch "
+
+inherit autotools-brokensep pkgconfig
+
+S = "${WORKDIR}/git"
diff --git a/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.9.9.bb b/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.9.9.bb
deleted file mode 100644
index bc94ab7..0000000
--- a/meta-tpm/recipes-tpm2/tpm2-totp/tpm2-totp_0.9.9.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-SUMMARY = "The tpm2-tss-engine project implements a cryptographic engine for OpenSSL." 
-DESCRIPTION = "The tpm2-tss-engine project implements a cryptographic engine for OpenSSL for Trusted Platform Module (TPM 2.0) using the tpm2-tss software stack that follows the Trusted Computing Groups (TCG) TPM Software Stack (TSS 2.0). It uses the Enhanced System API (ESAPI) interface of the TSS 2.0 for downwards communication. It supports RSA decryption and signatures as well as ECDSA signatures."
-
-LICENSE = "BSD-2-Clause"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=ed23833e93c95173c8d8913745e4b4e1"
-
-SECTION = "security/tpm"
-
-DEPENDS = "autoconf-archive libtss2-dev qrencode"
-
-SRCREV = "44fcb6819f79302d5a088b3def648616e3551d4a"
-SRC_URI = "git://github.com/tpm2-software/tpm2-totp.git \
-           file://litpm2_totp_build_fix.patch "
-
-inherit autotools-brokensep pkgconfig
-
-S = "${WORKDIR}/git"
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 11:15:18 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 11:15:18 -0700
Subject: [yocto] [meta-security][meta-tpm][PATCH 9/9] tpm2-tss-engine:
	update to 1.0.0
In-Reply-To: <20190623181518.19564-1-akuster808@gmail.com>
References: <20190623181518.19564-1-akuster808@gmail.com>
Message-ID: <20190623181518.19564-9-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../{tpm2-tss-engine_0.9.9.bb => tpm2-tss-engine_1.0.0.bb}      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta-tpm/recipes-tpm2/tpm2-tss-engine/{tpm2-tss-engine_0.9.9.bb => tpm2-tss-engine_1.0.0.bb} (95%)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tss-engine/tpm2-tss-engine_0.9.9.bb b/meta-tpm/recipes-tpm2/tpm2-tss-engine/tpm2-tss-engine_1.0.0.bb
similarity index 95%
rename from meta-tpm/recipes-tpm2/tpm2-tss-engine/tpm2-tss-engine_0.9.9.bb
rename to meta-tpm/recipes-tpm2/tpm2-tss-engine/tpm2-tss-engine_1.0.0.bb
index 36530be..0a8d54f 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tss-engine/tpm2-tss-engine_0.9.9.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tss-engine/tpm2-tss-engine_1.0.0.bb
@@ -8,7 +8,7 @@ SECTION = "security/tpm"
 
 DEPENDS = "autoconf-archive-native bash-completion libtss2 libgcrypt openssl"
 
-SRCREV = "bef89ec79cbb4c99963b0e336d9184827c545782"
+SRCREV = "a81d44a8610e28e5987af64f8aae16e4a2d09eaa"
 SRC_URI = "git://github.com/tpm2-software/tpm2-tss-engine.git"
 
 inherit autotools-brokensep pkgconfig systemd
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 17:09:26 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 17:09:26 -0700
Subject: [yocto] [meta-security][PATCH 1/2] libmspack: update SRC_URI and
	package
Message-ID: <20190624000927.20172-1-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../{libmspack_0.10.1.bb => libmspack_1.9.1.bb}        | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)
 rename recipes-security/libmspack/{libmspack_0.10.1.bb => libmspack_1.9.1.bb} (53%)

diff --git a/recipes-security/libmspack/libmspack_0.10.1.bb b/recipes-security/libmspack/libmspack_1.9.1.bb
similarity index 53%
rename from recipes-security/libmspack/libmspack_0.10.1.bb
rename to recipes-security/libmspack/libmspack_1.9.1.bb
index b46159f..8c288be 100644
--- a/recipes-security/libmspack/libmspack_0.10.1.bb
+++ b/recipes-security/libmspack/libmspack_1.9.1.bb
@@ -6,11 +6,11 @@ DEPENDS = ""
 
 LIC_FILES_CHKSUM = "file://COPYING.LIB;beginline=1;endline=2;md5=5b1fd1f66ef926b3c8a5bb00a72a28dd"
 
-SRC_URI = "${DEBIAN_MIRROR}/main/libm/${BPN}/${BPN}_${PV}.orig.tar.xz"
-
-SRC_URI[md5sum] = "d894d91eba4d2c6f76695fc9566d5387"
-SRC_URI[sha256sum] = "850c57442b850bf1bc0fc4ea8880903ebf2bed063c3c80782ee4626fbcb0e67d"
+SRCREV = "63d3faf90423a4a6c174539a7d32111a840adadc"
+SRC_URI = "git://github.com/kyz/libmspack.git"
 
 inherit autotools
 
-S = "${WORKDIR}/${BP}alpha"
+S = "${WORKDIR}/git/${BPN}"
+
+inherit autotools
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 23 17:09:27 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 23 Jun 2019 17:09:27 -0700
Subject: [yocto] [meta-security][PATCH 2/2] clamav: minor recipe cleanup
In-Reply-To: <20190624000927.20172-1-akuster808@gmail.com>
References: <20190624000927.20172-1-akuster808@gmail.com>
Message-ID: <20190624000927.20172-2-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 recipes-security/clamav/clamav_0.99.4.bb | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/recipes-security/clamav/clamav_0.99.4.bb b/recipes-security/clamav/clamav_0.99.4.bb
index 7d8767e..7f04337 100644
--- a/recipes-security/clamav/clamav_0.99.4.bb
+++ b/recipes-security/clamav/clamav_0.99.4.bb
@@ -66,14 +66,12 @@ EXTRA_OECONF_class-native += "${EXTRA_OECONF_CLAMAV}"
 EXTRA_OECONF_class-target += "--with-user=${UID}  --with-group=${GID} --disable-rpath ${EXTRA_OECONF_CLAMAV}"
 
 do_configure () {
-    cd ${S}
-    ./configure ${CONFIGUREOPTS} ${EXTRA_OECONF} 
+    ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} 
     install -d ${S}/clamav_db
 }
 
 do_configure_class-native () {
-    cd ${S}
-    ./configure ${CONFIGUREOPTS} ${EXTRA_OECONF} 
+    ${S}/configure ${CONFIGUREOPTS} ${EXTRA_OECONF} 
 }
 
 
-- 
2.17.1


From gabbla.malist at gmail.com  Sun Jun 23 23:03:12 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Mon, 24 Jun 2019 08:03:12 +0200
Subject: [yocto] Running Yocto inside Docker
In-Reply-To: <61eed6bb-10f6-e46a-7735-431934ace662@xunit.de>
References: <CAAx3WaCUb18Yf6Qp33qQCu9O3s-qpa75uoSm+sKv89jR0FbZmQ@mail.gmail.com>
	<CAPxNcnfeBKEEn-fEW2evxd3O3uVxrFmuOJMb6quwZz=oGpXgYg@mail.gmail.com>
	<61eed6bb-10f6-e46a-7735-431934ace662@xunit.de>
Message-ID: <CAAx3WaA8RjrihHoWDhFQ_+hj=e=m-h495w8VsH7gE-3aqLcGuQ@mail.gmail.com>

Hi all,

thank you for your suggestions! I googled a bit more and found this guide:

https://docs.gitlab.com/ce/ci/ssh_keys/README.html#ssh-keys-when-using-the-docker-executor

That is exactly what I was looking for! In this way I can avoid storing
keys in the containers and feeding it only when the pipe is triggered.

Best regards,
Gabriele

Il giorno sab 22 giu 2019 alle ore 22:37 Benjamin <b at halonis.de> ha scritto:

> Hej,
>
> I use for this secret variables and store the access tokens or ssh keys in
> in one of this. A script running inside of the docker container uses sed
> magic for replacing string, when ever the direct usage of the secret
> variables is not possible. The ssh key is then written in a first step with
> something like
>
> echo "$SECRET_PRIVATE_SSH" > ~/.ssh/id_ecdsa && chmod 600 ~/.ssh/id_ecdsa
>
> gitlab will not print the secret variables in clear format.
>
> https://docs.gitlab.com/ee/ci/variables/#via-the-ui
>
> Whenever possible you should use a deploy token, best would be to add this
> as well as the above mentioned ui variables. With the protected feature you
> can even prevent non privileged developers from stealing this secrets.
>
>
> https://docs.gitlab.com/ee/user/project/deploy_tokens/#creating-a-deploy-token
>
>
> Am 17.06.19 um 20:00 schrieb Rudolf Streif:
>
> That's more of a Gitlab than Yocto question. I am doing this all the time
> with my GL server on AWS. You need to add deploy a key to the repo you want
> to access and then push the key to your Docker instance from gitlab-ci.yaml
> from the repo that you are using with GL CI.
>
> :rjs
>
> On Mon, Jun 17, 2019, 07:20 Gabriele Zampieri <gabbla.malist at gmail.com>
> wrote:
>
>> Hi all,
>>
>> does anyone have a guide on how to setup Yocto to run inside docker?
>> Right now I managed to trigger the build from GitLab, but I'm facing an
>> issue related to ssh keys (some recipes from my meta layer are hosted on a
>> privare repository). Probably this is not the best mailing list to ask this
>> kind of question, but it may worth a try.
>>
>> Thank you,
>> Gabriele
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190624/c30fffd4/attachment.html>

From morne at linux.com  Mon Jun 24 00:08:10 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Mon, 24 Jun 2019 09:08:10 +0200
Subject: [yocto] General Question: Device specific value store
In-Reply-To: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
References: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
Message-ID: <20190624070810.GD1584@archworkstation>

On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
>Is there a smart, recommended way to deal with device specific data (i.e.  
>serial number, credentials for backend access, you name it), that is specific 
>for *one* device, and hence does not belong into the rootfs. I know, that there 
>are (safe) hardware stores for it, but what, if your device does not have one.

Not sure if I'm misunderstanding your question, but this should be part of your 
device commissioning process, i.e. like injecting specific security keys 
etc...so basically this will part of your image install / flash process, and not 
really part of the Yocto build process. The specifics of such a process would 
depend on your specific commissioning process.

		- Morn?

From jupiter.hce at gmail.com  Mon Jun 24 01:43:19 2019
From: jupiter.hce at gmail.com (JH)
Date: Mon, 24 Jun 2019 18:43:19 +1000
Subject: [yocto] Failed Linux network getnameinfo
Message-ID: <CAA=hcWSBOS6bpctp_wbs+ENHnnYxAviUEDvXjCSBJMamyRF9pg@mail.gmail.com>

Hi,

I can run following code in Ubuntu to print out the host address, but
I could not get host address (empty) in Yoctor imx6 build. That
function is POSIX compatible, what I could be missing?

struct sockaddr *addr;     /* input */
socklen_t addrlen;         /* input */
char hbuf[NI_MAXHOST];

if (getnameinfo(addr, addrlen, hbuf, sizeof(hbuf), NULL, 0, NI_NAMEREQD))
      printf("could not resolve hostname");
else
      printf("host=%s\n", hbuf);

Thank you.

Kind regards,

- jupiter

From f.forstmayr at gmail.com  Mon Jun 24 05:27:05 2019
From: f.forstmayr at gmail.com (Franz Forstmayr)
Date: Mon, 24 Jun 2019 14:27:05 +0200
Subject: [yocto] Using AUTOREV in PV triggers FetchError
Message-ID: <CAGKTrWKHrkNbKLhF22XEjQ+-a9ygjJGdiSB=DaVPJgJr0xRbRg@mail.gmail.com>

Hi,

i was using some simple recipes for kernel modules since rocko branch
successfully with AUTOREV and a release branch in my local gitlab
instance (over ssh). I was upgrading to thud these days, and now I'm
triggering some FetchErrors in recipes which are using AUTOREV.
My recipe looks like this:

inherit module

SRC_URI = "git://gitlab at gitlab.....:protocol=ssh"

SRCREV = "${AUTOREV}"
PV = "1.0+git${SRCPV}"

S = "${WORKDIR}/git"

Is there something wrong with this?
Is there a better way than getting the last revision of my release branch?
Sometimes I get this error:

> WARNING: .../recipes-kernel/dma-proxy/dma-proxy_git.bb: Exception during build_dependencies for WORKDIR           | ETA:  --:--:--
> WARNING: .../recipes-kernel/dma-proxy/dma-proxy_git.bb: Error during finalise of .../recipes-kernel/dma-proxy/dma-proxy_git.bb
> ERROR: ExpansionError during parsing .../recipes-kernel/dma-proxy/dma-proxy_git.bb                                 | ETA:  0:00:43
> Traceback (most recent call last):
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export PATH="/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/layers/openembedded-core/scripts:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/usr/bin/aarch64-poky-linux:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot/usr/bin/crossscripts:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/usr/sbin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/usr/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/sbin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/work/ro_zcu111_usbm2-poky-linux/dma-proxy/fetcheravoidrecurse-fetcheravoidrecurse/recipe-sysroot-native/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/microblaze/lin/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/aarch32/lin/gcc-arm-none-eabi/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/armr5/lin/gcc-arm-none-eabi/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/sysroots-xsct/Scout/2019.1/gnu/aarch64/lin/aarch64-none/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/layers/poky/bitbake/bin:/home/ecs/Workspaces/yocto/projects/basic_zcu111/tmp/hosttools"; export HOME="/home/ecs"; git -c core.fsyncobjectfiles=0 ls-remote ssh://gitlab at blabla/Research_and_Development/RD_ECS/Drivers/dma-proxy.git  failed with exit code 128, output:
> ssh_exchange_identification: Connection closed by remote host
> fatal: Could not read from remote repository.

> Please make sure you have the correct access rights
> and the repository exists.

> Summary: There were 2 WARNING messages shown.
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.



Regards Franz

From mauro at faresoftware.it  Mon Jun 24 10:29:46 2019
From: mauro at faresoftware.it (Mauro Ziliani)
Date: Mon, 24 Jun 2019 19:29:46 +0200
Subject: [yocto] Remove include /usr/include/SDL2
Message-ID: <a0336aa1-3a09-3b10-8c0b-d0233933f14d@faresoftware.it>

Hi all.

I'm trying to compile kivy inside yocto for a 586 board.

The compilation fails because the i586-cc uses /usr/include and 
/usr/local/include paths as INCLUDEDIR (togheter with others paths)


How can avoid this?


I need /usr/include o /usr/local/include for other apps, but I don't 
like the /usr/include is involved in yocto


MZ


From ross.burton at intel.com  Mon Jun 24 10:40:42 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Mon, 24 Jun 2019 18:40:42 +0100
Subject: [yocto] Remove include /usr/include/SDL2
In-Reply-To: <a0336aa1-3a09-3b10-8c0b-d0233933f14d@faresoftware.it>
References: <a0336aa1-3a09-3b10-8c0b-d0233933f14d@faresoftware.it>
Message-ID: <CAJTo0Lba0Osk-q=WU1TwiWCMC4rEZ6wut2xnPgbpwiWCiVdxvg@mail.gmail.com>

The problem is that kivy is ignoring all of the attempts at telling it
to build in a sysroot and *still* looking in /usr.  This is a clear
cut bug in the kivy build system, so you'll have to look at that and
see how to fix it.

Ross

On Mon, 24 Jun 2019 at 18:32, Mauro Ziliani <mauro at faresoftware.it> wrote:
>
> Hi all.
>
> I'm trying to compile kivy inside yocto for a 586 board.
>
> The compilation fails because the i586-cc uses /usr/include and
> /usr/local/include paths as INCLUDEDIR (togheter with others paths)
>
>
> How can avoid this?
>
>
> I need /usr/include o /usr/local/include for other apps, but I don't
> like the /usr/include is involved in yocto
>
>
> MZ
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From pierrelucbuhler at gmail.com  Mon Jun 24 11:06:45 2019
From: pierrelucbuhler at gmail.com (pierrelucbuhler at gmail.com)
Date: Mon, 24 Jun 2019 18:06:45 +0000
Subject: [yocto] =?utf-8?q?Are_native_packages_dependencies_listed_in_lice?=
	=?utf-8?q?nse=2Emanifest=3F?=
Message-ID: <5d111b11.1c69fb81.bbbda.d4fc@mx.google.com>

Hi,

I?m currently working to remove all GPLv3 packages included in my image.

I was using the license manifest file to list the remaining GPLv3 packages to remove.

While I was trying to remove gdbm, I ecountered some native dependencies.

When I looked at the license.manifest file, gdbm was still listed.

So I was asking myself if I still had packages that depends/includes gdbm hidden somewhere or it?s because the license.manifest also list packages used on the build host even if they are not included in the image.

For example, if curl-native is used in a recipe will curl be listed in license.manifest even if curl is not in the image?




So in other words, does license.manifest also includes native packages or it only lists the packages that make up the image (included in the image)?




Thanks for the support,




PLB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190624/23fa0304/attachment.html>

From sjolley.yp.pm at gmail.com  Mon Jun 24 12:16:19 2019
From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com)
Date: Mon, 24 Jun 2019 12:16:19 -0700
Subject: [yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed
Message-ID: <014001d52ac1$4e6208c0$eb261a40$@gmail.com>

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

 

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

 

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 at gmail.com
<mailto:sjolley.yp.pm at gmail.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_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm at gmail.com
<mailto:sjolley.yp.pm at gmail.com> 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190624/28db22da/attachment.html>

From ross.burton at intel.com  Mon Jun 24 14:48:54 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Mon, 24 Jun 2019 22:48:54 +0100
Subject: [yocto] Are native packages dependencies listed in
	license.manifest?
In-Reply-To: <5d111b11.1c69fb81.bbbda.d4fc@mx.google.com>
References: <5d111b11.1c69fb81.bbbda.d4fc@mx.google.com>
Message-ID: <CAJTo0LYm6Zgh3OD2t1ZXHny+cEcTCNO2ujD1S1w6VRv8bpdnOw@mail.gmail.com>

The image manifest lists what is being *distributed* so doesn't
include native dependencies.

Ross

On Mon, 24 Jun 2019 at 19:50, <pierrelucbuhler at gmail.com> wrote:
>
> Hi,
> I?m currently working to remove all GPLv3 packages included in my image.
> I was using the license manifest file to list the remaining GPLv3 packages to remove.
> While I was trying to remove gdbm, I ecountered some native dependencies.
> When I looked at the license.manifest file, gdbm was still listed.
> So I was asking myself if I still had packages that depends/includes gdbm hidden somewhere or it?s because the license.manifest also list packages used on the build host even if they are not included in the image.
> For example, if curl-native is used in a recipe will curl be listed in license.manifest even if curl is not in the image?
>
> So in other words, does license.manifest also includes native packages or it only lists the packages that make up the image (included in the image)?
>
> Thanks for the support,
>
> PLB
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From keith.derrick at lge.com  Mon Jun 24 19:26:27 2019
From: keith.derrick at lge.com (keith.derrick)
Date: Tue, 25 Jun 2019 02:26:27 +0000
Subject: [yocto] Dealing with line endings
Message-ID: <1561429587556.6733@lge.com>

I am using an upstream repo with a mix of line endings.


In my recipe, I'm applying a patch with normalized line endings, as our meta layer repo has a .gitattributes with "text=auto" set.


The patch is failing due to "different line endings".


Can the git fetcher be configured to normalize line endings on unpack? I tried setting core.autocrlf in my global .gitconfig, but the fetcher/unpacker seems to ignore it.


Thanks

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/e593869f/attachment.html>

From robert.joslyn at redrectangle.org  Mon Jun 24 22:28:26 2019
From: robert.joslyn at redrectangle.org (Robert Joslyn)
Date: Mon, 24 Jun 2019 22:28:26 -0700
Subject: [yocto] OPKG Spec
In-Reply-To: <CAM483UybQzjLoxaa6M25stxwf7xWXa-xW9Q6WxHz=PjwimaT3A@mail.gmail.com>
References: <CAM483UybQzjLoxaa6M25stxwf7xWXa-xW9Q6WxHz=PjwimaT3A@mail.gmail.com>
Message-ID: <c77b5c42da8261128f45af9a8461ce9f09eb2921.camel@redrectangle.org>

On Sun, 2019-06-23 at 16:15 +0300, Adi Malca wrote:
> Hello,
> 
> I'm looking for the current official OPKG spec with spelling and case
> sensitive.
> For example:
> Package: 
> Version: 
> Description: 
> Section: 
> Priority: 
> Maintainer: 
> License: 
> Architecture: 
> OE: 
> Homepage:
> Depends: 
> Source: 
> Filename: 
> SHA1:
> SHA256:
> 
> Best Regards,
> Adi

I'm not sure if there is an official spec somewhere, but the structure
of the packages and server index files can be seen in the code. The
main opkg utility is here: 
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/

The helper scripts are also useful: 
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/

You can see the structure of the metadata you mention, including
spelling, capitalization, etc, here:
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/pkg.c#n552

You can also see it here (perhaps more concisely):
http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg.py#n491

The Packages and Packages.gz index files use these variables. For
example, this is what shows up in the index for busybox on one of my
builds:

Package: busybox
Version: 1.30.1-r0
Depends: libc6 (>= 2.29), update-alternatives-opkg
Recommends: busybox-udhcpc
Section: base
Architecture: armv7vet2hf-neon
Maintainer: Poky <poky at yoctoproject.org>
MD5Sum: c0b45a09adec305b49153133a3392917
Size: 315406
Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
Source: busybox_1.30.1.bb
Description: Tiny versions of many common UNIX utilities in a single
small executable
OE: busybox
HomePage: http://www.busybox.net
License: GPLv2 & bzip2
Priority: optional

Packages can also use SHA256 rather than MD5.

Package: busybox
Version: 1.30.1-r0
Depends: libc6 (>= 2.29), update-alternatives-opkg
Recommends: busybox-udhcpc
Section: base
Architecture: armv7vet2hf-neon
Maintainer: Poky <poky at yoctoproject.org>
SHA256sum:
3ca8d2dd79759fa34bf04a0ee97fef5e354d97da76b03672544f3c4eeef76ac9
Size: 315406
Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
Source: busybox_1.30.1.bb
Description: Tiny versions of many common UNIX utilities in a single
small executable
OE: busybox
HomePage: http://www.busybox.net
License: GPLv2 & bzip2
Priority: optional

I'm not sure if anyone has any package feeds built by Yocto publicly
available, but OpenWRT uses opkg as well, with public feeds available.
For example:
https://downloads.openwrt.org/releases/18.06.2/packages/aarch64_cortex-a53/base/


Robert


From adim at jfrog.com  Tue Jun 25 00:19:54 2019
From: adim at jfrog.com (Adi Malca)
Date: Tue, 25 Jun 2019 10:19:54 +0300
Subject: [yocto] OPKG Spec
In-Reply-To: <c77b5c42da8261128f45af9a8461ce9f09eb2921.camel@redrectangle.org>
References: <CAM483UybQzjLoxaa6M25stxwf7xWXa-xW9Q6WxHz=PjwimaT3A@mail.gmail.com>
	<c77b5c42da8261128f45af9a8461ce9f09eb2921.camel@redrectangle.org>
Message-ID: <CAM483UypTWk6J2A-=jO8g95-cM=fvD8_pnFKHU-PV=5s3t37Hg@mail.gmail.com>

Thank you Robert, the last 2 links to the code were very helpful.

On Tue, Jun 25, 2019 at 8:28 AM Robert Joslyn <
robert.joslyn at redrectangle.org> wrote:

> On Sun, 2019-06-23 at 16:15 +0300, Adi Malca wrote:
> > Hello,
> >
> > I'm looking for the current official OPKG spec with spelling and case
> > sensitive.
> > For example:
> > Package:
> > Version:
> > Description:
> > Section:
> > Priority:
> > Maintainer:
> > License:
> > Architecture:
> > OE:
> > Homepage:
> > Depends:
> > Source:
> > Filename:
> > SHA1:
> > SHA256:
> >
> > Best Regards,
> > Adi
>
> I'm not sure if there is an official spec somewhere, but the structure
> of the packages and server index files can be seen in the code. The
> main opkg utility is here:
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg/
>
> The helper scripts are also useful:
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/
>
> You can see the structure of the metadata you mention, including
> spelling, capitalization, etc, here:
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg/tree/libopkg/pkg.c#n552
>
> You can also see it here (perhaps more concisely):
> http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/tree/opkg.py#n491
>
> The Packages and Packages.gz index files use these variables. For
> example, this is what shows up in the index for busybox on one of my
> builds:
>
> Package: busybox
> Version: 1.30.1-r0
> Depends: libc6 (>= 2.29), update-alternatives-opkg
> Recommends: busybox-udhcpc
> Section: base
> Architecture: armv7vet2hf-neon
> Maintainer: Poky <poky at yoctoproject.org>
> MD5Sum: c0b45a09adec305b49153133a3392917
> Size: 315406
> Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
> Source: busybox_1.30.1.bb
> Description: Tiny versions of many common UNIX utilities in a single
> small executable
> OE: busybox
> HomePage: http://www.busybox.net
> License: GPLv2 & bzip2
> Priority: optional
>
> Packages can also use SHA256 rather than MD5.
>
> Package: busybox
> Version: 1.30.1-r0
> Depends: libc6 (>= 2.29), update-alternatives-opkg
> Recommends: busybox-udhcpc
> Section: base
> Architecture: armv7vet2hf-neon
> Maintainer: Poky <poky at yoctoproject.org>
> SHA256sum:
> 3ca8d2dd79759fa34bf04a0ee97fef5e354d97da76b03672544f3c4eeef76ac9
> Size: 315406
> Filename: busybox_1.30.1-r0_armv7vet2hf-neon.ipk
> Source: busybox_1.30.1.bb
> Description: Tiny versions of many common UNIX utilities in a single
> small executable
> OE: busybox
> HomePage: http://www.busybox.net
> License: GPLv2 & bzip2
> Priority: optional
>
> I'm not sure if anyone has any package feeds built by Yocto publicly
> available, but OpenWRT uses opkg as well, with public feeds available.
> For example:
>
> https://downloads.openwrt.org/releases/18.06.2/packages/aarch64_cortex-a53/base/
>
>
> Robert
>
>

-- 
 <https://support.jfrog.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/0376e5e6/attachment.html>

From martin.jansa at gmail.com  Tue Jun 25 00:30:04 2019
From: martin.jansa at gmail.com (Martin Jansa)
Date: Tue, 25 Jun 2019 09:30:04 +0200
Subject: [yocto] Dealing with line endings
In-Reply-To: <1561429587556.6733@lge.com>
References: <1561429587556.6733@lge.com>
Message-ID: <CA+chaQf7VB36-ihmnx+ARiJ7VC4rQcuBSHgmwj33ytr_fauERw@mail.gmail.com>

Hi Keith,

you can use dos2unix.bbclass:
http://git.openembedded.org/openembedded-core/tree/meta/classes/dos2unix.bbclass
to convert them before do_patch.

Cheers,

On Tue, Jun 25, 2019 at 4:57 AM keith.derrick <keith.derrick at lge.com> wrote:

> I am using an upstream repo with a mix of line endings.
>
>
> In my recipe, I'm applying a patch with normalized line endings, as our
> meta layer repo has a .gitattributes with "text=auto" set.
>
>
> The patch is failing due to "different line endings".
>
>
> Can the git fetcher be configured to normalize line endings on unpack? I
> tried setting core.autocrlf in my global .gitconfig, but the
> fetcher/unpacker seems to ignore it.
>
>
> Thanks
>
> Keith
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/8fdc47ef/attachment.html>

From matthias.schoepfer at googlemail.com  Tue Jun 25 01:52:59 2019
From: matthias.schoepfer at googlemail.com (Matthias Schoepfer)
Date: Tue, 25 Jun 2019 10:52:59 +0200
Subject: [yocto] General Question: Device specific value store
In-Reply-To: <20190624070810.GD1584@archworkstation>
References: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
	<20190624070810.GD1584@archworkstation>
Message-ID: <43163f9c-29e2-6069-bd13-ff65f82d55bd@googlemail.com>

Hi Morn?,

thanks for you answer. Maybe, I will explain more: we have a Dragonboard 
410c based hardware. We use a read-only rootfs in one partition 
(actually two with A/B approach) and we have a data partition for user 
data as well as device specific data. We can partition and flash the 
device through fastboot. So, if we can prepare ext4 filesystems (maybe 
through yocto instead of hand-crafted scripting) for each device, 
commissioning will be an easy task for the manufacturer.

I guess, we are not the only ones that need to store device specific 
information besides the rootfs, and I do not find a whole lot about it 
in the yocto manuals. I wonder, if there are best practices, how to 
protect the data from getting corrupted (intentionally by an attacker or 
by accident through ... flash corruption or whatever).

Regards,

 ?? Matthias

On 6/24/19 9:08 AM, Morn? Lamprecht wrote:
> On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
>> Is there a smart, recommended way to deal with device specific data 
>> (i.e.? serial number, credentials for backend access, you name it), 
>> that is specific for *one* device, and hence does not belong into the 
>> rootfs. I know, that there are (safe) hardware stores for it, but 
>> what, if your device does not have one.
>
> Not sure if I'm misunderstanding your question, but this should be 
> part of your device commissioning process, i.e. like injecting 
> specific security keys etc...so basically this will part of your image 
> install / flash process, and not really part of the Yocto build 
> process. The specifics of such a process would depend on your specific 
> commissioning process.
>
> ??????? - Morn?

From zhe.he at windriver.com  Tue Jun 25 02:43:40 2019
From: zhe.he at windriver.com (zhe.he at windriver.com)
Date: Tue, 25 Jun 2019 17:43:40 +0800
Subject: [yocto] [meta-dpdk][PATCH] dpdk: Remove 18.05
Message-ID: <1561455820-9421-1-git-send-email-zhe.he@windriver.com>

From: He Zhe <zhe.he at windriver.com>

We have already had 18.11 and 18.05 is not a stable version.

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 recipes-extended/dpdk/dpdk_18.05.bb | 15 ---------------
 1 file changed, 15 deletions(-)
 delete mode 100644 recipes-extended/dpdk/dpdk_18.05.bb

diff --git a/recipes-extended/dpdk/dpdk_18.05.bb b/recipes-extended/dpdk/dpdk_18.05.bb
deleted file mode 100644
index b6897a8..0000000
--- a/recipes-extended/dpdk/dpdk_18.05.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-include dpdk.inc
-
-SRCREV = "a5dce55556286cc56655320d975c67b0dbe08693"
-
-LICENSE = "BSD-3-Clause & LGPLv2.1 & GPLv2"
-LIC_FILES_CHKSUM = "file://license/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-                    file://license/lgpl-2.1.txt;md5=4b54a1fd55a448865a0b32d41598759d \
-                    file://license/bsd-3-clause.txt;md5=0f00d99239d922ffd13cabef83b33444"
-
-SRC_URI += "\
-            file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch \
-            file://dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch \
-            file://dpdk-16.04-dpdk-enable-ip_fragmentation-in-common_base-config.patch \
-            file://0001-examples-Fix-maybe-uninitialized-warning.patch \
-            "
-- 
2.7.4


From gabbla.malist at gmail.com  Tue Jun 25 03:08:24 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Tue, 25 Jun 2019 12:08:24 +0200
Subject: [yocto] General Question: Device specific value store
In-Reply-To: <43163f9c-29e2-6069-bd13-ff65f82d55bd@googlemail.com>
References: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
	<20190624070810.GD1584@archworkstation>
	<43163f9c-29e2-6069-bd13-ff65f82d55bd@googlemail.com>
Message-ID: <CAAx3WaA+OemjNchvCFd_3m3K5LE4OedqFVtwdPAjYNwUSWv28Q@mail.gmail.com>

Hi Matthias,

an easier solution may be write those data during production. I don't think
that having a custom partition for each device is a good idea. You could
start the device in "production mode" and inject into the device specific
data through serial or USB. Obviously you must have some piece of software
running on the device that can read/write that partition.

In my opinion Yocto does not mention anything about this procedure probably
because this is not the standard way.

Gabriele

Il giorno mar 25 giu 2019 alle ore 10:53 Matthias Schoepfer <
matthias.schoepfer at googlemail.com> ha scritto:

> Hi Morn?,
>
> thanks for you answer. Maybe, I will explain more: we have a Dragonboard
> 410c based hardware. We use a read-only rootfs in one partition
> (actually two with A/B approach) and we have a data partition for user
> data as well as device specific data. We can partition and flash the
> device through fastboot. So, if we can prepare ext4 filesystems (maybe
> through yocto instead of hand-crafted scripting) for each device,
> commissioning will be an easy task for the manufacturer.
>
> I guess, we are not the only ones that need to store device specific
> information besides the rootfs, and I do not find a whole lot about it
> in the yocto manuals. I wonder, if there are best practices, how to
> protect the data from getting corrupted (intentionally by an attacker or
> by accident through ... flash corruption or whatever).
>
> Regards,
>
>     Matthias
>
> On 6/24/19 9:08 AM, Morn? Lamprecht wrote:
> > On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
> >> Is there a smart, recommended way to deal with device specific data
> >> (i.e.  serial number, credentials for backend access, you name it),
> >> that is specific for *one* device, and hence does not belong into the
> >> rootfs. I know, that there are (safe) hardware stores for it, but
> >> what, if your device does not have one.
> >
> > Not sure if I'm misunderstanding your question, but this should be
> > part of your device commissioning process, i.e. like injecting
> > specific security keys etc...so basically this will part of your image
> > install / flash process, and not really part of the Yocto build
> > process. The specifics of such a process would depend on your specific
> > commissioning process.
> >
> >         - Morn?
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/faf475ab/attachment-0001.html>

From mauro at faresoftware.it  Tue Jun 25 03:10:47 2019
From: mauro at faresoftware.it (Mauro Ziliani)
Date: Tue, 25 Jun 2019 12:10:47 +0200
Subject: [yocto] Remove include /usr/include/SDL2
In-Reply-To: <CAJTo0Lba0Osk-q=WU1TwiWCMC4rEZ6wut2xnPgbpwiWCiVdxvg@mail.gmail.com>
References: <a0336aa1-3a09-3b10-8c0b-d0233933f14d@faresoftware.it>
	<CAJTo0Lba0Osk-q=WU1TwiWCMC4rEZ6wut2xnPgbpwiWCiVdxvg@mail.gmail.com>
Message-ID: <ad7d1fe6-19ef-2b56-2f5b-5f6393fe4b80@faresoftware.it>

Thank for the answer.

I'll look for that.

MZ

Il 24/06/19 19:40, Burton, Ross ha scritto:
> The problem is that kivy is ignoring all of the attempts at telling it
> to build in a sysroot and *still* looking in /usr.  This is a clear
> cut bug in the kivy build system, so you'll have to look at that and
> see how to fix it.
>
> Ross
>
> On Mon, 24 Jun 2019 at 18:32, Mauro Ziliani <mauro at faresoftware.it> wrote:
>> Hi all.
>>
>> I'm trying to compile kivy inside yocto for a 586 board.
>>
>> The compilation fails because the i586-cc uses /usr/include and
>> /usr/local/include paths as INCLUDEDIR (togheter with others paths)
>>
>>
>> How can avoid this?
>>
>>
>> I need /usr/include o /usr/local/include for other apps, but I don't
>> like the /usr/include is involved in yocto
>>
>>
>> MZ
>>
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto

From Vignesh.Rajendran at in.bosch.com  Tue Jun 25 03:06:43 2019
From: Vignesh.Rajendran at in.bosch.com (Vignesh Rajendran (RBEI/ECF3))
Date: Tue, 25 Jun 2019 10:06:43 +0000
Subject: [yocto]  build on CVE is failing
Message-ID: <22839e9497e34df9b93272590fcc483d@in.bosch.com>

Hi,

I was trying to check the CVE feature on Yocto.

I couldn't succeed the build with CVE.
https://pastebin.com/m7hNcNcm

There seems like proxy environment doesn't recognized inside do_populate_cve_db.

ERROR: cve-update-db-1.0-r0 do_populate_cve_db: HTTPSConnectionPool(host='nvd.nist.gov', port=443):
Max retries exceeded with url: /feeds/json/cve/1.0/nvdcve-1.0-2002.meta (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f787f1a8908>: Failed to establish a new connection: [Errno -2] Name or service not known',))

I am using HEAD of poky master branch.

Best regards,

Rajendran Vignesh
RBEI/ECF3

Tel. +91 422 676-5103 | Threema Work<threemawork://add/?id=+914226765103>: +914226765103

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/fe3abd81/attachment.html>

From elcapitanbrown at gmail.com  Tue Jun 25 06:25:13 2019
From: elcapitanbrown at gmail.com (Larry Brown)
Date: Tue, 25 Jun 2019 09:25:13 -0400
Subject: [yocto] General Question: Device specific value store
In-Reply-To: <CAAx3WaA+OemjNchvCFd_3m3K5LE4OedqFVtwdPAjYNwUSWv28Q@mail.gmail.com>
References: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
	<20190624070810.GD1584@archworkstation>
	<43163f9c-29e2-6069-bd13-ff65f82d55bd@googlemail.com>
	<CAAx3WaA+OemjNchvCFd_3m3K5LE4OedqFVtwdPAjYNwUSWv28Q@mail.gmail.com>
Message-ID: <CAOmL4Ujwqu1pVe5zEGntJjYTNgw7__LPi_mdgn7-xU93dwF62A@mail.gmail.com>

You could either partition the flash with intentional space left at the end
of the disk and write/read directly to the flash at the specified location
or you could put it at the end of the uboot space.  There is a chunk of
unused space at the end of the uboot image that is not used IIRC that
should give enough for a serial and key.  You'd have to test to find out
for sure.  You could cat the uboot image to hexdump to see how much space
is left empty.  The idea of a space at the end of the flash is probably
better as reformatting or re-partitioning with this space left alone should
retain your values.

If anyone has issues with these suggestions feel free to correct me but it
seems pretty safe to me since you have control over how you partition your
device and this data will be pretty static.


On Tue, Jun 25, 2019 at 6:09 AM Gabriele Zampieri <gabbla.malist at gmail.com>
wrote:

> Hi Matthias,
>
> an easier solution may be write those data during production. I don't
> think that having a custom partition for each device is a good idea. You
> could start the device in "production mode" and inject into the device
> specific data through serial or USB. Obviously you must have some piece of
> software running on the device that can read/write that partition.
>
> In my opinion Yocto does not mention anything about this procedure
> probably because this is not the standard way.
>
> Gabriele
>
> Il giorno mar 25 giu 2019 alle ore 10:53 Matthias Schoepfer <
> matthias.schoepfer at googlemail.com> ha scritto:
>
>> Hi Morn?,
>>
>> thanks for you answer. Maybe, I will explain more: we have a Dragonboard
>> 410c based hardware. We use a read-only rootfs in one partition
>> (actually two with A/B approach) and we have a data partition for user
>> data as well as device specific data. We can partition and flash the
>> device through fastboot. So, if we can prepare ext4 filesystems (maybe
>> through yocto instead of hand-crafted scripting) for each device,
>> commissioning will be an easy task for the manufacturer.
>>
>> I guess, we are not the only ones that need to store device specific
>> information besides the rootfs, and I do not find a whole lot about it
>> in the yocto manuals. I wonder, if there are best practices, how to
>> protect the data from getting corrupted (intentionally by an attacker or
>> by accident through ... flash corruption or whatever).
>>
>> Regards,
>>
>>     Matthias
>>
>> On 6/24/19 9:08 AM, Morn? Lamprecht wrote:
>> > On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote:
>> >> Is there a smart, recommended way to deal with device specific data
>> >> (i.e.  serial number, credentials for backend access, you name it),
>> >> that is specific for *one* device, and hence does not belong into the
>> >> rootfs. I know, that there are (safe) hardware stores for it, but
>> >> what, if your device does not have one.
>> >
>> > Not sure if I'm misunderstanding your question, but this should be
>> > part of your device commissioning process, i.e. like injecting
>> > specific security keys etc...so basically this will part of your image
>> > install / flash process, and not really part of the Yocto build
>> > process. The specifics of such a process would depend on your specific
>> > commissioning process.
>> >
>> >         - Morn?
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
Larry Brown
S/V Trident
Palm Harbor, FL
~~~~~~~~~~~~~~~~~_/)~~~~~~~~
    ~     ~          ~~           ~
~           ~~_/)    ~      ~ ~        ~
     ~                  _/)          ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/26d5109b/attachment.html>

From jeremy.singy at gmail.com  Tue Jun 25 06:59:56 2019
From: jeremy.singy at gmail.com (=?UTF-8?B?SsOpcsOpbXkgU2luZ3k=?=)
Date: Tue, 25 Jun 2019 15:59:56 +0200
Subject: [yocto] Can't build SDK while shrinking shadow tools
In-Reply-To: <CAMKF1spO50-WtUOinnWO9wSqohTUXjBng-z_mFVtf0mbwbRP_A@mail.gmail.com>
References: <CAA42Xj5nygLnFp_ojTP5J59czFuG7f82c6bc_SLax+4+Ot2QVg@mail.gmail.com>
	<CAA42Xj5pNmu1BSVAd2FMTJvwO1fSbtckDfp+EOP9ELikG_=POw@mail.gmail.com>
	<CAMKF1spO50-WtUOinnWO9wSqohTUXjBng-z_mFVtf0mbwbRP_A@mail.gmail.com>
Message-ID: <CAA42Xj4dm_QYKAQ+r-JfZ8k=_vj-N1H4WwLp131=MyMGQgcyvA@mail.gmail.com>

On Wed, Jun 19, 2019 at 10:03 PM Khem Raj <raj.khem at gmail.com> wrote:
>
> On Fri, Jun 14, 2019 at 2:16 AM J?r?my Singy <jeremy.singy at gmail.com> wrote:
>>
>> Hi,
>>
>> I'm facing a problem by trying to shrink the size of our root filesystem.
>> To avoid installing some unneeded tools such as adduser, groupadd,
>> nologin, etc. I just created as usual a shadow_%.bbappend in our layer
>> which removes the content using do_install_append:
>>
>>     # do not install alternatives
>>     ALTERNATIVE_${PN} = ""
>>     ALTERNATIVE_${PN}-base = ""
>
> This is most probably the reason for your issue
> You may want to remove the alternatives which you are deleting but not everything

In the meantime I could fix the problem. I had to remove the
alternative for nologin in the util-linux recipe as well (as hinted by
the error message, this was the offending recipe)

I just wrote a util-linux_%.bbappend to remove the alternatives for
nologin (which I don't need) and I could then build the SDK:

    ALTERNATIVE_${PN}_remove = "nologin"
    ALTERNATIVE_LINK_NAME[nologin] = ""
    do_install_append() {
      rm -f ${D}${base_sbindir}/nologin
    }

Thanks for your help,
Jeremy

From elcapitanbrown at gmail.com  Tue Jun 25 07:42:12 2019
From: elcapitanbrown at gmail.com (Larry Brown)
Date: Tue, 25 Jun 2019 10:42:12 -0400
Subject: [yocto] Cortex m7 imx rt1052
Message-ID: <CAOmL4Ug9JTVvhecmi43K13pc+BbXZxc6AEtrfjEfjTh2zSQK+g@mail.gmail.com>

Does anyone know if there is a base bsp for at least the development board
imx rt1052?

-- 
Larry Brown
S/V Trident
Palm Harbor, FL
~~~~~~~~~~~~~~~~~_/)~~~~~~~~
    ~     ~          ~~           ~
~           ~~_/)    ~      ~ ~        ~
     ~                  _/)          ~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/ec1e8f03/attachment.html>

From ross.burton at intel.com  Tue Jun 25 07:48:00 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Tue, 25 Jun 2019 15:48:00 +0100
Subject: [yocto] build on CVE is failing
In-Reply-To: <22839e9497e34df9b93272590fcc483d@in.bosch.com>
References: <22839e9497e34df9b93272590fcc483d@in.bosch.com>
Message-ID: <CAJTo0LaUTDZi-cKg4dfGDdfm+gNrVxwPRQpVO0chprNn9nTBMQ@mail.gmail.com>

Yes, you're right, this is a bug in the new functionality.

The usual variables are in the data store, so you can get them with
e.g. d.getVar("http_proxy"), as you can clearly replicate the failure
would you be able to attempt a patch?

Ross

On Tue, 25 Jun 2019 at 11:14, Vignesh Rajendran (RBEI/ECF3)
<Vignesh.Rajendran at in.bosch.com> wrote:
>
> Hi,
>
>
>
> I was trying to check the CVE feature on Yocto.
>
>
>
> I couldn?t succeed the build with CVE.
>
> https://pastebin.com/m7hNcNcm
>
>
>
> There seems like proxy environment doesn?t recognized inside do_populate_cve_db.
>
>
>
> ERROR: cve-update-db-1.0-r0 do_populate_cve_db: HTTPSConnectionPool(host='nvd.nist.gov', port=443):
>
> Max retries exceeded with url: /feeds/json/cve/1.0/nvdcve-1.0-2002.meta (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f787f1a8908>: Failed to establish a new connection: [Errno -2] Name or service not known',))
>
>
>
> I am using HEAD of poky master branch.
>
>
>
> Best regards,
>
> Rajendran Vignesh
> RBEI/ECF3
>
> Tel. +91 422 676-5103 | Threema Work: +914226765103
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From rudolf.streif at ibeeto.com  Tue Jun 25 08:15:14 2019
From: rudolf.streif at ibeeto.com (Rudolf J Streif)
Date: Tue, 25 Jun 2019 08:15:14 -0700
Subject: [yocto] Creating my own bsp
In-Reply-To: <CAOmL4UhzAiin-LzbTQjgFbnKw8KOS=7EbktWcByVsXacB1JhpA@mail.gmail.com>
References: <CAOmL4UhzAiin-LzbTQjgFbnKw8KOS=7EbktWcByVsXacB1JhpA@mail.gmail.com>
Message-ID: <2bcecb85-630c-0d43-2cbc-74f8f7aec3e4@ibeeto.com>

Larry,

You would want to be more specific with your question and eventually
post error messages you are encountering. It looks like you are hung up
at the machine configuration file. You may want to post that. As far as
BSP layers and machine configuration files are concerned, my advice is
to start with an existing configuration that is close to your actual
hardware.

:rjs

On 6/21/19 10:46 AM, Larry Brown wrote:
> I've come across references to "yocto-bsp" script that should help
> build a bsp.? I'm starting from scratch with an arm 7M and trying to
> use the raspberrypi bsp as a reference.? There is so much complexity
> I'm not sure where to start.
>
> After setting up the files for the Linux kernel I'm using already on
> the board and the config, it first complained about TUNE_ARCH not
> being present.? This is not present in the meta-raspberrypi content
> but based on something I came across this just wants arm.? Then it
> complains TUNE_PKGARCH is not set.? I don't know what this is looking
> for and I'm not getting effective hits searching for it.? I'm guessing
> there are going to be a lot more after these two complaints.? It would
> be nice to read what went into a simple bsp that worked under for an
> arm board.
>
> PS I'm using the warrior release as it worked for bringing up the
> raspberry pi.
>
> Any help would be greatly appreciated.?
>
> -- 
> Larry Brown
>
>
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3396 x700

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/e83e72bb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/e83e72bb/attachment.pgp>

From mauro at faresoftware.it  Tue Jun 25 08:39:39 2019
From: mauro at faresoftware.it (Mauro Ziliani)
Date: Tue, 25 Jun 2019 17:39:39 +0200
Subject: [yocto] do_image_*[depends]: how this works?
Message-ID: <5ef67315-a366-0fb7-34e4-2cadc92a0ff5@faresoftware.it>

Hi all.

I don't understand how to use the do_image_wic[] istructions.

Where I can find info about?


I need to customize a syslinux.cfg configuration file, but with 
syslinux_%.bbappend I fail.

I look inside many image recipe the row

do_image_wic[depends] := ....


But I don't understand the mean


MZ


From alexander.l.elliott at navy.mil  Tue Jun 25 09:44:36 2019
From: alexander.l.elliott at navy.mil (Elliott, Alexander L CIV USN NAVSURFWARCEN DAH VA (USA))
Date: Tue, 25 Jun 2019 16:44:36 +0000
Subject: [yocto] yocto recipe error
Message-ID: <189257CBB431F1479EBC576E65F28F0C17FF257C@NAEANRFKXM02V.nadsusea.nads.navy.mil>

Hello,

I am very new to Yocto and having some trouble building a recipe. I am trying to add a pre-built application to my Petalinux project.

Here is my recipe:
SUMMARY = "Simple evtest application"
SECTION = "PEALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302

SRC_URI = "file://evtest"file://evtest"

S = "${WORKDIR}"

RDEPENDS_${PN} = "libgcc_s.so.1"

do_install() {
install -d ${D}/${bindir}
install -m 0755 ${S}/evtest ${D}/${bindir}
}

I added the RDEPENDS_${PN} = "libgcc_s.so.1" because I got an error that said it depended on it; however, I'm still getting the same error even after adding that line which says:
"ERROR: Nothing PROVIDES 'libgcc_s.so.1' (but /home/.../evtest.bb DEPENDS on or otherwise requires it)"
and also I get
"ERROR: Required build target 'petalinux-user-image' has no buildable providers. Missing or unbuildable dependency chain was : ['petalinux-user-image', 'evtest', 'libgcc_s.so.1']

Thanks for your time,

Alex



From sjolley.yp.pm at gmail.com  Tue Jun 25 10:22:41 2019
From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com)
Date: Tue, 25 Jun 2019 10:22:41 -0700
Subject: [yocto] Yocto Project Status WW26'19
Message-ID: <039e01d52b7a$990d2e40$cb278ac0$@gmail.com>

Current Dev Position: YP 2.8 M2

Next Deadline: YP 2.8 Milestone 2 Cutoff July 14th, 2019

 

SWAT Team Rotation:

*	SWAT lead is currently: Ross
*	SWAT team rotation: Ross -> Amanda on June 28, 2019
*	SWAT team rotation: Amanda -> Chen on July, 5, 2019
*	 <https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team>
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*	Bug Triage meeting Thursday June 27th at 7:30am PDT (
<https://zoom.us/j/454367603> https://zoom.us/j/454367603)
*	Monthly Project Meeting Tuesday July 2nd at 8am PDT (
<https://zoom.us/j/990892712> https://zoom.us/j/990892712) 
*	Twitch - Next event is Tuesday 9th July at 8am PDT (
<https://www.twitch.tv/yocto_project> https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*	2.8 M1 has been released.
*	Mailing lists issues are continuing to be worked on as a top
priority.
*	We have a new "newcomer" bug category which are bugs suited to
someone new to the project. These can be seen here:
<https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs>
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
*	Several key reproducibility fixes have merged, thanks Joshua!
*	The autobuilder has suffered stability issues with its NFS setup,
seemingly related to the increased load from the new servers. We're
monitoring changes, hoping they fix the issue.
*	We had significant problems with the versioning of libcrypt in
recent distros which resulted in the need for a new uninative release. This
fixes autobuilder builds.

 

Planned Releases for YP 2.8:

*	M2 Cutoff 14th July
*	M2 Release 26th July
*	M3 Cutoff (Feature Freeze) 25th Aug
*	M3 Release 6th Sept
*	M4 Cutoff 30th Sept
*	2.8 (M4) Final Release 25th Oct

 

Planned upcoming dot releases:

*	YP 2.7.1 (Warrior) is planned for build imminently now that 2.8 M1
is done but is pending the new uninative changes.
*	YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
before 2.8 M2

 

Tracking Metrics:

*	WDD 2482 (last week 2479) (
<https://wiki.yoctoproject.org/charts/combo.html>
https://wiki.yoctoproject.org/charts/combo.html)
*	Poky Patch Metrics  

*	Total patches found: 1509 (last week 1511)
*	Patches in the Pending State: 638 (42%) [last week 641 (43%)]

 

Key Status Links for YP:

 <https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status>
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

 <https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule>
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

 <https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features>
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features

 

The Status reports are now stored on the wiki at:
<https://wiki.yoctoproject.org/wiki/Weekly_Status>
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 Project Manager

*    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm at gmail.com
<mailto:sjolley.yp.pm at gmail.com> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/c7a4d214/attachment-0001.html>

From ross.burton at intel.com  Tue Jun 25 10:40:36 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Tue, 25 Jun 2019 18:40:36 +0100
Subject: [yocto] yocto recipe error
In-Reply-To: <189257CBB431F1479EBC576E65F28F0C17FF257C@NAEANRFKXM02V.nadsusea.nads.navy.mil>
References: <189257CBB431F1479EBC576E65F28F0C17FF257C@NAEANRFKXM02V.nadsusea.nads.navy.mil>
Message-ID: <CAJTo0LbzdppP_nsu2EEhsqNVm=gjcG7YoLA45OfyRrtnMiAzCA@mail.gmail.com>

On Tue, 25 Jun 2019 at 17:47, Elliott, Alexander L CIV USN
NAVSURFWARCEN DAH VA (USA) <alexander.l.elliott at navy.mil> wrote:
> RDEPENDS_${PN} = "libgcc_s.so.1"

You RDEPENDS on other package, not filenames.

RDEPENDS_${PN} = "libgcc"

Ross

From zoran.stojsavljevic at gmail.com  Tue Jun 25 10:51:12 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Tue, 25 Jun 2019 19:51:12 +0200
Subject: [yocto] yocto recipe error
In-Reply-To: <189257CBB431F1479EBC576E65F28F0C17FF257C@NAEANRFKXM02V.nadsusea.nads.navy.mil>
References: <189257CBB431F1479EBC576E65F28F0C17FF257C@NAEANRFKXM02V.nadsusea.nads.navy.mil>
Message-ID: <CAGAf8LxX4Ea-TqDhBT=7jOGmtC5knPoy3q9=6aNG_VZk94z5Mw@mail.gmail.com>

 > alexander.l.elliott at navy.mil

One honest advise. Please. use alexander.l.elliott at gmail.com... Much
healthier/relaxed, don't you agree? ;-)

Thank you,
Zoran
_______

On Tue, Jun 25, 2019 at 6:47 PM Elliott, Alexander L CIV USN
NAVSURFWARCEN DAH VA (USA) <alexander.l.elliott at navy.mil> wrote:
>
> Hello,
>
> I am very new to Yocto and having some trouble building a recipe. I am trying to add a pre-built application to my Petalinux project.
>
> Here is my recipe:
> SUMMARY = "Simple evtest application"
> SECTION = "PEALINUX/apps"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302
>
> SRC_URI = "file://evtest"file://evtest"
>
> S = "${WORKDIR}"
>
> RDEPENDS_${PN} = "libgcc_s.so.1"
>
> do_install() {
> install -d ${D}/${bindir}
> install -m 0755 ${S}/evtest ${D}/${bindir}
> }
>
> I added the RDEPENDS_${PN} = "libgcc_s.so.1" because I got an error that said it depended on it; however, I'm still getting the same error even after adding that line which says:
> "ERROR: Nothing PROVIDES 'libgcc_s.so.1' (but /home/.../evtest.bb DEPENDS on or otherwise requires it)"
> and also I get
> "ERROR: Required build target 'petalinux-user-image' has no buildable providers. Missing or unbuildable dependency chain was : ['petalinux-user-image', 'evtest', 'libgcc_s.so.1']
>
> Thanks for your time,
>
> Alex
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From akuster808 at gmail.com  Tue Jun 25 11:44:56 2019
From: akuster808 at gmail.com (akuster808)
Date: Tue, 25 Jun 2019 11:44:56 -0700
Subject: [yocto] Yocto Project Status WW26'19
In-Reply-To: <039e01d52b7a$990d2e40$cb278ac0$@gmail.com>
References: <039e01d52b7a$990d2e40$cb278ac0$@gmail.com>
Message-ID: <5183ac88-20de-9f18-2660-a32121cf92d8@gmail.com>



On 6/25/19 10:22 AM, sjolley.yp.pm at gmail.com wrote:
>
> Current Dev Position: YP 2.8 M2
>
> Next Deadline: YP 2.8 Milestone 2 Cutoff July 14th, 2019
>
> ?
>
> SWAT Team Rotation:
>
>   * SWAT lead is currently: Ross
>   * SWAT team rotation: Ross -> Amanda on June 28, 2019
>   * SWAT team rotation: Amanda -> Chen on July, 5, 2019
>
So how do we handle holiday coverage? July 4th is a US holiday.

- armin
>
>  *
>   * https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
> ?
>
> Next Team Meetings:
>
>   * Bug Triage meeting Thursday June 27th at 7:30am PDT
>     (https://zoom.us/j/454367603)
>   * Monthly Project Meeting Tuesday July 2nd at 8am PDT
>     (https://zoom.us/j/990892712) <https://zoom.us/j/990892712>?
>   * Twitch - Next event is Tuesday 9th July at 8am PDT
>     (https://www.twitch.tv/yocto_project)
>
> ?
>
> Key Status/Updates:
>
>   * 2.8 M1 has been released.
>   * Mailing lists issues are continuing to be worked on as a top priority.
>   * We have a new ?newcomer? bug category which are bugs suited to
>     someone new to the project. These can be seen here:
>     https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
>   * Several key reproducibility fixes have merged, thanks Joshua!
>   * The autobuilder has suffered stability issues with its NFS setup,
>     seemingly related to the increased load from the new servers.
>     We?re monitoring changes, hoping they fix the issue.
>   * We had significant problems with the versioning of libcrypt in
>     recent distros which resulted in the need for a new uninative
>     release. This fixes autobuilder builds.
>
> ?
>
> Planned Releases for YP 2.8:
>
>   * M2 Cutoff 14th July
>   * M2 Release 26th July
>   * M3 Cutoff (Feature Freeze) 25th Aug
>   * M3 Release 6th Sept
>   * M4 Cutoff 30th Sept
>   * 2.8 (M4) Final Release 25th Oct
>
> ?
>
> Planned upcoming dot releases:
>
>   * YP 2.7.1 (Warrior) is planned for build imminently now that 2.8 M1
>     is done but is pending the new uninative changes.
>   * YP 2.6.3 (Thud) is intended for build after 2.7.1 is complete and
>     before 2.8 M2
>
> ?
>
> Tracking Metrics:
>
>   * WDD 2482 (last week
>     2479)(https://wiki.yoctoproject.org/charts/combo.html)
>   * Poky Patch Metrics??
>       o Total patches found: 1509 (last week 1511)
>       o Patches in the Pending State: 638 (42%) [last week 641 (43%)]
>
> ?
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.8_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!]
>
> ?
>
> Thanks,
>
> ?
>
> */Stephen K. Jolley/**//*
>
> *Yocto Project Project Manager*
>
> (??? *Cell*:??????????????? (208) 244-4460
>
> * *Email*:??????????????_sjolley.yp.pm at gmail.com
> <mailto:sjolley.yp.pm at gmail.com>_
>
> ?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/76a392bf/attachment-0001.html>

From keith.derrick at lge.com  Tue Jun 25 17:15:17 2019
From: keith.derrick at lge.com (keith.derrick)
Date: Wed, 26 Jun 2019 00:15:17 +0000
Subject: [yocto] Dealing with line endings
In-Reply-To: <CA+chaQf7VB36-ihmnx+ARiJ7VC4rQcuBSHgmwj33ytr_fauERw@mail.gmail.com>
References: <1561429587556.6733@lge.com>,
	<CA+chaQf7VB36-ihmnx+ARiJ7VC4rQcuBSHgmwj33ytr_fauERw@mail.gmail.com>
Message-ID: <1561508118148.84601@lge.com>

Thanks Martin, that fixed it nicely.

________________________________
From: Martin Jansa <martin.jansa at gmail.com>
Sent: Tuesday, June 25, 2019 12:30 AM
To: Keith Derrick/LGEUS Advanced Platform(keith.derrick at lge.com)
Cc: yocto at yoctoproject.org
Subject: Re: [yocto] Dealing with line endings

Hi Keith,

you can use dos2unix.bbclass:
http://git.openembedded.org/openembedded-core/tree/meta/classes/dos2unix.bbclass
to convert them before do_patch.

Cheers,

On Tue, Jun 25, 2019 at 4:57 AM keith.derrick <keith.derrick at lge.com<mailto:keith.derrick at lge.com>> wrote:

I am using an upstream repo with a mix of line endings.


In my recipe, I'm applying a patch with normalized line endings, as our meta layer repo has a .gitattributes with "text=auto" set.


The patch is failing due to "different line endings".


Can the git fetcher be configured to normalize line endings on unpack? I tried setting core.autocrlf in my global .gitconfig, but the fetcher/unpacker seems to ignore it.


Thanks

Keith


--
_______________________________________________
yocto mailing list
yocto at yoctoproject.org<mailto:yocto at yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190626/a715c20c/attachment.html>

From yi.zhao at windriver.com  Tue Jun 25 18:00:13 2019
From: yi.zhao at windriver.com (Yi Zhao)
Date: Wed, 26 Jun 2019 09:00:13 +0800
Subject: [yocto] [meta-selinux][PATCH] audit: upgrade 2.8.4 -> 2.8.5
Message-ID: <1561510813-10520-1-git-send-email-yi.zhao@windriver.com>

* Drop backport patch:
  0001-Remove-strdupa-as-suggested-in-pull-request-25.patch

* Refresh all patches.

Signed-off-by: Yi Zhao <yi.zhao at windriver.com>
---
 ...e-strdupa-as-suggested-in-pull-request-25.patch | 47 ----------------------
 ...bstitue-functions-for-strndupa-rawmemchr.patch} | 23 +++++------
 .../audit/audit/audit-python-configure.patch       | 10 ++---
 recipes-security/audit/audit/audit-python.patch    |  8 ++--
 recipes-security/audit/audit/auditd                |  2 +-
 .../audit/audit/fix-swig-host-contamination.patch  | 22 +++++-----
 .../audit/{audit_2.8.4.bb => audit_2.8.5.bb}       |  7 ++--
 7 files changed, 35 insertions(+), 84 deletions(-)
 delete mode 100644 recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
 rename recipes-security/audit/audit/{0002-Add-substitue-functions-for-strndupa-rawmemchr.patch => Add-substitue-functions-for-strndupa-rawmemchr.patch} (88%)
 rename recipes-security/audit/{audit_2.8.4.bb => audit_2.8.5.bb} (92%)

diff --git a/recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch b/recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
deleted file mode 100644
index 38029aa..0000000
--- a/recipes-security/audit/audit/0001-Remove-strdupa-as-suggested-in-pull-request-25.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From a1782b58b687b74249dc8b2411a3f646b821ebd6 Mon Sep 17 00:00:00 2001
-From: Steve Grubb <sgrubb at redhat.com>
-Date: Thu, 4 Oct 2018 08:45:47 -0400
-Subject: [PATCH] Remove strdupa as suggested in pull request #25
-
----
- src/auditd.c | 11 ++++++-----
- 1 file changed, 6 insertions(+), 5 deletions(-)
-
-Origin: https://github.com/linux-audit/audit-userspace/commit/a1782b58b687b74249dc8b2411a3f646b821ebd6
-Applied-Upstream: yes
-
-diff --git a/src/auditd.c b/src/auditd.c
-index b0952db..c826ec0 100644
---- a/src/auditd.c
-+++ b/src/auditd.c
-@@ -209,21 +209,22 @@ static void cont_handler(struct ev_loop *loop, struct ev_signal *sig,
- 
- static int extract_type(const char *str)
- {
--	const char *tptr, *ptr2, *ptr = str;
-+	const char *ptr2, *ptr = str;
- 	if (*str == 'n') {
- 		ptr = strchr(str+1, ' ');
- 		if (ptr == NULL)
- 			return -1; // Malformed - bomb out
- 		ptr++;
- 	}
-+
- 	// ptr should be at 't'
- 	ptr2 = strchr(ptr, ' ');
--	// get type=xxx in a buffer
--	tptr = strndupa(ptr, ptr2 - ptr);
-+
- 	// find =
--	str = strchr(tptr, '=');
--	if (str == NULL)
-+	str = strchr(ptr, '=');
-+	if (str == NULL || str >= ptr2)
- 		return -1; // Malformed - bomb out
-+
- 	// name is 1 past
- 	str++;
- 	return audit_name_to_msg_type(str);
--- 
-2.20.1
-
diff --git a/recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch b/recipes-security/audit/audit/Add-substitue-functions-for-strndupa-rawmemchr.patch
similarity index 88%
rename from recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch
rename to recipes-security/audit/audit/Add-substitue-functions-for-strndupa-rawmemchr.patch
index c948aa3..bb6c61e 100644
--- a/recipes-security/audit/audit/0002-Add-substitue-functions-for-strndupa-rawmemchr.patch
+++ b/recipes-security/audit/audit/Add-substitue-functions-for-strndupa-rawmemchr.patch
@@ -1,12 +1,11 @@
-From 5346b6af0ca67a2965ca5846ae150f3021a2aa17 Mon Sep 17 00:00:00 2001
+From bdcdc3dff4469aac88e718bd15958d5ed4b9392a Mon Sep 17 00:00:00 2001
 From: Steve Grubb <sgrubb at redhat.com>
 Date: Tue, 26 Feb 2019 18:33:33 -0500
 Subject: [PATCH] Add substitue functions for strndupa & rawmemchr
 
+Upstream-Status: Backport
+[https://github.com/linux-audit/audit-userspace/commit/d579a08bb1cde71f939c13ac6b2261052ae9f77e]
 ---
-Origin: https://github.com/linux-audit/audit-userspace/commit/d579a08bb1cde71f939c13ac6b2261052ae9f77e
-Applied-Upstream: yes
-
  auparse/auparse.c   | 12 +++++++++++-
  auparse/interpret.c |  9 ++++++++-
  configure.ac        | 14 +++++++++++++-
@@ -14,7 +13,7 @@ Applied-Upstream: yes
  4 files changed, 43 insertions(+), 4 deletions(-)
 
 diff --git a/auparse/auparse.c b/auparse/auparse.c
-index f84712e..3764046 100644
+index 650db02..2e1c737 100644
 --- a/auparse/auparse.c
 +++ b/auparse/auparse.c
 @@ -1,5 +1,5 @@
@@ -24,7 +23,7 @@ index f84712e..3764046 100644
   * All Rights Reserved.
   *
   * This library is free software; you can redistribute it and/or
-@@ -1100,6 +1100,16 @@ static int str2event(char *s, au_event_t *e)
+@@ -1118,6 +1118,16 @@ static int str2event(char *s, au_event_t *e)
  	return 0;
  }
  
@@ -42,7 +41,7 @@ index f84712e..3764046 100644
  static int extract_timestamp(const char *b, au_event_t *e)
  {
 diff --git a/auparse/interpret.c b/auparse/interpret.c
-index 1846f9d..8540bd1 100644
+index 51c4a5e..67b7b77 100644
 --- a/auparse/interpret.c
 +++ b/auparse/interpret.c
 @@ -853,6 +853,13 @@ err_out:
@@ -69,7 +68,7 @@ index 1846f9d..8540bd1 100644
  				break;
  			*ptr = ' ';
 diff --git a/configure.ac b/configure.ac
-index ede7109..97b547f 100644
+index 54bdbf1..aef07fb 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1,7 +1,7 @@
@@ -101,7 +100,7 @@ index ede7109..97b547f 100644
  ALLWARNS=""
  ALLDEBUG="-g"
 diff --git a/src/ausearch-lol.c b/src/ausearch-lol.c
-index 4fbfbae..5eecefe 100644
+index 5d17a72..758c33e 100644
 --- a/src/ausearch-lol.c
 +++ b/src/ausearch-lol.c
 @@ -1,6 +1,6 @@
@@ -112,8 +111,8 @@ index 4fbfbae..5eecefe 100644
  * All Rights Reserved. 
  *
  * This software may be freely redistributed and/or modified under the
-@@ -131,6 +131,16 @@ static int inline events_are_equal(event *e1, event *e2)
- 	return 1;
+@@ -152,6 +152,16 @@ static int compare_event_time(event *e1, event *e2)
+ 	return 0;
  }
  
 +#ifndef HAVE_STRNDUPA
@@ -130,5 +129,5 @@ index 4fbfbae..5eecefe 100644
   * This function will look at the line and pick out pieces of it.
   */
 -- 
-2.20.1
+2.7.4
 
diff --git a/recipes-security/audit/audit/audit-python-configure.patch b/recipes-security/audit/audit/audit-python-configure.patch
index cb62ec3..37096b0 100644
--- a/recipes-security/audit/audit/audit-python-configure.patch
+++ b/recipes-security/audit/audit/audit-python-configure.patch
@@ -1,9 +1,9 @@
-From be689ee1748c6aa531dbca982e0218d077ac901c Mon Sep 17 00:00:00 2001
+From 6a2710db094061e1956fac3ed81114d0e958ea21 Mon Sep 17 00:00:00 2001
 From: Li xin <lixin.fnst at cn.fujitsu.com>
 Date: Sun, 19 Jul 2015 00:49:13 +0900
 Subject: [PATCH] audit: python cross-compile
 
-Upstream-Status: pending
+Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Xin Ouyang <Xin.Ouyang at windriver.com>
 Signed-off-by: Li Xin <lixin.fnst at cn.fujitsu.com>
@@ -14,10 +14,10 @@ Signed-off-by: T.O. Radzy Radzykewycz <radzy at windriver.com>
  1 file changed, 2 insertions(+), 15 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index 1f48cb4..cdb5219 100644
+index 6e345f1..54bdbf1 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -94,21 +94,8 @@ if test x$use_python = xno ; then
+@@ -99,21 +99,8 @@ if test "x$use_python" = xno ; then
  else
  AC_MSG_RESULT(testing)
  AM_PATH_PYTHON
@@ -42,5 +42,5 @@ index 1f48cb4..cdb5219 100644
  AM_CONDITIONAL(HAVE_PYTHON, test ${python_found} = "yes")
  
 -- 
-1.9.1
+2.7.4
 
diff --git a/recipes-security/audit/audit/audit-python.patch b/recipes-security/audit/audit/audit-python.patch
index 0c2dc1c..c1a2595 100644
--- a/recipes-security/audit/audit/audit-python.patch
+++ b/recipes-security/audit/audit/audit-python.patch
@@ -1,8 +1,10 @@
-From 9c8fd14feabe985242ef08e52c3e866d7755fa6e Mon Sep 17 00:00:00 2001
+From 9d95d7e28a2c4cbefa998d375de180c731a151b1 Mon Sep 17 00:00:00 2001
 From: Li xin <lixin.fnst at cn.fujitsu.com>
 Date: Sun, 19 Jul 2015 01:40:48 +0900
 Subject: [PATCH] Remove hard coded python include directory
 
+Upstream-Status: Inappropriate [embedded specific]
+
 Signed-off-by: Mark Hatle <mark.hatle at windriver.com>
 ---
  bindings/Makefile.am                | 8 +++++++-
@@ -11,7 +13,7 @@ Signed-off-by: Mark Hatle <mark.hatle at windriver.com>
  3 files changed, 12 insertions(+), 4 deletions(-)
 
 diff --git a/bindings/Makefile.am b/bindings/Makefile.am
-index cc68df3..998b990 100644
+index 5b5c576..7a15205 100644
 --- a/bindings/Makefile.am
 +++ b/bindings/Makefile.am
 @@ -22,4 +22,10 @@
@@ -58,5 +60,5 @@ index 8c98b94..ae7c52b 100644
  pyexec_LTLIBRARIES = _audit.la
  pyexec_SOLIBRARIES = _audit.so
 -- 
-1.8.4.2
+2.7.4
 
diff --git a/recipes-security/audit/audit/auditd b/recipes-security/audit/audit/auditd
index fcd96c9..cda2e43 100755
--- a/recipes-security/audit/audit/auditd
+++ b/recipes-security/audit/audit/auditd
@@ -30,7 +30,7 @@ SCRIPTNAME=/etc/init.d/"$NAME"
 
 . /etc/default/rcS
 
-. /etc/init.d/functions                                                
+. /etc/init.d/functions
 
 #
 # Function that starts the daemon/service
diff --git a/recipes-security/audit/audit/fix-swig-host-contamination.patch b/recipes-security/audit/audit/fix-swig-host-contamination.patch
index faeeeeb..184f515 100644
--- a/recipes-security/audit/audit/fix-swig-host-contamination.patch
+++ b/recipes-security/audit/audit/fix-swig-host-contamination.patch
@@ -1,4 +1,4 @@
-From d7577e1e55595123e3bcec78fa4a79fe8a314fe5 Mon Sep 17 00:00:00 2001
+From bd70f570ffb82991feb7a539ac1abf3165d417a4 Mon Sep 17 00:00:00 2001
 From: Li xin <lixin.fnst at cn.fujitsu.com>
 Date: Sun, 19 Jul 2015 02:42:58 +0900
 Subject: [PATCH] audit: Fixed swig host contamination issue
@@ -8,17 +8,17 @@ Unfortunately, the swig info file references host include
 directories.  Some of these were previously noticed and
 eliminated, but the one fixed here was not.
 
-Upstream Status:  pending
+Upstream-Status: Inappropriate [embedded specific]
 
 Signed-off-by: Anders Hedlund <anders.hedlund at windriver.com>
 Signed-off-by: Joe Slater <jslater at windriver.com>
 ---
  bindings/swig/python/Makefile.am | 3 ++-
- bindings/swig/src/auditswig.i    | 4 ++--
- 2 files changed, 4 insertions(+), 3 deletions(-)
+ bindings/swig/src/auditswig.i    | 2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/bindings/swig/python/Makefile.am b/bindings/swig/python/Makefile.am
-index ae7c52b..d1bb93c 100644
+index ae7c52b..c580bc0 100644
 --- a/bindings/swig/python/Makefile.am
 +++ b/bindings/swig/python/Makefile.am
 @@ -22,6 +22,7 @@
@@ -34,25 +34,23 @@ index ae7c52b..d1bb93c 100644
  nodist__audit_la_SOURCES  = audit_wrap.c
  audit.py audit_wrap.c: ${srcdir}/../src/auditswig.i 
 -	swig -o audit_wrap.c ${SWIG_FLAGS} ${SWIG_INCLUDES} ${srcdir}/../src/auditswig.i 
-+	swig -o audit_wrap.c ${SWIG_FLAGS} ${SWIG_INCLUDES} -I$(STDINC) ${srcdir}/../src/auditswig.i 
++	swig -o audit_wrap.c ${SWIG_FLAGS} ${SWIG_INCLUDES} -I$(STDINC) ${srcdir}/../src/auditswig.i
  
  CLEANFILES = audit.py* audit_wrap.c *~
  
 diff --git a/bindings/swig/src/auditswig.i b/bindings/swig/src/auditswig.i
-index 9364ac4..48667d4 100644
+index 7ebb373..424fb68 100644
 --- a/bindings/swig/src/auditswig.i
 +++ b/bindings/swig/src/auditswig.i
-@@ -39,8 +39,8 @@ signed
+@@ -39,7 +39,7 @@ signed
  #define __attribute(X) /*nothing*/
  typedef unsigned __u32;
  typedef unsigned uid_t;
 -%include "/usr/include/linux/audit.h"
 +%include "linux/audit.h"
  #define __extension__ /*nothing*/
--%include "/usr/include/stdint.h"
-+%include "stdint.h"
+ #include <stdint.h>
  %include "../lib/libaudit.h"
- 
 -- 
-1.8.4.2
+2.7.4
 
diff --git a/recipes-security/audit/audit_2.8.4.bb b/recipes-security/audit/audit_2.8.5.bb
similarity index 92%
rename from recipes-security/audit/audit_2.8.4.bb
rename to recipes-security/audit/audit_2.8.5.bb
index 594786a..bd09873 100644
--- a/recipes-security/audit/audit_2.8.4.bb
+++ b/recipes-security/audit/audit_2.8.5.bb
@@ -11,14 +11,13 @@ SRC_URI = "http://people.redhat.com/sgrubb/${BPN}/${BPN}-${PV}.tar.gz \
            file://audit-python-configure.patch \
            file://audit-python.patch \
            file://fix-swig-host-contamination.patch \
-           file://0001-Remove-strdupa-as-suggested-in-pull-request-25.patch \
-           file://0002-Add-substitue-functions-for-strndupa-rawmemchr.patch \
+           file://Add-substitue-functions-for-strndupa-rawmemchr.patch \
            file://auditd \
            file://auditd.service \
            file://audit-volatile.conf \
 "
-SRC_URI[md5sum] = "ec9510312564c3d9483bccf8dbda4779"
-SRC_URI[sha256sum] = "a410694d09fc5708d980a61a5abcb9633a591364f1ecc7e97ad5daef9c898c38"
+SRC_URI[md5sum] = "9455e5773670afdbccaeb92681b2e97d"
+SRC_URI[sha256sum] = "0e5d4103646e00f8d1981e1cd2faea7a2ae28e854c31a803e907a383c5e2ecb7"
 
 inherit autotools pythonnative update-rc.d systemd
 
-- 
2.7.4


From anibal.limon at linaro.org  Tue Jun 25 18:51:13 2019
From: anibal.limon at linaro.org (Anibal Limon)
Date: Tue, 25 Jun 2019 20:51:13 -0500
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
	<98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
Message-ID: <CA+_AqisMBmPaNy7xyt1+9c73RnMcChugCcxz6Bb4cBOCHG=-kQ@mail.gmail.com>

On Wed, 19 Jun 2019 at 12:50, Randy MacLeod <randy.macleod at windriver.com>
wrote:

> On 6/14/19 10:48 AM, Randy MacLeod wrote:
> > When running the run-execscript bash ptest as a user rather than root, a
> warning:
> >    bash: cannot set terminal process group (16036): Inappropriate ioctl
> for device
> >    bash: no job control in this shell
> > contaminates the bash log files causing the test to fail. This happens
> only
> > when run under ptest-runner and not when interactively testing!
> >
> > The changes made to fix this include:
> > 1. Get the process group id (pgid) before forking,
> > 2. Set the pgid in both the parent and child to avoid a race,
> > 3. Find, open and set permission on the child tty, and
> > 4. Allow the child to attach to controlling tty.
> >
> > Also add '-lutil' to Makefile. This lib is from libc and provides
> openpty.
>
>
> Hmmm, I was making the code compile cleanly under clang using
>    -Weverything
> when I noticed:
>
> 1. the 'make check' tests. They still work fine.
> 2. The './ptest-runner -d tests/data -t 1' tests
>     which now generate loads of error like:
>      ERROR: Unable to detach from controlling tty, Inappropriate ioctl
> for device
>
> so while this change fixed the bash-ptest, the ptest-runner self-test
> it did something wrong.... Ah, I'm calling:
>     ioctl(0, TIOCNOTTY) == -1)
> repeatedly in the parent so that's what's generating the extra logs.
> Fixed locally and I'll send a patch but it's not urgent. Phew! :)
>
> Anibal,
>
> If you could reply to explain your plans for Richard's patches
> that would help me figure out when to send the clang warning clean-ups
> commits and what commit to base my work on.
>

Hi,

I plan to take the Richard patches, He added in the recipe to have real
testing and looks like
there aren't problems related to, Richard can you confirm it?,

Regarding the openpty include, I see some linkage problem when running make
check, proposed fix:

...
--- a/Makefile
+++ b/Makefile
@@ -22,19 +22,20 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c
tests/utils.c $(BASE_SOURCES)
 TEST_OBJECTS=$(TEST_SOURCES:.c=.o)
 TEST_EXECUTABLE=ptest-runner-test
 TEST_LDFLAGS=-lm -lrt -lpthread
-TEST_LIBSTATIC=-lcheck -lsubunit
+TEST_LIBSTATIC=-lutil
+TEST_LIBSTATIC_TEST=$(TEST_LIBSTATIC) -lcheck -lsubunit

 TEST_DATA=$(shell echo `pwd`/tests/data)

 all: $(SOURCES) $(EXECUTABLE)

 $(EXECUTABLE): $(OBJECTS)
-       $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
+       $(CC) $(LDFLAGS) $(OBJECTS) -o $@ $(TEST_LIBSTATIC)

 tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)

 $(TEST_EXECUTABLE): $(TEST_OBJECTS)
-       $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@
$(TEST_LIBSTATIC)
+       $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@
$(TEST_LIBSTATIC_TEST)

 check: $(TEST_EXECUTABLE)
        ./$(TEST_EXECUTABLE) -d $(TEST_DATA)
...

Best regards,
Anibal



>
>
> ../Randy
>
> >
> > Signed-off-by: Sakib Sajal <sakib.sajal at windriver.com>
> > Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com>
> > ---
> >   Makefile |   2 +-
> >   utils.c  | 102 +++++++++++++++++++++++++++++++++++++++++++++++++------
> >   2 files changed, 92 insertions(+), 12 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 1bde7be..439eb79 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
> >   all: $(SOURCES) $(EXECUTABLE)
> >
> >   $(EXECUTABLE): $(OBJECTS)
> > -     $(CC) $(LDFLAGS) $(OBJECTS) -o $@
> > +     $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
> >
> >   tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
> >
> > diff --git a/utils.c b/utils.c
> > index ad737c2..f11ce39 100644
> > --- a/utils.c
> > +++ b/utils.c
> > @@ -1,5 +1,6 @@
> >   /**
> >    * Copyright (c) 2016 Intel Corporation
> > + * Copyright (C) 2019 Wind River Systems, Inc.
> >    *
> >    * This program is free software; you can redistribute it and/or
> >    * modify it under the terms of the GNU General Public License
> > @@ -22,23 +23,27 @@
> >    */
> >
> >   #define _GNU_SOURCE
> > +
> >   #include <stdio.h>
> >
> > +#include <dirent.h>
> > +#include <errno.h>
> > +#include <fcntl.h>
> > +#include <grp.h>
> >   #include <libgen.h>
> > -#include <signal.h>
> >   #include <poll.h>
> > -#include <fcntl.h>
> > +#include <pty.h>
> > +#include <signal.h>
> > +#include <stdlib.h>
> > +#include <string.h>
> >   #include <time.h>
> > -#include <dirent.h>
> > +#include <unistd.h>
> > +
> > +#include <sys/ioctl.h>
> >   #include <sys/resource.h>
> > +#include <sys/stat.h>
> >   #include <sys/types.h>
> >   #include <sys/wait.h>
> > -#include <sys/stat.h>
> > -#include <unistd.h>
> > -#include <string.h>
> > -#include <stdlib.h>
> > -
> > -#include <errno.h>
> >
> >   #include "ptest_list.h"
> >   #include "utils.h"
> > @@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char
> *run_ptest, pid_t pid,
> >       return status;
> >   }
> >
> > +/* Returns an integer file descriptor.
> > + * If it returns < 0, an error has occurred.
> > + * Otherwise, it has returned the slave pty file descriptor.
> > + * fp should be writable, likely stdout/err.
> > + */
> > +static int
> > +setup_slave_pty(FILE *fp) {
> > +     int pty_master = -1;
> > +     int pty_slave = -1;
> > +     char pty_name[256];
> > +     struct group *gptr;
> > +     gid_t gid;
> > +     int slave = -1;
> > +
> > +     if (openpty(&pty_master, &pty_slave, pty_name, NULL, NULL) < 0) {
> > +             fprintf(fp, "ERROR: openpty() failed with: %s.\n",
> strerror(errno));
> > +             return -1;
> > +     }
> > +
> > +     if ((gptr = getgrnam(pty_name)) != 0) {
> > +             gid = gptr->gr_gid;
> > +     } else {
> > +             /* If the tty group does not exist, don't change the
> > +              * group on the slave pty, only the owner
> > +              */
> > +             gid = -1;
> > +     }
> > +
> > +     /* chown/chmod the corresponding pty, if possible.
> > +      * This will only work if the process has root permissions.
> > +      */
> > +     if (chown(pty_name, getuid(), gid) != 0) {
> > +             fprintf(fp, "ERROR; chown() failed with: %s.\n",
> strerror(errno));
> > +     }
> > +
> > +     /* Makes the slave read/writeable for the user. */
> > +     if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
> > +             fprintf(fp, "ERROR: chmod() failed with: %s.\n",
> strerror(errno));
> > +     }
> > +
> > +     if ((slave = open(pty_name, O_RDWR)) == -1) {
> > +             fprintf(fp, "ERROR: open() failed with: %s.\n",
> strerror(errno));
> > +     }
> > +     return (slave);
> > +}
> > +
> > +
> >   int
> >   run_ptests(struct ptest_list *head, const struct ptest_options opts,
> >               const char *progname, FILE *fp, FILE *fp_stderr)
> > @@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct
> ptest_options opts,
> >       int timeouted;
> >       time_t sttime, entime;
> >       int duration;
> > +     int slave;
> > +     int pgid = -1;
> >
> >       if (opts.xml_filename) {
> >               xh = xml_create(ptest_list_length(head),
> opts.xml_filename);
> > @@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct
> ptest_options opts,
> >                       close(pipefd_stdout[1]);
> >                       break;
> >               }
> > -
> >               fprintf(fp, "START: %s\n", progname);
> >               PTEST_LIST_ITERATE_START(head, p);
> >                       char *ptest_dir = strdup(p->run_ptest);
> > @@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct
> ptest_options opts,
> >                               break;
> >                       }
> >                       dirname(ptest_dir);
> > +                     if (ioctl(0, TIOCNOTTY) == -1) {
> > +                             fprintf(fp, "ERROR: Unable to detach from
> controlling tty, %s\n", strerror(errno));
> > +                     }
> > +
> > +                     if ((pgid = getpgid(0)) == -1) {
> > +                             fprintf(fp, "ERROR: getpgid() failed,
> %s\n", strerror(errno));
> > +                     }
> >
> >                       child = fork();
> >                       if (child == -1) {
> > @@ -395,13 +455,33 @@ run_ptests(struct ptest_list *head, const struct
> ptest_options opts,
> >                               rc = -1;
> >                               break;
> >                       } else if (child == 0) {
> > -                             setsid();
> > +                             close(0);
> > +                             if ((slave = setup_slave_pty(fp)) < 0) {
> > +                                     fprintf(fp, "ERROR: could not
> setup pty (%d).", slave);
> > +                             }
> > +                             if (setpgid(0,pgid) == -1) {
> > +                                     fprintf(fp, "ERROR: setpgid()
> failed, %s\n", strerror(errno));
> > +                             }
> > +
> > +                             if (setsid() ==  -1) {
> > +                                     fprintf(fp, "ERROR: setsid()
> failed, %s\n", strerror(errno));
> > +                             }
> > +
> > +                             if (ioctl(0, TIOCSCTTY, NULL) == -1) {
> > +                                     fprintf(fp, "ERROR: Unable to
> attach to controlling tty, %s\n", strerror(errno));
> > +                             }
> > +
> >                               run_child(p->run_ptest, pipefd_stdout[1],
> pipefd_stderr[1]);
> > +
> >                       } else {
> >                               int status;
> >                               int fds[2]; fds[0] = pipefd_stdout[0];
> fds[1] = pipefd_stderr[0];
> >                               FILE *fps[2]; fps[0] = fp; fps[1] =
> fp_stderr;
> >
> > +                             if (setpgid(child, pgid) == -1) {
> > +                                     fprintf(fp, "ERROR: setpgid()
> failed, %s\n", strerror(errno));
> > +                             }
> > +
> >                               sttime = time(NULL);
> >                               fprintf(fp, "%s\n", get_stime(stime,
> GET_STIME_BUF_SIZE, sttime));
> >                               fprintf(fp, "BEGIN: %s\n", ptest_dir);
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/4339c012/attachment-0001.html>

From Vignesh.Rajendran at in.bosch.com  Tue Jun 25 19:58:00 2019
From: Vignesh.Rajendran at in.bosch.com (Vignesh Rajendran (RBEI/ECF3))
Date: Wed, 26 Jun 2019 02:58:00 +0000
Subject: [yocto] build on CVE is failing
In-Reply-To: <CAJTo0LaUTDZi-cKg4dfGDdfm+gNrVxwPRQpVO0chprNn9nTBMQ@mail.gmail.com>
References: <22839e9497e34df9b93272590fcc483d@in.bosch.com>
	<CAJTo0LaUTDZi-cKg4dfGDdfm+gNrVxwPRQpVO0chprNn9nTBMQ@mail.gmail.com>
Message-ID: <22b8b93a35164facac62905d3c1dbd5c@in.bosch.com>

Hi Ross,

Sure, I will give a try.
Thank You.

Best regards,

Rajendran Vignesh
RBEI/ECF3  

Tel. +91 422 676-5103 | Threema Work: +914226765103 


-----Original Message-----
From: Burton, Ross <ross.burton at intel.com> 
Sent: Tuesday, June 25, 2019 8:18 PM
To: Vignesh Rajendran (RBEI/ECF3) <Vignesh.Rajendran at in.bosch.com>
Cc: yocto at yoctoproject.org; Ramadevi Sennakesavan (RBEI/ECF3) <Ramadevi.Sennakesavan at in.bosch.com>
Subject: Re: [yocto] build on CVE is failing

Yes, you're right, this is a bug in the new functionality.

The usual variables are in the data store, so you can get them with e.g. d.getVar("http_proxy"), as you can clearly replicate the failure would you be able to attempt a patch?

Ross

On Tue, 25 Jun 2019 at 11:14, Vignesh Rajendran (RBEI/ECF3) <Vignesh.Rajendran at in.bosch.com> wrote:
>
> Hi,
>
>
>
> I was trying to check the CVE feature on Yocto.
>
>
>
> I couldn?t succeed the build with CVE.
>
> https://pastebin.com/m7hNcNcm
>
>
>
> There seems like proxy environment doesn?t recognized inside do_populate_cve_db.
>
>
>
> ERROR: cve-update-db-1.0-r0 do_populate_cve_db: HTTPSConnectionPool(host='nvd.nist.gov', port=443):
>
> Max retries exceeded with url: 
> /feeds/json/cve/1.0/nvdcve-1.0-2002.meta (Caused by 
> NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object 
> at 0x7f787f1a8908>: Failed to establish a new connection: [Errno -2] 
> Name or service not known',))
>
>
>
> I am using HEAD of poky master branch.
>
>
>
> Best regards,
>
> Rajendran Vignesh
> RBEI/ECF3
>
> Tel. +91 422 676-5103 | Threema Work: +914226765103
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From richard.purdie at linuxfoundation.org  Tue Jun 25 23:56:03 2019
From: richard.purdie at linuxfoundation.org (richard.purdie at linuxfoundation.org)
Date: Wed, 26 Jun 2019 07:56:03 +0100
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <CA+_AqisMBmPaNy7xyt1+9c73RnMcChugCcxz6Bb4cBOCHG=-kQ@mail.gmail.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
	<98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
	<CA+_AqisMBmPaNy7xyt1+9c73RnMcChugCcxz6Bb4cBOCHG=-kQ@mail.gmail.com>
Message-ID: <7fb8cc8572391fce34212e6b9b3eef112ebf107c.camel@linuxfoundation.org>

On Tue, 2019-06-25 at 20:51 -0500, Anibal Limon wrote:
> I plan to take the Richard patches, He added in the recipe to have
> real testing and looks like
> there aren't problems related to, Richard can you confirm it?,

We've been running the patches for a while in the recipe (since we last
discussed them) and we haven't seen any problems with them.

Thanks for looking at this, its a good one to get sorted out.

Cheers,

Richard


From morne at linux.com  Wed Jun 26 03:03:34 2019
From: morne at linux.com (=?iso-8859-1?Q?Morn=E9?= Lamprecht)
Date: Wed, 26 Jun 2019 12:03:34 +0200
Subject: [yocto] General Question: Device specific value store
In-Reply-To: <CAOmL4Ujwqu1pVe5zEGntJjYTNgw7__LPi_mdgn7-xU93dwF62A@mail.gmail.com>
References: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
	<20190624070810.GD1584@archworkstation>
	<43163f9c-29e2-6069-bd13-ff65f82d55bd@googlemail.com>
	<CAAx3WaA+OemjNchvCFd_3m3K5LE4OedqFVtwdPAjYNwUSWv28Q@mail.gmail.com>
	<CAOmL4Ujwqu1pVe5zEGntJjYTNgw7__LPi_mdgn7-xU93dwF62A@mail.gmail.com>
Message-ID: <20190626100334.GA9460@archworkstation>

On Tue, Jun 25, 2019 at 09:25:13AM -0400, Larry Brown wrote:
>>> I wonder, if there are best practices, how to protect the data from getting 
>>> corrupted (intentionally by an attacker or by accident through ... flash 
>>> corruption or whatever).

Ideally your hardware should have some sort of hw-based secure key storage, and 
use that to support some sort of secure boot scheme. You can then implement a 
chain of trust, allowing you to securely verify a hash signature of the data 
during bootup, to ensure that it hadn't been tampered with or gotten corrupted.

Atmel / Microchip, for example, offers a range of Crypto Authentication ICs that 
could be added to your hardware to support this, if you hardware didn't have 
built in support for something like this. Their offering also included tools to 
securely inject the data into the secure ICs during manufacturing, or 
alternatively, you could write your own tool to interface with their API.

		- Morn?

From andrea.adami at gmail.com  Wed Jun 26 03:21:33 2019
From: andrea.adami at gmail.com (Andrea Adami)
Date: Wed, 26 Jun 2019 12:21:33 +0200
Subject: [yocto] General Question: Device specific value store
In-Reply-To: <20190626100334.GA9460@archworkstation>
References: <6fefee9b-8521-b633-8ae4-00b09e6d3532@googlemail.com>
	<20190624070810.GD1584@archworkstation>
	<43163f9c-29e2-6069-bd13-ff65f82d55bd@googlemail.com>
	<CAAx3WaA+OemjNchvCFd_3m3K5LE4OedqFVtwdPAjYNwUSWv28Q@mail.gmail.com>
	<CAOmL4Ujwqu1pVe5zEGntJjYTNgw7__LPi_mdgn7-xU93dwF62A@mail.gmail.com>
	<20190626100334.GA9460@archworkstation>
Message-ID: <CAAQYJAuc6QLwo-4nkdfZMcRuiZUba-c=i5CuapjR7tsV=Ph-2g@mail.gmail.com>

On Wed, Jun 26, 2019 at 12:03 PM Morn? Lamprecht <morne at linux.com> wrote:
>
> On Tue, Jun 25, 2019 at 09:25:13AM -0400, Larry Brown wrote:
> >>> I wonder, if there are best practices, how to protect the data from getting
> >>> corrupted (intentionally by an attacker or by accident through ... flash
> >>> corruption or whatever).
>
> Ideally your hardware should have some sort of hw-based secure key storage, and
> use that to support some sort of secure boot scheme. You can then implement a
> chain of trust, allowing you to securely verify a hash signature of the data
> during bootup, to ensure that it hadn't been tampered with or gotten corrupted.
>
> Atmel / Microchip, for example, offers a range of Crypto Authentication ICs that
> could be added to your hardware to support this, if you hardware didn't have
> built in support for something like this. Their offering also included tools to
> securely inject the data into the secure ICs during manufacturing, or
> alternatively, you could write your own tool to interface with their API.
>
>                 - Morn?
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


Hi,
almost all flash have a non-volatile storage.
It was OTP on old NOR, now there are more flavors: your board appears
to have eMMC and so OTP/MTP should be supported by the mmc stack.
Check out this link:
https://www.synopsys.com/designware-ip/technical-bulletin/memory-options.html

Regards
Andrea

From zhe.he at windriver.com  Wed Jun 26 04:12:31 2019
From: zhe.he at windriver.com (zhe.he at windriver.com)
Date: Wed, 26 Jun 2019 19:12:31 +0800
Subject: [yocto] [meta-security][PATCH] kernel: Add conditional inclusion of
	fragments for linux-yocto-dev
Message-ID: <1561547551-406985-1-git-send-email-zhe.he@windriver.com>

From: He Zhe <zhe.he at windriver.com>

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
 recipes-kernel/linux/linux-yocto-dev.bbappend | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
new file mode 100644
index 0000000..68b2b8b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -0,0 +1,11 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/linux-yocto-5.0:"
+
+SRC_URI += "\
+        ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' file://apparmor.cfg', '', d)} \
+        ${@bb.utils.contains('DISTRO_FEATURES', 'apparmor', ' file://apparmor_on_boot.cfg', '', d)} \
+"
+
+SRC_URI += "\
+        ${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' file://smack.cfg', '', d)} \
+        ${@bb.utils.contains('DISTRO_FEATURES', 'smack', ' file://smack-default-lsm.cfg', '', d)} \
+"
-- 
2.7.4


From randy.macleod at windriver.com  Wed Jun 26 08:55:55 2019
From: randy.macleod at windriver.com (Randy MacLeod)
Date: Wed, 26 Jun 2019 11:55:55 -0400
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <CA+_AqisMBmPaNy7xyt1+9c73RnMcChugCcxz6Bb4cBOCHG=-kQ@mail.gmail.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
	<98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
	<CA+_AqisMBmPaNy7xyt1+9c73RnMcChugCcxz6Bb4cBOCHG=-kQ@mail.gmail.com>
Message-ID: <ffe4bdfd-5a89-1c4f-87cf-dbd27b3025e5@windriver.com>

On 6/25/19 9:51 PM, Anibal Limon wrote:
> 
> 
> On Wed, 19 Jun 2019 at 12:50, Randy MacLeod <randy.macleod at windriver.com 
> <mailto:randy.macleod at windriver.com>> wrote:
> 
>     On 6/14/19 10:48 AM, Randy MacLeod wrote:
>      > When running the run-execscript bash ptest as a user rather than
>     root, a warning:
>      >? ? bash: cannot set terminal process group (16036): Inappropriate
>     ioctl for device
>      >? ? bash: no job control in this shell
>      > contaminates the bash log files causing the test to fail. This
>     happens only
>      > when run under ptest-runner and not when interactively testing!
>      >
>      > The changes made to fix this include:
>      > 1. Get the process group id (pgid) before forking,
>      > 2. Set the pgid in both the parent and child to avoid a race,
>      > 3. Find, open and set permission on the child tty, and
>      > 4. Allow the child to attach to controlling tty.
>      >
>      > Also add '-lutil' to Makefile. This lib is from libc and provides
>     openpty.
> 
> 
>     Hmmm, I was making the code compile cleanly under clang using
>      ? ?-Weverything
>     when I noticed:
> 
>     1. the 'make check' tests. They still work fine.
>     2. The './ptest-runner -d tests/data -t 1' tests
>      ? ? which now generate loads of error like:
>      ? ? ?ERROR: Unable to detach from controlling tty, Inappropriate ioctl
>     for device
> 
>     so while this change fixed the bash-ptest, the ptest-runner self-test
>     it did something wrong.... Ah, I'm calling:
>      ? ? ioctl(0, TIOCNOTTY) == -1)
>     repeatedly in the parent so that's what's generating the extra logs.
>     Fixed locally and I'll send a patch but it's not urgent. Phew! :)
> 
>     Anibal,
> 
>     If you could reply to explain your plans for Richard's patches
>     that would help me figure out when to send the clang warning clean-ups
>     commits and what commit to base my work on.
> 
> 
> Hi,
> 
> I plan to take the Richard patches, He added in the recipe to have real 
> testing and looks like
> there aren't problems related to, Richard can you confirm it?,
> 
> Regarding the openpty include, I see some linkage problem when running 
> make check, proposed fix:

Yes, I had noticed that and fixed it as well.

I'll send my latest patch series once you have merged
Richard's changes into master. Hopefully that will be today... :)

I decided to compile with:
   clang -Weverything
to see if there were any problems and there
were quite a few things to fix. Now, for the most part,
neither clang nor gcc complain about the code.

../Randy

> 
> ...
> --- a/Makefile
> +++ b/Makefile
> @@ -22,19 +22,20 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c 
> tests/utils.c $(BASE_SOURCES)
>  ?TEST_OBJECTS=$(TEST_SOURCES:.c=.o)
>  ?TEST_EXECUTABLE=ptest-runner-test
>  ?TEST_LDFLAGS=-lm -lrt -lpthread
> -TEST_LIBSTATIC=-lcheck -lsubunit
> +TEST_LIBSTATIC=-lutil
> +TEST_LIBSTATIC_TEST=$(TEST_LIBSTATIC) -lcheck -lsubunit
> 
>  ?TEST_DATA=$(shell echo `pwd`/tests/data)
> 
>  ?all: $(SOURCES) $(EXECUTABLE)
> 
>  ?$(EXECUTABLE): $(OBJECTS)
> - ? ? ? $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
> + ? ? ? $(CC) $(LDFLAGS) $(OBJECTS) -o $@ $(TEST_LIBSTATIC)
> 
>  ?tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
> 
>  ?$(TEST_EXECUTABLE): $(TEST_OBJECTS)
> - ? ? ? $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@ 
> $(TEST_LIBSTATIC)
> + ? ? ? $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@ 
> $(TEST_LIBSTATIC_TEST)
> 
>  ?check: $(TEST_EXECUTABLE)
>  ? ? ? ? ./$(TEST_EXECUTABLE) -d $(TEST_DATA)
> ...
> 
> Best regards,
> Anibal
> 
> 
> 
>     ../Randy
> 
>      >
>      > Signed-off-by: Sakib Sajal <sakib.sajal at windriver.com
>     <mailto:sakib.sajal at windriver.com>>
>      > Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com
>     <mailto:Randy.MacLeod at windriver.com>>
>      > ---
>      >? ?Makefile |? ?2 +-
>      >? ?utils.c? | 102
>     +++++++++++++++++++++++++++++++++++++++++++++++++------
>      >? ?2 files changed, 92 insertions(+), 12 deletions(-)
>      >
>      > diff --git a/Makefile b/Makefile
>      > index 1bde7be..439eb79 100644
>      > --- a/Makefile
>      > +++ b/Makefile
>      > @@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
>      >? ?all: $(SOURCES) $(EXECUTABLE)
>      >
>      >? ?$(EXECUTABLE): $(OBJECTS)
>      > -? ? ?$(CC) $(LDFLAGS) $(OBJECTS) -o $@
>      > +? ? ?$(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
>      >
>      >? ?tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
>      >
>      > diff --git a/utils.c b/utils.c
>      > index ad737c2..f11ce39 100644
>      > --- a/utils.c
>      > +++ b/utils.c
>      > @@ -1,5 +1,6 @@
>      >? ?/**
>      >? ? * Copyright (c) 2016 Intel Corporation
>      > + * Copyright (C) 2019 Wind River Systems, Inc.
>      >? ? *
>      >? ? * This program is free software; you can redistribute it and/or
>      >? ? * modify it under the terms of the GNU General Public License
>      > @@ -22,23 +23,27 @@
>      >? ? */
>      >
>      >? ?#define _GNU_SOURCE
>      > +
>      >? ?#include <stdio.h>
>      >
>      > +#include <dirent.h>
>      > +#include <errno.h>
>      > +#include <fcntl.h>
>      > +#include <grp.h>
>      >? ?#include <libgen.h>
>      > -#include <signal.h>
>      >? ?#include <poll.h>
>      > -#include <fcntl.h>
>      > +#include <pty.h>
>      > +#include <signal.h>
>      > +#include <stdlib.h>
>      > +#include <string.h>
>      >? ?#include <time.h>
>      > -#include <dirent.h>
>      > +#include <unistd.h>
>      > +
>      > +#include <sys/ioctl.h>
>      >? ?#include <sys/resource.h>
>      > +#include <sys/stat.h>
>      >? ?#include <sys/types.h>
>      >? ?#include <sys/wait.h>
>      > -#include <sys/stat.h>
>      > -#include <unistd.h>
>      > -#include <string.h>
>      > -#include <stdlib.h>
>      > -
>      > -#include <errno.h>
>      >
>      >? ?#include "ptest_list.h"
>      >? ?#include "utils.h"
>      > @@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char
>     *run_ptest, pid_t pid,
>      >? ? ? ?return status;
>      >? ?}
>      >
>      > +/* Returns an integer file descriptor.
>      > + * If it returns < 0, an error has occurred.
>      > + * Otherwise, it has returned the slave pty file descriptor.
>      > + * fp should be writable, likely stdout/err.
>      > + */
>      > +static int
>      > +setup_slave_pty(FILE *fp) {
>      > +? ? ?int pty_master = -1;
>      > +? ? ?int pty_slave = -1;
>      > +? ? ?char pty_name[256];
>      > +? ? ?struct group *gptr;
>      > +? ? ?gid_t gid;
>      > +? ? ?int slave = -1;
>      > +
>      > +? ? ?if (openpty(&pty_master, &pty_slave, pty_name, NULL, NULL)
>     < 0) {
>      > +? ? ? ? ? ? ?fprintf(fp, "ERROR: openpty() failed with: %s.\n",
>     strerror(errno));
>      > +? ? ? ? ? ? ?return -1;
>      > +? ? ?}
>      > +
>      > +? ? ?if ((gptr = getgrnam(pty_name)) != 0) {
>      > +? ? ? ? ? ? ?gid = gptr->gr_gid;
>      > +? ? ?} else {
>      > +? ? ? ? ? ? ?/* If the tty group does not exist, don't change the
>      > +? ? ? ? ? ? ? * group on the slave pty, only the owner
>      > +? ? ? ? ? ? ? */
>      > +? ? ? ? ? ? ?gid = -1;
>      > +? ? ?}
>      > +
>      > +? ? ?/* chown/chmod the corresponding pty, if possible.
>      > +? ? ? * This will only work if the process has root permissions.
>      > +? ? ? */
>      > +? ? ?if (chown(pty_name, getuid(), gid) != 0) {
>      > +? ? ? ? ? ? ?fprintf(fp, "ERROR; chown() failed with: %s.\n",
>     strerror(errno));
>      > +? ? ?}
>      > +
>      > +? ? ?/* Makes the slave read/writeable for the user. */
>      > +? ? ?if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
>      > +? ? ? ? ? ? ?fprintf(fp, "ERROR: chmod() failed with: %s.\n",
>     strerror(errno));
>      > +? ? ?}
>      > +
>      > +? ? ?if ((slave = open(pty_name, O_RDWR)) == -1) {
>      > +? ? ? ? ? ? ?fprintf(fp, "ERROR: open() failed with: %s.\n",
>     strerror(errno));
>      > +? ? ?}
>      > +? ? ?return (slave);
>      > +}
>      > +
>      > +
>      >? ?int
>      >? ?run_ptests(struct ptest_list *head, const struct ptest_options
>     opts,
>      >? ? ? ? ? ? ? ?const char *progname, FILE *fp, FILE *fp_stderr)
>      > @@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const
>     struct ptest_options opts,
>      >? ? ? ?int timeouted;
>      >? ? ? ?time_t sttime, entime;
>      >? ? ? ?int duration;
>      > +? ? ?int slave;
>      > +? ? ?int pgid = -1;
>      >
>      >? ? ? ?if (opts.xml_filename) {
>      >? ? ? ? ? ? ? ?xh = xml_create(ptest_list_length(head),
>     opts.xml_filename);
>      > @@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const
>     struct ptest_options opts,
>      >? ? ? ? ? ? ? ? ? ? ? ?close(pipefd_stdout[1]);
>      >? ? ? ? ? ? ? ? ? ? ? ?break;
>      >? ? ? ? ? ? ? ?}
>      > -
>      >? ? ? ? ? ? ? ?fprintf(fp, "START: %s\n", progname);
>      >? ? ? ? ? ? ? ?PTEST_LIST_ITERATE_START(head, p);
>      >? ? ? ? ? ? ? ? ? ? ? ?char *ptest_dir = strdup(p->run_ptest);
>      > @@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const
>     struct ptest_options opts,
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
>      >? ? ? ? ? ? ? ? ? ? ? ?}
>      >? ? ? ? ? ? ? ? ? ? ? ?dirname(ptest_dir);
>      > +? ? ? ? ? ? ? ? ? ? ?if (ioctl(0, TIOCNOTTY) == -1) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR: Unable to
>     detach from controlling tty, %s\n", strerror(errno));
>      > +? ? ? ? ? ? ? ? ? ? ?}
>      > +
>      > +? ? ? ? ? ? ? ? ? ? ?if ((pgid = getpgid(0)) == -1) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR: getpgid()
>     failed, %s\n", strerror(errno));
>      > +? ? ? ? ? ? ? ? ? ? ?}
>      >
>      >? ? ? ? ? ? ? ? ? ? ? ?child = fork();
>      >? ? ? ? ? ? ? ? ? ? ? ?if (child == -1) {
>      > @@ -395,13 +455,33 @@ run_ptests(struct ptest_list *head, const
>     struct ptest_options opts,
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?rc = -1;
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?break;
>      >? ? ? ? ? ? ? ? ? ? ? ?} else if (child == 0) {
>      > -? ? ? ? ? ? ? ? ? ? ? ? ? ? ?setsid();
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?close(0);
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if ((slave = setup_slave_pty(fp)) <
>     0) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR: could
>     not setup pty (%d).", slave);
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (setpgid(0,pgid) == -1) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR:
>     setpgid() failed, %s\n", strerror(errno));
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}
>      > +
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (setsid() ==? -1) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR:
>     setsid() failed, %s\n", strerror(errno));
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}
>      > +
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (ioctl(0, TIOCSCTTY, NULL) == -1) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR: Unable
>     to attach to controlling tty, %s\n", strerror(errno));
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}
>      > +
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?run_child(p->run_ptest,
>     pipefd_stdout[1], pipefd_stderr[1]);
>      > +
>      >? ? ? ? ? ? ? ? ? ? ? ?} else {
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int status;
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int fds[2]; fds[0] =
>     pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?FILE *fps[2]; fps[0] = fp; fps[1] =
>     fp_stderr;
>      >
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?if (setpgid(child, pgid) == -1) {
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "ERROR:
>     setpgid() failed, %s\n", strerror(errno));
>      > +? ? ? ? ? ? ? ? ? ? ? ? ? ? ?}
>      > +
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?sttime = time(NULL);
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "%s\n",
>     get_stime(stime, GET_STIME_BUF_SIZE, sttime));
>      >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?fprintf(fp, "BEGIN: %s\n", ptest_dir);
>      >
> 
> 
>     -- 
>     # Randy MacLeod
>     # Wind River Linux
> 


-- 
# Randy MacLeod
# Wind River Linux

From pierrelucbuhler at gmail.com  Wed Jun 26 11:21:28 2019
From: pierrelucbuhler at gmail.com (Pierre-Luc Buhler)
Date: Wed, 26 Jun 2019 14:21:28 -0400
Subject: [yocto] Are native packages dependencies listed in
	license.manifest?
In-Reply-To: <CAJTo0LYm6Zgh3OD2t1ZXHny+cEcTCNO2ujD1S1w6VRv8bpdnOw@mail.gmail.com>
References: <5d111b11.1c69fb81.bbbda.d4fc@mx.google.com>
	<CAJTo0LYm6Zgh3OD2t1ZXHny+cEcTCNO2ujD1S1w6VRv8bpdnOw@mail.gmail.com>
Message-ID: <CADNqb7RULJx_V5u0twHxSMK8Gv8QxGrYOkx_PRNLCqR6XCaCAg@mail.gmail.com>

Thanks for the response.

Have a nice day.

PLB

Le lun. 24 juin 2019, ? 17 h 49, Burton, Ross <ross.burton at intel.com> a
?crit :

> The image manifest lists what is being *distributed* so doesn't
> include native dependencies.
>
> Ross
>
> On Mon, 24 Jun 2019 at 19:50, <pierrelucbuhler at gmail.com> wrote:
> >
> > Hi,
> > I?m currently working to remove all GPLv3 packages included in my image.
> > I was using the license manifest file to list the remaining GPLv3
> packages to remove.
> > While I was trying to remove gdbm, I ecountered some native dependencies.
> > When I looked at the license.manifest file, gdbm was still listed.
> > So I was asking myself if I still had packages that depends/includes
> gdbm hidden somewhere or it?s because the license.manifest also list
> packages used on the build host even if they are not included in the image.
> > For example, if curl-native is used in a recipe will curl be listed in
> license.manifest even if curl is not in the image?
> >
> > So in other words, does license.manifest also includes native packages
> or it only lists the packages that make up the image (included in the
> image)?
> >
> > Thanks for the support,
> >
> > PLB
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190626/febeba6a/attachment.html>

From yi.zhao at windriver.com  Wed Jun 26 17:38:59 2019
From: yi.zhao at windriver.com (Yi Zhao)
Date: Thu, 27 Jun 2019 08:38:59 +0800
Subject: [yocto] [meta-cgl][PATCH 1/3] packagegroup-cgl-middleware: remove
	ipsec-tools and umip
Message-ID: <1561595941-25137-1-git-send-email-yi.zhao@windriver.com>

The ipsec-tools and umip had been removed from meta-openembedded. We
should remove them from the packagegroup.

Signed-off-by: Yi Zhao <yi.zhao at windriver.com>
---
 meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb | 2 --
 1 file changed, 2 deletions(-)

diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
index 6ec68c4..4fa7d48 100644
--- a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
+++ b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
@@ -23,7 +23,6 @@ MULTIPATH_TOOLS = " \
     "
 
 RDEPENDS_packagegroup-cgl-middleware = "\
-    ipsec-tools \
     net-snmp-server \
     net-snmp-client \
     net-snmp-libs \
@@ -51,7 +50,6 @@ RDEPENDS_packagegroup-cgl-middleware = "\
     ifenslave \
     drbd-utils \
     openl2tp \
-    umip \
     dmidecode \
     "
 
-- 
2.7.4


From yi.zhao at windriver.com  Wed Jun 26 17:39:00 2019
From: yi.zhao at windriver.com (Yi Zhao)
Date: Thu, 27 Jun 2019 08:39:00 +0800
Subject: [yocto] [meta-cgl][PATCH 2/3] packagegroup-cgl-applications: only
	install libpam and pam-passwdqc if pam distro flag set
In-Reply-To: <1561595941-25137-1-git-send-email-yi.zhao@windriver.com>
References: <1561595941-25137-1-git-send-email-yi.zhao@windriver.com>
Message-ID: <1561595941-25137-2-git-send-email-yi.zhao@windriver.com>

Fix build error when pam distro flag is not set:

$ bitbake packagegroup-cgl-applications
ERROR: Nothing RPROVIDES 'pam-passwdqc' (but
/buildarea/poky/meta-cgl/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
RDEPENDS on or otherwise requires it)
ERROR: Nothing RPROVIDES 'libpam' (but
/buildarea/poky/meta-cgl/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
RDEPENDS on or otherwise requires it)

Signed-off-by: Yi Zhao <yi.zhao at windriver.com>
---
 meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb b/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
index 5e7170d..6b7a630 100644
--- a/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
+++ b/meta-cgl-common/packagegroups/packagegroup-cgl-applications.bb
@@ -46,9 +46,8 @@ RDEPENDS_${PN} = " \
     samhain-server \
     audit \
     crash \
-    pam-passwdqc \
-    libpam \
     makedumpfile \
+    ${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'pam-passwdqc libpam', '', d)} \
     "
 
 LTTNG ?= "\
-- 
2.7.4


From yi.zhao at windriver.com  Wed Jun 26 17:39:01 2019
From: yi.zhao at windriver.com (Yi Zhao)
Date: Thu, 27 Jun 2019 08:39:01 +0800
Subject: [yocto] [meta-cgl][PATCH 3/3] libhtml-tagset-perl: remove recipe
In-Reply-To: <1561595941-25137-1-git-send-email-yi.zhao@windriver.com>
References: <1561595941-25137-1-git-send-email-yi.zhao@windriver.com>
Message-ID: <1561595941-25137-3-git-send-email-yi.zhao@windriver.com>

The libhtml-tagset-perl recipe was added to meta-perl layer with commit:
4058e65f3c4e17ad04423f4c9edf8607fe6fdb4f
We can drop this duplicate recipe.

Signed-off-by: Yi Zhao <yi.zhao at windriver.com>
---
 .../recipes-perl/perl/libhtml-tagset-perl_3.20.bb       | 17 -----------------
 1 file changed, 17 deletions(-)
 delete mode 100644 meta-cgl-common/recipes-perl/perl/libhtml-tagset-perl_3.20.bb

diff --git a/meta-cgl-common/recipes-perl/perl/libhtml-tagset-perl_3.20.bb b/meta-cgl-common/recipes-perl/perl/libhtml-tagset-perl_3.20.bb
deleted file mode 100644
index 2765cd2..0000000
--- a/meta-cgl-common/recipes-perl/perl/libhtml-tagset-perl_3.20.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-DESCRIPTION = "HTML Tagset bits."
-HOMEPAGE = "http://search.cpan.org/dist/HTML-Tagset/"
-SECTION = "libs"
-LICENSE = "Artistic-1.0 | GPL-1.0+"
-LIC_FILES_CHKSUM = "file://README;beginline=60;md5=16ddda2d845a5546f615e6b122d1dbad"
-PR = "r4"
-
-SRC_URI = "http://search.cpan.org/CPAN/authors/id/P/PE/PETDANCE/HTML-Tagset-${PV}.tar.gz"
-
-S = "${WORKDIR}/HTML-Tagset-${PV}"
-
-inherit cpan
-
-BBCLASSEXTEND="native"
-
-SRC_URI[md5sum] = "d2bfa18fe1904df7f683e96611e87437"
-SRC_URI[sha256sum] = "adb17dac9e36cd011f5243881c9739417fd102fce760f8de4e9be4c7131108e2"
-- 
2.7.4


From daniel.wenninger92 at gmail.com  Wed Jun 26 23:31:49 2019
From: daniel.wenninger92 at gmail.com (danwe)
Date: Thu, 27 Jun 2019 08:31:49 +0200
Subject: [yocto] bitbak command: No recipe available for
Message-ID: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>

while using the command:
daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake core-immage-full
cmdline I get the following ouput:
````

Loading cache: 100% |############################################| Time:
0:00:03

Loaded 1358 entries from dependency cache.

Parsing recipes: 100% |##########################################| Time:
0:00:12

Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65
skipped, 0 masked, 0 errors.

ERROR: No recipes available for:

  /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend

  /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend

  /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend



Summary: There was 1 ERROR message shown, returning a non-zero exit code.
````

How can I solve this?

Thanks.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/defada48/attachment.html>

From Qi.Chen at windriver.com  Thu Jun 27 00:30:11 2019
From: Qi.Chen at windriver.com (ChenQi)
Date: Thu, 27 Jun 2019 15:30:11 +0800
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
References: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
Message-ID: <c13e6f65-72e7-aeda-c731-79b44b219a5a@windriver.com>

Set the following in some conf file, e.g. distro.conf, local.conf.
BB_DANGLINGAPPENDS_WARNONLY = "true"

Best Regards,
Chen Qi

On 06/27/2019 02:31 PM, danwe wrote:
> while using the command:
> daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake 
> core-immage-full cmdline I get the following ouput:
> ````
>
> Loading cache: 100% |############################################| 
> Time: 0:00:03
>
> Loaded 1358 entries from dependency cache.
>
> Parsing recipes: 100% |##########################################| 
> Time: 0:00:12
>
> Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 
> targets, 65 skipped, 0 masked, 0 errors.
>
> ERROR: No recipes available for:
>
> /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>
> /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>
> /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> ````
>
> How can I solve this?
>
> Thanks.
>
> Daniel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/590a420a/attachment.html>

From daniel.wenninger92 at gmail.com  Thu Jun 27 00:34:01 2019
From: daniel.wenninger92 at gmail.com (danwe)
Date: Thu, 27 Jun 2019 09:34:01 +0200
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <c13e6f65-72e7-aeda-c731-79b44b219a5a@windriver.com>
References: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
	<c13e6f65-72e7-aeda-c731-79b44b219a5a@windriver.com>
Message-ID: <CAEmXcAxJsF6JNBkh8SDF5MzoUp_igiHmNDAyoW+EGvuGz9sGuw@mail.gmail.com>

Hi,

thank you very much. So now I don't get errors but warnings. So for what do
I need those .bbappend files? Are you sure there will be no problems later?

Thanks.

Daniel

Am Do., 27. Juni 2019 um 09:18 Uhr schrieb ChenQi <Qi.Chen at windriver.com>:

> Set the following in some conf file, e.g. distro.conf, local.conf.
> BB_DANGLINGAPPENDS_WARNONLY = "true"
>
> Best Regards,
> Chen Qi
>
> On 06/27/2019 02:31 PM, danwe wrote:
>
> while using the command:
> daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake
> core-immage-full cmdline I get the following ouput:
> ````
>
> Loading cache: 100% |############################################| Time:
> 0:00:03
>
> Loaded 1358 entries from dependency cache.
>
> Parsing recipes: 100% |##########################################| Time:
> 0:00:12
>
> Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65
> skipped, 0 masked, 0 errors.
>
> ERROR: No recipes available for:
>
>   /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>
>   /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>
>   /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
>
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> ````
>
> How can I solve this?
>
> Thanks.
>
> Daniel
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/f6730abc/attachment-0001.html>

From Qi.Chen at windriver.com  Thu Jun 27 00:48:05 2019
From: Qi.Chen at windriver.com (ChenQi)
Date: Thu, 27 Jun 2019 15:48:05 +0800
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <CAEmXcAxJsF6JNBkh8SDF5MzoUp_igiHmNDAyoW+EGvuGz9sGuw@mail.gmail.com>
References: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
	<c13e6f65-72e7-aeda-c731-79b44b219a5a@windriver.com>
	<CAEmXcAxJsF6JNBkh8SDF5MzoUp_igiHmNDAyoW+EGvuGz9sGuw@mail.gmail.com>
Message-ID: <6eecbcdb-2317-648f-429f-b59c6a108804@windriver.com>

On 06/27/2019 03:34 PM, danwe wrote:
> Hi,
>
> thank you very much. So now I don't get errors but warnings. So for 
> what do I need those .bbappend files? Are you sure there will be no 
> problems later?
>

You need to ask the maintainer of meta-bbb.

Best Regards,
Chen Qi

> Thanks.
>
> Daniel
>
> Am Do., 27. Juni 2019 um 09:18 Uhr schrieb ChenQi 
> <Qi.Chen at windriver.com <mailto:Qi.Chen at windriver.com>>:
>
>     Set the following in some conf file, e.g. distro.conf, local.conf.
>     BB_DANGLINGAPPENDS_WARNONLY = "true"
>
>     Best Regards,
>     Chen Qi
>
>     On 06/27/2019 02:31 PM, danwe wrote:
>>     while using the command:
>>     daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake
>>     core-immage-full cmdline I get the following ouput:
>>     ````
>>
>>     Loading cache: 100%
>>     |############################################| Time: 0:00:03
>>
>>     Loaded 1358 entries from dependency cache.
>>
>>     Parsing recipes: 100%
>>     |##########################################| Time: 0:00:12
>>
>>     Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361
>>     targets, 65 skipped, 0 masked, 0 errors.
>>
>>     ERROR: No recipes available for:
>>
>>     /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>>
>>     /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>>
>>     /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
>>
>>     Summary: There was 1 ERROR message shown, returning a non-zero
>>     exit code.
>>
>>     ````
>>
>>     How can I solve this?
>>
>>     Thanks.
>>
>>     Daniel
>>
>>
>
>     -- 
>     _______________________________________________
>     yocto mailing list
>     yocto at yoctoproject.org <mailto:yocto at yoctoproject.org>
>     https://lists.yoctoproject.org/listinfo/yocto
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/310231d1/attachment.html>

From ross.burton at intel.com  Thu Jun 27 00:36:48 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Thu, 27 Jun 2019 08:36:48 +0100
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
References: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
Message-ID: <CAJTo0LY4vYE1SZo3Hp7mUeyiXvhfY67uhx+2+ZgwM9wBjU9ZRw@mail.gmail.com>

The problem is that oe-core and meta-bbb are different releases so the
versions don't match up.  Ensure that oe-core and meta-bbb are on the
same branch.

Ross

On Thu, 27 Jun 2019 at 07:33, danwe <daniel.wenninger92 at gmail.com> wrote:
>
> while using the command:
> daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake core-immage-full cmdline I get the following ouput:
> ````
>
> Loading cache: 100% |############################################| Time: 0:00:03
>
> Loaded 1358 entries from dependency cache.
>
> Parsing recipes: 100% |##########################################| Time: 0:00:12
>
> Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65 skipped, 0 masked, 0 errors.
>
> ERROR: No recipes available for:
>
>   /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>
>   /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>
>   /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
>
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> ````
>
> How can I solve this?
>
> Thanks.
>
> Daniel
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From daniel.wenninger92 at gmail.com  Thu Jun 27 00:53:43 2019
From: daniel.wenninger92 at gmail.com (danwe)
Date: Thu, 27 Jun 2019 09:53:43 +0200
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <CAJTo0LY4vYE1SZo3Hp7mUeyiXvhfY67uhx+2+ZgwM9wBjU9ZRw@mail.gmail.com>
References: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
	<CAJTo0LY4vYE1SZo3Hp7mUeyiXvhfY67uhx+2+ZgwM9wBjU9ZRw@mail.gmail.com>
Message-ID: <CAEmXcAwD9J=XzU87Rv9NOa5bXg1oL_F2XHR0n_i4yHxtjLmA8w@mail.gmail.com>

Hi.
Thank you. Could you tell me how I can ensure that these are on the same
branch? There is just one meta-bbb I can download...

Am Do., 27. Juni 2019 um 09:37 Uhr schrieb Burton, Ross <
ross.burton at intel.com>:

> The problem is that oe-core and meta-bbb are different releases so the
> versions don't match up.  Ensure that oe-core and meta-bbb are on the
> same branch.
>
> Ross
>
> On Thu, 27 Jun 2019 at 07:33, danwe <daniel.wenninger92 at gmail.com> wrote:
> >
> > while using the command:
> > daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake
> core-immage-full cmdline I get the following ouput:
> > ````
> >
> > Loading cache: 100% |############################################| Time:
> 0:00:03
> >
> > Loaded 1358 entries from dependency cache.
> >
> > Parsing recipes: 100% |##########################################| Time:
> 0:00:12
> >
> > Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets,
> 65 skipped, 0 masked, 0 errors.
> >
> > ERROR: No recipes available for:
> >
> >   /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
> >
> >   /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
> >
> >   /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
> >
> >
> >
> > Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> >
> > ````
> >
> > How can I solve this?
> >
> > Thanks.
> >
> > Daniel
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/fb4dc957/attachment.html>

From ross.burton at intel.com  Thu Jun 27 01:24:19 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Thu, 27 Jun 2019 09:24:19 +0100
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <CAEmXcAwD9J=XzU87Rv9NOa5bXg1oL_F2XHR0n_i4yHxtjLmA8w@mail.gmail.com>
References: <CAEmXcAxcyTEv0tqmGrT9RyFch2ZxZWpAti5ssnh0+P0zTR9tqQ@mail.gmail.com>
	<CAJTo0LY4vYE1SZo3Hp7mUeyiXvhfY67uhx+2+ZgwM9wBjU9ZRw@mail.gmail.com>
	<CAEmXcAwD9J=XzU87Rv9NOa5bXg1oL_F2XHR0n_i4yHxtjLmA8w@mail.gmail.com>
Message-ID: <CAJTo0LY23qW0_N9t9A6AT5Dk28ctWzaXvmvdvMjP+wgwuyBjcA@mail.gmail.com>

Then ensure that the oe-core or poky or whatever provides your meta/
layer is at the same version as the meta-bbb expects.

Basically this should all be in the meta-bbb instructions, and if it
isn't then ask them.  I've never used meta-bbb.

Ross

On Thu, 27 Jun 2019 at 08:53, danwe <daniel.wenninger92 at gmail.com> wrote:
>
> Hi.
> Thank you. Could you tell me how I can ensure that these are on the same branch? There is just one meta-bbb I can download...
>
> Am Do., 27. Juni 2019 um 09:37 Uhr schrieb Burton, Ross <ross.burton at intel.com>:
>>
>> The problem is that oe-core and meta-bbb are different releases so the
>> versions don't match up.  Ensure that oe-core and meta-bbb are on the
>> same branch.
>>
>> Ross
>>
>> On Thu, 27 Jun 2019 at 07:33, danwe <daniel.wenninger92 at gmail.com> wrote:
>> >
>> > while using the command:
>> > daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake core-immage-full cmdline I get the following ouput:
>> > ````
>> >
>> > Loading cache: 100% |############################################| Time: 0:00:03
>> >
>> > Loaded 1358 entries from dependency cache.
>> >
>> > Parsing recipes: 100% |##########################################| Time: 0:00:12
>> >
>> > Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65 skipped, 0 masked, 0 errors.
>> >
>> > ERROR: No recipes available for:
>> >
>> >   /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>> >
>> >   /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>> >
>> >   /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
>> >
>> >
>> >
>> > Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>> >
>> > ````
>> >
>> > How can I solve this?
>> >
>> > Thanks.
>> >
>> > Daniel
>> > --
>> > _______________________________________________
>> > yocto mailing list
>> > yocto at yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto

From mingli.yu at windriver.com  Thu Jun 27 01:49:37 2019
From: mingli.yu at windriver.com (mingli.yu at windriver.com)
Date: Thu, 27 Jun 2019 16:49:37 +0800
Subject: [yocto] [PATCH 1/2] meta-cloud-services: add layer depends on
	networking-layer
Message-ID: <1561625378-149930-1-git-send-email-mingli.yu@windriver.com>

From: Mingli Yu <Mingli.Yu at windriver.com>

Since spice of meta-cloud-services depends on
cyrus-sasl which comes from networking-layer,
add missing layer depends back.

Signed-off-by: Mingli Yu <Mingli.Yu at windriver.com>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 203f9db..2cfb75f 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -8,4 +8,4 @@ BBFILE_COLLECTIONS += "cloud-services-layer"
 BBFILE_PATTERN_cloud-services-layer := "^${LAYERDIR}/"
 BBFILE_PRIORITY_cloud-services-layer = "5"
 LAYERSERIES_COMPAT_cloud-services-layer = "thud warrior"
-LAYERDEPENDS_cloud-services-layer = "core filesystems-layer"
+LAYERDEPENDS_cloud-services-layer = "core filesystems-layer networking-layer"
-- 
2.7.4


From mingli.yu at windriver.com  Thu Jun 27 01:49:38 2019
From: mingli.yu at windriver.com (mingli.yu at windriver.com)
Date: Thu, 27 Jun 2019 16:49:38 +0800
Subject: [yocto] [PATCH 2/2] nss-pam-ldapd: add required distro feature
	check for pam
In-Reply-To: <1561625378-149930-1-git-send-email-mingli.yu@windriver.com>
References: <1561625378-149930-1-git-send-email-mingli.yu@windriver.com>
Message-ID: <1561625378-149930-2-git-send-email-mingli.yu@windriver.com>

From: Mingli Yu <Mingli.Yu at windriver.com>

As nss-pam-ldapd depends on libpam, it should do
required distro feature check for pam.

Signed-off-by: Mingli Yu <Mingli.Yu at windriver.com>
---
 recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb b/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb
index 404aeca..dfa562f 100644
--- a/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb
+++ b/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb
@@ -20,7 +20,8 @@ SRC_URI = "\
 	file://nslcd.service \
 	"
 
-inherit autotools
+inherit autotools distro_features_check
+REQUIRED_DISTRO_FEATURES = "pam"
 
 SRC_URI[md5sum] = "8c99fdc54f4bf9aca8c5f53fdb1403ff"
 SRC_URI[sha256sum] = "ef7362e7f2003da8c7beb7bcc03c30494acf712625aaac8badc6e7eb16f3453f"
-- 
2.7.4


From anibal.limon at linaro.org  Thu Jun 27 08:27:05 2019
From: anibal.limon at linaro.org (Anibal Limon)
Date: Thu, 27 Jun 2019 10:27:05 -0500
Subject: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be
 session leader
In-Reply-To: <ffe4bdfd-5a89-1c4f-87cf-dbd27b3025e5@windriver.com>
References: <20190613223928.14424-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-1-Randy.MacLeod@windriver.com>
	<20190614144853.25839-5-Randy.MacLeod@windriver.com>
	<98784449-a7d4-1015-2918-600e9c6f2c1c@windriver.com>
	<CA+_AqisMBmPaNy7xyt1+9c73RnMcChugCcxz6Bb4cBOCHG=-kQ@mail.gmail.com>
	<ffe4bdfd-5a89-1c4f-87cf-dbd27b3025e5@windriver.com>
Message-ID: <CA+_AqivqnMwATHRKUo5ETpG8=udieiX9C2Ef3U9Xjt85ra8ROQ@mail.gmail.com>

On Wed, 26 Jun 2019 at 10:56, Randy MacLeod <randy.macleod at windriver.com>
wrote:

> On 6/25/19 9:51 PM, Anibal Limon wrote:
> >
> >
> > On Wed, 19 Jun 2019 at 12:50, Randy MacLeod <randy.macleod at windriver.com
> > <mailto:randy.macleod at windriver.com>> wrote:
> >
> >     On 6/14/19 10:48 AM, Randy MacLeod wrote:
> >      > When running the run-execscript bash ptest as a user rather than
> >     root, a warning:
> >      >    bash: cannot set terminal process group (16036): Inappropriate
> >     ioctl for device
> >      >    bash: no job control in this shell
> >      > contaminates the bash log files causing the test to fail. This
> >     happens only
> >      > when run under ptest-runner and not when interactively testing!
> >      >
> >      > The changes made to fix this include:
> >      > 1. Get the process group id (pgid) before forking,
> >      > 2. Set the pgid in both the parent and child to avoid a race,
> >      > 3. Find, open and set permission on the child tty, and
> >      > 4. Allow the child to attach to controlling tty.
> >      >
> >      > Also add '-lutil' to Makefile. This lib is from libc and provides
> >     openpty.
> >
> >
> >     Hmmm, I was making the code compile cleanly under clang using
> >         -Weverything
> >     when I noticed:
> >
> >     1. the 'make check' tests. They still work fine.
> >     2. The './ptest-runner -d tests/data -t 1' tests
> >          which now generate loads of error like:
> >           ERROR: Unable to detach from controlling tty, Inappropriate
> ioctl
> >     for device
> >
> >     so while this change fixed the bash-ptest, the ptest-runner self-test
> >     it did something wrong.... Ah, I'm calling:
> >          ioctl(0, TIOCNOTTY) == -1)
> >     repeatedly in the parent so that's what's generating the extra logs.
> >     Fixed locally and I'll send a patch but it's not urgent. Phew! :)
> >
> >     Anibal,
> >
> >     If you could reply to explain your plans for Richard's patches
> >     that would help me figure out when to send the clang warning
> clean-ups
> >     commits and what commit to base my work on.
> >
> >
> > Hi,
> >
> > I plan to take the Richard patches, He added in the recipe to have real
> > testing and looks like
> > there aren't problems related to, Richard can you confirm it?,
> >
> > Regarding the openpty include, I see some linkage problem when running
> > make check, proposed fix:
>
> Yes, I had noticed that and fixed it as well.
>
> I'll send my latest patch series once you have merged
> Richard's changes into master. Hopefully that will be today... :)
>

I just merged the changes,

Thanks,
Anibal


>
> I decided to compile with:
>    clang -Weverything
> to see if there were any problems and there
> were quite a few things to fix. Now, for the most part,
> neither clang nor gcc complain about the code.
>
> ../Randy
>
> >
> > ...
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -22,19 +22,20 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c
> > tests/utils.c $(BASE_SOURCES)
> >   TEST_OBJECTS=$(TEST_SOURCES:.c=.o)
> >   TEST_EXECUTABLE=ptest-runner-test
> >   TEST_LDFLAGS=-lm -lrt -lpthread
> > -TEST_LIBSTATIC=-lcheck -lsubunit
> > +TEST_LIBSTATIC=-lutil
> > +TEST_LIBSTATIC_TEST=$(TEST_LIBSTATIC) -lcheck -lsubunit
> >
> >   TEST_DATA=$(shell echo `pwd`/tests/data)
> >
> >   all: $(SOURCES) $(EXECUTABLE)
> >
> >   $(EXECUTABLE): $(OBJECTS)
> > -       $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
> > +       $(CC) $(LDFLAGS) $(OBJECTS) -o $@ $(TEST_LIBSTATIC)
> >
> >   tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
> >
> >   $(TEST_EXECUTABLE): $(TEST_OBJECTS)
> > -       $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@
> > $(TEST_LIBSTATIC)
> > +       $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@
> > $(TEST_LIBSTATIC_TEST)
> >
> >   check: $(TEST_EXECUTABLE)
> >          ./$(TEST_EXECUTABLE) -d $(TEST_DATA)
> > ...
> >
> > Best regards,
> > Anibal
> >
> >
> >
> >     ../Randy
> >
> >      >
> >      > Signed-off-by: Sakib Sajal <sakib.sajal at windriver.com
> >     <mailto:sakib.sajal at windriver.com>>
> >      > Signed-off-by: Randy MacLeod <Randy.MacLeod at windriver.com
> >     <mailto:Randy.MacLeod at windriver.com>>
> >      > ---
> >      >   Makefile |   2 +-
> >      >   utils.c  | 102
> >     +++++++++++++++++++++++++++++++++++++++++++++++++------
> >      >   2 files changed, 92 insertions(+), 12 deletions(-)
> >      >
> >      > diff --git a/Makefile b/Makefile
> >      > index 1bde7be..439eb79 100644
> >      > --- a/Makefile
> >      > +++ b/Makefile
> >      > @@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
> >      >   all: $(SOURCES) $(EXECUTABLE)
> >      >
> >      >   $(EXECUTABLE): $(OBJECTS)
> >      > -     $(CC) $(LDFLAGS) $(OBJECTS) -o $@
> >      > +     $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
> >      >
> >      >   tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
> >      >
> >      > diff --git a/utils.c b/utils.c
> >      > index ad737c2..f11ce39 100644
> >      > --- a/utils.c
> >      > +++ b/utils.c
> >      > @@ -1,5 +1,6 @@
> >      >   /**
> >      >    * Copyright (c) 2016 Intel Corporation
> >      > + * Copyright (C) 2019 Wind River Systems, Inc.
> >      >    *
> >      >    * This program is free software; you can redistribute it and/or
> >      >    * modify it under the terms of the GNU General Public License
> >      > @@ -22,23 +23,27 @@
> >      >    */
> >      >
> >      >   #define _GNU_SOURCE
> >      > +
> >      >   #include <stdio.h>
> >      >
> >      > +#include <dirent.h>
> >      > +#include <errno.h>
> >      > +#include <fcntl.h>
> >      > +#include <grp.h>
> >      >   #include <libgen.h>
> >      > -#include <signal.h>
> >      >   #include <poll.h>
> >      > -#include <fcntl.h>
> >      > +#include <pty.h>
> >      > +#include <signal.h>
> >      > +#include <stdlib.h>
> >      > +#include <string.h>
> >      >   #include <time.h>
> >      > -#include <dirent.h>
> >      > +#include <unistd.h>
> >      > +
> >      > +#include <sys/ioctl.h>
> >      >   #include <sys/resource.h>
> >      > +#include <sys/stat.h>
> >      >   #include <sys/types.h>
> >      >   #include <sys/wait.h>
> >      > -#include <sys/stat.h>
> >      > -#include <unistd.h>
> >      > -#include <string.h>
> >      > -#include <stdlib.h>
> >      > -
> >      > -#include <errno.h>
> >      >
> >      >   #include "ptest_list.h"
> >      >   #include "utils.h"
> >      > @@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char
> >     *run_ptest, pid_t pid,
> >      >       return status;
> >      >   }
> >      >
> >      > +/* Returns an integer file descriptor.
> >      > + * If it returns < 0, an error has occurred.
> >      > + * Otherwise, it has returned the slave pty file descriptor.
> >      > + * fp should be writable, likely stdout/err.
> >      > + */
> >      > +static int
> >      > +setup_slave_pty(FILE *fp) {
> >      > +     int pty_master = -1;
> >      > +     int pty_slave = -1;
> >      > +     char pty_name[256];
> >      > +     struct group *gptr;
> >      > +     gid_t gid;
> >      > +     int slave = -1;
> >      > +
> >      > +     if (openpty(&pty_master, &pty_slave, pty_name, NULL, NULL)
> >     < 0) {
> >      > +             fprintf(fp, "ERROR: openpty() failed with: %s.\n",
> >     strerror(errno));
> >      > +             return -1;
> >      > +     }
> >      > +
> >      > +     if ((gptr = getgrnam(pty_name)) != 0) {
> >      > +             gid = gptr->gr_gid;
> >      > +     } else {
> >      > +             /* If the tty group does not exist, don't change the
> >      > +              * group on the slave pty, only the owner
> >      > +              */
> >      > +             gid = -1;
> >      > +     }
> >      > +
> >      > +     /* chown/chmod the corresponding pty, if possible.
> >      > +      * This will only work if the process has root permissions.
> >      > +      */
> >      > +     if (chown(pty_name, getuid(), gid) != 0) {
> >      > +             fprintf(fp, "ERROR; chown() failed with: %s.\n",
> >     strerror(errno));
> >      > +     }
> >      > +
> >      > +     /* Makes the slave read/writeable for the user. */
> >      > +     if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
> >      > +             fprintf(fp, "ERROR: chmod() failed with: %s.\n",
> >     strerror(errno));
> >      > +     }
> >      > +
> >      > +     if ((slave = open(pty_name, O_RDWR)) == -1) {
> >      > +             fprintf(fp, "ERROR: open() failed with: %s.\n",
> >     strerror(errno));
> >      > +     }
> >      > +     return (slave);
> >      > +}
> >      > +
> >      > +
> >      >   int
> >      >   run_ptests(struct ptest_list *head, const struct ptest_options
> >     opts,
> >      >               const char *progname, FILE *fp, FILE *fp_stderr)
> >      > @@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const
> >     struct ptest_options opts,
> >      >       int timeouted;
> >      >       time_t sttime, entime;
> >      >       int duration;
> >      > +     int slave;
> >      > +     int pgid = -1;
> >      >
> >      >       if (opts.xml_filename) {
> >      >               xh = xml_create(ptest_list_length(head),
> >     opts.xml_filename);
> >      > @@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const
> >     struct ptest_options opts,
> >      >                       close(pipefd_stdout[1]);
> >      >                       break;
> >      >               }
> >      > -
> >      >               fprintf(fp, "START: %s\n", progname);
> >      >               PTEST_LIST_ITERATE_START(head, p);
> >      >                       char *ptest_dir = strdup(p->run_ptest);
> >      > @@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const
> >     struct ptest_options opts,
> >      >                               break;
> >      >                       }
> >      >                       dirname(ptest_dir);
> >      > +                     if (ioctl(0, TIOCNOTTY) == -1) {
> >      > +                             fprintf(fp, "ERROR: Unable to
> >     detach from controlling tty, %s\n", strerror(errno));
> >      > +                     }
> >      > +
> >      > +                     if ((pgid = getpgid(0)) == -1) {
> >      > +                             fprintf(fp, "ERROR: getpgid()
> >     failed, %s\n", strerror(errno));
> >      > +                     }
> >      >
> >      >                       child = fork();
> >      >                       if (child == -1) {
> >      > @@ -395,13 +455,33 @@ run_ptests(struct ptest_list *head, const
> >     struct ptest_options opts,
> >      >                               rc = -1;
> >      >                               break;
> >      >                       } else if (child == 0) {
> >      > -                             setsid();
> >      > +                             close(0);
> >      > +                             if ((slave = setup_slave_pty(fp)) <
> >     0) {
> >      > +                                     fprintf(fp, "ERROR: could
> >     not setup pty (%d).", slave);
> >      > +                             }
> >      > +                             if (setpgid(0,pgid) == -1) {
> >      > +                                     fprintf(fp, "ERROR:
> >     setpgid() failed, %s\n", strerror(errno));
> >      > +                             }
> >      > +
> >      > +                             if (setsid() ==  -1) {
> >      > +                                     fprintf(fp, "ERROR:
> >     setsid() failed, %s\n", strerror(errno));
> >      > +                             }
> >      > +
> >      > +                             if (ioctl(0, TIOCSCTTY, NULL) ==
> -1) {
> >      > +                                     fprintf(fp, "ERROR: Unable
> >     to attach to controlling tty, %s\n", strerror(errno));
> >      > +                             }
> >      > +
> >      >                               run_child(p->run_ptest,
> >     pipefd_stdout[1], pipefd_stderr[1]);
> >      > +
> >      >                       } else {
> >      >                               int status;
> >      >                               int fds[2]; fds[0] =
> >     pipefd_stdout[0]; fds[1] = pipefd_stderr[0];
> >      >                               FILE *fps[2]; fps[0] = fp; fps[1] =
> >     fp_stderr;
> >      >
> >      > +                             if (setpgid(child, pgid) == -1) {
> >      > +                                     fprintf(fp, "ERROR:
> >     setpgid() failed, %s\n", strerror(errno));
> >      > +                             }
> >      > +
> >      >                               sttime = time(NULL);
> >      >                               fprintf(fp, "%s\n",
> >     get_stime(stime, GET_STIME_BUF_SIZE, sttime));
> >      >                               fprintf(fp, "BEGIN: %s\n",
> ptest_dir);
> >      >
> >
> >
> >     --
> >     # Randy MacLeod
> >     # Wind River Linux
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/f333fc1c/attachment-0001.html>

From JMcCabe at kirintec.com  Thu Jun 27 09:53:33 2019
From: JMcCabe at kirintec.com (John McCabe)
Date: Thu, 27 Jun 2019 16:53:33 +0000
Subject: [yocto] Recursions problem with pre-built versioned libraries and
 oe_soinstall
Message-ID: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>

Hi,

(Sorry for the long post, but....)

I'm new to Yocto etc and I'm struggling with configuring a recipe to install some library files that I've built. The libraries in question are part of OpenDDS, which I've cross-compiled for a Zynq-7000 target. At this point I don't want to include the build of the libraries in the Yocto (actually PetaLinux) configuration as it takes hours to build, so I just want to add the shared libraries that are needed into the image. However I haven't managed to get this to work in hours, if not days, of trying. Despite multiple attempts at an opendds.bb file, I continue to get issues with:

===
Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'
===

Essentially there are a set of binaries and a set of shared libraries that I want to go into the image. If you look at the current version of the opendds.bb file I'm using, below, you should see a list of the files in question.

===
#
# This file is the OpenDDS libraries recipe.
#

SUMMARY = "OpenDDS Libraries"
SECTION = "PETALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI = "file://DCPSInfoRepo \
	file://tao_cosnaming \
	file://tao_imr \
	file://tao_imr_activator \
	file://tao_imr_locator \
	file://tao_nsadd \
	file://tao_nsdel \
	file://tao_nslist \
	file://libACE.so.6.2a_p15 \
	file://libACEXML.so.6.2a_p15 \
	file://libACEXML_Parser.so.6.2a_p15 \
	file://libOpenDDS_Dcps.so.3.13.2 \
	file://libOpenDDS_FACE.so.3.13.2 \
	file://libOpenDDS_Federator.so.3.13.2 \
	file://libOpenDDS_InfoRepoDiscovery.so.3.13.2 \
	file://libOpenDDS_InfoRepoLib.so.3.13.2 \
	file://libOpenDDS_InfoRepoServ.so.3.13.2 \
	file://libOpenDDS_Model.so.3.13.2 \
	file://libOpenDDS_Multicast.so.3.13.2 \
	file://libOpenDDS_Rtps.so.3.13.2 \
	file://libOpenDDS_Rtps_Udp.so.3.13.2 \
	file://libOpenDDS_Shmem.so.3.13.2 \
	file://libOpenDDS_Tcp.so.3.13.2 \
	file://libOpenDDS_Udp.so.3.13.2 \
	file://libOpenDDS_monitor.so.3.13.2 \
	file://libTAO.so.2.2a_p15 \
	file://libTAO_AnyTypeCode.so.2.2a_p15 \
	file://libTAO_Async_IORTable.so.2.2a_p15 \
	file://libTAO_Async_ImR_Client_IDL.so.2.2a_p15 \
	file://libTAO_BiDirGIOP.so.2.2a_p15 \
	file://libTAO_CSD_Framework.so.2.2a_p15 \
	file://libTAO_CSD_ThreadPool.so.2.2a_p15 \
	file://libTAO_CodecFactory.so.2.2a_p15 \
	file://libTAO_Codeset.so.2.2a_p15 \
	file://libTAO_CosNaming.so.2.2a_p15 \
	file://libTAO_CosNaming_Serv.so.2.2a_p15 \
	file://libTAO_CosNaming_Skel.so.2.2a_p15 \
	file://libTAO_DynamicInterface.so.2.2a_p15 \
	file://libTAO_FTORB_Utils.so.2.2a_p15 \
	file://libTAO_FT_ClientORB.so.2.2a_p15 \
	file://libTAO_FT_ServerORB.so.2.2a_p15 \
	file://libTAO_IDL_FE.so.2.2a_p15 \
	file://libTAO_IORManip.so.2.2a_p15 \
	file://libTAO_IORTable.so.2.2a_p15 \
	file://libTAO_ImR_Activator.so.2.2a_p15 \
	file://libTAO_ImR_Activator_IDL.so.2.2a_p15 \
	file://libTAO_ImR_Client.so.2.2a_p15 \
	file://libTAO_ImR_Locator.so.2.2a_p15 \
	file://libTAO_ImR_Locator_IDL.so.2.2a_p15 \
	file://libTAO_Messaging.so.2.2a_p15 \
	file://libTAO_PI.so.2.2a_p15 \
	file://libTAO_PI_Server.so.2.2a_p15 \
	file://libTAO_PortableGroup.so.2.2a_p15 \
	file://libTAO_PortableServer.so.2.2a_p15 \
	file://libTAO_Strategies.so.2.2a_p15 \
	file://libTAO_Svc_Utils.so.2.2a_p15 \
	file://libTAO_Valuetype.so.2.2a_p15 \
        "

S = "${WORKDIR}"

do_install() {
	     install -d ${D}${bindir}
	     install -d ${D}${libdir}
	     install -m 0755 DCPSInfoRepo ${D}${bindir}
	     install -m 0755 tao_cosnaming ${D}${bindir}
	     install -m 0755 tao_imr ${D}${bindir}
	     install -m 0755 tao_imr_activator ${D}${bindir}
	     install -m 0755 tao_imr_locator ${D}${bindir}
	     install -m 0755 tao_nsadd ${D}${bindir}
	     install -m 0755 tao_nsdel ${D}${bindir}
	     install -m 0755 tao_nslist ${D}${bindir}
	     oe_soinstall libACE.so.6.2a_p15 ${D}${libdir}
	     oe_soinstall libACEXML.so.6.2a_p15 ${D}${libdir}
	     oe_soinstall libACEXML_Parser.so.6.2a_p15 ${D}${libdir}
	     oe_soinstall libOpenDDS_Dcps.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_FACE.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Federator.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_InfoRepoDiscovery.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_InfoRepoLib.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_InfoRepoServ.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Model.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Multicast.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Rtps.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Rtps_Udp.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Shmem.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Tcp.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_Udp.so.3.13.2 ${D}${libdir}
	     oe_soinstall libOpenDDS_monitor.so.3.13.2 ${D}${libdir}
	     oe_soinstall libTAO.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_AnyTypeCode.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Async_IORTable.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Async_ImR_Client_IDL.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_BiDirGIOP.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_CSD_Framework.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_CSD_ThreadPool.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_CodecFactory.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Codeset.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_CosNaming.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_CosNaming_Serv.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_CosNaming_Skel.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_DynamicInterface.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_FTORB_Utils.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_FT_ClientORB.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_FT_ServerORB.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_IDL_FE.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_IORManip.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_IORTable.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_ImR_Activator.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_ImR_Activator_IDL.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_ImR_Client.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_ImR_Locator.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_ImR_Locator_IDL.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Messaging.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_PI.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_PI_Server.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_PortableGroup.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_PortableServer.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Strategies.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Svc_Utils.so.2.2a_p15 ${D}${libdir}
	     oe_soinstall libTAO_Valuetype.so.2.2a_p15 ${D}${libdir}
}

# Don't bother trying to build the debug package, at least for now!
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_SYSROOT_STRIP = "1"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"

# Inhibit warnings about files being stripped
INSANE_SKIP_${PN} = "ldflags"
INSANE_SKIP_${PN} = "already-stripped"

# No .h files to be packaged, so only list .so stuff
FILES_${PN} = "${bindir}/* ${libdir}/*.so.*"
FILES_${PN}-dev = "${bindir}/* ${libdir}/*.so"
===

The files were all built in another folder but I've copied them into the project-spec/meta-user/recipes-apps/opendds/files folder so that they can be picked up ok. I uses the normal install to do the binaries, and oe_soinstall to work with the versioned shared libraries, as described in various places.

I added a print statement into package.bbclass at line 1233 (see below) to try to get a bit more information into the log file about the point where it's breaking). The log then shows this below (I presume that the stderr output being in the middle of that lot is just some sequencing effect):

===
DEBUG: Executing python function package_fixsymlinks
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Svc_Utils.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ClientORB.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_Framework.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps_Udp.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_ImR_Client_IDL.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_DynamicInterface.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_AnyTypeCode.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Tcp.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator_IDL.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoDiscovery.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoLib.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Valuetype.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_BiDirGIOP.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Messaging.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORManip.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Serv.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableServer.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_IORTable.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IDL_FE.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML_Parser.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_monitor.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Multicast.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI_Server.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Strategies.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Federator.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Shmem.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Model.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CodecFactory.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ServerORB.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACE.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Dcps.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORTable.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Skel.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator_IDL.so, pkg: opendds-devERROR: 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: <module>
     0001:
 *** 0002:package_fixsymlinks(d)
     0003:
File: '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/classes/package.bbclass', lineno: 1236, function: package_fixsymlinks
     1232:        for path in pkgfiles[pkg]:
     1233:                print('path: %s, pkg: %s' % (path, pkg))
     1234:                rpath = path[len(inst_root):]
     1235:                pkg_files[pkg].append(rpath)
 *** 1236:                rtarget = cpath.realpath(path, inst_root, True, assume_dir = True)
     1237:                if not cpath.lexists(rtarget):
     1238:                    dangling_links[pkg].append(os.path.normpath(rtarget[len(inst_root):]))
     1239:
     1240:    newrdepends = {}
File: '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/lib/oe/cachedpath.py', lineno: 229, function: realpath
     0225:                # be printed a backtrace with 100s of OSError exceptions
     0226:                # else
     0227:                raise OSError(errno.ELOOP,
     0228:                              "too much recursions while resolving '%s'; loop in '%s'" %
 *** 0229:                              (file, e.strerror))
     0230:
     0231:            raise
     0232:
     0233:        return file
Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'

DEBUG: Python function package_fixsymlinks finished
DEBUG: Python function do_package finished
ERROR: Function failed: package_fixsymlinks

path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoServ.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_ThreadPool.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FTORB_Utils.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableGroup.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Client.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_FACE.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Codeset.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Udp.so, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_locator, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_cosnaming, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsdel, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsadd, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nslist, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_activator, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/DCPSInfoRepo, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr, pkg: opendds-dev
path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15, pkg: opendds
===

In addition, I get a batch of the following messages coming out:

===
1: opendds-1.0-r0 do_package - 0s (pid 23258)
link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_Svc_Utils.so.2.2a_p15'.
link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI_Server.so.2.2a_p15'.
link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI.so.2.2a_p15'.
===

And, when I go into the lib folder and list the contents, I see:

===
:
lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so -> libTAO_PI_Server.so.2.2a_p15
lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15 -> libTAO_PI_Server.so.2.2a_p15
:
===

With (on Ubuntu), all the filenames in red with a grey (or black?) background, i.e. broken links.

I have a couple of questions about all this:

1) The oe_soinstall function (see here - https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/utils.bbclass)  includes a line that installs (using "install") the xxx.so.x.y file, which causes a copy of the file from ${WORKDIR} to go into the <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi.opendds/1.0-r0/image/usr/lib directory. It then generates sonamelink and solink from the library details and creates symbolic links that point back to the copies of the library files in ${WORKDIR}. In doing that, the copy of the file that was placed there by the install line is overwritten with the symbolic link; is that normal? (I presume it must be otherwise no one would be getting oe_soinstall to work!).

2) Is there anything in the shared library filenames' version part that could be causing something to get confused? I've seen mention of zzz.so.a.b.c etc where a, b and c are normally numeric, which is different to the version information in the DDS files, but...

3) I can understand why there could be a recursion issue detected, but it's not met who's putting those weird links into the package/usr/lib folder. Is there something in the .bb file that I need to change to make that work properly?

4) Can anyone see whether I'm just simply doing something wrong and clarify what I need to do to put it right?

Any help will be very, very gratefully appreciated. As I said, I'm new to Yocto and have spent hours looking for help/example of the use of oe_soinstall. Each time round the loop of updating my .bb file and building it takes quite a long time so...

Many thanks,
John

John McCabe
Principal Software Engineer
Kirintec Ltd
  
+44 (0) 1989 568350
  
JMcCabe at kirintec.com
  
www.kirintec.com
Follow us: 

?
?

Receipt of this e-mail is subject to conditions, view our email disclaimer. Kirintec Limited of Ross-on-Wye HR9 5PB is ?registered in England and Wales with the company number 6699502. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image584022.png
Type: image/png
Size: 10433 bytes
Desc: image584022.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image743201.png
Type: image/png
Size: 341 bytes
Desc: image743201.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image289906.png
Type: image/png
Size: 370 bytes
Desc: image289906.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image885432.png
Type: image/png
Size: 490 bytes
Desc: image885432.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image679662.png
Type: image/png
Size: 641 bytes
Desc: image679662.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image231032.png
Type: image/png
Size: 642 bytes
Desc: image231032.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image469003.png
Type: image/png
Size: 675 bytes
Desc: image469003.png
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image018193.jpg
Type: image/jpeg
Size: 85123 bytes
Desc: image018193.jpg
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190627/8322bfbb/attachment-0001.jpg>

From moritz.porst at gmx.de  Fri Jun 28 02:21:31 2019
From: moritz.porst at gmx.de (Moritz Porst)
Date: Fri, 28 Jun 2019 11:21:31 +0200
Subject: [yocto] Can't boot to initramfs
Message-ID: <89d3d916-1fca-5ff5-e68e-79370dd0bfb7@gmx.de>

Hello,
I currently try to deploy a single rootfs update mechanism for my
embedded device. I can't boot to initramfs using either "break" or
"break=premount" (without quotes...). I tried this in systemd-boot and
grub-efi (always efi boot) but the boot process just continues normally.
If I insert at the same point e.g. "quiet" this argument is recognised.
I boot the .wic image with a separate boot partition from a USB stick.
in local.conf I have set:
INITRAMFS_IMAGE = "core-image-minimal-initramfs"
INITRAMFS_IMAGE_BUNDLE = "1"

In order to reduce complexity I now use the standard
core-image-minimal-initramfs without .bbappend. I can confirm (from
seeing the task) that bitbake bundled the kernel with the initramfs.

You can find the /var/log/dmesg here: https://pastebin.com/ya7iCtq7

To my understanding the initramfs should be embedded in /boot/bzImage.
However since I use an intel platform I also have a /boot/microcode.cpio
which gets loaded via "initrd /microcode.cpio". Removing this line in
grub does not enable me to get an initramfs prompt either (again, using
break as option).

Did I forget some configuration or do I have to put the break statement
at a very specific position within the "linux ..." boot command ? Do you
know which bitbake variables to check ? (both set in local.conf do not
get overwritten, already checked this). I got the thud branch checked
out in all my meta-layers except for meta-qt which is currently on
master branch.

Help is much appreciated !

Best regards
Moritz


From gabbla.malist at gmail.com  Fri Jun 28 02:25:10 2019
From: gabbla.malist at gmail.com (Gabriele Zampieri)
Date: Fri, 28 Jun 2019 11:25:10 +0200
Subject: [yocto] Getting a package PV from another
Message-ID: <CAAx3WaCCs+z5ctCrmM25YHh84S2L9y+E85KnuDvKNNFqe304Uw@mail.gmail.com>

Hi all,

is there a way to get a specific package version from another?

Best regards,
Gabriele
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/4bd04a80/attachment.html>

From Qi.Chen at windriver.com  Fri Jun 28 02:47:25 2019
From: Qi.Chen at windriver.com (ChenQi)
Date: Fri, 28 Jun 2019 17:47:25 +0800
Subject: [yocto] Recursions problem with pre-built versioned libraries
 and oe_soinstall
In-Reply-To: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
References: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <784d3708-806e-04f5-55be-0775989d2f16@windriver.com>

Hi John,

When you have problems regarding yocto, please send email to this 
mailing list.

Regards,
Chen Qi

On 06/28/2019 12:53 AM, John McCabe wrote:
> Hi,
>
> (Sorry for the long post, but....)
>
> I'm new to Yocto etc and I'm struggling with configuring a recipe to 
> install some library files that I've built. The libraries in question 
> are part of OpenDDS, which I've cross-compiled for a Zynq-7000 target. 
> At this point I don't want to include the build of the libraries in 
> the Yocto (actually PetaLinux) configuration as it takes hours to 
> build, so I just want to add the shared libraries that are needed into 
> the image. However I haven't managed to get this to work in hours, if 
> not days, of trying. Despite multiple attempts at an opendds.bb file, 
> I continue to get issues with:
>
> ===
> Exception: OSError: [Errno 40] too much recursions while resolving 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; 
> loop in 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'
> ===
>
> Essentially there are a set of binaries and a set of shared libraries 
> that I want to go into the image. If you look at the current version 
> of the opendds.bb file I'm using, below, you should see a list of the 
> files in question.
>
> ===
> #
> # This file is the OpenDDS libraries recipe.
> #
>
> SUMMARY = "OpenDDS Libraries"
> SECTION = "PETALINUX/apps"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM = 
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> SRC_URI = "file://DCPSInfoRepo \
> file://tao_cosnaming \
> file://tao_imr \
> file://tao_imr_activator \
> file://tao_imr_locator \
> file://tao_nsadd \
> file://tao_nsdel \
> file://tao_nslist \
> file://libACE.so.6.2a_p15 \
> file://libACEXML.so.6.2a_p15 \
> file://libACEXML_Parser.so.6.2a_p15 \
> file://libOpenDDS_Dcps.so.3.13.2 \
> file://libOpenDDS_FACE.so.3.13.2 \
> file://libOpenDDS_Federator.so.3.13.2 \
> file://libOpenDDS_InfoRepoDiscovery.so.3.13.2 \
> file://libOpenDDS_InfoRepoLib.so.3.13.2 \
> file://libOpenDDS_InfoRepoServ.so.3.13.2 \
> file://libOpenDDS_Model.so.3.13.2 \
> file://libOpenDDS_Multicast.so.3.13.2 \
> file://libOpenDDS_Rtps.so.3.13.2 \
> file://libOpenDDS_Rtps_Udp.so.3.13.2 \
> file://libOpenDDS_Shmem.so.3.13.2 \
> file://libOpenDDS_Tcp.so.3.13.2 \
> file://libOpenDDS_Udp.so.3.13.2 \
> file://libOpenDDS_monitor.so.3.13.2 \
> file://libTAO.so.2.2a_p15 \
> file://libTAO_AnyTypeCode.so.2.2a_p15 \
> file://libTAO_Async_IORTable.so.2.2a_p15 \
> file://libTAO_Async_ImR_Client_IDL.so.2.2a_p15 \
> file://libTAO_BiDirGIOP.so.2.2a_p15 \
> file://libTAO_CSD_Framework.so.2.2a_p15 \
> file://libTAO_CSD_ThreadPool.so.2.2a_p15 \
> file://libTAO_CodecFactory.so.2.2a_p15 \
> file://libTAO_Codeset.so.2.2a_p15 \
> file://libTAO_CosNaming.so.2.2a_p15 \
> file://libTAO_CosNaming_Serv.so.2.2a_p15 \
> file://libTAO_CosNaming_Skel.so.2.2a_p15 \
> file://libTAO_DynamicInterface.so.2.2a_p15 \
> file://libTAO_FTORB_Utils.so.2.2a_p15 \
> file://libTAO_FT_ClientORB.so.2.2a_p15 \
> file://libTAO_FT_ServerORB.so.2.2a_p15 \
> file://libTAO_IDL_FE.so.2.2a_p15 \
> file://libTAO_IORManip.so.2.2a_p15 \
> file://libTAO_IORTable.so.2.2a_p15 \
> file://libTAO_ImR_Activator.so.2.2a_p15 \
> file://libTAO_ImR_Activator_IDL.so.2.2a_p15 \
> file://libTAO_ImR_Client.so.2.2a_p15 \
> file://libTAO_ImR_Locator.so.2.2a_p15 \
> file://libTAO_ImR_Locator_IDL.so.2.2a_p15 \
> file://libTAO_Messaging.so.2.2a_p15 \
> file://libTAO_PI.so.2.2a_p15 \
> file://libTAO_PI_Server.so.2.2a_p15 \
> file://libTAO_PortableGroup.so.2.2a_p15 \
> file://libTAO_PortableServer.so.2.2a_p15 \
> file://libTAO_Strategies.so.2.2a_p15 \
> file://libTAO_Svc_Utils.so.2.2a_p15 \
> file://libTAO_Valuetype.so.2.2a_p15 \
> "
>
> S = "${WORKDIR}"
>
> do_install() {
> install -d ${D}${bindir}
> install -d ${D}${libdir}
> install -m 0755 DCPSInfoRepo ${D}${bindir}
> install -m 0755 tao_cosnaming ${D}${bindir}
> install -m 0755 tao_imr ${D}${bindir}
> install -m 0755 tao_imr_activator ${D}${bindir}
> install -m 0755 tao_imr_locator ${D}${bindir}
> install -m 0755 tao_nsadd ${D}${bindir}
> install -m 0755 tao_nsdel ${D}${bindir}
> install -m 0755 tao_nslist ${D}${bindir}
> oe_soinstall libACE.so.6.2a_p15 ${D}${libdir}
> oe_soinstall libACEXML.so.6.2a_p15 ${D}${libdir}
> oe_soinstall libACEXML_Parser.so.6.2a_p15 ${D}${libdir}
> oe_soinstall libOpenDDS_Dcps.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_FACE.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Federator.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_InfoRepoDiscovery.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_InfoRepoLib.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_InfoRepoServ.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Model.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Multicast.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Rtps.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Rtps_Udp.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Shmem.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Tcp.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_Udp.so.3.13.2 ${D}${libdir}
> oe_soinstall libOpenDDS_monitor.so.3.13.2 ${D}${libdir}
> oe_soinstall libTAO.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_AnyTypeCode.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Async_IORTable.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Async_ImR_Client_IDL.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_BiDirGIOP.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_CSD_Framework.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_CSD_ThreadPool.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_CodecFactory.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Codeset.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_CosNaming.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_CosNaming_Serv.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_CosNaming_Skel.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_DynamicInterface.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_FTORB_Utils.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_FT_ClientORB.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_FT_ServerORB.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_IDL_FE.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_IORManip.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_IORTable.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_ImR_Activator.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_ImR_Activator_IDL.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_ImR_Client.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_ImR_Locator.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_ImR_Locator_IDL.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Messaging.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_PI.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_PI_Server.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_PortableGroup.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_PortableServer.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Strategies.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Svc_Utils.so.2.2a_p15 ${D}${libdir}
> oe_soinstall libTAO_Valuetype.so.2.2a_p15 ${D}${libdir}
> }
>
> # Don't bother trying to build the debug package, at least for now!
> INHIBIT_PACKAGE_STRIP = "1"
> INHIBIT_SYSROOT_STRIP = "1"
> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
>
> # Inhibit warnings about files being stripped
> INSANE_SKIP_${PN} = "ldflags"
> INSANE_SKIP_${PN} = "already-stripped"
>
> # No .h files to be packaged, so only list .so stuff
> FILES_${PN} = "${bindir}/* ${libdir}/*.so.*"
> FILES_${PN}-dev = "${bindir}/* ${libdir}/*.so"
> ===
>
> The files were all built in another folder but I've copied them into 
> the project-spec/meta-user/recipes-apps/opendds/files folder so that 
> they can be picked up ok. I uses the normal install to do the 
> binaries, and oe_soinstall to work with the versioned shared 
> libraries, as described in various places.
>
> I added a print statement into package.bbclass at line 1233 (see 
> below) to try to get a bit more information into the log file about 
> the point where it's breaking). The log then shows this below (I 
> presume that the stderr output being in the middle of that lot is just 
> some sequencing effect):
>
> ===
> DEBUG: Executing python function package_fixsymlinks
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Svc_Utils.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ClientORB.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_Framework.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps_Udp.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_ImR_Client_IDL.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_DynamicInterface.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_AnyTypeCode.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Tcp.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator_IDL.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoDiscovery.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoLib.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Valuetype.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_BiDirGIOP.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Messaging.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORManip.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Serv.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableServer.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_IORTable.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IDL_FE.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML_Parser.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_monitor.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Multicast.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI_Server.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Strategies.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Federator.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Shmem.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Model.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CodecFactory.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ServerORB.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACE.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Dcps.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORTable.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Skel.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator_IDL.so, 
> pkg: opendds-devERROR: 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: <module>
> 0001:
> *** 0002:package_fixsymlinks(d)
> 0003:
> File: 
> '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/classes/package.bbclass', 
> lineno: 1236, function: package_fixsymlinks
> 1232: for path in pkgfiles[pkg]:
> 1233: print('path: %s, pkg: %s' % (path, pkg))
> 1234: rpath = path[len(inst_root):]
> 1235: pkg_files[pkg].append(rpath)
> *** 1236: rtarget = cpath.realpath(path, inst_root, True, assume_dir = 
> True)
> 1237: if not cpath.lexists(rtarget):
> 1238: 
> dangling_links[pkg].append(os.path.normpath(rtarget[len(inst_root):]))
> 1239:
> 1240: newrdepends = {}
> File: 
> '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/lib/oe/cachedpath.py', 
> lineno: 229, function: realpath
> 0225: # be printed a backtrace with 100s of OSError exceptions
> 0226: # else
> 0227: raise OSError(errno.ELOOP,
> 0228: "too much recursions while resolving '%s'; loop in '%s'" %
> *** 0229: (file, e.strerror))
> 0230:
> 0231: raise
> 0232:
> 0233: return file
> Exception: OSError: [Errno 40] too much recursions while resolving 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; 
> loop in 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'
>
> DEBUG: Python function package_fixsymlinks finished
> DEBUG: Python function do_package finished
> ERROR: Function failed: package_fixsymlinks
>
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoServ.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_ThreadPool.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FTORB_Utils.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableGroup.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Client.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_FACE.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Codeset.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Udp.so, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_locator, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_cosnaming, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsdel, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsadd, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nslist, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_activator, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/DCPSInfoRepo, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr, 
> pkg: opendds-dev
> path: 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15, 
> pkg: opendds
> ===
>
> In addition, I get a batch of the following messages coming out:
>
> ===
> 1: opendds-1.0-r0 do_package - 0s (pid 23258)
> link recursion too deep, not expanding path 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_Svc_Utils.so.2.2a_p15'.
> link recursion too deep, not expanding path 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI_Server.so.2.2a_p15'.
> link recursion too deep, not expanding path 
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI.so.2.2a_p15'.
> ===
>
> And, when I go into the lib folder and list the contents, I see:
>
> ===
> :
> lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so -> 
> libTAO_PI_Server.so.2.2a_p15
> lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 
> libTAO_PI_Server.so.2.2a_p15 -> libTAO_PI_Server.so.2.2a_p15
> :
> ===
>
> With (on Ubuntu), all the filenames in red with a grey (or black?) 
> background, i.e. broken links.
>
> I have a couple of questions about all this:
>
> 1) The oe_soinstall function (see here - 
> https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/utils.bbclass) 
> includes a line that installs (using "install") the xxx.so.x.y file, 
> which causes a copy of the file from ${WORKDIR} to go into the 
> <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi.opendds/1.0-r0/image/usr/lib 
> directory. It then generates sonamelink and solink from the library 
> details and creates symbolic links that point back to the copies of 
> the library files in ${WORKDIR}. In doing that, the copy of the file 
> that was placed there by the install line is overwritten with the 
> symbolic link; is that normal? (I presume it must be otherwise no one 
> would be getting oe_soinstall to work!).
>
> 2) Is there anything in the shared library filenames' version part 
> that could be causing something to get confused? I've seen mention of 
> zzz.so.a.b.c etc where a, b and c are normally numeric, which is 
> different to the version information in the DDS files, but...
>
> 3) I can understand why there could be a recursion issue detected, but 
> it's not met who's putting those weird links into the package/usr/lib 
> folder. Is there something in the .bb file that I need to change to 
> make that work properly?
>
> 4) Can anyone see whether I'm just simply doing something wrong and 
> clarify what I need to do to put it right?
>
> Any help will be very, very gratefully appreciated. As I said, I'm new 
> to Yocto and have spent hours looking for help/example of the use of 
> oe_soinstall. Each time round the loop of updating my .bb file and 
> building it takes quite a long time so...
>
> Many thanks,
> John
> 	
> John McCabe?
> Principal Software Engineer
> Kirintec Ltd
>
> 		
> 	
>
> 	+44 (0) 1989 568350
>
> 	
> 	
>
> 	*JMcCabe at kirintec.com* <mailto:JMcCabe at kirintec.com>
>
> 	
>
> 	*www.kirintec.com* <http://www.kirintec.com/>
>
> Follow us: 	
> <https://en-gb.facebook.com/Kirintec/>
>
> 	
> <https://uk.linkedin.com/company/kirintec>
>
> 	
> <https://twitter.com/KirintecLtd>
>
>
> ?
> ?
>
> <https://www.kirintec.com/>
> Receipt of this e-mail is subject to conditions, view our 
> email disclaimer. Kirintec Limited of Ross-on-Wye HR9 5PB 
> is ?registered in England and Wales with the company number 6699502.
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 10433 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 341 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 370 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 490 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 641 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 642 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 675 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 85123 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/b68db71d/attachment-0001.jpe>

From Qi.Chen at windriver.com  Fri Jun 28 02:49:56 2019
From: Qi.Chen at windriver.com (ChenQi)
Date: Fri, 28 Jun 2019 17:49:56 +0800
Subject: [yocto] [yocto-builds] Yocto build won't boot from HDD
In-Reply-To: <trinity-b095feb1-65bd-4db2-999a-3afe9a9f0428-1561451174816@3c-app-webde-bs02>
References: <trinity-b095feb1-65bd-4db2-999a-3afe9a9f0428-1561451174816@3c-app-webde-bs02>
Message-ID: <85e7a539-cefc-e96c-4dd3-51d288a16a01@windriver.com>

Forward to this yocto mailing list. Hope some experts could help you.
When you have problems regarding yocto, please send email to this 
mailing list.

Regards,
Chen Qi

On 06/25/2019 04:26 PM, a.silberhorn at web.de wrote:
> Hello everybody,
> Since im new to Yocto I ran into some problems trying to boot my 
> intel-corei7-64 core-image-minimal from HDD.
> I used dd to put it on the hard drive but while booting it stops with 
> a Kernel panic:
> Kernel panic - not syncing: VFS: Unable to moutn root fs on unkknown 
> block (0,0)
> I tried a lot and searched for a solution. First of all I had to do a 
> grub-install and configured the grub.cfg file in the boot partition to 
> list the Image in GRUB but I am not getting any further than that 
> point. In some forums they said its meaning that the initramfs is missing.
> I dont think that the image itself is broken because it works on a usb 
> flash drive.
> Could someone of you folks be so nice to help me out of this misery?
> Best regards
> Alex
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/f523c01e/attachment.html>

From Qi.Chen at windriver.com  Fri Jun 28 02:50:52 2019
From: Qi.Chen at windriver.com (ChenQi)
Date: Fri, 28 Jun 2019 17:50:52 +0800
Subject: [yocto] [yocto-builds] Yocto build Issue
In-Reply-To: <980292376.238401.1561633028960@email.ionos.com>
References: <980292376.238401.1561633028960@email.ionos.com>
Message-ID: <5239a45d-0756-6c85-9b2d-218b34d9168c@windriver.com>

Forward to this yocto mailing list.
When you have problems regarding yocto, use this mailing list.

Regards,
Chen Qi

On 06/27/2019 06:57 PM, Pawan Badganchi wrote:
>
> Hello sir,
>
>            I am adding IMAGE_INSTALL_append = "kernel-modules" in 
> local.conf.When i build with  bitbake core-image-minimal command this 
> kernel module is loading.while i build with bitbake 
> atmel-qt5-demo-image command kernel module is not loading.
>
>           Please tell us what is the issue.
>
> Thanks & Regards,
>
> Pawan
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/0eaf2820/attachment.html>

From john at mccabe.org.uk  Fri Jun 28 03:25:20 2019
From: john at mccabe.org.uk (John McCabe)
Date: Fri, 28 Jun 2019 11:25:20 +0100 (BST)
Subject: [yocto] Recursions problem with pre-built versioned libraries
 and oe_soinstall
In-Reply-To: <784d3708-806e-04f5-55be-0775989d2f16@windriver.com>
References: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
	<784d3708-806e-04f5-55be-0775989d2f16@windriver.com>
Message-ID: <600923197.440588.1561717520748@email.ionos.co.uk>

Hi Chen,

I'm a little confused by your message.

You've replied to my email to the Yocto mailing list, regarding a problem I'm having with Yocto, by suggesting I email this list if I have a problem with Yocto.

Unless I'm missing something, that doesn't make a lot of sense. Can you please clarify?

Thanks

John

(PS - changed my subscription email address as my company's Outlook forces a load of random nonsense in the sig!).

> On 28 June 2019 at 10:47 ChenQi <Qi.Chen at windriver.com> wrote: 
>  
> 
> Hi John, 
>  
>  When you have problems regarding yocto, please send email to this mailing list. 
>  
>  Regards, 
>  Chen Qi 
>  
>  On 06/28/2019 12:53 AM, John McCabe wrote: 
> > Hi, 
> >  
> >  (Sorry for the long post, but....) 
> >  
> >  I'm new to Yocto etc and I'm struggling with configuring a recipe to install some library files that I've built. The libraries in question are part of OpenDDS, which I've cross-compiled for a Zynq-7000 target. At this point I don't want to include the build of the libraries in the Yocto (actually PetaLinux) configuration as it takes hours to build, so I just want to add the shared libraries that are needed into the image. However I haven't managed to get this to work in hours, if not days, of trying. Despite multiple attempts at an opendds.bb file, I continue to get issues with: 
> >  
> >  === 
> >  Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15' 
> >  === 
> >  
> >  Essentially there are a set of binaries and a set of shared libraries that I want to go into the image. If you look at the current version of the opendds.bb file I'm using, below, you should see a list of the files in question. 
> >  
> >  === 
> >  # 
> >  # This file is the OpenDDS libraries recipe. 
> >  # 
> >  
> >  SUMMARY = "OpenDDS Libraries" 
> >  SECTION = "PETALINUX/apps" 
> >  LICENSE = "MIT" 
> >  LIC_FILES_CHKSUM = ["file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"](file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302) 
> >  
> >  SRC_URI = " [file://DCPSInfoRepo]() \ 
> >  [file://tao_cosnaming]() \ 
> >  [file://tao_imr]() \ 
> >  [file://tao_imr_activator]() \ 
> >  [file://tao_imr_locator]() \ 
> >  [file://tao_nsadd]() \ 
> >  [file://tao_nsdel]() \ 
> >  [file://tao_nslist]() \ 
> >  [file://libACE.so.6.2a_p15]() \ 
> >  [file://libACEXML.so.6.2a_p15]() \ 
> >  [file://libACEXML_Parser.so.6.2a_p15]() \ 
> >  [file://libOpenDDS_Dcps.so.3.13.2]() \ 
> >  [file://libOpenDDS_FACE.so.3.13.2]() \ 
> >  [file://libOpenDDS_Federator.so.3.13.2]() \ 
> >  [file://libOpenDDS_InfoRepoDiscovery.so.3.13.2]() \ 
> >  [file://libOpenDDS_InfoRepoLib.so.3.13.2]() \ 
> >  [file://libOpenDDS_InfoRepoServ.so.3.13.2]() \ 
> >  [file://libOpenDDS_Model.so.3.13.2]() \ 
> >  [file://libOpenDDS_Multicast.so.3.13.2]() \ 
> >  [file://libOpenDDS_Rtps.so.3.13.2]() \ 
> >  [file://libOpenDDS_Rtps_Udp.so.3.13.2]() \ 
> >  [file://libOpenDDS_Shmem.so.3.13.2]() \ 
> >  [file://libOpenDDS_Tcp.so.3.13.2]() \ 
> >  [file://libOpenDDS_Udp.so.3.13.2]() \ 
> >  [file://libOpenDDS_monitor.so.3.13.2]() \ 
> >  [file://libTAO.so.2.2a_p15]() \ 
> >  [file://libTAO_AnyTypeCode.so.2.2a_p15]() \ 
> >  [file://libTAO_Async_IORTable.so.2.2a_p15]() \ 
> >  [file://libTAO_Async_ImR_Client_IDL.so.2.2a_p15]() \ 
> >  [file://libTAO_BiDirGIOP.so.2.2a_p15]() \ 
> >  [file://libTAO_CSD_Framework.so.2.2a_p15]() \ 
> >  [file://libTAO_CSD_ThreadPool.so.2.2a_p15]() \ 
> >  [file://libTAO_CodecFactory.so.2.2a_p15]() \ 
> >  [file://libTAO_Codeset.so.2.2a_p15]() \ 
> >  [file://libTAO_CosNaming.so.2.2a_p15]() \ 
> >  [file://libTAO_CosNaming_Serv.so.2.2a_p15]() \ 
> >  [file://libTAO_CosNaming_Skel.so.2.2a_p15]() \ 
> >  [file://libTAO_DynamicInterface.so.2.2a_p15]() \ 
> >  [file://libTAO_FTORB_Utils.so.2.2a_p15]() \ 
> >  [file://libTAO_FT_ClientORB.so.2.2a_p15]() \ 
> >  [file://libTAO_FT_ServerORB.so.2.2a_p15]() \ 
> >  [file://libTAO_IDL_FE.so.2.2a_p15]() \ 
> >  [file://libTAO_IORManip.so.2.2a_p15]() \ 
> >  [file://libTAO_IORTable.so.2.2a_p15]() \ 
> >  [file://libTAO_ImR_Activator.so.2.2a_p15]() \ 
> >  [file://libTAO_ImR_Activator_IDL.so.2.2a_p15]() \ 
> >  [file://libTAO_ImR_Client.so.2.2a_p15]() \ 
> >  [file://libTAO_ImR_Locator.so.2.2a_p15]() \ 
> >  [file://libTAO_ImR_Locator_IDL.so.2.2a_p15]() \ 
> >  [file://libTAO_Messaging.so.2.2a_p15]() \ 
> >  [file://libTAO_PI.so.2.2a_p15]() \ 
> >  [file://libTAO_PI_Server.so.2.2a_p15]() \ 
> >  [file://libTAO_PortableGroup.so.2.2a_p15]() \ 
> >  [file://libTAO_PortableServer.so.2.2a_p15]() \ 
> >  [file://libTAO_Strategies.so.2.2a_p15]() \ 
> >  [file://libTAO_Svc_Utils.so.2.2a_p15]() \ 
> >  [file://libTAO_Valuetype.so.2.2a_p15]() \ 
> >  " 
> >  
> >  S = "${WORKDIR}" 
> >  
> >  do_install() { 
> >  install -d ${D}${bindir} 
> >  install -d ${D}${libdir} 
> >  install -m 0755 DCPSInfoRepo ${D}${bindir} 
> >  install -m 0755 tao_cosnaming ${D}${bindir} 
> >  install -m 0755 tao_imr ${D}${bindir} 
> >  install -m 0755 tao_imr_activator ${D}${bindir} 
> >  install -m 0755 tao_imr_locator ${D}${bindir} 
> >  install -m 0755 tao_nsadd ${D}${bindir} 
> >  install -m 0755 tao_nsdel ${D}${bindir} 
> >  install -m 0755 tao_nslist ${D}${bindir} 
> >  oe_soinstall libACE.so.6.2a_p15 ${D}${libdir} 
> >  oe_soinstall libACEXML.so.6.2a_p15 ${D}${libdir} 
> >  oe_soinstall libACEXML_Parser.so.6.2a_p15 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Dcps.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_FACE.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Federator.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_InfoRepoDiscovery.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_InfoRepoLib.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_InfoRepoServ.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Model.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Multicast.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Rtps.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Rtps_Udp.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Shmem.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Tcp.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_Udp.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libOpenDDS_monitor.so.3.13.2 ${D}${libdir} 
> >  oe_soinstall libTAO.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_AnyTypeCode.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Async_IORTable.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Async_ImR_Client_IDL.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_BiDirGIOP.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_CSD_Framework.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_CSD_ThreadPool.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_CodecFactory.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Codeset.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_CosNaming.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_CosNaming_Serv.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_CosNaming_Skel.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_DynamicInterface.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_FTORB_Utils.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_FT_ClientORB.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_FT_ServerORB.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_IDL_FE.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_IORManip.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_IORTable.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_ImR_Activator.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_ImR_Activator_IDL.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_ImR_Client.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_ImR_Locator.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_ImR_Locator_IDL.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Messaging.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_PI.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_PI_Server.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_PortableGroup.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_PortableServer.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Strategies.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Svc_Utils.so.2.2a_p15 ${D}${libdir} 
> >  oe_soinstall libTAO_Valuetype.so.2.2a_p15 ${D}${libdir} 
> >  } 
> >  
> >  # Don't bother trying to build the debug package, at least for now! 
> >  INHIBIT_PACKAGE_STRIP = "1" 
> >  INHIBIT_SYSROOT_STRIP = "1" 
> >  INHIBIT_PACKAGE_DEBUG_SPLIT = "1" 
> >  
> >  # Inhibit warnings about files being stripped 
> >  INSANE_SKIP_${PN} = "ldflags" 
> >  INSANE_SKIP_${PN} = "already-stripped" 
> >  
> >  # No .h files to be packaged, so only list .so stuff 
> >  FILES_${PN} = "${bindir}/* ${libdir}/*.so.*" 
> >  FILES_${PN}-dev = "${bindir}/* ${libdir}/*.so" 
> >  === 
> >  
> >  The files were all built in another folder but I've copied them into the project-spec/meta-user/recipes-apps/opendds/files folder so that they can be picked up ok. I uses the normal install to do the binaries, and oe_soinstall to work with the versioned shared libraries, as described in various places. 
> >  
> >  I added a print statement into package.bbclass at line 1233 (see below) to try to get a bit more information into the log file about the point where it's breaking). The log then shows this below (I presume that the stderr output being in the middle of that lot is just some sequencing effect): 
> >  
> >  === 
> >  DEBUG: Executing python function package_fixsymlinks 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Svc_Utils.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ClientORB.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_Framework.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps_Udp.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_ImR_Client_IDL.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_DynamicInterface.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_AnyTypeCode.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Tcp.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator_IDL.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoDiscovery.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoLib.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Valuetype.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_BiDirGIOP.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Messaging.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORManip.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Serv.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableServer.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_IORTable.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IDL_FE.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML_Parser.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_monitor.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Multicast.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI_Server.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Strategies.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Federator.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Shmem.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Model.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CodecFactory.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ServerORB.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACE.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Dcps.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORTable.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Skel.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator_IDL.so, pkg: opendds-devERROR: 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:package_fixsymlinks(d) 
> >  0003: 
> >  File: '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/classes/package.bbclass', lineno: 1236, function: package_fixsymlinks 
> >  1232: for path in pkgfiles[pkg]: 
> >  1233: print('path: %s, pkg: %s' % (path, pkg)) 
> >  1234: rpath = path[len(inst_root):] 
> >  1235: pkg_files[pkg].append(rpath) 
> >  *** 1236: rtarget = cpath.realpath(path, inst_root, True, assume_dir = True) 
> >  1237: if not cpath.lexists(rtarget): 
> >  1238: dangling_links[pkg].append(os.path.normpath(rtarget[len(inst_root):])) 
> >  1239: 
> >  1240: newrdepends = {} 
> >  File: '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/lib/oe/cachedpath.py', lineno: 229, function: realpath 
> >  0225: # be printed a backtrace with 100s of OSError exceptions 
> >  0226: # else 
> >  0227: raise OSError(errno.ELOOP, 
> >  0228: "too much recursions while resolving '%s'; loop in '%s'" % 
> >  *** 0229: (file, e.strerror)) 
> >  0230: 
> >  0231: raise 
> >  0232: 
> >  0233: return file 
> >  Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15' 
> >  
> >  DEBUG: Python function package_fixsymlinks finished 
> >  DEBUG: Python function do_package finished 
> >  ERROR: Function failed: package_fixsymlinks 
> >  
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoServ.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_ThreadPool.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FTORB_Utils.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableGroup.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Client.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_FACE.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Codeset.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Udp.so, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_locator, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_cosnaming, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsdel, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsadd, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nslist, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_activator, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/DCPSInfoRepo, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr, pkg: opendds-dev 
> >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15, pkg: opendds 
> >  === 
> >  
> >  In addition, I get a batch of the following messages coming out: 
> >  
> >  === 
> >  1: opendds-1.0-r0 do_package - 0s (pid 23258) 
> >  link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_Svc_Utils.so.2.2a_p15'. 
> >  link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI_Server.so.2.2a_p15'. 
> >  link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI.so.2.2a_p15'. 
> >  === 
> >  
> >  And, when I go into the lib folder and list the contents, I see: 
> >  
> >  === 
> >  : 
> >  lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so -> libTAO_PI_Server.so.2.2a_p15 
> >  lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15 -> libTAO_PI_Server.so.2.2a_p15 
> >  : 
> >  === 
> >  
> >  With (on Ubuntu), all the filenames in red with a grey (or black?) background, i.e. broken links. 
> >  
> >  I have a couple of questions about all this: 
> >  
> >  1) The oe_soinstall function (see here - https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/utils.bbclass) includes a line that installs (using "install") the xxx.so.x.y file, which causes a copy of the file from ${WORKDIR} to go into the <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi.opendds/1.0-r0/image/usr/lib directory. It then generates sonamelink and solink from the library details and creates symbolic links that point back to the copies of the library files in ${WORKDIR}. In doing that, the copy of the file that was placed there by the install line is overwritten with the symbolic link; is that normal? (I presume it must be otherwise no one would be getting oe_soinstall to work!). 
> >  
> >  2) Is there anything in the shared library filenames' version part that could be causing something to get confused? I've seen mention of zzz.so.a.b.c etc where a, b and c are normally numeric, which is different to the version information in the DDS files, but... 
> >  
> >  3) I can understand why there could be a recursion issue detected, but it's not met who's putting those weird links into the package/usr/lib folder. Is there something in the .bb file that I need to change to make that work properly? 
> >  
> >  4) Can anyone see whether I'm just simply doing something wrong and clarify what I need to do to put it right? 
> >  
> >  Any help will be very, very gratefully appreciated. As I said, I'm new to Yocto and have spent hours looking for help/example of the use of oe_soinstall. Each time round the loop of updating my .bb file and building it takes quite a long time so... 
> >  
> >  Many thanks, 
> >  John 
> > 
> > John?McCabe?

From ross.burton at intel.com  Fri Jun 28 03:53:41 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Fri, 28 Jun 2019 11:53:41 +0100
Subject: [yocto] Recursions problem with pre-built versioned libraries
	and oe_soinstall
In-Reply-To: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
References: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CAJTo0LY+dZj9m74+QutZ7kzApZFwGTQ5B6ZXT0O-0KJdhpDoMw@mail.gmail.com>

On Thu, 27 Jun 2019 at 17:58, John McCabe <JMcCabe at kirintec.com> wrote:

> Exception: OSError: [Errno 40] too much recursions while resolving
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15';
> loop in
> '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'



> lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15
> -> libTAO_PI_Server.so.2.2a_p15
>

You can't deny that this is a symlink loop.

Note that these are all the users of oe_libinstall in oe-core:

$ git grep -l oe_soinstall
meta/classes/utils.bbclass

So I'm not massively surprised that it's buggy.  In this case, it looks
like the library either has an incorrect soname, or the install function
isn't handling the soname being the same: it assumes that it is being
passed libfoo.so.1.2.3 which has a soname of libfoo.so.1 and will copy
libfoo.so.1.2.3 and then create libfoo.so.1 and libfoo.so symlinks.    My
recommendations:

1) Write a proper recipe instead of building code outside of OE and trying
to copy it in by hand.  Or,
2) Determine what the correct structure is regarding sonames, and either
fix oe_soinstall or just use install/ln directly.

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image584022.png
Type: image/png
Size: 10433 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image743201.png
Type: image/png
Size: 341 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image289906.png
Type: image/png
Size: 370 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image885432.png
Type: image/png
Size: 490 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image679662.png
Type: image/png
Size: 641 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image231032.png
Type: image/png
Size: 642 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image469003.png
Type: image/png
Size: 675 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0013.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image018193.jpg
Type: image/jpeg
Size: 85123 bytes
Desc: not available
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/6c03e9aa/attachment-0001.jpg>

From zoran.stojsavljevic at gmail.com  Fri Jun 28 04:14:27 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Fri, 28 Jun 2019 13:14:27 +0200
Subject: [yocto] Recursions problem with pre-built versioned libraries
	and oe_soinstall
In-Reply-To: <600923197.440588.1561717520748@email.ionos.co.uk>
References: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
	<784d3708-806e-04f5-55be-0775989d2f16@windriver.com>
	<600923197.440588.1561717520748@email.ionos.co.uk>
Message-ID: <CAGAf8LynFQwKqHoMjTxMkikKi1xi9Wwqzs6ZzJGkzb0-enBtTA@mail.gmail.com>

> You've replied to my email to the Yocto mailing list, regarding a
> problem I'm having with Yocto, by suggesting I email this list if I
> have a problem with Yocto.

You can't deny that this is a symlink loop. On a higher level! ;-)

Zoran
_______

On Fri, Jun 28, 2019 at 12:39 PM John McCabe <john at mccabe.org.uk> wrote:
>
> Hi Chen,
>
> I'm a little confused by your message.
>
> You've replied to my email to the Yocto mailing list, regarding a problem I'm having with Yocto, by suggesting I email this list if I have a problem with Yocto.
>
> Unless I'm missing something, that doesn't make a lot of sense. Can you please clarify?
>
> Thanks
>
> John
>
> (PS - changed my subscription email address as my company's Outlook forces a load of random nonsense in the sig!).
>
> > On 28 June 2019 at 10:47 ChenQi <Qi.Chen at windriver.com> wrote:
> >
> >
> > Hi John,
> >
> >  When you have problems regarding yocto, please send email to this mailing list.
> >
> >  Regards,
> >  Chen Qi
> >
> >  On 06/28/2019 12:53 AM, John McCabe wrote:
> > > Hi,
> > >
> > >  (Sorry for the long post, but....)
> > >
> > >  I'm new to Yocto etc and I'm struggling with configuring a recipe to install some library files that I've built. The libraries in question are part of OpenDDS, which I've cross-compiled for a Zynq-7000 target. At this point I don't want to include the build of the libraries in the Yocto (actually PetaLinux) configuration as it takes hours to build, so I just want to add the shared libraries that are needed into the image. However I haven't managed to get this to work in hours, if not days, of trying. Despite multiple attempts at an opendds.bb file, I continue to get issues with:
> > >
> > >  ===
> > >  Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'
> > >  ===
> > >
> > >  Essentially there are a set of binaries and a set of shared libraries that I want to go into the image. If you look at the current version of the opendds.bb file I'm using, below, you should see a list of the files in question.
> > >
> > >  ===
> > >  #
> > >  # This file is the OpenDDS libraries recipe.
> > >  #
> > >
> > >  SUMMARY = "OpenDDS Libraries"
> > >  SECTION = "PETALINUX/apps"
> > >  LICENSE = "MIT"
> > >  LIC_FILES_CHKSUM = ["file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"](file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302)
> > >
> > >  SRC_URI = " [file://DCPSInfoRepo]() \
> > >  [file://tao_cosnaming]() \
> > >  [file://tao_imr]() \
> > >  [file://tao_imr_activator]() \
> > >  [file://tao_imr_locator]() \
> > >  [file://tao_nsadd]() \
> > >  [file://tao_nsdel]() \
> > >  [file://tao_nslist]() \
> > >  [file://libACE.so.6.2a_p15]() \
> > >  [file://libACEXML.so.6.2a_p15]() \
> > >  [file://libACEXML_Parser.so.6.2a_p15]() \
> > >  [file://libOpenDDS_Dcps.so.3.13.2]() \
> > >  [file://libOpenDDS_FACE.so.3.13.2]() \
> > >  [file://libOpenDDS_Federator.so.3.13.2]() \
> > >  [file://libOpenDDS_InfoRepoDiscovery.so.3.13.2]() \
> > >  [file://libOpenDDS_InfoRepoLib.so.3.13.2]() \
> > >  [file://libOpenDDS_InfoRepoServ.so.3.13.2]() \
> > >  [file://libOpenDDS_Model.so.3.13.2]() \
> > >  [file://libOpenDDS_Multicast.so.3.13.2]() \
> > >  [file://libOpenDDS_Rtps.so.3.13.2]() \
> > >  [file://libOpenDDS_Rtps_Udp.so.3.13.2]() \
> > >  [file://libOpenDDS_Shmem.so.3.13.2]() \
> > >  [file://libOpenDDS_Tcp.so.3.13.2]() \
> > >  [file://libOpenDDS_Udp.so.3.13.2]() \
> > >  [file://libOpenDDS_monitor.so.3.13.2]() \
> > >  [file://libTAO.so.2.2a_p15]() \
> > >  [file://libTAO_AnyTypeCode.so.2.2a_p15]() \
> > >  [file://libTAO_Async_IORTable.so.2.2a_p15]() \
> > >  [file://libTAO_Async_ImR_Client_IDL.so.2.2a_p15]() \
> > >  [file://libTAO_BiDirGIOP.so.2.2a_p15]() \
> > >  [file://libTAO_CSD_Framework.so.2.2a_p15]() \
> > >  [file://libTAO_CSD_ThreadPool.so.2.2a_p15]() \
> > >  [file://libTAO_CodecFactory.so.2.2a_p15]() \
> > >  [file://libTAO_Codeset.so.2.2a_p15]() \
> > >  [file://libTAO_CosNaming.so.2.2a_p15]() \
> > >  [file://libTAO_CosNaming_Serv.so.2.2a_p15]() \
> > >  [file://libTAO_CosNaming_Skel.so.2.2a_p15]() \
> > >  [file://libTAO_DynamicInterface.so.2.2a_p15]() \
> > >  [file://libTAO_FTORB_Utils.so.2.2a_p15]() \
> > >  [file://libTAO_FT_ClientORB.so.2.2a_p15]() \
> > >  [file://libTAO_FT_ServerORB.so.2.2a_p15]() \
> > >  [file://libTAO_IDL_FE.so.2.2a_p15]() \
> > >  [file://libTAO_IORManip.so.2.2a_p15]() \
> > >  [file://libTAO_IORTable.so.2.2a_p15]() \
> > >  [file://libTAO_ImR_Activator.so.2.2a_p15]() \
> > >  [file://libTAO_ImR_Activator_IDL.so.2.2a_p15]() \
> > >  [file://libTAO_ImR_Client.so.2.2a_p15]() \
> > >  [file://libTAO_ImR_Locator.so.2.2a_p15]() \
> > >  [file://libTAO_ImR_Locator_IDL.so.2.2a_p15]() \
> > >  [file://libTAO_Messaging.so.2.2a_p15]() \
> > >  [file://libTAO_PI.so.2.2a_p15]() \
> > >  [file://libTAO_PI_Server.so.2.2a_p15]() \
> > >  [file://libTAO_PortableGroup.so.2.2a_p15]() \
> > >  [file://libTAO_PortableServer.so.2.2a_p15]() \
> > >  [file://libTAO_Strategies.so.2.2a_p15]() \
> > >  [file://libTAO_Svc_Utils.so.2.2a_p15]() \
> > >  [file://libTAO_Valuetype.so.2.2a_p15]() \
> > >  "
> > >
> > >  S = "${WORKDIR}"
> > >
> > >  do_install() {
> > >  install -d ${D}${bindir}
> > >  install -d ${D}${libdir}
> > >  install -m 0755 DCPSInfoRepo ${D}${bindir}
> > >  install -m 0755 tao_cosnaming ${D}${bindir}
> > >  install -m 0755 tao_imr ${D}${bindir}
> > >  install -m 0755 tao_imr_activator ${D}${bindir}
> > >  install -m 0755 tao_imr_locator ${D}${bindir}
> > >  install -m 0755 tao_nsadd ${D}${bindir}
> > >  install -m 0755 tao_nsdel ${D}${bindir}
> > >  install -m 0755 tao_nslist ${D}${bindir}
> > >  oe_soinstall libACE.so.6.2a_p15 ${D}${libdir}
> > >  oe_soinstall libACEXML.so.6.2a_p15 ${D}${libdir}
> > >  oe_soinstall libACEXML_Parser.so.6.2a_p15 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Dcps.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_FACE.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Federator.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_InfoRepoDiscovery.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_InfoRepoLib.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_InfoRepoServ.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Model.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Multicast.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Rtps.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Rtps_Udp.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Shmem.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Tcp.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_Udp.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libOpenDDS_monitor.so.3.13.2 ${D}${libdir}
> > >  oe_soinstall libTAO.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_AnyTypeCode.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Async_IORTable.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Async_ImR_Client_IDL.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_BiDirGIOP.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_CSD_Framework.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_CSD_ThreadPool.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_CodecFactory.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Codeset.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_CosNaming.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_CosNaming_Serv.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_CosNaming_Skel.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_DynamicInterface.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_FTORB_Utils.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_FT_ClientORB.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_FT_ServerORB.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_IDL_FE.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_IORManip.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_IORTable.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_ImR_Activator.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_ImR_Activator_IDL.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_ImR_Client.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_ImR_Locator.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_ImR_Locator_IDL.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Messaging.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_PI.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_PI_Server.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_PortableGroup.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_PortableServer.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Strategies.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Svc_Utils.so.2.2a_p15 ${D}${libdir}
> > >  oe_soinstall libTAO_Valuetype.so.2.2a_p15 ${D}${libdir}
> > >  }
> > >
> > >  # Don't bother trying to build the debug package, at least for now!
> > >  INHIBIT_PACKAGE_STRIP = "1"
> > >  INHIBIT_SYSROOT_STRIP = "1"
> > >  INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
> > >
> > >  # Inhibit warnings about files being stripped
> > >  INSANE_SKIP_${PN} = "ldflags"
> > >  INSANE_SKIP_${PN} = "already-stripped"
> > >
> > >  # No .h files to be packaged, so only list .so stuff
> > >  FILES_${PN} = "${bindir}/* ${libdir}/*.so.*"
> > >  FILES_${PN}-dev = "${bindir}/* ${libdir}/*.so"
> > >  ===
> > >
> > >  The files were all built in another folder but I've copied them into the project-spec/meta-user/recipes-apps/opendds/files folder so that they can be picked up ok. I uses the normal install to do the binaries, and oe_soinstall to work with the versioned shared libraries, as described in various places.
> > >
> > >  I added a print statement into package.bbclass at line 1233 (see below) to try to get a bit more information into the log file about the point where it's breaking). The log then shows this below (I presume that the stderr output being in the middle of that lot is just some sequencing effect):
> > >
> > >  ===
> > >  DEBUG: Executing python function package_fixsymlinks
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Svc_Utils.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ClientORB.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_Framework.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps_Udp.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Rtps.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_ImR_Client_IDL.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_DynamicInterface.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_AnyTypeCode.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Tcp.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator_IDL.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoDiscovery.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoLib.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Valuetype.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_BiDirGIOP.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Messaging.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORManip.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Serv.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableServer.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Activator.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Async_IORTable.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IDL_FE.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACEXML_Parser.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_monitor.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Multicast.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI_Server.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Strategies.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Federator.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Shmem.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Model.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PI.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CodecFactory.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FT_ServerORB.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libACE.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Dcps.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_IORTable.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CosNaming_Skel.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Locator_IDL.so, pkg: opendds-devERROR: 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:package_fixsymlinks(d)
> > >  0003:
> > >  File: '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/classes/package.bbclass', lineno: 1236, function: package_fixsymlinks
> > >  1232: for path in pkgfiles[pkg]:
> > >  1233: print('path: %s, pkg: %s' % (path, pkg))
> > >  1234: rpath = path[len(inst_root):]
> > >  1235: pkg_files[pkg].append(rpath)
> > >  *** 1236: rtarget = cpath.realpath(path, inst_root, True, assume_dir = True)
> > >  1237: if not cpath.lexists(rtarget):
> > >  1238: dangling_links[pkg].append(os.path.normpath(rtarget[len(inst_root):]))
> > >  1239:
> > >  1240: newrdepends = {}
> > >  File: '/opt/pkg/petalinux/components/yocto/source/arm/layers/core/meta/lib/oe/cachedpath.py', lineno: 229, function: realpath
> > >  0225: # be printed a backtrace with 100s of OSError exceptions
> > >  0226: # else
> > >  0227: raise OSError(errno.ELOOP,
> > >  0228: "too much recursions while resolving '%s'; loop in '%s'" %
> > >  *** 0229: (file, e.strerror))
> > >  0230:
> > >  0231: raise
> > >  0232:
> > >  0233: return file
> > >  Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'
> > >
> > >  DEBUG: Python function package_fixsymlinks finished
> > >  DEBUG: Python function do_package finished
> > >  ERROR: Function failed: package_fixsymlinks
> > >
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_InfoRepoServ.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_CSD_ThreadPool.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_FTORB_Utils.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_PortableGroup.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_ImR_Client.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_FACE.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libTAO_Codeset.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/lib/libOpenDDS_Udp.so, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_locator, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_cosnaming, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsdel, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nsadd, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_nslist, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr_activator, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/DCPSInfoRepo, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds-dev/usr/bin/tao_imr, pkg: opendds-dev
> > >  path: <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15, pkg: opendds
> > >  ===
> > >
> > >  In addition, I get a batch of the following messages coming out:
> > >
> > >  ===
> > >  1: opendds-1.0-r0 do_package - 0s (pid 23258)
> > >  link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_Svc_Utils.so.2.2a_p15'.
> > >  link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI_Server.so.2.2a_p15'.
> > >  link recursion too deep, not expanding path '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/package/usr/lib/libTAO_PI.so.2.2a_p15'.
> > >  ===
> > >
> > >  And, when I go into the lib folder and list the contents, I see:
> > >
> > >  ===
> > >  :
> > >  lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so -> libTAO_PI_Server.so.2.2a_p15
> > >  lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15 -> libTAO_PI_Server.so.2.2a_p15
> > >  :
> > >  ===
> > >
> > >  With (on Ubuntu), all the filenames in red with a grey (or black?) background, i.e. broken links.
> > >
> > >  I have a couple of questions about all this:
> > >
> > >  1) The oe_soinstall function (see here - https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/utils.bbclass) includes a line that installs (using "install") the xxx.so.x.y file, which causes a copy of the file from ${WORKDIR} to go into the <project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi.opendds/1.0-r0/image/usr/lib directory. It then generates sonamelink and solink from the library details and creates symbolic links that point back to the copies of the library files in ${WORKDIR}. In doing that, the copy of the file that was placed there by the install line is overwritten with the symbolic link; is that normal? (I presume it must be otherwise no one would be getting oe_soinstall to work!).
> > >
> > >  2) Is there anything in the shared library filenames' version part that could be causing something to get confused? I've seen mention of zzz.so.a.b.c etc where a, b and c are normally numeric, which is different to the version information in the DDS files, but...
> > >
> > >  3) I can understand why there could be a recursion issue detected, but it's not met who's putting those weird links into the package/usr/lib folder. Is there something in the .bb file that I need to change to make that work properly?
> > >
> > >  4) Can anyone see whether I'm just simply doing something wrong and clarify what I need to do to put it right?
> > >
> > >  Any help will be very, very gratefully appreciated. As I said, I'm new to Yocto and have spent hours looking for help/example of the use of oe_soinstall. Each time round the loop of updating my .bb file and building it takes quite a long time so...
> > >
> > >  Many thanks,
> > >  John
> > >
> > > John McCabe
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From john at mccabe.org.uk  Fri Jun 28 04:41:14 2019
From: john at mccabe.org.uk (John McCabe)
Date: Fri, 28 Jun 2019 12:41:14 +0100 (BST)
Subject: [yocto] Recursions problem with pre-built versioned libraries
 and oe_soinstall
In-Reply-To: <CAJTo0LY+dZj9m74+QutZ7kzApZFwGTQ5B6ZXT0O-0KJdhpDoMw@mail.gmail.com>
References: <LNXP265MB0346E0B3875EEF62066F257ED1FD0@LNXP265MB0346.GBRP265.PROD.OUTLOOK.COM>
	<CAJTo0LY+dZj9m74+QutZ7kzApZFwGTQ5B6ZXT0O-0KJdhpDoMw@mail.gmail.com>
Message-ID: <667705151.446726.1561722074672@email.ionos.co.uk>

Ross,

Thank you for your reply.

Please see interspersed comments below.

> On 28 June 2019 at 11:53 "Burton, Ross" <ross.burton at intel.com> wrote: 
> 
> On Thu, 27 Jun 2019 at 17:58, John McCabe < JMcCabe at kirintec.com> wrote:
> > Exception: OSError: [Errno 40] too much recursions while resolving '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; loop in '<project-base>/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'
> ? 
> > lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15 -> libTAO_PI_Server.so.2.2a_p15
> ?
> You can't deny that this is a symlink loop.

Yes, it is most definitely a symlink loop/fault.

oe_soinstall does this (from https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/utils.bbclass):

01 oe_soinstall() {
02 	# Purpose: Install shared library file and
03 	#          create the necessary links
04 	# Example: oe_soinstall libfoo.so.1.2.3 ${D}${libdir}
05 	libname=`basename $1`
06 	case "$libname" in
07 	    *.so)
08 	        bbfatal "oe_soinstall: Shared library must haved versioned filename (e.g. libfoo.so.1.2.3)"
09 	        ;;
10 	esac
11 	install -m 755 $1 $2/$libname
12 	sonamelink=`${HOST_PREFIX}readelf -d $1 |grep 'Library soname:' |sed -e 's/.*\[\(.*\)\].*/\1/'`
13 	if [ -z $sonamelink ]; then
14 		bbfatal "oe_soinstall: $libname is missing ELF tag 'SONAME'."
15 	fi
16 	solink=`echo $libname | sed -e 's/\.so\..*/.so/'`
17 	ln -sf $libname $2/$sonamelink
18 	ln -sf $libname $2/$solink
19 }

Which is as I described so, at the end of it, lines 17 & 18 have created symbolic links in the <output>/usr/lib folder to the ${WORKDIR} copy of the versioned shared library.

Later on the "def perform_packagecopy(d)" function (see https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/package.bbclass, probably!) is run. In run.do_package this shows as:

01def perform_packagecopy(d):
02    enabled = oe.data.typed_value('LICENSE_CREATE_PACKAGE', d)
03    if d.getVar('CLASSOVERRIDE', True) == 'class-target' and enabled:
04        lic_files_paths = find_license_files(d)
05
06        # LICENSE_FILES_DIRECTORY starts with '/' so os.path.join cannot be used to join D and LICENSE_FILES_DIRECTORY
07        destdir = d.getVar('D', True) + os.path.join(d.getVar('LICENSE_FILES_DIRECTORY', True), d.getVar('PN', True))
08        copy_license_files(lic_files_paths, destdir)
09        add_package_and_files(d)
10    dest = d.getVar('D', True)
11    dvar = d.getVar('PKGD', True)
12
13    # Start by package population by taking a copy of the installed
14    # files to operate on
15    # Preserve sparse files and hard links
16    cmd = 'tar -cf - -C %s -p . | tar -xf - -C %s' % (dest, dvar)
17    (retval, output) = oe.utils.getstatusoutput(cmd)
18    if retval:
19        bb.fatal("file copy failed with exit code %s (cmd was %s)%s" % (retval, cmd, ":\n%s" % output if output else ""))
20
21    # replace RPATHs for the nativesdk binaries, to make them relocatable
22    if bb.data.inherits_class('nativesdk', d) or bb.data.inherits_class('cross-canadian', d):
23        rpath_replace (dvar, d)

It's line 16 that's breaking things; that tar command claims to preserve sparse files and hard links, but I've tried running that command manually and it certainly doesn't preserve symbolic links.

> Note that these are all the users of oe_libinstall in oe-core:
> 
> $ git grep -l oe_soinstall
> meta/classes/utils.bbclass

Yip - I looked through the core files to see if there were other recipes that used it and found the same result.

> So I'm not massively surprised that it's buggy.? In this case, it looks like the library either has an incorrect soname, or the install function isn't handling the soname being the same: it assumes that it is being passed libfoo.so.1.2.3 which has a soname of libfoo.so.1 and will copy libfoo.so.1.2.3 and then create libfoo.so.1 and libfoo.so symlinks. 

Everything that's done as part of do_install is working as it "should" (!?) if you follow through the code. As described, the result of the do_install is that there is a file called libTAO_PI_Server.so.2.2a_p15 in ${WORKDIR}, and in ${WORKDIR}/image/usr/lib there are two symbolic links; libTAO_PI_Server.so.2.2a_p15 and libTAO_PI_Server.so, both of which point to the file in ${WORKDIR}. When the tar commands are run in perform_packagecopy, you end up with this:

lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so -> libTAO_PI_Server.so.2.2a_p15
lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15 -> libTAO_PI_Server.so.2.2a_p15

What confuses me are that there are a small number of examples out there on how to use oe_soinstall, and a couple of comments here and there about how it's what you should be using to install versioned shared libraries, particularly here bugzilla.yoctodev.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries#Versioned_Libraries, and it looks quite sensible and simple until you come to try to use it!

>? ?My recommendations:
 ?
> 1) Write a proper recipe instead of building code outside of OE and trying to copy it in by hand.? Or,

In the long run that would be the plan, however, I'm still in the early stages so thought that it would be nice to avoid having to rebuild the OpenDDS stuff as it takes, as I mentioned, a number of hours to build!

> 2) Determine what the correct structure is regarding sonames, and either fix oe_soinstall

Now there's a question; how to determine whether it's actually oe_soinstall that's at fault (which, clearly, appears to be very rarely used!), or perform_packagecopy (which is vastly more widely used) and then work out how to fix it!

> or just use install/ln directly.

I suspect this will be the path I need to take, unless anyone else has any useful suggestions.

Many thanks
John

From liezhi.yang at windriver.com  Fri Jun 28 05:32:44 2019
From: liezhi.yang at windriver.com (Robert Yang)
Date: Fri, 28 Jun 2019 20:32:44 +0800
Subject: [yocto] [PATCH 0/1] update-documentation-conf: python2 -> python3
Message-ID: <cover.1561724919.git.liezhi.yang@windriver.com>

The following changes since commit bfe3012ea4b2c973bd6ca5fa1de1adf51e1a9da4:

  busybox: Fix typo in syslog initscript (2019-06-27 13:28:48 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib rbt/update-documentation-conf
  http://git.pokylinux.org/cgit.cgi//log/?h=rbt/update-documentation-conf

Robert Yang (1):
  update-documentation-conf: python2 -> python3

 documentation/tools/update-documentation-conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4


From liezhi.yang at windriver.com  Fri Jun 28 05:32:45 2019
From: liezhi.yang at windriver.com (Robert Yang)
Date: Fri, 28 Jun 2019 20:32:45 +0800
Subject: [yocto] [PATCH 1/1] update-documentation-conf: python2 -> python3
In-Reply-To: <cover.1561724919.git.liezhi.yang@windriver.com>
References: <cover.1561724919.git.liezhi.yang@windriver.com>
Message-ID: <83f73ac48e5be42c72493b723bb582e2550f4d58.1561724919.git.liezhi.yang@windriver.com>

This script is python3 indeed.

Signed-off-by: Robert Yang <liezhi.yang at windriver.com>
---
 documentation/tools/update-documentation-conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/tools/update-documentation-conf b/documentation/tools/update-documentation-conf
index 3f8d280..32d0a2e 100644
--- a/documentation/tools/update-documentation-conf
+++ b/documentation/tools/update-documentation-conf
@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 
 # documentation.conf update script
 #
-- 
2.7.4


From zoran.stojsavljevic at gmail.com  Fri Jun 28 05:26:41 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Fri, 28 Jun 2019 14:26:41 +0200
Subject: [yocto] Can't boot to initramfs
In-Reply-To: <89d3d916-1fca-5ff5-e68e-79370dd0bfb7@gmx.de>
References: <89d3d916-1fca-5ff5-e68e-79370dd0bfb7@gmx.de>
Message-ID: <CAGAf8Lz2t90EjsaXPXxsSoioHb33u7dutnREiFr53NYp-WVD5A@mail.gmail.com>

> INITRAMFS_IMAGE = *"core-image-minimal-initramfs"*
> INITRAMFS_IMAGE_BUNDLE = "1"
...
> You can find the /var/log/dmesg here: https://pastebin.com/ya7iCtq7I

Some hints...

[1] Kernel command line: BOOT_IMAGE=/bzImage
root=PARTUUID=71d1d94a-83e8-4895-98eb-35309f58119f
break=premount quiet rootwait rootwait rootfstype=ext4 *console=ttyS0,115200
console=tty0*

input: Video Bus as
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input7
fbcon: inteldrmfb (fb0) is primary device
Console: switching to colour frame buffer device 128x48
*i915 0000:00:02.0: fb0: inteldrmfb frame buffer device*
snd_hda_intel 0000:00:1b.0: bound 0000:00:02.0 (ops
i915_audio_component_bind_ops [i915])

Hmmmmm... You are using console and serial, but full i915 GFX kernel driver
is still included in the build???

[2] efi: EFI v2.31 by American Megatrends

Using AMI BIOS as boot loader FW... OK?! Am I correct?

[3] smpboot: CPU0: Intel(R) Atom(TM) CPU  E3825  @ 1.33GHz (family: 0x6,
model: 0x37, stepping: 0x9)

This is CPUID ID 0x30679, which uses MCU... Which MicroCodeUnit? M0130679xxx
(info from AMI BIOS)?

[4] Using INTEL ATOM BYT E3825 dual core (sans Hyper-threading), implies
that you are using
4GB (e820 messages) as single channel (one memory module DDR3 as 4GB)! Am I
correct (important)?

[5] Dracut phase?!
> To my understanding the initramfs should be embedded in /boot/bzImage.
> However since I use an intel platform I also have a /boot/microcode.cpio
> which gets loaded via "initrd /microcode.cpio". Removing this line in
> grub does not enable me to get an initramfs prompt either (again, using
> break as option).

You are obviously stopping in boot phase called dracut. Please, try to
mount by hand
/dev/sda(whatever)... You should use fdisk -l command, or do ls -al /dev |
grep sda to
dig out which partition you need to mount to /tmp dir to see
rootfstype=ext4 (HDD/SSD)
_______

Just thinking loud... .. .

Hope this helps (has very little to do with YOCTO build system, BTW) . ;-)

Zoran
_______


On Fri, Jun 28, 2019 at 11:22 AM Moritz Porst <moritz.porst at gmx.de> wrote:

> Hello,
> I currently try to deploy a single rootfs update mechanism for my
> embedded device. I can't boot to initramfs using either "break" or
> "break=premount" (without quotes...). I tried this in systemd-boot and
> grub-efi (always efi boot) but the boot process just continues normally.
> If I insert at the same point e.g. "quiet" this argument is recognised.
> I boot the .wic image with a separate boot partition from a USB stick.
> in local.conf I have set:
> INITRAMFS_IMAGE = "core-image-minimal-initramfs"
> INITRAMFS_IMAGE_BUNDLE = "1"
>
> In order to reduce complexity I now use the standard
> core-image-minimal-initramfs without .bbappend. I can confirm (from
> seeing the task) that bitbake bundled the kernel with the initramfs.
>
> You can find the /var/log/dmesg here: https://pastebin.com/ya7iCtq7
>
> To my understanding the initramfs should be embedded in /boot/bzImage.
> However since I use an intel platform I also have a /boot/microcode.cpio
> which gets loaded via "initrd /microcode.cpio". Removing this line in
> grub does not enable me to get an initramfs prompt either (again, using
> break as option).
>
> Did I forget some configuration or do I have to put the break statement
> at a very specific position within the "linux ..." boot command ? Do you
> know which bitbake variables to check ? (both set in local.conf do not
> get overwritten, already checked this). I got the thud branch checked
> out in all my meta-layers except for meta-qt which is currently on
> master branch.
>
> Help is much appreciated !
>
> Best regards
> Moritz
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/453d7955/attachment.html>

From daniel.wenninger92 at gmail.com  Fri Jun 28 06:41:35 2019
From: daniel.wenninger92 at gmail.com (danwe)
Date: Fri, 28 Jun 2019 15:41:35 +0200
Subject: [yocto] Copying the binaries to an SD card after bulding with Yocto
Message-ID: <CAEmXcAzx7i7ZKdgsfxJ4ChZ_jWAcTFZCHBp2Hp2MCaQVFdHrCw@mail.gmail.com>

Hi,

I have successfully build BeagleBone systems with Yocto.
I have used this site:
https://jumpnowtek.com/beaglebone/BeagleBone-Systems-with-Yocto.html

Now I need to copy the binaries to an SD card and have a question to the
following:
In the instruction I can read the following:
``````````````````````````
This *copy_boot.sh* script needs to know the TMPDIR to find the binaries.
It looks for an environment variable called OETMP.

For instance, if I had this in the local.conf

TMPDIR = "/oe7/bbb/tmp-warrior"

Then I would export this environment variable before running copy_boot.sh

~/bbb/meta-bbb/scripts$ export OETMP=/oe7/bbb/tmp-warrior

Then run the copy_boot.sh script passing the location of SD card
~/bbb/meta-bbb/scripts$ ./copy_boot.sh sdb
```````````````````````

I did that but it shows me the following error:
OETMP: /oe7/bbb/tmp-warrior
Directory not found: /oe7/bbb/tmp-warrior/deploy/images/beaglebone

So my question is if I need to uncomment TMPDIR = "/oe7/bbb/tmp-warrior" in
my local.conf when doing this or not? --> I tried both.

So my copy_boot.sh looks for an environment variable called OETMP. And
OETMP should know the TMPDIR (directory). But what should I export?

Thanks.

Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/dc70714f/attachment-0001.html>

From zoran.stojsavljevic at gmail.com  Fri Jun 28 06:45:00 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Fri, 28 Jun 2019 15:45:00 +0200
Subject: [yocto] [yocto-builds] Yocto build Issue
In-Reply-To: <5239a45d-0756-6c85-9b2d-218b34d9168c@windriver.com>
References: <980292376.238401.1561633028960@email.ionos.com>
	<5239a45d-0756-6c85-9b2d-218b34d9168c@windriver.com>
Message-ID: <CAGAf8LxjwgmuH=uNU43x6=YkPzhpj5kjaR1Rd_mLcoyH3QVofA@mail.gmail.com>

Some hints again...

> I am adding IMAGE_INSTALL_append = "kernel-modules" in local.conf.
> When i build with  bitbake core-image-minimal command this kernel
> module is loading.while i build with bitbake atmel-qt5-demo-image
> command kernel module is not loading.
> Please tell us what is the issue.

Here is what local.conf I am using as included minimal kernel source
tree (also with systemd included). Please, try to experiment with it!
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/local.conf_full.

I use to compile the YOCTO Warrior minimal system for BBB the following command:
bitbake -k core-image-minimal

Hope this helps!

Best Regards,
Zoran


On Fri, Jun 28, 2019 at 11:41 AM ChenQi <Qi.Chen at windriver.com> wrote:
>
> Forward to this yocto mailing list.
> When you have problems regarding yocto, use this mailing list.
>
> Regards,
> Chen Qi
>
> On 06/27/2019 06:57 PM, Pawan Badganchi wrote:
>
> Hello sir,
>
>            I am adding IMAGE_INSTALL_append = "kernel-modules" in local.conf.When i build with  bitbake core-image-minimal command this kernel module is loading.while i build with bitbake atmel-qt5-demo-image command kernel module is not loading.
>
>           Please tell us what is the issue.
>
> Thanks & Regards,
>
> Pawan
>
>
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From zoran.stojsavljevic at gmail.com  Fri Jun 28 07:01:22 2019
From: zoran.stojsavljevic at gmail.com (Zoran Stojsavljevic)
Date: Fri, 28 Jun 2019 16:01:22 +0200
Subject: [yocto] Copying the binaries to an SD card after bulding with
	Yocto
In-Reply-To: <CAEmXcAzx7i7ZKdgsfxJ4ChZ_jWAcTFZCHBp2Hp2MCaQVFdHrCw@mail.gmail.com>
References: <CAEmXcAzx7i7ZKdgsfxJ4ChZ_jWAcTFZCHBp2Hp2MCaQVFdHrCw@mail.gmail.com>
Message-ID: <CAGAf8LwsGwTTKOSwDST4xdPhv0Gbg=7tPKdnML+2P_qpU=E0YA@mail.gmail.com>

>> ~/bbb/meta-bbb/scripts$ export OETMP=/oe7/bbb/tmp-warrior
>> Then run the copy_boot.sh script passing the location of SD card

I forgot how inheritance schema works with shells. When you run
copy_boot.sh script, it'll spawn for you new shell, and, IIRC, it
should inherit OETMP from parent shell. You can try to experiment, and
export OETMP command embed into copy_boot.sh file/script, and see what
is happening. You also can, as first command after #!/bin/bash, to
issue env command, and see what variables you have inherited from
parent shell.

In my opinion, this problem has very little to do with YOCTO building
system... Am I really (!) correct?

Zoran
_______

On Fri, Jun 28, 2019 at 3:42 PM danwe <daniel.wenninger92 at gmail.com> wrote:
>
> Hi,
>
> I have successfully build BeagleBone systems with Yocto.
> I have used this site:
> https://jumpnowtek.com/beaglebone/BeagleBone-Systems-with-Yocto.html
>
> Now I need to copy the binaries to an SD card and have a question to the following:
> In the instruction I can read the following:
> ``````````````````````````
> This copy_boot.sh script needs to know the TMPDIR to find the binaries. It looks for an environment variable called OETMP.
>
> For instance, if I had this in the local.conf
>
> TMPDIR = "/oe7/bbb/tmp-warrior"
>
> Then I would export this environment variable before running copy_boot.sh
>
> ~/bbb/meta-bbb/scripts$ export OETMP=/oe7/bbb/tmp-warrior
>
> Then run the copy_boot.sh script passing the location of SD card
>
> ~/bbb/meta-bbb/scripts$ ./copy_boot.sh sdb
> ```````````````````````
>
> I did that but it shows me the following error:
> OETMP: /oe7/bbb/tmp-warrior
> Directory not found: /oe7/bbb/tmp-warrior/deploy/images/beaglebone
>
> So my question is if I need to uncomment TMPDIR = "/oe7/bbb/tmp-warrior" in my local.conf when doing this or not? --> I tried both.
>
> So my copy_boot.sh looks for an environment variable called OETMP. And OETMP should know the TMPDIR (directory). But what should I export?
>
> Thanks.
>
> Daniel
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From daniel.wenninger92 at gmail.com  Fri Jun 28 07:13:12 2019
From: daniel.wenninger92 at gmail.com (danwe)
Date: Fri, 28 Jun 2019 16:13:12 +0200
Subject: [yocto] Copying the binaries to an SD card after bulding with
	Yocto
In-Reply-To: <CAGAf8LwsGwTTKOSwDST4xdPhv0Gbg=7tPKdnML+2P_qpU=E0YA@mail.gmail.com>
References: <CAEmXcAzx7i7ZKdgsfxJ4ChZ_jWAcTFZCHBp2Hp2MCaQVFdHrCw@mail.gmail.com>
	<CAGAf8LwsGwTTKOSwDST4xdPhv0Gbg=7tPKdnML+2P_qpU=E0YA@mail.gmail.com>
Message-ID: <CAEmXcAwovn3nh+NWxGLjJpq-c5LrxvyUPDVHAR+fpnt+=2V+-w@mail.gmail.com>

I have just asked that question because I built with Yocto and thought that
someone had this problem before or did use my written website.
So I don't really understand what the diretory: /oe7/bbb/tmp-warrior is
used for because I do not see it...

Thanks.

Daniel

Am Fr., 28. Juni 2019 um 16:01 Uhr schrieb Zoran Stojsavljevic <
zoran.stojsavljevic at gmail.com>:

> >> ~/bbb/meta-bbb/scripts$ export OETMP=/oe7/bbb/tmp-warrior
> >> Then run the copy_boot.sh script passing the location of SD card
>
> I forgot how inheritance schema works with shells. When you run
> copy_boot.sh script, it'll spawn for you new shell, and, IIRC, it
> should inherit OETMP from parent shell. You can try to experiment, and
> export OETMP command embed into copy_boot.sh file/script, and see what
> is happening. You also can, as first command after #!/bin/bash, to
> issue env command, and see what variables you have inherited from
> parent shell.
>
> In my opinion, this problem has very little to do with YOCTO building
> system... Am I really (!) correct?
>
> Zoran
> _______
>
> On Fri, Jun 28, 2019 at 3:42 PM danwe <daniel.wenninger92 at gmail.com>
> wrote:
> >
> > Hi,
> >
> > I have successfully build BeagleBone systems with Yocto.
> > I have used this site:
> > https://jumpnowtek.com/beaglebone/BeagleBone-Systems-with-Yocto.html
> >
> > Now I need to copy the binaries to an SD card and have a question to the
> following:
> > In the instruction I can read the following:
> > ``````````````````````````
> > This copy_boot.sh script needs to know the TMPDIR to find the binaries.
> It looks for an environment variable called OETMP.
> >
> > For instance, if I had this in the local.conf
> >
> > TMPDIR = "/oe7/bbb/tmp-warrior"
> >
> > Then I would export this environment variable before running copy_boot.sh
> >
> > ~/bbb/meta-bbb/scripts$ export OETMP=/oe7/bbb/tmp-warrior
> >
> > Then run the copy_boot.sh script passing the location of SD card
> >
> > ~/bbb/meta-bbb/scripts$ ./copy_boot.sh sdb
> > ```````````````````````
> >
> > I did that but it shows me the following error:
> > OETMP: /oe7/bbb/tmp-warrior
> > Directory not found: /oe7/bbb/tmp-warrior/deploy/images/beaglebone
> >
> > So my question is if I need to uncomment TMPDIR = "/oe7/bbb/tmp-warrior"
> in my local.conf when doing this or not? --> I tried both.
> >
> > So my copy_boot.sh looks for an environment variable called OETMP. And
> OETMP should know the TMPDIR (directory). But what should I export?
> >
> > Thanks.
> >
> > Daniel
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/2ca2d2b0/attachment.html>

From aaron.biver at gmail.com  Fri Jun 28 09:44:40 2019
From: aaron.biver at gmail.com (Aaron Biver)
Date: Fri, 28 Jun 2019 12:44:40 -0400
Subject: [yocto] Syntax for zero-padding a number in a recipe?
Message-ID: <CAMd7AX9SH60WPAhR87p=Za17rDOCf0CMsp3S7LFbgrT9Y+c2RQ@mail.gmail.com>

Is there such a thing as zero padding a number in a recipe (or vice versa?
I'd be just as happy starting with a zero-padded number, and converting it
to non-zero-padded.
The crux of the dilemma is that I must have zero-padding for file-naming,
but I CAN'T have zero padding in these numbers when I pass them to the C
code (or the C code treats them as octal).

I'd like to start with:
VERSION_MAJOR="1"
VERSION_MINOR="19"

And turn this into "01" and "19" for purposes of naming the output file
from the recipe.

I've tried the bash-style printf -v, but the recipe kicks the printf lines
out with a parse error.

VERSION_MAJOR="01"
VERSION_MINOR="19"

VERSION_MAJOR_STR=""
VERSION_MINOR_STR=""

printf -v VERSION_MAJOR_STR "%02d" VERSION_MAJOR
printf -v VERSION_MINOR_STR "%02d" VERSION_MINOR
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/bb886790/attachment.html>

From aaron.biver at gmail.com  Fri Jun 28 11:33:48 2019
From: aaron.biver at gmail.com (Aaron Biver)
Date: Fri, 28 Jun 2019 14:33:48 -0400
Subject: [yocto] Creating a file within a recipe
Message-ID: <CAMd7AX9bg5u+Wm=bWbbW7_0A06Ko6njP9OuE96+-W1PxJjugUQ@mail.gmail.com>

I'd like to be able to create a file using the cat command in a recipe.
The sub-goal is to have the file created somewhere I can actually find it:

do_create_tebf0808() {
cat > tebf0808.bif <<EOF
all:
{
    ${LATEST_TEBF0808_FW}
}
EOF
}

This fails at the "EOF" line:
ERROR: ParseError at ...firmware.bb:43: unparsed line: 'EOF'
                         | ETA:  --:--:--

Maybe sed would work better?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/853d4132/attachment-0001.html>

From ross.burton at intel.com  Fri Jun 28 12:53:34 2019
From: ross.burton at intel.com (Burton, Ross)
Date: Fri, 28 Jun 2019 20:53:34 +0100
Subject: [yocto] Creating a file within a recipe
In-Reply-To: <CAMd7AX9bg5u+Wm=bWbbW7_0A06Ko6njP9OuE96+-W1PxJjugUQ@mail.gmail.com>
References: <CAMd7AX9bg5u+Wm=bWbbW7_0A06Ko6njP9OuE96+-W1PxJjugUQ@mail.gmail.com>
Message-ID: <CAJTo0LaYOfqUoqwV257E60ZSZPzHBZ9pCUM6q0fckE8MLVnSeQ@mail.gmail.com>

The bash parser does have some bugs, and I think you just found one.
Probably easier to have a template on disk in SRC_URI, and sed in the
value you want.

Ross

On Fri, 28 Jun 2019 at 19:35, Aaron Biver <aaron.biver at gmail.com> wrote:
>
> I'd like to be able to create a file using the cat command in a recipe.  The sub-goal is to have the file created somewhere I can actually find it:
>
> do_create_tebf0808() {
> cat > tebf0808.bif <<EOF
> all:
> {
>     ${LATEST_TEBF0808_FW}
> }
> EOF
> }
>
> This fails at the "EOF" line:
> ERROR: ParseError at ...firmware.bb:43: unparsed line: 'EOF'                                        | ETA:  --:--:--
>
> Maybe sed would work better?
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

From aaron.biver at gmail.com  Fri Jun 28 12:57:51 2019
From: aaron.biver at gmail.com (Aaron Biver)
Date: Fri, 28 Jun 2019 15:57:51 -0400
Subject: [yocto] Creating a file within a recipe
In-Reply-To: <CAJTo0LaYOfqUoqwV257E60ZSZPzHBZ9pCUM6q0fckE8MLVnSeQ@mail.gmail.com>
References: <CAMd7AX9bg5u+Wm=bWbbW7_0A06Ko6njP9OuE96+-W1PxJjugUQ@mail.gmail.com>
	<CAJTo0LaYOfqUoqwV257E60ZSZPzHBZ9pCUM6q0fckE8MLVnSeQ@mail.gmail.com>
Message-ID: <CAMd7AX_DUwW_NkjBGAnB9YzjJ8_cYE-ftT7oc4ZCTyWmb7Pwkw@mail.gmail.com>

That seems to work.  Thanks!

On Fri, Jun 28, 2019 at 3:53 PM Burton, Ross <ross.burton at intel.com> wrote:

> The bash parser does have some bugs, and I think you just found one.
> Probably easier to have a template on disk in SRC_URI, and sed in the
> value you want.
>
> Ross
>
> On Fri, 28 Jun 2019 at 19:35, Aaron Biver <aaron.biver at gmail.com> wrote:
> >
> > I'd like to be able to create a file using the cat command in a recipe.
> The sub-goal is to have the file created somewhere I can actually find it:
> >
> > do_create_tebf0808() {
> > cat > tebf0808.bif <<EOF
> > all:
> > {
> >     ${LATEST_TEBF0808_FW}
> > }
> > EOF
> > }
> >
> > This fails at the "EOF" line:
> > ERROR: ParseError at ...firmware.bb:43: unparsed line: 'EOF'
>                             | ETA:  --:--:--
> >
> > Maybe sed would work better?
> >
> >
> > --
> > _______________________________________________
> > yocto mailing list
> > yocto at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/71e53160/attachment.html>

From ch at denx.de  Fri Jun 28 13:48:06 2019
From: ch at denx.de (Claudius Heine)
Date: Fri, 28 Jun 2019 22:48:06 +0200
Subject: [yocto] Syntax for zero-padding a number in a recipe?
In-Reply-To: <CAMd7AX9SH60WPAhR87p=Za17rDOCf0CMsp3S7LFbgrT9Y+c2RQ@mail.gmail.com>
References: <CAMd7AX9SH60WPAhR87p=Za17rDOCf0CMsp3S7LFbgrT9Y+c2RQ@mail.gmail.com>
Message-ID: <156175488609.25365.211872127310867605@ardipi>

Hi,

Quoting Aaron Biver (2019-06-28 18:44:40)
> Is there such a thing as zero padding a number in a recipe (or vice versa?
> I'd be just as happy starting with a zero-padded number, and converting it
> to non-zero-padded.

In bitbake you could do this with inline python:

	NUMBER = "1"
	NUMBER_PADDED = "${@"{:02d}".format(d.getVar("NUMBER", True))}"
	NUMBER_PADDED2 = "0012"
	NUMBER2 = "${@str(int(d.getVar("NUMBER_PADDED2", True)))}"

I have not tested this and it could possible be done more elegant, but
it should work.

regards,
Claudius

> The crux of the dilemma is that I must have zero-padding for file-naming,
> but I CAN'T have zero padding in these numbers when I pass them to the C
> code (or the C code treats them as octal).
> 
> I'd like to start with:
> VERSION_MAJOR="1"
> VERSION_MINOR="19"
> 
> And turn this into "01" and "19" for purposes of naming the output file
> from the recipe.
> 
> I've tried the bash-style printf -v, but the recipe kicks the printf lines
> out with a parse error.
> 
> VERSION_MAJOR="01"
> VERSION_MINOR="19"
> 
> VERSION_MAJOR_STR=""
> VERSION_MINOR_STR=""
> 
> printf -v VERSION_MAJOR_STR "%02d" VERSION_MAJOR
> printf -v VERSION_MINOR_STR "%02d" VERSION_MINOR
> 
> 
> -- 
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch at denx.de

           PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
                             Keyserver: hkp://pool.sks-keyservers.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/ead1e77a/attachment.pgp>

From sjolley.yp.pm at gmail.com  Sat Jun 29 09:11:48 2019
From: sjolley.yp.pm at gmail.com (sjolley.yp.pm at gmail.com)
Date: Sat, 29 Jun 2019 09:11:48 -0700
Subject: [yocto] Meetings next week.
Message-ID: <0aa501d52e95$5bd1ab50$137501f0$@gmail.com>

All,

 

Due to the 4th of July holiday next week.  Some meetings will be changed.

 

Triage will be canceled on the 4th..  Next Bug Triage meeting Thursday will
be July 11th at 7:30am PDT (https://zoom.us/j/454367603)

Monthly Project Meeting will still be Tuesday July 2nd at 8am PDT (
<https://zoom.us/j/990892712> https://zoom.us/j/990892712) 

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*    Cell:                (208) 244-4460

* Email:               <mailto:sjolley.yp.pm at gmail.com>
sjolley.yp.pm at gmail.com

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190629/c257e9c6/attachment-0001.html>

From akuster808 at gmail.com  Sun Jun 30 12:11:47 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 30 Jun 2019 12:11:47 -0700
Subject: [yocto] [meta-security-compliance][PATCH 1/2] lynis: update to 2.7.5
Message-ID: <20190630191148.30104-1-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 .../recipes-auditors/lynis/{lynis_2.7.2.bb => lynis_2.7.5.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta-security-compliance/recipes-auditors/lynis/{lynis_2.7.2.bb => lynis_2.7.5.bb} (89%)

diff --git a/meta-security-compliance/recipes-auditors/lynis/lynis_2.7.2.bb b/meta-security-compliance/recipes-auditors/lynis/lynis_2.7.5.bb
similarity index 89%
rename from meta-security-compliance/recipes-auditors/lynis/lynis_2.7.2.bb
rename to meta-security-compliance/recipes-auditors/lynis/lynis_2.7.5.bb
index 3ba82f9..21e4517 100644
--- a/meta-security-compliance/recipes-auditors/lynis/lynis_2.7.2.bb
+++ b/meta-security-compliance/recipes-auditors/lynis/lynis_2.7.5.bb
@@ -8,8 +8,8 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=3edd6782854304fd11da4975ab9799c1"
 
 SRC_URI = "https://cisofy.com/files/${BPN}-${PV}.tar.gz"
 
-SRC_URI[md5sum] = "3422cee3b12fc33338fcde003d65e234"
-SRC_URI[sha256sum] = "fde6ccf8d6ec0ae1e9c9f4a6d640cddcde4bf7a92f8437d47d16a5477e21bfda"
+SRC_URI[md5sum] = "fb527b6976e70a6bcd57036c9cddc242"
+SRC_URI[sha256sum] = "3d27ade73a5c1248925ad9c060024940ce5d2029f40aaa901f43314888fe324d"
 
 S = "${WORKDIR}/${BPN}"
 
-- 
2.17.1


From akuster808 at gmail.com  Sun Jun 30 12:11:48 2019
From: akuster808 at gmail.com (Armin Kuster)
Date: Sun, 30 Jun 2019 12:11:48 -0700
Subject: [yocto] [meta-security-compliance][PATCH 2/2]
	meta-security-compliance: update README
In-Reply-To: <20190630191148.30104-1-akuster808@gmail.com>
References: <20190630191148.30104-1-akuster808@gmail.com>
Message-ID: <20190630191148.30104-2-akuster808@gmail.com>

Signed-off-by: Armin Kuster <akuster808 at gmail.com>
---
 meta-security-compliance/README | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-security-compliance/README b/meta-security-compliance/README
index b29c143..320f856 100644
--- a/meta-security-compliance/README
+++ b/meta-security-compliance/README
@@ -28,9 +28,9 @@ Maintenance
 Send pull requests, patches, comments or questions to yocto at yoctoproject.org
 
 When sending single patches, please using something like:
-'git send-email -1 --to yocto at yoctoproject.org --subject-prefix=meta-security][PATCH'
+'git send-email -1 --to yocto at yoctoproject.org --subject-prefix=meta-security-compliance][PATCH'
 
-Layer Maintainer: Armin Kuster <akuster at mvista.com>
+Layer Maintainer: Armin Kuster <akuster808 at gmail.com>
 
 
 License
-- 
2.17.1


From anuj.mittal at intel.com  Sun Jun 30 15:46:51 2019
From: anuj.mittal at intel.com (Anuj Mittal)
Date: Mon, 1 Jul 2019 06:46:51 +0800
Subject: [yocto] [meta-dpdk][PATCH] dpdk: Remove 18.05
In-Reply-To: <1561455820-9421-1-git-send-email-zhe.he@windriver.com>
References: <1561455820-9421-1-git-send-email-zhe.he@windriver.com>
Message-ID: <45fd1791-5a3e-9288-778d-c4418167797c@intel.com>

On 25-Jun-19 05:43 PM, zhe.he at windriver.com wrote:
> From: He Zhe <zhe.he at windriver.com>
> 
> We have already had 18.11 and 18.05 is not a stable version.
> 
> Signed-off-by: He Zhe <zhe.he at windriver.com>
> ---
>   recipes-extended/dpdk/dpdk_18.05.bb | 15 ---------------
>   1 file changed, 15 deletions(-)
>   delete mode 100644 recipes-extended/dpdk/dpdk_18.05.bb

Can you please also remove the patches that are specific to this version?

Thanks,

Anuj

From mingli.yu at windriver.com  Sun Jun 30 19:08:21 2019
From: mingli.yu at windriver.com (mingli.yu at windriver.com)
Date: Mon, 1 Jul 2019 10:08:21 +0800
Subject: [yocto] [meta-cloud-services][PATCH 1/2] meta-cloud-services: add
	layer depends on networking-layer
Message-ID: <1561946902-247680-1-git-send-email-mingli.yu@windriver.com>

From: Mingli Yu <Mingli.Yu at windriver.com>

Since spice of meta-cloud-services depends on
cyrus-sasl which comes from networking-layer,
add missing layer depends back.

Signed-off-by: Mingli Yu <Mingli.Yu at windriver.com>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 203f9db..2cfb75f 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -8,4 +8,4 @@ BBFILE_COLLECTIONS += "cloud-services-layer"
 BBFILE_PATTERN_cloud-services-layer := "^${LAYERDIR}/"
 BBFILE_PRIORITY_cloud-services-layer = "5"
 LAYERSERIES_COMPAT_cloud-services-layer = "thud warrior"
-LAYERDEPENDS_cloud-services-layer = "core filesystems-layer"
+LAYERDEPENDS_cloud-services-layer = "core filesystems-layer networking-layer"
-- 
2.7.4


From mingli.yu at windriver.com  Sun Jun 30 19:08:22 2019
From: mingli.yu at windriver.com (mingli.yu at windriver.com)
Date: Mon, 1 Jul 2019 10:08:22 +0800
Subject: [yocto] [meta-cloud-services][PATCH 2/2] nss-pam-ldapd: add
	required distro feature check for pam
In-Reply-To: <1561946902-247680-1-git-send-email-mingli.yu@windriver.com>
References: <1561946902-247680-1-git-send-email-mingli.yu@windriver.com>
Message-ID: <1561946902-247680-2-git-send-email-mingli.yu@windriver.com>

From: Mingli Yu <Mingli.Yu at windriver.com>

As nss-pam-ldapd depends on libpam, it should do
required distro feature check for pam.

Signed-off-by: Mingli Yu <Mingli.Yu at windriver.com>
---
 recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb b/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb
index 404aeca..dfa562f 100644
--- a/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb
+++ b/recipes-support/nss-pam-ldapd/nss-pam-ldapd_0.9.8.bb
@@ -20,7 +20,8 @@ SRC_URI = "\
 	file://nslcd.service \
 	"
 
-inherit autotools
+inherit autotools distro_features_check
+REQUIRED_DISTRO_FEATURES = "pam"
 
 SRC_URI[md5sum] = "8c99fdc54f4bf9aca8c5f53fdb1403ff"
 SRC_URI[sha256sum] = "ef7362e7f2003da8c7beb7bcc03c30494acf712625aaac8badc6e7eb16f3453f"
-- 
2.7.4


From zhe.he at windriver.com  Sun Jun 30 20:00:33 2019
From: zhe.he at windriver.com (zhe.he at windriver.com)
Date: Mon, 1 Jul 2019 11:00:33 +0800
Subject: [yocto] [meta-dpdk][PATCH v2] dpdk: Remove 18.05
Message-ID: <1561950033-256966-1-git-send-email-zhe.he@windriver.com>

From: He Zhe <zhe.he at windriver.com>

We have already had 18.11 and 18.05 is not a stable version.
This patch also removes the patch no longer needed.

Signed-off-by: He Zhe <zhe.he at windriver.com>
---
v2: Remove the patch no longer needed.

 ...2-dpdk-fix-installation-warning-and-issue.patch | 79 ----------------------
 recipes-extended/dpdk/dpdk_18.05.bb                | 15 ----
 2 files changed, 94 deletions(-)
 delete mode 100644 recipes-extended/dpdk/dpdk/dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch
 delete mode 100644 recipes-extended/dpdk/dpdk_18.05.bb

diff --git a/recipes-extended/dpdk/dpdk/dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch b/recipes-extended/dpdk/dpdk/dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch
deleted file mode 100644
index 0505888..0000000
--- a/recipes-extended/dpdk/dpdk/dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch
+++ /dev/null
@@ -1,79 +0,0 @@
-From 0be350c3b04d83ea9182f45936ef3219aed5c0c1 Mon Sep 17 00:00:00 2001
-From: Shashwat Pandey <shashwatx.p at intel.com>
-Date: Mon, 20 Feb 2017 15:46:22 +0800
-Subject: [PATCH] dpdk: fix installation warning and issue
-
-Upstream-Status: Inappropriate [configuration]
-
-Ensure that all compiled libs should be installed to correct location.
-For cross compiling cp -r and extra tar flags used to avoid  QA warning
-[host-user-contaminated].
-Added excluded files from bin and removing mk and app/dpdk-pmdinfogen files
-installation since it is not needed as a part of image.
-
-Signed-off-by: Shashwat Pandey <shashwatx.p at intel.com>
-
----
- mk/rte.sdkinstall.mk | 29 ++++++++++++++---------------
- 1 file changed, 14 insertions(+), 15 deletions(-)
-
-diff --git a/mk/rte.sdkinstall.mk b/mk/rte.sdkinstall.mk
-index 4e97feff9fde..42625333a4e2 100644
---- a/mk/rte.sdkinstall.mk
-+++ b/mk/rte.sdkinstall.mk
-@@ -115,16 +115,17 @@ endif
- 
- install-runtime:
- 	$(Q)$(call rte_mkdir, $(DESTDIR)$(libdir))
--	$(Q)cp -a    $O/lib/* $(DESTDIR)$(libdir)
-+	$(Q)cp -r    $O/lib/* $(DESTDIR)$(libdir)
- 	$(Q)$(call rte_mkdir, $(DESTDIR)$(bindir))
--	$(Q)tar -cf -      -C $O --exclude 'app/*.map' \
--		--exclude app/dpdk-pmdinfogen \
--		--exclude 'app/cmdline*' --exclude app/test \
--		--exclude app/testacl --exclude app/testpipeline app | \
--	    tar -xf -      -C $(DESTDIR)$(bindir) --strip-components=1 \
--		--keep-newer-files
-+	$(Q)tar -cf -      -C $O --exclude app/dpdk-pmdinfogen app | \
-+	tar -xf -      -C $(DESTDIR)$(bindir) --no-same-owner --no-same-permissions \
-+		--strip-components=1 --keep-newer-files --warning=no-ignore-newer
- 	$(Q)$(call rte_mkdir,      $(DESTDIR)$(datadir))
--	$(Q)cp -a $(RTE_SDK)/usertools $(DESTDIR)$(datadir)
-+	$(Q)cp -r $(RTE_SDK)/usertools $(DESTDIR)$(datadir)
-+	$(Q)$(call rte_symlink,    $(DESTDIR)$(datadir)/usertools/dpdk-setup.sh, \
-+	                           $(DESTDIR)$(datadir)/usertools/setup.sh)
-+	$(Q)$(call rte_symlink,    $(DESTDIR)$(datadir)/usertools/dpdk-devbind.py, \
-+	                           $(DESTDIR)$(datadir)/usertools/dpdk_nic_bind.py)
- 	$(Q)$(call rte_mkdir,      $(DESTDIR)$(sbindir))
- 	$(Q)$(call rte_symlink,    $(DESTDIR)$(datadir)/usertools/dpdk-devbind.py, \
- 	                           $(DESTDIR)$(sbindir)/dpdk-devbind)
-@@ -142,7 +143,7 @@ endif
- install-kmod:
- ifneq ($(wildcard $O/kmod/*),)
- 	$(Q)$(call rte_mkdir, $(DESTDIR)$(kerneldir))
--	$(Q)cp -a   $O/kmod/* $(DESTDIR)$(kerneldir)
-+	$(Q)cp -r   $O/kmod/* $(DESTDIR)$(kerneldir)
- endif
- 
- install-sdk:
-@@ -151,11 +152,9 @@ install-sdk:
- 	    tar -xf -      -C $(DESTDIR)$(includedir) --strip-components=1 \
- 		--keep-newer-files
- 	$(Q)$(call rte_mkdir,                            $(DESTDIR)$(sdkdir))
--	$(Q)cp -a               $(RTE_SDK)/mk            $(DESTDIR)$(sdkdir)
--	$(Q)cp -a               $(RTE_SDK)/buildtools    $(DESTDIR)$(sdkdir)
--	$(Q)$(call rte_mkdir,                            $(DESTDIR)$(targetdir)/app)
--	$(Q)cp -a               $O/.config               $(DESTDIR)$(targetdir)
--	$(Q)cp -a               $O/app/dpdk-pmdinfogen   $(DESTDIR)$(targetdir)/app
-+	$(Q)cp -r               $(RTE_SDK)/buildtools       $(DESTDIR)$(sdkdir)
-+	$(Q)$(call rte_mkdir,                            $(DESTDIR)$(targetdir))
-+	$(Q)cp -r               $O/.config               $(DESTDIR)$(targetdir)
- 	$(Q)$(call rte_symlink, $(DESTDIR)$(includedir), $(DESTDIR)$(targetdir)/include)
- 	$(Q)$(call rte_symlink, $(DESTDIR)$(libdir),     $(DESTDIR)$(targetdir)/lib)
- 
-@@ -171,4 +170,4 @@ ifneq ($(wildcard $O/doc/*/*/*pdf),)
- 	$(Q)cp -a $O/doc/*/*/*pdf $(DESTDIR)$(docdir)/guides
- endif
- 	$(Q)$(call rte_mkdir,         $(DESTDIR)$(datadir))
--	$(Q)cp -a $(RTE_SDK)/examples $(DESTDIR)$(datadir)
-+	$(Q)cp -r $(RTE_SDK)/examples $(DESTDIR)$(datadir)
diff --git a/recipes-extended/dpdk/dpdk_18.05.bb b/recipes-extended/dpdk/dpdk_18.05.bb
deleted file mode 100644
index b6897a8..0000000
--- a/recipes-extended/dpdk/dpdk_18.05.bb
+++ /dev/null
@@ -1,15 +0,0 @@
-include dpdk.inc
-
-SRCREV = "a5dce55556286cc56655320d975c67b0dbe08693"
-
-LICENSE = "BSD-3-Clause & LGPLv2.1 & GPLv2"
-LIC_FILES_CHKSUM = "file://license/gpl-2.0.txt;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-                    file://license/lgpl-2.1.txt;md5=4b54a1fd55a448865a0b32d41598759d \
-                    file://license/bsd-3-clause.txt;md5=0f00d99239d922ffd13cabef83b33444"
-
-SRC_URI += "\
-            file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch \
-            file://dpdk-17.02-dpdk-fix-installation-warning-and-issue.patch \
-            file://dpdk-16.04-dpdk-enable-ip_fragmentation-in-common_base-config.patch \
-            file://0001-examples-Fix-maybe-uninitialized-warning.patch \
-            "
-- 
2.7.4


From zhe.he at windriver.com  Sun Jun 30 20:00:53 2019
From: zhe.he at windriver.com (He Zhe)
Date: Mon, 1 Jul 2019 11:00:53 +0800
Subject: [yocto] [meta-dpdk][PATCH] dpdk: Remove 18.05
In-Reply-To: <45fd1791-5a3e-9288-778d-c4418167797c@intel.com>
References: <1561455820-9421-1-git-send-email-zhe.he@windriver.com>
	<45fd1791-5a3e-9288-778d-c4418167797c@intel.com>
Message-ID: <db007c98-ab03-9ed6-86c6-61e890768ab7@windriver.com>



On 7/1/19 6:46 AM, Anuj Mittal wrote:
> On 25-Jun-19 05:43 PM, zhe.he at windriver.com wrote:
>> From: He Zhe <zhe.he at windriver.com>
>>
>> We have already had 18.11 and 18.05 is not a stable version.
>>
>> Signed-off-by: He Zhe <zhe.he at windriver.com>
>> ---
>> ? recipes-extended/dpdk/dpdk_18.05.bb | 15 ---------------
>> ? 1 file changed, 15 deletions(-)
>> ? delete mode 100644 recipes-extended/dpdk/dpdk_18.05.bb
>
> Can you please also remove the patches that are specific to this version?

OK. v2 sent.

Zhe

>
> Thanks,
>
> Anuj
>


From pokybuild at centos7-ty-4.yocto.io  Sun Jun 30 20:08:44 2019
From: pokybuild at centos7-ty-4.yocto.io (Poky Build User)
Date: Mon,  1 Jul 2019 03:08:44 +0000 (GMT)
Subject: [yocto] QA notification for completed autobuilder build
	(yocto-2.7.1.rc1)
Message-ID: <20190701030845.0C5E523F54@centos7-ty-4.yocto.io>


A build flagged for QA (yocto-2.7.1.rc1) was completed on the autobuilder and is available at:


    https://autobuilder.yocto.io/pub/releases/yocto-2.7.1.rc1


Build hash information: 

bitbake: 34ed28a412af642a993642c14bd8b95d5ef22cd8
meta-gplv2: 460ba027fd79b99151f95c826446f3aead5d17ff
meta-intel: e84c763090f91196a5d234f62ee39bcf296c7f2e
meta-mingw: 10695afe8cd406844e0d0dd868c11677e07557d4
oecore: 886deb4d0919c7a81036ea14fb8fd0f1619dd3a3
poky: 38d5c8ea98cfa49825c473eba8984c12edf062be



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie at linuxfoundation.org


 

From balazovic.peter at gmail.com  Tue Jun 25 00:00:49 2019
From: balazovic.peter at gmail.com (Peter Balazovic)
Date: Tue, 25 Jun 2019 09:00:49 +0200
Subject: [yocto] Issue on do_sdk_depends: The file ... is installed by both.
Message-ID: <CAFq4t4houL31Cf=gDwGx6JsVXRdrAeL-7ORkBOO4pa=otz6BDw@mail.gmail.com>

Hello guys

I'm trying to generate extended SDK under and generating extended SDK I am
getting the erros such as

ERROR: image-qt5-1.0-r0 do_sdk_depends: The file
/usr/include/tensorflow/contrib/lite/string_util.h is installed by both
tensorflow and tensorflow-lite, aborting
ERROR: image-qt5-1.0-r0 do_sdk_depends:
ERROR: image-qt5-1.0-r0 do_sdk_depends: Function failed:
extend_recipe_sysroot

can you help me identify an issue on this fail?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190625/bada941f/attachment-0001.html>

From daniel.wenninger92 at gmail.com  Wed Jun 26 08:23:07 2019
From: daniel.wenninger92 at gmail.com (danwe)
Date: Wed, 26 Jun 2019 17:23:07 +0200
Subject: [yocto] bitbak command: No recipe available for
In-Reply-To: <CAEmXcAy0wo=CnCgCWREHKugwrfWWL2RdPtZ9dZWGuB2NTPDoEA@mail.gmail.com>
References: <CAEmXcAy0wo=CnCgCWREHKugwrfWWL2RdPtZ9dZWGuB2NTPDoEA@mail.gmail.com>
Message-ID: <CAEmXcAxmtRtXSOf9dPD5gokFymDmCWNG9D55krgokOsCQ6GXXw@mail.gmail.com>

Hi,

while using the command:
daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake core-immage-full
cmdline
I get the following ouput:
````

Loading cache: 100% |############################################| Time:
0:00:03

Loaded 1358 entries from dependency cache.

Parsing recipes: 100% |##########################################| Time:
0:00:12

Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65
skipped, 0 masked, 0 errors.

ERROR: No recipes available for:

  /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend

  /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend

  /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend



Summary: There was 1 ERROR message shown, returning a non-zero exit code.
````

How can I solve this?

Thanks.

Daniel

Am Mi., 26. Juni 2019 um 17:11 Uhr schrieb danwe <
daniel.wenninger92 at gmail.com>:

> Hi,
>
> while using the command:
> daniel at daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake
> core-immage-full cmdline I get the following ouput:
> ````
>
> Loading cache: 100% |############################################| Time:
> 0:00:03
>
> Loaded 1358 entries from dependency cache.
>
> Parsing recipes: 100% |##########################################| Time:
> 0:00:12
>
> Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65
> skipped, 0 masked, 0 errors.
>
> ERROR: No recipes available for:
>
>   /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend
>
>   /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend
>
>   /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend
>
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> ````
>
> How can I solve this?
>
> Thanks.
>
> Daniel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190626/8284f722/attachment-0001.html>

From pawan.b at elpisitsolutions.com  Fri Jun 28 04:16:44 2019
From: pawan.b at elpisitsolutions.com (Pawan Badganchi)
Date: Fri, 28 Jun 2019 07:16:44 -0400 (EDT)
Subject: [yocto] [yocto-builds] Yocto build Issue
In-Reply-To: <5239a45d-0756-6c85-9b2d-218b34d9168c@windriver.com>
References: <980292376.238401.1561633028960@email.ionos.com>
	<5239a45d-0756-6c85-9b2d-218b34d9168c@windriver.com>
Message-ID: <570562183.566234.1561720604653@email.ionos.com>

An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190628/7a21262e/attachment-0001.html>

From pawan.b at elpisitsolutions.com  Sun Jun 30 22:18:09 2019
From: pawan.b at elpisitsolutions.com (Pawan Badganchi)
Date: Mon, 1 Jul 2019 01:18:09 -0400 (EDT)
Subject: [yocto] [yocto-builds] Yocto build Issue
In-Reply-To: <CAGAf8LxjwgmuH=uNU43x6=YkPzhpj5kjaR1Rd_mLcoyH3QVofA@mail.gmail.com>
References: <980292376.238401.1561633028960@email.ionos.com>
	<5239a45d-0756-6c85-9b2d-218b34d9168c@windriver.com>
	<CAGAf8LxjwgmuH=uNU43x6=YkPzhpj5kjaR1Rd_mLcoyH3QVofA@mail.gmail.com>
Message-ID: <1551414335.754087.1561958289026@email.ionos.com>

An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190701/099ee01a/attachment.html>