Re: [yocto] bitbake memres usecase

[Paul Eggleton]

Hi Trevor,

On Wednesday, 2 August 2017 12:09:48 AM CEST Trevor Woerner wrote:
> I'm trying to understand if memres is right for me.
> 
> Every night my machine, via jenkins, grinds away doing about a dozen
> builds. Each of these builds is for a separate MACHINE, in separate
> directories, with separate layers, configurations, etc. My jenkins
> instance has two executors (on the same machine). So if one build runs
> long, two builds could be running at the same time.
> 
> Should I enable memres?
> 
> Also, sometimes I kick off a jenkins job or two during the day, while
> at the same time doing manual builds somewhere else on the same
> machine. Maybe all I want to do manually is to run "bitbake -e" and
> investigate some packageconfig setting. Would having one
> memres-bitbake running cause issues with multiple builds running at
> the same time?
> 
> Is it possible to have one memres-bitbake running for the jenkins
> jobs, but have my own bitbake running for my manual jobs?
> 
> Or maybe none of the above is the use-case for memres?

It's really not going to save you much - it's not intended to help automated 
builds, it's really to improve interactive usage for repeated bitbake runs 
where a few seconds delay on each command is annoying. With regard to 
simultaneous access, there are certain operations that can internally be done 
whilst a normal build is running, and bitbake's command structure does support 
that, but I don't think bitbake is set up to actually enable that kind of 
usage at the moment.

Another thing to consider is that whilst it wasn't labelled as such, memres 
was fairly buggy until just recently in master, and we've just changed things 
so that it's effectively replaced by the default mode of operation where it 
can optionally remain resident by setting a timeout variable.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Perforce fetcher ignores module and label

[Katu Txakur]

Hi,

I'm still having problems fetching from Perforce. Is there any
documentation based on the latest implementation of the
poky/bitbake/lib/bb/fetch2/perforce.py file?
The copyright 2016 points to Kodak Alaris, Inc. Should I contact them?

I would appreciate if someone could point me in the right direction.

Regards,
Katu

2017-07-25 10:05 GMT+01:00 Katu Txakur :

> Hi,
>
> I'm upgrading a recipe that fetches the source code from Perforce.
>
> The old recipe was:
>
> SRC_URI = " \
>   p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
>   "
>
> With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
> outside SRC_URI, leaving the recipe with:
>
> SRC_URI = " \
>   p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> local/path/relativeto/p4;label=${P4CHANGELIST} \
>   "
>
> The Perforce fetcher kind of works, but it seems to be ignoring the
> "module" and the "label" attributes. After reading the Python script I can
> see that after the "@", only the substring before the first ";" is used.
>
> Is there a way to set module and label/changelist? I have several folders
> per recipe that I need to map to different subfolders and with the current
> script some of the folders don't get fetched.
>
> Thanks for your time.
>
> Regards,
> Katu
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] installing iso images in legacy mode

[Markus Volk]

Perhaps the issue should be fixed by making this switch static ?



On Tue, 1 Aug 2017 21:58:16 +0200
Markus Volk  wrote:

> I had some time to look at this issue today. Since grub was recently updated 
> i tried using the old recipes from pyro. This fixed booting without efi. Then 
> i had a look at meta/recipes-core/initrdscripts/files/init-install.sh
> 
> My suspicion was, that this line
> 
> grub_version=$(grub-install -v|sed 's/.* \([0-9]\).*/\1/')
> 
> turns out to be zero with grub-202, and thereby messes the whole thing up
> 
> Changing to:
> 
> grub_version=202
> 
> fixed my legacy boot problem.
> 
> :)
> 
> On Mon, 31 Jul 2017 17:27:07 +0200
> Markus Volk  wrote:
> 
> > Iso Images (x86_64) created with the current master fail when trying to 
> > install using the legacy bios startup. Live boot from usb is fine, but when 
> > installing, i´m getting an error ... "/usr/share/locale" could not be 
> > found. After reboot i'm getting dropped to grub-shell, because the kernel 
> > could not be loaded.
> > 
> > When setting the bios startup to uefi mode, everything works as expected.
> > 
> > Has legacy pcbios mode been dropped or is this some kind of bug ?
> > 
> > -- 
> > Markus Volk 
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> -- 
> Markus Volk 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


-- 
Markus Volk 


0001-init-install.sh-fix-grub-install-for-legacy-pcbios.patch
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Perforce fetcher ignores module and label

[Paul Eggleton]

Hi Katu,

Andrew Bradford (on CC) was the last person to make significant changes to 
that module. I believe it's not very widely used - none of the recipes we 
commonly deal with make use of it and thus few of us have enough experience 
with it to give good advice. If Andrew doesn't have any ideas, the code 
shouldn't be too hard to follow and we will accept patches (particularly if 
they are accompanied with a good explanation of why the change is needed in 
the commit message).

Cheers,
Paul

On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> Hi,
> 
> I'm still having problems fetching from Perforce. Is there any
> documentation based on the latest implementation of the
> poky/bitbake/lib/bb/fetch2/perforce.py file?
> The copyright 2016 points to Kodak Alaris, Inc. Should I contact them?
> 
> I would appreciate if someone could point me in the right direction.
> 
> Regards,
> Katu
> 
> 2017-07-25 10:05 GMT+01:00 Katu Txakur :
> 
> > Hi,
> >
> > I'm upgrading a recipe that fetches the source code from Perforce.
> >
> > The old recipe was:
> >
> > SRC_URI = " \
> >   p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> > rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
> >   "
> >
> > With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
> > outside SRC_URI, leaving the recipe with:
> >
> > SRC_URI = " \
> >   p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > local/path/relativeto/p4;label=${P4CHANGELIST} \
> >   "
> >
> > The Perforce fetcher kind of works, but it seems to be ignoring the
> > "module" and the "label" attributes. After reading the Python script I can
> > see that after the "@", only the substring before the first ";" is used.
> >
> > Is there a way to set module and label/changelist? I have several folders
> > per recipe that I need to map to different subfolders and with the current
> > script some of the folders don't get fetched.
> >
> > Thanks for your time.
> >
> > Regards,
> > Katu
> >
> 


-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] postinstall intercept hooks fail because of missing qemuwrapper

[Andersen, Christian]

