Re: [yocto] is there a rationale for YP using sysvinit as default init manager?

[Alexander Kanavin]

On Thu, 21 Nov 2019 at 22:18, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> We got so far and after looking at the position we ended up I decided
> it was easier to switch poky-altcfg rather than change poky and/or OE
> defaults. I resolved that bug as "complete" as we now had testing of
> systemd on a near enough equal footing to sysvinit which was the
> concern people had raised. There are problems in oe-selftest and some
> other corner cases but nothing people seem to be running into day-to-
> day.
>

It is also quite amazing that the project, by design, has entirely
sidestepped the divisive init system wars that have been gripping the
mainstream linux distros for years (and still are). I'd say it hardly
matters what the default is, if the other options are well supported.

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

Re: [yocto] Public cloud provider for Yocto builds

[Alexander Kanavin]

I would have the following requirements for any provider you choose:

1. Having kvm enabled (for the purpose of running qemu tests in the cloud
with good performance)
2. NFS server as a service from the cloud provider (so you don't have to
set it up and maintain it yourself)
3. Ability to share directories to the public over http (for the purpose of
providing sstate cache to developers' local machines).

Alex

On Tue, 12 Nov 2019 at 00:55, John McGehee 
wrote:

> ​I am looking at building on a public cloud provider like AWS, Google or
> Azure. Is there any cloud provider that is better than the others for Yocto
> build and CI?
>
>
> Is there anything else that I should use to get the most our of
> cloud-based builds?
>
> *** MEDIATEK Confidentiality Notice ***
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or
> otherwise exempt from disclosure under applicable laws. It is
> intended to be conveyed only to the designated recipient(s). Any
> use, dissemination, distribution, printing, retaining or copying
> of this e-mail (including its attachments) by unintended recipient(s)
> is strictly prohibited and may be unlawful. If you are not an
> intended recipient of this e-mail, or believe that you have received
> this e-mail in error, please notify the sender immediately
> (by replying to this e-mail), delete any and all copies of this
> e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] [auto-upgrade-helper] Add SPDX identifier to auto-upgrade-helper

[Alexander Kanavin]

Thanks, patch applied and pushed.

Alex

On Mon, 21 Oct 2019 at 14:46, Yann CARDAILLAC 
wrote:

> Hi guys,
>
> I'm working on bug :
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13531
>
> I've add GPLV2-or-later to all the sources, is there any modification you
> want to add?
>
> Best regards,
>
> Yann CARDAILLAC
> --
> [image: SMILE] 
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Yann CARDAILLAC*
> Ingénieur Systèmes Embarqués
>
> [image: email] yann.cardail...@smile.fr
> [image: url] http://www.smile.eu
>
> [image: Twitter]  [image: Facebook]
>  [image: LinkedIn]
>  [image: Github]
> 
>
>
> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][PATCH 2/2] apparmor: make bash dependency optional

[Alexander Kanavin]

Bash is only needed by one not particularly important script,
so not requiring bash is a useful option for builds that
cannot have gpl3 components.

Signed-off-by: Alexander Kanavin 
---
 recipes-mac/AppArmor/apparmor_2.13.3.bb | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.3.bb 
b/recipes-mac/AppArmor/apparmor_2.13.3.bb
index 990d870..6183064 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.3.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.3.bb
@@ -32,11 +32,12 @@ PARALLEL_MAKE = ""
 
 inherit pkgconfig autotools-brokensep update-rc.d python3native perlnative 
ptest cpan manpages systemd
 
-PACKAGECONFIG ??= "python perl"
+PACKAGECONFIG ??= "python perl aa-decode"
 PACKAGECONFIG[manpages] = "--enable-man-pages, --disable-man-pages"
 PACKAGECONFIG[python] = "--with-python, --without-python, python3 swig-native"
 PACKAGECONFIG[perl] = "--with-perl, --without-perl, perl perl-native 
swig-native"
 PACKAGECONFIG[apache2] = ",,apache2,"
+PACKAGECONFIG[aa-decode] = ",,,bash"
 
 PAMLIB="${@bb.utils.contains('DISTRO_FEATURES', 'pam', '1', '0', d)}"
 HTTPD="${@bb.utils.contains('PACKAGECONFIG', 'apache2', '1', '0', d)}"
@@ -97,6 +98,10 @@ do_install () {
rm -f ${D}${sbindir}/aa-notify
fi
 
+   if ! ${@bb.utils.contains('PACKAGECONFIG','aa-decode','true','false', 
d)}; then
+   rm -f ${D}${sbindir}/aa-decode
+   fi
+
if test -z "${HTTPD}" ; then
oe_runmake -C ${B}/changehat/mod_apparmor DESTDIR="${D}" install
fi
@@ -161,7 +166,6 @@ PACKAGES += "mod-${PN}"
 FILES_${PN} += "/lib/apparmor/ ${sysconfdir}/apparmor 
${PYTHON_SITEPACKAGES_DIR}"
 FILES_mod-${PN} = "${libdir}/apache2/modules/*"
 
-RDEPENDS_${PN} += "bash"
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','python','python3-core 
python3-modules','', d)}"
 RDEPENDS_${PN}_remove += 
"${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
 RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib bash"
-- 
2.17.1

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

[yocto] [meta-security][PATCH 1/2] apparmor: add PRIVATE_LIBS for ptest package

[Alexander Kanavin]

Otherwise, the following occurs:
ERROR: apparmor-2.13.3-r0 do_package: apparmor: Multiple shlib providers for 
libapparmor.so.1: apparmor, apparmor-ptest (used by files: 
/home/alexander/development/poky/build-metaoe/tmp/work/core2-32-poky-linux/apparmor/2.13.3-r0/packages-split/apparmor/usr/lib/perl5/vendor_perl/5.30.0/i686-linux/auto/LibAppArmor/LibAppArmor.so)
ERROR: apparmor-2.13.3-r0 do_package: apparmor: Multiple shlib providers for 
libapparmor.so.1: apparmor, apparmor-ptest (used by files: 
/home/alexander/development/poky/build-metaoe/tmp/work/core2-32-poky-linux/apparmor/2.13.3-r0/packages-split/apparmor/usr/lib/python3.7/site-packages/LibAppArmor/_LibAppArmor.cpython-37m-i686-linux-gnu.so)

Signed-off-by: Alexander Kanavin 
---
 recipes-mac/AppArmor/apparmor_2.13.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.3.bb 
b/recipes-mac/AppArmor/apparmor_2.13.3.bb
index 2e5d221..990d870 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.3.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.3.bb
@@ -165,3 +165,5 @@ RDEPENDS_${PN} += "bash"
 RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG','python','python3-core 
python3-modules','', d)}"
 RDEPENDS_${PN}_remove += 
"${@bb.utils.contains('PACKAGECONFIG','perl','','perl', d)}"
 RDEPENDS_${PN}-ptest += "perl coreutils dbus-lib bash"
+
+PRIVATE_LIBS_${PN}-ptest = "libapparmor.so*"
-- 
2.17.1

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

Re: [yocto] [OE-core] Yocto Project Status WW40’19

[Alexander Kanavin]

On Tue, 1 Oct 2019 at 16:54, Stephen K Jolley 
wrote:

> A significant performance problem has been found on the autobuilder where
> some builds are scaling in time badly as the sstate cache grows, taking 12
> hours or more in some cases. Unfortunately nobody seems motivated to help
> work on this kind of issue.
>

Wait a moment, I believe there is a patch for this issue?
http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287445.html

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

Re: [yocto] perf.bb on poky master branch

[Alexander Kanavin]

On Wed, 4 Sep 2019 at 10:53, vygu  wrote:

> Just to signal there are several mistakes with the recipe "perf.bb" from
> poky on master (currently: e2bde009b325b40641407ecf50f54ed8c41726d6)
>
> - If "Python 3 is not yet supported" by "perf" sources, it causes an issue
> during the do_compile task
> - The last "install" in the do_configure_prepend task about
> "tools/include/linux/bits.h" does not work with a linux kernel 4.5 to 4.18
> because this file does not exist
> [- The usage of _prepend or _append in this bb file does not help to
> create a bbappend]
>

I think this is expected: perf from oe-core is not guaranteed to work with
kernels other than those provided by oe-core. If this cannot be solved by
patching the original recipe (and sending patches to oe-core list), then
you can probably just make a custom perf recipe instead that works for you.

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

Re: [yocto] ptest-runner yocto build sytem issue

[Alexander Kanavin]

On Mon, 2 Sep 2019 at 16:06, sateesh m  wrote:

> Sure, sir. If you don't mine can you please share where this log file will
> present.
> I am seeing /tmp-glibc/work/riscv-oe-linux/ptest-runner/2.3.4.../temp/
> I am seeing here but log.do_rootfs file is not Present here.
>
> Can you please tell me where I can found this file.
>

I do not know what image you are building; it is in build directory of that
image. Use 'find' to locate it :)

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

Re: [yocto] ptest-runner yocto build sytem issue

[Alexander Kanavin]

On Mon, 2 Sep 2019 at 15:06, sateesh m  wrote:

> I followed the wiki https://wiki.yoctoproject.org/wiki/Ptest , but when I
> boot to my image and run ptest-runner I have the output : "No ptests found."
> Is this normal ? I thought that
>
> DISTRO_FEATURES_append = " ptest"
> and
> EXTRA_IMAGE_FEATURES += "ptest-pkgs"
>
> would install all the ptests for me in my image, apparently I am wrong but
> could you please explain to me why this is not the case i.e why ptests are
> not automatically installed in the image even though I included the above
> lines in my local.conf ?
>
> How to test my packages using ptest. can you share sample test or testing
> procedure document .
>

Can you share the log.do_rootfs file for your image please?

There are also example ptest images in poky, so you could try those and see
how they work.

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

Re: [yocto] Fetching Yocto layers

[Alexander Kanavin]

On Mon, 2 Sep 2019 at 15:05, Brian Silverman  wrote:

> The tags chosen above are based on what we test and ship.  So my issue is
> that someone has to correctly follow the above instructions for different
> versions of multiple layers if they want a reproducible build of a specific
> version of mylayer-image.
>
> Is there a canonical why to encode this information within my layer?
> Obviously I could script the above, store it in my layer, and have the user
> run that script.  But, that seems very unyocto-like.
>

At the moment Yocto project does not have an off-the shelf setup for
multiple layers. You are welcome to provide and maintain one, until then it
is indeed custom scripts, or tools like Google's 'repo', or maybe git
submodules could work.

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

Re: [yocto] Yocto 2.7 SDK Eclipse

[Alexander Kanavin]

On Wed, 21 Aug 2019 at 11:00, Bert Böhne  wrote:

> thanks for your reply. Do I need the plugins for writing and debugging
> code in Eclipse? The documentation says:
>
>
>
> 24.9.11. ADT Removed¶
>
>
>
> The Application Development Toolkit (ADT) has been removed because its
> functionality almost completely overlapped with the standard SDK and the
> extensible SDK. For information on these SDKs and how to build and use
> them, see the Yocto Project Application Development and the Extensible
> Software Development Kit (eSDK) manual.
>
>
>
> So would it work if I use Eclipse and maybe a plugin for CMake? Start
> Eclipse from the cmdline where I sourced the SDK environment setup script?
>
>
>
> What is the ‘normal’ way or tool for writing applications? Is it weird to
> want to use Eclipse?
>

I do not want to define 'normal'; for me personally the way to work is to
do everything from command line, with an extremely lightweight editor (e.g.
nano). Since I have never used Eclipse, I do not know what the (now
removed) plugins actually do. You can certainly still edit code using
Eclipse but I can imagine that for building it, and running it and other
things you would have to switch to the command line.

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

Re: [yocto] Yocto 2.7 SDK Eclipse

[Alexander Kanavin]

On Tue, 20 Aug 2019 at 17:34, Bert Böhne  wrote:

> I am using Yocto 2.7 and I want to use the SDK to build applications(or
> give the SDK to my colleagues to let them build applications). I have read
> in the documentation that there are plugins for Eclipse. But for Yocto
> 2.7(or maybe earlier) the support for this plugin was removed. So if we
> want to use Eclipse (and CMake), is this still possible? I am a little
> confused about this.
>
>
>
> If anybody could give me a hint, I would appreciate it very much.
>

It is possible, but you have to maintain it. The project couldn't find
anyone to take care of the plugins, and so the only remaining option was to
disable them.

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

Re: [yocto] Ticket Purchasing Yocto Conference in Lyon

[Alexander Kanavin]

On Mon, 19 Aug 2019 at 11:38,  wrote:

> some of our colleagues would like to join the yocto after the linux
> embedded. Unfortuntely I can’t find any website or link where a ticket
> purchasing is possible. Is it possible to receive any information on the
> purchasing process and when it will start?
>

It is right here:
https://events.linuxfoundation.org/events/embedded-linux-conference-europe-2019/program/co-located-events/

There is a link that lets you modify an existing registration by adding
'extras' to it, and yocto summit is one such. You need a registration code
for the original conference that came with the confirmation email.

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

Re: [yocto] State of Meson build system through eSDK

[Alexander Kanavin]

On Tue, 13 Aug 2019 at 12:41, Martin Siegumfeldt  wrote:

> The link above is not about eSDK, it's about devtool which works perfectly
> fine in a non-SDK environment (e.g. plain yocto).
>
> Hmm, since it is a subsection beneath 'Using the Extensible SDK' I was
> expecting the list to describe supported build systems related to devtool
> in context of the eSDK?
>

This is maybe not communicated well, but devtool works the same in and out
of SDK environment. You can check what build systems it supports here:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/scripts/lib/recipetool/create_buildsys.py#n874

It probably wouldn't be too much effort to add a meson handler there. In
any case, 'devtool add' is just a starting point, and does not promise to
produce a fully working recipe.

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

Re: [yocto] State of Meson build system through eSDK

[Alexander Kanavin]

On Tue, 13 Aug 2019 at 10:40, Martin Siegumfeldt  wrote:

> I am wondering if/when Meson is expected supported through the eSDK - I
> don't see it from the list:
>
> https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-a-closer-look-at-devtool-add
> ?
>

The link above is not about eSDK, it's about devtool which works perfectly
fine in a non-SDK environment (e.g. plain yocto).

I think meson in SDKs actually is supported, as there is a nativesdk-
version of the meson recipe. Do you want to try and report?

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

[linux-yocto] [PATCH] common-pc: enable support for bochs vga interface (qemu stdvga)

[Alexander Kanavin]

This will enable standardizing qemu machines to '-vga std' emulated
hardware (as opposed to the current mix of vmware or cirrus cards,
both outdated).

See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13466 for details.

Signed-off-by: Alexander Kanavin 
---
 bsp/common-pc-64/common-pc-64.scc | 2 ++
 bsp/common-pc/common-pc.scc   | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/bsp/common-pc-64/common-pc-64.scc 
b/bsp/common-pc-64/common-pc-64.scc
index b7b824c6..548f12d7 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -36,3 +36,5 @@ include cfg/8250.scc
 
 # sugarbay graphics
 include features/i915/i915.scc
+
+include features/drm-bochs/drm-bochs.scc
diff --git a/bsp/common-pc/common-pc.scc b/bsp/common-pc/common-pc.scc
index cd947b0f..fcb8af05 100644
--- a/bsp/common-pc/common-pc.scc
+++ b/bsp/common-pc/common-pc.scc
@@ -36,3 +36,5 @@ include features/bluetooth/bluetooth.scc
 # This stays last in the list, since it is our final override of the
 # common fragments (if required)
 kconf hardware common-pc.cfg
+
+include features/drm-bochs/drm-bochs.scc
-- 
2.17.1

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

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

On Thu, 8 Aug 2019 at 10:57, JH  wrote:

> Hi Alex, thanks for your response and kind help. I finally fixed it by
> adding a do_package_qa() in my bb file. What will be the consequence
> about it?
>

The consequences are that you have removed all of the standard quality
checks on your recipe, so it may break later (at installation or at
runtime) in various funny ways.

Also, this would be rejected in pretty much any code review.

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

Re: [yocto] [OE-core] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am to 8:30am on the first Tuesday (PST)

[Alexander Kanavin]

On Tue, 6 Aug 2019 at 03:53,  wrote:

> Wiki: https://www.yoctoproject.org/public-virtual-meetings/
>

That page links a Google calendar, and the calendar is in many ways
mismatching what is listed on the page. Can you please re-create the
calendar?

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

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

The right way out of this is to fix the issue: your main package depends on
the -dev package, and so will always pull it into the target image. I am
not telling you how to disable the check, as you're merely hiding a bug
that way :)

If you provide ls -lR of ${D}, we might be able to understand what happens.

Alex

On Tue, 6 Aug 2019 at 14:45, JH  wrote:

