Re: [yocto] FW: tentative list of vars to be dropped from variable glossary

[Scott Rifenbark]

See chapter 4 of the dev manual (
http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html) for
this adjustment.

Scott

On Thu, Mar 29, 2012 at 7:32 AM, Rifenbark, Scott M 
scott.m.rifenb...@intel.com wrote:



 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Thursday, March 29, 2012 6:48 AM
 To: Rudolf Streif; Rifenbark, Scott M
 Cc: yocto@yoctoproject.org
 Subject: Re: [yocto] tentative list of vars to be dropped from variable
 glossary

 On Mon, 2012-03-26 at 16:50 -0700, Rudolf Streif wrote:
  Thanks, Richard. Clearer now but not entirely.
 
 
 
   BBMASK removes recipes from being parsed. It does not
  remove them from
   images although that would I guess be an indirect result
  since you could
  no longer build them.
 
 
  Yes, it removes it from being parsed. I used, for test although not
  sensible, BBMASK = base-passwd. If I then tried building
  core-image-minimal it fails with Nothing provides base-passwd. If
  one could use BBMASK to customize images as suggested
  in
 http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#usingpoky-extend-customimage-localconfthen
  one would expect the package to be removed indirectly from the image.
 However, that does not happen, the build just fails.

 I hadn't realised Scott had added this to the customising images section
 of the manual. This is not what its designed for and we need to move
 this to somewhere less confusing.

 Scott: This is going to need to move somewhere else in the manual as
 this is confusing. I'm going to suggest a 4.12 section Other tips and
 tricks which says:

 
 Sometimes there are groups of recipes you might wish to filter out. If
 there were recipes you know you're never going to want/use, removing
 them from parsing would speed up parts of the build for example.

 It is possible to filter or mask out both .bb and .bbappend files. You
 can do this by providing an expression with the BBMASK variable. Here is
 an example:

 BBMASK = .*/meta-mymachine/recipes-maybe/

 Here, all .bb and .bbappend files in the directory that matches the
 expression are ignored during the build process.
 

 Cheers,

 Richard




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

Re: [yocto] FW: tentative list of vars to be dropped from variable glossary

[Scott Rifenbark]

yes


On Fri, Mar 30, 2012 at 4:39 AM, Richard Purdie richard.pur...@intel.comwrote:

 On Thu, 2012-03-29 at 16:08 -0600, Scott Rifenbark wrote:
  See chapter 4 of the dev manual
  (http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html)
  for this adjustment.

 Looks good but can you change the title to say Excluding Recipes From
 the Build :)

 Cheers,

 Richard


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

Re: [yocto] yocto ref manual: confusion between BB_ENV_WHITELIST and BB_ENV_EXTRAWHITE

[Scott Rifenbark]

I  changed the variable from BB_ENV_WHITELIST in the description to 
BB_ENV_EXTRAWHITE to make sense with the given example.  You can see the 
change at 
http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#ref-bitbake-runtask.


Scott

On 9/6/2012 1:41 AM, Paul Eggleton wrote:

On Saturday 10 March 2012 08:59:02 Robert P. J. Day wrote:

   from section B.5 of yocto ref manual:

Tell BitBake to load what you want from the environment into the data
store. You can do so through the BB_ENV_WHITELIST variable. For
example, assume you want to prevent the build system from accessing
your $HOME/.ccache directory. The following command tells BitBake to
load CCACHE_DIR from the environment into the data store:

  export BB_ENV_EXTRAWHITE=$BB_ENV_EXTRAWHITE CCACHE_DIR

   i think you can see how that might confuse the reader.

Looks like this still needs to be addressed. Scott, would you mind taking a
look at this? Seems to me that BB_ENV_WHITELIST just ought to be changed to
BB_ENV_EXTRAWHITE to make this make sense.

Cheers,
Paul



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

Re: [yocto] [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

Sorry man... I just stuck the new one in there.  Alphabetical would be
best.  I will fix that.

Thanks,
Scott

On Fri, May 4, 2018 at 9:26 AM, Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> Not sure why you reordered the descriptions of the features from
> image,package,sdk,task to image,task,package,sdk (I added “task” at the end
> since that kept them sorted alphabetically), but apart from that it looks
> fine to me.
>
>
>
> //Peter
>
>
>
> *From:* Scott Rifenbark [mailto:srifenb...@gmail.com]
> *Sent:* den 3 maj 2018 15:58
> *To:* Peter Kjellerstedt <peter.kjellerst...@axis.com>
> *Cc:* Richard Purdie <richard.pur...@linuxfoundation.org>;
> openembedded-core <openembedded-c...@lists.openembedded.org>; Yocto
> discussion list <yocto@yoctoproject.org>
>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> Hi Peter,
>
> Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
> Project Reference Manual (see https://yoctoproject.org/docs/
> 2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also
> see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.
> html#var-BUILDHISTORY_FEATURES for the commit in the yocto-docs
> repository.
>
> Please look it over as I did a bit of modification for manual purposes.
>
> Regards,
>
> Scott
>
>
>
> On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
> peter.kjellerst...@axis.com> wrote:
>
>
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 1 maj 2018 16:56
> *To:* Richard Purdie <richard.pur...@linuxfoundation.org>
> *Cc:* openembedded-core <openembedded-c...@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>
>
>
> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <richard.purdie@
> linuxfoundation.org> wrote:
>
> Hi,
>
> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
> > I'm relatively new to OE; I've written a couple of pre-alpha layers
> > to try some idea, and worked on meta-openembedded, but I've not had a
> > chance to go in depth on the Yocto documentation, and at the some
> > there see to be things (based on the lists) that are out of date, or
> > new things that aren't even mentioned, which makes getting up speed
> > somewhat difficult.
>
> Writing down where you think there are issues would be a help so that
> we can see if there is some way we can improve that.
>
>
>
> Yes - please indicate any areas in the documentation you believe need
> updated, changed, or added.  I have been trying to bring things up-to-date
> in several manuals during the 2.5 process.  So, identifying areas in the
> 2.5 manual set would be very helpful.  To be sure you are viewing 2.5
> manuals use the following form for the URL:
>
>   yoctoproject.org/docs/2.5//.html
>
>   where  is
>
>brief-yoctoprojectqs
>
>bsp-guide
>
>overview-manual
>
>dev-manual
>
>sdk-manual
>
>profile-manual
>
>kernel-dev
>
>ref-manual
>
>toaster-manual
>
>bitbake-user-guide
>
> Thanks
>
> Scott
>
> Is there any special process to get manual updates accepted? I am asking
> because I sent an update for the BUILDHISTORY_FEATURES variable to the
> Yocto mailing list (https://lists.yoctoproject.org/pipermail/yocto/2018-
> January/039787.html) at the end of January (last pinged a month ago) and
> it still has not made it into the manual AFAICT and it has not received any
> feedback.
>
> //Peter
>
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] 2.6 planning proposals and meeting

[Scott Rifenbark]

Peter,

See
https://www.yoctoproject.org/docs/2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES
for the re-ordered list.

Thanks,
Scott

On Fri, May 4, 2018 at 9:53 AM, Scott Rifenbark <srifenb...@gmail.com>
wrote:

> Sorry man... I just stuck the new one in there.  Alphabetical would be
> best.  I will fix that.
>
> Thanks,
> Scott
>
> On Fri, May 4, 2018 at 9:26 AM, Peter Kjellerstedt <
> peter.kjellerst...@axis.com> wrote:
>
>> Not sure why you reordered the descriptions of the features from
>> image,package,sdk,task to image,task,package,sdk (I added “task” at the end
>> since that kept them sorted alphabetically), but apart from that it looks
>> fine to me.
>>
>>
>>
>> //Peter
>>
>>
>>
>> *From:* Scott Rifenbark [mailto:srifenb...@gmail.com]
>> *Sent:* den 3 maj 2018 15:58
>> *To:* Peter Kjellerstedt <peter.kjellerst...@axis.com>
>> *Cc:* Richard Purdie <richard.pur...@linuxfoundation.org>;
>> openembedded-core <openembedded-c...@lists.openembedded.org>; Yocto
>> discussion list <yocto@yoctoproject.org>
>>
>> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>>
>>
>>
>> Hi Peter,
>>
>> Thanks for the patch.  I have applied it to the 2.5 version of the Yocto
>> Project Reference Manual (see https://yoctoproject.org/docs/
>> 2.5/ref-manual/ref-manual.html#var-BUILDHISTORY_FEATURES).  You can also
>> see https://yoctoproject.org/docs/2.5/ref-manual/ref-manual.html
>> #var-BUILDHISTORY_FEATURES for the commit in the yocto-docs repository.
>>
>> Please look it over as I did a bit of modification for manual purposes.
>>
>> Regards,
>>
>> Scott
>>
>>
>>
>> On Thu, May 3, 2018 at 12:29 AM, Peter Kjellerstedt <
>> peter.kjellerst...@axis.com> wrote:
>>
>>
>>
>>
>>
>> *From:* openembedded-core-boun...@lists.openembedded.org [mailto:
>> openembedded-core-boun...@lists.openembedded.org] *On Behalf Of *Scott
>> Rifenbark
>> *Sent:* den 1 maj 2018 16:56
>> *To:* Richard Purdie <richard.pur...@linuxfoundation.org>
>> *Cc:* openembedded-core <openembedded-c...@lists.openembedded.org>
>> *Subject:* Re: [OE-core] 2.6 planning proposals and meeting
>>
>>
>>
>> On Tue, May 1, 2018 at 7:46 AM, Richard Purdie <
>> richard.pur...@linuxfoundation.org> wrote:
>>
>> Hi,
>>
>> On Fri, 2018-04-20 at 08:02 -0400, Daniel F. Dickinson wrote:
>> > I'm relatively new to OE; I've written a couple of pre-alpha layers
>> > to try some idea, and worked on meta-openembedded, but I've not had a
>> > chance to go in depth on the Yocto documentation, and at the some
>> > there see to be things (based on the lists) that are out of date, or
>> > new things that aren't even mentioned, which makes getting up speed
>> > somewhat difficult.
>>
>> Writing down where you think there are issues would be a help so that
>> we can see if there is some way we can improve that.
>>
>>
>>
>> Yes - please indicate any areas in the documentation you believe need
>> updated, changed, or added.  I have been trying to bring things up-to-date
>> in several manuals during the 2.5 process.  So, identifying areas in the
>> 2.5 manual set would be very helpful.  To be sure you are viewing 2.5
>> manuals use the following form for the URL:
>>
>>   yoctoproject.org/docs/2.5//.html
>>
>>   where  is
>>
>>brief-yoctoprojectqs
>>
>>bsp-guide
>>
>>overview-manual
>>
>>dev-manual
>>
>>sdk-manual
>>
>>profile-manual
>>
>>kernel-dev
>>
>>ref-manual
>>
>>toaster-manual
>>
>>bitbake-user-guide
>>
>> Thanks
>>
>> Scott
>>
>> Is there any special process to get manual updates accepted? I am asking
>> because I sent an update for the BUILDHISTORY_FEATURES variable to the
>> Yocto mailing list (https://lists.yoctoproject.or
>> g/pipermail/yocto/2018-January/039787.html) at the end of January (last
>> pinged a month ago) and it still has not made it into the manual AFAICT and
>> it has not received any feedback.
>>
>> //Peter
>>
>>
>>
>>
>>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Excluding ptest packages from image build

[Scott Rifenbark]

If we set up a bug on this Be sure to include the explanation about the
misleading doc entry for that variable as well.  There would be a definite
documentation component to the bug.

Thanks,
Scott

On Wed, May 9, 2018 at 10:34 PM, ChenQi  wrote:

> I just checked the codes. I think the ref manual might be a little
> misleading.
> "Prevents specific packages from being installed when you are installing
> complementary packages. "
> might better be changed to:
> "Prevents specific packages to install their complementary packages. Items
> specified by this variable are considered as regular expression."
> Maybe an example should follow.
>
> So specifying value 'acl' for PACKAGE_EXCLUDE_COMPLEMENTARY should be
> valid and its complementary packages should not be installed. Specifying
> 'acl.*' should have the same effect, but 'acl.' should not.
>
> Anyway, I think you should file a bug with steps to reproduce the problem.
>
> Also, I found that we currently don't have a mechanism to exclude some
> specific complementary package (e.g. acl-ptest in your case). We might need
> to reconsider what PACKAGE_EXCLUDE should mean.
> More specifically, if a user requires *-ptest packages in general, but
> wants to exclude acl-ptest package, there's no easy way to do so.
>
> Best Regards,
> Chen Qi
>
> On 05/09/2018 11:30 PM, Erik Nellessen wrote:
>
>> I would like to exclude some ptest packages from an image build.
>>
>> To include ptest packages in general, my image recipe contains the
>> following line:
>> IMAGE_FEATURES_append = " ptest-pkgs"
>>
>> As a first step, I tried to exclude the acl-ptest package. To do so, I
>> added the following to my image recipe:
>> PACKAGE_EXCLUDE_COMPLEMENTARY = "acl-ptest"
>>
>> I thought that this would exclude the acl-ptest package as described in
>> the project reference: https://www.yoctoproject.org/d
>> ocs/2.4.2/ref-manual/ref-manual.html#var-PACKAGE_EXCLUDE_COMPLEMENTARY
>> "Prevents specific packages from being installed when you are installing
>> complementary packages.
>>
>> You might find that you want to prevent installing certain packages when
>> you are installing complementary packages. For example, if you are using
>> IMAGE_FEATURES to install dev-pkgs, you might not want to install all
>> packages from a particular multilib. If you find yourself in this
>> situation, you can use the PACKAGE_EXCLUDE_COMPLEMENTARY variable to
>> specify regular expressions to match the packages you want to exclude."
>>
>> Anyhow this did not result in an image without the acl-ptest package, as
>> I could validate by having a look at the image's manifest file.
>>
>> When I changed the image recipe to contain the regular expression "acl",
>> i.e
>> PACKAGE_EXCLUDE_COMPLEMENTARY = "acl"
>> all three acl packages (acl, acl-lic, acl-ptest) were excluded from the
>> image.
>>
>> And to really start the confusion, when changed the regular expression to
>> "acl.", i.e.
>> PACKAGE_EXCLUDE_COMPLEMENTARY = "acl."
>> all three packages were also excluded.
>>
>> Now I am really confused. My expectation was that "acl-ptest" and "acl"
>> would match the acl-ptest package name and "acl." would not match the acl
>> package name.
>>
>> Does anybody see what I am missing here?
>>
>> Thanks in advance,
>> Erik
>>
>>
>>
>>
> --
> ___
> 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] ROOTFS_RPM_DEBUG undocumented

[Scott Rifenbark]

If ROOTFS_RPM_DEBUG should be a documented variable in the Yocto Project
Reference Manual, could someone please provide me with some base
explanation of the variable and any usage specifics?

Thanks,
Scott

On Fri, May 4, 2018 at 5:41 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:

> On 05/04/2018 03:42 PM, Paulo Neves wrote:
>
>> I will propose a patch with a default bb.debug, and always have the
>> verbose on dnf. Let's see how it affects the performance. I cannot
>> test this in a docker container because of the problems described
>> below:
>>
>> In the mean time I found what was happening with my slow do_rootfs. I
>> was running bitbake with RPM packaging in a docker instance. It seems
>> there is a problem with RPM/dnf in bitbake where it is extremely slow
>> inside a docker container (1 file per second). After changing to IPK
>> packages everything went smoothly.
>>
>> Others have had the same problem[1]. I will later report this to
>> openembedded mailing list as this effectively makes RPM unusable in a
>> container. I will also provide a Dockerfile to reproduce this problem.
>>
>> [1] https://github.com/moby/moby/issues/23137#issuecomment-359097008
>>
>
> No need to report. We have already fixed this and reported upstream:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/rec
> ipes-devtools/rpm/files/0001-Revert-Set-FD_CLOEXEC-on-opene
> d-files-before-exec-fr.patch
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1537564
>
>
>
> Alex
> --
> ___
> 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 create img file from a working machine

[Scott Rifenbark]

Yes - that is a good place to look.  The topic is from the Yocto Project
Development Tasks Manual (
https://www.yoctoproject.org/docs/2.5/dev-manual/dev-manual.html#creating-partitioned-images-using-wic
).

Scott

On Wed, May 16, 2018 at 6:27 AM, Alan Martinovic 
wrote:

> Hey,
> perhaps this will help you:
> https://www.yoctoproject.org/docs/2.4/mega-manual/mega-
> manual.html#creating-partitioned-images-using-wic
>
> On Wed, May 16, 2018 at 8:49 AM, Denis  wrote:
> >
> >
> > Hi. This is my first experience with Yocto.
> >
> > After having create a working machine this is the machine file list
> >
> >
> >
> > bzImage
> > bzImage--4.14.30+git0+ea9330894e_74f6cd2b69-r0-
> qemux86-20180515055407.bin
> > bzImage-qemux86.bin
> > core-image-minimal-qemux86-20180515055407.testdata.json
> > core-image-minimal-qemux86-20180515141056.qemuboot.conf
> > core-image-minimal-qemux86-20180515141056.rootfs.ext4
> > core-image-minimal-qemux86-20180515141056.rootfs.manifest
> > core-image-minimal-qemux86-20180515141056.rootfs.tar.bz2
> > core-image-minimal-qemux86-20180515141056.testdata.json
> > core-image-minimal-qemux86.ext4
> > core-image-minimal-qemux86.manifest
> > core-image-minimal-qemux86.qemuboot.conf
> > core-image-minimal-qemux86.tar.bz2
> > core-image-minimal-qemux86.testdata.json
> > core-image-sato-qemux86-20180515175948.qemuboot.conf
> > core-image-sato-qemux86-20180515175948.rootfs.ext4
> > core-image-sato-qemux86-20180515175948.rootfs.manifest
> > core-image-sato-qemux86-20180515175948.rootfs.tar.bz2
> > core-image-sato-qemux86-20180515175948.testdata.json
> > core-image-sato-qemux86.ext4
> > core-image-sato-qemux86.manifest
> > core-image-sato-qemux86.qemuboot.conf
> > core-image-sato-qemux86.tar.bz2
> > core-image-sato-qemux86.testdata.json
> > modules--4.14.30+git0+ea9330894e_74f6cd2b69-r0-
> qemux86-20180515055407.tgz
> > modules-qemux86.tgz
> >
> >
> >
> > Now how can I create a img file? I have searched on the web but I have
> found
> > nothing.
> >
> >
> >
> > Regards.
> >
> >
> >
> >
> > --
> >
> > +39.347.4070897
> >
> > www.labcsp.com
> >
> > www.denisgottardello.it
> >
> > GMT+1
> >
> > Skype: mrdebug
> >
> >
> > --
> > ___
> > 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

[yocto] Fwd: Yocto

[Scott Rifenbark]

Hi Nikhil,

I am forwarding your email to the Yocto Project email group.  Someone there
can better help you with your questions.  I take care of the Yocto manual
set.

Thanks,
Scott Rifenbark

-- Forwarded message -
From: nikh kkvv <nikh...@gmail.com>
Date: Fri, May 25, 2018, 6:03 AM
Subject: Yocto
To: <srifenb...@gmail.com>


Hi srifenbark,


I am Nikhil working as soft ware engineer in kerala.

Currently i am working with a project which require yocto based file system.
I am using sama5d36-xplained evaluation kit.

Based on the information from the following site
http://www.at91.com/linux4sam/bin/view/Linux4SAM/YoctoProject build a file
system which support qt images and tested successfully.

Is there any way to  avoid this demo images from this build and add qt
support for bitbake core-image minimal process.


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

[yocto] Fwd: Yocto

[Scott Rifenbark]

-- Forwarded message -
From: Scott Rifenbark <srifenb...@gmail.com>
Date: Fri, May 25, 2018, 6:18 AM
Subject: Fwd: Yocto
To: <yocto@yoctoproject.org>


Hi Nikhil,

I am forwarding your email to the Yocto Project email group.  Someone there
can better help you with your questions.  I take care of the Yocto manual
set.

Thanks,
Scott Rifenbark

-- Forwarded message -
From: nikh kkvv <nikh...@gmail.com>
Date: Fri, May 25, 2018, 6:03 AM
Subject: Yocto
To: <srifenb...@gmail.com>


Hi srifenbark,


I am Nikhil working as soft ware engineer in kerala.

Currently i am working with a project which require yocto based file system.
I am using sama5d36-xplained evaluation kit.

Based on the information from the following site
http://www.at91.com/linux4sam/bin/view/Linux4SAM/YoctoProject build a file
system which support qt images and tested successfully.

Is there any way to  avoid this demo images from this build and add qt
support for bitbake core-image minimal process.


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

Re: [yocto] TEST_IMAGE issues

[Scott Rifenbark]

There is nothing in the docs that says that an image must contain "-image"
or "image-".

Maybe someone can tell me if we should have that.

Scott

On Fri, May 18, 2018 at 4:44 AM, Mirza Krak  wrote:

> Hi all!
>
> Found something interesting (perhaps).
>
> So we where thinking about enabling some of the OE QA tests that that
> are part of poky.
>
> Seemed pretty straight forward. Added following to local.conf:
>
> INHERIT += "testimage"
>
> Build my image and then tried to run:
>
> bitbake -c testimage 
>
> To my despair it did not work and instead produced an error. Tried
> both on "pyro" and "rocko" branches. The error was:
>
> | runqemu started, pid is 45087
> | NOTE: runqemu started, pid is 45087
> | waiting at most 60 seconds for qemu pid
> | NOTE: waiting at most 60 seconds for qemu pid
> | runqemu exited with code 1
> | NOTE: runqemu exited with code 1
> | Output from runqemu:
> | runqemu - ERROR - Unknown path arg
> /tmp/deploy/images/qemux86-64/genivi-dev-platform-qemux86-64.ext4
> | runqemu - ERROR - Try 'runqemu help' on how to use it
>
> Some (a lot) digging later, I finally figured out that error occurs
> because the image name does not contain "-image" or "image-". runqemu
> is not able to parse it and throws a "unknown" argument error (not
> that obvious from the print).
>
> I realize that this is a "problem" in runqemu and not much to do about
> it with a large refactoring job on the runqemu application.
>
> But I am looking for suggesting for an appropriate workaround, other
> then renaming the image which I have verified works.
>
> Does it say somewhere in the docs that all image files must contain
> "-image" or "image-" in their name? If that is the case it makes sense
> to rename it, but trying to avoid that.
>
> --
> Med Vänliga Hälsningar / Best Regards
>
> Mirza Krak
> email: mi...@mkrak.org
> web: https://mkrak.org
> --
> ___
> 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] Gratitude