Hello,

we are using the current version of pyro. When building an image recipe we get 
some warnings, that some postinstall intercept hooks failed. The log-file of 
do_rootfs shows:

NOTE: Running intercept scripts:
NOTE: > Executing update_gio_module_cache intercept ...
/home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_gio_module_cache:
 9: 
/home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_gio_module_cache:
 qemuwrapper: not found
WARNING: The postinstall intercept hook 'update_gio_module_cache' failed (exit 
code: 127)! See log for details! (Output: b'')
WARNING: The postinstalls for the following packages will be postponed for 
first boot: libglib-2.0-0
NOTE: > Executing update_font_cache intercept ...
/home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_font_cache:
 11: 
/home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_font_cache:
 qemuwrapper: not found
WARNING: The postinstall intercept hook 'update_font_cache' failed (exit code: 
127)! See log for details! (Output: b'')
WARNING: The postinstalls for the following packages will be postponed for 
first boot: ttf-sazanami-mincho ttf-arphic-uming ttf-dejavu-sans 
ttf-dejavu-sans-mono ttf-devanagari

So qemuwrapper is missing. How can I fix this?

Kind regards
Christian


KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 
3924 - USt-Id-Nr./Vat No.: DE 813742170
Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
16-0 * Telefax: +49  2351 16-2400
Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 
2331 8040-602
Geschäftsführung: Dr.-Ing. Dipl.-Wirt.Ing. Manfred Gerhard, Dipl.-Ing. Marwin 
Kinzl, Dipl.-Oec. Andreas Kostal

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

Re: [yocto] postinstall intercept hooks fail because of missing qemuwrapper

[Markus Volk]

hi,

this could be fixed by adding "qemuwrapper-cross" to the depends of your 
image.bb

regards
Markus

On Wed, 2 Aug 2017 09:24:06 +
"Andersen, Christian"  wrote:

> Hello,
> 
> we are using the current version of pyro. When building an image recipe we 
> get some warnings, that some postinstall intercept hooks failed. The log-file 
> of do_rootfs shows:
> 
> NOTE: Running intercept scripts:
> NOTE: > Executing update_gio_module_cache intercept ...
> /home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_gio_module_cache:
>  9: 
> /home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_gio_module_cache:
>  qemuwrapper: not found
> WARNING: The postinstall intercept hook 'update_gio_module_cache' failed 
> (exit code: 127)! See log for details! (Output: b'')
> WARNING: The postinstalls for the following packages will be postponed for 
> first boot: libglib-2.0-0
> NOTE: > Executing update_font_cache intercept ...
> /home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_font_cache:
>  11: 
> /home/anders05/Dev/build-puck/build/tmp/work/abc-def-linux-gnueabi/puck-image-basic/1.0-r0/intercept_scripts/update_font_cache:
>  qemuwrapper: not found
> WARNING: The postinstall intercept hook 'update_font_cache' failed (exit 
> code: 127)! See log for details! (Output: b'')
> WARNING: The postinstalls for the following packages will be postponed for 
> first boot: ttf-sazanami-mincho ttf-arphic-uming ttf-dejavu-sans 
> ttf-dejavu-sans-mono ttf-devanagari
> 
> So qemuwrapper is missing. How can I fix this?
> 
> Kind regards
> Christian
> 
> 
> KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn 
> HRB 3924 - USt-Id-Nr./Vat No.: DE 813742170
> Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
> 16-0 * Telefax: +49  2351 16-2400
> Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax 
> +49 2331 8040-602
> Geschäftsführung: Dr.-Ing. Dipl.-Wirt.Ing. Manfred Gerhard, Dipl.-Ing. Marwin 
> Kinzl, Dipl.-Oec. Andreas Kostal
> 


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

Re: [yocto] Perforce fetcher ignores module and label

[Katu Txakur]

Thank you Paul,
I will wait and see if Andrew Bradford can kindly have a look at this.

Cheers,
Katu

2017-08-02 9:28 GMT+01:00 Paul Eggleton :

> Hi Katu,
>
> Andrew Bradford (on CC) was the last person to make significant changes to
> that module. I believe it's not very widely used - none of the recipes we
> commonly deal with make use of it and thus few of us have enough experience
> with it to give good advice. If Andrew doesn't have any ideas, the code
> shouldn't be too hard to follow and we will accept patches (particularly if
> they are accompanied with a good explanation of why the change is needed in
> the commit message).
>
> Cheers,
> Paul
>
> On Wednesday, 2 August 2017 9:40:10 AM CEST Katu Txakur wrote:
> > Hi,
> >
> > I'm still having problems fetching from Perforce. Is there any
> > documentation based on the latest implementation of the
> > poky/bitbake/lib/bb/fetch2/perforce.py file?
> > The copyright 2016 points to Kodak Alaris, Inc. Should I contact them?
> >
> > I would appreciate if someone could point me in the right direction.
> >
> > Regards,
> > Katu
> >
> > 2017-07-25 10:05 GMT+01:00 Katu Txakur :
> >
> > > Hi,
> > >
> > > I'm upgrading a recipe that fetches the source code from Perforce.
> > >
> > > The old recipe was:
> > >
> > > SRC_URI = " \
> > >   p4://${P4USER}:${P4PASSWD}:${P4HOST}:${P4PORT}@Depot/path/pe
> > > rforce/...;module=local/path/relativeto/p4;label=${P4CHANGELIST} \
> > >   "
> > >
> > > With the new version of /lib/bb/fetch2/perforce.py, I had to set P4PORT
> > > outside SRC_URI, leaving the recipe with:
> > >
> > > SRC_URI = " \
> > >   p4://${P4USER}:${P4PASSWD}@Depot/path/perforce/...;module=
> > > local/path/relativeto/p4;label=${P4CHANGELIST} \
> > >   "
> > >
> > > The Perforce fetcher kind of works, but it seems to be ignoring the
> > > "module" and the "label" attributes. After reading the Python script I
> can
> > > see that after the "@", only the substring before the first ";" is
> used.
> > >
> > > Is there a way to set module and label/changelist? I have several
> folders
> > > per recipe that I need to map to different subfolders and with the
> current
> > > script some of the folders don't get fetched.
> > >
> > > Thanks for your time.
> > >
> > > Regards,
> > > Katu
> > >
> >
>
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] postinstall intercept hooks fail because of missing qemuwrapper

