Re: [OE-core] [oe] OpenEmbedded Happy Hour
See you all from down under ! Cheers Ankur On Sun, May 17, 2020, 2:27 AM Marco Cavallini [KOAN] < m.cavall...@koansoftware.com> wrote: > On 15/05/20 17:56, Philip Balister wrote: > > I've made a wiki page to track these: > > > > https://www.openembedded.org/wiki/Happy_Hours > > > > Then next one is scheduled for 2100 UTC on May 27. This is late evening > > for Europe and morning for New Zealand, so hopefully we see some > > different faces. The meeting info is on the wiki page. > > > > There is no set agenda, so bring some projects to talk about with the > > community. > > > > > > Philip > > > > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+May+27&iso=20200527T21&p1=%3A&ah=1 > > -- > Marco > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#138371): https://lists.openembedded.org/g/openembedded-core/message/138371 Mute This Topic: https://lists.openembedded.org/mt/74261148/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Including vendor's pre-built binary in image
Thank you Denys, INSANE_SKIP "file-rdeps" solved the issue
cheers
On Wed, Apr 8, 2020 at 7:12 PM Denys Dmytriyenko wrote:
> On Wed, Apr 08, 2020 at 01:52:47PM +1200, Ankur Tyagi wrote:
> > Hi,
> >
> > I am sure this is not being discussed for first time and I tried
> > all suggested solution in previous emails but none worked hence I am
> asking
> > again.
> >
> > Trying to include a pre-built binary from vendor in my image but getting
> > following QA error:
> >
> > ERROR: my-recipe-1.0-r0 do_package_qa: QA Issue: /etc/vendor/tool
> contained
> > in package my-recipe requires libstdc++.so.6(CXXABI_1.3), but no
> providers
> > found in RDEPENDS_my-recipe ? [file-rdeps]
> > ERROR: my-recipe -1.0-r0 do_package_qa: QA Issue: /etc/vendor/tool
> > contained in package my-recipe requires libstdc++.so.6(GLIBCXX_3.4), but
> no
> > providers found in RDEPENDS_my-recipe ? [file-rdeps]
> > ERROR: my-recipe -1.0-r0 do_package_qa: QA run found fatal errors. Please
> > consider fixing them.
> > ERROR: my-recipe -1.0-r0 do_package_qa: Function failed: do_package_qa
> >
> > I have tried following in my-recipe_1.0.bb but error still persists
> > RDEPENDS_${PN} += "libstdc++6"
> >
> > How can I fix this?
>
> https://lists.yoctoproject.org/g/poky/message/11900
>
>
> > thanks
> > Ankur
>
> >
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137122):
https://lists.openembedded.org/g/openembedded-core/message/137122
Mute This Topic: https://lists.openembedded.org/mt/72865821/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Including vendor's pre-built binary in image
Hi,
Ideally yes but vendor won't be able to do so.
I am looking for a fix at my end.
thanks
Ankur
On Wed, Apr 8, 2020 at 6:42 PM wrote:
> Hi,
>
> On Wed, Apr 08, 2020 at 01:52:47PM +1200, Ankur Tyagi wrote:
> > Hi,
> >
> > I am sure this is not being discussed for first time and I tried
> > all suggested solution in previous emails but none worked hence I am
> asking
> > again.
> >
> > Trying to include a pre-built binary from vendor in my image but getting
> > following QA error:
> >
> > ERROR: my-recipe-1.0-r0 do_package_qa: QA Issue: /etc/vendor/tool
> contained
> > in package my-recipe requires libstdc++.so.6(CXXABI_1.3), but no
> providers
> > found in RDEPENDS_my-recipe ? [file-rdeps]
> > ERROR: my-recipe -1.0-r0 do_package_qa: QA Issue: /etc/vendor/tool
> > contained in package my-recipe requires libstdc++.so.6(GLIBCXX_3.4), but
> no
> > providers found in RDEPENDS_my-recipe ? [file-rdeps]
> > ERROR: my-recipe -1.0-r0 do_package_qa: QA run found fatal errors. Please
> > consider fixing them.
> > ERROR: my-recipe -1.0-r0 do_package_qa: Function failed: do_package_qa
> >
> > I have tried following in my-recipe_1.0.bb but error still persists
> > RDEPENDS_${PN} += "libstdc++6"
>
> This shared library comes from gcc-runtime recipe and libstdc++ binary
> package
> (before name manglings). buildhistory helps with cases like this.
>
> I would write recipes for all binaries and make sure all QA checks are
> passing
> with them. Best way is to get vendors to compile with your SDK.
>
> Cheers,
>
> -Mikko
>
> >
> > How can I fix this?
> >
> > thanks
> > Ankur
>
> >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137121):
https://lists.openembedded.org/g/openembedded-core/message/137121
Mute This Topic: https://lists.openembedded.org/mt/72865821/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Including vendor's pre-built binary in image
Hi,
I am sure this is not being discussed for first time and I tried
all suggested solution in previous emails but none worked hence I am asking
again.
Trying to include a pre-built binary from vendor in my image but getting
following QA error:
ERROR: my-recipe-1.0-r0 do_package_qa: QA Issue: /etc/vendor/tool contained
in package my-recipe requires libstdc++.so.6(CXXABI_1.3), but no providers
found in RDEPENDS_my-recipe ? [file-rdeps]
ERROR: my-recipe -1.0-r0 do_package_qa: QA Issue: /etc/vendor/tool
contained in package my-recipe requires libstdc++.so.6(GLIBCXX_3.4), but no
providers found in RDEPENDS_my-recipe ? [file-rdeps]
ERROR: my-recipe -1.0-r0 do_package_qa: QA run found fatal errors. Please
consider fixing them.
ERROR: my-recipe -1.0-r0 do_package_qa: Function failed: do_package_qa
I have tried following in my-recipe_1.0.bb but error still persists
RDEPENDS_${PN} += "libstdc++6"
How can I fix this?
thanks
Ankur
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#137110):
https://lists.openembedded.org/g/openembedded-core/message/137110
Mute This Topic: https://lists.openembedded.org/mt/72865821/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] recipe design curiosity: how to best install a package configuration file?
new recipe version (most likely) will have new release and expect any change
If you are concerned about recipe version in your layer then manage that
rather than copying original recipe file *as it is* in your layer
When upgrading recipe, anyway have to test it to make sure your image
doesn't break. So no way you will miss any breaking change introduced. And
at that point you could have (if needed) your custom version in "file/"
rather than always copying the working sample which is already maintained
by someone else
I wouldn't recommend to have copy of unchanged upstream files in a custom
layer
Cheers
Ankur
On Sat, Mar 21, 2020, 12:32 AM Robert P. J. Day
wrote:
> On Sat, 21 Mar 2020, Ankur Tyagi wrote:
>
> > what if sample file is updated in new version? Now you have to
> > maintain the copy in your "file/" as well.
> >
> > If you are using sample file as it is, then keeping a copy is
> > probably not a good idea
> >
> > Cheers
> > Ankur
>
> i actually think that's an argument in my favour ... i would be very
> nervous about how upgrading a recipe version would quietly upgrade my
> configuration file. i would far prefer to have to manually upgrade my
> configuration to keep in step.
>
> rday
>
> > got into a discussion yesterday about the "cleanest" way to
> design a
> > .bbappend file to install a package's configuration file, so i'm
> > curious about best practices, and here's an example. (and i'm
> asking
> > as it looks like this will be an issue for a number of recipes i'm
> > looking at.)
> >
> > current recipe for conntrack-tools:
> >
> >
> http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb
> >
> > note how the recipe install step installs a conntrack.conf.sample
> > file:
> >
> > do_install_append() {
> > install -d ${D}/${sysconfdir}/conntrackd
> > install -d ${D}/${sysconfdir}/init.d
> > install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf
> ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample
> > ...
> >
> > so far, so good. now, in cases where a sample conf file is
> provided,
> > there is, of course, no guarantee that it will be applicable out of
> > the box -- one *expects* that it might be necessary to tweak such a
> > file and install it as part of a .bbappend file. and here's the
> point
> > of contention.
> >
> > in this current situation, it turns out that that sample conf
> file
> > just happens to be appropriate, so the entire .bbappend file for
> this
> > recipe consists of:
> >
> > do_install_append () {
> > install -m 0644 \
> > ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \
> > ${D}/${sysconfdir}/conntrackd/conntrackd.conf
> > }
> >
> > yes, that will work, but i suggested that, even though it's
> > convenient, the problem with that approach is that looking at the
> > .bbappend file doesn't show you the contents of the file that will
> be
> > installed. to see the actual conf file, you'd have to peruse the
> > source, or check the final result ... you get the idea.
> >
> > i suggested that, even though the sample file in *this* case was
> > perfectly appropriate, i would choose to make a copy of it under
> > files/, and install the conf file from *there*, the advantage being
> > that the actual file being installed is immediately readable.
> >
> > does anyone have any strong opinions on this? it seems mundane,
> but
> > i think the latter approach is still superior, especially since i
> > suspect most sample configuration files would have to be adjusted,
> > anyway.
> >
> > thoughts? just trying to collect some best practices to apply to
> > this project.
> >
> > rday
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> >
> >
>
> --
>
>
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter: http://twitter.com/rpjday
> LinkedIn: http://ca.linkedin.com/in/rpjday
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] recipe design curiosity: how to best install a package configuration file?
what if sample file is updated in new version? Now you have to maintain the
copy in your "file/" as well.
If you are using sample file as it is, then keeping a copy is probably not
a good idea
Cheers
Ankur
On Sat, Mar 21, 2020, 12:04 AM Robert P. J. Day
wrote:
>
> got into a discussion yesterday about the "cleanest" way to design a
> .bbappend file to install a package's configuration file, so i'm
> curious about best practices, and here's an example. (and i'm asking
> as it looks like this will be an issue for a number of recipes i'm
> looking at.)
>
> current recipe for conntrack-tools:
>
>
> http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/conntrack-tools/conntrack-tools_1.4.5.bb
>
> note how the recipe install step installs a conntrack.conf.sample
> file:
>
> do_install_append() {
> install -d ${D}/${sysconfdir}/conntrackd
> install -d ${D}/${sysconfdir}/init.d
> install -m 0644 ${S}/doc/sync/ftfw/conntrackd.conf
> ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample
> ...
>
> so far, so good. now, in cases where a sample conf file is provided,
> there is, of course, no guarantee that it will be applicable out of
> the box -- one *expects* that it might be necessary to tweak such a
> file and install it as part of a .bbappend file. and here's the point
> of contention.
>
> in this current situation, it turns out that that sample conf file
> just happens to be appropriate, so the entire .bbappend file for this
> recipe consists of:
>
> do_install_append () {
> install -m 0644 \
> ${D}/${sysconfdir}/conntrackd/conntrackd.conf.sample \
> ${D}/${sysconfdir}/conntrackd/conntrackd.conf
> }
>
> yes, that will work, but i suggested that, even though it's
> convenient, the problem with that approach is that looking at the
> .bbappend file doesn't show you the contents of the file that will be
> installed. to see the actual conf file, you'd have to peruse the
> source, or check the final result ... you get the idea.
>
> i suggested that, even though the sample file in *this* case was
> perfectly appropriate, i would choose to make a copy of it under
> files/, and install the conf file from *there*, the advantage being
> that the actual file being installed is immediately readable.
>
> does anyone have any strong opinions on this? it seems mundane, but
> i think the latter approach is still superior, especially since i
> suspect most sample configuration files would have to be adjusted,
> anyway.
>
> thoughts? just trying to collect some best practices to apply to
> this project.
>
> rday
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Very large size of libraries in core-image-minimal rootfs
Hi Khem, I have no experience with musl but keen to understand does musl improves/impacts DRAM performance as compared to glibc? regards Ankur On Wed, 27 Nov 2019, 7:17 a.m. Khem Raj, wrote: > On Mon, 2019-11-25 at 23:10 +0200, Adrian Bunk wrote: > > On Mon, Nov 25, 2019 at 07:26:58PM +, Ross Burton wrote: > > > On 25/11/2019 18:37, Ankur Tyagi wrote: > > > > Hi, > > > > > > > > Based upon "thud" branch, I created core-image-minimal for > > > > am335x-evm > > > > board and resulting image size is very big(71M) > > > > > > If disk size is important then a good first step is to use musl > > > instead of > > > glibc: > > > > > > TCLIBC = "musl" > > > ... > > > > musl is mainly useful for tiny systems, a 40 MB partition is such a > > huge > > amount of space that the size of the C library no longer matters > > much. > > > > The size benefit of replacing glibc with musl is around 2 MB. > > I would refrain from labeling as useful for tiny systems. since > static size is one thing, there is DRAM behaviour which is equally > important, how malloc and other resource oriented algorithms behave is > important as well. > > secondly, if I have 40MB partition, one might rather want to use extra > space for implementing features in their product than spend it for > enabling the system if they can. > > there are many other design considerations where musl might make more > sense > > > > > A partition with an -Os build of Yocto with glibc+systemd (sic) > > is around 9 MB, together with bootloader and kernel this all > > fits in a 16 MB flash. Use compression for kernel and root > > filesystem and everything fits in a 8 MB flash. > > > > -Os is not as well tested option as -O2 is. So we should always > recommend it with grain of salt, speaking from experience there are > bugs that will show up with Os which you wont see with O2 and leave a > bad taste for user > > > > Ross > > > > cu > > Adrian > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Very large size of libraries in core-image-minimal rootfs
Hi Adrian, Thanks for explaining things and helping me out. Once I have stable builds then will try your suggestion as well. Ankur On Mon, Nov 25, 2019 at 1:10 PM Adrian Bunk wrote: > On Mon, Nov 25, 2019 at 07:26:58PM +, Ross Burton wrote: > > On 25/11/2019 18:37, Ankur Tyagi wrote: > > > Hi, > > > > > > Based upon "thud" branch, I created core-image-minimal for am335x-evm > > > board and resulting image size is very big(71M) > > > > If disk size is important then a good first step is to use musl instead > of > > glibc: > > > > TCLIBC = "musl" > >... > > musl is mainly useful for tiny systems, a 40 MB partition is such a huge > amount of space that the size of the C library no longer matters much. > > The size benefit of replacing glibc with musl is around 2 MB. > > A partition with an -Os build of Yocto with glibc+systemd (sic) > is around 9 MB, together with bootloader and kernel this all > fits in a 16 MB flash. Use compression for kernel and root > filesystem and everything fits in a 8 MB flash. > > > Ross > > cu > Adrian > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Very large size of libraries in core-image-minimal rootfs
Hi Ross, I just used arago distro as it is but you are right, once I have stable builds with default configuration then I will try your suggestion. Thanks for your help Ankur On Mon, Nov 25, 2019 at 12:58 PM Ross Burton wrote: > On 25/11/2019 20:22, Ankur Tyagi wrote: > > # Select external binary prebuilt Arm toolchain > > TCMODE = "external-arm" > > TCLIBC = "external-arm-toolchain" > > FWIW, I don't see what the value in external toolchains actually is. > You might get better results by simply setting: > > TCMODE = "default" > TCLIB = "glibc" > > (or TCLIBC="musl" if you want to save even more space) > > Ross > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Very large size of libraries in core-image-minimal rootfs
Hi Adrian, Seems you are correct. My distro is based upon TI's Arago distro which uses following # Select external binary prebuilt Arm toolchain TCMODE = "external-arm" TCLIBC = "external-arm-toolchain" And external-arm-toolchain.bb recipe has following require recipes-core/glibc/glibc-package.inc INHIBIT_DEFAULT_DEPS = "1" INHIBIT_PACKAGE_STRIP = "1" INHIBIT_PACKAGE_DEBUG_SPLIT = "1" And glibc-package.inc has following INHIBIT_SYSROOT_STRIP = "1" I just rebuild by disabling INHIBIT_PACKAGE_STRIP = "1" in external-arm-toolchain.bb and it reduced image size to 12M $ ls -al lib/ -rwxr-xr-x 1 ankur ankur 138436 Nov 26 09:08 ld-2.28.so lrwxrwxrwx 1 ankur ankur 10 Nov 26 09:08 ld-linux-armhf.so.3 -> ld-2.28.so -rwxr-xr-x 1 ankur ankur 1246708 Nov 26 09:08 libc.so.6 -rwxr-xr-x 1 ankur ankur9600 Nov 26 09:08 libdl.so.2 -rw-r--r-- 1 ankur ankur 132 Nov 26 09:07 libgcc_s.so -rw-r--r-- 1 ankur ankur 124396 Nov 26 09:07 libgcc_s.so.1 -rwxr-xr-x 1 ankur ankur 451932 Nov 26 09:08 libm.so.6 -rwxr-xr-x 1 ankur ankur 67292 Nov 26 09:08 libnsl.so.1 -rwxr-xr-x 1 ankur ankur 26244 Nov 26 09:08 libnss_compat.so.2 -rwxr-xr-x 1 ankur ankur 17812 Nov 26 09:08 libnss_dns.so.2 -rwxr-xr-x 1 ankur ankur 38368 Nov 26 09:08 libnss_files.so.2 -rwxr-xr-x 1 ankur ankur 13708 Nov 26 09:08 libnss_hesiod.so.2 -rwxr-xr-x 1 ankur ankur 92356 Nov 26 09:08 libpthread.so.0 $ ls -al usr/lib total 2816 drwxr-xr-x 3 ankur ankur4096 Nov 26 09:18 . drwxr-xr-x 10 ankur ankur4096 Nov 26 09:18 .. lrwxrwxrwx 1 ankur ankur 15 Nov 26 09:12 libi2c.so.0 -> libi2c.so.0.1.1 -rwxr-xr-x 1 ankur ankur5292 Nov 26 09:12 libi2c.so.0.1.1 lrwxrwxrwx 1 ankur ankur 16 Nov 26 09:11 libkmod.so.2 -> libkmod.so.2.3.3 -rwxr-xr-x 1 ankur ankur 46840 Nov 26 09:11 libkmod.so.2.3.3 -rwxr-xr-x 1 ankur ankur 1404888 Nov 26 09:08 libstdc++.so.6 -rwxr-xr-x 1 ankur ankur 1404888 Nov 26 09:08 libstdc++.so.6.0.25 -rw-r--r-- 1 ankur ankur2388 Nov 26 09:08 libstdc++.so.6.0.25-gdb.py Thank you so much for help. Regards Ankur On Tue, Nov 26, 2019 at 8:55 AM Adrian Bunk wrote: > On Tue, Nov 26, 2019 at 07:37:48AM +1300, Ankur Tyagi wrote: > > Hi, > > > > Based upon "thud" branch, I created core-image-minimal for am335x-evm > board > > and resulting image size is very big (71M) > > > > /lib dir is 39M and /usr/lib is 24M. > >... > > -rwxr-xr-x 1 ankur ankur *16537400* Nov 26 06:41 libc.so.6 > >... > > -rwxr-xr-x 1 ankur ankur *6416640* Nov 26 06:41 libm.so.6 > >... > > These sizes are the expected sizes for the libraries with debug symbols. > > Are you setting INHIBIT_PACKAGE_DEBUG_SPLIT or something similar that > prevents stripping of the target filesystem? > > > Thanks > > Ankur > > cu > Adrian > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Very large size of libraries in core-image-minimal rootfs
That could be it. How can I make sure debug stripping is enabled? thanks Ankur On Tue, Nov 26, 2019 at 8:49 AM Ross Burton wrote: > On 25/11/2019 19:33, Ankur Tyagi wrote: > > Thanks for the suggestion. > > But curious why libs are so big now? > > The same files on my system: > > -rwxr-xr-x root/root 1806504 2019-11-04 21:14 ./lib64/libc-2.30.so > -rwxr-xr-x root/root113296 2019-11-04 21:14 ./lib64/libpthread-2.30.so > -rw-r--r-- root/root100248 2019-11-04 21:14 ./lib64/libgcc_s.so.1 > > Your files are a lot larger, so I suspect that you've somehow turned off > debug stripping. > > Ross > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Very large size of libraries in core-image-minimal rootfs
Hi Ross, Thanks for the suggestion. But curious why libs are so big now? Regards Ankur On Tue, Nov 26, 2019 at 8:27 AM Ross Burton wrote: > On 25/11/2019 18:37, Ankur Tyagi wrote: > > Hi, > > > > Based upon "thud" branch, I created core-image-minimal for am335x-evm > > board and resulting image size is very big(71M) > > If disk size is important then a good first step is to use musl instead > of glibc: > > TCLIBC = "musl" > > The C++ runtime is also giant, so see if you can not use C++? > > Ross > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Very large size of libraries in core-image-minimal rootfs
Hi, Based upon "thud" branch, I created core-image-minimal for am335x-evm board and resulting image size is very big (71M) /lib dir is 39M and /usr/lib is 24M. How can the libraries be trimmed down to fit image inside 40M partition? I can see duplicacy in /usr/lib and symlink should help but that would reduce 12M. I need to reduce further 20M. When I was using "daisy" branch, resulting image was much tiny but world has changed since then. Any help is much appreciated as I am now blocked and looking for some help. $ ls -al lib/ total 38712 drwxr-xr-x 4 ankur ankur 4096 Nov 26 07:13 . drwxr-xr-x 17 ankur ankur 4096 Nov 26 07:13 .. -rwxr-xr-x 1 ankur ankur 1347940 Nov 26 06:41 ld-2.28.so lrwxrwxrwx 1 ankur ankur 10 Nov 26 06:41 ld-linux-armhf.so.3 -> ld-2.28.so -rwxr-xr-x 1 ankur ankur 133528 Nov 26 06:41 libanl.so.1 lrwxrwxrwx 1 ankur ankur 16 Nov 26 06:41 libattr.so.1 -> libattr.so.1.1.0 -rw-r--r-- 1 ankur ankur13736 Nov 26 06:41 libattr.so.1.1.0 lrwxrwxrwx 1 ankur ankur 17 Nov 26 06:44 libblkid.so.1 -> libblkid.so.1.1.0 -rwxr-xr-x 1 ankur ankur 195404 Nov 26 06:44 libblkid.so.1.1.0 -rwxr-xr-x 1 ankur ankur25392 Nov 26 06:41 libBrokenLocale.so.1 -rwxr-xr-x 1 ankur ankur 153372 Nov 26 06:41 libcrypt.so.1 -rwxr-xr-x 1 ankur ankur *16537400* Nov 26 06:41 libc.so.6 -rwxr-xr-x 1 ankur ankur 225508 Nov 26 06:41 libdl.so.2 -rw-r--r-- 1 ankur ankur 132 Nov 26 06:40 libgcc_s.so -rw-r--r-- 1 ankur ankur *9063520* Nov 26 06:40 libgcc_s.so.1 -rwxr-xr-x 1 ankur ankur *6416640* Nov 26 06:41 libm.so.6 -rwxr-xr-x 1 ankur ankur 722176 Nov 26 06:41 libnsl.so.1 -rwxr-xr-x 1 ankur ankur 178932 Nov 26 06:41 libnss_compat.so.2 -rwxr-xr-x 1 ankur ankur 122236 Nov 26 06:41 libnss_dns.so.2 -rwxr-xr-x 1 ankur ankur 373084 Nov 26 06:41 libnss_files.so.2 -rwxr-xr-x 1 ankur ankur 115836 Nov 26 06:41 libnss_hesiod.so.2 lrwxrwxrwx 1 ankur ankur 17 Nov 26 06:44 libpamc.so.0 -> libpamc.so.0.82.1 -rwxr-xr-x 1 ankur ankur 9592 Nov 26 06:44 libpamc.so.0.82.1 lrwxrwxrwx 1 ankur ankur 21 Nov 26 06:44 libpam_misc.so.0 -> libpam_misc.so.0.82.1 -rwxr-xr-x 1 ankur ankur 9628 Nov 26 06:44 libpam_misc.so.0.82.1 lrwxrwxrwx 1 ankur ankur 16 Nov 26 06:44 libpam.so.0 -> libpam.so.0.84.2 -rwxr-xr-x 1 ankur ankur34396 Nov 26 06:44 libpam.so.0.84.2 -rwxr-xr-x 1 ankur ankur *2742208* Nov 26 06:41 libpthread.so.0 -rwxr-xr-x 1 ankur ankur 436644 Nov 26 06:41 libresolv.so.2 -rwxr-xr-x 1 ankur ankur 424948 Nov 26 06:41 librt.so.1 lrwxrwxrwx 1 ankur ankur 12 Nov 26 06:45 libudev.so.0 -> libudev.so.1 lrwxrwxrwx 1 ankur ankur 16 Nov 26 06:45 libudev.so.1 -> libudev.so.1.6.3 -rwxr-xr-x 1 ankur ankur88176 Nov 26 06:45 libudev.so.1.6.3 lrwxrwxrwx 1 ankur ankur 19 Nov 26 07:13 libusb-1.0.so.0 -> libusb-1.0.so.0.1.0 -rwxr-xr-x 1 ankur ankur67292 Nov 26 07:13 libusb-1.0.so.0.1.0 -rwxr-xr-x 1 ankur ankur40320 Nov 26 06:41 libutil.so.1 lrwxrwxrwx 1 ankur ankur 16 Nov 26 06:44 libuuid.so.1 -> libuuid.so.1.3.0 -rwxr-xr-x 1 ankur ankur22108 Nov 26 06:44 libuuid.so.1.3.0 lrwxrwxrwx 1 ankur ankur 14 Nov 26 06:40 libz.so.1 -> libz.so.1.2.11 -rwxr-xr-x 1 ankur ankur63012 Nov 26 06:40 libz.so.1.2.11 drwxr-xr-x 2 ankur ankur 4096 Nov 26 07:13 security drwxr-xr-x 3 ankur ankur 4096 Nov 26 06:45 udev $ ls -al usr/lib/ total 23376 drwxr-xr-x 3 ankur ankur 4096 Nov 26 07:13 . drwxr-xr-x 10 ankur ankur 4096 Nov 26 07:13 .. lrwxrwxrwx 1 ankur ankur 15 Nov 26 07:12 libi2c.so.0 -> libi2c.so.0.1.1 -rwxr-xr-x 1 ankur ankur 5292 Nov 26 07:12 libi2c.so.0.1.1 lrwxrwxrwx 1 ankur ankur 16 Nov 26 06:44 libkmod.so.2 -> libkmod.so.2.3.3 -rwxr-xr-x 1 ankur ankur46840 Nov 26 06:44 libkmod.so.2.3.3 -rwxr-xr-x 1 ankur ankur *11930116* Nov 26 06:43 libstdc++.so.6 -rwxr-xr-x 1 ankur ankur *11930116* Nov 26 06:43 libstdc++.so.6.0.25 -rw-r--r-- 1 ankur ankur 2388 Nov 26 06:43 libstdc++.so.6.0.25-gdb.py drwxr-xr-x 3 ankur ankur 4096 Nov 26 07:13 opkg $ du -h 4.0K./sys 4.0K./boot 4.0K./dev 5.5M./sbin 612K./bin 4.0K./usr/share/dict 4.0K./usr/share/man 4.0K./usr/share/misc 4.0K./usr/share/info 20K./usr/share 208K./usr/libexec 824K./usr/sbin 520K./usr/bin 4.0K./usr/include 4.0K./usr/src 4.0K./usr/games 1.1M./usr/lib/opkg/alternatives 1.1M./usr/lib/opkg *24M./usr/lib26M./usr* 4.0K./var/local 4.0K./var/spool/mail 8.0K./var/spool 4.0K./var/backups 4.0K./var/lib/opkg 4.0K./var/lib/misc 4.0K./var/lib/urandom 16K./var/lib 4.0K./var/volatile 4.0K./var/cache/opkg 8.0K./var/cache/ldconfig 16K./var/cache 56K./var 4.0K./mnt/.psplash 8.0K./mnt 4.0K./proc 4.0K./etc/network/if-up.d 4.0K./etc/network/if-down.d 4.0K./etc/network/if-post-down.d 8.0K./etc/network/if-pre-up.d 28K./etc/network 92K./etc/pam.d 4.0K./etc/rc
Re: [OE-core] How to set up custom layer correctly
Hi Andrey, On Thu, Nov 14, 2019 at 8:54 PM Andrey Zhizhikin wrote: > > Hey Ankur, > > On Wed, Nov 13, 2019 at 9:55 PM Ankur Tyagi wrote: > > > > Hi, > > > > I have a custom layer for custom board based upon am335x-evm and custom > > images. > > > > I have a master layer called "my-custom-layer" which has three sub-layers > > - my-custom-distro : custom distro based upon TI's 'arago' distro, Qt > > and other s/w recipe appends > > - my-custom-image : custom images, packagegroups, toolchain recipes > > - my-custom-machine : custom machine conf, bsp and kernel recipes > > Those config files are OK to create, but can you please tell how did > you create your own machine? My custom machine is based upon am335x-evm custom_machine.conf require conf/machine/am335x-evm.conf UBOOT_MACHINE = "custom_machine_config" SERIAL_CONSOLES = "115200;ttyS0" MKUBIFS_ARGS = "-F -m 4096 -e 253952 -c 800" UBINIZE_ARGS = "-m 4096 -p 256KiB -s 1024 -O 4096" > > > > When I am building my image, it throws numerous warnings like below > > for almost all packages in the image: > > > > eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: libudev rdepends on > > u-boot-custom-src, but it isn't a build dependency, missing > > u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > > WARNING: eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: eudev > > rdepends on u-boot-custom-src, but it isn't a build dependency, > > missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > > WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput rdepends > > on u-boot-custom-src, but it isn't a build dependency, missing > > u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > > WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput-bin > > rdepends on u-boot-custom-src, but it isn't a build dependency, > > missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] > > > > I would be interesting to see your u-boot-custom recipe here. Looks > like this one is not formed well enough. Did you base it from u-boot > recipe of am335x layer? Correct, it is based upon u-boot-ti-staging from meta-ti layer > > Another thing is if you're building your own version of U-Boot - you > would need to set a PREFERRED_PROVIDER to point to it. This > Yes, I have set it up in my distro conf > > > > And once sstate-cache is built and if I try to reuse it after bumping > > u-boot-custom to new SRCREV then I get errors like: > > > > Collected errors: > > * Solver encountered 2 problem(s): > > * Problem 1/2: > > * - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606 > > needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl > > * > > * Solution 1: > > * - do not ask to install a package providing packagegroup-ggl-base > > > > * Problem 2/2: > > * - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606 > > needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl > > * > > * Solution 1: > > * - do not ask to install a package providing packagegroup-ggl-qt > > > Those might come from the point I stated above - your u-boot recipe > does not provide necessary packages, or the PREFERRED_PROVIDER might > not be set correctly. > > > Something is definitely not right the way I am have setup my layers > > but I would like to understand what is wrong, why it is wrong and what > > is the recommended way to do it > > I can tell you how I personally do it. This is a mere experience that > I have and it does not serve as an official How-To - there is a very > good documentation about the process of using Yocto on the website. :) > I base my new configuration on the oe-core/vendor BSP, utilizing as > much as possible from it at the first step. Then once the evaluation > image is built (for example core-image-minimal) I examine the > distro/machine to identify whether I can use it as-is, or create my > distro/machine based on those provided. In later case I try to keep it > as close to original source as possible, this would allow ease of > upgrade in the future. > > As a suggested reading here: > https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html > Thank you for the insights, it was helpful as I have also been trying to follow the same path > > Because in future I would like to add different machines, distros and > > images for different custom products. That is why instead of putting > > everything inside one layer I thought of keeping a separate layer fo
[OE-core] How to set up custom layer correctly
Hi, I have a custom layer for custom board based upon am335x-evm and custom images. I have a master layer called "my-custom-layer" which has three sub-layers - my-custom-distro : custom distro based upon TI's 'arago' distro, Qt and other s/w recipe appends - my-custom-image : custom images, packagegroups, toolchain recipes - my-custom-machine : custom machine conf, bsp and kernel recipes When I am building my image, it throws numerous warnings like below for almost all packages in the image: eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: libudev rdepends on u-boot-custom-src, but it isn't a build dependency, missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] WARNING: eudev-3.2.7-r0.3.arago5 do_package_qa: QA Issue: eudev rdepends on u-boot-custom-src, but it isn't a build dependency, missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput rdepends on u-boot-custom-src, but it isn't a build dependency, missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] WARNING: libinput-1.11.3-r0 do_package_qa: QA Issue: libinput-bin rdepends on u-boot-custom-src, but it isn't a build dependency, missing u-boot-custom in DEPENDS or PACKAGECONFIG? [build-deps] And once sstate-cache is built and if I try to reuse it after bumping u-boot-custom to new SRCREV then I get errors like: Collected errors: * Solver encountered 2 problem(s): * Problem 1/2: * - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606 needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl * * Solution 1: * - do not ask to install a package providing packagegroup-ggl-base * Problem 2/2: * - nothing provides u-boot-custom-src >= 2019.01+git0+b31ea1d606 needed by linux-custom-src-4.19.73+git0+d02acfec3d-gamos.wsl * * Solution 1: * - do not ask to install a package providing packagegroup-ggl-qt Something is definitely not right the way I am have setup my layers but I would like to understand what is wrong, why it is wrong and what is the recommended way to do it Because in future I would like to add different machines, distros and images for different custom products. That is why instead of putting everything inside one layer I thought of keeping a separate layer for each. Looking forward to learning from your responses. Thanks Ankur -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RDEPENDS libstdc++ error
And this tool is provided to us as a pre-compiled binary. On Thu, 11 Jul 2019, 7:54 p.m. Ankur Tyagi, wrote: > Hi, > > I have a third party tool which I was packaging in my image based upon > Yocto 1.6 > > Now I am upgrading to Yocto 2.7 and the recipe which packages third > party tool is generating following error: > > requires libstdc++.so.6(CXXABI_1.3), but no providers found in > RDEPENDS_test-util? [file-rdeps] > requires libstdc++.so.6(GLIBCXX_3.4), but no providers found in > RDEPENDS_test-util? [file-rdeps] > > Is there a way to fix this without asking vendor to provide a new > version of tool? > > Thanks > Ankur > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] RDEPENDS libstdc++ error
Hi, I have a third party tool which I was packaging in my image based upon Yocto 1.6 Now I am upgrading to Yocto 2.7 and the recipe which packages third party tool is generating following error: requires libstdc++.so.6(CXXABI_1.3), but no providers found in RDEPENDS_test-util? [file-rdeps] requires libstdc++.so.6(GLIBCXX_3.4), but no providers found in RDEPENDS_test-util? [file-rdeps] Is there a way to fix this without asking vendor to provide a new version of tool? Thanks Ankur -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
Hi Chris, I tried uploading sstate-cache again in Artifactory but this time used jfrog-cli (https://www.jfrog.com/confluence/display/CLI/CLI+for+JFrog+Artifactory) instead of curl and now it is working fine. regards Ankur On Wed, Jul 10, 2019 at 1:39 PM Ankur Tyagi wrote: > > On Wed, Jul 10, 2019 at 2:28 AM chris.lapla...@agilent.com > wrote: > > > > > DEBUG: For url file://5c/sstate:u-boot-ti-staging:wsl-linux- > > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > > returning > > > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti- > > > staging%3Awsl-linux- > > > gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz; > > > downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux- > > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus: trying again > > > DEBUG: checkstatus() urlopen failed: HTTP Error 404: Not Found > > > > Is this mapping correct? Does using curl to download > > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-staging%3Awsl-linux-gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz;downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > work? > > > > Yes, curl/wget can download it. What wrong do you suspect here? > > Thanks > Ankur > > > Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
On Wed, Jul 10, 2019 at 2:28 AM chris.lapla...@agilent.com wrote: > > > DEBUG: For url file://5c/sstate:u-boot-ti-staging:wsl-linux- > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > returning > > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti- > > staging%3Awsl-linux- > > gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz; > > downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux- > > gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus: trying again > > DEBUG: checkstatus() urlopen failed: HTTP Error 404: Not Found > > Is this mapping correct? Does using curl to download > https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-staging%3Awsl-linux-gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz;downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz > work? > Yes, curl/wget can download it. What wrong do you suspect here? Thanks Ankur > Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
Hi Chris,
1) I am able to fetch sstate using curl, wget
2) Looking in bitbake -DDD output, url is correct as I can use that
url to download it using curl, wget
DEBUG: SState: Attempting to fetch
file://5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
DEBUG: Searching for
5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
in paths:
/home/nws/wsl/arago/downstream/ggl-oe-layersetup/build/sstate-cache
DEBUG: Defaulting to
/home/nws/wsl/arago/downstream/ggl-oe-layersetup/build/sstate-cache/5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
for
5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
DEBUG: Testing URL
file://5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
DEBUG: For url ['file', '',
'5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz',
'', '', OrderedDict()] comparing ['file', '', '.*', '', '',
OrderedDict()] to ['https', 'artifactory.local.gallagher.io',
'/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/PATH', '', '',
OrderedDict([('downloadfilename', 'PATH')])]
DEBUG: For url
file://5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
returning
https://artifactory.local.gallagher.io/artifactory/rnd-yocto-packages/sstate-cache/wsl-thud/5c/sstate%3Au-boot-ti-staging%3Awsl-linux-gnueabi%3A2019.01%2BgitAUTOINC%2B06e0b5babe%3Ar17%3Awsl%3A3%3A5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz;downloadfilename=5c/sstate:u-boot-ti-staging:wsl-linux-gnueabi:2019.01+gitAUTOINC+06e0b5babe:r17:wsl:3:5cdf9380b9b3f8c94a706344cf19554a_packagedata.tgz
DEBUG: checkstatus: trying again
DEBUG: checkstatus: trying again
DEBUG: checkstatus: trying again
DEBUG: checkstatus: trying again
DEBUG: checkstatus() urlopen failed: HTTP Error 404: Not Found
Regards
Ankur
On Tue, Jul 9, 2019 at 9:16 AM Ankur Tyagi wrote:
>
> Hi Chris,
>
> Thanks for your pointers, I will try them.
>
> Regarding using curl for sstate fetch, how to set SSTATE_MIRRORS ?
> Below is my current configuration
>
> SSTATE_MIRRORS ?= "\
> file://.*
> https://artifactory.com/yocto/sstate-cache/PATH;downloadfilename=PATH
> \
> "
> Thanks
> Ankur
>
> On Tue, Jul 9, 2019 at 3:37 AM chris.lapla...@agilent.com
> wrote:
> >
> > > I can't see any "log.do_setscene" inside the tmp directory.
> > > When I start an image build, it does say executing setscene task but
> > > then no setscene task log for any recipe
> > >
> > > Initialising tasks: 100%
> > > |##
> > > ##|
> > > Time: 0:00:01
> > > Checking sstate mirror object availability: 100%
> > > |##
> > > ##|
> > > Time: 0:00:02
> > > Sstate summary: Wanted 484 Found 0 Missed 968 Current 0 (0% match, 0%
> > > complete)
> > > NOTE: Executing SetScene Tasks
> > > NOTE: Executing RunQueue Tasks
> >
> > We have Artifactory serving our sstate as well, so here's some tips.
> >
> > 1. Try seeing if you can fetch some sstate using curl directly. If you are
> > authenticating to the Artifactory server using a .netrc server, make sure
> > to pass "--netrc" to curl.
> > 2. You can diagnose the sstate mirror by passing -DDD to bitbake. It will
> > spit out a ton of debug messages, so you might want to redirect it all to a
> > file. E.g.:
> >
> > bitbake something -DDD >out.txt 2>&1
> >
> > Start looking after the line that begins "DEBUG: SState using premirror
> > of". It will dump out the URLs that it tries to fetch.
> >
> > 3. Within Artifactory, you can check the access log by going to: Admin >
> > System Logs > access.log
> >
> > Look for "DENIED LOGIN" errors.
> >
> > Chris
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
Hi Chris, Thanks for your pointers, I will try them. Regarding using curl for sstate fetch, how to set SSTATE_MIRRORS ? Below is my current configuration SSTATE_MIRRORS ?= "\ file://.* https://artifactory.com/yocto/sstate-cache/PATH;downloadfilename=PATH \ " Thanks Ankur On Tue, Jul 9, 2019 at 3:37 AM chris.lapla...@agilent.com wrote: > > > I can't see any "log.do_setscene" inside the tmp directory. > > When I start an image build, it does say executing setscene task but > > then no setscene task log for any recipe > > > > Initialising tasks: 100% > > |## > > ##| > > Time: 0:00:01 > > Checking sstate mirror object availability: 100% > > |## > > ##| > > Time: 0:00:02 > > Sstate summary: Wanted 484 Found 0 Missed 968 Current 0 (0% match, 0% > > complete) > > NOTE: Executing SetScene Tasks > > NOTE: Executing RunQueue Tasks > > We have Artifactory serving our sstate as well, so here's some tips. > > 1. Try seeing if you can fetch some sstate using curl directly. If you are > authenticating to the Artifactory server using a .netrc server, make sure to > pass "--netrc" to curl. > 2. You can diagnose the sstate mirror by passing -DDD to bitbake. It will > spit out a ton of debug messages, so you might want to redirect it all to a > file. E.g.: > > bitbake something -DDD >out.txt 2>&1 > > Start looking after the line that begins "DEBUG: SState using premirror of". > It will dump out the URLs that it tries to fetch. > > 3. Within Artifactory, you can check the access log by going to: Admin > > System Logs > access.log > > Look for "DENIED LOGIN" errors. > > Chris -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Problems with sstate-cache in Artifactory
Hi Ross, I can't see any "log.do_setscene" inside the tmp directory. When I start an image build, it does say executing setscene task but then no setscene task log for any recipe Initialising tasks: 100% || Time: 0:00:01 Checking sstate mirror object availability: 100% || Time: 0:00:02 Sstate summary: Wanted 484 Found 0 Missed 968 Current 0 (0% match, 0% complete) NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks Regards Ankur On Thu, Jul 4, 2019 at 12:04 AM Burton, Ross wrote: > > Check the log for the a particular setscene task and it will show what > requests it made, and if they failed. > > Ross > > On Wed, 3 Jul 2019 at 11:09, Ankur Tyagi wrote: > > > > Hi, > > > > I am trying to setup sstate-cache in Artifactory so that multiple > > Linux host systems can share it. > > > > Once build finished in one Linux machine, I uploaded all of > > sstate-cache directory to Artifactory > > > > Then I configured sstate mirrors in local.conf > > SSTATE_MIRRORS ?= "\ > > file://.* > > https://artifactory.com/yocto/sstate-cache/PATH;downloadfilename=PATH > > \ > > " > > But when the build started, it didn't used anything from the sstate > > mirror and ended up building everything > > > > Am I missing something? > > > > Thanks > > Ankur > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Problems with sstate-cache in Artifactory
Hi, I am trying to setup sstate-cache in Artifactory so that multiple Linux host systems can share it. Once build finished in one Linux machine, I uploaded all of sstate-cache directory to Artifactory Then I configured sstate mirrors in local.conf SSTATE_MIRRORS ?= "\ file://.* https://artifactory.com/yocto/sstate-cache/PATH;downloadfilename=PATH \ " But when the build started, it didn't used anything from the sstate mirror and ended up building everything Am I missing something? Thanks Ankur -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 2/2] base-files: respect PERSISTENT_LOG_DIR
On Thu, Aug 30, 2018 at 8:38 PM Khem Raj wrote:
>
> On Thu, Aug 30, 2018 at 1:34 AM Ankur Tyagi wrote:
> >
> > Hi Khem,
> >
> > Is this patch being accepted ?
> >
>
> I am not convinced if we need this patch as we can do this using volatile
> binds.
> or base-files changes if needed.
>
How volatile binds will help with VOLATILE_LOG_DIR set as "no" ?
This patch is modifying base-files so that users can simply set a
variable in conf file instead of modifying base-files.
> > regards
> > Ankur
> >
> > On Tue, Aug 28, 2018 at 7:45 AM Ankur Tyagi wrote:
> > >
> > > On Sat, Aug 25, 2018 at 12:17 PM Khem Raj wrote:
> > > >
> > > > On Fri, Aug 17, 2018 at 6:00 PM Ankur Tyagi
> > > > wrote:
> > > > >
> > > > > Respect PERSISTENT_LOG_DIR variable. In this way, if the user
> > > > > overrides
> > > > > this variable to be e.g "/home/root/log", /var/log on the final image
> > > > > would
> > > > > be a link pointing to /home/root/log on persistent storage.
> > > > >
> > > >
> > > > I would suggest to stick with VOLATILE_BINDS
> > >
> > > But this won't help with VOLATILE_LOG_DIR set as "no".
> > > I think it is a common requirement to have persistent logging mounted
> > > in a separate partition.
> > > This patch makes it easy (hopefully) for the user to achieve the above
> > > without any additional recipe.
> > >
> > > >
> > > > > Signed-off-by: Ankur Tyagi
> > > > > ---
> > > > > meta/recipes-core/base-files/base-files_3.0.14.bb | 6 +-
> > > > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > > > b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > > > index 1c0863b..597fdaa 100644
> > > > > --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > > > +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > > > @@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir}
> > > > > ${base_sbindir} ${base_libdir} \
> > > > > ${localstatedir}/backups ${localstatedir}/lib \
> > > > > /sys ${localstatedir}/lib/misc ${localstatedir}/spool \
> > > > > ${localstatedir}/volatile \
> > > > > - ${localstatedir}/${@'volatile/' if
> > > > > oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
> > > > > + ${@'${localstatedir}/volatile/log' if
> > > > > oe.types.boolean('${VOLATILE_LOG_DIR}') else '${PERSISTENT_LOG_DIR}'
> > > > > if d.getVar('PERSISTENT_LOG_DIR') else '${localstatedir}/log' } \
> > > > > /home ${prefix}/src ${localstatedir}/local \
> > > > > /media"
> > > > >
> > > > > @@ -106,6 +106,10 @@ do_install () {
> > > > > ln -sf volatile/$d ${D}${localstatedir}/$d
> > > > > done
> > > > >
> > > > > + if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = False -a
> > > > > ! -z ${PERSISTENT_LOG_DIR} ]; then
> > > > > + ln -sf ${PERSISTENT_LOG_DIR} ${D}/${localstatedir}/log
> > > > > + fi
> > > > > +
> > > > > ln -snf ../run ${D}${localstatedir}/run
> > > > > ln -snf ../run/lock ${D}${localstatedir}/lock
> > > > >
> > > > > --
> > > > > 2.7.4
> > > > >
> > > > > --
> > > > > ___
> > > > > Openembedded-core mailing list
> > > > > Openembedded-core@lists.openembedded.org
> > > > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 2/2] base-files: respect PERSISTENT_LOG_DIR
Hi Khem,
Is this patch being accepted ?
regards
Ankur
On Tue, Aug 28, 2018 at 7:45 AM Ankur Tyagi wrote:
>
> On Sat, Aug 25, 2018 at 12:17 PM Khem Raj wrote:
> >
> > On Fri, Aug 17, 2018 at 6:00 PM Ankur Tyagi wrote:
> > >
> > > Respect PERSISTENT_LOG_DIR variable. In this way, if the user overrides
> > > this variable to be e.g "/home/root/log", /var/log on the final image
> > > would
> > > be a link pointing to /home/root/log on persistent storage.
> > >
> >
> > I would suggest to stick with VOLATILE_BINDS
>
> But this won't help with VOLATILE_LOG_DIR set as "no".
> I think it is a common requirement to have persistent logging mounted
> in a separate partition.
> This patch makes it easy (hopefully) for the user to achieve the above
> without any additional recipe.
>
> >
> > > Signed-off-by: Ankur Tyagi
> > > ---
> > > meta/recipes-core/base-files/base-files_3.0.14.bb | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > index 1c0863b..597fdaa 100644
> > > --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > > @@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir}
> > > ${base_libdir} \
> > > ${localstatedir}/backups ${localstatedir}/lib \
> > > /sys ${localstatedir}/lib/misc ${localstatedir}/spool \
> > > ${localstatedir}/volatile \
> > > - ${localstatedir}/${@'volatile/' if
> > > oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
> > > + ${@'${localstatedir}/volatile/log' if
> > > oe.types.boolean('${VOLATILE_LOG_DIR}') else '${PERSISTENT_LOG_DIR}' if
> > > d.getVar('PERSISTENT_LOG_DIR') else '${localstatedir}/log' } \
> > > /home ${prefix}/src ${localstatedir}/local \
> > > /media"
> > >
> > > @@ -106,6 +106,10 @@ do_install () {
> > > ln -sf volatile/$d ${D}${localstatedir}/$d
> > > done
> > >
> > > + if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = False -a !
> > > -z ${PERSISTENT_LOG_DIR} ]; then
> > > + ln -sf ${PERSISTENT_LOG_DIR} ${D}/${localstatedir}/log
> > > + fi
> > > +
> > > ln -snf ../run ${D}${localstatedir}/run
> > > ln -snf ../run/lock ${D}${localstatedir}/lock
> > >
> > > --
> > > 2.7.4
> > >
> > > --
> > > ___
> > > Openembedded-core mailing list
> > > Openembedded-core@lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 2/2] base-files: respect PERSISTENT_LOG_DIR
On Sat, Aug 25, 2018 at 12:17 PM Khem Raj wrote:
>
> On Fri, Aug 17, 2018 at 6:00 PM Ankur Tyagi wrote:
> >
> > Respect PERSISTENT_LOG_DIR variable. In this way, if the user overrides
> > this variable to be e.g "/home/root/log", /var/log on the final image would
> > be a link pointing to /home/root/log on persistent storage.
> >
>
> I would suggest to stick with VOLATILE_BINDS
But this won't help with VOLATILE_LOG_DIR set as "no".
I think it is a common requirement to have persistent logging mounted
in a separate partition.
This patch makes it easy (hopefully) for the user to achieve the above
without any additional recipe.
>
> > Signed-off-by: Ankur Tyagi
> > ---
> > meta/recipes-core/base-files/base-files_3.0.14.bb | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > index 1c0863b..597fdaa 100644
> > --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> > +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> > @@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir}
> > ${base_libdir} \
> > ${localstatedir}/backups ${localstatedir}/lib \
> > /sys ${localstatedir}/lib/misc ${localstatedir}/spool \
> > ${localstatedir}/volatile \
> > - ${localstatedir}/${@'volatile/' if
> > oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
> > + ${@'${localstatedir}/volatile/log' if
> > oe.types.boolean('${VOLATILE_LOG_DIR}') else '${PERSISTENT_LOG_DIR}' if
> > d.getVar('PERSISTENT_LOG_DIR') else '${localstatedir}/log' } \
> > /home ${prefix}/src ${localstatedir}/local \
> > /media"
> >
> > @@ -106,6 +106,10 @@ do_install () {
> > ln -sf volatile/$d ${D}${localstatedir}/$d
> > done
> >
> > + if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = False -a ! -z
> > ${PERSISTENT_LOG_DIR} ]; then
> > + ln -sf ${PERSISTENT_LOG_DIR} ${D}/${localstatedir}/log
> > + fi
> > +
> > ln -snf ../run ${D}${localstatedir}/run
> > ln -snf ../run/lock ${D}${localstatedir}/lock
> >
> > --
> > 2.7.4
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable
Ping
Regards
Ankur
On Sat 18 Aug, 2018, 12:59 PM Ankur Tyagi, wrote:
> This variable is only respected when VOLATILE_LOG_DIR is "no".
>
> The default value is "" which results in the /var/log being log directory.
>
> The user could override this value to a path e.g "/home/root/log" which
> results /var/log being a link pointing to /home/root/log directory on
> persistent storage.
>
> Signed-off-by: Ankur Tyagi
> ---
> meta/conf/bitbake.conf | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index e5dc1ac..9db22c8 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
> # If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links
> to /var/volatile/log.
> # If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is on
> persistent storage.
> VOLATILE_LOG_DIR ?= "yes"
> +# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log
> links to PERSISTENT_LOG_DIR
> +PERSISTENT_LOG_DIR ??= ""
>
> ##
> # Architecture-dependent build variables.
> --
> 2.7.4
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 2/2] base-files: respect PERSISTENT_LOG_DIR
Ping
Regards
Ankur
On Sat 18 Aug, 2018, 12:59 PM Ankur Tyagi, wrote:
> Respect PERSISTENT_LOG_DIR variable. In this way, if the user overrides
> this variable to be e.g "/home/root/log", /var/log on the final image would
> be a link pointing to /home/root/log on persistent storage.
>
> Signed-off-by: Ankur Tyagi
> ---
> meta/recipes-core/base-files/base-files_3.0.14.bb | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
> b/meta/recipes-core/base-files/base-files_3.0.14.bb
> index 1c0863b..597fdaa 100644
> --- a/meta/recipes-core/base-files/base-files_3.0.14.bb
> +++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
> @@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir}
> ${base_libdir} \
> ${localstatedir}/backups ${localstatedir}/lib \
> /sys ${localstatedir}/lib/misc ${localstatedir}/spool \
> ${localstatedir}/volatile \
> - ${localstatedir}/${@'volatile/' if
> oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
> + ${@'${localstatedir}/volatile/log' if
> oe.types.boolean('${VOLATILE_LOG_DIR}') else '${PERSISTENT_LOG_DIR}' if
> d.getVar('PERSISTENT_LOG_DIR') else '${localstatedir}/log' } \
> /home ${prefix}/src ${localstatedir}/local \
> /media"
>
> @@ -106,6 +106,10 @@ do_install () {
> ln -sf volatile/$d ${D}${localstatedir}/$d
> done
>
> + if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = False -a ! -z
> ${PERSISTENT_LOG_DIR} ]; then
> + ln -sf ${PERSISTENT_LOG_DIR} ${D}/${localstatedir}/log
> + fi
> +
> ln -snf ../run ${D}${localstatedir}/run
> ln -snf ../run/lock ${D}${localstatedir}/lock
>
> --
> 2.7.4
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable
Ping
Regards
Ankur
On Mon 20 Aug, 2018, 9:12 PM Ankur Tyagi, wrote:
> Initially I thought of doing that but then dropped it because it would
> create a dependency on syslog configuration file.
> If in future syslog configuration parameter (LOGFILE) gets renamed, then
> we need to make corresponding change as well.
>
> I think creating /var/log as a link is a less dependent change.
>
> Let me know your thoughts.
>
> Regards
> Ankur
>
> On Mon, Aug 20, 2018 at 1:49 PM ChenQi wrote:
>
>> The requirement is to put logs into directories other than /var/log.
>> Could it be achieved by modifying the syslog daemon configuration file
>> (e.g. /etc/syslog.conf) to replace /var/log with the specified
>> directory. Maybe the corresponding logrotate configuration file also
>> needs to be modified.
>>
>> Best Regards,
>> Chen Qi
>>
>> On 08/18/2018 08:59 AM, Ankur Tyagi wrote:
>> > This variable is only respected when VOLATILE_LOG_DIR is "no".
>> >
>> > The default value is "" which results in the /var/log being log
>> directory.
>> >
>> > The user could override this value to a path e.g "/home/root/log" which
>> > results /var/log being a link pointing to /home/root/log directory on
>> > persistent storage.
>> >
>> > Signed-off-by: Ankur Tyagi
>> > ---
>> > meta/conf/bitbake.conf | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
>> > index e5dc1ac..9db22c8 100644
>> > --- a/meta/conf/bitbake.conf
>> > +++ b/meta/conf/bitbake.conf
>> > @@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
>> > # If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log
>> links to /var/volatile/log.
>> > # If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is
>> on persistent storage.
>> > VOLATILE_LOG_DIR ?= "yes"
>> > +# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log
>> links to PERSISTENT_LOG_DIR
>> > +PERSISTENT_LOG_DIR ??= ""
>> >
>> > ##
>> > # Architecture-dependent build variables.
>>
>>
>>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable
Initially I thought of doing that but then dropped it because it would
create a dependency on syslog configuration file.
If in future syslog configuration parameter (LOGFILE) gets renamed, then we
need to make corresponding change as well.
I think creating /var/log as a link is a less dependent change.
Let me know your thoughts.
Regards
Ankur
On Mon, Aug 20, 2018 at 1:49 PM ChenQi wrote:
> The requirement is to put logs into directories other than /var/log.
> Could it be achieved by modifying the syslog daemon configuration file
> (e.g. /etc/syslog.conf) to replace /var/log with the specified
> directory. Maybe the corresponding logrotate configuration file also
> needs to be modified.
>
> Best Regards,
> Chen Qi
>
> On 08/18/2018 08:59 AM, Ankur Tyagi wrote:
> > This variable is only respected when VOLATILE_LOG_DIR is "no".
> >
> > The default value is "" which results in the /var/log being log
> directory.
> >
> > The user could override this value to a path e.g "/home/root/log" which
> > results /var/log being a link pointing to /home/root/log directory on
> > persistent storage.
> >
> > Signed-off-by: Ankur Tyagi
> > ---
> > meta/conf/bitbake.conf | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index e5dc1ac..9db22c8 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
> > # If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log
> links to /var/volatile/log.
> > # If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is
> on persistent storage.
> > VOLATILE_LOG_DIR ?= "yes"
> > +# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log
> links to PERSISTENT_LOG_DIR
> > +PERSISTENT_LOG_DIR ??= ""
> >
> > ##
> > # Architecture-dependent build variables.
>
>
>
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][rocko][sumo][master][PATCH 2/2] base-files: respect PERSISTENT_LOG_DIR
Respect PERSISTENT_LOG_DIR variable. In this way, if the user overrides
this variable to be e.g "/home/root/log", /var/log on the final image would
be a link pointing to /home/root/log on persistent storage.
Signed-off-by: Ankur Tyagi
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 1c0863b..597fdaa 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -42,7 +42,7 @@ dirs755 = "/boot /dev ${base_bindir} ${base_sbindir}
${base_libdir} \
${localstatedir}/backups ${localstatedir}/lib \
/sys ${localstatedir}/lib/misc ${localstatedir}/spool \
${localstatedir}/volatile \
- ${localstatedir}/${@'volatile/' if
oe.types.boolean('${VOLATILE_LOG_DIR}') else ''}log \
+ ${@'${localstatedir}/volatile/log' if
oe.types.boolean('${VOLATILE_LOG_DIR}') else '${PERSISTENT_LOG_DIR}' if
d.getVar('PERSISTENT_LOG_DIR') else '${localstatedir}/log' } \
/home ${prefix}/src ${localstatedir}/local \
/media"
@@ -106,6 +106,10 @@ do_install () {
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+ if [ ${@ oe.types.boolean('${VOLATILE_LOG_DIR}') } = False -a ! -z
${PERSISTENT_LOG_DIR} ]; then
+ ln -sf ${PERSISTENT_LOG_DIR} ${D}/${localstatedir}/log
+ fi
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [oe-core][rocko][sumo][master][PATCH 1/2] bitbake.conf: add PERSISTENT_LOG_DIR variable
This variable is only respected when VOLATILE_LOG_DIR is "no".
The default value is "" which results in the /var/log being log directory.
The user could override this value to a path e.g "/home/root/log" which
results /var/log being a link pointing to /home/root/log directory on
persistent storage.
Signed-off-by: Ankur Tyagi
---
meta/conf/bitbake.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index e5dc1ac..9db22c8 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -88,6 +88,8 @@ ROOT_HOME ??= "/home/root"
# If set to boolean true ('yes', 'y', 'true', 't', '1'), /var/log links to
/var/volatile/log.
# If set to boolean false ('no', 'n', 'false', 'f', '0'), /var/log is on
persistent storage.
VOLATILE_LOG_DIR ?= "yes"
+# If VOLATILE_LOG_DIR is false and PERSISTENT_LOG_DIR is set, /var/log links
to PERSISTENT_LOG_DIR
+PERSISTENT_LOG_DIR ??= ""
##
# Architecture-dependent build variables.
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] How to upgrade Qt modules in daisy branch
Thank you Andreas, Martin and Alex for your responses. I will follow your leads and hopefully will be able to do it. Regards Ankur On Fri 10 Aug, 2018, 4:16 AM Andreas Müller, wrote: > On Thu, Aug 9, 2018 at 2:40 PM, Martin Jansa > wrote: > > For daisy you probably don't have support for PACKAGECONFIG_CONFARGS > which > > was added in Yocto 2.1 krogoth. > > > I remember doing similar for other reasons. We have images based on > jethro (ok - daisy is a bit older) with later Qt's. Our builds are > based on [1] but I created branches up to Qt5.9 (stable release - but > not updated to latest) [2] for jethro. > > It's not daisy - not Qt5.11 - no guarantees - but maybe a start. > > [1] https://github.com/schnitzeltony/meta-qt5/tree/jethro+5.7 > [2] https://github.com/schnitzeltony/meta-qt5/tree/jethro+5.9 > > Andreas > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] How to upgrade Qt modules in daisy branch
Hi, Our product is based upon 'daisy' branch (I know it's pretty old !) and now we have a need to support BLE in it (typical business case). My inner-self says it's the right time to upgrade everything but from business unit point of view, best would be to upgrade "just enough" to get BLE working. So I upgraded Bluez4.101 to Bluez5.46 which went well but when I started upgrading QtConnectivity from v5.4.1 to v5.11.0 then things started falling apart. It seems from v5.8 onward, Qt adopted new configuration system which is causing configuration and compilation failures when building QtConnectivity. Following change in recipe doesn't work. -PACKAGECONFIG[bluez] = "CONFIG+=OE_BLUEZ_ENABLED,,bluez4" +PACKAGECONFIG[bluez] = "-feature-bluez,-no-feature-bluez,bluez5" Is there a way I can upgrade QtConnectivity to v5.11 while staying on daisy branch ? Or is it just not possible to do so ? Any help is appreciated. Thanks Ankur -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] [yocto] OEDAM, April 8 in San Diego after ELC
Hi, Is there any information/material posted online for people who weren't able to attend because of geographical barriers ? regards Ankur On Tue, Apr 12, 2016 at 1:48 PM, Tom King wrote: > do we have meeting minutes posted someplace? > > thanks > > tom > > On Mon, Apr 11, 2016 at 6:43 PM, Philip Balister > wrote: > > > On 04/11/2016 09:35 PM, Denys Dmytriyenko wrote: > > > On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote: > > >> Hello Everyone: > > >> > > >> If you attended OEDAM last Friday in San Diego, I very much hope that > > you enjoyed being here. > > >> > > >> The Catamaran Hotel, where we held the meeting, would very much > > appreciate your feedback: > > >> > > >> www.catamaranresort.com/trip > > >> > > >> I hope you all had a safe trip back home, > > > > > > And huge thanks to Rudi and Jefro for their help in organizing the > event! > > > > > > > And an even bigger thanks to everyone that came to the meeting. You are > > the people that make OpenEmbedded great! > > > > Philip > > -- > > ___ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.openembedded.org/mailman/listinfo/openembedded-core > > > -- > ___ > Openembedded-devel mailing list > openembedded-de...@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-devel > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