[Scott Rifenbark]

Jefro,

Sad to see you step down.  You have been great for the project and
especially for carrying the "documentation banner" truly caring about
that aspect.  I hope you do great in your next role and we will keep in
touch.

Scott

On Wed, Jun 6, 2018 at 6:21 AM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> Good Luck, Jeffrey...
>
> I do not know you, but (knowing well about INTEL inside) I know that
> you liked what you did. I do sincerely hope that on the new INTEL
> assignment, you'll find Peace of Mind and R Joy!
>
> > ...I know there are a lot of behind the scenes things which
> > happen which all keep the project running smoothly.
>
> There are many players behind the scenes. Not only INTEL. This is the
> assurance (my best guess) of said/written above.
>
> Time Will Tell.
> Zoran
> ___
>
> On Wed, Jun 6, 2018 at 2:19 PM, Richard Purdie
>  wrote:
> > On Wed, 2018-06-06 at 06:42 +, Osier-mixon, Jeffrey wrote:
> >> I have been the Yocto Project community manager for over 7 years now,
> >> and have had the pleasure of knowing or conversing individually with
> >> several hundred of you. It is with mixed feelings that I must
> >> announce that I am stepping down from my position as the YP community
> >> manager and the Advisory Board chair after 7 years, as I am taking on
> >> a new role in my job.
> >
> > Thanks for everything you've done for the project, I'm sorry to see you
> > move on. As well as the obvious things, I know there are a lot of
> > behind the scenes things which happen which all keep the project
> > running smoothly. Good luck with the new role and I hope to see you
> > around at conferences etc. in the future, its a small world! :)
> >
> > Cheers,
> >
> > Richard
> >
> > --
> > ___
> > 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] [yocto-docs] documentation: Updated testimage targets.

[Scott Rifenbark]

Paulo,