[Andersen, Christian]

Hi Markus,

thanks for the hint. In my image recipe I was setting some other dependencies 
for wic using DEPENDS="...". So the dependency for qemuwrapper-cross, which is 
provided by image.bbclass, was overwritten. After changing my dependencies to 
DEPENDS_append it is working now.

Regards
Christian


> -Ursprüngliche Nachricht-
> Von: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> Im Auftrag von Markus Volk
> Gesendet: Mittwoch, 2. August 2017 11:36
> An: yocto@yoctoproject.org
> Betreff: Re: [yocto] postinstall intercept hooks fail because of missing
> qemuwrapper
> 
> hi,
> 
> this could be fixed by adding "qemuwrapper-cross" to the depends of your
> image.bb
> 
> regards
> Markus
> 
> On Wed, 2 Aug 2017 09:24:06 +
> "Andersen, Christian"  wrote:
> 
> > Hello,
> >
> > we are using the current version of pyro. When building an image recipe we 
> > get
> some warnings, that some postinstall intercept hooks failed. The log-file of
> do_rootfs shows:
> >
> >(...)
> >
> > So qemuwrapper is missing. How can I fix this?
> >
> > Kind regards
> > Christian

KOSTAL Industrie Elektrik GmbH - Sitz Lüdenscheid, Registergericht Iserlohn HRB 
3924 - USt-Id-Nr./Vat No.: DE 813742170
Postanschrift: An der Bellmerei 10, D-58513 Lüdenscheid * Telefon: +49  2351 
16-0 * Telefax: +49  2351 16-2400
Werksanschrift: Lange Eck 11, D-58099 Hagen * Tel. +49 2331 8040-601 * Fax +49 
2331 8040-602
Geschäftsführung: Dr.-Ing. Dipl.-Wirt.Ing. Manfred Gerhard, Dipl.-Ing. Marwin 
Kinzl, Dipl.-Oec. Andreas Kostal

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

Re: [yocto] How to strip down my Yocto Linux?

[Markus Volk]

I guess that depends on what your needs are. Personally i would start to build 
core-image-minimal and just add the packages i need

regards
Markus

On Wed, 2 Aug 2017 09:47:15 + (UTC)
Bacheh Karaji  wrote:

> 
> I would like to strip down my Yocto Linux before put in it to flash. Unneeded 
> software, man pages, POCO sample codes and other documentation just waste 
> resource, especially on the i.MX28 EVK with only 128MB flash.
> 
> My local.conf file looks following:
> 
> $ gedit conf/local.conf &
> ...
> IMAGE_INSTALL_append = " poco nginx canutils vsftpd curl fcgi spawn-fcgi 
> net-snmp util-linux ubiattach-klibc ubimkvol-klibc ubiformat-klibc minicom 
> net-tools zeroconf avahi-autoipd mtd-utils u-boot-fw-utils ethtool"
> ...
> I bitbake the image "core-image-base".
> 
> I was wondering, is there a way that I can delete all of the Unneeded files?
> 
> Can somebody help me howto strip down my Yocto Linux?
> 


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

Re: [yocto] How to strip down my Yocto Linux?

[Ayoub Zaki]

A quick win also to remove DISTRO features in local.conf that your 
application(s) does not need  :


DISTRO_FEATURES_remove = "bluetooth"
DISTRO_FEATURES_remove = "3g"
DISTRO_FEATURES_remove = "opengl"
DISTRO_FEATURES_remove = "wayland"
DISTRO_FEATURES_remove = "x11"
DISTRO_FEATURES_remove = "nfc"
DISTRO_FEATURES_remove = "nfs"
DISTRO_FEATURES_remove = "ext2"

etc...

--

Ayoub Zaki

ayoub.z...@embexus.com
Mobile: +49(0)176-62901545
Skype: ayoub.zaki_2
https://embexus.com


On 02.08.2017 11:57, Markus Volk wrote:

I guess that depends on what your needs are. Personally i would start to build 
core-image-minimal and just add the packages i need

regards
Markus

On Wed, 2 Aug 2017 09:47:15 + (UTC)
Bacheh Karaji  wrote:


I would like to strip down my Yocto Linux before put in it to flash. Unneeded 
software, man pages, POCO sample codes and other documentation just waste 
resource, especially on the i.MX28 EVK with only 128MB flash.

My local.conf file looks following:

$ gedit conf/local.conf &
...
IMAGE_INSTALL_append = " poco nginx canutils vsftpd curl fcgi spawn-fcgi net-snmp 
util-linux ubiattach-klibc ubimkvol-klibc ubiformat-klibc minicom net-tools zeroconf 
avahi-autoipd mtd-utils u-boot-fw-utils ethtool"
...
I bitbake the image "core-image-base".

I was wondering, is there a way that I can delete all of the Unneeded files?

Can somebody help me howto strip down my Yocto Linux?





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

Re: [yocto] How to strip down my Yocto Linux?

[Josef Holzmayr]

Hi!

At the moment it like this:

On 02.08.2017 11:47, Bacheh Karaji wrote:
> I bitbake the image "core-image-base"/.

You start out with a already big image setup.

IMAGE_INSTALL_append = " poco nginx canutils vsftpd curl fcgi spawn-fcgi 
net-snmp util-linux ubiattach-klibc ubimkvol-klibc ubiformat-klibc 
minicom net-tools zeroconf avahi-autoipd mtd-utils u-boot-fw-utils ethtool"


And then you add even more stuff.

After that, you want to remove lots of it again.

While that maybe technically works, its pretty pointless. You first 
waste a lot of compilation time in generating stuff, which you then need 
additional time to remove again.


The correct approach is to create an image recipe that exactly fits your 
needs. Usually one would start out with core-image-minimal.bb, copy that 
to your-cool-image.bb, and then add the additionally wanted packages in 
there.


Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

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

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

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

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

Re: [yocto] How to strip down my Yocto Linux?

[Burton, Ross]

First, the core images are examples; copy and paste the closest to what you
want and then modify the recipe.

If you want a really small image then start from core-image-minimal, but be
aware that is missing a lot of stuff you may actually want.