> Thanks Alex, here is the error in my application build, it used working
> well:
>
> ERROR: app_library-1.0.0-0 do_package_qa: QA Issue: app_library
> rdepends on app_library-dev [dev-deps]
> ERROR: app_library-1.0.0-0 do_package_qa: QA run found fatal errors.
> Please consider fixing them.
> ERROR: app_library-1.0.0-0 do_package_qa: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
>
> /home/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/app_library/1.0.0-0/temp/log.do_package_qa.6626
> ERROR: Task
> (/home/build/oe-core/../meta-app/recipes-core/app_library/app_library_git.bb:
> do_package_qa)
> failed with exit code '1'
>
> There is no do_package_qa in my app_library_git.bb, where is that
> do_package_qa from? how can I disable it? It sounds every easy in the
> document to disable it, but it did not give any clues -:(.
>
> Thank you.
>
> Kind regards,
>
> - jh
> On 8/6/19, Alexander Kanavin  wrote:
> > It may help if you copy-paste the exact error you are getting, and the
> > content of the directory where it happens.
> >
> > Alex
> >
> > On Tue, 6 Aug 2019 at 13:09, JH  wrote:
> >
> >> On 8/6/19, Alexander Kanavin  wrote:
> >> > You don't; package_qa is reporting real issues with your packaging, so
> >> you
> >> > need to address them.
> >>
> >> Well, my first issue is I need to build it, the document said it can
> >> be disabled, but did not say how, appreciate anyone helps how to
> >> disable it.
> >>
> >> Thank you
> >>
> >>
> >> > Alex
> >> >
> >> > On Tue, 6 Aug 2019 at 10:40, JH  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> According to the latest document:
> >> >>
> >> >> "Package QA checks are now performed during a new do_package_qa task
> >> >> rather than being part of the do_package task. This allows more
> >> >> parallel execution. This change is unlikely to be an issue except for
> >> >> highly customized recipes that disable packaging tasks themselves by
> >> >> marking them as noexec. For those packages, you will need to disable
> >> >> the do_package_qa task as well."
> >> >>
> >> >> How can I disable the do_package_qa task?
> >> >>
> >> >> Thank you.
> >> >>
> >> >> Kind regards,
> >> >>
> >> >> - jh
> >> >>
> >> >> On 8/4/19, JH  wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I was running my Yocto build fine until I had a minor change to
> move
> >> >> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so
> >> >> > to
> >> >> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> >> >> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> >> >> > errors, please consider fixing them.
> >> >> >
> >> >> > Even I reverse the changes back the, it still complained the same
> >> >> > error.
> >> >> >
> >> >> > I don't have do_package_qa in my bb file, where is it from? What is
> >> >> > that error about? How to fix it?
> >> >> >
> >> >> > Thank you.
> >> >> >
> >> >> > Kind regards,
> >> >> >
> >> >> > - jh
> >> >> >
> >> >> --
> >> >> ___
> >> >> 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] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

It may help if you copy-paste the exact error you are getting, and the
content of the directory where it happens.

Alex

On Tue, 6 Aug 2019 at 13:09, JH  wrote:

> On 8/6/19, Alexander Kanavin  wrote:
> > You don't; package_qa is reporting real issues with your packaging, so
> you
> > need to address them.
>
> Well, my first issue is I need to build it, the document said it can
> be disabled, but did not say how, appreciate anyone helps how to
> disable it.
>
> Thank you
>
>
> > Alex
> >
> > On Tue, 6 Aug 2019 at 10:40, JH  wrote:
> >
> >> Hi,
> >>
> >> According to the latest document:
> >>
> >> "Package QA checks are now performed during a new do_package_qa task
> >> rather than being part of the do_package task. This allows more
> >> parallel execution. This change is unlikely to be an issue except for
> >> highly customized recipes that disable packaging tasks themselves by
> >> marking them as noexec. For those packages, you will need to disable
> >> the do_package_qa task as well."
> >>
> >> How can I disable the do_package_qa task?
> >>
> >> Thank you.
> >>
> >> Kind regards,
> >>
> >> - jh
> >>
> >> On 8/4/19, JH  wrote:
> >> > Hi,
> >> >
> >> > I was running my Yocto build fine until I had a minor change to move
> >> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so to
> >> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> >> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> >> > errors, please consider fixing them.
> >> >
> >> > Even I reverse the changes back the, it still complained the same
> >> > error.
> >> >
> >> > I don't have do_package_qa in my bb file, where is it from? What is
> >> > that error about? How to fix it?
> >> >
> >> > Thank you.
> >> >
> >> > Kind regards,
> >> >
> >> > - jh
> >> >
> >> --
> >> ___
> >> 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] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

You don't; package_qa is reporting real issues with your packaging, so you
need to address them.

Alex

On Tue, 6 Aug 2019 at 10:40, JH  wrote:

> Hi,
>
> According to the latest document:
>
> "Package QA checks are now performed during a new do_package_qa task
> rather than being part of the do_package task. This allows more
> parallel execution. This change is unlikely to be an issue except for
> highly customized recipes that disable packaging tasks themselves by
> marking them as noexec. For those packages, you will need to disable
> the do_package_qa task as well."
>
> How can I disable the do_package_qa task?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
> On 8/4/19, JH  wrote:
> > Hi,
> >
> > I was running my Yocto build fine until I had a minor change to move
> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so to
> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> > errors, please consider fixing them.
> >
> > Even I reverse the changes back the, it still complained the same error.
> >
> > I don't have do_package_qa in my bb file, where is it from? What is
> > that error about? How to fix it?
> >
> > Thank you.
> >
> > Kind regards,
> >
> > - jh
> >
> --
> ___
> 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-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

[Alexander Kanavin]

Awesome, thanks!

Alex

On Wed, 31 Jul 2019 at 17:04, Alex J Lennon 
wrote:

>
> On 18/06/2019 11:58, Alexander Kanavin wrote:
> > Ping #2!
> >
> > Alex
>
>
> Apologies for the long delay! The patch is in finally...
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Integration of Conan Package Manager into the Yocto Project

[Alexander Kanavin]

Pulling down things from the network in do_install() is not the best
option. Is reproducibility and integrity of such downloads guaranteed? What
about the component licensing, where is that checked (against upstream
changes)? Also, yocto's download caching and mirroring facility is
side-stepped entirely.

The typical 'Yocto way' would be to write a specific conan fetcher for
bitbake, so that you can specify SRC_URI = "conan://..." in recipes:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2?h=master-next

Generally, if someone is doing system integration with Yocto and has access
to the source code, they might just write actual component recipes for
building from source, as the presented workflow with building via SDK and
artifactory binary uploads is awkward, and all benefits that happen when
yocto is able to build directly from source code are lost.

Regards,
Alex


On Fri, 26 Jul 2019 at 14:39, Dani Manzaneque 
wrote:

> Hi!
>
> We have developed an integration with Yocto for the open-source Conan
> C/C++ package manager.
> This integration includes the ability to cross-build packages with a
> Yocto SDK Toolchain and later deploy them in the Yocto build.
>
> We have created a blog post with a brief introduction to the Yocto
> Project and the announcement of the integration:
> https://blog.conan.io/2019/07/26/Conan-Yocto-integration.html
>
> And a detailed section in our documentation with the configuration for
> the meta-conan layer and the Bitbake recipes for the packages:
> https://docs.conan.io/en/latest/integrations/cross_platform/yocto.html
>
> Feedback is welcomed. Thanks a lot!
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Alexander Kanavin]

On Tue, 23 Jul 2019 at 20:49,  wrote:

>
>- There are patches available which enable runqueue optimisations
>based on output comparisons of tasks. This removes the need to run later
>tasks if the output is unchanged and is based upon the previous hash
>equivalence server work. This feature should be a significant win for the
>users and is now working to a level where we’ll likely make this a key
>feature of the next release.
>
> This is going to be awesome! Maybe this achievement should get wider
exposure via a LWN article? (provided they accept the submission)

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

Re: [yocto] meta-mono updates

[Alexander Kanavin]

I don’t really know what’s the situation with meta-mono specifically, but if 
you’re willing to be the maintainer, that’d be great. Do keep in mind that 
yocto is almost entirely a volunteer project, contributors and maintainers come 
and go without long term promises.

Alex

> On 18 Jul 2019, at 9.49, MUGRIDGE Robin  wrote:
> 
> Hi,
>  
> I notice that meta-mono has not been updated for a while now (2018-11-06 for 
> the repo at git.yoctoproject.org, 2019-03-22 for the repo at 
> github.com/DynamicDevices).
>  
> Is this layer no longer being maintained?  Is there an alternative?
>  
> Thanks,
>  
> Robin
>  
> ___
> This e-mail is confidential and is for the addressee only.   Please refer to 
> www.oxinst.com/email-statement for regulatory information.
> -- 
> ___
> 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-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

[Alexander Kanavin]

Ping #2!

Alex

On Mon, 27 May 2019 at 12:22, Alex J Lennon 
wrote:

>
> Thanks for the reminder Alex
> On 27/05/2019 11:16, Alexander Kanavin wrote:
>
> Ping?
>
> Alex
>
> On Mon, 13 May 2019 at 18:25, Alexander Kanavin  
>  wrote:
>
> When build directory is deeply nested, the shebang limit of 127
> characters is hit, which leads to doltlibtool failing to execute.
>
> Signed-off-by: Alexander Kanavin  
> 
> ---
>  recipes-mono/mono/mono-5.xx.inc | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
> index c36374c..dec2475 100644
> --- a/recipes-mono/mono/mono-5.xx.inc
> +++ b/recipes-mono/mono/mono-5.xx.inc
> @@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
>
>  # Workaround for observed race in `make install`
>  PARALLEL_MAKEINST=""
> +
> +# Otherwise the full path to bash is written to the first line of 
> doltlibtool script
> +# which causes build failures with deeply nested build directories
> +CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
> --
> 2.17.1
>
>
> --
>
> [image: Dynamic Devices Ltd] <http://www.dynamicdevices.co.uk/>
>
> Alex J Lennon MA (Cantab) MIET MIOD / Director
> DoES Liverpool 1st Floor The Tapestry 68 – 76 Kempston Street Liverpool L3
> 8HL, United Kingdom
>
> mobile: +44 (0)7478 346120
>
> [image: Linkedin] <http://www.linkedin.com/in/alexjlennon> [image: Skype]
> <http://www.daneurope.org/web/guest/registration?p_p_id=registration_p_lifecycle=0_p_mode=view_p_state=normal&_registration_struts_action=%2Fext%2Fregistration%2Fwizard&_registration_processType=2&_registration_partnerCode=517352>
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. Company Name is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf causing build failure

[Alexander Kanavin]

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

Alex

On Fri, 14 Jun 2019 at 15:53, Larry Brown  wrote:

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

Re: [yocto] [meta-selinux][PATCH] glib-2.0: fix configure error for meson build

[Alexander Kanavin]

On Wed, 12 Jun 2019 at 09:54, Yi Zhao  wrote:

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

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

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

Re: [yocto] Issue with INCOMPATIBLE_LICENSE

[Alexander Kanavin]

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

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

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

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

Re: [yocto] Python module not found when using autotools

[Alexander Kanavin]

I guess you could start by looking at configure.ac in the failing
component's source code and specifically which m4 macro it is using to find
the python module, then look at the definition of that macro and what it
does. Sadly, this kind of thing - working your way through large,
unfamiliar code base to debug a build failure - is typical when working
with Yocto, and is pretty much a required skill.

Alex

On Thu, 30 May 2019 at 21:08, Serkan Türker 
wrote:

> Hi Alexander,
>
> thank you for the quick reply. Doing the ./configure part on the host
> machine for host (basically, compiling tizonia on Ubuntu) works fine, there
> it can find the soundcloud module. I just don't understand where autotools
> (during bitbake) is looking for the soundcloud module and what I have to do
> to make it work.
>
> Cheers,
> Serkan
>
> On Thu, May 30, 2019 at 11:46 AM Alexander Kanavin 
> wrote:
>
>> This is really an autotools question, not a yocto question. Specifically,
>> what happens at this point?
>> *| checking python module: soundcloud... no*
>>
>> Quite likely, the autotools script runs native python and asks it to
>> import soundcloud, which fails. You need a different approach, maybe
>> checking for the module file in the target sysroot.
>>
>> Also, do not use python 2.7. All upstream support for it ends in 6 months.
>>
>> Alex
>>
>> On Thu, 30 May 2019 at 04:37, Serkan Türker 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am trying to write a bitbake file for a project. The project uses
>>> autotools for configuring the project before building it.
>>> While configuring it, it searches for several python modules, where some
>>> of them are custom modules I wrote the bitbake recipe for.
>>> Even though the python module builds and installs correctly to the
>>> sysroot directory, it is not found in the configure step.
>>>
>>> 
>>> python-soundcloud_0.5.0.bb
>>>
>>> *---*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *LICENSE = "MIT"LIC_FILES_CHKSUM =
>>> "file://LICENSE;md5=31fa3a9dc818e0087893d63583d2d21a"SRC_URI[md5sum] =
>>> "40c1d32afd019ed11ec1fbee3e84e31f"SRC_URI[sha256sum] =
>>> "aad2003592cec945f835f158f7b41ba8bf805c5738a2fcc5629668ea1df653d5"DEPENDS_${PN}
>>> = "${PYTHON_PN}-modules"PYPI_PACKAGE = "soundcloud"*
>>>
>>>
>>>
>>> *inherit setuptools pypiRDEPENDS_${PN} = "${PYTHON_PN}-modules"*
>>>
>>> ---
>>>
>>> *python-soundcloud is succesfully installed to
>>> "BUILD/sysroots/raspberrypi3/usr/lib/python2.7/site-packages/soundcloud"*
>>>
>>> 
>>> tizonia.bb
>>>
>>> ---
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *SUMMARY = "Tizonia Library"DESCRIPTION = "Tizonia"LICENSE =
>>> "LGPL-3.0"LIC_FILES_CHKSUM =
>>> "file://COPYING.LESSER;md5=e6a600fd5e1d9cbde2d983680233ad02"SRC_URI =
>>> "git://github.com/tizonia/tizonia-openmax-il.git;protocol=https
>>> <http://github.com/tizonia/tizonia-openmax-il.git;protocol=https>"SRCREV =
>>> "9004bc40b89eeafb04b28fbb2b772e47dd62fdc9"S = "${WORKDIR}/git"DEPENDS =
>>> "mediainfo log4c python-pip python-soundcloud"*
>>>
>>>
>>>
>>>
>>>
>>> *inherit autotools ccache pkgconfig pythonnativeRDEPENDS_${PN} =
>>> "libstdc++ mediainfo log4c python-soundcloud"EXTRA_OECONF += "-C"*
>>>
>>> ---
>>>
>>> *The error message I get from bitbake:*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *| checking for python2.7... (cached)
>>> /home/developer/build-webos-ose/BUIL

Re: [yocto] Python module not found when using autotools

[Alexander Kanavin]

This is really an autotools question, not a yocto question. Specifically,
what happens at this point?
*| checking python module: soundcloud... no*

Quite likely, the autotools script runs native python and asks it to import
soundcloud, which fails. You need a different approach, maybe checking for
the module file in the target sysroot.

Also, do not use python 2.7. All upstream support for it ends in 6 months.

Alex

On Thu, 30 May 2019 at 04:37, Serkan Türker 
wrote:

> Hi all,
>
> I am trying to write a bitbake file for a project. The project uses
> autotools for configuring the project before building it.
> While configuring it, it searches for several python modules, where some
> of them are custom modules I wrote the bitbake recipe for.
> Even though the python module builds and installs correctly to the sysroot
> directory, it is not found in the configure step.
>
> 
> python-soundcloud_0.5.0.bb
>
> *---*
>
>
>
>
>
>
>
>
> *LICENSE = "MIT"LIC_FILES_CHKSUM =
> "file://LICENSE;md5=31fa3a9dc818e0087893d63583d2d21a"SRC_URI[md5sum] =
> "40c1d32afd019ed11ec1fbee3e84e31f"SRC_URI[sha256sum] =
> "aad2003592cec945f835f158f7b41ba8bf805c5738a2fcc5629668ea1df653d5"DEPENDS_${PN}
> = "${PYTHON_PN}-modules"PYPI_PACKAGE = "soundcloud"*
>
>
>
> *inherit setuptools pypiRDEPENDS_${PN} = "${PYTHON_PN}-modules"*
>
> ---
>
> *python-soundcloud is succesfully installed to
> "BUILD/sysroots/raspberrypi3/usr/lib/python2.7/site-packages/soundcloud"*
>
> 
> tizonia.bb
>
> ---
>
>
>
>
>
>
>
>
>
>
> *SUMMARY = "Tizonia Library"DESCRIPTION = "Tizonia"LICENSE =
> "LGPL-3.0"LIC_FILES_CHKSUM =
> "file://COPYING.LESSER;md5=e6a600fd5e1d9cbde2d983680233ad02"SRC_URI =
> "git://github.com/tizonia/tizonia-openmax-il.git;protocol=https
> "SRCREV =
> "9004bc40b89eeafb04b28fbb2b772e47dd62fdc9"S = "${WORKDIR}/git"DEPENDS =
> "mediainfo log4c python-pip python-soundcloud"*
>
>
>
>
>
> *inherit autotools ccache pkgconfig pythonnativeRDEPENDS_${PN} =
> "libstdc++ mediainfo log4c python-soundcloud"EXTRA_OECONF += "-C"*
>
> ---
>
> *The error message I get from bitbake:*
>
>
>
>
>
>
>
>
>
>
>
>
> *| checking for python2.7... (cached)
> /home/developer/build-webos-ose/BUILD/sysroots/x86_64-linux/usr/bin/python-native/python|
> checking for a version of Python >= '2.1.0'... yes| checking for a version
> of Python >= '2.7'... yes| checking for the distutils Python package...
> yes| checking for Python include path...
> -I/home/developer/build-webos-ose/BUILD/sysroots/raspberrypi3/usr/include/python2.7|
> checking for Python library path...
> -L/home/developer/build-webos-ose/BUILD/sysroots/raspberrypi3/usr/lib
> -lpython2.7| checking for Python site-packages path...
> /home/developer/build-webos-ose/BUILD/sysroots/x86_64-linux/usr/lib/python2.7/site-packages|
> checking python extra libraries... -lpthread -ldl  -lpthread -lutil -lm|
> checking python extra linking flags... -Xlinker -export-dynamic| checking
> consistency of all components of python development environment... yes|
> checking python module: soundcloud... no| configure: error: failed to find
> required module soundcloud*
>
> Does somebody know what I am doing wrong? I cannot figure it out, any help
> is appreciated!
>
> Cheers,
> Serkan
> --
> ___
> 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-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