No problems... I made the changes already in the 2.6 version of the YP Ref
Manual (see
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#var-TEST_TARGET).
You can review that for me and let me know what further changes I need.
You can just respond via email if you like in this thread to tell me of any
changes.  You do not have to submit a formal patch.

I searched for and think I got all the instances of "Systemd-bootTarget"
fixed.  I figured this was just an oversight in the original patch you
sent.  No problems.  Here is a link to the 2.6 version of the mega-manual
that you could search through for any term
https://yoctoproject.org/docs/2.6/mega-manual/mega-manual.html.  That is a
handy manual to locate terms across the entire Yocto Project manual set.

In short, you don't have to send me a new patch for the docs... I think we
are 99% there.  I just will need you to review that description of
TEST_TARGET in the ref-manual (
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#var-TEST_TARGET)
and let me know if things are okay with that.

Best,
Scott

On Fri, Aug 10, 2018 at 11:44 AM, Paulo Neves  wrote:

> Hello Scott,
>
> Regarding the other instances of Systemd-bootTarget I will try to grep
> for them and fix them.
> Regarding the truncation It is a mistake on my part. Do you know how I
> can generate the manual to be sure that I do not have mistakes like
> that?
>
> Regarding the file, my apologies. You cannot find it because the
> changes which this manual changes relate to have not yet been
> accepted. I was a bit caught off guard by the fact that the
> documentation and open-embedded mailing lists are separate so I did
> not think that I should only submit documentation changes after the
> OE/poky and others are accepted. When I produced my changes I did it
> in the poky git repository, and split the documentation ad-hoc. I will
> submit the documentation with the fixes you proposed after my other
> commits are accepted. My apologies for the time wasted.
>
> Paulo Neves
>
>
> On Mon, Aug 6, 2018 at 11:12 PM Scott Rifenbark 
> wrote:
> >
> > Paulo,
> >
> > I have some questions on this commit for the dev-manual.
> >
> > See inline comments from me
> >
> >
> >
> > On Mon, Aug 6, 2018 at 4:34 AM, Paulo Neves  wrote:
> >>
> >> The documentation of available names for TEST_TARGET have
> >> been updated to match the convention of using the
> >> class names of controllers.
> >>
> >> Signed-off-by: Paulo Neves 
> >> ---
> >>  documentation/dev-manual/dev-manual-common-tasks.xml |  8 
> >>  documentation/ref-manual/ref-variables.xml   | 19
> ---
> >>  2 files changed, 8 insertions(+), 19 deletions(-)
> >>
> >> diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml
> b/documentation/dev-manual/dev-manual-common-tasks.xml
> >> index 0cb967f..2fcdad0 100644
> >> --- a/documentation/dev-manual/dev-manual-common-tasks.xml
> >> +++ b/documentation/dev-manual/dev-manual-common-tasks.xml
> >> @@ -11400,7 +11400,7 @@
> >>  within a separately started QEMU or any
> >>  other virtual machine manager.
> >>  
> >> -"
> Systemd-bootTarget":
> >> +"
> SystemdbootTarget":
> >>  Choose "Systemd-bootTarget" if your
> hardware is
> >
> >
> > There are many instances of the term "Systemd-bootTarget" remaining in
> the manual.  I assume they also will need to convert to "SystemdbootTarget"?
> >
> >>
> >>  an EFI-based machine with
> >>  systemd-boot as
> bootloader and
> >> @@ -11459,10 +11459,10 @@
> >>  
> >>
> >>  
> >> -Selecting Systemd-bootTarget
> >> +Selecting SystemdbootTarget
> >>
> >>  
> >> -If you did not set TEST_TARGET
> to
> >> +If you did not set TEST_TARG
> >
> >
> > Looks like an early truncation of the line that is used for the
> replacement?  Should be "If you did not set TEST_TARGET
> to"
> >
> >>  "Systemd-bootTarget", then you do not need any
> information
> >>  in this section.
> >>  You can skip down to the
> >>

[yocto] [crops][PATCH] docker-win-mac-docs.wiki: Updated link for referencing Yocto docs

[Scott Rifenbark]

The link was going to a retired Quick Start.  I changed the link
to the appropriate section of the YP Development Tasks Manual.

Signed-off-by: Scott Rifenbark 
---
 Windows-Instructions-(Docker-Toolbox).md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Windows-Instructions-(Docker-Toolbox).md 
b/Windows-Instructions-(Docker-Toolbox).md
index 31432bd..f33bc66 100644
--- a/Windows-Instructions-(Docker-Toolbox).md
+++ b/Windows-Instructions-(Docker-Toolbox).md
@@ -74,7 +74,7 @@ You will see a prompt that looks like
 
 `pokyuser@892e5d2574d6:/workdir$`
 
-Although this is called the poky container, it does not include the bitbake 
meta-data for the Yocto Project poky distro, instead it is a Linux environment 
with all dependencies already installed. See the [Yocto Quick Start 
Guide](http://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html#releases)
 to get started with with Yocto project.
+Although this is called the poky container, it does not include the bitbake 
meta-data for the Yocto Project poky distro, instead it is a Linux environment 
with all dependencies already installed. See the [Yocto Project Development 
Tasks 
Manual](https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#cloning-and-checking-out-branchs)
 to get started with with Yocto project.
 
 ## Troubleshooting
 ### Cannot connect to docker
-- 
2.7.4

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

[yocto] [poky-container][PATCH] README.md: Updated a link into the YP doc set.

[Scott Rifenbark]

The existing link was a dead end.  It took the reader to the
retired YP Quick Start.  The new link is to the section in the
YP Development Tasks Manual where the ready can learn how to
clone poky and proceed.

Signed-off-by: Scott Rifenbark 
---
 README.md | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/README.md b/README.md
index c5276fd..6bc172a 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,7 @@ point.
 
 The workdir you create will be used for the output created while using the 
container.
 For example a user could create a directory using the command
-  
+
 ```
 mkdir -p /home/myuser/mystuff
 ```
@@ -31,7 +31,7 @@ point.
 
 For the rest of the Linux instructions we'll assume the workdir chosen was
 `/home/myuser/mystuff`.
-
+
   * **Windows/Mac**
 
 On Windows or Mac a workdir isn't needed. Instead the volume called 
*myvolume* will be used. This volume should have been created when following 
the instructions at https://github.com/crops/docker-win-mac-docs/wiki.
@@ -46,9 +46,9 @@ point.
 ```
 docker run --rm -it -v /home/myuser/mystuff:/workdir crops/poky 
--workdir=/workdir
 ```
-
+
   * **Windows/Mac**
-  
+
 ```
 docker run --rm -it -v myvolume:/workdir crops/poky --workdir=/workdir
 ```
@@ -62,5 +62,4 @@ point.
   ```
   pokyuser@3bbac563cacd:/workdir$
   ```
-  At this point you should be able to follow the same instructions as described
-  in 
https://www.yoctoproject.org/docs/current/yocto-project-qs/yocto-project-qs.html#releases.
+  At this point you should be able to follow the instructions in the [Yocto 
Project Development Tasks 
Manual](https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#cloning-and-checking-out-branchs)
 to get started with with Yocto project.
-- 
2.7.4

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

Re: [yocto] [yocto-docs] documentation: Updated testimage targets.

[Scott Rifenbark]

Paulo,

I have some questions on this commit for the dev-manual.

See inline comments from me



On Mon, Aug 6, 2018 at 4:34 AM, Paulo Neves  wrote:

> The documentation of available names for TEST_TARGET have
> been updated to match the convention of using the
> class names of controllers.
>
> Signed-off-by: Paulo Neves 
> ---
>  documentation/dev-manual/dev-manual-common-tasks.xml |  8 
>  documentation/ref-manual/ref-variables.xml   | 19
> ---
>  2 files changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml
> b/documentation/dev-manual/dev-manual-common-tasks.xml
> index 0cb967f..2fcdad0 100644
> --- a/documentation/dev-manual/dev-manual-common-tasks.xml
> +++ b/documentation/dev-manual/dev-manual-common-tasks.xml
> @@ -11400,7 +11400,7 @@
>  within a separately started QEMU or any
>  other virtual machine manager.
>  
> -"Systemd-bootTarget": emphasis>
> +"
> SystemdbootTarget":
>  Choose "Systemd-bootTarget" if your hardware
> is
>

There are many instances of the term "Systemd-bootTarget" remaining in the
manual.  I assume they also will need to convert to "SystemdbootTarget"?


>  an EFI-based machine with
>  systemd-boot as
> bootloader and
> @@ -11459,10 +11459,10 @@
>  
>
>  
> -Selecting Systemd-bootTarget
> +Selecting SystemdbootTarget
>
>  
> -If you did not set TEST_TARGET
> to
> +If you did not set TEST_TARG
>

Looks like an early truncation of the line that is used for the
replacement?  Should be "If you did not set
TEST_TARGET to"

 "Systemd-bootTarget", then you do not need any
> information
>  in this section.
>  You can skip down to the
> @@ -11472,7 +11472,7 @@
>
>  
>  If you did set TEST_TARGET to
> -"Systemd-bootTarget", you also need to perform a
> one-time
> +"SystemdbootTarget", you also need to perform a
> one-time
>  setup of your master image by doing the following:
>  
>  Set
> EFI_PROVIDER:
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 2465553..a61fee6 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -15162,35 +15162,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  You can provide the following arguments with
>  TEST_TARGET:
>  
> -"qemu" and
> "QemuTarget":
> +"
> QemuTarget":
>  Boots a QEMU image and runs the tests.
>  See the
>  "Enabling Runtime Tests on QEMU"
>  section in the Yocto Project Development Tasks
>  Manual for more information.
>  
> -"simpleremote" and
> "SimpleRemoteTarget":
> +"SimpleRemoteTarget": emphasis>
>  Runs the tests on target hardware that is
> already
>  up and running.
>  The hardware can be on the network or it can
> be
>  a device running an image on QEMU.
>  You must also set
>  <
> filename>TEST_TARGET_IP
> -when you use "simpleremote" or
> "SimpleRemoteTarget".
> +when you use "SimpleRemoteTarget".
>  
>  This argument is defined in
> -meta/lib/oeqa/
> targetcontrol.py.
> -The small caps names are kept for
> compatibility
> -reasons.
> -
> -
> -"
> GummibootTarget":
> -Automatically deploys and runs tests on an
> -EFI-enabled machine that has a master image
> -installed.
> -
> -This argument is defined in
> -meta/lib/oeqa/
> controllers/masterimage.py.
> +meta/lib/oeqa/
> controllers/simpleremote.py.
>

I cannot find any file named "meta/lib/oeqa/controllers/simpleremote.py" in
the poky 

Re: [yocto] [yocto-docs][PATCH] ref-manual: Removed misleading paragraph in siteinfo section

[Scott Rifenbark]

Yevgeny and Richard,

See the siteinfo.bbclass section here -
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#ref-classes-siteinfo
.

Paragraph removed.

Thanks,
Scott

On Tue, Aug 14, 2018 at 4:38 AM Yevgeny Popovych 
wrote:

> Hello Scott.
>
> siteinfo was removed from base.bbclass by Richard Purdie in 2010
> (commit 185cb38f1319856b4bdaaf4d9a73b5056be53d54 in openembedded-core).
>
> Richard, can you confirm/reject this change?
>
> Thanks!
>
>
> On 11/05/2017 08:04 PM, Yevgeny Popovych wrote:
> > ..on the inclusion of siteinfo.bbclass in base.bbclass.
> > This is not true since 2010.
> >
> > Signed-off-by: Yevgeny Popovych 
> > ---
> >  documentation/ref-manual/ref-classes.xml | 6 --
> >  1 file changed, 6 deletions(-)
> >
> > diff --git a/documentation/ref-manual/ref-classes.xml
> b/documentation/ref-manual/ref-classes.xml
> > index 5961d3e..fe41f9e 100644
> > --- a/documentation/ref-manual/ref-classes.xml
> > +++ b/documentation/ref-manual/ref-classes.xml
> > @@ -3134,12 +3134,6 @@ This check was removed for YP 2.3 release
> >  and  linkend='var-SITEINFO_BITS'>SITEINFO_BITS
> >  that can be used elsewhere in the metadata.
> >  
> > -
> > -
> > -Because the
> > - linkend='ref-classes-base'>base class
> > -includes the siteinfo class, it is always
> active.
> > -
> >  
> >
> >  
> >
>
> --
> Sincerely,
> Yevgeny Popovych
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 2.6 migration guide

[Scott Rifenbark]

Thanks Robert...  I will do that.

Scott

On Wed, Oct 31, 2018 at 12:15 AM Robert Berger <
yocto.user.mailingl...@gmail.com> wrote:

> Hi Scott,
>
> On 31.10.18 00:06, Scott Rifenbark wrote:
> >
> > I have an initial section at
> >
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
>
> > which is based on Richard's input.  I am sure there are more items.
>
> You might want to add a link to the bitbake manual or some example from
> there for the new functionality of _remove operator:
>
>
> http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334
>
> FOO = "123 456 789 123456 123 456 123 456"
> FOO_remove = "123"
> FOO_remove = "456"
>
> FOO is now: "  789 123456" instead of "789 123456"
>
> >
> > Thanks,
> > Scott
>
> Regards,
>
> Robert
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 2.6 migration guide

[Scott Rifenbark]

Can you tell me why "123456" is also not removed?  That string contains
instances of "123" and "456"

Thanks,
Scott

On Wed, Oct 31, 2018 at 12:15 AM Robert Berger <
yocto.user.mailingl...@gmail.com> wrote:

> Hi Scott,
>
> On 31.10.18 00:06, Scott Rifenbark wrote:
> >
> > I have an initial section at
> >
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
>
> > which is based on Richard's input.  I am sure there are more items.
>
> You might want to add a link to the bitbake manual or some example from
> there for the new functionality of _remove operator:
>
>
> http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334
>
> FOO = "123 456 789 123456 123 456 123 456"
> FOO_remove = "123"
> FOO_remove = "456"
>
> FOO is now: "  789 123456" instead of "789 123456"
>
> >
> > Thanks,
> > Scott
>
> Regards,
>
> Robert
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 2.6 migration guide

[Scott Rifenbark]

Got it, thanks.

On Wed, Oct 31, 2018 at 9:02 AM Bas Mevissen  wrote:

> On 2018-10-31 16:50, Scott Rifenbark wrote:
>
> > Can you tell me why "123456" is also not removed?  That string contains
> > instances of "123" and "456"
>
>
> Because it removes all occurrences of the list value "123" and not of
> value "123456" or any part of it. Otherwise, it would be impossible to
> use this function to only remove, say, "1" from a long list of numbers.
> (here 'value' is not limited to a number).
>
> -- Bas.
>
> >
> > Thanks,
> > Scott
> >
> > On Wed, Oct 31, 2018 at 12:15 AM Robert Berger
> >  wrote:
> >
> >> Hi Scott,
> >>
> >> On 31.10.18 00:06, Scott Rifenbark wrote:
> >>>
> >>> I have an initial section at
> >>>
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release
> ,
> >>> which is based on Richard's input.  I am sure there are more items.
> >>
> >> You might want to add a link to the bitbake manual or some example
> >> from
> >> there for the new functionality of _remove operator:
> >>
> >>
> http://git.openembedded.org/bitbake/tree/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml?id=c0a23dd9155c50a6b7df796980bc7b612cac7994#n334
> >>
> >> FOO = "123 456 789 123456 123 456 123 456"
> >> FOO_remove = "123"
> >> FOO_remove = "456"
> >>
> >> FOO is now: "  789 123456" instead of "789 123456"
> >>
> >>>
> >>> Thanks,
> >>> Scott
> >>
> >> Regards,
> >>
> >> Robert
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] 2.6 migration guide

[Scott Rifenbark]

Paul,

Thanks for sending.

Contributors

I have an initial section at
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
which is based on Richard's input.  I am sure there are more items.

Thanks,
Scott

On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton 
wrote:

> Hi folks
>
> When Scott prepares the migration guide for a release, he usually looks to
> me
> to collate the notable changes for it (those requiring user intervention).
> I
> haven't prepared anything yet though and the 2.6 release is fast
> approaching.
> Can anyone who has been involved in or is aware of such changes in master
> for
> upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>
> Scott and I will take care of cleaning it up, so things added there don't
> need
> to be perfect.
>
> I will also be doing my usual trawl through the commits in the release for
> the
> more general changelog, so most things will get picked up that way, but
> it's
> really helpful if people with first-hand knowledge of the implications of
> some
> of these changes are involved in how they get documented.
>
> Thanks,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Need Help To Solve Errors while build of Yocto Project

[Scott Rifenbark]

Hi,

I am not a developer but according to that manual, one of the requirements
is Python 3.4 or greater.  I see Python2 stuff in the attached screen
shots.  Someone else could probably be more definitive.  That might not be
the reason but you could try with Python 3.

https://www.yoctoproject.org/docs/2.5.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html#brief-compatible-distro

Scott

On Thu, Oct 25, 2018 at 8:13 AM Bhavin Dharmendrabhai Maru <
bhavin.m...@vvdntech.in> wrote:

> Hi Support Team,
>
> I am new to yocto project and start to build yocto project by the steps
> provided in below link:
>
> https://www.yoctoproject.org/docs/2.5.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
>
> I am getting errors when i give *$ bitbake core-image-sato *command.
> details screenshot of errors are attached with this email for your
> reference.
>
> Kindly help me to solve these errors. Any help in this will be appreciated.
>
> Thanks and Regards,
> Bhavin Maru
> --
> ___
> 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] [OE-core] 2.6 migration guide

[Scott Rifenbark]

Peter,

Thanks
Scott

https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-openssl-changes
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#migration-2.6-security-changes

On Fri, Nov 2, 2018 at 8:10 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> In “4.14.2. OpenSSL Changes”, change “both versions their dependency
> chains” to “both versions in their dependency chains”.
>
> In “4.14.4. Security Changes”, change “files” to “flags” (twice).
>
>
>
> //Peter
>
>
>
> *From:* openembedded-core-boun...@lists.openembedded.org <
> openembedded-core-boun...@lists.openembedded.org> *On Behalf Of *Scott
> Rifenbark
> *Sent:* den 30 oktober 2018 23:07
> *To:* Paul Eggleton 
> *Cc:* Yocto discussion list ; openembedded-core <
> openembedded-c...@lists.openembedded.org>
> *Subject:* Re: [OE-core] 2.6 migration guide
>
>
>
> Paul,
>
>
>
> Thanks for sending.
>
>
>
> Contributors
>
>
>
> I have an initial section at
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#moving-to-the-yocto-project-2.6-release,
> which is based on Richard's input.  I am sure there are more items.
>
>
>
> Thanks,
>
> Scott
>
>
>
> On Tue, Oct 23, 2018 at 2:14 PM Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
> Hi folks
>
> When Scott prepares the migration guide for a release, he usually looks to
> me
> to collate the notable changes for it (those requiring user intervention).
> I
> haven't prepared anything yet though and the 2.6 release is fast
> approaching.
> Can anyone who has been involved in or is aware of such changes in master
> for
> upcoming 2.6 (thud) make a note of it on the wiki in raw form on this page:
>
>   https://wiki.yoctoproject.org/wiki/FutureMigrationGuide
>
> Scott and I will take care of cleaning it up, so things added there don't
> need
> to be perfect.
>
> I will also be doing my usual trawl through the commits in the release for
> the
> more general changelog, so most things will get picked up that way, but
> it's
> really helpful if people with first-hand knowledge of the implications of
> some
> of these changes are involved in how they get documented.
>
> Thanks,
> Paul
>
> --
> Paul Eggleton
> Intel Open Source Technology Centre
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QEMU kernel defconfigs

[Scott Rifenbark]

On Thu, Nov 15, 2018 at 12:08 PM Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 2018-11-15 12:29 p.m., Jon Mason wrote:
> > I'm having difficulty determining where the kernel defconfigs are
> > defined and located.  I'm specifically looking for the qemuarm and
> > qemuarm64 kernel defconfigs.  I've looked at the relevant
> > documentation,
> https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
> > and
> > no SRC_URI with defconfig or KBUILD_DEFCONFIG_KMACHINE defined in
> > meta/recipes-kernel/linux/linux-yocto_4.18.bb
> >
> > What am I missing?
>
> The reference machines with linux-yocto don't use defconfigs at all.
> They are fully assembled from the configuration fragments in the
> kernel-cache repo.
>
> You'll see the location of the kernel-cache, and the routines that
> gather up the fragments in the linux-yocto* recipes.
>
> The kernel development manual has that detail as well:
>
>
> https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#kernel-dev-advanced
>
> Bruce
>
> >
> > Also, "A defconfig file is simply a .config renamed to "defconfig"."
> > is not correct.  A properly created defconfig is created by `make
> > savedefconfig` and is a minimal file which only has the delta between
> > the desired config and defaults from the Kconfig files.
> >
> https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file
> >
> > Thanks,
> > Jon
>

Jon - see
https://www.yoctoproject.org/docs/2.5.1/kernel-dev/kernel-dev.html#creating-a-defconfig-file
for some re-phrasing.

>
>
> --
> ___
> 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] FW: final pass on release notes....and general status of readiness

[Scott Rifenbark]

Especially true for the manuals... always go to the website for best set of
manuals.

Scott

On Wed, Nov 14, 2018 at 1:41 PM akuster808  wrote:

>
> On 11/14/18 12:47 PM, Jolley, Stephen K wrote:
>
> We will release YP 2.6 M4 rc1 shortly.  Please give feedback if any is
> required.
>
>
> Please add the note that Tip of Thud is not what is being released.
>
> This will just confuse folks trying to connect the dots.
>
>
> - armin
>
>
>
> Thanks,
>
>
>
> Stephen
>
>
>
> *From:* Graydon, Tracy
> *Sent:* Wednesday, November 14, 2018 12:33 PM
> *To:* Jolley, Stephen K 
> ; Michael Halstead
>  
> *Subject:* final pass on release notesand general status of readiness
>
>
>
> Ugh, I am not seeing the email I sent with the finalized release notes. I
> dunno if I sent it or not because I am having a nightmare with Outlook on
> Mac eating things and generally not working right.
>
>
> So, by way of sanity check, attached.  The only changes were adding the
> binutils CVES to Known issues:
>
>
>
> binutils: fix CVE-2018-18309, CVE-2018-18605, CVE-2018-18606,
> CVE-2018-18607
>
>
>
> And the gitsm known issue:
>
>
>
> - gitsm fixes on master-next:
>
> * The submodule name and path were assumed to be the same, which is not
> necessarily true.
>
> * Submodules refer to a specific commit, not branch, but we erroneously
> check against the branch specified in SRC_URI. This results in
>
> failure if a submodule commit is not on that branch.
>
>
>
> So, nothing major there. Just really a sanity check on the gitsm wording.
>
>
>
> Everything is ready to go. Pages are set and just need to be published.
> Release announcement is ready. So we just need to do the final mirror and
> tagging magic, and announce.
>
>
>
> If the wording on gitsm issue looks reasonable, we are good to go.
>
>
>
> -t
>
>
>
>
>
> --
> ___
> 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] [yocto-docs][PATCH] documentation: Document debug-with-srcpkg

[Scott Rifenbark]

Joshua,

Thanks for the patch.  I have appliied it.  You can see it at
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#var-PACKAGE_DEBUG_SPLIT_STYLE
.

Scott

On Sun, Sep 23, 2018 at 8:24 PM Joshua Watt  wrote:

> Adds documentation for the "debug-with-srcpkg" option for the
> PACKAGE_DEBUG_SPLIT_STYLE variable
>
> Signed-off-by: Joshua Watt 
> ---
>  documentation/ref-manual/ref-variables.xml | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 05487cf83f6..1bc6e2b77d5 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -9646,6 +9646,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  ".debug" previously described with the
> exception
>  that no source files are installed.
>  .
> +
> +"debug-with-srcpkg": The same behavior as
> +".debug" previously described with the
> exception
> +that all source files are placed in a separate
> +*-src pkg.
> +
>  
>  
>
> --
> 2.17.1
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] ref-manual: Update the definition of SDK_VERSION