How to remove things depends on how they got installed in the first place.
Unless you have doc-pkgs in IMAGE_FEATURES then you shouldn't have any man
pages or documentation.  If the poco recipe installs sample code you don't
want then fix the recipe to put those in another package. etc etc.

Ross

On 2 August 2017 at 10:47, Bacheh Karaji  wrote:

> I would like to strip down my Yocto Linux before put in it to flash.
> Unneeded software, man pages, POCO sample codes and other documentation
> just waste resource, especially on the i.MX28 EVK with only 128MB flash.
>
> My local.conf file looks following:
>
>
>
>
>
> *$ gedit conf/local.conf & ... IMAGE_INSTALL_append = " poco nginx
> canutils vsftpd curl fcgi spawn-fcgi net-snmp util-linux ubiattach-klibc
> ubimkvol-klibc ubiformat-klibc minicom net-tools zeroconf avahi-autoipd
> mtd-utils u-boot-fw-utils ethtool" ... I bitbake the image
> "core-image-base"*.
>
> I was wondering, is there a way that I can delete all of the Unneeded
> files?
>
> Can somebody help me howto strip down my Yocto Linux?
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-qt4][PATCH] qwt: Skip the already-stripped QA test.

[Philip Balister]

In 2013, the poky reference distribution made already-stripped an error
not a warning. So if you try to build gnuradio with poky, it fails.

Since qt4 is not being updated and should go away eventually, skip
the check here.

Signed-off-by: Philip Balister 
---
 recipes-qt4/recipes-libs/qwt_6.0.1.bb | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/recipes-qt4/recipes-libs/qwt_6.0.1.bb 
b/recipes-qt4/recipes-libs/qwt_6.0.1.bb
index f38816a..2c95b8e 100644
--- a/recipes-qt4/recipes-libs/qwt_6.0.1.bb
+++ b/recipes-qt4/recipes-libs/qwt_6.0.1.bb
@@ -8,3 +8,6 @@ SRC_URI[qwt.md5sum] = "ace68558eab873e2da7e641179c4ef0c"
 SRC_URI[qwt.sha256sum] = 
"3fe19dd5962d705632fc2ef616b009299de6cf1e702538296924dbfdc8003cb2"
 
 RPROVIDES_${PN}-dev = "libqwt-dev"
+
+INSANE_SKIP_${PN} += "already-stripped"
+
-- 
2.7.5

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

Re: [yocto] local file update vs rebuild

[Takashi Matsuzawa]

Hello.

Thank you for your comment.


I want to double check.


 = image name

 = recipe within 


Then, I am not sure if doing below will rebuild  from scratch.


$ bitbake  -c cleansstate

$ bitbake 


Especially, I am doing things like below within my .


SRC_URI += "file://src/*;subdir=local"


I want to be sure that, if I make modification to the local files (referred to 
as file://... path within SRC_URI variable of  recipe), the changes are 
reflected to the final image.

(Not explicitly specifying -c cleansstate to ).


From: Khem Raj 
Sent: Tuesday, August 1, 2017 3:42 AM
To: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] local file update vs rebuild



On 7/31/17 4:39 AM, Takashi Matsuzawa wrote:
> Hello.
> I am uncertain about do_clean behavior with local files.
>
>
> Say, I have local files referred by my recipe, and I have made changes to the 
> files referred.
> (Note, there is no change in my .bb file itself.)
>
>
>> SRC_URI += "file://src/*;subdir=local"
>
>
> What makes those changed files reflected to the build?
> Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?
>
>
> According to the document
>
>
>> do_clean
>> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, 
>> do_install, and do_package).
>> if no changes have been made and the recipe is rebuilt after cleaning, 
>> output files are simply restored from the sstate cache.
>
>
> I want to avoid doing do_cleanall often, and I would like to tell bitbake 
> that my recipe needs rebuild at the same time not rebuilding others.
> But at the same time I want to avoid building my single explicity.
> I just want to build the image name as target.

I think ccleansstate should be good.

>
>

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

Re: [yocto] local file update vs rebuild

[Burton, Ross]

If you modify a recipe then anything that depends on it will be rebuilt.
So changing a file referenced in SRC_URI in a recipe will cause the image
to rebuild if you build the image.

Ross

On 2 August 2017 at 12:03, Takashi Matsuzawa  wrote:

> Hello.
>
> Thank you for your comment.
>
>
> I want to double check.
>
>
>  = image name
>
>  = recipe within 
>
>
> Then, I am not sure if doing below will rebuild  from scratch.
>
>
> $ bitbake  -c cleansstate
>
> $ bitbake 
>
>
> Especially, I am doing things like below within my .
>
>
> SRC_URI += "file://src/*;subdir=local"
>
> I want to be sure that, if I make modification to the local files
> (referred to as file://... path within SRC_URI variable of  recipe),
> the changes are reflected to the final image.
>
> (Not explicitly specifying -c cleansstate to ).
>
> --
> *From:* Khem Raj 
> *Sent:* Tuesday, August 1, 2017 3:42 AM
> *To:* Takashi Matsuzawa; yocto@yoctoproject.org
> *Subject:* Re: [yocto] local file update vs rebuild
>
>
>
> On 7/31/17 4:39 AM, Takashi Matsuzawa wrote:
> > Hello.
> > I am uncertain about do_clean behavior with local files.
> >
> >
> > Say, I have local files referred by my recipe, and I have made changes
> to the files referred.
> > (Note, there is no change in my .bb file itself.)
> >
> >
> >> SRC_URI += "file://src/*;subdir=local"
> >
> >
> > What makes those changed files reflected to the build?
> > Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?
> >
> >
> > According to the document
> >
> >
> >> do_clean
> >> do_unpack task forward (i.e. do_unpack, do_configure, do_compile,
> do_install, and do_package).
> >> if no changes have been made and the recipe is rebuilt after cleaning,
> output files are simply restored from the sstate cache.
> >
> >
> > I want to avoid doing do_cleanall often, and I would like to tell
> bitbake that my recipe needs rebuild at the same time not rebuilding others.
> > But at the same time I want to avoid building my single explicity.
> > I just want to build the image name as target.
>
> I think ccleansstate should be good.
>
> >
> >
>
>
> --
> ___
> 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-qt4][PATCH] qwt: Skip the already-stripped QA test.