[Alexander Kanavin]

Ping?

Alex

On Mon, 13 May 2019 at 18:25, Alexander Kanavin  wrote:
>
> When build directory is deeply nested, the shebang limit of 127
> characters is hit, which leads to doltlibtool failing to execute.
>
> Signed-off-by: Alexander Kanavin 
> ---
>  recipes-mono/mono/mono-5.xx.inc | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
> index c36374c..dec2475 100644
> --- a/recipes-mono/mono/mono-5.xx.inc
> +++ b/recipes-mono/mono/mono-5.xx.inc
> @@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
>
>  # Workaround for observed race in `make install`
>  PARALLEL_MAKEINST=""
> +
> +# Otherwise the full path to bash is written to the first line of 
> doltlibtool script
> +# which causes build failures with deeply nested build directories
> +CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
> --
> 2.17.1
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] distrodata documentation in 2.7 Mega Manual

[Alexander Kanavin]

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

This is no longer necessary, you can remove the step.

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

There is no equivalent, you can remove the sectrion.

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

The equivalent functionality is provided by running devtool - 'devtool
latest-version' for one recipe, 'devtool check-upgrade-status' for
several (or all).

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

All three should refer to the equivalent replacement (see above)
provided by devtool.

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

Re: [yocto] configuration for a layer apart from local.conf

[Alexander Kanavin]

Yes - your distro configuration file is the correct place to do it.

Alex

On Wed, 22 May 2019 at 07:12, Pandey, Kamal  wrote:
>
> Hi,
>
> I want to know if there is any other place where we can set configuration for 
> a particular layer, apart from local.conf. For example if I want to set 
> LICENSE_FLAGS_WHITELIST can I do that in layer.conf, or do I need to do that 
> in local.conf only. Similarly for BBMASK too. So basically my question is, 
> for setting the configurations of a particular layer, is there any place 
> where I can set those variables inside that layer only?
>
> Best Regards
>
> Kamal Pandey
>
>
>
> --
> ___
> 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] NPM Fetcher question

[Alexander Kanavin]

I think Jean-Marie might be able to help as he recently did a bit of NPM fixing?


Alex

On Tue, 21 May 2019 at 19:52, Scott Rifenbark  wrote:
>
> Hi,
>
> I am trying to determine if the information in 
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM is relevant and 
> up-to-date for current YP release.  I am having trouble finding a resource 
> familiar with this topic.
>
> Can anyone point me to the expert for this area?
>
> Thanks,
> Scott Rifenbark (docs)
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting SRC_URI runtime - possible options

[Alexander Kanavin]

Don't use the config file at all. Just create as many recipes as you
need, put the common bits into the class, and the bits that differ
into the recipes directly.

Example:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/pypi.bbclass

Alex

On Tue, 21 May 2019 at 12:22, Belisko Marek  wrote:
>
> On Tue, May 21, 2019 at 12:14 PM Alexander Kanavin  
> wrote:
>>
>> You can write a class which sets the template for SRC_URI and then a
>> series of recipes that inherit the class, and define the variable that
>> would turn the template into the actual URI.
>
> OK I think it make sense. So parsing of config file will be done in class and 
> then class will be used in recipes to set correct SRU_URI.
> Do you have any idea what is wrong with actual code I posted? Why it is doing 
> some strange things? Thanks.
>>
>>
>> Alex
>>
>> On Tue, 21 May 2019 at 12:10, Belisko Marek  wrote:
>> >
>> > Hi,
>> >
>> > On Tue, May 21, 2019 at 12:00 PM Alexander Kanavin 
>> >  wrote:
>> >>
>> >> If you provide some context for why you want this, we might be able to
>> >> suggest a different way.
>> >
>> > Customer wants to have kind of base-os (build in yocto) and then on top of 
>> > that different flavor python application which should be fetch and added 
>> > during build based on configuration file. This is only need. Thanks.
>> >>
>> >>
>> >> Alex
>> >>
>> >> On Tue, 21 May 2019 at 08:11, Belisko Marek  
>> >> wrote:
>> >> >
>> >> > Hi,
>> >> >
>> >> > I have special need to fetch repo which is defined in config file in 
>> >> > form (repo and branch):
>> >> > g...@testrepo.com/myrepo mysuperbranch
>> >> >
>> >> > Config file is placed in recipe directory. I've tried to add some bits 
>> >> > and pieces but it seems it's not doing right. Snippet from recipe:
>> >> >
>> >> > LICENSE = "CLOSED"
>> >> >
>> >> > SRCREV = "${AUTOREV}"
>> >> > PV = "${SRCPV}"
>> >> >
>> >> > do_fetch_prepend () {
>> >> >
>> >> > src_uri = d.getVar('SRC_URI')
>> >> >
>> >> > p = d.getVar("FILE")
>> >> > idx = p.rfind("/")
>> >> > p = p[:idx]
>> >> > p += "/config.txt"
>> >> >
>> >> > with open(p) as f:
>> >> > read_data = f.readline().strip().split(" ")
>> >> > d.setVar('SRC_URI', read_data[0])
>> >> > }
>> >> >
>> >> > SRC_URI = ""
>> >> >
>> >> > S = "${WORKDIR}/git"
>> >> >
>> >> > It looks like that repo is fetched but unpack doesn't put git directory 
>> >> > in $WORKDIR and in build directory I get strange directories like:
>> >> >
>> >> > !=
>> >> > bitbake-cookerdaemon.log
>> >> > cache
>> >> > conf
>> >> > ${@d.getVar('S')
>> >> > else
>> >> > if
>> >> > os.path.join('
>> >> > os.path.normpath(d.getVar('S'))
>> >> > os.path.normpath(d.getVar('WORKDIR'))
>> >> > 'patches')}
>> >> > tmp
>> >> >
>> >> > so there is obviously I'm doing something wrong :). My question is if 
>> >> > this is the way or should I stick to some variables set in local.conf 
>> >> > and then use it in recipe? Thanks a lot for any pointers.
>> >> >
>> >> > BR,
>> >> >
>> >> > marek
>> >> > --
>> >> > as simple and primitive as possible
>> >> > -
>> >> > Marek Belisko - OPEN-NANDRA
>> >> > Freelance Developer
>> >> >
>> >> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> >> > Tel: +421 915 052 184
>> >> > skype: marekwhite
>> >> > twitter: #opennandra
>> >> > web: http://open-nandra.com
>> >> > --
>> >> > ___
>> >> > yocto mailing list
>> >> > yocto@yoctoproject.org
>> >> > https://lists.yoctoproject.org/listinfo/yocto
>> >
>> >
>> >
>> > marek
>
>
>
> marek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting SRC_URI runtime - possible options

[Alexander Kanavin]

You can write a class which sets the template for SRC_URI and then a
series of recipes that inherit the class, and define the variable that
would turn the template into the actual URI.

Alex

On Tue, 21 May 2019 at 12:10, Belisko Marek  wrote:
>
> Hi,
>
> On Tue, May 21, 2019 at 12:00 PM Alexander Kanavin  
> wrote:
>>
>> If you provide some context for why you want this, we might be able to
>> suggest a different way.
>
> Customer wants to have kind of base-os (build in yocto) and then on top of 
> that different flavor python application which should be fetch and added 
> during build based on configuration file. This is only need. Thanks.
>>
>>
>> Alex
>>
>> On Tue, 21 May 2019 at 08:11, Belisko Marek  wrote:
>> >
>> > Hi,
>> >
>> > I have special need to fetch repo which is defined in config file in form 
>> > (repo and branch):
>> > g...@testrepo.com/myrepo mysuperbranch
>> >
>> > Config file is placed in recipe directory. I've tried to add some bits and 
>> > pieces but it seems it's not doing right. Snippet from recipe:
>> >
>> > LICENSE = "CLOSED"
>> >
>> > SRCREV = "${AUTOREV}"
>> > PV = "${SRCPV}"
>> >
>> > do_fetch_prepend () {
>> >
>> > src_uri = d.getVar('SRC_URI')
>> >
>> > p = d.getVar("FILE")
>> > idx = p.rfind("/")
>> > p = p[:idx]
>> > p += "/config.txt"
>> >
>> > with open(p) as f:
>> > read_data = f.readline().strip().split(" ")
>> > d.setVar('SRC_URI', read_data[0])
>> > }
>> >
>> > SRC_URI = ""
>> >
>> > S = "${WORKDIR}/git"
>> >
>> > It looks like that repo is fetched but unpack doesn't put git directory in 
>> > $WORKDIR and in build directory I get strange directories like:
>> >
>> > !=
>> > bitbake-cookerdaemon.log
>> > cache
>> > conf
>> > ${@d.getVar('S')
>> > else
>> > if
>> > os.path.join('
>> > os.path.normpath(d.getVar('S'))
>> > os.path.normpath(d.getVar('WORKDIR'))
>> > 'patches')}
>> > tmp
>> >
>> > so there is obviously I'm doing something wrong :). My question is if this 
>> > is the way or should I stick to some variables set in local.conf and then 
>> > use it in recipe? Thanks a lot for any pointers.
>> >
>> > BR,
>> >
>> > marek
>> > --
>> > as simple and primitive as possible
>> > -
>> > Marek Belisko - OPEN-NANDRA
>> > Freelance Developer
>> >
>> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
>> > Tel: +421 915 052 184
>> > skype: marekwhite
>> > twitter: #opennandra
>> > web: http://open-nandra.com
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> marek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] setting SRC_URI runtime - possible options

[Alexander Kanavin]

If you provide some context for why you want this, we might be able to
suggest a different way.

Alex

On Tue, 21 May 2019 at 08:11, Belisko Marek  wrote:
>
> Hi,
>
> I have special need to fetch repo which is defined in config file in form 
> (repo and branch):
> g...@testrepo.com/myrepo mysuperbranch
>
> Config file is placed in recipe directory. I've tried to add some bits and 
> pieces but it seems it's not doing right. Snippet from recipe:
>
> LICENSE = "CLOSED"
>
> SRCREV = "${AUTOREV}"
> PV = "${SRCPV}"
>
> do_fetch_prepend () {
>
> src_uri = d.getVar('SRC_URI')
>
> p = d.getVar("FILE")
> idx = p.rfind("/")
> p = p[:idx]
> p += "/config.txt"
>
> with open(p) as f:
> read_data = f.readline().strip().split(" ")
> d.setVar('SRC_URI', read_data[0])
> }
>
> SRC_URI = ""
>
> S = "${WORKDIR}/git"
>
> It looks like that repo is fetched but unpack doesn't put git directory in 
> $WORKDIR and in build directory I get strange directories like:
>
> !=
> bitbake-cookerdaemon.log
> cache
> conf
> ${@d.getVar('S')
> else
> if
> os.path.join('
> os.path.normpath(d.getVar('S'))
> os.path.normpath(d.getVar('WORKDIR'))
> 'patches')}
> tmp
>
> so there is obviously I'm doing something wrong :). My question is if this is 
> the way or should I stick to some variables set in local.conf and then use it 
> in recipe? Thanks a lot for any pointers.
>
> BR,
>
> marek
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
> --
> ___
> 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] [PATCH][AUH] steps.py: set up AUH workdir before calling bitbake to get env

[Alexander Kanavin]

Otherwise, if bitbake fails, there will be tracebacks later on.

Signed-off-by: Alexander Kanavin 
---
 modules/steps.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/modules/steps.py b/modules/steps.py
index 2eb4499..87d7584 100644
--- a/modules/steps.py
+++ b/modules/steps.py
@@ -34,9 +34,9 @@ from errors import *
 from buildhistory import BuildHistory
 
 def load_env(devtool, bb, git, opts, pkg_ctx):
-pkg_ctx['env'] = bb.env(pkg_ctx['PN'])
 pkg_ctx['workdir'] = os.path.join(pkg_ctx['base_dir'], pkg_ctx['PN'])
 os.mkdir(pkg_ctx['workdir'])
+pkg_ctx['env'] = bb.env(pkg_ctx['PN'])
 pkg_ctx['recipe_dir'] = os.path.dirname(pkg_ctx['env']['FILE'])
 
 if pkg_ctx['env']['PV'] == pkg_ctx['NPV']:
-- 
2.17.1

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

Re: [yocto] python-numpy RDEPENDS not honored?

[Alexander Kanavin]

Basically if you make a patch for the numpy recipe to address this,
and post it to oe-core list, everyone would appreciate :)

Alex

On Tue, 14 May 2019 at 20:16, Aaron Cohen  wrote:
>
> Is there a place I should post this that would get more attention?
>
> On Thu, May 9, 2019 at 4:48 PM Aaron Cohen  wrote:
>>
>> I think the problem is in the python-numpy_1.14.5.bb recipe.
>>
>> It does: RDEPENDS_${PN}_class-target_append = ...
>>
>> where it seems to need to be: RDEPENDS_${PN}_append_class-target = ...
>>
>> Note the position of the word append.
>>
>> If someone wanted to point me in the right direction, I could try to make a 
>> qa task that would discover this sort of error if it seems feasible?
>>
>> --Aaron
>>
>>
>> On Thu, May 9, 2019 at 4:15 PM Aaron Cohen  wrote:
>>>
>>> python-numpy is being installed on my image as a dependency of one of my 
>>> packages.
>>>
>>> However, none of python-numpy's RDEPENDS are currently being included on 
>>> the image.
>>>
>>> When I run bitbake -e python-numpy > numpy.txt, I see that for some reason, 
>>> the RDEPENDS is being overridden to a nearly empty value:
>>>
 # $RDEPENDS_python-numpy [5 operations]
 #   append 
 /home/joel-cohen/code/juevos/poky/meta/classes/distutils-base.bbclass:2
 # "${@['', '${PYTHON_PN}-core']['${CLASSOVERRIDE}' == 'class-target']}"
 #   set 
 /home/joel-cohen/code/juevos/poky/meta/recipes-devtools/python-numpy/python-numpy.inc:112
 # "${PYTHON_PN}-unittest   ${PYTHON_PN}-difflib
${PYTHON_PN}-pprint   ${PYTHON_PN}-pickle   
 ${PYTHON_PN}-shell   ${PYTHON_PN}-nose 
   ${PYTHON_PN}-doctest   ${PYTHON_PN}-datetime 
   ${PYTHON_PN}-distutils   ${PYTHON_PN}-misc   
 ${PYTHON_PN}-mmap   ${PYTHON_PN}-netclient 
   ${PYTHON_PN}-numbers   
 ${PYTHON_PN}-pydoc   ${PYTHON_PN}-pkgutil  
  ${PYTHON_PN}-email   ${PYTHON_PN}-compression 
   ${PYTHON_PN}-ctypes   ${PYTHON_PN}-threading "
 #   rename from RDEPENDS_${PN} data.py:117 [expandKeys]
 # "${PYTHON_PN}-unittest   ${PYTHON_PN}-difflib
${PYTHON_PN}-pprint   ${PYTHON_PN}-pickle   
 ${PYTHON_PN}-shell   ${PYTHON_PN}-nose 
   ${PYTHON_PN}-doctest   ${PYTHON_PN}-datetime 
   ${PYTHON_PN}-distutils   ${PYTHON_PN}-misc   
 ${PYTHON_PN}-mmap   ${PYTHON_PN}-netclient 
   ${PYTHON_PN}-numbers   
 ${PYTHON_PN}-pydoc   ${PYTHON_PN}-pkgutil  
  ${PYTHON_PN}-email   ${PYTHON_PN}-compression 
   ${PYTHON_PN}-ctypes   ${PYTHON_PN}-threading "
 #   override[class-native]:set 
 /home/joel-cohen/code/juevos/poky/meta/recipes-devtools/python-numpy/python-numpy.inc:114
 # ""
 #   override[class-native]:rename from RDEPENDS_${PN}_class-native 
 data_smart.py:644 [renameVar]
 # ""
 # pre-expansion value:
 #   " ${PYTHON_PN}-subprocess "
 RDEPENDS_python-numpy=" python-subprocess "
>>>
>>>
>>>
>>> Anyone have any ideas for why this recipe doesn't seem to be behaving 
>>> correctly?
>>>
>>> I'm using poky 2.6 at the moment.
>>>
>>> Thanks for any help,
>>> Aaron
>
> --
> ___
> 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] ntp recipe not able to install few packages in the rootfs

[Alexander Kanavin]

How does your image recipe look like? Also, log.do_rootfs can provide
a hint about what got installed into the image (you will find it in
the image build directory).

Alex