[Scott Rifenbark]

Peter,

Thanks for the patch.  See
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-SDK_VERSION
for the update.

Scott

On Fri, Jan 18, 2019 at 8:02 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> The definition in poky.conf has been updated.
>
> Signed-off-by: Peter Kjellerstedt 
> ---
> This of course assumes that the corresponding patch that I just sent
> to the openembedded-core mailing list has been integrated first.
>
>  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 ed65727fc7..4b243a12dd 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -13045,7 +13045,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  /meta-poky/conf/distro/poky.conf)
>  defines the SDK_VERSION as
> follows:
>  
> - SDK_VERSION :=
> "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
> + SDK_VERSION =
> "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}"
>  
>  
>
> --
> 2.12.0
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [documentation][PATCH] documentation: remove True option to getVar calls

[Scott Rifenbark]

Hi Andre,

Thanks for the patch.  See
http://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#platdev-appdev-devpyshell
and
http://www.yoctoproject.org/docs/2.7/dev-manual/dev-manual.html#using-x32-psabi
sections for the changes.

Thanks,
Scott Rifenbark



On Tue, Jan 15, 2019 at 7:03 AM André Draszik  wrote:

> From: André Draszik 
>
> getVar() has been defaulting to expanding by default for
> a long time (2016), thus remove the True option from
> getVar() examples with a regex search and replace.
>
> Search & replace made using the following command:
> sed -e 's|\(d\.getVar \?\)( \?\([^,()]*\), \?True)|\1(\2)|g' \
> -i $(git grep -E 'getVar ?\( ?([^,()]*), ?True\)' \
>  | cut -d':' -f1 \
>  | sort -u)
>
> Note that there are are several other examples of getVar()
> usage which already don't explicitly add the True option,
> this patch just align some stray remainders.
>
> Signed-off-by: André Draszik 
> ---
>  documentation/dev-manual/dev-manual-common-tasks.xml | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml
> b/documentation/dev-manual/dev-manual-common-tasks.xml
> index c75e718d67..af0e4d53bf 100644
> --- a/documentation/dev-manual/dev-manual-common-tasks.xml
> +++ b/documentation/dev-manual/dev-manual-common-tasks.xml
> @@ -5116,15 +5116,15 @@
>  So, commands such as the following are useful when exploring
> the data
>  store and running functions:
>  
> - pydevshell> d.getVar("STAGING_DIR", True)
> + pydevshell> d.getVar("STAGING_DIR")
>   '/media/build1/poky/build/tmp/sysroots'
> - pydevshell> d.getVar("STAGING_DIR", False)
> + pydevshell> d.getVar("STAGING_DIR")
>   '${TMPDIR}/sysroots'
>   pydevshell> d.setVar("FOO", "bar")
> - pydevshell> d.getVar("FOO", True)
> + pydevshell> d.getVar("FOO")
>   'bar'
>   pydevshell> d.delVar("FOO")
> - pydevshell> d.getVar("FOO", True)
> + pydevshell> d.getVar("FOO")
>   pydevshell> bb.build.exec_func("do_unpack", d)
>   pydevshell>
>  
> @@ -6892,8 +6892,8 @@
>  
>   MACHINE = "qemux86-64"
>   DEFAULTTUNE = "x86-64-x32"
> - baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE',
> True) \
> -or 'INVALID'), True) or 'lib'}"
> + baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE') \
> +or 'INVALID')) or 'lib'}"
>  
>  Once you have set up your configuration file, use BitBake to
>  build an image that supports the x32 psABI.
> --
> 2.20.1
>
> --
> ___
> 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] [PATCH 2/2] ref-manual: Add missing whitespace around "=" in a few code examples

[Scott Rifenbark]

Peter,

Thank you for the patch in the ref-manual.  I applied the patch (
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=0d22771c64d082bf86f5efd85ac9aaeb1c7f3093
)

You can see the changes in the upcoming version of the ref-manual.  I will
back port as needed too.
http://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html.

Scott

On Thu, Dec 13, 2018 at 3:24 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> Signed-off-by: Peter Kjellerstedt 
> ---
>  documentation/ref-manual/ref-variables.xml | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 7dc3a3f79a..730737226e 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -7655,9 +7655,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR =
> "${INC_PR}.3"
>  
>   KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc
> features/taskstats/taskstats.scc"
>   KERNEL_FEATURES_append = " ${KERNEL_EXTRA_FEATURES}"
> - KERNEL_FEATURES_append_qemuall=" cfg/virtio.scc"
> - KERNEL_FEATURES_append_qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> - KERNEL_FEATURES_append_qemux86-64=" cfg/sound.scc"
> + KERNEL_FEATURES_append_qemuall = " cfg/virtio.scc"
> + KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc
> cfg/paravirt_kvm.scc"
> + KERNEL_FEATURES_append_qemux86-64 = " cfg/sound.scc"
>  
>  
>  
> @@ -10422,7 +10422,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  PACKAGECONFIG.
>  You can either completely override the
> variable:
>  
> - PACKAGECONFIG="f4 f5"
> + PACKAGECONFIG = "f4 f5"
>  
>  Or, you can just append the variable:
>  
> @@ -10436,7 +10436,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  As with append files previously described,
>  you can either completely override the
> variable:
>  
> - PACKAGECONFIG_pn-recipename="f4 f5"
> + PACKAGECONFIG_pn-recipename = "f4 f5"
>  
>  Or, you can just amend the variable:
>  
> --
> 2.12.0
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 1/2] ref-manual: Document the fifth argument to PACKAGECONFIG

[Scott Rifenbark]

Peter,

Thanks for the patch.  See
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-PACKAGECONFIG
for the changes.

Commit:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/commit/?id=adb17e3172c829de77d2664c91f7cf4b22c9e5f0

Scott

On Thu, Dec 13, 2018 at 3:24 AM Peter Kjellerstedt <
peter.kjellerst...@axis.com> wrote:

> Support for adding runtime recommendations (RRECOMMENDS) using
> PACKAGECONFIG was introduced in Rocko.
>
> Signed-off-by: Peter Kjellerstedt 
> ---
>  documentation/ref-manual/ref-variables.xml | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 58c5418d16..7dc3a3f79a 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -10333,9 +10333,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  Here is the basic block structure:
>  
>   PACKAGECONFIG ??= "f1 f2 f3 ..."
> - PACKAGECONFIG[f1] = "--with-f1,--without-f1,build-deps-f1,rt-deps-f1"
> - PACKAGECONFIG[f2] = "--with-f2,--without-f2,build-deps-f2,rt-deps-f2"
> - PACKAGECONFIG[f3] = "--with-f3,--without-f3,build-deps-f3,rt-deps-f3"
> + PACKAGECONFIG[f1] =
> "--with-f1,--without-f1,build-deps-f1,rt-deps-f1,rt-recs-f1"
> + PACKAGECONFIG[f2] =
> "--with-f2,--without-f2,build-deps-f2,rt-deps-f2,rt-recs-f2"
> + PACKAGECONFIG[f3] =
> "--with-f3,--without-f3,build-deps-f3,rt-deps-f3,rt-recs-f3"
>  
>  
>
> @@ -10344,7 +10344,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  variable itself specifies a space-separated list of
> the
>  features to enable.
>  Following the features, you can determine the
> behavior of
> -each feature by providing up to four order-dependent
> +each feature by providing up to five order-dependent
>  arguments, which are separated by commas.
>  You can omit any argument you like but must retain the
>  separating commas.
> @@ -10370,6 +10370,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR
> = "${INC_PR}.3"
>  ( linkend='var-RDEPENDS'>RDEPENDS)
>  that should be added if the feature is
> enabled.
>  
> +Additional runtime recommendations
> +( linkend='var-RRECOMMENDS'>RRECOMMENDS)
> +that should be added if the feature is
> enabled.
> +
>  
>  
>
> --
> 2.12.0
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [[yocto-docs][thud][PATCH] ref-system-requirements: sync with thud poky.conf

[Scott Rifenbark]

Thanks Armin!  You too!

On Mon, Nov 19, 2018 at 11:28 AM akuster808  wrote:

>
>
> On 11/19/18 10:16 AM, Scott Rifenbark wrote:
>
> Armin,
>
> See
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros
> and let me know if the patch is good.
>
> Looks good.
> Thanks,
> Have a good Thanksgiving.
> Armin
>
>
> Thanks,
> Scott
>
> On Sun, Nov 18, 2018 at 6:15 PM Armin Kuster  wrote:
>
>> poky.conf
>> ubuntu-16.04
>> ubuntu-16.10
>> ubuntu-17.04
>> fedora-26
>> centos-7
>> debian-8
>> debian-9
>> opensuse-42.1
>> opensuse-42.2
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  documentation/ref-manual/ref-system-requirements.xml | 20
>> 
>>  1 file changed, 12 insertions(+), 8 deletions(-)
>>
>> diff --git a/documentation/ref-manual/ref-system-requirements.xml
>> b/documentation/ref-manual/ref-system-requirements.xml
>> index 9298e84..0abc47e 100644
>> --- a/documentation/ref-manual/ref-system-requirements.xml
>> +++ b/documentation/ref-manual/ref-system-requirements.xml
>> @@ -93,19 +93,22 @@
>>  Ubuntu 11.10
>>  Ubuntu 12.04 (LTS)
>>  Ubuntu 13.10
>> -Ubuntu 14.04 (LTS) -->
>> +Ubuntu 14.04 (LTS)
>>  Ubuntu 14.10
>>  Ubuntu 15.04
>> -Ubuntu 15.10
>> +Ubuntu 15.10 -->
>>  Ubuntu 16.04 (LTS)
>> +Ubuntu 16.10 (LTS)
>> +Ubuntu 17.04 
>>  
>> +Fedora release 20
>> (Heisenbug)
>>  Fedora release 22
>>  Fedora release 23
>> -
>> +Fedora release 26
>> +
>> -
>> -openSUSE 13.2
>> +openSUSE 13.1
>> +openSUSE 13.2 -->
>>  openSUSE 42.1
>> +openSUSE 42.2
>>  
>>  
>>
>> --
>> 2.7.4
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [[yocto-docs][thud][PATCH] ref-system-requirements: sync with thud poky.conf

[Scott Rifenbark]

Armin,

See
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros
and let me know if the patch is good.

Thanks,
Scott

On Sun, Nov 18, 2018 at 6:15 PM Armin Kuster  wrote:

> poky.conf
> ubuntu-16.04
> ubuntu-16.10
> ubuntu-17.04
> fedora-26
> centos-7
> debian-8
> debian-9
> opensuse-42.1
> opensuse-42.2
>
> Signed-off-by: Armin Kuster 
> ---
>  documentation/ref-manual/ref-system-requirements.xml | 20
> 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-system-requirements.xml
> b/documentation/ref-manual/ref-system-requirements.xml
> index 9298e84..0abc47e 100644
> --- a/documentation/ref-manual/ref-system-requirements.xml
> +++ b/documentation/ref-manual/ref-system-requirements.xml
> @@ -93,19 +93,22 @@
>  Ubuntu 11.10
>  Ubuntu 12.04 (LTS)
>  Ubuntu 13.10
> -Ubuntu 14.04 (LTS) -->
> +Ubuntu 14.04 (LTS)
>  Ubuntu 14.10
>  Ubuntu 15.04
> -Ubuntu 15.10
> +Ubuntu 15.10 -->
>  Ubuntu 16.04 (LTS)
> +Ubuntu 16.10 (LTS)
> +Ubuntu 17.04 
>  
> +Fedora release 20
> (Heisenbug)
>  Fedora release 22
>  Fedora release 23
> -
> +Fedora release 26
> +
> -
> -openSUSE 13.2
> +openSUSE 13.1
> +openSUSE 13.2 -->
>  openSUSE 42.1
> +openSUSE 42.2
>  
>  
>
> --
> 2.7.4
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is there a good "getting started" tutorial?

[Scott Rifenbark]

Grant - I will check this out.  I am going to use this manual -
https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
.

Scott

On Fri, Jan 11, 2019 at 9:33 AM Grant Edwards 
wrote:

>
> I'm new to Yocto and looking for a good "getting started"
> tutorial. I've tried
>
>
> https://www.yoctoproject.org/docs/2.6/brief-yoctoprojectqs/brief-yoctoprojectqs.html
>
> and immediately ran into mistakes on the very first step:
>
> Use Git to Clone Poky¶
> Once you complete the setup instructions for your machine, you need to
> get a copy of the Poky repository on your build host. Use the following
> commands to clone the Poky repository and then checkout the yocto-2.6
> release:
>
>  $ git clone git://git.yoctoproject.org/poky
>  Cloning into 'poky'...
>  remote: Counting objects: 361782, done.
>  remote: Compressing objects: 100% (87100/87100), done.
>  remote: Total 361782 (delta 268619), reused 361439 (delta 268277)
>  Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s,
> done.
>  Resolving deltas: 100% (268619/268619), done.
>  Checking connectivity... done.
>  $ git checkout tags/yocto-2.5 -b my-yocto-2.5
>
> The previous Git checkout command creates a local branch named
> my-yocto-2.6. [...]
>
> It does? The 'git clone' command seems to be OK, but the second command
> fails:
>
> $ git clone git://git.yoctoproject.org/poky
> Cloning into 'poky'...
> remote: Counting objects: 428632, done.
> remote: Compressing objects: 100% (101203/101203), done.
> remote: Total 428632 (delta 320463), reused 428532 (delta 320363)
> Receiving objects: 100% (428632/428632), 153.01 MiB | 1.33 MiB/s, done.
> Resolving deltas: 100% (320463/320463), done.
> $ git checkout tags/yocto-2.5 -b my-yocto-2.5
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
>
> I re-tried the second command, changing the version from 2.5 to 2.6,
> and that didn't work either:
>
> $ git checkout tags/yocto-2.6 -b my-yocto-2.6
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
>
> It looks like there's a missing 'cd poky' command that needs to be
> inserted before the 'git checkout', and the checkout command needs to
> be changed from 2.5 to 2.6.
>
> Has anybody tried this tutorial recently to see if it actually works?
>
> Is there a better getting started doc?
>
> --
> Grant
> --
> ___
> 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] Is there a good "getting started" tutorial?

[Scott Rifenbark]

Hi Grant,

There are indeed some errors in that tutorial.  Thanks for finding them and
sending notification.  Try the instructions in the latest quick start for
the 2.6 "thud" release.

https://yoctoproject.org/docs/2.6/brief-yoctoprojectqs/brief-yoctoprojectqs.html

I have run through them and made some adjustments to the manual to clear
things up.  It is working for me.

Thanks,
Scott

On Fri, Jan 11, 2019 at 9:33 AM Grant Edwards 
wrote:

>
> I'm new to Yocto and looking for a good "getting started"
> tutorial. I've tried
>
>
> https://www.yoctoproject.org/docs/2.6/brief-yoctoprojectqs/brief-yoctoprojectqs.html
>
> and immediately ran into mistakes on the very first step:
>
> Use Git to Clone Poky¶
> Once you complete the setup instructions for your machine, you need to
> get a copy of the Poky repository on your build host. Use the following
> commands to clone the Poky repository and then checkout the yocto-2.6
> release:
>
>  $ git clone git://git.yoctoproject.org/poky
>  Cloning into 'poky'...
>  remote: Counting objects: 361782, done.
>  remote: Compressing objects: 100% (87100/87100), done.
>  remote: Total 361782 (delta 268619), reused 361439 (delta 268277)
>  Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s,
> done.
>  Resolving deltas: 100% (268619/268619), done.
>  Checking connectivity... done.
>  $ git checkout tags/yocto-2.5 -b my-yocto-2.5
>
> The previous Git checkout command creates a local branch named
> my-yocto-2.6. [...]
>
> It does? The 'git clone' command seems to be OK, but the second command
> fails:
>
> $ git clone git://git.yoctoproject.org/poky
> Cloning into 'poky'...
> remote: Counting objects: 428632, done.
> remote: Compressing objects: 100% (101203/101203), done.
> remote: Total 428632 (delta 320463), reused 428532 (delta 320363)
> Receiving objects: 100% (428632/428632), 153.01 MiB | 1.33 MiB/s, done.
> Resolving deltas: 100% (320463/320463), done.
> $ git checkout tags/yocto-2.5 -b my-yocto-2.5
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
>
> I re-tried the second command, changing the version from 2.5 to 2.6,
> and that didn't work either:
>
> $ git checkout tags/yocto-2.6 -b my-yocto-2.6
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not
> set).
>
> It looks like there's a missing 'cd poky' command that needs to be
> inserted before the 'git checkout', and the checkout command needs to
> be changed from 2.5 to 2.6.
>
> Has anybody tried this tutorial recently to see if it actually works?
>
> Is there a better getting started doc?
>
> --
> Grant
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Team Development Environment