[Paul Eggleton]

On Wednesday, 2 August 2017 12:56:58 PM CEST Philip Balister wrote:
> In 2013, the poky reference distribution made already-stripped an error
> not a warning. So if you try to build gnuradio with poky, it fails.
> 
> Since qt4 is not being updated and should go away eventually, skip
> the check here.
> 
> Signed-off-by: Philip Balister 
> ---
>  recipes-qt4/recipes-libs/qwt_6.0.1.bb | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/recipes-qt4/recipes-libs/qwt_6.0.1.bb 
> b/recipes-qt4/recipes-libs/qwt_6.0.1.bb
> index f38816a..2c95b8e 100644
> --- a/recipes-qt4/recipes-libs/qwt_6.0.1.bb
> +++ b/recipes-qt4/recipes-libs/qwt_6.0.1.bb
> @@ -8,3 +8,6 @@ SRC_URI[qwt.md5sum] = "ace68558eab873e2da7e641179c4ef0c"
>  SRC_URI[qwt.sha256sum] = 
> "3fe19dd5962d705632fc2ef616b009299de6cf1e702538296924dbfdc8003cb2"
>  
>  RPROVIDES_${PN}-dev = "libqwt-dev"
> +
> +INSANE_SKIP_${PN} += "already-stripped"
> +
> 

Merged to master, pyro and morty.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

[Khem Raj]

On Tue, Aug 1, 2017 at 11:42 PM, Riko Ho  wrote:
> Could it be this one ?
>
> https://www.devmanuals.net/install/ubuntu/ubuntu-12-04-lts-precise-pangolin/install-libthread-queue-perl.html
>

yes