On Tue, 14 May 2019 at 11:42, Pandey, Kamal  wrote:
>
> Hi
> I was trying to add ntp package to my image, I used the meta-networking layer 
> for the recipe and added the ntp package to my custom image.bb recipe.
> After compiling I can see multiple packages in package-split directory of the 
> working directory of ntp package, but these binaries are missing in the 
> ROOTFS directory.
> Below is my ntp recipe:
>
>
> SUMMARY = "Network Time Protocol daemon and utilities"
> DESCRIPTION = "The Network Time Protocol (NTP) is used to \
> synchronize the time of a computer client or server to \
> another server or reference time source, such as a radio \
> or satellite receiver or modem."
> HOMEPAGE = "http://support.ntp.org;
> SECTION = "net"
> LICENSE = "NTP"
> LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=e877a1d567a6a58996d2b66e3e387003"
>
> DEPENDS = "libevent"
>
> SRC_URI = 
> "http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-4.2/ntp-${PV}.tar.gz \
>file://ntp-4.2.4_p6-nano.patch \
>file://reproducibility-fixed-path-to-posix-shell.patch \
>file://reproducibility-respect-source-date-epoch.patch \
>file://ntpd \
>file://ntp.conf \
>file://ntpdate \
>file://ntpdate.default \
>file://ntpdate.service \
>file://ntpd.service \
>file://sntp.service \
>file://sntp \
>file://ntpd.list \
> "
>
> SRC_URI[md5sum] = "1522d66574bae14abb2622746dad2bdc"
> SRC_URI[sha256sum] = 
> "709b222b5013d77d26bfff532b5ea470a8039497ef29d09363931c036cb30454"
>
> inherit autotools update-rc.d useradd systemd pkgconfig
>
> # The ac_cv_header_readline_history is to stop ntpdc depending on either
> # readline or curses
> EXTRA_OECONF += "--with-net-snmp-config=no \
>  --without-ntpsnmpd \
>  ac_cv_header_readline_history_h=no \
>  --with-yielding_select=yes \
>  --with-locfile=redhat \
>  --without-rpath \
>  "
> CFLAGS_append = " -DPTYS_ARE_GETPT -DPTYS_ARE_SEARCHED"
>
> USERADD_PACKAGES = "${PN}"
> NTP_USER_HOME ?= "/var/lib/ntp"
> USERADD_PARAM_${PN} = "--system --home-dir ${NTP_USER_HOME} \
>--no-create-home \
>--shell /bin/false --user-group ntp"
>
> # NB: debug is default-enabled by NTP; keep it default-enabled here.
> PACKAGECONFIG ??= "cap debug refclocks openssl \
> ${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} \
> "
> PACKAGECONFIG[openssl] = "--with-openssl-libdir=${STAGING_LIBDIR} \
>   --with-openssl-incdir=${STAGING_INCDIR} \
>   --with-crypto, \
>   --without-openssl --without-crypto, \
>   openssl"
> PACKAGECONFIG[cap] = "--enable-linuxcaps,--disable-linuxcaps,libcap"
> PACKAGECONFIG[readline] = 
> "--with-lineeditlibs,--without-lineeditlibs,readline"
> PACKAGECONFIG[refclocks] = 
> "--enable-all-clocks,--disable-all-clocks,pps-tools"
> PACKAGECONFIG[debug] = "--enable-debugging,--disable-debugging"
> PACKAGECONFIG[mdns] = 
> "ac_cv_header_dns_sd_h=yes,ac_cv_header_dns_sd_h=no,mdns"
> PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
>
> do_install_append() {
> install -d ${D}${sysconfdir}/init.d
> install -m 644 ${WORKDIR}/ntp.conf ${D}${sysconfdir}
> install -m 755 ${WORKDIR}/ntpd ${D}${sysconfdir}/init.d
> install -d ${D}${bindir}
> install -m 755 ${WORKDIR}/ntpdate ${D}${bindir}/ntpdate-sync
>
> install -m 755 -d ${D}${NTP_USER_HOME}
> chown ntp:ntp ${D}${NTP_USER_HOME}
>
> # Fix hardcoded paths in scripts
> sed -i 's!/usr/sbin/!${sbindir}/!g' ${D}${sysconfdir}/init.d/ntpd 
> ${D}${bindir}/ntpdate-sync
> sed -i 's!/usr/bin/!${bindir}/!g' ${D}${sysconfdir}/init.d/ntpd 
> ${D}${bindir}/ntpdate-sync
> sed -i 's!/etc/!${sysconfdir}/!g' ${D}${sysconfdir}/init.d/ntpd 
> ${D}${bindir}/ntpdate-sync
> sed -i 's!/var/!${localstatedir}/!g' ${D}${sysconfdir}/init.d/ntpd 
> ${D}${bindir}/ntpdate-sync
> sed -i 
> 's!^PATH=.*!PATH=${base_sbindir}:${base_bindir}:${sbindir}:${bindir}!' 
> ${D}${bindir}/ntpdate-sync
> sed -i '1s,#!.*perl -w,#! ${bindir}/env perl,' ${D}${sbindir}/ntptrace
> sed -i '/use/i use warnings;' ${D}${sbindir}/ntptrace
> sed -i '1s,#!.*perl,#! ${bindir}/env perl,' ${D}${sbindir}/ntp-wait
> sed -i '/use/i use warnings;' ${D}${sbindir}/ntp-wait
> sed -i '1s,#!.*perl -w,#! ${bindir}/env perl,' ${D}${sbindir}/calc_tickadj
> sed -i '/use/i use warnings;' ${D}${sbindir}/calc_tickadj
>
> install -d ${D}/${sysconfdir}/default
> install -m 644 ${WORKDIR}/ntpdate.default 
> ${D}${sysconfdir}/default/ntpdate
> install -m 0644 ${WORKDIR}/sntp ${D}${sysconfdir}/default/
>
> install 

Re: [linux-yocto] how to add recipe-sysroot-native to PKG_CONFIG_PATH for linux-yocto

[Alexander Kanavin]

You probably need to add a dependency on glib-2.0 to your recipe, then
the needed pkgconfig will be in the target sysroot.

If you can copy-paste the entire recipe, that would help.

Alex

On Tue, 14 May 2019 at 11:06, Tong Chen  wrote:
>
> Hi all:
> I'm adding some kernel extensions to poky. In summary, I need to extend 
> kallsyms, and the new functionality depends on glib-2.0.
> So I added pkg-confi in the ./scripts/Makefile:
>
> HOSTCFLAGS_kallsyms.o := $(shell pkg-config --cflags glib-2.0) 
> -I$(srctree)/scripts
> HOSTLDLIBS_kallsyms := $(shell pkg-config --libs glib-2.0) -ldw
>
> But when compiling with bitbake, the following error occurs:
>
> | Package glib-2.0 was not found in the pkg-config search path.
> | Perhaps you should add the directory containing `glib-2.0.pc'
> | to the PKG_CONFIG_PATH environment variable
> | No package 'glib-2.0' found
>
> Extrat the setting of PKG_CONFIG_PATH from temp/run.do_compile:
>
> Export 
> PKG_CONFIG_PATH="/home/hchan/code/poky_new/poky/build_ctd/tmp/work/qemux86_64-poky-linux/linux-yocto/5.0.7+gitAUTOINC+d26eec23cf_891531d68e-r0/recipe-sysroot/usr/lib/pkgconfig
>  
> :/home/hchan/code/poky_new/poky/build_ctd/tmp/work/qemux86_64-poky-linux/linux-yocto/5.0.7+gitAUTOINC+d26eec23cf_891531d68e-r0/recipe-sysroot/usr/share/pkgconfig"
>
> Look at the recipe-sysroot directory, where there is no corresponding 
> glib-2.0.pc file, but in the recipe-sysroot-native directory, there is:
>
> ./recipe-sysroot-native/usr/lib/pkgconfig/glib-2.0.pc
>
> So my question is how to insert recipe-sysroot-native directory to 
> PKG_CONFIG_PATH variable?
>
> I am not particularly familiar with poky/bitbake at the moment. By searching, 
> I found these assignments. But not sure where to add it, and how to add:
>
> Hchan@hchan-ThinkPad:~/code/poky_new/poky$ grep --color -rnH 'export 
> PKG_CONFIG_PATH=' ./meta*
> ./meta/recipes-devtools/pkgconfig/pkgconfig/pkg-config-native.in:3:export 
> PKG_CONFIG_PATH="@PATH_NATIVE@"
> ./meta/recipes-devtools/qemu/qemu.inc:85: export 
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$BHOST_PKGCONFIG_PATH
> ./meta/classes/toolchain-scripts.bbclass:49: echo 'export 
> PKG_CONFIG_PATH=$SDKTARGETSYSROOT'"$libdir"'/pkgconfig:$SDKTARGETSYSROOT'"$prefix"'/share/pkgconfig'
>  >> $script
> ./meta/classes/toolchain-scripts.bbclass:72: echo 'export 
> PKG_CONFIG_PATH=${PKG_CONFIG_PATH}' >> $script
>
> --
> Tom
>
> --
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] [meta-mono][PATCH] mono-5.xx: fix an issue with too long paths in doltlibtool

[Alexander Kanavin]

When build directory is deeply nested, the shebang limit of 127
characters is hit, which leads to doltlibtool failing to execute.

Signed-off-by: Alexander Kanavin 
---
 recipes-mono/mono/mono-5.xx.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/recipes-mono/mono/mono-5.xx.inc b/recipes-mono/mono/mono-5.xx.inc
index c36374c..dec2475 100644
--- a/recipes-mono/mono/mono-5.xx.inc
+++ b/recipes-mono/mono/mono-5.xx.inc
@@ -102,3 +102,7 @@ RDEPENDS_${PN} =+ "bash"
 
 # Workaround for observed race in `make install`
 PARALLEL_MAKEINST=""
+
+# Otherwise the full path to bash is written to the first line of doltlibtool 
script
+# which causes build failures with deeply nested build directories
+CACHED_CONFIGUREVARS += "ac_cv_path_DOLT_BASH='/usr/bin/env bash'"
-- 
2.17.1

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

[yocto] [meta-security][PATCH] apparmor: fetch from git

[Alexander Kanavin]

Tarballs from archive.ubuntu.com can and do disappear (similar to 
archive.debian.org).

Signed-off-by: Alexander Kanavin 
---
 recipes-mac/AppArmor/apparmor_2.13.2.bb | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-mac/AppArmor/apparmor_2.13.2.bb 
b/recipes-mac/AppArmor/apparmor_2.13.2.bb
index 62ed611..4eaec00 100644
--- a/recipes-mac/AppArmor/apparmor_2.13.2.bb
+++ b/recipes-mac/AppArmor/apparmor_2.13.2.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = 
"file://${S}/LICENSE;md5=fd57a4b0bc782d7b80fd431f10bbf9d0"
 DEPENDS = "bison-native apr gettext-native coreutils-native"
 
 SRC_URI = " \
-   
http://archive.ubuntu.com/ubuntu/pool/main/a/${BPN}/${BPN}_${PV}.orig.tar.gz \
+   
git://gitlab.com/apparmor/apparmor.git;protocol=https;branch=apparmor-2.13 \
file://disable_perl_h_check.patch \
file://crosscompile_perl_bindings.patch \
file://apparmor.rc \
@@ -24,8 +24,8 @@ SRC_URI = " \
file://run-ptest \
"
 
-SRC_URI[md5sum] = "2439b35266b5a3a461b0a2dba6e863c3"
-SRC_URI[sha256sum] = 
"844def9926dfda5c7858428d06e44afc80573f9706458b6e7282edbb40b11a30"
+SRCREV = "af4808b5f6b58946f5c5a4de4b77df5e0eae6ca0"
+S = "${WORKDIR}/git"
 
 PARALLEL_MAKE = ""
 
-- 
2.17.1

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

Re: [yocto] Multiple MACHINEs and DISTROs: When to use own build dir, SSTATE_DIR, DL_DIR ?

[Alexander Kanavin]

SSTATE_DIR and DL_DIR can (and should) be shared between all builds.

Each MACHINE/DISTRO combination works best with it's own build_dir.

Alex

On Thu, 9 May 2019 at 11:47, Fabian Knapp  wrote:

>
> Hello,
>
> we have multiple MACHINEs and DISTROs and Im wondering for which
> combinations I have to setup a dedicated build dir, SSTATE_DIR and DL_DIR.
>
> Information in the form of:
>
> Each (change of) MACHINE needs its dedicated SSTATE_DIR and build dir but
> can share DL_DIR.
>
> would be very helpful for me.
>
> Thank you in advance.
>
> Fabian
>
> [image: Visit us at EES Europe] 
> --
> ___
> 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] Eclipse (plugin, settings)

[Alexander Kanavin]

Nevertheless, you are welcome to resurrect the plugin, if you are
willing to do the maintenance work. Yocto is what you make it.

Alex

On Wed, 8 May 2019 at 15:37, Zoran Stojsavljevic
 wrote:
>
> https://marc.info/?l=openembedded-core=155482339222316=2
>
> (do not shoot the messenger, thank you)
>
> Zoran
> ___
>
> On Wed, May 8, 2019 at 1:11 PM Arno Steffens  wrote:
> >
> > I want to use Eclipse as IDE for coding/debugging.
> > What do I have to set to get the proper compiler prefixes and pathes, libs 
> > and includes ?
> > Or any way to combine the environment setup with start of eclipse?
> >
> > I have seen there was a Eclipse plugin, but not for newer versions as 
> > 2019.03.
> >
> > Here (https://www.yoctoproject.org/software-item/eclipse-ide-plug-in/) is 
> > referenced to the eSDK manual, but no word about eclipse in it. Til now I 
> > just use SDK.
> >
> > Thanks
> > Arno
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Changing IMAGE_NAME [yocto krogoth]

[Alexander Kanavin]

You need to use vardepsexclude (read in the bitbake manual how to).

Generally I am not a fan of putting timestamps into anything
yocto-built, it's prone to issues like this, breaks reproducibility,
and also subverts sstate if not managed carefully. I'd almost suggest
you build the image with a default name, and then rename it after the
fact when deploying to some artefact storage.

Alex

On Thu, 11 Apr 2019 at 11:30, Mauro Ziliani  wrote:
>
> Thanks
>
> It was a typing error.
>
> In my recipe I set the value as you told me.
>
> But the ERROR keep on show
>
>
> Il 10/04/19 11:59, mikko.rap...@bmw.de ha scritto:
> > On Wed, Apr 10, 2019 at 11:47:42AM +0200, Mauro Ziliani wrote:
> >> Hi all.
> >>
> >> I need to change the default IMAGE_NAME of my image recipe.
> >>
> >> I make my image recipe as mysystem-image_1.0.bb and I'd like to produce
> >> and image (tar) with the name
> >>
> >> mysystem-image-1.0-.tar
> >>
> >>
> >> So I setup
> >>
> >> IMAGE_NAME := "{IMAGE_BASENAME}-${PV}-${DATETIME}"
> > Should be:
> >
> > IMAGE_NAME := "${IMAGE_BASENAME}-${PV}-${DATETIME}"
> >
> > note the added $. I guess that's the bit which confuses bitbake. Been 
> > there, done that
> > too :)
> >
> > Hope this helps,
> >
> > -Mikko
> --
> ___
> 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] dhcp and avahi package addition to image

[Alexander Kanavin]

Most likely neither of these recipes actually provides a package named
'dhcp' or 'avahi'. Run 'bitbake -e avahi' and look for the PACKAGES
variable in the output, that would tell you the actual package names
that you can add to the image.

Alex

On Tue, 9 Apr 2019 at 16:16, Pandey, Kamal  wrote:
>
> Hello,
>
>
>
> I was trying to add avahi and dhcp  to my image. While running $bitbake dhcp 
> avahi, everything is working fine but when I add these packages to 
> packagegroup  or directly to the image recipe using EXTRA_IMAGE_INSTALL or 
> IMAGE_INSTALL_append. It starts giving error.
>
> The error  for avahi is shown below:
>
> ERROR: core-image-special-pdm3-1.0-r0 do_rootfs: Could not invoke dnf. 
> Command 
> '/home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/recipe-sysroot-native/usr/bin/dnf
>  -y -c 
> /home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/rootfs/etc/dnf/dnf.conf
>  
> --setopt=reposdir=/home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/rootfs/etc/yum.repos.d
>  
> --repofrompath=oe-repo,/home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/oe-rootfs-repo
>  
> --installroot=/home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/rootfs
>  
> --setopt=logdir=/home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/temp
>  --nogpgcheck install packagegroup-pdm3-apps packagegroup-pdm3-qt 
> packagegroup-core-tools-debug packagegroup-core-boot packagegroup-core-x11 
> packagegroup-pdm3-base packagegroup-core-tools-profile 
> packagegroup-pdm3-fonts base-passwd packagegroup-core-ssh-openssh shadow 
> run-postinsts kernel-image-fitimage-4.14.79-yocto-standard' returned 1:
>
> Added oe-repo repo from 
> /home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/oe-rootfs-repo
>
> Last metadata expiration check: 0:00:00 ago on Tue 09 Apr 2019 01:49:20 PM 
> UTC.
>
> Error:
>
> Problem: conflicting requests
>
>   - nothing provides avahi needed by packagegroup-pdm3-apps-1.0-r1.noarch
>
>
>
> ERROR: core-image-special-pdm3-1.0-r0 do_rootfs: Function failed: do_rootfs
>
> ERROR: Logfile of failure stored in: 
> /home/iepl007/yocto_build/build_dir/tmp/work/pdm3_zynqmp-pdm3-linux/core-image-special-pdm3/1.0-r0/temp/log.do_rootfs.12565
>
> ERROR: Task 
> (/home/iepl007/yocto_build/poky/../meta-pdm3-dev/meta-ifm-pdm3/recipes-core/images/core-image-special-pdm3.bb:do_rootfs)
>  failed with exit code '1'
>
>
>
>
>
> And the error for dhcp is shown below:
>
>
>
>
>
> ERROR: Nothing RPROVIDES 'dhcp' (but 
> /home/iepl007/yocto_build/poky/../meta-pdm3-dev/meta-ifm-pdm3/recipes-core/packagegroups/packagegroup-pdm3-app.bb
>  RDEPENDS on or otherwise requires it)
>
> NOTE: Runtime target 'dhcp' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['dhcp']
>
> NOTE: Runtime target 'packagegroup-pdm3-apps' is unbuildable, removing...
>
> Missing or unbuildable dependency chain was: ['packagegroup-pdm3-apps', 
> 'dhcp']
>
> ERROR: Required build target 'pdm3-special-swuimage' has no buildable 
> providers.
>
> Missing or unbuildable dependency chain was: ['pdm3-special-swuimage', 
> 'core-image-special-pdm3', 'packagegroup-pdm3-apps', 'dhcp']
>
>
>
> Please provide a solution for this I don’t want to clean my sstate-cache or 
> the tmp directory. I am ready to debug the corrupted sstate if someone is 
> experienced with sstate-cache.
>
> Thanks
>
> Kamal Pandey
>
> --
> ___
> 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] QA cycle report for 2.7 M3 RC1

[Alexander Kanavin]

On Tue, 2 Apr 2019 at 20:33,  wrote:
> > [15] Bug 13257 - [2.7 M3 rc1] python3 ptest facing timeout issue
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13257
>
> I'm hoping a patch from Ross in master fixes this, need to retest ptest
> with this applied.

Sadly I have narrowed this down to the 5.0 kernel update. More
information in the bug, would be good to have this independently
confirmed. Updating python to 3.7.3 does not help.

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

[yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering

[Alexander Kanavin]

As ptest-runner communicates with child processes via pipe2(),
the corresponding channels are not attached to a pty. In that
situation stdio facilities like printf() or fwrite() are fully
buffered. If a ptest would use them, without bothering
to fflush() the output, ptest-runner will only receive what
was written by the child ptest process after a buffer gets filled.
If the unit tests are proceeding slowly, this may mean that
ptest-runner will erroneously timeout due to an apparent lack of
'signs of life' from the child process.

stdbuf utility from coreutils adjusts the buffering to a line-buffered
one, and so ptest-runner will get the lines as soon as they are
written.

Signed-off-by: Alexander Kanavin 
---
 utils.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/utils.c b/utils.c
index 504df0b..1376e39 100644
--- a/utils.c
+++ b/utils.c
@@ -243,16 +243,13 @@ filter_ptests(struct ptest_list *head, char **ptests, int 
ptest_num)
 static inline void
 run_child(char *run_ptest, int fd_stdout, int fd_stderr)
 {
-   char **argv = malloc(sizeof(char) * 2);
+   char* argv[] = {"stdbuf", "-oL", "-eL", "./run-ptest", NULL};
chdir(dirname(strdup(run_ptest)));
 
-   argv[0] = run_ptest;
-   argv[1] = NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
-   execv(run_ptest, argv);
+   execvp(argv[0], argv);
 
exit(1);
 }
-- 
2.17.1

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

Re: [yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering

[Alexander Kanavin]

Bah, sorry, debugging got into the patch.

Will resend.

Alex

On Thu, 4 Apr 2019 at 17:34, Alexander Kanavin  wrote:
>
> As ptest-runner communicates with child processes via pipe2(),
> the corresponding channels are not attached to a pty. In that
> situation stdio facilities like printf() or fwrite() are fully
> buffered. If a ptest would use them, without bothering
> to fflush() the output, ptest-runner will only receive what
> was written by the child ptest process after a buffer gets filled.
> If the unit tests are proceeding slowly, this may mean that
> ptest-runner will erroneously timeout due to an apparent lack of
> 'signs of life' from the child process.
>
> stdbuf utility from coreutils adjusts the buffering to a line-buffered
> one, and so ptest-runner will get the lines as soon as they are
> written.
>
> Signed-off-by: Alexander Kanavin 
> ---
>  utils.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/utils.c b/utils.c
> index 504df0b..c130fbd 100644
> --- a/utils.c
> +++ b/utils.c
> @@ -243,16 +243,13 @@ filter_ptests(struct ptest_list *head, char **ptests, 
> int ptest_num)
>  static inline void
>  run_child(char *run_ptest, int fd_stdout, int fd_stderr)
>  {
> -   char **argv = malloc(sizeof(char) * 2);
> +   char* argv[] = {"stdbuf", "-oL", "-eL", "./run-ptest", NULL};
> chdir(dirname(strdup(run_ptest)));
>
> -   argv[0] = run_ptest;
> -   argv[1] = NULL;
> -
> dup2(fd_stdout, STDOUT_FILENO);
> // XXX: Redirect stderr to stdout to avoid buffer ordering problems.
> dup2(fd_stdout, STDERR_FILENO);
> -   execv(run_ptest, argv);
> +   execvp(argv[0], argv);
>
> exit(1);
>  }
> @@ -291,12 +288,12 @@ wait_child(const char *ptest_dir, const char 
> *run_ptest, pid_t pid,
>
> if (pfds[0].revents != 0) {
> while ((n = read(fds[0], buf, 
> WAIT_CHILD_BUF_MAX_SIZE)) > 0)
> -   fwrite(buf, n, 1, fps[0]);
> +   fwrite(buf, n, 1, fps[0]); 
> fwrite("hallo", 5 ,1 ,fps[0]); fflush(fps[0]);
> }
>
> if (pfds[1].revents != 0) {
> while ((n = read(fds[1], buf, 
> WAIT_CHILD_BUF_MAX_SIZE)) > 0)
> -   fwrite(buf, n, 1, fps[1]);
> +   fwrite(buf, n, 1, fps[1]); 
> fwrite("hallo-err", 9 ,1 ,fps[0]); fflush(fps[1]);
> }
>
> clock_gettime(clock, );
> --
> 2.17.1
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [ptest-runner] Run ptests via stdbuf configured to line-buffering

[Alexander Kanavin]

As ptest-runner communicates with child processes via pipe2(),
the corresponding channels are not attached to a pty. In that
situation stdio facilities like printf() or fwrite() are fully
buffered. If a ptest would use them, without bothering
to fflush() the output, ptest-runner will only receive what
was written by the child ptest process after a buffer gets filled.
If the unit tests are proceeding slowly, this may mean that
ptest-runner will erroneously timeout due to an apparent lack of
'signs of life' from the child process.

stdbuf utility from coreutils adjusts the buffering to a line-buffered
one, and so ptest-runner will get the lines as soon as they are
written.

Signed-off-by: Alexander Kanavin 
---
 utils.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/utils.c b/utils.c
index 504df0b..c130fbd 100644
--- a/utils.c
+++ b/utils.c
@@ -243,16 +243,13 @@ filter_ptests(struct ptest_list *head, char **ptests, int 
ptest_num)
 static inline void
 run_child(char *run_ptest, int fd_stdout, int fd_stderr)
 {
-   char **argv = malloc(sizeof(char) * 2);
+   char* argv[] = {"stdbuf", "-oL", "-eL", "./run-ptest", NULL};
chdir(dirname(strdup(run_ptest)));
 
-   argv[0] = run_ptest;
-   argv[1] = NULL;
-
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
-   execv(run_ptest, argv);
+   execvp(argv[0], argv);
 
exit(1);
 }
@@ -291,12 +288,12 @@ wait_child(const char *ptest_dir, const char *run_ptest, 
pid_t pid,
 
if (pfds[0].revents != 0) {
while ((n = read(fds[0], buf, 
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
-   fwrite(buf, n, 1, fps[0]);
+   fwrite(buf, n, 1, fps[0]); 
fwrite("hallo", 5 ,1 ,fps[0]); fflush(fps[0]);
}
 
if (pfds[1].revents != 0) {
while ((n = read(fds[1], buf, 
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
-   fwrite(buf, n, 1, fps[1]);
+   fwrite(buf, n, 1, fps[1]); 
fwrite("hallo-err", 9 ,1 ,fps[0]); fflush(fps[1]);
}
 
clock_gettime(clock, );
-- 
2.17.1

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

Re: [yocto] [OE-core] [oe] Git commit process question.

[Alexander Kanavin]

On Thu, 4 Apr 2019 at 02:39, Khem Raj  wrote:
> Definitely, and I agree that we should put relevant information in
> commits, usually
> the information about side effects if any, links to changelog etc. are
> useful too
> however, we should not enforce a behavior which could result in
> redundancy as explained

To be honest, researching changelogs and summarizing them into commit
messages is feasible if you maintain maybe three recipes. When you
maintain thirty, it becomes a burden, and I am not going to take that
burden. There's already enough work in getting the upgrade into
working shape, work that largely goes unnoticed and unappreciated and
does not require finding and reading upstream changelogs.

HOWEVER. I think we could start putting links to changelogs into the
recipes themselves. If it's a webpage, we can use templating to
substitute version numbers, if it's a file in the source tree, we can
also come up with a format for that. Then it's a simple extension to
e.g. devtool to show that changelog via less or a browser.

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

Re: [yocto] [OE-core] [oe] Git commit process question.

[Alexander Kanavin]

Just to make clear, the AUH workflow does require the maintainer to
sign off and edit a commit message via 'git commit -s --reset-author
--amend' for every commit, so AUH does not get in the way of useful
commit messages.

Alex

On Wed, 3 Apr 2019 at 12:31, Burton, Ross  wrote:
>
> On Tue, 2 Apr 2019 at 20:46, Tom Rini  wrote:
> > > The kernel does not have "upgrade foo to the latest upstream version" 
> > > commits.
> > >
> > > With the Automatic Upgrade Helper this is a semi-automatic task, and
> > > most of the time there is no specific motivation other than upgrading
> > > to the latest upstream version.
> >
> > But since that's just filling in a template the body can also be a
> > template perhaps with useful AUH data (run at ... by ... ?) ?
>
> Apart from making the commit message longer what does this achieve?
> The commit already has a timestamp and author.
>
> Ross
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image introspection

[Alexander Kanavin]

DISTRO_FEATURES_DEFAULT is set using ?= :

DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth ext2 ipv4 ipv6
irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g
nfc x11"

So you can override it by setting it using =, which is also a chance
to trim other unnecessary features.

Alex

On Fri, 29 Mar 2019 at 10:50, Dimitris Tassopoulos  wrote:
>
> Hi Alexander,
>
> in this case the 3g is added by default from the poky distro in
> the DISTRO_FEATURES_DEFAULT var in:
> meta/conf/distro/include/default-distrovars.inc
>
> And because the poky distro is the base distro for the image
> this is inherited. Therefore it needs to be removed with the
> DISTRO_FEATURES_remove unless there is another way,
> which I'm not aware to easily remove/adjust without having
> to create a new distro.
>
> Regards,
> Dimitris
>
> On Fri, Mar 29, 2019 at 10:38 AM Alexander Kanavin  
> wrote:
>>
>> You can do that using
>>
>> bitbake -e  and looking for how DISTRO_FEATURES is formed in
>> the output of the command.
>>
>> Alex
>>
>> On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin  
>> wrote:
>> >
>> > On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos  
>> > wrote:
>> >
>> > > To do that, add this to your build/conf/local.conf file
>> > >
>> > >> DISTRO_FEATURES_remove = " 3g"
>> >
>> > This works around the issue after the fact. It's better to track down
>> > where 3g is added in the first place, and adjust that.
>> >
>> > Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image introspection

[Alexander Kanavin]

You can do that using

bitbake -e  and looking for how DISTRO_FEATURES is formed in
the output of the command.

Alex

On Fri, 29 Mar 2019 at 10:37, Alexander Kanavin  wrote:
>
> On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos  wrote:
>
> > To do that, add this to your build/conf/local.conf file
> >
> >> DISTRO_FEATURES_remove = " 3g"
>
> This works around the issue after the fact. It's better to track down
> where 3g is added in the first place, and adjust that.
>
> Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image introspection

[Alexander Kanavin]

On Fri, 29 Mar 2019 at 09:51, Dimitris Tassopoulos  wrote:

> To do that, add this to your build/conf/local.conf file
>
>> DISTRO_FEATURES_remove = " 3g"

This works around the issue after the fact. It's better to track down
where 3g is added in the first place, and adjust that.

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

Re: [yocto] How to produce Release.gpg

[Alexander Kanavin]

On Mon, 18 Mar 2019 at 08:14, Mauro Ziliani  wrote:
> Is it possible to sign Release automatically from bitbake?

At the moment signing deb repositories is not supported (but it is
supported for rpm and opkg).
You are welcome to add the missing support,
meta/lib/oe/package_manager.py is where it happens.

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

Re: [yocto] [thud]: Issues with git sub modules

[Alexander Kanavin]

Yocto master has got a lot of fixing around gitsm fetcher
(particularly creation of symlinks seems to be gone), so if you could
try that and report, that would be appreciated.

Alex

On Wed, 6 Mar 2019 at 15:20, philippe gislard
 wrote:
>
> Hello everyone,
>
> Our use case is the following:
> - We are building firmwares using yocto on machines that have no internet 
> access
> - We have a mirror that we are feeding with tarballs generated by a
> machine connected to internet
> - We want to port our BSP to yocto thud
>
> Until now (we used krogoth) our mirror was operating properly.
>
> Since we switched to thud, the build systems is generating tarballs of
> git repositories (i.e.: gstreamer1.0-plugins-good_1.14.imx.bb, from
> freescale) containing symbolic links to git submodules (gstreamer
> common).
> The issue is that these symbolic links contain an absolute path which
> is not portable on other machines.
>
> We fixed it by patching the yocto framework so it generates a relative
> symbolic link instead.
>
> _We want to be sure is that is the proper way to fix the issue we are
> facing for our use case_
>
> You will find the patch we used at the end of this mail.
>
> Thank you.
>
> From 456bc347c38039006619c0e95831cb4faf4d8c49 Mon Sep 17 00:00:00 2001
> From: Philippe GISLARD 
> Date: Wed, 6 Mar 2019 10:03:43 +0100
> Subject: [PATCH] Change the git submodule symbolic link from absolute to
>  relative in order to allow sharing the downloaded packages between different
>  build machines
>
> Signed-off-by: Philippe GISLARD 
> Signed-off-by: Fabien MICAELLI 
> ---
>  bitbake/lib/bb/fetch2/gitsm.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
> index 35729db..009b2af 100644
> --- a/bitbake/lib/bb/fetch2/gitsm.py
> +++ b/bitbake/lib/bb/fetch2/gitsm.py
> @@ -119,7 +119,7 @@ class GitSM(Git):
>  os.makedirs(os.path.dirname(symlink_path), exist_ok=True)
>  except OSError:
>  pass
> -os.symlink(local_paths[module], symlink_path)
> +os.symlink(os.path.relpath(local_paths[module],
> os.path.dirname(symlink_path)), symlink_path)
>
>  return True
>
> --
> 2.7.4
>
> --
> Philippe GISLARD
> --
> ___
> 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] using git am to apply git patch in the workdir of any package+

[Alexander Kanavin]

The supported recommended workflow for this things is with devtool.

Please try especially 'devtool modify' and 'devtool upgrade'. The latter
will rebase patches for you, regardless of how they were made.

Alex

On Wed, 6 Mar 2019 at 15:18, Pandey, Kamal  wrote:

> Hello,
>
> I am trying to modify the src code of a package named say x,
>
> For this I type the command $bitbake x –c devshell.
>
> This leads me to the git repo of the x package(if it is a git repo).
>
> Now I do my changes, commit the changes, and create a patch out of it
> using git format-patch.
>
> Now I want this git patch to be applied via git am  whenever I run bitbake
> x.
>
> In some packages the patch is applied via git am for example
> linux-yocto-%.bb, but in some cases the patch is not being applied via git
> am for example u-boot%.bb
>
> Is there any setting in bitbake to apply git patches via git am so that it
> is easy to modify the older patches via rebase commands, or we have to
> create new patch every time for a small change and the later patches will
> have dependency on older patches.
>
>
>
>
>
> Best Regards
>
> Kamal Pandey
>
> Junior Software Engineer
>
> [image: ifm_logo_sqrs]ifm engineering pvt. ltd.
>
> Survey No. 1/10/16, 3rd floor, Above SBI, Bavdhan Branch, N.D.A. Road,
> Bavdhan, Pune, India - 411021 | Web: www.ifm.com | Phone: +91-20-22951910
> Extn:215 | CIN: U29213PN2010FTC13676
>
>
> --
> ___
> 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] Newbie questions on cross-building packages for PPC

[Alexander Kanavin]

On Sat, 23 Feb 2019 at 22:18, Philip Prindeville
 wrote:
> I’ve worked on a lot of embedded projects involving cross-building (like 
> AstLinux and OpenWrt), but I’m new to Yocto so please bear with the noob 
> questions.
>
> I’d like to build packages (mostly RPM’s, plus a Linux kernel or three) on an 
> x86_64 (AMD64) Linux (CentOS 7.6) platform, but for e500v2 and 85xxDP PPC 
> targets.
>
> What do I need to do to set up a toolchain and environment to be able to do 
> that?

First, you need to figure out which BSP layer provides support for
your targets. What boards are you targeting?

> Ideally, I’d also like to set up an RPM target so I could use “rpmbuild 
> --target e500v2-unknown-linux” (or whatever) and it would use the correct 
> compiler, linker, archiver, sysheaders, etc.
>
> Advice on both of these, or just pointers to instructions on how to set it 
> all up, would be great.

I'd suggest you start with the yocto quickstart guide, so you'll know
the basic procedures.
https://www.yoctoproject.org/docs/latest/brief-yoctoprojectqs/brief-yoctoprojectqs.html

> For instance, do I need one compiler only that can handle multiple processor 
> variants via the --march= flag, or is this not the right way to go?  And 
> similarly, since the linker can rewrite code (shortening branch offsets, 
> peep-hole optimization, unreachable code removal, etc.) do I need different 
> linker versions for the 2 PPC variants?

This is what BSP layers do, they define a target machine (which
includes compiler and linker settings), and give it a name. Then you
place that name in your configuration file, and the target build
process will sort itself out.

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

Re: [yocto] [meta-mingw][PATCH] diffutils: Upgrade to 3.7

[Alexander Kanavin]

On Wed, 20 Feb 2019 at 19:08, Joshua Watt  wrote:
>  .../diffutils/diffutils/sdiff-no-kill.patch   | 32 ---
>  .../diffutils/diffutils_3.6.bbappend  | 18 ---
>  .../diffutils/diffutils_3.7.bbappend  | 14 

Should this be called simply diffutils_%.bbappend ?
This way things won't suddenly break when oe-core gets a new version.
(a possible resulting build failure is better than a certain parsing
failure imo)

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

Re: [yocto] Add cmd.py library for python-core package

[Alexander Kanavin]

On Wed, 20 Feb 2019 at 12:25, Piotr Piwko  wrote:
> I would like to add cmd.py library to my final image. In order to do
> so I modified python2-manifest.json file from poky delivery.
>
> This solution works fine. However, is there any possibility to do not
> change the global poky/python2-manifest,json file and get the same
> result? I would like to provide this library only for particular image
> not for all my supported ones. I tried to put new manifest file in
> upper layers of my meta, but it seems to not be taken into
> consideration by python recipe.

I'm not sure why you had to modify the manifest, as cmd.py is provided
by python-shell package according to the manifest. If you show your
changes, it may be easier to understand the issue.

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

Re: [yocto] QEMU Raspberry Pi 2 machine

[Alexander Kanavin]

You can just use a qemux86-64 target, which is much faster because it
executes directly on the hardware. What's the need to emulate
specifically arm?

Alex

On Mon, 18 Feb 2019 at 19:34, Jean-Christian de Rivaz
 wrote:
>
> Hi,
>
> The chromium-x11 browser can't be compiled for the qemuarm machine because it 
> use the old ARM926 processor. I have modified the qemuarm.conf file  inside 
> poky/meta/conf/machine/ to add
> DEFAULTTUNE ?= "cortexa7thf-neon-vfpv4"
> require conf/machine/include/tune-cortexa7.inc
> But I want to avoid patching files of the poky project. Is there a proper way 
> to add a QEMU Raspberry Pi 2 target like qemuraspi2 for example ? It look 
> like many recipe files contains specific part for qemuarm so I wonder if 
> adding a new QEMU machine it a simple enough task.
>
> Best Regards,
> Jean-Christian de Rivaz
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Alexander Kanavin]

I think it looks right now, thanks :)

Alex

On Thu, 14 Feb 2019 at 10:13, Michael Halstead
 wrote:
>
> The regular 3 hour update wasn't installed on the new server. I have
> repaired that and added the RRS updates as well..
>
> The update has been run several times in testing and I'm curious if RRS
> has caught up as expected.
>
> On 2/12/19 5:57 PM, Paul Eggleton wrote:
> > Hi Alex
> >
> > On Wednesday, 13 February 2019 6:22:23 AM NZDT Alexander Kanavin wrote:
> >> On Tue, 12 Feb 2019 at 17:10,  wrote:
> >>> The recipe reporting system integration with the layer index is available
> >>> at: https://layers.openembedded.org/rrs/recipes/OE-Core/2.7/M3/ and the
> >>> historical data has now been imported.
> >> Sadly the new RRS still seems to be suffering from the 'outdated info'
> >> problem. For example glibc, or python3 recipes have been updated to
> >> latest versions, yet RRS still shows that they haven't been.
> > We're reliant upon the layer index updating and it appears that's not 
> > working
> > at the moment. I have asked Michael to look into it. Thanks for the report,
> > I'll reply back here when things are sorted out.
> >
> > Cheers,
> > Paul
> >
> --
> Michael Halstead
> Linux Foundation / SysAdmin
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Alexander Kanavin]

On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich  wrote:
> Hi, I've been struggling a bit with this question. I want to use Yocto to 
> build two+ products with separate dev/prod images for each (dev including 
> debug-tweaks, etc.). I've ruled out separate image recipes because my dev 
> builds need ENABLE_UART on my RaspberryPi and that needs to be set at the 
> conf level (I've got it set conditionally in my base dist conf). Multiconfig 
> looked promising, but I'm not happy about how long the parsing takes to start 
> a build. "--postread" looked nice, but I've barely seen it mentioned so I'm 
> worried that it's not well supported.
>

Which recipes use the ENABLE_UART setting? You might want to write two
variants of those, and include them into images accordingly.

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

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

[Alexander Kanavin]

On Tue, 12 Feb 2019 at 17:10,  wrote:
> The recipe reporting system integration with the layer index is available at: 
> https://layers.openembedded.org/rrs/recipes/OE-Core/2.7/M3/ and the 
> historical data has now been imported.

Sadly the new RRS still seems to be suffering from the 'outdated info'
problem. For example glibc, or python3 recipes have been updated to
latest versions, yet RRS still shows that they haven't been.

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

Re: [yocto] Intentionally failing postinstall scriplets - Yocto Sumo

[Alexander Kanavin]

You need to inspect the rootfs log, to find out precisely why they are
failing. Placing things into _ontarget() is only a part of the instruction,
and applicable only when postinsts have a genuine need to be executed on
the target device. I think your situation is explained by this:

If deferring to first boot wasn't the intent, then scriptlet failure
may mean an issue in the recipe, or a regression elsewhere.

Details of the failure are in
/home/build_arm-cortex-a8/tmp/work/arm_cortex_a8-poky-linux-gnueabi/custom-image/1.0-r0/temp/log.do_rootfs.


Alex

On Tue, 12 Feb 2019 at 11:11, Dhanush K.S  wrote:

> Hello,
>
> Building an image with Yocto Sumo throws out some warning messages during
> do.rootfs. Although I'm partially clear that update-alternatives has
> something to do with these warnings, but following the instructions in the
> warning and placing the packages in pkg_postinst_ontarget_${PN} () does
> not resolve the issue.
>
> What am I missing here and what is the ideal solution to avoid these
> warnings?
>
> Here is my *BUILD INFORMATION*
>
> Build Configuration:
> BB_VERSION   = "1.37.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal-4.8"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "arm-cortex-a8"
> DISTRO   = "poky"
> DISTRO_VERSION   = "2.5"
> TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU   = "hard"
> meta-custombsp-ti
> meta
> meta-poky
> meta-yocto-bsp
> meta-custom-common  = ":"
> meta-oe  = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
>
>
> WARNING: custom-image-1.0-r0 do_rootfs: Intentionally failing postinstall 
> scriptlets of ['vsftpd', 'dropbear', 'chrony'] to defer them to first boot is 
> deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>
> If deferring to first boot wasn't the intent, then scriptlet failure may mean 
> an issue in the recipe, or a regression elsewhere.
>
> Details of the failure are in 
> /home/build_arm-cortex-a8/tmp/work/arm_cortex_a8-poky-linux-gnueabi/custom-image/1.0-r0/temp/log.do_rootfs.
>
> WARNING: custom-image-1.0-r0 do_rootfs: [log_check] abkdkj-image: found 4 
> warning messages in the logfile:
>
> [log_check] warning: %post(vsftpd-3.0.3-r0.cortexa8hf_neon) scriptlet failed, 
> exit status 1
>
> [log_check] warning: %post(dropbear-2017.75-r0.cortexa8hf_neon) scriptlet 
> failed, exit status 1
>
> [log_check] warning: %post(chrony-3.1-r0.cortexa8hf_neon) scriptlet failed, 
> exit status 1
>
> [log_check] WARNING: Intentionally failing postinstall scriptlets of 
> ['vsftpd', 'dropbear', 'chrony'] to defer them to first boot is deprecated. 
> Please place them into pkg_postinst_ontarget_${PN} ().
>
>
>
> Thanks,
>
> Dhanush
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] u-boot: update commit id to the latest one of u-boot upstream

[Alexander Kanavin]

On Mon, 28 Jan 2019 at 11:20,  wrote:
> There are 2 CVE issues fixing in latest u-boot upstream, so
> update commit id to involve these fixing patches.

We generally don't update commit id's to something random, as that
means picking a source tree in the middle of a development cycle. If
you want to update a component, please use a commit that has a version
tag attached to it.

Also, the patch needs to go to oe-core mailing list.

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

Re: [yocto] dnf fail in do_rootfs cannot find shared library

[Alexander Kanavin]

One more thing: can you provide the .spec file that is generated
during build and used to create .rpm packages? You will find it under
tmp/work//x_media/

Please try not to edit anything out of it.

Alex

On Wed, 23 Jan 2019 at 12:02, Måns Zigher  wrote:
>
> I have toke the rpm file that was produced. I found the file under the build 
> directory under 
> tmp/work/imx8mq-strix-linux/x_media/1.0-r44/deploy-rpms/imx8mq/temp/x_media-1.0-r44.imx8mq.rpm.
>  I used the following commands
> 7z x x_media-1.0-r44.imx8mq.rpm
> 7z x x_media-1.0-r44.imx8mq.cpio
>
> The result from this gave me the file tree where I then could run
> file usr/lib/libx_media_1.0.so
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, version 
> 1 (SYSV), dynamically linked, stripped
>
> So I believe that I have concluded that the rpm include the file that dnf is 
> complaining about. I don't understand why dnf thinks that this dependency is 
> not meet when it clearly is part of the package. I have added verbose flags 
> to the dnf call but dose not give any more information.
> I am not sure how I can proceed to find out what I have done wrong. The 
> recipe is a bit of a freak of nature because the binaries that I am packaging 
> is actually built using another toolchain but it is for the same arch can dnf 
> detect that?
>
> BR
> Måns Zigher
>
> Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher :
>>
>> Hi,
>>
>> I am struggling with a recipe which more or less just downloads binaries and 
>> creating a package. We have previously been using ipkg but now we have 
>> switched to rpm in our builds. One of the binaries in the packages is a 
>> library let's call it libx_media_1.0.so. This library is part of the package 
>> that the recipe is producing. The library is placed under /usr/lib/. When 
>> building the image I am getting the following error
>>
>> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
>> .
>> ...
>> Error:
>>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media, but 
>> none of the providers can be installed
>>   - conflicting requests
>>   - nothing provides libx_media_1.0.so()(64bit) needed by 
>> x_media-1.0-r44.imx8mq
>>
>> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>>
>> Here is the output from running the command file on the library
>>
>> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, 
>> version 1 (SYSV), dynamically linked, stripped
>>
>> I have also verified that the library is part of the produced rpm so that is 
>> not the issue.
>>
>> Dose anyone have any suggestion on how to debug this problem? Because I am 
>> out of ideas
>>
>> BR
>> Måns Zigher
>
> --
> ___
> 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] dnf fail in do_rootfs cannot find shared library

[Alexander Kanavin]

On Tue, 22 Jan 2019 at 17:59, Måns Zigher  wrote:
> I am struggling with a recipe which more or less just downloads binaries and 
> creating a package. We have previously been using ipkg but now we have 
> switched to rpm in our builds. One of the binaries in the packages is a 
> library let's call it libx_media_1.0.so. This library is part of the package 
> that the recipe is producing. The library is placed under /usr/lib/. When 
> building the image I am getting the following error
>
> ERROR: base-image-1.0-r0 do_rootfs: Could not invoke dnf. Command
> .
> ...
> Error:
>  Problem: package packagegroup-x-media-1.0-r11.noarch requires x_media, but 
> none of the providers can be installed
>   - conflicting requests
>   - nothing provides libx_media_1.0.so()(64bit) needed by 
> x_media-1.0-r44.imx8mq
>
> ERROR: base-image-1.0-r0 do_rootfs: Function failed: do_rootfs
>
> Here is the output from running the command file on the library
>
> usr/lib/libx_media_1.0.so: ELF 64-bit LSB shared object, ARM aarch64, version 
> 1 (SYSV), dynamically linked, stripped
>
> I have also verified that the library is part of the produced rpm so that is 
> not the issue.
>
> Dose anyone have any suggestion on how to debug this problem? Because I am 
> out of ideas

Can you:
- show how you did the verification of the rpm?
- copy-paste the recipe

please?

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

Re: [yocto] [Recipe reporting system] Upgradable recipe name list

[Alexander Kanavin]

Hello,

just to remind you that RRS continues to send these badly outdated,
misleading reports once a week to yocto@. Please switch them off
and/or take the new RRS into use (if the new RRS addresses the
problem).

Alex


On Mon, 21 Jan 2019 at 06:01,  wrote:
>
> This mail was sent out by Recipe reporting system.
>
> This message list those recipes which need to be upgraded. If maintainers
> believe some of them needn't to upgrade at this time, they can fill
> RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder
> until newer upstream version was detected.
>
> Example:
> RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable"
>
> You can check the detail information at:
>
> http://recipes.yoctoproject.org/
>
> Package   Version  Upstream version  Maintainer   
> NoUpgradeReason
>   ---    
> ---  --
> libgloss  3.0.03.0.0.20180831Alejandro 
> Hernandez
> newlib3.0.03.0.0.20180831Alejandro 
> Hernandez
> libmodulemd   1.7.02.0.0 Alexander Kanavin
> pcmanfm   1.3.01.3.1 Alexander Kanavin
> webkitgtk 2.22.4   2.22.5    Alexander Kanavin
> boost 1.68.0   1.69.0    Alexander Kanavin
> libfm-extra   1.3.0.2  1.3.1     Alexander Kanavin
> libfm 1.3.0.2  1.3.1     Alexander Kanavin
> nativesdk-meson   0.47.2   0.49.0        Alexander Kanavin
> ffmpeg4.0.24.1       Alexander Kanavin
> libcomps  0.1.8+gitX   0.1.9     Alexander Kanavin
> librepo   1.9.2    1.9.3     Alexander Kanavin
> meson 0.47.2   0.49.0    Alexander Kanavin
> dnf   4.0.9    4.0.10Alexander Kanavin
> libdnf0.22.3   0.24.1Alexander Kanavin
> lighttpd  1.4.51       1.4.52Alexander Kanavin
> gobject-introspec...  1.58.1   1.58.2Alexander Kanavin
> btrfs-tools   4.19     4.19.1Alexander Kanavin
> bjam-native   1.68.0   1.69.0Alexander Kanavin
> createrepo-c  0.11.1+gitX  0.12.0Alexander Kanavin
> busybox   1.29.2   1.29.3Andrej Valek
> apt   1.2.24   1.4.8 Aníbal Limón
> apt-native1.2.24   1.4.8 Aníbal Limón
> dpkg  1.18.24  1.19.2Aníbal Limón
> puzzles   0.0+gitX 0.0-new-commits-a...  Anuj Mittal
> libpcap   1.8.11.9.0 Anuj Mittal
> base-passwd   3.5.29   3.5.45Anuj Mittal  
> Version 3.5.38 requires cde...
> ifupdown  0.8.16   0.8.33Anuj Mittal
> glib-2.0  2.58.0   2.58.1Anuj Mittal
> glib-networking   2.54.1   2.58.0Anuj Mittal
> pixman0.34.0   0.36.0Anuj Mittal
> harfbuzz  2.1.32.2.0 Anuj Mittal
> gst-examples  0.0.1+gitX   0.0.1-new-commits...  Anuj Mittal
> sqlite3   3.25.3   3.26.0Anuj Mittal
> vte   0.52.2   0.54.3Anuj Mittal
> gsettings-desktop...  3.28.0   3.28.1Anuj Mittal
> libsolv   0.7.10.7.2 Anuj Mittal
> eudev 3.2.53.2.7 Anuj Mittal
> atk   2.28.1   2.30.0Anuj Mittal
> librsvg   2.40.20  2.44.10   Anuj Mittal  
> Versions from 2.41.0 requir...
> cairo 1.14.12  1.16.2Anuj Mittal
> i2c-tools 4.0  4.1   Anuj Mittal
> libatomic-ops 7.6.6+gitX   7.6.8 Anuj Mittal
> libpng1.6.35   1.6.36Anuj Mittal
> at-spi2-atk   2.26.2   2.30.0Anuj Mittal
> mmc-utils 0.1  0.1-new-commits-a...  Anuj Mittal
> libjpeg-turbo 2.0.02.0.1 Anuj Mittal
> mtools4.0.19   4.0.23Anuj Mitt

Re: [yocto] Rebased Python 3.7.1 patch

[Alexander Kanavin]

You can start by reading the following:

https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines

Alex

On Fri, 18 Jan 2019 at 16:24, Seth McLean  wrote:
>
> I've rebased and made some minor changes to a Python 3.7.1 patch from 
> patchworks. I'd be interested in seeing this patch make it into master if 
> possible.
>
> Could anyone provide any guidance on the process of submitting a patch?
>
> Thanks,
>
> Seth
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bb.build.addtask: add simple check for circular dependency

[Alexander Kanavin]

> On 18 Jan 2019, at 16.34, Burton, Ross  wrote:
> 
>> On Fri, 18 Jan 2019 at 15:08, Ulf Samuelsson  wrote:
>> We could insert a check if the KNOWN_TASKS is valid in a verification test.
>> When building core-image-minimal, the task order within core-image-minimal 
>> is analyzed, (dependencies on all other recipes is filtered away).
>> Then you find out if there are tasks added, missing, and/or in the wrong 
>> order.
> 
> What about people who add new tasks?  Do they now need to go and
> extend KNOWN_TASKS correctly too?

I might be missing something, but isn’t the right moment to detect loops when 
the task graph is fully formed? Then just run generic DFS on it, not a 
difficult or heavy algorithm.

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

[yocto] [PATCH] README: remove mentions of distrodata, as AUH no longer uses it

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin 
---
 README | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/README b/README
index 4752dc6..cb9f87e 100644
--- a/README
+++ b/README
@@ -30,13 +30,6 @@ Setup
upgrade-helper.conf. A sample file is provided in AUH source tree;
it can be used as-is, or tweaked further.
 
-3. Enable distrodata and supply appropriate additional metadata. For
-   example, you could add the following to your conf/local.conf:
-
 snip ---
-INHERIT =+ "distrodata"
 snip ---
-
 WARNING: if you are using the default maintainers.inc file supplied
  with Poky (in meta-yocto) and you don't set a
  maintainers_whitelist or (global_)maintainer_override in the
@@ -57,7 +50,7 @@ BUILDHISTORY_COMMIT = "1"
 If upgrade is succesful buildhistory diff's are generated into
 $BUILDDIR/upgrade-helper/work/recipe/buildhistory-diff.txt.
 
-(Do not remove any other inherited class in the process, e.g. distrodata).
+(Do not remove any other inherited class in the process).
 
 5. If you want to enable testimage (optional) you need to enable in
 upgrade-helper.conf also add the following lines to your conf/local.conf
@@ -76,7 +69,7 @@ a vncserver example:
 $ vncserver :1
 $ export DISPLAY=:1
 
-(Do not remove any other inherited class in the process, e.g. distrodata).
+(Do not remove any other inherited class in the process).
 
 Usage
 -
-- 
2.17.1

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

Re: [yocto] Is it possible to upgrade Nodejs from 8 to 10 LTS?

[Alexander Kanavin]

On Wed, 9 Jan 2019 at 22:34, Stefano Cappa  wrote:
> As explained here https://github.com/nodejs/Release, NodeJS 10 is the current 
> active LTS and NodeJS 8 is right now in "Maintenance" (from January 2019).
>
> I saw that in master branch, Node has been updated from 8.12 to 8.14. Is 
> there an official scheduling to release NodeJS 10 in open-embedded, for 
> instance with yocto 2.7?

In Yocto there is generally no official scheduling for version
updates. That work is basically all volunteer-driven, so you are
welcome to prepare the patches and send them for review and testing.

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

Re: [yocto] [Recipe reporting system] Upgradable recipe name list

[Alexander Kanavin]

On Mon, 7 Jan 2019 at 20:32, Paul Eggleton
 wrote:
> I think the RRS still serves a purpose, if it's putting out correct 
> information of course.
> I have spent quite a bit of time reworking it, but Michael hasn't had the 
> time to do
> the upgrade yet. I will ping him again.

It is certainly useful, I just wonder if we still need these mailing
list reports specifically. AUH does largely the same job, and adds
proposed upgrade patches too :)

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

Re: [yocto] [Recipe reporting system] Upgradable recipe name list

[Alexander Kanavin]

Looks like this has regressed and is sending out outdated, misleading
information (probably related to recent distrodata-releated changes).

Shall we switch it off for now?

AUH has largely superseded this report anyway, and I have a feeling
most people tune it out already.

Alex

On Mon, 7 Jan 2019 at 06:01,  wrote:
>
> This mail was sent out by Recipe reporting system.
>
> This message list those recipes which need to be upgraded. If maintainers
> believe some of them needn't to upgrade at this time, they can fill
> RECIPE_NO_UPDATE_REASON in respective recipe file to ignore this remainder
> until newer upstream version was detected.
>
> Example:
> RECIPE_NO_UPDATE_REASON = "Version 2.0 is unstable"
>
> You can check the detail information at:
>
> http://recipes.yoctoproject.org/
>
> Package   Version  Upstream version  Maintainer   
> NoUpgradeReason
>   ---    
> ---  --
> libgloss  3.0.03.0.0.20180831Alejandro 
> Hernandez
> newlib3.0.03.0.0.20180831Alejandro 
> Hernandez
> libmodulemd   1.7.02.0.0 Alexander Kanavin
> pcmanfm   1.3.01.3.1 Alexander Kanavin
> webkitgtk 2.22.4   2.22.5    Alexander Kanavin
> boost 1.68.0   1.69.0    Alexander Kanavin
> libfm-extra   1.3.0.2  1.3.1     Alexander Kanavin
> libfm 1.3.0.2  1.3.1     Alexander Kanavin
> nativesdk-meson   0.47.2   0.49.0        Alexander Kanavin
> ffmpeg4.0.24.1       Alexander Kanavin
> libcomps  0.1.8+gitX   0.1.9     Alexander Kanavin
> librepo   1.9.2    1.9.3     Alexander Kanavin
> meson 0.47.2   0.49.0    Alexander Kanavin
> dnf   4.0.9    4.0.10Alexander Kanavin
> libdnf0.22.3   0.24.1Alexander Kanavin
> lighttpd  1.4.51       1.4.52Alexander Kanavin
> gobject-introspec...  1.58.1   1.58.2Alexander Kanavin
> btrfs-tools   4.19     4.19.1Alexander Kanavin
> bjam-native   1.68.0   1.69.0Alexander Kanavin
> createrepo-c  0.11.1+gitX  0.12.0Alexander Kanavin
> busybox   1.29.2   1.29.3Andrej Valek
> apt   1.2.24   1.4.8 Aníbal Limón
> apt-native1.2.24   1.4.8 Aníbal Limón
> dpkg  1.18.24  1.19.2Aníbal Limón
> puzzles   0.0+gitX 0.0-new-commits-a...  Anuj Mittal
> libpcap   1.8.11.9.0 Anuj Mittal
> base-passwd   3.5.29   3.5.45Anuj Mittal  
> Version 3.5.38 requires cde...
> ifupdown  0.8.16   0.8.33Anuj Mittal
> glib-2.0  2.58.0   2.58.1Anuj Mittal
> glib-networking   2.54.1   2.58.0Anuj Mittal
> pixman0.34.0   0.36.0Anuj Mittal
> harfbuzz  2.1.32.2.0 Anuj Mittal
> gst-examples  0.0.1+gitX   0.0.1-new-commits...  Anuj Mittal
> sqlite3   3.25.3   3.26.0Anuj Mittal
> vte   0.52.2   0.54.3Anuj Mittal
> gsettings-desktop...  3.28.0   3.28.1Anuj Mittal
> libsolv   0.7.10.7.2 Anuj Mittal
> eudev 3.2.53.2.7 Anuj Mittal
> atk   2.28.1   2.30.0Anuj Mittal
> librsvg   2.40.20  2.44.10   Anuj Mittal  
> Versions from 2.41.0 requir...
> cairo 1.14.12  1.16.2Anuj Mittal
> i2c-tools 4.0  4.1   Anuj Mittal
> libatomic-ops 7.6.6+gitX   7.6.8 Anuj Mittal
> libpng1.6.35   1.6.36Anuj Mittal
> at-spi2-atk   2.26.2   2.30.0Anuj Mittal
> mmc-utils 0.1  0.1-new-commits-a...  Anuj Mittal
> libjpeg-turbo 2.0.02.0.1 Anuj Mittal
> mtools 

Re: [yocto] Some Guide for CI/CD with Yocto

[Alexander Kanavin]

On Fri, 4 Jan 2019 at 21:33, Shantanoo Desai  wrote:
> I just have become more comfortable with Yocto for e.g. using devtool  and 
> basic bitbake commands.
>
> I am was successfully able to create some python applications for my target 
> board via a layer. I would like to use CI / CD eventually for Yocto.
> I have seen videos from Linux Foundation but I could not find any guide to 
> create some basic CI stuff for Yocto.
>
>
> Any help or suggestions in this direction would be appreciated.

You could start by replicating Yocto's buildbot-based CI setup:

http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2/about/
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/about/

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

Re: [yocto] Python upgrade path?

[Alexander Kanavin]

Yep, that’s all reasonable. Devtool won’t help you with rebasing patches to 
poky tree. It has a facility for upgrading recipes, but it’s likely to fail in 
non trivial ways for something as complex as python. You’re better off taking 
existing patches and getting them to work I’d say.

Alex


> On 3 Jan 2019, at 15.50, Derek Dresser  wrote:
> 
>> On Thu, Jan 3, 2019 at 5:36 AM Alexander Kanavin  
>> wrote:
>> On Thu, 3 Jan 2019 at 10:11, Derek Dresser  wrote:
>> > I have an application that uses features introduced in Python 3.6, so I am 
>> > trying to add a new version of Python to my Yocto build.  I know that 
>> > 3.5.6 is the latest version of Python that has been included in a Yocto 
>> > release.  I found the patches here
>> > https://patchwork.openembedded.org/series/14778/
>> > and was able to build Python3.7.1 for the commit specified in the patch.  
>> > I looked briefly at rebasing the patches on the Thud branch, but I think 
>> > that is beyond my current Python and Yocto capabilities.
>> >
>> > Are there any paths forward for me to get a newer version of Python using 
>> > Yocto?  Would it be possible for me to use a package created from that 
>> > patched build and integrate it with my current thud build?  Are there any 
>> > other workarounds I could use until a newer version of Python is supported?
>> >
>> > I'd be happy to spend some time on this if I could help move this forward, 
>> > but I don't think this is something I can do by myself at this point.  I'm 
>> > quite new to Yocto.
>> 
>> Sadly there is no good answer. There are patches, but they need
>> further work (see oe-core list for details). Worse yet, thud is likely
>> to stay with 3.5, as such drastic version upgrades are usually not
>> done in stable branches (you are still free to do it via a custom
>> layer with backported recipes though).
>> 
>> If you can take solving the issues and getting py 3.7 merged into
>> master as an exercise, this would be greatly appreciated by everyone,
>> and would take you out of 'new to yocto' :)
>> 
>> 
>> Alex
> 
> Thanks for the response.  I will take a look at getting 3.7 to build, but I'd 
> benefit from some guidance on the process to do so.  I was able to get the 
> patches to build on the specified commit that they target (although I just 
> tried again and ran into some issues.  I'll have to figure out what I did the 
> first time.)  This is what I did.
> 
> 1. download patches from https://patchwork.openembedded.org/series/14778/
> 2. checkout poky at specified commit 
> "e349b239c8833bcdad9b1ff1a0702ace2db71959"
> 3. apply patch
> 4. bitbake python3
> 
> I then tried to rebase the patches on the master branch and ran into many 
> merge conflicts that I didn't really have the context to resolve.  I believe 
> that is where I'll have to dig in to get things working.
> 
> My questions are, is that a reasonable process?  Is there a better process 
> using devtool or something?  Any guidance is appreciated.
> 
> Thanks,
> Derek
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python upgrade path?

[Alexander Kanavin]

On Thu, 3 Jan 2019 at 10:11, Derek Dresser  wrote:
> I have an application that uses features introduced in Python 3.6, so I am 
> trying to add a new version of Python to my Yocto build.  I know that 3.5.6 
> is the latest version of Python that has been included in a Yocto release.  I 
> found the patches here
> https://patchwork.openembedded.org/series/14778/
> and was able to build Python3.7.1 for the commit specified in the patch.  I 
> looked briefly at rebasing the patches on the Thud branch, but I think that 
> is beyond my current Python and Yocto capabilities.
>
> Are there any paths forward for me to get a newer version of Python using 
> Yocto?  Would it be possible for me to use a package created from that 
> patched build and integrate it with my current thud build?  Are there any 
> other workarounds I could use until a newer version of Python is supported?
>
> I'd be happy to spend some time on this if I could help move this forward, 
> but I don't think this is something I can do by myself at this point.  I'm 
> quite new to Yocto.

Sadly there is no good answer. There are patches, but they need
further work (see oe-core list for details). Worse yet, thud is likely
to stay with 3.5, as such drastic version upgrades are usually not
done in stable branches (you are still free to do it via a custom
layer with backported recipes though).

If you can take solving the issues and getting py 3.7 merged into
master as an exercise, this would be greatly appreciated by everyone,
and would take you out of 'new to yocto' :)


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

Re: [yocto] devtool to built for update repo revision

[Alexander Kanavin]

On Thu, 3 Jan 2019 at 10:09, Peter Balazovic  wrote:
> I am trying to use "devtool" from eSDK to create own recipe. At first it 
> works with repo and can generate recipe and binaries and deploy to target 
> machine.
>
> Now I'd like to update it with a new revision of source code.
> So I updated SRCREV per released commit and as well add PV = 
> "0.1+git${SRCPV}".
>
> I am not editing source code locally at workspace of eSDK.
>
> I rebuilt it but it seems still the same revision is built. What else needs 
> to update to correctly rebuild from new revision of repo?

When you have a recipe source code in the workspace, that source code
takes priority over what the recipe is saying. You need to first issue
'devtool finish' (puts the changes back into the recipe) or 'devtool
reset' (does not do that).

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

Re: [yocto] devtool upgrade ERROR: recipe is already in your workspace

[Alexander Kanavin]

On Thu, 3 Jan 2019 at 10:10, Peter Balazovic  wrote:
> I have created recipe with devtool and now I want to upgrade following
>
> > devtool upgrade myrecipe --srcrev 82a02d8585d262d6ab2d9dc335ed2231dc2d7f06
>
> I am getting error
>
> > ERROR: recipe is already in your workspace
>
> How to correctly upgrade recipe with devtool (eSDK)?


Same - use 'devtool finish' first.

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

Re: [yocto] [yocto-security] Open ssl version

[Alexander Kanavin]

It's likely that you ask bitbake to build something that has a hard
dependency on openssl 1.0. Most probably openssh.

Alex

On Thu, 20 Dec 2018 at 05:30, Vishwanath Chandapur  wrote:
>
> Hi Team,
>
> I have set opnessl version in sumo but getting below errors.
>
>
> PREFERRED_VERSION_openssl = "1.1.0i"
>
>
> Logs:
>
> NOTE: Resolving any missing task queue dependencies
>
> NOTE: preferred version 1.1.0i of openssl not available (for item libssl)
> NOTE: versions of openssl available: 1.0.2p
> NOTE: preferred version 1.1.0i of openssl not available (for item openssl10)
> NOTE: versions of openssl available: 1.0.2p
> NOTE: preferred version 1.1.0i of openssl not available (for item 
> openssl-conf)
> NOTE: versions of openssl available: 1.0.2p
>
>
> ERROR: Multiple versions of openssl are due to be built 
> (/home/ubuntu/workspace/yocto/sources/poky/meta/recipes-connectivity/openssl/openssl_1.0.2p.bb
>  
> /home/ubuntu/workspace/yocto/sources/poky/meta/recipes-connectivity/openssl/openssl_1.1.0i.bb).
>  Only one version of a given PN should be built in any given build. You 
> likely need to set PREFERRED_VERSION_openssl to select the correct version or 
> don't depend on multiple versions.
>
>
> With Regards
> Vishwa
>
> On Fri, Dec 14, 2018 at 5:31 PM Burton, Ross  wrote:
>>
>> How did you set it?
>>
>> Also this isn't relevant to yocto-security, please move to yocto@.
>>
>> Ross
>> On Fri, 14 Dec 2018 at 11:53, Vishwanath Chandapur  
>> wrote:
>> >
>> > Hi Ross,
>> >
>> > I tried to enable by using PREFERRED_VERSION.
>> >
>> > But getting these errors .
>> > 
>> > NOTE: Resolving any missing task queue dependencies
>> > NOTE: preferred version 1.0.% of openssl not available (for item openssl)
>> > NOTE: versions of openssl available: 1.1.0i
>> > NOTE: preferred version 1.0.% of openssl-native not available (for item 
>> > openssl-native)
>> > NOTE: versions of openssl-native available: 1.1.0i
>> > NOTE: preferred version 1.0.% of nativesdk-openssl not available (for item 
>> > nativesdk-openssl)
>> > NOTE: versions of nativesdk-openssl available: 1.1.0i
>> > NOTE: preferred version 1.0.% of openssl not available (for item 
>> > openssl-dev)
>> > NOTE: versions of openssl available: 1.1.0i
>> > NOTE: preferred version 1.0.% of nativesdk-openssl not available (for item 
>> > nativesdk-openssl-dev)
>> > NOTE: versions of nativesdk-openssl available: 1.1.0i
>> > ERROR: Nothing RPROVIDES 'libssl
>> > >>>
>> >
>> > With Regards
>> > Vishwa
>> >
>> >
>> > On Thu, 13 Dec 2018 at 5:57 PM, Burton, Ross  wrote:
>> >>
>> >> Yes, Sumo has OpenSSL 1.1 but it isn't enabled by default because at
>> >> the time of release some important pieces of software had not yet
>> >> migrated.
>> >>
>> >> You can switch by using PREFERRED_VERSION.
>> >>
>> >> Ross
>> >> On Thu, 13 Dec 2018 at 12:13, Vishwanath Chandapur  
>> >> wrote:
>> >> >
>> >> > Hi Team,
>> >> >
>> >> > Currently we are migrating to poly sumo version .
>> >> > But we have requirement to use 1.1.0 but poky is still supporting 1.0.2
>> >> >
>> >> > I would like know if latest OpenSSL available for future release .
>> >> >
>> >> > With Regard
>> >> > Vishwa
>> >> > ___
>> >> > yocto-security mailing list
>> >> > yocto-secur...@yoctoproject.org
>> >> > https://lists.yoctoproject.org/listinfo/yocto-security
>
> --
> ___
> 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: [linux-yocto] [PATCH] virtio.cfg: enable CONFIG_DRM_VIRTIO_GPU

[Alexander Kanavin]

On Mon, 17 Dec 2018 at 04:31, Bruce Ashfield
 wrote:
> > This adds support for a virtual graphics card provided by QEMU,
> > which allows accelerated host-assisted GL inside QEMU guests.
>
> merged. This will be in my next consolidated pull request.

Thanks. I'm new to this - why is the patch in version branches, but
not in master?

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

[linux-yocto] [PATCH] virtio.cfg: enable CONFIG_DRM_VIRTIO_GPU

[Alexander Kanavin]

This adds support for a virtual graphics card provided by QEMU,
which allows accelerated host-assisted GL inside QEMU guests.

Signed-off-by: Alexander Kanavin 
---
 cfg/virtio.cfg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cfg/virtio.cfg b/cfg/virtio.cfg
index 98d76a67..039cb9a8 100644
--- a/cfg/virtio.cfg
+++ b/cfg/virtio.cfg
@@ -10,3 +10,4 @@ CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_VIRTIO=y
 CONFIG_SCSI_VIRTIO=y
 CONFIG_CRYPTO_DEV_VIRTIO=y
+CONFIG_DRM_VIRTIO_GPU=y
-- 
2.17.1

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

Re: [yocto] [PATCH][auh] upgradehelper: Replace do_checkpkg usage with direct tinfoil calls

[Alexander Kanavin]

On Fri, 14 Dec 2018 at 17:07, Richard Purdie
 wrote:
> +with bb.tinfoil.Tinfoil() as tinfoil:
> +tinfoil.prepare(config_only=False)
> +recipes = self.recipes
> +if not recipes:
> +recipes = tinfoil.all_recipe_files(variants=False)
> +
> +for fn in recipes:
> +try:
> +if fn.startswith("/"):
> +data = tinfoil.parse_recipe_file(fn)
> +else:
> +data = tinfoil.parse_recipe(fn)
> +except bb.providers.NoProvider:
> +I(" No provider for %s" % fn)
> +continue
> +
> +unreliable = data.getVar('UPSTREAM_CHECK_UNRELIABLE')
> +if unreliable == "1":
> +I(" Skip package %s as upstream check unreliable" % pn)
> +continue
> +
> +uv = oe.recipeutils.get_recipe_upstream_version(data)
> +
> +pn = data.getVar('PN')
> +cur_ver = uv['current_version']
> +
> +
> +upstream_version_unknown = 
> data.getVar('UPSTREAM_VERSION_UNKNOWN')
> +if not uv['version']:
> +status = "UNKNOWN" if upstream_version_unknown else 
> "UNKNOWN_BROKEN"
> +else:
> +cmp = vercmp_string(uv['current_version'], uv['version'])
> +if cmp == -1:
> +status = "UPDATE" if not upstream_version_unknown 
> else "KNOWN_BROKEN"
> +elif cmp == 0:
> +status = "MATCH" if not upstream_version_unknown 
> else "KNOWN_BROKEN"
> +else:
> +status = "UNKNOWN" if upstream_version_unknown else 
> "UNKNOWN_BROKEN"
> +

This part is generally useful, and should be placed somewhere in
lib/oe/recipeutils.py perhaps? I can imagine having a script (AUH
itself perhaps) that can use the data to print statistics or detect
broken upstream checks. Agree about issues with do_checkpkg  and
general awfulness of distrodata class :)

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

Re: [yocto] supplier workflow

[Alexander Kanavin]

You can put the ipk file location directly into SRC_URI. Bitbake will
unpack it without further tricks. Then just copy the contents in
do_install().

Alex
On Sat, 17 Nov 2018 at 09:35, Robert Berger
 wrote:
>
> Hi,
>
> I came across a scenario, which does not seem too strange, but I am not
> sure how this can be handled with OE/YP. (just nasty hacks with SSTATE)
>
> 1) Company A provides an SDK to to Company B - no source code provided
> 2) Company B provides a "binary" back to Company A - no source code povided
> 3) Company A integrates this "binary" back into some project and
> bitbakes the image
>
> Ideally Company B does not just provide a "binary" executable/library,
> but a package e.g. ipk.
>
> Company A could provide an extensible SDK and Company B could create a
> package of their stuff with it.
>
> Now comes the question: "Is it possible for Company A to add a package
> (no source code available) back into a project and bitbake this?
> If yes, how?"
>
> The advantage would be that Company B would be forced to bitbake it
> (with the additional checks done by OE/YP) and not just compile
> something somehow with a "classic" SDK and ship it.
>
> Regards,
>
> Robert
> --
> ___
> 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] Working on Dependent Recipes in eSDK

[Alexander Kanavin]

I don’t think esdk is designed for this kind of ‘full stack’ development. You 
can go back to working directly with yocto layers, and skip the esdk 
altogether. Devtool will work exactly same (minus the sdk specific commands).

Alex

> On 18 Oct 2018, at 19.37, aaron_wri...@selinc.com wrote:
> 
> My team recently started using the eSDK for day-to-day development. 
> Previously, they were using the bitbake command to build, which works, but 
> has overhead. Yesterday three different people came up to me a question 
> about workflow with the eSDK, and they all had to do with dependent 
> recipes in the eSDK.
> 
> For example, a developer would sit down to make something new that relies 
> on a library provided by a recipe in the eSDK. So they "devtool 
> sdk-install needed-library", and get to work. While working, they 
> discover, I need to add something to this library I depend on so that it 
> does what I want in the way I want. So they "devtool modify 
> needed-library" and change the source of that library to do what they 
> want, and build that library using its build system (CMake or Autotools). 
> Then they return to working on the new something and find that none of 
> their changes to the library they depend on are available. 
> 
> At this point, they are lost. They just start trying things to make it 
> work, like "devtool build needed-library", which successfully completes, 
> but doesn't help. Some people also try to use the build system of the 
> library they modified to install it into the machine sysroot of the eSDK 
> with a command like, "make install 
> DESTDIR=/tmp/sysroots/", and that actually does help. 
> They can now use the changes they made to the library in the new something 
> they are working on. However, when they use the "devtool sdk-install" 
> command again, their changes to the needed library that they installed 
> into the machine sysroot are reverted.
> 
> So--what is the workflow they are supposed to use? 
> 
> Pushing the changes to the library upstream, updating the recipe, and 
> waiting for a new eSDK is not practical given that the developers may have 
> to iterate on the changes to the library quite a bit before they get it 
> just right for their new something.
> 
> Is there a way to update the eSDK sysroots with recipes that are in the 
> workspace? Could "devtool build" also update the eSDK sysroots? Or is 
> there a different way to get this done?
> -- 
> ___
> 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] Project Demo At Edinburgh Submit

[Alexander Kanavin]

Hello Dan,

I believe you need to contact Nicholas:
https://lists.yoctoproject.org/pipermail/yocto/2018-September/042588.html

Alex
On Sun, 7 Oct 2018 at 13:20, Dan Lynch  wrote:
>
> Greetings Yocto mailing listers,
>
> I am pretty new to Yocto and completely new to this list obviously. So
> allow me to introduce myself.
>
> My name is Dan Lynch and I'm a Linux/FOSS geek/dev and journalist from
> Liverpool. I've been working on a brand new open hardware and FOSS
> project with Alex Lennon who some of you will know, plus another local
> lad called Matt Croughan who you are probably less likely to know.
>
> We started it 2 weeks ago, it's called MakeSpace.Live and it's already
> taken off like a rocket. So much so that I think we could do a good demo
> on the Yocto stand.
>
> I am already going to be in Edinburgh for the Open Source Summit ina
> couple of weeks and Alex mentioned you were looking for people to
> demo/discuss things on your stand.
>
> Do I need to do anything formal to apply or can I just come along with a
> load of Raspberry Pis and cameras? Our project leverages Yocto for the
> Pi images so it is relevant obviously.
>
> Many thanks in advance,
>
> Dan
>
>
> --
> http://danlynch.org
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [RFC] CVEs on sumo branch

[Alexander Kanavin]

2018-09-21 21:43 GMT+02:00 Sinan Kaya :
> 2. Apply the attached patches to sumo branch.
>
> We'd like to hear the community opinion.

For stable branches the yocto project tends to be on the conservative
side. Which means option 2: backport the cve fixes.

For the master branch, version upgrades are preferable, unless a
pre-release freeze is in effect.

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

Re: [yocto] remove unneeded files from update-alternatives packages

[Alexander Kanavin]

You can probably have a .bbappend file which removes all the unneeded files in
do_install_append()

Alex

2018-09-21 19:29 GMT+02:00 Matthias Schoepfer
:
> Hi!
>
> In my case, I am using coreutils and busybox. But I only need one
> program of coreutils. Now, I have plenty binaries with .coreutils
> installed in my image, which bloats the image (every byte counts ;) ).
> Its a read-only-image, update-alternatives or package management is not
> used. Is there a better way to remove the unneeded files then manually
> removing them in a ROOTFS_POSTPROCESS_COMMAND?!
>
> Thanks and Regards,
>
> Matthias
>
>
> --
> ___
> 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] Native yocto compile in docker container without cross compile

[Alexander Kanavin]

I think what you are looking for is a Yocto generated SDK for your image?

bitbake -c populate_sdk 

Alex

2018-09-18 23:00 GMT+02:00 Fabian Sturm :
> Hi,
>
> I am wondering, there does not seem to be any information about native
> compile of projects in a Yocto docker container. It seems that most of
> the people use cross compile even though that imho is not necessary if
> your target is x86 too. So here is what I want to do:
>
> - Create a docker container with Yocto Linux, possibly same as the
> target image
> - Install gcc, cmake, autotools etc. in the docker container
> - Run the docker container on a vanilla Ubuntu Linux
> - Run build jobs in this docker container directly
>
> Rational. I have several projects with fully functioning build systems,
> e.g. make, cmake or autotools which I need to compile for different
> platforms, e.g. Windows, Ubuntu Linux and Yocto Linux. I now don't want
> to write recipes just for the Yocto cross compile which I need to
> additionally maintain and I also don't want to make the original build
> systems cross compile aware. This can soon get really hard if the build
> system generates intermediate binaries that are called in the build
> itself and if it is not prepared for this.
> Since my target and host platform are both x86 I do not see the need
> for a cross compile anyways. Usually it is necessary since the target
> platform might be a very slow ARM system that can't handle all the
> builds itself. But I do not have this limitation.
>
> With such a solution my original build systems should still be able to
> run unmodified. Within the docker container the environment would be
> almost the same as in an Ubuntu Linux. The compiler can be accessed
> without any cross compile settings and any intermediate binaries can
> also be directly executed etc.
>
> If there are some fundamental reasons why this is a bad idea, I would
> like to know. I also would appreciate any tips on how to create such a
> docker image. Usually my Yocto image for the target would not contain a
> compiler or make tool. So I need a way to add those after the fact.
>
>
> Thanks a lot!
> Fabian
>
> --
> ___
> 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] bitbake error

[Alexander Kanavin]

It seems as though the build system is unable to create this directory:

/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8

You probably have a permission problem there, working from /home/b but
attempting to create /home/yocto.

Alex

2018-09-13 15:15 GMT+02:00 idealsim :
> Hi, i'm trying to build an image with Yocto on a new machine (ubuntu 16.04
> LTS)but i have this error that i can't resolve. Can you help ?
>
> ERROR: Execution of event handler 'uninative_event_fetchloader' failed
> Traceback (most recent call last):
>   File "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> line 55, in uninative_event_fetchloader(e= 0x7f2015027790>):
>  if not os.path.exists(tarballpath):
> >bb.utils.mkdirhier(tarballdir)
>  if d.getVar("UNINATIVE_URL", True) == "unset":
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> 716, in
> mkdirhier(directory='/home/b/yocto-krogoth/../../yocto/downloads//uninative/acf1e44a0ac2e855e81da6426197d36358bf7b4e88e552ef933128498c8910f8'):
>  if e.errno != errno.EEXIST:
> >raise e
>
> OSError: [Errno 13] Permission denied: '/home/b/yocto-krogoth/../../yocto'
>
> ERROR: Command execution failed: Traceback (most recent call last):
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py", line
> 104, in runAsyncCommand
> commandmethod(self.cmds_async, self, options)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/command.py", line
> 325, in buildTargets
> command.cooker.buildTargets(pkgs_to_build, task)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/cooker.py", line
> 1423, in buildTargets
> bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.data)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> 178, in fire
> fire_class_handlers(event, d)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> 110, in fire_class_handlers
> execute_handler(name, handler, event, d)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/event.py", line
> 82, in execute_handler
> ret = handler(event)
>   File "/home/b/yocto-krogoth/sources/poky/meta/classes/uninative.bbclass",
> line 55, in uninative_event_fetchloader
> bb.utils.mkdirhier(tarballdir)
>   File "/home/b/yocto-krogoth/sources/poky/bitbake/lib/bb/utils.py", line
> 716, in mkdirhier
> raise e
> OSError: [Errno 13] Permission denied: '/home/b/yocto-krogoth/../../yocto'
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Is there a "yocto way" to rebuild sqlite amalgamation?

[Alexander Kanavin]

These two are orthogonal. "amalgamation" is building sqlite from a
single source file for performance and simplicity reasons, which is
what yocto does as well, despite there being no mention of it in the
recipe. Enabling or disabling specific sqlite features can be done
regardless of whether amalgamation or original source code file bunch
is in use.

Alex

2018-09-12 16:54 GMT+02:00 Brian Hutchinson :
> I need to enable SQLITE_ENABLE_UPDATE_DELETE_LIMIT and while researching how
> to do that I read the "amalgamation" needs to be rebuilt.  Sqlite site gives
> instructions on how to do that but I was wondering if this is really
> necessary in a yocto environment.  I did some searches in recipies and the
> work directory where sqlite3 was built and do not get any hits at all on
> "amalgamation".
>
> Any words of wisdom?  I never heard of sqlite amalgamation or had to deal
> with it before so this is a new one on me.
>
> Regards,
>
> Brian
>
> --
> ___
> 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] Postinstall scriptlets of ['coreutils'] have failed

[Alexander Kanavin]

It's right in the message?

ERROR: Logfile of failure stored in:
/home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.27709

Alex

2018-09-09 10:58 GMT+02:00 Jens Rehsack :
> Hi,
>
> I got following issue when building an image for live-debugging:
>
> ERROR: updatable-app-dev-image-1.0-r0 do_rootfs: Postinstall scriptlets of 
> ['coreutils'] have failed. If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in 
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-dev-image/1.0-r0/temp/log.do_rootfs.
> ERROR: updatable-app-dev-image-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in: 
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/updatable-app-dev-image/1.0-r0/temp/log.do_rootfs.14358
> ERROR: Task 
> (/home/sno/gpw-community-bsp/sources/meta-jens/recipes-images/images/updatable-app-dev-image.bb:do_rootfs)
>  failed with exit code '1'
>
> I can reproduce it using core-image-minimal-dev
>
> WARNING: core-image-minimal-dev-1.0-r0 do_rootfs: coreutils.postinst returned 
> 1, marking as unpacked only, configuration required on target.
> ERROR: core-image-minimal-dev-1.0-r0 do_rootfs: Postinstall scriptlets of 
> ['coreutils'] have failed. If the intention is to defer them to first boot,
> then please place them into pkg_postinst_ontarget_${PN} ().
> Deferring to first boot via 'exit 1' is no longer supported.
> Details of the failure are in 
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.
> ERROR: core-image-minimal-dev-1.0-r0 do_rootfs: Function failed: do_rootfs
> ERROR: Logfile of failure stored in: 
> /home/sno/gpw-community-bsp/mops-yocto-platform/tmp/work/fischer-poky-linux/core-image-minimal-dev/1.0-r0/temp/log.do_rootfs.27709
> ERROR: Task 
> (/home/sno/gpw-community-bsp/sources/poky/meta/recipes-core/images/core-image-minimal-dev.bb:do_rootfs)
>  failed with exit code '1'
>
> Any idea where to start debugging?
>
> Best regards
> --
> Jens Rehsack - rehs...@gmail.com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

[Alexander Kanavin]

Sadly, Yocto is not well equippped to deal with projects that download
stuff from the internet as a part of the build process. I'd say if
it's just one project, write a separate recipe for it, and build it
via that. Then install into the original recipe's sysroot or build dir
as needed, and make sure the project doesn't attempt to download it
anymore.

Alex

2018-09-06 13:05 GMT+02:00 Måns Zigher :
> Hi,
>
> I have a cmake project that is making use of ExternalProject_Add. The
> external project will make use of git clone to pull down the project. The
> problem that I am seeing is that the do_configure will fail because it
> cannot find git which is not part of the sysroot the reason for git not
> being part the sysroot is that git-native is included in ASSUME_PROVIDED
> which prevent me from getting it into the sysroot and when running
> do_configure it will only look for it in the sysroot and not on the host if
> I am not mistaken? What would the best way be to proceed to solve this
> problem?
>
> BR
> Måns Zigher
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] (How) did you script bitbake/set up nightly builds?

[Alexander Kanavin]

2018-08-31 12:49 GMT+02:00 Alan Martinovic :
> am just in the process of forming a base for automated nightly builds.
> The goal is to have the build process run every night and report what
>  the status was.
>
> I've opted for python for all the conditionals and checks  and then have
> external
> bash scripts that actually sets the environment and invokes bitbake.
>
> Did it like that because I didn't find a clean way so far to deal with
>
> source oe/oe-init-build-env
>
> from python.
>
>
> Would like to hear how did you script bitbake and how does your setup look
> like?

I guess you should look at what the Yocto project itself is using:

http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2/about/
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/about/

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

Re: [yocto] do_rootfs fails at master with something about glibc-binary-localedata-...

[Alexander Kanavin]

2018-08-28 21:39 GMT+02:00 jan vermaete :
> It's working. Thanks!
>
> I hope deb package will be again fully supported in the next release.

Someone has to do the work though. If you truly want it fixed, you
know what to do :)

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

Re: [yocto] do_rootfs fails at master with something about glibc-binary-localedata-...

[Alexander Kanavin]

2018-08-28 16:34 GMT+02:00 jan vermaete :
> I have a perfect working project at the latest state of Sumo.
> However, building the image when having all meta layers at the latest
> state at master fails.
>
> The step 'do_rootfs' gives:
> --
> The following packages have unmet dependencies:
>  locale-base-en-gb : Depends: glibc-binary-localedata-en-gb but it is
> not going to be installed
>  locale-base-en-us : Depends: glibc-binary-localedata-en-us but it is
> not going to be installed
> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or
> specify a solution).

We don't really test deb packaging, and especially making images from
debs is not tested on the autobuilder at all I believe. Your options
are to debug the dependencies in .deb, or switch to rpm or ipk
formats.

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