[Scott Rifenbark]

Hi,

I am looking for real-world feedback from people involved with YP
development in a team environment.  I have a section (
https://yoctoproject.org/docs/2.6.1/dev-manual/dev-manual.html#usingpoky-changes-collaborate)
that discusses that environment.

If anyone is inclined, it would be cool to get some feedback on the
section.

Thanks very much!
Scott
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Porject

[Scott Rifenbark]

Hi Don,

I can't really advise you on this as I am not a Yocto developer.  However,
I can forward this question to the yocto@yoctoproject.org mail group and,
in particular, to a resource that is looking closely at kernel stuff to
help improve that manual and get it more up-to-date.  That guy is named
Richard Griffiths of Intel.  You should be able to get some help with
this.  Sorry... I wish I was a crack YP developer :)

Thanks,
Scott

On Sun, Jan 27, 2019 at 11:50 AM Don Osmond  wrote:

> Scott
>
> I have been reading your
> https://www.yoctoproject.org/docs/2.4/kernel-dev/kernel-dev.html and it
> has been very helpful.  I have a project where I am needing to get the
> ability to use iptables NAT which does not come in the core image from Digi
> which also uses Yocto.  In my Ubuntu 16.04 LTS development VM, I am able to
> build the base image (bitbake dey-image-qt), menuconfig the kernel config
> (bitbake -c devshell virtual/kernel), compile the kernel (bitbake -C
> compile virtual/kernel).  The results are in the
> /workspace/ccimx6ulsbc/tmp/deploy/images/ccimx6ulsbc as see in list below:
>
>
>
> dosmond@ubuntu:/workspace/ccimx6ulsbc/tmp/deploy/images/ccimx6ulsbc$ ls
>
> boot.scr
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.boot.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.recovery.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.manifest
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.tar.bz2
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.rootfs.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc-20190127164412.testdata.json
>
> dey-image-qt-x11-ccimx6ulsbc.boot.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc.manifest
>
> dey-image-qt-x11-ccimx6ulsbc.recovery.ubifs
>
> dey-image-qt-x11-ccimx6ulsbc.tar.bz2
>
> dey-image-qt-x11-ccimx6ulsbc.testdata.json
>
> dey-image-qt-x11-ccimx6ulsbc.ubifs
>
>
> dey-image-recovery-initramfs-ccimx6ulsbc-20190127161551.rootfs.cpio.gz.u-boot.tf
>
> dey-image-recovery-initramfs-ccimx6ulsbc-20190127161551.rootfs.manifest
>
> dey-image-recovery-initramfs-ccimx6ulsbc-20190127161551.testdata.json
>
> dey-image-recovery-initramfs-ccimx6ulsbc.cpio.gz.u-boot.tf
>
> dey-image-recovery-initramfs-ccimx6ulsbc.manifest
>
> dey-image-recovery-initramfs-ccimx6ulsbc.testdata.json
>
> imx6ul-ccimx6ulsbc.dtb
>
> imx6ul-ccimx6ulsbc-id135.dtb
>
> imx6ul-ccimx6ulsbc-id136.dtb
>
> imx6ul-ccimx6ulsbc-wb.dtb
>
> install_linux_fw_sd.scr
>
> modules--4.9-r0.5-ccimx6ulsbc-20190127182701.tgz
>
> modules-ccimx6ulsbc.tgz
>
> u-boot-ccimx6ulsbc1GB-2017.03-r0.imx
>
> u-boot-ccimx6ulsbc1GB.imx
>
> u-boot-ccimx6ulsbc-2017.03-r0.imx
>
> u-boot-ccimx6ulsbc.imx
>
> u-boot-ccimx6ulsbc.imx-ccimx6ulsbc
>
> u-boot-ccimx6ulsbc.imx-ccimx6ulsbc1GB
>
> u-boot.imx
>
> zImage
>
> zImage--4.9-r0.5-ccimx6ulsbc-20190127182701.bin
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-20190127182701.dtb
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-id135-20190127182701.dtb
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-id136-20190127182701.dtb
>
> zImage--4.9-r0.5-imx6ul-ccimx6ulsbc-wb-20190127182701.dtb
>
> zImage-ccimx6ulsbc.bin
>
> zImage-imx6ul-ccimx6ulsbc.dtb
>
> zImage-imx6ul-ccimx6ulsbc-id135.dtb
>
> zImage-imx6ul-ccimx6ulsbc-id136.dtb
>
> zImage-imx6ul-ccimx6ulsbc-wb.dtb
>
>
>
> So, what I am having an issue with are the steps to get the latest kernel
> changes a part of the image?  I thought if I ran “bitbake dey-image-qt”
> again that it would.  I think I am missing something.  Anything you can
> share would be greatly appreciated.
>
> Thanks
>
> Don
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image introspection

[Scott Rifenbark]

Hi Dimitris,

Any kind of procedures, flows, information developed that you think are
useful but not in the current YP documentation can be considered to be
added somewhere (manuals, wiki, etc.).  Is your "small tutorial" fully
captured here in your email? Or, do you have a separate document?  Any sort
of targeted task can be considered for the YP Development Tasks manual.  It
is full of various tasks that over the years have been declared important
or common.

Feel free to respond to me with any documentation suggestions/contributions
and so forth.

Scott

On Fri, Mar 29, 2019 at 1:50 AM Dimitris Tassopoulos 
wrote:

> Hi all,
>
> I was thinking that the mail list shouldn't be only for problems and
> questions and that from time to time, it would be nice to see some guides,
> tutorials or success stories from people that follow the list.
>
> Anyway, a few days ago someone had an issue with one of the BSPs I'm
> maintaining and I wrote him a small guide on how to -try- to resolve future
> issues like that. Then I thought that I haven't found a small tutorial
> like this. Maybe it already exists, but nevertheless I haven't seen it.
> Of course, those things are in the documentation, but they are documented
> as individual tools (which is the correct thing to do), but it's not very
> clear how to use all those things together to perform more complex tasks.
>
> So, in my case the issue was that ofono was installed in the image and that
> needed to be removed. Probably a lot of you already know the answer but for
> me that I've never bothered with that I had to track it down how it got in
> there.
>
> Everything from now on assumes that you've setup up your bitbake
> environment
> of your build with whatever setup scripts you're using (e.g.
> *oe-init-build-env*)
>
> There are several ways to do introspection on an image. For example,
> let's say that you found a file in the in rootfs and you want to know which
> recipe added that file. Then you can use this command:
>
> oe-pkgdata-util find-path /usr/sbin/ofonod
>
>
> *oe-pkgdata-util* is a utility in *poky/scripts/oe-pkgdata-util* and
> `find-path` is pretty obvious what it does. This will return:
>
> ofono: /usr/sbin/ofonod
>
>
> So now you know that it's indeed the *ofono* recipe that adds this file.
> Next,
> you need how this did get in the image (probably some other dependency
> because you didn't). Then you can use the `-g` parameter with bitbake like
> this:
>
> bitbake -g allwinner-image
>
>
> This will create a file called `recipe-depends.dot`. This is a dot file
> that
> has all the dependencies in the image. You can use the same command to get
> the dependencies for a recipe, but now we care about the image.
>
> Next step is to search in that file, why that key is there. Why is `-w` and
> key is `-k`. You can always remember this as "-w-hy that -k-ey is there?"
> and you
> run this command:
>
> oe-depends-dot -k ofono -w recipe-depends.dot
>
>
> This will return the recipe that has this as dependency.
>
>
>> Because: allwinner-image packagegroup-base
>
>
> That means that the key is there because of allwinner-image (this is the
> image
> recipe, but it can be any other image) and because the *allwinner-image*
> inherits the
> *packagegroup-base*. So this packagegroup is the guilty.
>
> Let's find this thing now. Get in the meta layer sources folder and run
> this
>
> find . | grep packagegroup-base
>
>
> This will return
>
>> ./poky/meta/recipes-core/packagegroups/packagegroup-base.bb
>
>
> Great. Open this file to an editor and find where is *ofono*. Gotcha, is
> in:
>
> RDEPENDS_packagegroup-base-3g
>
>
> Then it's the *packagegroup-base-3g* that does that. Probably that's a
> recipe
> or package group file, so you can run:
>
> find . | grep packagegroup-base-3g
>
>
> But you get nothing... Then probably this is declared somewhere a file with
> another name, so let's search inside the files in the poky layer:
>
> grep -nriI ackagegroup-base-3g
>
>
> And we get:
>
> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:35:
>> ${@bb.utils.contains("DISTRO_FEATURES", "3g", "packagegroup-base-3g", "",
>> d)} \
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:73:
>> ${@bb.utils.contains('COMBINED_FEATURES', '3g', 'packagegroup-base-3g',
>> '',d)} \
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:122:
>> d.setVar("ADD_3G", "packagegroup-base-3g")
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:316:SUMMARY_packagegroup-base-3g
>> = "Cellular data support"
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:317:RDEPENDS_packagegroup-base-3g
>> = "\
>> poky/meta/recipes-core/packagegroups/packagegroup-base.bb:320:RRECOMMENDS_packagegroup-base-3g
>> = "\
>
>
>
> So it's actually in the same file that we already opened. Here you can
> facepalm,
> but we didn't know that, so this would be the procedure anyways to track
> it down.
> Now, search for *packagegroup-base-3g* inside the 
> 

Re: [yocto] [PATCH] Documentation: unify the spacing for questions in various places e.g. before the [Y/n] there should be a space, and before "?" there should be none. Unify the questions where the s

[Scott Rifenbark]

Hi,

I applied changes for docs.  Someone else needs to get the changes into the
*.sh files.
See inline comments for links to adjusted text.

Scott

On Fri, Mar 29, 2019 at 2:33 AM Gianfranco Costamagna <
costamagna.gianfra...@gmail.com> wrote:

> Signed-off-by: Gianfranco Costamagna 
> Signed-off-by: Gianfranco Costamagna 
> ---
>  documentation/kernel-dev/kernel-dev-common.xml| 2 +-
>  documentation/sdk-manual/sdk-extensible.xml   | 2 +-
>  documentation/sdk-manual/sdk-using.xml| 2 +-
>  meta/files/toolchain-shar-extract.sh  | 4 ++--
>  .../initrdscripts/files/init-install-efi-testfs.sh| 2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/documentation/kernel-dev/kernel-dev-common.xml
> b/documentation/kernel-dev/kernel-dev-common.xml
> index 7ff4cba3b0..7d8826fa35 100644
> --- a/documentation/kernel-dev/kernel-dev-common.xml
> +++ b/documentation/kernel-dev/kernel-dev-common.xml
> @@ -185,7 +185,7 @@
>   Poky (Yocto Project Reference Distro) Extensible SDK installer
> version 
>
> 
>   Enter target directory for SDK (default: ~/poky_sdk):
> - You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed[Y/n]? Y
> + You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed [Y/n]? Y
>

See step 6 for this doc change -
https://yoctoproject.org/docs/2.7/kernel-dev/kernel-dev.html#getting-ready-to-develop-using-devtool


  Extracting SDK..done
>   Setting it up...
>   Extracting buildtools...
> diff --git a/documentation/sdk-manual/sdk-extensible.xml
> b/documentation/sdk-manual/sdk-extensible.xml
> index 09f06088d2..9be082d8ba 100644
> --- a/documentation/sdk-manual/sdk-extensible.xml
> +++ b/documentation/sdk-manual/sdk-extensible.xml
> @@ -157,7 +157,7 @@
>   Poky (Yocto Project Reference Distro) Extensible SDK installer
> version 2.5
>
> ==
>   Enter target directory for SDK (default: ~/poky_sdk):
> - You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed[Y/n]? Y
> + You are about to install the SDK to "/home/scottrif/poky_sdk".
> Proceed [Y/n]? Y
>

See the output here -
https://yoctoproject.org/docs/2.7/sdk-manual/sdk-manual.html#sdk-installing-the-extensible-sdk


  Extracting SDK..done
>   Setting it up...
>   Extracting buildtools...
> diff --git a/documentation/sdk-manual/sdk-using.xml
> b/documentation/sdk-manual/sdk-using.xml
> index dd220c340b..06fdb573ed 100644
> --- a/documentation/sdk-manual/sdk-using.xml
> +++ b/documentation/sdk-manual/sdk-using.xml
> @@ -149,7 +149,7 @@
>   Poky (Yocto Project Reference Distro) SDK installer version 
>   ===
>   Enter target directory for SDK (default: /opt/poky/):
> - You are about to install the SDK to "/opt/poky/".
> Proceed[Y/n]? Y
> + You are about to install the SDK to "/opt/poky/". Proceed
> [Y/n]? Y
>

See the output here -
https://yoctoproject.org/docs/2.7/sdk-manual/sdk-manual.html#sdk-installing-the-sdk


  Extracting SDK
> ..done
>   Setting it up...done
>   SDK has been successfully set up and is ready to be used.
> diff --git a/meta/files/toolchain-shar-extract.sh
> b/meta/files/toolchain-shar-extract.sh
> index 9eabd62630..156085b500 100644
> --- a/meta/files/toolchain-shar-extract.sh
> +++ b/meta/files/toolchain-shar-extract.sh
> @@ -185,11 +185,11 @@ fi
>
>  if [ -e "$target_sdk_dir/environment-setup-@REAL_MULTIMACH_TARGET_SYS@"
> ]; then
> echo "The directory \"$target_sdk_dir\" already contains a SDK for
> this architecture."
> -   printf "If you continue, existing files will be overwritten!
> Proceed[y/N]? "
> +   printf "If you continue, existing files will be overwritten!
> Proceed [y/N]? "
>
> default_answer="n"
>  else
> -   printf "You are about to install the SDK to \"$target_sdk_dir\".
> Proceed[Y/n]? "
> +   printf "You are about to install the SDK to \"$target_sdk_dir\".
> Proceed [Y/n]? "
>
> default_answer="y"
>  fi
> diff --git
> a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> index 9c4b263d54..b351985a61 100644
> --- a/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> +++ b/meta/recipes-core/initrdscripts/files/init-install-efi-testfs.sh
> @@ -27,7 +27,7 @@ do
>  # Try sleeping here to avoid getting kernel messages
>  # obscuring/confusing user
>  sleep 5
> -echo "Found drive at /dev/${device}. Do you want to
> install this image there ? [y/n]"
> +  

Re: [yocto] ROS support on yocto project

[Scott Rifenbark]

On Thu, Feb 28, 2019 at 9:26 AM Matthias Schoepfer <
matthias.schoep...@googlemail.com> wrote:

> Hi!
>
>
> Yes, there is, there is a meta-ros.
>
>
> For your convenience:
>
>
>
> https://discourse.ros.org/t/new-version-of-meta-ros-for-kinetic-distribution/2833
>
> https://github.com/bmwcarit/meta-ros
>
>
> It does work. BTW, afaik there is no yocto 3.9.0, 2.6.1 is last stable if
> I am not mistaken.
>
yes - see https://wiki.yoctoproject.org/wiki/Releases


> Regards,
>
>
>
>Matthias
>
>
> On 2/21/19 9:26 AM, Carlos Pozos Ochoa wrote:
>
> I recently acquire a Renesas R Car M3 board which runs on an embedded
> linux image build by means of the Yocto project. We are currently using
> YOCTO 3.9.0. We are looking forward to implement ROS kinetic libraries on
> this embedded linux. Does the yocto project supports this libraries? In the
> case it does, is there any special process to install and run them? Or is
> it work as a normal linux distribution?
>
>
> --
> ___
> 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] Removing busybox