> Thanks
>
>
> On 02/08/17 14:38, Khem Raj wrote:
>
> apply the solutions they may work for ubuntu
>
> On Tue, Aug 1, 2017 at 11:33 PM, Riko Ho  wrote:
>
> Dear Yocto Team Member,
>
> I'm building with Ubuntu 16
>
>
> On 02/08/17 14:31, Khem Raj wrote:
>
> On Tue, Aug 1, 2017 at 11:18 PM, Riko Ho  wrote:
>
> Dear Yocto Team Member,
>
> That's the branch :
>
> ==
>
> meta-poky
> meta-yocto-bsp= "pyro:e5aa1ac23669a45491de9ecffac491c01e70203f"
> openembedded-core = "master:2fd0757ae7fd63bc93a4ce8579c6ba0cdbb4c1cd"
> meta-openembedded
> meta-oe
> meta-xfce
> meta-gnome
> meta-python
> meta-multimedia
> meta-networking   = "master:b063789560bfb9c60a7a15277b5b3a9839b5ba74"
> meta-browser  =
> "firefox-52.1.2esr-2:c79cf6c7811afd2cd167e8967e3c29b1e797371e"
> meta-ti   = "master:872d418f6e503dea66e3533f43e7a17618183982"
>
> Initialising tasks: 100%
> ||
> Time: 0:00:08
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: automake-native-1.15-r0 do_compile: oe_runmake failed
> ERROR: automake-native-1.15-r0 do_compile: Function failed: do_compile (log
> file is located at
> /home/bianchi77/poky/build/tmp/work/x86_64-linux/automake-native/1.15-r0/temp/log.do_compile.9291)
> ERROR: Logfile of failure stored in:
> /home/bianchi77/poky/build/tmp/work/x86_64-linux/automake-native/1.15-r0/temp/log.do_compile.9291
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | NOTE: Using icecc
> | NOTE: make -j 10
> | ERROR: oe_runmake failed
> | : && /home/bianchi77/poky/build/tmp/hosttools/mkdir -p doc && {
> PATH='/home/bianchi77/poky/build/tmp/work/x86_64-linux/automake-native/1.15-r0/build/t/wrap:'$PATH
> && export PATH; } && /usr/bin/env perl ../automake-1.15/doc/help2man
> --output=doc/automake-1.15.1 automake-1.15
> | help2man: can't get `--help' info from automake-1.15
>
> What OS do you run on build machine ?
> if its archlinux then apply this patch to automake
>
> https://gist.github.com/xywei/03b546054f0d2e2f76c5ac530c88268a
>
> otherwise if its centos7 then install
>
> yum install perl-Thread-Queue
>
>
>
> | Try `--no-discard-stderr' if option outputs to stderr
> | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
> | make: *** [doc/automake-1.15.1] Error 255
> | ERROR: Function failed: do_compile (log file is located at
> /home/bianchi77/poky/build/tmp/work/x86_64-linux/automake-native/1.15-r0/temp/log.do_compile.9291)
> ERROR: Task
> (virtual:native:/home/bianchi77/poky/meta/recipes-devtools/automake/automake_1.15.bb:do_compile)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 845 tasks of which 844 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> virtual:native:/home/bianchi77/poky/meta/recipes-devtools/automake/automake_1.15.bb:do_compile
> Summary: There were 4 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> bianchi77@bianchi77-HP-Pavilion-dv6-Notebook-PC:~/poky/build$
>
> How can I fix that automake error ?
>
> I tried to run bitbake core-image-minimal for it.
> Thanks,
>
> On 31/07/17 21:26, Burton, Ross wrote:
>
> Then the branch you checked out.  git branch will tell you.
>
> Ross
>
> On 31 July 2017 at 14:17, Riko Ho  wrote:
>
> Git clone ...
>
> On Jul 31, 2017 9:16 PM, "Burton, Ross"  wrote:
>
> How did you get poky?
>
> Ross
>
> On 31 July 2017 at 14:14, Riko Ho  wrote:
>
> How can I see my branch?
>
> On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:
>
> On 31 July 2017 at 03:33, Riko Ho  wrote:
>
> Is my auto make disabled with icecc ?
>
> How to make it enable ? thanks.
>
> That's just a debug message.
>
> | help2man: can't get `--help' info from automake-1.15
> | Try `--no-discard-stderr' if option outputs to stderr
> | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
>
> That's the error your hitting.
>
> I think you need to update to the latest commit for the branch you're
> on, there was a problem with modern perl in help2man.  What release/branch
> are you using?
>
> Ross
>
>
> --
>
> /***/
> Sent by Ubuntu LTS 16.04,
> Kind regards,
> Riko Ho
> /***/
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> --
>
> /***/
> Sent by Ubuntu LTS 16.04,
> Kind regards,
> Riko Ho
> /***/
>
>
> --
>
> /***/
> Sent by Ubuntu LTS 16.04,
> Kind regards,
> Riko Ho
> /***/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] DEBUG: automake-native: class native found in blacklist, disable icecc ?

[Riko Ho]

Still got the same error after installing it? Any other clues?
On Aug 2, 2017 9:53 PM, "Khem Raj"  wrote:

> On Tue, Aug 1, 2017 at 11:42 PM, Riko Ho  wrote:
> > Could it be this one ?
> >
> > https://www.devmanuals.net/install/ubuntu/ubuntu-12-04-
> lts-precise-pangolin/install-libthread-queue-perl.html
> >
>
> yes
>
> > Thanks
> >
> >
> > On 02/08/17 14:38, Khem Raj wrote:
> >
> > apply the solutions they may work for ubuntu
> >
> > On Tue, Aug 1, 2017 at 11:33 PM, Riko Ho 
> wrote:
> >
> > Dear Yocto Team Member,
> >
> > I'm building with Ubuntu 16
> >
> >
> > On 02/08/17 14:31, Khem Raj wrote:
> >
> > On Tue, Aug 1, 2017 at 11:18 PM, Riko Ho 
> wrote:
> >
> > Dear Yocto Team Member,
> >
> > That's the branch :
> >
> > ==
> >
> > meta-poky
> > meta-yocto-bsp= "pyro:e5aa1ac23669a45491de9ecffac491c01e70203f"
> > openembedded-core = "master:2fd0757ae7fd63bc93a4ce8579c6ba0cdbb4c1cd"
> > meta-openembedded
> > meta-oe
> > meta-xfce
> > meta-gnome
> > meta-python
> > meta-multimedia
> > meta-networking   = "master:b063789560bfb9c60a7a15277b5b3a9839b5ba74"
> > meta-browser  =
> > "firefox-52.1.2esr-2:c79cf6c7811afd2cd167e8967e3c29b1e797371e"
> > meta-ti   = "master:872d418f6e503dea66e3533f43e7a17618183982"
> >
> > Initialising tasks: 100%
> > |###
> #|
> > Time: 0:00:08
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > ERROR: automake-native-1.15-r0 do_compile: oe_runmake failed
> > ERROR: automake-native-1.15-r0 do_compile: Function failed: do_compile
> (log
> > file is located at
> > /home/bianchi77/poky/build/tmp/work/x86_64-linux/
> automake-native/1.15-r0/temp/log.do_compile.9291)
> > ERROR: Logfile of failure stored in:
> > /home/bianchi77/poky/build/tmp/work/x86_64-linux/
> automake-native/1.15-r0/temp/log.do_compile.9291
> > Log data follows:
> > | DEBUG: Executing shell function do_compile
> > | NOTE: Using icecc
> > | NOTE: make -j 10
> > | ERROR: oe_runmake failed
> > | : && /home/bianchi77/poky/build/tmp/hosttools/mkdir -p doc && {
> > PATH='/home/bianchi77/poky/build/tmp/work/x86_64-linux/
> automake-native/1.15-r0/build/t/wrap:'$PATH
> > && export PATH; } && /usr/bin/env perl ../automake-1.15/doc/help2man
> > --output=doc/automake-1.15.1 automake-1.15
> > | help2man: can't get `--help' info from automake-1.15
> >
> > What OS do you run on build machine ?
> > if its archlinux then apply this patch to automake
> >
> > https://gist.github.com/xywei/03b546054f0d2e2f76c5ac530c88268a
> >
> > otherwise if its centos7 then install
> >
> > yum install perl-Thread-Queue
> >
> >
> >
> > | Try `--no-discard-stderr' if option outputs to stderr
> > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
> > | make: *** [doc/automake-1.15.1] Error 255
> > | ERROR: Function failed: do_compile (log file is located at
> > /home/bianchi77/poky/build/tmp/work/x86_64-linux/
> automake-native/1.15-r0/temp/log.do_compile.9291)
> > ERROR: Task
> > (virtual:native:/home/bianchi77/poky/meta/recipes-
> devtools/automake/automake_1.15.bb:do_compile)
> > failed with exit code '1'
> > NOTE: Tasks Summary: Attempted 845 tasks of which 844 didn't need to be
> > rerun and 1 failed.
> >
> > Summary: 1 task failed:
> >
> > virtual:native:/home/bianchi77/poky/meta/recipes-
> devtools/automake/automake_1.15.bb:do_compile
> > Summary: There were 4 WARNING messages shown.
> > Summary: There were 2 ERROR messages shown, returning a non-zero exit
> code.
> > bianchi77@bianchi77-HP-Pavilion-dv6-Notebook-PC:~/poky/build$
> >
> > How can I fix that automake error ?
> >
> > I tried to run bitbake core-image-minimal for it.
> > Thanks,
> >
> > On 31/07/17 21:26, Burton, Ross wrote:
> >
> > Then the branch you checked out.  git branch will tell you.
> >
> > Ross
> >
> > On 31 July 2017 at 14:17, Riko Ho  wrote:
> >
> > Git clone ...
> >
> > On Jul 31, 2017 9:16 PM, "Burton, Ross"  wrote:
> >
> > How did you get poky?
> >
> > Ross
> >
> > On 31 July 2017 at 14:14, Riko Ho  wrote:
> >
> > How can I see my branch?
> >
> > On Jul 31, 2017 9:12 PM, "Burton, Ross"  wrote:
> >
> > On 31 July 2017 at 03:33, Riko Ho  wrote:
> >
> > Is my auto make disabled with icecc ?
> >
> > How to make it enable ? thanks.
> >
> > That's just a debug message.
> >
> > | help2man: can't get `--help' info from automake-1.15
> > | Try `--no-discard-stderr' if option outputs to stderr
> > | Makefile:3687: recipe for target 'doc/automake-1.15.1' failed
> >
> > That's the error your hitting.
> >
> > I think you need to update to the latest commit for the branch you're
> > on, there was a problem with modern perl in help2man.  What
> release/branch
> > are you using?
> >
> > Ross
> >
> >
> > --
> >
> > /***/
> > Sent by Ubuntu LTS 16.04,
> > Kind regards,
> > Riko Ho
> > /***/
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> 

Re: [yocto] local file update vs rebuild

[Takashi Matsuzawa]

Helli, thank you for your confirmation.

From: Burton, Ross 
Sent: Wednesday, August 2, 2017 8:47:00 PM
To: Takashi Matsuzawa
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] local file update vs rebuild

If you modify a recipe then anything that depends on it will be rebuilt.  So 
changing a file referenced in SRC_URI in a recipe will cause the image to 
rebuild if you build the image.

Ross

On 2 August 2017 at 12:03, Takashi Matsuzawa 
mailto:tmatsuz...@xevo.com>> wrote:

Hello.

Thank you for your comment.


I want to double check.


 = image name

 = recipe within 


Then, I am not sure if doing below will rebuild  from scratch.


$ bitbake  -c cleansstate

$ bitbake 


Especially, I am doing things like below within my .


SRC_URI += "file://src/*;subdir=local"


I want to be sure that, if I make modification to the local files (referred to 
as file://... path within SRC_URI variable of  recipe), the changes are 
reflected to the final image.

(Not explicitly specifying -c cleansstate to ).


From: Khem Raj mailto:raj.k...@gmail.com>>
Sent: Tuesday, August 1, 2017 3:42 AM
To: Takashi Matsuzawa; yocto@yoctoproject.org
Subject: Re: [yocto] local file update vs rebuild



On 7/31/17 4:39 AM, Takashi Matsuzawa wrote:
> Hello.
> I am uncertain about do_clean behavior with local files.
>
>
> Say, I have local files referred by my recipe, and I have made changes to the 
> files referred.
> (Note, there is no change in my .bb file itself.)
>
>
>> SRC_URI += "file://src/*;subdir=local"
>
>
> What makes those changed files reflected to the build?
> Do I need do_cleanall?  do_cleansstate or maybe do_clean is enough?
>
>
> According to the document
>
>
>> do_clean
>> do_unpack task forward (i.e. do_unpack, do_configure, do_compile, 
>> do_install, and do_package).
>> if no changes have been made and the recipe is rebuilt after cleaning, 
>> output files are simply restored from the sstate cache.
>
>
> I want to avoid doing do_cleanall often, and I would like to tell bitbake 
> that my recipe needs rebuild at the same time not rebuilding others.
> But at the same time I want to avoid building my single explicity.
> I just want to build the image name as target.

I think ccleansstate should be good.

>
>


--
___
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] extensible SDK build failure

[RUSSELL PETERSON]

Frustrating in that I can't get the eSDK to fully build. I'm past the issue
with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
below. Anyone seen this before? From what I can tell these tasks are being
executed out of the run queue.  Not all the messages are from cve-check but 
most.

Anyone seen this?



ERROR: Task attr-native.do_cve_check attempted to execute unexpectedly
ERROR: Task binutils-native.do_cve_check attempted to execute unexpectedly
ERROR: Task dbus-glib.do_cve_check attempted to execute unexpectedly
ERROR: Task libtool-native.do_cve_check attempted to execute unexpectedly
ERROR: Task fixesproto.do_cve_check attempted to execute unexpectedly
ERROR: Task bc.do_cve_check attempted to execute unexpectedly
ERROR: Task lsof.do_cve_check attempted to execute unexpectedly
ERROR: Task python-setuptools-native.do_cve_check attempted to execute
unexpectedly
ERROR: Task libxrandr-native.do_cve_check attempted to execute unexpectedly
ERROR: Task libpciaccess.do_cve_check attempted to execute unexpectedly
ERROR: Task xf86driproto.do_cve_check attempted to execute unexpectedly
ERROR: Task ncurses-native.do_cve_check attempted to execute unexpectedly

On August 1, 2017 at 8:55 PM Russell Peterson  wrote:

FYI: For those interested…

Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta layer
and directly set the acpaths variable to the STAGING native directory and that
seems to work fine. Works for now but I will try to come up with a cleaner,
more generic fix.

acpaths = “-I ${STAGING_DATADIR_NATIVE}/aclocal/“

Regards,

Russell

> 
> On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON  
> wrote:
> 
> Thank you for the response, Paul. You were correct that I had the
> TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my
> image bb file and things seem far more sane... although I must admit I am
> not 100% sure why it works but I will study it a bit and figure it out.
> Thanks for your help.
> 
> I have run into another issue while trying to generate the eSDK in that
> there appears to be an issue with building harfbuzz. From what I can tell,
> this appears to be an issue with the search paths for the autoreconf call.
> The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 
> directory
> FIRST and therefore not getting the one in
> harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has
> the correct m4_pattern_allow.
> 
> Do you think that's a bug or something with my recipe? Seems like I just
> want to reverse the -I options... but I don't know how, exactly.
> 
> 
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf
> 
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/
> 
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/
> --force
> 
> ../../../autoconf-2.69/lib/autoconf/specific.m4:368:
> AC_USE_SYSTEM_EXTENSIONS is expanded from...
> | configure.ac:22: the top level
> | configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
> | If this token and others are legitimate, please use m4_pattern_allow.
> | See the Autoconf documentation.
> | autoreconf:
> 
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/bin/autoconf
> failed with exit status: 1
> | ERROR: Function failed: do_configure (log file is located at
> 
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)
> 
> > > 
> > On July 31, 2017 at 9:50 AM Paul Eggleton 
> > 
> > wrote:
> > 
> > Hi Russell,
> > 
> > It looks to me like you have added kernel-devsrc to the 
> > TOOLCHAIN_*_TASK
> > variable at the global level, which you really don't want to do if 
> > you're
> > going to be building buildtools-tarball (which eSDK will build as a
> > dependency). I'd suggest moving that setting to your image recipe.
> > 
> > Cheers,
> > Paul
> > 
> > On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
> > 
> > > > > 
> > > Hello, all.
> > > 
> > > I’m trying to build the eSDK for my platform and I just can’t 
> > > figure out
> > > why dnf can’t find kernel-devsrc. It’s there, I added it. The 
> > > “normal
> > > SDK” uses it and builds fine. Just no luck with the eSDK.
> > > Any help out there? Poky is pyro. aarch64 SoC target platform 
> > > with an
> > > x86 build host (CentOS 7.3). Basically I just bitbake -c
> > > do_populate_sdk_ext core-image-full. I do have a linux kernel 
> > > recipe
> > > that pulls the kernel from the standard kerne

Re: [yocto] How to strip down my Yocto Linux?

[Khem Raj]

On Wed, Aug 2, 2017 at 3:35 AM Burton, Ross  wrote:

> First, the core images are examples; copy and paste the closest to what
> you want and then modify the recipe.
>
> If you want a really small image then start from core-image-minimal, but
> be aware that is missing a lot of stuff you may actually want.
>

And use poky-tiny for distro reference to build up your own

>
> How to remove things depends on how they got installed in the first
> place.  Unless you have doc-pkgs in IMAGE_FEATURES then you shouldn't have
> any man pages or documentation.  If the poco recipe installs sample code
> you don't want then fix the recipe to put those in another package. etc etc.
>
> Ross
>
> On 2 August 2017 at 10:47, Bacheh Karaji  wrote:
>
>> I would like to strip down my Yocto Linux before put in it to flash.
>> Unneeded software, man pages, POCO sample codes and other documentation
>> just waste resource, especially on the i.MX28 EVK with only 128MB flash.
>>
>> My local.conf file looks following:
>>
>>
>>
>>
>>
>> *$ gedit conf/local.conf & ... IMAGE_INSTALL_append = " poco nginx
>> canutils vsftpd curl fcgi spawn-fcgi net-snmp util-linux ubiattach-klibc
>> ubimkvol-klibc ubiformat-klibc minicom net-tools zeroconf avahi-autoipd
>> mtd-utils u-boot-fw-utils ethtool" ... I bitbake the image
>> "core-image-base"*.
>>
>> I was wondering, is there a way that I can delete all of the Unneeded
>> files?
>>
>> Can somebody help me howto strip down my Yocto Linux?
>>
>> --
>> ___
>> 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] QA cycle report for 2.4 M2 rc2

[Cruz, Libertad]

Hello All,



Here is the report for the 2.4 M2 rc2 full point release test cycle.

Full Report : 
https://wiki.yoctoproject.org/wiki/WW31_-_2017-07-31_-_Full_Test_Cycle_2.4_M2_rc2



=== Summary 

The QA cycle for release 2.4 M2 rc2 is complete.


Performance
Measurements were mostly the same levels as of 2.4 M1 rc1, there was a little 
improvement of 5% on rootfs build time for Fedora machine.


UbuntuTest   2.4 M1 rc12.4 M2 rc2 %
 sato 1:12:11  1:13:58  2.47
 rootfs  2:242:31   4.86
 rmwork  1:08:27  1:07:22 -1.58
 kernel 5:265:393.99
 eSDK   2:302:300.00


FedoraTest  2.4 M1 rc1 2.4 M2 rc2 %
   sato 1:13:49   1:13:52 0.07
   rootfs  2:38 2:29  -5.70
   rmwork  1:08:22   1:08:42 0.49
   kernel 6:10 6:04  -1.62
   eSDK   2:36 2:34  -1.28





ptest

There was an improvement of the pass rate for gdk-pixbuf of 5% , an improvement 
of 1.30% on glib-2.0, an improvement of 2.9% on openssh, an improvement of 
15.2% on util-linux. There was a regression on the pass rate for libxml2 of 
4.20% .



Compliance

For posix test there is no mayor change in the number of failures on 2.4m2 rc2 
and 2.4 m1 rc1.



Failures2.4 M2 RC2  2.4 M1 RC1

  Generic86-64   46  45

  Beaglebone  45  45

  Edgerouter   46  46

  Mpc8315e-rdb45  45



Results are found here: https://wiki.yoctoproject.org/wiki/Posix_result

Detail analysis found here:  https://wiki.yoctoproject.org/wiki/POSIX-results



For LTP testing we had 2 additional failures in comparison to 2.4 M1 rc1



Genericx86-64   
 mpc8315e-rdb

2.4 M2 rc2Total1384 
 1348

 Failures24 
  30



Genericx86-64   
 mpc8315e-rdb

2.4 M1 rc1Total1384 
 1348

 Failures22 
  30





The LPT results are found: https://wiki.yoctoproject.org/wiki/LTP_result .





=== QA-Hints



QA does not approve that  the workarounds provided  for 2.4 m2 rc2  were on 
different commits. Testing was not limited to 2.4 m2 rc2 commit 
"8e15e9b6e478f6368034519b2a8fd3c7ea71d23b" it was performed by following each 
commit on the provided workarounds described below.



  --11850[1] was opened to track the fact that Eclipse plugins were not 
publish under 2.4 m2 rc2 so, the plugins were taken from previous build 2.4 m2 
rc1. These files need to be copied in to 2.4m2 rc2 if and before release is 
approved.

  --11834[10] describes that if you add a bad layer to bblayers bitbake 
server will hang in connecting and  although is resolved & verified this bug 
was linked to this release candidate because the commit is not integrated to 
2.4 m2 rc2. By linking this issue in the test report users can then find the 
correct commit that will fix it.

  --11857[9] was opened to track that there are some problems creating wic 
images on CentOS is also resolved & verified, but it is still linked to 2.4 m2 
rc2 because the commit is not integrated to this release candidate. Users can 
then find the correct commit that will fix it.

  --11855[4]  this bug reports the fact that libgcc-initial can't build on 
fedora i686, but again when trying with latest master commit it passes. Users 
can then know which commit to work on.

  --11889[11] Toaster does not build on 2.4 m2 rc2 but when changing to 
latest master commit it works fine.





This testing cycle report does not reflects the results  exclusively of 2.4 m2 
rc2 but of all the other commits that were applied so that eclipse, toaster, 
bitbake and  ADT on Fedora i686 would not be blocked. We recommend a 2.4 m2 rc3 
where all the commits are integrated.



On the wiki a  new section was created for Compliance results. For LTP testing 
there is currently an issue with the hardware infrastructure of Wind River 
hence  beaglebone and  edgerouter have not been tested.



=== Bugs 



   New Bugs
-11850[1]  [Autobuilder] Eclipse-plugin files are not found in 
autobuilder
-11873[