Re: [yocto] packaging documentation

[Steve Scott]

Hi Scott:

 

Yes, I’ve been searching in the mega manual, and I’ve read the section in the 
overview manual. The old OE Manual explanation was more what I was looking for. 
It seems that has been lost somewhere along the way. Filing a bug against the 
docs sounds like a good idea – I’m not sure how to do that.

 

Thanks.

 

-steve

 

From: Scott Rifenbark [mailto:srifenb...@gmail.com] 
Sent: Wednesday, March 13, 2019 8:42 AM
To: ssc...@san.rr.com
Cc: Yocto discussion list 
Subject: Re: [yocto] packaging documentation

 

Hi Steve, 

 

Have you found the YP Overview and Concepts Manual?  There is a fairly large 
section here - 
https://yoctoproject.org/docs/2.6.1/overview-manual/overview-manual.html#openembedded-build-system-build-concepts
 that covers build concepts in some detail.  This might help you.  

 

Another idea for finding topics in the YP manual set is to use the YP 
Mega-Manual 
(https://yoctoproject.org/docs/current/mega-manual/mega-manual.html), which is 
a compilation of the set of YP manuals.  You can search the entire set for 
terms (e.g. "packag").  It occurs a lot in the set but it is a way to find all 
the occurrences. 

 

If you still cannot find satisfactory explanation on how packages are 
generated, we can file a bug against the docs and get a good explanation in 
there.

 

Hope this helps, 

Scott

 

On Wed, Mar 13, 2019 at 9:21 AM Steve Scott mailto:ssc...@san.rr.com> > wrote:

Hi:

 

I’ve been trying to get a better understanding of how packages are generated by 
recipes. I found a fairly good explanation in an old OpenEmbedded User’s Manual 
(https://dominion.thruhere.net/koen/OE/OE-usermanual.html#recipes_packages). 
The manual is hard to find, and doesn’t appear to be archive on the 
openembedded site (https://www.openembedded.org/wiki/Documentation).

 

Can somebody point me to an equivalent discussion in the current Yocto project 
documentation?

 

Thanks.

 

-steve

 

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

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

[yocto] packaging documentation

[Steve Scott]

Hi:

 

I've been trying to get a better understanding of how packages are generated
by recipes. I found a fairly good explanation in an old OpenEmbedded User's
Manual
(https://dominion.thruhere.net/koen/OE/OE-usermanual.html#recipes_packages).
The manual is hard to find, and doesn't appear to be archive on the
openembedded site (https://www.openembedded.org/wiki/Documentation).

 

Can somebody point me to an equivalent discussion in the current Yocto
project documentation?

 

Thanks.

 

-steve

 

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

Re: [yocto] SRC_URI when there is a local mirror but no remote repo

[Steve Scott]

SRC_URI = "file://${TOPDIR}/../local_mirror/example-1.0.0.src.tar.gz" should
work, without need for do_unpack.

What error are you getting?

> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Edmund Nadolski
> Sent: Wednesday, March 06, 2019 11:52 AM
> To: Edmund Nadolski ;
> yocto@yoctoproject.org
> Subject: Re: [yocto] SRC_URI when there is a local mirror but no remote
repo
> 
> Friendly ping, any thoughts on this?
> 
> One thing I have noted - without the remote url, bitbake will not link the
file
> into DL_DIR or create a *.done file for it.
> 
> TIA,
> Ed
> 
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org  boun...@yoctoproject.org>
> > On Behalf Of Edmund Nadolski
> > Sent: Wednesday, February 27, 2019 3:00 PM
> > To: yocto@yoctoproject.org
> > Subject: [yocto] SRC_URI when there is a local mirror but no remote
> > repo
> >
> > Hi,
> >
> > Does Yocto/Bitbake support a way to set SRC_URI in a recipe when there
> > is no corresponding upstream remote (git://, https://, etc.) for a
*.tar.gz
> file?
> > IOW, I've configured for own_mirrors and set BB_NO_NETWORK=1, and
> my
> > *.tar.gz file only lives in the local_mirror directory.
> >
> > It looks to me like file:// thinks that the file always lives under
${S}.
> >
> > TIA,
> > Ed
> >
> > ...
> > # functional workaround
> > SRC_URI = " http://some.example.com/example-1.0.0.src.tar.gz;
> > ...
> >
> > do_unpack () {
> > # Unpack straight from the local mirror since there is no remote
> > tar xzf ${TOPDIR}/../local_mirror/example-1.0.0.src.tar.gz -C
> > ${S}
> >
> > do_install () {
> > install -d ${D}/${MY_DIR}
> > install -m 0744 ${S}/example/example.sh ${D}/${MY_DIR}
> >
> > --
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

[yocto] nativesdk questions

[Steve Scott]

Hi all:

I am using the jethro (2.0.1) version of yocto.

I added a shared library (foo.so) to our native sdk build by putting
BBCLASSEXTEND = "nativesdk"
in the foo.bb recipe, then 
TOOLCHAIN_HOST_TASK_append += " nativesdk-foo  nativesdk-foo-dev "
in our rootfs image recipe.

This had the effect of not only including my library and its header files,
but also a huge number of other
header files in my native sdk's
.../sysroots/x86_64-pokysdk-linux/usr/include
that weren't there previously. It looks like they are the header files for
the components of the GNU C library.

Questions:
1. What is causing all these additional header files to show up in my native
sdk usr/include directory?
2. Is there some way to turn this off?
3. Is the native toolchain  included in the native sdk (the cross compiler
tools
 are there, but I didn't see the native ones).
4. If the native toolchain isn't in the native sdk, how do I find the native
tool chain inside the Yocto tree?

Thanks.

-steve


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

Re: [yocto] [selinux] sumo compilation

[Steve Scott]

You may also need
PREFERRED_PROVIDER_virtual/refpolicy = "refpolicy-standard"
in local.conf. 

-steve

> -Original Message-
> From: Sinan Kaya [mailto:ok...@kernel.org]
> Sent: Thursday, October 18, 2018 8:06 AM
> To: ssc...@san.rr.com; 'Stefano Cappa' 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] [selinux] sumo compilation
> 
> Sorry for confusing names, not enough coffee yet...
> 
> I was trying to say that Steve's suggestion to use
> 
> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> 
> didn't work on sumo branch.
> 
> On 10/18/2018 10:49 AM, Sinan Kaya wrote:
> > CC'ing the selinux maintainers:
> >
> > I was told that using the master branch and reverting the e2fs change
> > (http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/commit/?id=78e
> > ca8242ea5397c4dc0654d62244453b4260151)
> > works on sumo.
> >
> > Stefano's suggestion unfortunately didn't work.
> >
> > Maybe, it is time to create the sumo branch?
> >
> > On 10/18/2018 9:48 AM, Steve Scott wrote:
> >> I did not try it on sumo.
> >>
> >>
> >> From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com]
> >> Sent: Wednesday, October 17, 2018 11:15 PM
> >> To: ssc...@san.rr.com
> >> Cc: Sinan Kaya ; yocto@yoctoproject.org
> >> Subject: Re: [yocto] [selinux] sumo compilation
> >>
> >>
> >> Exactly the same issue since September.
> >>
> >>
> >> Here is my discussion
> >> https://lists.yoctoproject.org/pipermail/yocto/2018-
> September/042711.html.
> >> With that trick did you find a solution also on sumo?
> >>
> >>
> >> Il gio 18 ott 2018, 01:42  >> <mailto:ssc...@san.rr.com> > ha
> >> scritto:
> >>
> >>
> >> It was broken in rocko too. I added this to local.conf to workaround the
> problem:
> >>
> >> PREFERRED_VERSION_refpolicy-standard = "2.20170204"
> >>
> >> -steve
> >>
> >>  Sinan Kaya mailto:ok...@kernel.org> > wrote:
> >>> Hi,
> >>>
> >>> We realized today that SELinux does not compile on sumo branch.
> >>>
> >>> Is it possible for someone to branch the last working version to a sumo
> branch?
> >>>
> >>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> >>>
> >>> NOTE: Running task 352 of 2707
> >>> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fspr
> >>> ogs_1.43.8.bb <http://e2fsprogs_1.43.8.bb> :do_patch)
> >>> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> >>> NOTE: Running task 1413 of 2707
> >>> (/sources/poky/meta/recipes-
> devtools/e2fsprogs/e2fsprogs_1.43.8.bb:d
> >>> o_patch)
> >>> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> >>> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt
> >>> --quiltrc Applying patch misc_create_inode.c-label_rootfs.patch
> >>> patching file misc/create_inode.c
> >>> Hunk #1 FAILED at 979.
> >>> Hunk #2 FAILED at 987.
> >>>
> >>> Sinan
> >>> --
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org <mailto:yocto@yoctoproject.org>
> >>> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >

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

Re: [yocto] [selinux] sumo compilation

[Steve Scott]

I did not try it on sumo. 

 

From: Stefano Cappa [mailto:stefano.cappa.k...@gmail.com] 
Sent: Wednesday, October 17, 2018 11:15 PM
To: ssc...@san.rr.com
Cc: Sinan Kaya ; yocto@yoctoproject.org
Subject: Re: [yocto] [selinux] sumo compilation

 

Exactly the same issue since September. 

 

Here is my discussion 
https://lists.yoctoproject.org/pipermail/yocto/2018-September/042711.html. With 
that trick did you find a solution also on sumo? 

 

Il gio 18 ott 2018, 01:42 mailto:ssc...@san.rr.com> > ha 
scritto:


It was broken in rocko too. I added this to local.conf to workaround the 
problem:

PREFERRED_VERSION_refpolicy-standard = "2.20170204"

-steve

 Sinan Kaya mailto:ok...@kernel.org> > wrote: 
> Hi,
> 
> We realized today that SELinux does not compile on sumo branch.
> 
> Is it possible for someone to branch the last working version to a sumo 
> branch?
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-selinux/refs/
> 
> NOTE: Running task 352 of 2707 
> (virtual:native:/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb
>   :do_patch)
> NOTE: recipe e2fsprogs-native-1.43.8-r0: task do_patch: Started
> NOTE: Running task 1413 of 2707 
> (/sources/poky/meta/recipes-devtools/e2fsprogs/e2fsprogs_1.43.8.bb:do_patch)
> NOTE: recipe e2fsprogs-1.43.8-r0: task do_patch: Started
> ERROR: e2fsprogs-native-1.43.8-r0 do_patch: Command Error: 'quilt --quiltrc
> Applying patch misc_create_inode.c-label_rootfs.patch
> patching file misc/create_inode.c
> Hunk #1 FAILED at 979.
> Hunk #2 FAILED at 987.
> 
> Sinan
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org  
> https://lists.yoctoproject.org/listinfo/yocto

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

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

Re: [yocto] how to install files in nativesdk

[Steve Scott]

Thanks Ross. That helped me pull it all together.

-steve

> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Monday, October 08, 2018 4:11 AM
> To: ssc...@san.rr.com
> Cc: Yocto-mailing-list 
> Subject: Re: [yocto] how to install files in nativesdk
> 
> On Sat, 6 Oct 2018 at 06:18, Steve Scott  wrote:
> > I am able to generate a standard SDK with native and target sysroots.
> > The target sysroot has header files for my custom libraries. The
> > header files are generally installed in
> > /usr/include/
> >
> > We use cmake and googletest running on the *host* for testing some of
> > our libraries. So I need to build googletest and the test apps using
> > the host (x86_64) tools. The test apps need to include the target's
> > library header files.
> >
> > I tried specifying the SDK's *target* usr/include as an include
> > directory to the compiler, but files in this tree preempted the
> > standard compiler (g++) system include files. I can avoid this problem
> > by installing the library header files under the SDK's native sysroot;
> > i.e. in /usr/include/
> > and setting this directory as an include directory on the compiler
> > command line.
> >
> > However, I cannot grok how to get these files into the SDK's native
> > tree. It seems related to
> >BBCLASSEXTEND = "native nativesdk"
> > but I'm just chasing my tail trying to figure out the magic incantation.
> >
> > Does anyone know how to do this? Or is there a better approach?
> 
> Assuming the recipe is correctly written, simply adding:
> 
> BBCLASSEXTEND = "native nativesdk"
> 
> Will give your recipe (eg foo.bb) native and nativesdk variant (foo-native and
> nativesdk-foo).  The class extension automatically changes the paths so in
> general that's all you need to do.  Then just add nativesdk-foo to your SDK
> using TOOLCHAIN_HOST_TASK_append = "
> nativesdk-foo".
> 
> Ross

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

[yocto] how to install files in nativesdk

[Steve Scott]

Hi:

I'm a list newbie, so let me know if this should be posted somewhere else.

I am able to generate a standard SDK with native and target
sysroots. The target sysroot has header files for my custom
libraries. The header files are generally installed in
/usr/include/  

We use cmake and googletest running on the *host* for testing some of
our libraries. So I need to build googletest and the test apps using the
host (x86_64) tools. The test apps need to include the target's library
header files.

I tried specifying the SDK's *target* usr/include as an include directory to
the compiler, but files in this tree preempted the standard compiler (g++)
system include files. I can avoid this problem by installing the library
header files under the SDK's native sysroot; i.e. in 
/usr/include/ 
and setting this directory as an include directory on the compiler
command line.

However, I cannot grok how to get these files into the SDK's native
tree. It seems related to  
   BBCLASSEXTEND = "native nativesdk"
but I'm just chasing my tail trying to figure out the magic incantation.

Does anyone know how to do this? Or is there a better approach?

Thanks.

-steve scott




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