[Scott Rifenbark]

Hi,

Sounds like this issue might have some documentation ripples when it
settles out.

Scott

On Wed, Feb 27, 2019 at 10:46 AM Tom Rini  wrote:

> On Wed, Feb 27, 2019 at 06:35:10PM +, Burton, Ross wrote:
> > On Wed, 27 Feb 2019 at 17:58, Tom Rini  wrote:
> > > I'm not sure we can blacklist busybox from the build at this time
> > > (hddimg requires initramfs that requires busybox) but instead only
> force
> > > remove it from the image and ensure it still builds.
> >
> > Don't build an image with a initramfs?
>
> OK, so I've kicked things a bit harder again, and here's what I see as
> the (small) rub.
> $ git grep hddimg meta/conf/
> meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg"
>
> So yes, we can do a test with qemux86/qemux86-64 and documenting this in
> local.conf.sample is good (and a packagegroup that gives more 1:1
> functionality is on my TODO list somewhere).  But it's also true that
> we'll get people with "I can't remove busybox and I tried what it says"
> posts since blindly pulling in hddimg gives at least:
> ERROR: Nothing RPROVIDES 'busybox-mdev' (but
> /home/trini/work/OE/oe-core/meta/recipes-core/initrdscripts/
> initramfs-framework_1.0.bb
> RDEPENDS on or otherwise requires it)
>
> That's the point I want to make, after throwing out a quick test build
> dir.
>
> --
> Tom
> --
> ___
> 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] [OE-core] Information about non-traditional uses of the Yocto Project and OpenEmbedded

[Scott Rifenbark]

Sounds like good potential for a section or chapter in the user docs.

Scott

On Wed, Feb 27, 2019 at 12:01 PM Philip Balister 
wrote:

> During the last OpenEmbedded developer meeting, it became clear that
> people are using the Yocto project/OpenEmbedded in spaces outside what
> we think of as traditional embedded. Lieu Ta is working on a
> presentation for the Linux Foundation Leadership Summit and we would
> like to collect as many "unusual" applications are possible from
> companies we can publicly acknowledge. Unusual is edge, containers,
> desktop, etc. Or even really interesting embedded applications :)
>
> Please drop me an email (off list is fine) with enough info for us to
> add you to a slide and acknowledge your work.
>
> Thanks,
>
> Philip
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] ref-manual: Fix typo

[Scott Rifenbark]

Thanks Daniel,

Fixed and published to tips in Sumo, Thud, and Warrior.

See
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-USERADD_PACKAGES
for example in 2.7 (under development) YP Reference Manual.

Scott

On Thu, Feb 21, 2019 at 4:11 AM Daniel Ammann 
wrote:

> Signed-off-by: Daniel Ammann 
> ---
>  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 d9d0915a8..9a47bcd33 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -16884,7 +16884,7 @@
>   USERADD_PACKAGES = "${PN}"
>  
>  
> -If follows that if you are going to use the
> +It follows that if you are going to use the
>  USERADD_PACKAGES variable,
>  you need to set one or more of the
>   linkend='var-USERADD_PARAM'>USERADD_PARAM,
> --
> 2.11.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INHIBIT_SYSROOT_STRIP

[Scott Rifenbark]

Dimitris,

Good find... I will see about documenting this.

Scott

On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos 
wrote:

> Hi all,
>
> this is not a request for help.
>
> Today, I've found a very nice option which is not documented
> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
> inside the poky/meta/classes/staging.bbclass.
>
> I had an issue with a recipe that had a few binaries that I wanted to add
> to the
> recipe-sysroot-native in order to build another package and I was getting
> errors
> because the do_populate_sysroot couldn't strip those binaries. I've
> searched in
> the source and found that the author of that code was handling this case,
> but it's
> not documented (at least in the latest mega-manual).
>
> Therefore, I'm dropping this message as a reference to other that might
> need it.
>
> Regards,
> Dimitris
> --
> ___
> 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] INHIBIT_SYSROOT_STRIP

[Scott Rifenbark]

Got it. Thanks Khem.

On Wed, Mar 6, 2019 at 10:22 AM Khem Raj  wrote:

> On Wed, Mar 6, 2019 at 9:48 AM Scott Rifenbark 
> wrote:
> >
> > I think we should probably at least document the variable in the YP
> Reference Manual's glossary.  Correct?
> >
>
> yes and also mention that we only expect it to be used in rare special
> curcumstances, e,g, prebuilt binaries etc.
>
> > Scott
> >
> > On Wed, Mar 6, 2019 at 9:24 AM Khem Raj  wrote:
> >>
> >> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark 
> wrote:
> >> >
> >> > Dimitris,
> >> >
> >> > Good find... I will see about documenting this.
> >> >
> >>
> >> Although its not encouranged to use it, its to be used as a last resort
> >> we use it sparingly.
> >>
> >> > Scott
> >> >
> >> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos <
> dimt...@gmail.com> wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> this is not a request for help.
> >> >>
> >> >> Today, I've found a very nice option which is not documented
> >> >> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
> >> >> inside the poky/meta/classes/staging.bbclass.
> >> >>
> >> >> I had an issue with a recipe that had a few binaries that I wanted
> to add to the
> >> >> recipe-sysroot-native in order to build another package and I was
> getting errors
> >> >> because the do_populate_sysroot couldn't strip those binaries. I've
> searched in
> >> >> the source and found that the author of that code was handling this
> case, but it's
> >> >> not documented (at least in the latest mega-manual).
> >> >>
> >> >> Therefore, I'm dropping this message as a reference to other that
> might need it.
> >> >>
> >> >> Regards,
> >> >> Dimitris
> >> >> --
> >> >> ___
> >> >> 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] INHIBIT_SYSROOT_STRIP

[Scott Rifenbark]

I think we should probably at least document the variable in the YP
Reference Manual's glossary.  Correct?

Scott

On Wed, Mar 6, 2019 at 9:24 AM Khem Raj  wrote:

> On Wed, Mar 6, 2019 at 8:15 AM Scott Rifenbark 
> wrote:
> >
> > Dimitris,
> >
> > Good find... I will see about documenting this.
> >
>
> Although its not encouranged to use it, its to be used as a last resort
> we use it sparingly.
>
> > Scott
> >
> > On Wed, Mar 6, 2019 at 8:12 AM Dimitris Tassopoulos 
> wrote:
> >>
> >> Hi all,
> >>
> >> this is not a request for help.
> >>
> >> Today, I've found a very nice option which is not documented
> >> which is the INHIBIT_SYSROOT_STRIP and is used in the sysroot_strip()
> >> inside the poky/meta/classes/staging.bbclass.
> >>
> >> I had an issue with a recipe that had a few binaries that I wanted to
> add to the
> >> recipe-sysroot-native in order to build another package and I was
> getting errors
> >> because the do_populate_sysroot couldn't strip those binaries. I've
> searched in
> >> the source and found that the author of that code was handling this
> case, but it's
> >> not documented (at least in the latest mega-manual).
> >>
> >> Therefore, I'm dropping this message as a reference to other that might
> need it.
> >>
> >> Regards,
> >> Dimitris
> >> --
> >> ___
> >> 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] packaging documentation

[Scott Rifenbark]

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  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
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] packaging documentation

[Scott Rifenbark]

Hey Steve,

Ok - I will file this later today so you don't need to worry about it.  I
will use "Need better explanation of how recipes create packages" as the
topic.  I will add you to the CC list so you can track it.

Thanks for helping with finding issues with the docs.

Scott

On Wed, Mar 13, 2019 at 9:47 AM Steve Scott  wrote:

> 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  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
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Yocto Project Status WW12'19

[Scott Rifenbark]

Hi,

Here is a "start" at publicly documenting QA... I started on this a while
back and got content from Richard only.  It would be good to have eyes on
this so it could be completed.  There are holes and stuff may have
changed.  If you want, please look it over and send me feedback.

See https://yoctoproject.org/docs/scott_temp/test-manual/test-manual.html

Thanks,
Scott

On Tue, Mar 19, 2019 at 8:53 AM  wrote:

> Current Dev Position: YP 2.7 M3 (New feature Freeze has begun.)
>
> Next Deadline: YP 2.7 M3 Cutoff was Feb. 25, 2019
>
>
>
> SWAT Team Rotation:
>
>- SWAT lead is currently: Armin
>- SWAT team rotation: Armin -> Paul on Mar. 23, 2019
>- SWAT team rotation: Paul -> Ross on Mar. 30, 2019
>- https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>
>
> Key Status/Updates:
>
>- M3 has not built yet however most major pieces are in place,
>including now, agreement on the new QA process. The delay is partly due to
>RP travel with others able to cover being unavailable for other reasons,
>combined with infrastructure issues.
>- The remaining questions for M3 are:
>   - Public documentation of the new QA process
>   - Upgrade for uninative for glibc 2.29
>   - Mesa upgrade? (unlikely given failures in testing)
>- The Yocto Project has updated to its new governance model which
>includes establishing a Technical Steering Committee (TSC) for Yocto
>Project. This is designed to complement  and work alongside the
>OpenEmbedded TSC. Three members of the YP TSC are selected by the Yocto
>Project governing board and those people are Ross Burton, Khem Raj and
>Richard Purdie. The remaining two seats will be elected by OpenEmbedded. It
>is intended the TSC will take over the release process, SWAT team, bug
>triage and feature planning/development for 2.8.
>- YP 2.5.3 continues to be blocked on autobuilder-helper changes for
>the stable branches and the resulttool changes in master to move to the new
>QA process.
>- There is discussion on the openembedded-architecture list about
>changes to the stable branch patch criteria to bring us more into line with
>current industry best practices and thinking.
>
>
>
> Planned Releases for YP 2.7:
>
>- YP 2.7 M3 Cutoff was Feb. 25, 2019
>- YP 2.7 M3 Release Target was Mar. 8, 2019
>- YP 2.7 M4 Cutoff is Apr. 1, 2019
>- YP 2.7 M4 Release Target is Apr. 26, 2019
>
>
>
> Planned upcoming dot releases:
>
>- YP 2.5.3 (Sumo) will be targeted after YP 2.7 M2 is done.
>- YP 2.5.4 (Sumo) will be targeted after YP 2.7 M4 is done.
>- YP 2.6.2 (Thud) will be targeted after YP 2.5.4 is done.
>
>
>
> Tracking Metrics:
>
>- WDD 2432 (last week 2439) (
>https://wiki.yoctoproject.org/charts/combo.html)
>- Poky Patch Metrics
>   - Total patches found: 1526 (last week 1523)
>   - Patches in the Pending State: 656 (43%) [last week 657 (43%)]
>
>
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.7_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.7_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...@gmail.com
> *
>
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Guidance to start yocto project.

[Scott Rifenbark]

H Rahul,

I would start with the
https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html
manual.  Gets you up and running.

Scott

On Mon, Mar 11, 2019 at 9:32 AM rahul chauhan 
wrote:

> Hello,
>
> I am beginner with yocto project and i want to learn the yocto project and
> start working on it.
> can you please guide how can i proceed step by step and  what are the
> prerequisites?
>
> Thanks and Regards
> Rahul Chauhan
> --
> ___
> 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] [yocto-doc][PATCH] ref-manual: fix copy-paste style error (`SRC_URI`)

[Scott Rifenbark]

Filip,

Thanks for the catch.  I have fixed this in the upcoming 2.7 version of the
YP reference guide.  You can see the fix here -
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-SRC_URI.

I will back-port to the relevant YP-maintained development branches (thud
and sumo).

Scott

On Mon, Mar 11, 2019 at 8:30 AM Filip Jareš  wrote:

> The update fixes a copy-paste-and-forget-to-update-everything error
> in the documentation of the `SRC_URI` entry in the Reference Manual.
> The `maxdate` paragraph just repeated what is there for the
> neighboring `mindate` paragraph which was incorrect.
>
> What is documented (and patched) here is implemented in the
> `should_apply` function in `meta/lib/oe/patch.py`.
>
> Signed-off-by: Filip Jareš 
> ---
>  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 3ffa92c..b49fb25 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -13798,7 +13798,7 @@
>  
>
>  maxdate -
>  Apply the patch only if
> SRCDATE
> -is not later than
> mindate.
> +is not later than
> maxdate.
>  
>
>  minrev -
>  Apply the patch only if
> SRCREV
> --
> 2.7.4
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [PATCH 1/3] opkg: add --ignore-recommends flag

[Scott Rifenbark]

This change looks like it impacts documentation (i.e.
https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-BAD_RECOMMENDATIONS).
When will this change go into effect?

Scott

On Thu, Feb 7, 2019 at 7:58 AM Alejandro del Castillo <
alejandro.delcasti...@ni.com> wrote:

> To be used for BAD_RECOMMENDATIONS feature.
>
> Signed-off-by: Alejandro del Castillo 
> ---
>  ...pkg-add-add-ignore-recommends-option.patch | 259 ++
>  meta/recipes-devtools/opkg/opkg_0.4.0.bb  |   1 +
>  2 files changed, 260 insertions(+)
>  create mode 100644
> meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
>
> diff --git
> a/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> new file mode 100644
> index 00..47d1b3c37e
> --- /dev/null
> +++
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> @@ -0,0 +1,259 @@
> +From 64aa98646a17c299bf37af2975b98daf5d7d30b4 Mon Sep 17 00:00:00 2001
> +From: Alejandro del Castillo 
> +Date: Thu, 31 Jan 2019 18:16:08 -0600
> +Subject: [PATCH] libopkg: add --add-ignore-recommends option
> +
> +Add option to ignore specific recommended packages. On the libsolv
> +backed, this feature will only work on libsolv version > 0.7.2 [1].
> +
> +[1]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openSUSE_libsolv_issues_254=DwIBaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=GObNHzFJpWpf_PripIrf-K2RhsktYdAUEieAJexXOKw=3G-meChUqClFggFPqsrAxIZBfLnRKIHm62Uuy1X6nQQ=
> +
> +Signed-off-by: Alejandro del Castillo 
> +
> +Upstream-Status: Accepted
> +---
> + libopkg/opkg_conf.c   |  2 +
> + libopkg/opkg_conf.h   |  1 +
> + .../solvers/internal/pkg_depends_internal.c   |  3 +-
> + libopkg/solvers/libsolv/opkg_solver_libsolv.c | 21 ++-
> + man/opkg.1.in |  3 +
> + src/opkg.c|  6 ++
> + tests/Makefile|  1 +
> + tests/core/43_add_ignore_recommends.py| 62 +++
> + 8 files changed, 97 insertions(+), 2 deletions(-)
> + create mode 100755 tests/core/43_add_ignore_recommends.py
> +
> +diff --git a/libopkg/opkg_conf.c b/libopkg/opkg_conf.c
> +index 06880a1..f2330cd 100644
> +--- a/libopkg/opkg_conf.c
>  b/libopkg/opkg_conf.c
> +@@ -597,6 +597,7 @@ int opkg_conf_init(void)
> + pkg_dest_list_init(_config->tmp_dest_list);
> + nv_pair_list_init(_config->arch_list);
> + str_list_init(_config->exclude_list);
> ++str_list_init(_config->ignore_recommends_list);
> +
> + return 0;
> + }
> +@@ -938,6 +939,7 @@ void opkg_conf_deinit(void)
> + pkg_dest_list_deinit(_config->pkg_dest_list);
> + nv_pair_list_deinit(_config->arch_list);
> + str_list_deinit(_config->exclude_list);
> ++str_list_deinit(_config->ignore_recommends_list);
> +
> + if (opkg_config->verbosity >= DEBUG) {
> + hash_print_stats(_config->pkg_hash);
> +diff --git a/libopkg/opkg_conf.h b/libopkg/opkg_conf.h
> +index eb56a29..316c500 100644
> +--- a/libopkg/opkg_conf.h
>  b/libopkg/opkg_conf.h
> +@@ -61,6 +61,7 @@ typedef struct opkg_conf {
> + pkg_dest_list_t tmp_dest_list;
> + nv_pair_list_t arch_list;
> + str_list_t exclude_list;
> ++str_list_t ignore_recommends_list;
> +
> + int restrict_to_default_dest;
> + pkg_dest_t *default_dest;
> +diff --git a/libopkg/solvers/internal/pkg_depends_internal.c
> b/libopkg/solvers/internal/pkg_depends_internal.c
> +index cd56d84..5deee70 100644
> +--- a/libopkg/solvers/internal/pkg_depends_internal.c
>  b/libopkg/solvers/internal/pkg_depends_internal.c
> +@@ -228,7 +228,8 @@ int pkg_hash_fetch_unsatisfied_dependencies(pkg_t
> *pkg,
> + || compound_depend->type == SUGGEST)
> + && (satisfying_pkg->state_want == SW_DEINSTALL
> + || satisfying_pkg->state_want == SW_PURGE
> +-|| opkg_config->no_install_recommends);
> ++|| opkg_config->no_install_recommends
> ++||
> str_list_contains(_config->ignore_recommends_list,
> satisfying_pkg->name));
> + if (ignore) {
> + opkg_msg(NOTICE,
> +  "%s: ignoring recommendation for "
> +diff --git a/libopkg/solvers/libsolv/opkg_solver_libsolv.c
> b/libopkg/solvers/libsolv/opkg_solver_libsolv.c
> +index 2b27e3a..403e07b 100644
> +--- a/libopkg/solvers/libsolv/opkg_solver_libsolv.c
>  b/libopkg/solvers/libsolv/opkg_solver_libsolv.c
> +@@ -484,6 +484,7 @@ static void pkg2solvable(pkg_t *pkg, Solvable
> *solvable_out)
> + static void populate_installed_repo(libsolv_solver_t *libsolv_solver)
> + {
> + int i;
> ++Id what;
> +
> + 

Re: [yocto] [OE-core] [PATCH 1/3] opkg: add --ignore-recommends flag

[Scott Rifenbark]

On Thu, Feb 7, 2019 at 9:44 AM Alejandro Del Castillo <
alejandro.delcasti...@ni.com> wrote:

>
>
> On 2/7/19 11:36 AM, Scott Rifenbark wrote:
> > This change looks like it impacts documentation (i.e.
> >
> https://yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#var-BAD_RECOMMENDATIONS.
>
> > When will this change go into effect?
>
> I believe it doesn't. It is refactoring the opkg implementation to
> leverage a new opkg feature (--add-ignore-recommends), which is a more
> robust implementation. Should be transparent to users.
>

Thank you for the clarification... I thought it might be a user option.


> > On Thu, Feb 7, 2019 at 7:58 AM Alejandro del Castillo
> > mailto:alejandro.delcasti...@ni.com>>
> wrote:
> >
> > To be used for BAD_RECOMMENDATIONS feature.
> >
> > Signed-off-by: Alejandro del Castillo  > <mailto:alejandro.delcasti...@ni.com>>
> > ---
> >   ...pkg-add-add-ignore-recommends-option.patch | 259
> ++
> >   meta/recipes-devtools/opkg/opkg_0.4.0.bb
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__opkg-5F0.4.0.bb=DwMFaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=8hd_9vew95YIf_VIv2QHNu2EFnc3G2WZ5KA2Upnv5j8=JvgzuAyAoVrkeSZAdWZUuIsFWQ8okApbCk1iiF13CDc=>
>
> >  |   1 +
> >   2 files changed, 260 insertions(+)
> >   create mode 100644
> >
>  
> meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> >
> > diff --git
> >
>  
> a/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> >
>  
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> > new file mode 100644
> > index 00..47d1b3c37e
> > --- /dev/null
> > +++
> >
>  
> b/meta/recipes-devtools/opkg/opkg/0001-libopkg-add-add-ignore-recommends-option.patch
> > @@ -0,0 +1,259 @@
> > +From 64aa98646a17c299bf37af2975b98daf5d7d30b4 Mon Sep 17 00:00:00
> 2001
> > +From: Alejandro del Castillo  > <mailto:alejandro.delcasti...@ni.com>>
> > +Date: Thu, 31 Jan 2019 18:16:08 -0600
> > +Subject: [PATCH] libopkg: add --add-ignore-recommends option
> > +
> > +Add option to ignore specific recommended packages. On the libsolv
> > +backed, this feature will only work on libsolv version > 0.7.2 [1].
> > +
> > +[1]
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openSUSE_libsolv_issues_254=DwIBaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=GObNHzFJpWpf_PripIrf-K2RhsktYdAUEieAJexXOKw=3G-meChUqClFggFPqsrAxIZBfLnRKIHm62Uuy1X6nQQ=
> > +
> > +Signed-off-by: Alejandro del Castillo  > <mailto:alejandro.delcasti...@ni.com>>
> > +
> > +Upstream-Status: Accepted
> > +---
> > + libopkg/opkg_conf.c   |  2 +
> > + libopkg/opkg_conf.h   |  1 +
> > + .../solvers/internal/pkg_depends_internal.c   |  3 +-
> > + libopkg/solvers/libsolv/opkg_solver_libsolv.c | 21 ++-
> > + man/opkg.1.in
> > <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__opkg.1.in=DwMFaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=wNcrL2akRn6jfxhHaKavUrJB_C9JAMXtynjLd8ZzgXQ=8hd_9vew95YIf_VIv2QHNu2EFnc3G2WZ5KA2Upnv5j8=8yIWRVT6JV0YnkHzVgeo8pAkiFPM4xz8y9APvxobmhY=>
>
> > |  3 +
> > + src/opkg.c|  6 ++
> > + tests/Makefile|  1 +
> > + tests/core/43_add_ignore_recommends.py| 62
> +++
> > + 8 files changed, 97 insertions(+), 2 deletions(-)
> > + create mode 100755 tests/core/43_add_ignore_recommends.py
> > +
> > +diff --git a/libopkg/opkg_conf.c b/libopkg/opkg_conf.c
> > +index 06880a1..f2330cd 100644
> > +--- a/libopkg/opkg_conf.c
> >  b/libopkg/opkg_conf.c
> > +@@ -597,6 +597,7 @@ int opkg_conf_init(void)
> > + pkg_dest_list_init(_config->tmp_dest_list);
> > + nv_pair_list_init(_config->arch_list);
> > + str_list_init(_config->exclude_list);
> > ++str_list_init(_config->ignore_recommends_list);
> > +
> > + return 0;
> > + }
> > +@@ -938,6 +939,7 @@ void opkg_conf_deinit(void)
> > + pkg_dest_list_deinit(_config->pkg_dest_list);
> > + nv_pair_

Re: [yocto] YPTM minutes

[Scott Rifenbark]

On Tue, Feb 5, 2019 at 10:24 AM Joshua Watt  wrote:

> On Tue, 2019-02-05 at 10:11 -0800, Scott Rifenbark wrote:
>
>
>
> On Tue, Feb 5, 2019 at 8:37 AM  wrote:
>
> *Yocto Technical Team Minutes for Feb. 5, 2019.*
>
>
>
> Attendees: Armin, David, Joshua, Randy, Tim, Richard G., Stephen,
> Jan-Simon, Manjukum, Tracey, Trevor, Nick, Richard P, Mark, Kate, Michael,
>
>
>
> YP 2.6.1 was released on Feb. 4, 2019.
>
> YP 2.7 M2 was built and is in QA and is 79% done.  See:
> https://wiki.yoctoproject.org/wiki/2.7_QA_Status
>
>
>
> Armin agreed to add Ubuntu 18.4 to YP 2.6 series and we will use in for YP
> 2.7
>
> We discussed that the YP 2.6 manual doesn’t have an upgrading to YP 2.6.
> Tracey will look into this.
>
>
> Can I get some clarification on this.  Ubuntu 18.04 seems to be an LTS.  I
> don't have "LTS" listed in the 2.6 ref-manual (
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros)
> but do have Ubuntu 18.04 listed as a supported distro.  What is meant by
> "... the YP 2.6 manual doesn't have an upgrading to YP 2.6."?  - Thanks
> Scott
>
>
> I think there is a little confusion here. There are actually 2 issues:
>
> 1) The Yocto 2.6 manual doesn't have the "Moving to the Yocto Project 2.6
> Release" section to describe the changes that have been made from 2.5 ->
> 2.6 (
> https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#moving-to-the-yocto-project-2.5-release).
> Oddly, this section *is* present in the "latest" mega manual.
>

I think I know what happened here.  The tip of "thud" has the section on
migrating to YP 2.6.  However, as pointed out, the published 2.6 manual
does not have it.  During a release, docs lag behind software and
everything else that gets locked down.  I wrote that section for the 2.6
release of the manuals.  Likely, some important fix had to be back-ported
to the manuals post-release and I probably was working from a cloned thud
repo that was checked out on the tag "Yocto-2.6", which is earlier than the
commits for that section.  So, when I rebuilt manuals post-release for
various reasons, it was not included.  I can fix that for the 2.6 version
of the manual.  It is already present in the newly released 2.6.1 version
of the manual.  This problem is ongoing with the docs.  I just recently
have come up with a work-around for these types of situations.  I am now
keeping a local area of changed doc source files per-release for released
manuals.  That way, in the future, I can checkout a release by tag, make
any special changes, and then populate the local repo with the previously
changed files.  Rebuilding then produces manuals with all the one-off
changes that have occurred. - Thanks for the clarification Joshua.


> 2) The second (unrelated) issue has to do with reporting 18.04 as a
> supported host distro. I'm not as familiar with this one, so I'll let
> someone else chime in.
>
>
>
>
> We discussed the status of YP 2.7 upgrades and we are doing OK there.  We
> are struggling on new features YP 2.7.  Richard is primarily working to
> stabilize the autobuilder to produce an automated QA report to allow QA to
> transition from Intel.
>
>
>
> Richard discussed maintainers of OE-Core.  AUH is sending requests but not
> getting feedback.
>
>
>
> Richard discussed that we have issues with some products and need support
> from the community to fix.
>
>
>
> Tim discussed ptest issues Richard has identified.
>
>
>
> Richard asked if there were ideas about how to better communicate with the
> community. No specific suggestions.
>
>
>
> Thanks,
>
>
>
> *Stephen K. Jolley*
>
> *Yocto Project Project Manager*
>
> (*Cell*:(208) 244-4460
>
> * *Email*:  *sjolley.yp...@gmail.com
> *
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> --
>
> Joshua Watt 
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YPTM minutes

[Scott Rifenbark]

On Tue, Feb 5, 2019 at 1:05 PM akuster808  wrote:

>
>
> On 2/5/19 10:24 AM, Joshua Watt wrote:
>
> On Tue, 2019-02-05 at 10:11 -0800, Scott Rifenbark wrote:
>
>
>
> On Tue, Feb 5, 2019 at 8:37 AM  wrote:
>
> *Yocto Technical Team Minutes for Feb. 5, 2019.*
>
>
>
> Attendees: Armin, David, Joshua, Randy, Tim, Richard G., Stephen,
> Jan-Simon, Manjukum, Tracey, Trevor, Nick, Richard P, Mark, Kate, Michael,
>
>
>
> YP 2.6.1 was released on Feb. 4, 2019.
>
> YP 2.7 M2 was built and is in QA and is 79% done.  See:
> https://wiki.yoctoproject.org/wiki/2.7_QA_Status
>
>
>
> Armin agreed to add Ubuntu 18.4 to YP 2.6 series and we will use in for YP
> 2.7
>
> We discussed that the YP 2.6 manual doesn’t have an upgrading to YP 2.6.
> Tracey will look into this.
>
>
> Can I get some clarification on this.  Ubuntu 18.04 seems to be an LTS.  I
> don't have "LTS" listed in the 2.6 ref-manual (
> https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros)
> but do have Ubuntu 18.04 listed as a supported distro.  What is meant by
> "... the YP 2.6 manual doesn't have an upgrading to YP 2.6."?  - Thanks
> Scott
>
>
> I think there is a little confusion here. There are actually 2 issues:
>
> 1) The Yocto 2.6 manual doesn't have the "Moving to the Yocto Project 2.6
> Release" section to describe the changes that have been made from 2.5 ->
> 2.6 (
> https://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html#moving-to-the-yocto-project-2.5-release).
> Oddly, this section *is* present in the "latest" mega manual.
>
> 2) The second (unrelated) issue has to do with reporting 18.04 as a
> supported host distro. I'm not as familiar with this one, so I'll let
> someone else chime in.
>
>
> This is in thud-next:
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/distro/poky.conf?h=thud-next=263cf203bd363a6b9d58524ff5862d23c76e6390
>
> Once I get sumo stabilized, the same will be validated and back ported.
>

Once poky.conf is legit for a release, I have a script that extracts these
repos out and that is what I use for the manuals.
Thanks


> - armin
>
>
>
>
>
> We discussed the status of YP 2.7 upgrades and we are doing OK there.  We
> are struggling on new features YP 2.7.  Richard is primarily working to
> stabilize the autobuilder to produce an automated QA report to allow QA to
> transition from Intel.
>
>
>
> Richard discussed maintainers of OE-Core.  AUH is sending requests but not
> getting feedback.
>
>
>
> Richard discussed that we have issues with some products and need support
> from the community to fix.
>
>
>
> Tim discussed ptest issues Richard has identified.
>
>
>
> Richard asked if there were ideas about how to better communicate with the
> community. No specific suggestions.
>
>
>
> Thanks,
>
>
>
> *Stephen K. Jolley*
>
> *Yocto Project Project Manager*
>
> (*Cell*:(208) 244-4460
>
> * *Email*:  *sjolley.yp...@gmail.com
> *
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> --
>
> Joshua Watt 
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [YP Core] Thud moved out of active releases

[Scott Rifenbark]

Denis,

I don't understand this myself.  I don't believe 2.6.1 has released just
yet.  I have symlinks set such that the "current" documentation points to
"2.6" so any URL for a manual such as
https://yoctoproject.org/docs/current/ref-manual/ref-manual.html resolves
to the "2.6" manual.

Scott

On Mon, Jan 28, 2019 at 10:33 PM Hopp, Denis 
wrote:

> Hello all,
>
> is it intended that the thud release 2.6 documents overview went
> into archived documents? I can't find any news about it and thud is
> still promoted as latest release on the frontpage.
> (https://www.yoctoproject.org/)
> Or is this standard procedure and 2.6.1 will follow shortly?
>
> Greetings
> --
> ___
> 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] (no subject)

[Scott Rifenbark]

Hi,

Have you tried adding the feature through MACHINE_FEATURES variable? (
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#ref-features-machine
and
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#var-MACHINE_FEATURES
).

A developer can probably provide more detailed information Antonio.

Thanks,
Scott

On Tue, Jan 29, 2019 at 8:12 AM Antonio Santagiuliana <
santantonios...@gmail.com> wrote:

> Hi,
> I am missing the steps required to add to an image the support for an RTC
> plugged in to I2C1 interface, with autostart.
> is there a page with instructions ?
> thank you
> --
> ___
> 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] Yocto doc typo

[Scott Rifenbark]

Ahh... The elusive "eSDSK"... :)

Thanks Brian.  I will fix that right away.

Here is the section in the 2.6.1 manual -
https://yoctoproject.org/docs/2.6.1/overview-manual/overview-manual.html#openembedded-build-system-workflow
.
Here is the section in the "latest" (2.7) manual -
https://yoctoproject.org/docs/2.7/overview-manual/overview-manual.html#openembedded-build-system-workflow

Scott.

On Tue, Feb 5, 2019 at 10:09 AM Brian Silverman 
wrote:

> Minor typo at (eSDSK -> eSDK):
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/documentation/overview-manual/overview-manual-yp-intro.xml#n1160
>
>
>
>
> --
> Brian Silverman
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YPTM minutes

[Scott Rifenbark]

On Tue, Feb 5, 2019 at 8:37 AM  wrote:

> *Yocto Technical Team Minutes for Feb. 5, 2019.*
>
>
>
> Attendees: Armin, David, Joshua, Randy, Tim, Richard G., Stephen,
> Jan-Simon, Manjukum, Tracey, Trevor, Nick, Richard P, Mark, Kate, Michael,
>
>
>
> YP 2.6.1 was released on Feb. 4, 2019.
>
> YP 2.7 M2 was built and is in QA and is 79% done.  See:
> https://wiki.yoctoproject.org/wiki/2.7_QA_Status
>
>
>
> Armin agreed to add Ubuntu 18.4 to YP 2.6 series and we will use in for YP
> 2.7
>
> We discussed that the YP 2.6 manual doesn’t have an upgrading to YP 2.6.
> Tracey will look into this.
>

Can I get some clarification on this.  Ubuntu 18.04 seems to be an LTS.  I
don't have "LTS" listed in the 2.6 ref-manual (
https://yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#detailed-supported-distros)
but do have Ubuntu 18.04 listed as a supported distro.  What is meant by
"... the YP 2.6 manual doesn't have an upgrading to YP 2.6."?  - Thanks
Scott


>
> We discussed the status of YP 2.7 upgrades and we are doing OK there.  We
> are struggling on new features YP 2.7.  Richard is primarily working to
> stabilize the autobuilder to produce an automated QA report to allow QA to
> transition from Intel.
>
>
>
> Richard discussed maintainers of OE-Core.  AUH is sending requests but not
> getting feedback.
>
>
>
> Richard discussed that we have issues with some products and need support
> from the community to fix.
>
>
>
> Tim discussed ptest issues Richard has identified.
>
>
>
> Richard asked if there were ideas about how to better communicate with the
> community. No specific suggestions.
>
>
>
> Thanks,
>
>
>
> *Stephen K. Jolley*
>
> *Yocto Project Project Manager*
>
> (*Cell*:(208) 244-4460
>
> * *Email*:  *sjolley.yp...@gmail.com
> *
>
>
> --
> ___
> 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] [Openembedded-architecture] [OE-core] Eclipse support dropped with immediate effect

[Scott Rifenbark]

Richard and Armin,

I am going to start pulling Eclipse from the docs today.  The changes won't
make the frozen rc build but the website docs will reflect reality.

Scott

On Thu, Apr 11, 2019 at 12:20 AM  wrote:

> On Thu, 2019-04-11 at 08:42 +0530, akuster808 wrote:
> >
> > On 4/10/19 3:11 PM, richard.pur...@linuxfoundation.org wrote:
> > > On Wed, 2019-04-10 at 05:56 +0530, akuster808 wrote:
> > > > On 4/9/19 8:52 PM, Richard Purdie wrote:
> > > > > I'm sorry to have to say this but the project is terminating
> > > > > its
> > > > > official eclipse plugin support with immediate effect.
> > > > Does this affect the stable branches as well?
> > > Yes, I think we'll just be removing the target from the autobuilder
> > > entirely.
> >
> > Have we every removed a feature from a release? Do we need to doc
> > this ?
>
> Its not so much remove as not release. No, we haven't and yes, we do
> need to document it in the release notes.
>
> Cheers,
>
> Richard
>
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] distrodata documentation in 2.7 Mega Manual

[Scott Rifenbark]

I can take the section in the ref-manual for the "distrodata.bbclass" out.
However, I could use some clarifications on the following areas where
"distrdata" is referenced.  I don't think I can just remove all of the
terms.

Here they are:

 * In dev-manual's "Using the Auto Upgrade Helper (AUH)" section -
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#gs-using-the-auto-upgrade-helper:
Step 5 talks about making configurations in the local.conf file.  First
thing is to enable "distrodata" by inheriting the class.  Do we have an
equivalent for this now that the class is gone?

* in ref-manual's "do_distrodata" task section -
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-distrodata:
Does this task disappear as well?  Or, is there an equivalent?

* In ref-manual's "do_checkpkg" task section -
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-checkpkg:
This task was included as part of the distrodata.bbclass.  How do we
address the do_checkpkg task section now?

* In the UPSTREAM_CHECK_GETTAGREGEX variable description in the ref-manual
glossary -
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_GITTAGREGEX:
How do we change this?

* in the UPSTREAM_CHECK_REGEX variable description also in the glossary -
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_REGEX:
How do we change this?

* in the UPSTREAM_CHECK_URI variable description also int he glossary -
https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_URI:
How do we change this?

Thanks,
Scott

On Tue, May 21, 2019 at 12:31 PM Paul Barker  wrote:

> Just reading the 2.7 Mega Manual at
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html and
> noticed a possible bug.
>
> "24.15.9. Removed Classes" indicates that the `distrodata` class is now
> gone. However it's still referred to in several other places in the
> documentation. May need a bit of garbage collection.
>
> Thanks,
>
> --
> Paul Barker
> Managing Director & Principal Engineer
> Beta Five Ltd
> --
> ___
> 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] distrodata documentation in 2.7 Mega Manual

[Scott Rifenbark]

Paul & Alexander,

I have updated the YP doc set for the removal of the three classes.
Changes apply to the 2.7 and "master" (2.8)
trees.  You see the effects in:

 * https://yoctoproject.org/docs/2.7/mega-manual/mega-manual.html
 * https://yoctoproject.org/docs/2.8/mega-manual/mega-manual.html

Thanks for pointing these out and for the added explanations.

Scott

On Thu, May 23, 2019 at 2:23 AM Alexander Kanavin 
wrote:

> On Thu, 23 May 2019 at 02:22, Scott Rifenbark 
> wrote:
> >  * In dev-manual's "Using the Auto Upgrade Helper (AUH)" section -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#gs-using-the-auto-upgrade-helper:
> Step 5 talks about making configurations in the local.conf file.  First
> thing is to enable "distrodata" by inheriting the class.  Do we have an
> equivalent for this now that the class is gone?
>
> This is no longer necessary, you can remove the step.
>
> > * in ref-manual's "do_distrodata" task section -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-distrodata:
> Does this task disappear as well?  Or, is there an equivalent?
>
> There is no equivalent, you can remove the sectrion.
>
> > * In ref-manual's "do_checkpkg" task section -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#ref-tasks-checkpkg:
> This task was included as part of the distrodata.bbclass.  How do we
> address the do_checkpkg task section now?
>
> The equivalent functionality is provided by running devtool - 'devtool
> latest-version' for one recipe, 'devtool check-upgrade-status' for
> several (or all).
>
> > * In the UPSTREAM_CHECK_GETTAGREGEX variable description in the
> ref-manual glossary -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_GITTAGREGEX:
> How do we change this?
> > * in the UPSTREAM_CHECK_REGEX variable description also in the glossary
> -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_REGEX:
> How do we change this?
> > * in the UPSTREAM_CHECK_URI variable description also int he glossary -
> https://www.yoctoproject.org/docs/2.7/mega-manual/mega-manual.html#var-UPSTREAM_CHECK_URI:
> How do we change this?
>
> All three should refer to the equivalent replacement (see above)
> provided by devtool.
>
> Alex
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] NPM Fetcher question

[Scott Rifenbark]

Hi,

I am trying to determine if the information in
https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM is relevant and
up-to-date for current YP release.  I am having trouble finding a resource
familiar with this topic.

Can anyone point me to the expert for this area?

Thanks,
Scott Rifenbark (docs)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[Scott Rifenbark]

Great, thanks!

On Thu, May 2, 2019 at 11:21 AM akuster  wrote:

>
>
> On 5/2/19 10:45 AM, Scott Rifenbark wrote:
>
> The term "Container Layer" was put in the ref-manual by me to describe a
> "meta-*" layer that had other "meta-*" layers (see
> https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
> and the term "Container Layer").  Maybe this was never a good term?  I
> don't know.  Nobody has said anything about that term for many releases.
>
> The problem Robert points out needs to be fixed in the BSP manual as
> "meta-intel" is not longer qualifying by my definition.  I can fix that.
>
> Is "Container Layer" ok as I have defined it?
>
> in those terms above, yes its fine.
>
> thanks for clarifying.
>
> Armin
>
>
> Thanks,
> Scott
>
> On Thu, May 2, 2019 at 10:21 AM akuster  wrote:
>
>>
>>
>> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
>> > As meta-intel is no longer a container layer, use meta-xilinx as
>> > an example instead.
>>
>> I thought "meta-virtualization" was a container layer?
>>
>> IMHO, a BSP should only deal with getting a MACHINE booted.
>>
>> - armin
>> >
>> > Signed-off-by: Robert P. J. Day 
>> >
>> > ---
>> >
>> > diff --git a/documentation/bsp-guide/bsp.xml
>> b/documentation/bsp-guide/bsp.xml
>> > index 0bb0b68ab..a53ff6bce 100644
>> > --- a/documentation/bsp-guide/bsp.xml
>> > +++ b/documentation/bsp-guide/bsp.xml
>> > @@ -146,18 +146,15 @@
>> >
>> >  
>> >  Some layers function as a layer to hold other BSP layers.
>> > -These layers are knows as
>> > +These layers are known as
>> >  "> url='_DOCS_REF_URL;#term-container-layer'>container layers".
>> >  An example of this type of layer is the
>> > -meta-intel layer.
>> > -This layer contains BSP layers for the Intel-core2-32
>> > -Intel Common Core
>> > -(Intel-core2-32) and the Intel-corei7-64
>> > -Intel Common Core
>> > -(Intel-corei7-64).
>> > -the meta-intel layer also contains
>> > -the common/ directory, which contains
>> > -common content across those layers.
>> > +meta-xilinx layer.
>> > +This container layer contains some basic top-level information,
>> > +as well as three actual Xilinx-related BSP layers,
>> > +meta-xilinx-bsp,
>> > +meta-xilinx-contrib, and
>> > +meta-xilinx-standalone.
>> >  
>> >
>> >  
>> >
>>
>> --
>> ___
>> 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] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[Scott Rifenbark]

The term "Container Layer" was put in the ref-manual by me to describe a
"meta-*" layer that had other "meta-*" layers (see
https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
and the term "Container Layer").  Maybe this was never a good term?  I
don't know.  Nobody has said anything about that term for many releases.

The problem Robert points out needs to be fixed in the BSP manual as
"meta-intel" is not longer qualifying by my definition.  I can fix that.

Is "Container Layer" ok as I have defined it?

Thanks,
Scott

On Thu, May 2, 2019 at 10:21 AM akuster  wrote:

>
>
> On 5/2/19 6:19 AM, Robert P. J. Day wrote:
> > As meta-intel is no longer a container layer, use meta-xilinx as
> > an example instead.
>
> I thought "meta-virtualization" was a container layer?
>
> IMHO, a BSP should only deal with getting a MACHINE booted.
>
> - armin
> >
> > Signed-off-by: Robert P. J. Day 
> >
> > ---
> >
> > diff --git a/documentation/bsp-guide/bsp.xml
> b/documentation/bsp-guide/bsp.xml
> > index 0bb0b68ab..a53ff6bce 100644
> > --- a/documentation/bsp-guide/bsp.xml
> > +++ b/documentation/bsp-guide/bsp.xml
> > @@ -146,18 +146,15 @@
> >
> >  
> >  Some layers function as a layer to hold other BSP layers.
> > -These layers are knows as
> > +These layers are known as
> >  " url='_DOCS_REF_URL;#term-container-layer'>container layers".
> >  An example of this type of layer is the
> > -meta-intel layer.
> > -This layer contains BSP layers for the Intel-core2-32
> > -Intel Common Core
> > -(Intel-core2-32) and the Intel-corei7-64
> > -Intel Common Core
> > -(Intel-corei7-64).
> > -the meta-intel layer also contains
> > -the common/ directory, which contains
> > -common content across those layers.
> > +meta-xilinx layer.
> > +This container layer contains some basic top-level information,
> > +as well as three actual Xilinx-related BSP layers,
> > +meta-xilinx-bsp,
> > +meta-xilinx-contrib, and
> > +meta-xilinx-standalone.
> >  
> >
> >  
> >
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] "meta-intel" layer bad example of a "container layer"

[Scott Rifenbark]

Robert,

I have updated the BSP Guide and removed all but a single instance of
"container layer".  You can see what I have left at the bottom of this
section -
https://yoctoproject.org/docs/2.8/bsp-guide/bsp-guide.html#bsp-layers.
Also, the YP Reference Manual "Terms" section has been updated with similar
text -
https://yoctoproject.org/docs/2.8/ref-manual/ref-manual.html#ref-terms.

Thanks,
Scott

On Thu, May 2, 2019 at 5:59 AM Burton, Ross  wrote:

> Right, meta-intel isn't a container layer.  It just has two MACHINES.
>
> Ross
>
> On Thu, 2 May 2019 at 13:54, Robert P. J. Day 
> wrote:
> >
> >
> >   catching up with all the YP stuff i've missed over the last while
> > and, in the BSP guide in the layers section:
> >
> >
> https://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers
> >
> > one reads:
> >
> > "Some layers function as a layer to hold other BSP layers. These
> > layers are knows as "container layers". An example of this type of
> > layer is the meta-intel layer. This layer contains BSP layers for the
> > Intel-core2-32 Intel® Common Core (Intel-core2-32) and the
> > Intel-corei7-64 Intel® Common Core (Intel-corei7-64). the meta-intel
> > layer also contains the common/ directory, which contains common
> > content across those layers. "
> >
> >   pretty sure meta-intel has been a regular BSP layer for a while now,
> > so another example should be used. off the top of my head, i'd suggest
> > meta-xilinx:
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/
> >
> > unless anyone has strong objections, i can send in a patch.
> >
> > rday
> >
> > --
> >
> > 
> > Robert P. J. Day Ottawa, Ontario, CANADA
> >  http://crashcourse.ca
> >
> > Twitter:   http://twitter.com/rpjday
> > LinkedIn:   http://ca.linkedin.com/in/rpjday
> >
> --
> > ___
> > 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] [yocto-announce] [ANNOUNCEMENT] Yocto Project 2.7.1 (Warrior 21.0.1) Released

[Scott Rifenbark]

Hi,

"Current" docs symlink now pointing to 2.7.1 release (i.e.
https://yoctoproject.org/docs/current/ref-manual/ref-manual.html).

Thanks,
Scott

On Tue, Jul 16, 2019 at 5:26 PM Tummalapalli, Vineela <
vineela.tummalapa...@intel.com> wrote:

> Hello,
>
> We are pleased to announce the Yocto Project 2.7.1 (warrior-21.0.1)
> Release is now available for download.
>
>
> http://downloads.yoctoproject.org/releases/yocto/yocto-2.7.1/poky-warrior-21.0.1.tar.bz2
>
> http://mirrors.kernel.org/yocto/yocto/yocto-2.7.1/poky-warrior-21.0.1.tar.bz2
>
> A gpg signed version of these release notes is available at:
>
> http://downloads.yoctoproject.org/releases/yocto/yocto-2.7.1/RELEASENOTES
>
> Full Test Report:
>
> http://downloads.yoctoproject.org/releases/yocto/yocto-2.7.1/testreport.txt
>
> Thank you for everyone's contributions to this release.
>
> Vineela Tummalapalli
> Yocto Project Build and Release
> Vineela Tummalapalli 
>
> --
> ___
> 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] [yocto-docs][PATCH] ref-manual: Correct the requirements for KERNEL_DEVICETREE

[Scott Rifenbark]

Adrian,

Thanks for the update to the KERNEL_DEVICETREE variable.  I have applied
this patch to the 2.8 version of the reference manual:
https://yoctoproject.org/docs/2.8/ref-manual/ref-manual.html#var-KERNEL_DEVICETREE
.

Scott

On Fri, Aug 23, 2019 at 8:06 AM Adrian Bunk  wrote:

> Signed-off-by: Adrian Bunk 
> ---
>  documentation/ref-manual/ref-variables.xml | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/documentation/ref-manual/ref-variables.xml
> b/documentation/ref-manual/ref-variables.xml
> index 0080364e4f..33afaa5f45 100644
> --- a/documentation/ref-manual/ref-variables.xml
> +++ b/documentation/ref-manual/ref-variables.xml
> @@ -7580,15 +7580,9 @@
>  However, providing just the
> .dtb
>  file is preferred.
>  
> -In order to use this variable, you must have the
> include
> -files in your kernel recipe:
> -
> - require recipes-kernel/linux/linux-dtb.inc
> -
> -or
> -
> - require recipes-kernel/linux/linux-yocto.inc
> -
> +In order to use this variable, the
> + linkend='ref-classes-kernel-devicetree'>kernel-devicetree
> +class must be inherited.
>  
>  
>  
> --
> 2.17.1
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto