Re: [yocto] Can't get *.a's into SDK sysroot

[Zoran Stojsavljevic]

Hello Andre,

> RDEPENDS_${PN}-dev += "${PN}-staticdev"

I also read this email, and decided to investigate myself. Since I
wrote meta-mylayer with cannelloni recipe in it.

To find out if the recipe works correctly, and it is incorporated
(upfront) in ROOTFS, I did the following:
[1] Did the compilation of the clean tree;
[2] After that, I did: bitbake -s | grep cannelloni -> yes, the build
system sees it;
[3] Changed to ${TMPDIR}/work and issued the command: find . -name cannelloni

To my surprise, the search produced empty results.

Then I added your line to the cannelloni recipe: RDEPENDS_${PN}-dev +=
"${PN}-staticdev"

Again, bitbake -c cleanall cannelloni, then bitbake cannelloni, and
step [3] produced visible results.

Now I see it in the .../tmp/work/...

But, there were NOT any changes in: .../tmp/deploy/images/beaglebone/
directory (in ${build} directory, I guess)???

So, what I need to do to see build components changed (since I assume,
cannelloni still did not make it in ROOTFS)???

Thank you,
Zoran
___

On Wed, Jul 25, 2018 at 2:08 AM, Andre McCurdy  wrote:
> On Tue, Jul 24, 2018 at 4:53 PM, Greg Wilson-Lindberg 
> wrote:
>>
>> I've created a recipe for Canfestival (a CAN bus CANOpen support library).
>> I have had it building for a while, but I had the configuration set up to
>> build all parts of it as .so's. I need to change it so that parts of the
>> library are .a's. My problem is that I can't get the .a's to copy to the SDK
>> sysroot /usr/lib directory. The .a's are in the canfestival image/usr/lib &
>> sysroot-destdir/usr/lib directories, but nothing that I've tried has gotten
>> them to the SDK sysroot.
>>
>>
>>
>> Here is the canfestival_3-asc.bb file that I'm using:
>>
>>
>>
>> SUMMARY = "Independent CANOpen® stack"
>>
>> DESCRIPTION = "CanFestival focuses on providing an ANSI-C platform
>> independent \
>>
>>CANOpen® stack that can be built as master or slave nodes
>> on PCs, \
>>
>>Real-time IPCs, and Microcontrollers."
>>
>>
>>
>> HOMEPAGE = "http://www(dot)canfestival(dot)org/" // obfuscated to get past
>> our email system
>>
>>
>>
>> SRCREV = "895:8973dd8be7e8"
>>
>>
>>
>> SRC_URI =
>> "hg://bitbucket.org/Mongo;protocol=https;module=canfestival-3-asc \
>>
>>file://canfestival_3-asc-configure.patch \
>>
>>file://canfestival_3-asc-makefile.in.patch \
>>
>>file://canfestival_3-asc-src_makefile.in.patch \
>>
>>\
>>
>>file://sdo.c.patch \
>>
>>file://def.h.patch \
>>
>>"
>>
>> PR = 'r01'
>>
>>
>>
>> LICENSE = "LGPLv2"
>>
>> LIC_FILES_CHKSUM = "file://COPYING;md5=46ec399d3928b6c91e3634ab7263af44 \
>>
>> file://LICENCE;md5=085e7fb76fb3fa8ba9e9ed0ce95a43f9"
>>
>>
>>
>> TARGET_CC_ARCH += "${LDFLAGS}"
>>
>>
>>
>>
>>
>>
>>
>> do_configure() {
>>
>> bbplain "Starting Configure"
>>
>> #bbplain "rootfs: ${D}"
>>
>> ./configure --target=unix --prefix=${D}/usr/ --can=socket
>> --timers=unix  --SDO_MAX_SIMULTANEOUS_TRANSFERS=30
>> --SDO_MAX_LENGTH_TRANSFER=4096 --MAX_NB_TIMER=128 --SDO_TIMEOUT_MS=3000
>> --debug="WAR"
>>
>>
>>
>> bbplain "Configure Done"
>>
>> }
>>
>>
>>
>> do_compile() {
>>
>> oe_runmake canfestival
>>
>> }
>>
>>
>>
>> do_install() {
>>
>> bbplain "Starting Install"
>>
>> #bbplain "rootfs: ${D}"
>>
>> oe_runmake install PREFIX=${D}/usr/
>>
>>
>>
>> bbplain "Install Done"
>>
>> }
>>
>>
>>
>> FILES_${PN}-dbg = "/usr/src/debug/canfestival"
>>
>> FILES_${PN}-dev = "/usr/lib/libcanfestival*.a
>> /usr/include/canfestival/*.h"
>>
>> FILES_${PN} = "/usr/lib/libcanfestival*.a /usr/lib/libcanfestival*.so"
>>
>>
>>
>> #PACKAGE_BEFORE_PN = "${PN}-info"
>>
>> #FILES_${PN}-info = "usr/lib/pkgconfig"
>>
>>
>>
>> I've fiddled with the various FILES lines, but nothing that I do gets the
>> .a files copied to the SDK sysroot /usr/lib directory.
>>
>>
>>
>> Any insight into what is going wrong would be greatly appreciated.
>
>
> Assuming the static libs are being built and installed correctly they should
> be packaged correctly by the default packaging rules. ie you shouldn't need
> to tweak any FILES_xxx values.
>
> However you will need to ensure that the -staticdev package gets included in
> the SDK. Assuming you always want the static libs for this particular recipe
> to be available then you can try adding the following to the recipe:
>
>   RDEPENDS_${PN}-dev += "${PN}-staticdev"
>
>
>
> --
> ___
> 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] SDK and out of tree modules

[RUSSELL PETERSON]

So, this seems broken to me.  I managed to get around this issue 
(sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?) by 
appending PACKAGE_EXTRA_ARCHS with the MACHINE_ARCH for my bsp.  While 
PACKAGE_ARCHS now has a duplicate in it (it already includes MACHINE_ARCH as 
well as PACKAGE_EXTRA_ARCH), the python code in staging_populate_sysroot seems 
to require this or it looks for the wrong manifest file.

Also, when building the eSDK, dnf seems very confused about what packages are 
compatible.  It's looking for my SoC arch packages... but then won't accept 
aarch64 as being compatible.  I needed to set:

ALL_MULTILIB_PACKAGE_ARCHS =+ " ${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}}"

to get /etc/dnf/vars/arch to update correctly.  This is a bit tedious.  I'm now 
having a similar issue because dnf doesn't seem to like an arch of 
x86_64-nativesdk.  Do I update ALL_MULTILIB_PACKAGE_ARCHS again??  Ug.

--Russ
 

> On July 24, 2018 at 8:36 AM RUSSELL PETERSON  wrote:
> 
> 
> I am running Poky Rocko at the HEAD (just updated yesterday) and see the 
> following when I attempt to build the eSDK:
> 
> sstate-control/manifest-allarch-kernel-devsrc.populate_sysroot not found?
> 
> I see this has been an issue with others as well.  It looks like Paul had a 
> fix around April but then the trail went silent so I'm not sure if there was 
> a fix or if that fix went into Rocko.  Anyone?
> 
> --Russ
> 
> > On July 21, 2018 at 4:42 PM Russell Peterson  wrote:
> > 
> > 
> > No, just the standard SDK.  I was having issues building the eSDK back when 
> > we used pyro and never fully figured it out… but we have since upgraded to 
> > rocko.  I should revisit the eSDK and see if it works for me now or find 
> > the root cause since it sounds useful.
> > 
> > Thanks, Khem.
> > 
> > —Russ
> > 
> > 
> > > On Jul 21, 2018, at 1:34 PM, Khem Raj  wrote:
> > > 
> > > On Sat, Jul 21, 2018 at 6:20 AM Russell Peterson  
> > > wrote:
> > >> 
> > >> Hello,
> > >> 
> > >> I have been building some modules using the SDK for a while now.  This 
> > >> is mostly for development flow purposes but we have had a few customers 
> > >> doing this as well.  To get this to work we always need to run “make 
> > >> silentoldconfig scripts” inside the RFS of the SDK on the build host.  
> > >> Many folks forget to do this this and thus many, many questions come my 
> > >> way about the SDK being broken and they can’t build their modules (not 
> > >> all users are kernel experts or even intermediates… they just want to 
> > >> apply a patch and quickly move on to their app).  Is there a way to do 
> > >> this auto-magically during the installation of the SDK by adding some 
> > >> type of scripts etc… to the recipe?  I assume it needs to be done at 
> > >> install time since while the build host is x86… the exact linux distro 
> > >> is not known until then (or does that matter?).
> > >> 
> > > 
> > > are you using extensible SDK ? in that case I think do_make_scripts
> > > from module-base.bbclass should be helpful
> > > 
> > >> —Russ
> > >> 
> > >> --
> > >> ___
> > >> yocto mailing list
> > >> yocto@yoctoproject.org
> > >> https://lists.yoctoproject.org/listinfo/yocto
> > 
> > -- 
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

[Matt Hoosier]

(Cross-posting to bitbake-devel.)

Quite a while ago I wrote the following message:

On Tue, Jan 24, 2017 at 11:55 AM Matt Hoosier 
wrote:

> In order to support a use-case that embeds information about the Git
> revision of Yocto itself that was used to make a build, I would like to run
> some arbitrary Python code and dump the results (Git SHA1's, tag names,
> etc) into a Bitbake variable.
>
> The idea is that the variable would get consumed in a do_install() task to
> populate some cookie-crumb file in the package payload.
>
> Something like:
>
>   DEPENDS = "git-native"
>
>   python () {
> # This pseudocode isn't strictly functional for invoking Git, but you
> get the idea
> d.setVar('GIT_INFO', subprocess.Popen(['git', 'rev-list',
> ...]).communicate().stdout)
>   }
>
>   do_install () {
> install -d ${D}/etc
> echo "${GIT_INFO}" > ${D}/etc/git-info.txt
>   }
>
> This all works on a fresh run, but Bitbake appears not to be evaluating
> the anonymous Python function on each execution. This leads it to have
> out-of-date information about the Git working copy when global state
> changes but happens not to impact the particular recipe holding this logic.
>
>
The replies given at the time were very helpful in letting me accomplish my
immediate goals, but I never really did get to the bottom of the real
question:


> Is there any trick available to cause the Python function to execute (and
> hence update the value of ${GIT_INFO} each Bitbake execution so that the
> up-to-the-moment contents of it filter into the calculation of the
> signature for do_install()? Or am I just trying a wrong-headed approach and
> doing something illegitimate?
>

Some build systems I know of [1] that are based on hashes rather than
timestamps have a way that you can inform the task execution engine to
always poison the inputs to a certain task's up-to-dateness check. Is there
anything in Bitbake that would allow a declaration to force such-and-such
variable in a recipe always to be re-evaluated:

  EXTERNALLY_INFLUENCED_VARIABLE = "${@int(random.random() * 10)}"
  do_install[vardepsalwaysdirty] = " EXTERNALLY_INFLUENCED_VARIABLE "

  do_install() {
echo '${ EXTERNALLY_INFLUENCED_VARIABLE }' > ${D}/etc/stuff.txt
  }

Don't read too much into the example calling random() here. That's not
really what I want to do; the point is just that the variable's value
(though deterministic) isn't computed strictly from Bitbake metadata. So
I'm searching for a way to get the value of EXTERNALLY_INFLUENCED_VARIABLE
to be re-computed each time Bitbake starts. If the computed value ends up
matching what was seen on the last execution, then any dependent tasks
wouldn't need re-run.

Any ideas?

[1] I'm thinking particularly of Waf's hash-based task graph, which
supports annotations that can be used to always cause a task to be re-run
even if all the inputs feeding into it appear up-to-date.

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

Re: [yocto] Can't get *.a's into SDK sysroot

[Andre McCurdy]

On Wed, Jul 25, 2018 at 1:23 AM, Zoran Stojsavljevic
 wrote:
> Hello Andre,
>
>> RDEPENDS_${PN}-dev += "${PN}-staticdev"
>
> I also read this email, and decided to investigate myself. Since I
> wrote meta-mylayer with cannelloni recipe in it.
>
> To find out if the recipe works correctly, and it is incorporated
> (upfront) in ROOTFS, I did the following:
> [1] Did the compilation of the clean tree;
> [2] After that, I did: bitbake -s | grep cannelloni -> yes, the build
> system sees it;
> [3] Changed to ${TMPDIR}/work and issued the command: find . -name cannelloni
>
> To my surprise, the search produced empty results.
>
> Then I added your line to the cannelloni recipe: RDEPENDS_${PN}-dev +=
> "${PN}-staticdev"
>
> Again, bitbake -c cleanall cannelloni, then bitbake cannelloni, and
> step [3] produced visible results.
>
> Now I see it in the .../tmp/work/...
>
> But, there were NOT any changes in: .../tmp/deploy/images/beaglebone/
> directory (in ${build} directory, I guess)???
>
> So, what I need to do to see build components changed (since I assume,
> cannelloni still did not make it in ROOTFS)???

I'm not sure that I understand the question.

If you are asking why you sometimes don't see build artefacts under
${TMPDIR}/work then remember that the goal of building a normal recipe
is to create a set of installable packages under ${TMPDIR}/deploy. The
files in the work directory are just side effects of the intermediate
steps to achieve that... and bitbake will try hard to skip those
intermediate steps if they can be avoided (ie if outputs can be
recreated from sstate).

If you are asking why building your image from a completely clean tree
doesn't result in building your recipe (or changing your recipe
doesn't result in the image being rebuilt) then yes it suggests that
your image doesn't include and packages created by your recipe.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH] Revert mm/vmstat.c: fix vmstat_update() preemption BUG

[Bruce Ashfield]

On 2018-07-24 9:47 PM, He Zhe wrote:



On 2018年07月25日 04:07, Bruce Ashfield wrote:

On 2018-07-23 10:07 PM, He Zhe wrote:



On 2018年07月24日 03:21, Bruce Ashfield wrote:

Which version/branches is this for ?



This is for linux-yocto rt branches. linux-yocto-4.12 does not need this
fix, since the commit, see below, causing the issue have not been included.


Rather than me guessing. Which versions are you looking at ? I've got
active -stable updates for many of the linux-yocto trees, so any number
could be impacted.


I'm looking at
git://git.yoctoproject.org/linux-yocto
v4.14/standard/preempt-rt/base
v4.14/standard/preempt-rt/intel

I want to fix
http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v4.14/standard/preempt-rt/base&id=08e9dbd5184e4e059adf1cc77b5dc08eca314a77
by porting
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git/commit/?h=v4.14-rt&id=ac7768148a10fe7e934a7a510cc067883163f115




thanks for the details. This is now merged.

Bruce


Thanks,
Zhe




Bruce



git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

commit 08e9dbd5184e4e059adf1cc77b5dc08eca314a77
Author: Steven J. Hill 
AuthorDate: Wed Mar 28 16:01:09 2018 -0700
Commit: Greg Kroah-Hartman 
CommitDate: Wed May 30 07:52:21 2018 +0200

  mm/vmstat.c: fix vmstat_update() preemption BUG


Thanks,
Zhe


Given the author, I'm assuming it is for the -rt branches and also
for 4.12 .. but I'd like a confirmation of that.

Bruce

On 2018-07-20 4:13 AM, zhe...@windriver.com wrote:

From: Sebastian Andrzej Siewior 

commit 97731753d44d5efcb95b994dc952c0e8195b3e96 upstream

This patch reverts commit c7f26ccfb2c3 ("mm/vmstat.c: fix
vmstat_update() preemption BUG").
Steven saw a "using smp_processor_id() in preemptible" message and
added a preempt_disable() section around it to keep it quiet. This is
not the right thing to do it does not fix the real problem.

vmstat_update() is invoked by a kworker on a specific CPU. This worker
it bound to this CPU. The name of the worker was "kworker/1:1" so it
should have been a worker which was bound to CPU1. A worker which can
run on any CPU would have a `u' before the first digit.

smp_processor_id() can be used in a preempt-enabled region as long as
the task is bound to a single CPU which is the case here. If it could
run on an arbitrary CPU then this is the problem we have an should seek
to resolve.
Not only this smp_processor_id() must not be migrated to another CPU but
also refresh_cpu_vm_stats() which might access wrong per-CPU variables.
Not to mention that other code relies on the fact that such a worker
runs on one specific CPU only.

Therefore I revert that commit and we should look instead what broke the
affinity mask of the kworker.

Cc: Steven J. Hill 
Cc: Tejun Heo 
Cc: Andrew Morton 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Steven Rostedt (VMware) 

Backport this to fix following serious crash for preempt-rt kernel

BUG: scheduling while atomic: kworker/3:1/91/0x0002
Preemption disabled at:
[] vmstat_update+0x2d/0xb0
CPU: 3 PID: 91 Comm: kworker/3:1 Not tainted 4.14.48-rt29-yocto-preempt-rt #1
Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge, BIOS 
BDW-E2R1.86C.0118.R01.1503110618 03/11/2015
Workqueue: mm_percpu_wq vmstat_update
Call Trace:
    dump_stack+0x4f/0x6b
    ? vmstat_update+0x2d/0xb0
    __schedule_bug.cold.24+0x7d/0x9a
    __schedule+0x45a/0x6c0
    ? task_blocks_on_rt_mutex+0x173/0x300
    schedule+0x3d/0xd0
    rt_spin_lock_slowlock_locked+0x118/0x2a0
    rt_spin_lock_slowlock+0x48/0x60
    rt_spin_lock+0x3f/0x50
    queue_delayed_work_on+0x63/0x100
    vmstat_update+0x6e/0xb0
    process_one_work+0x1c3/0x430
    worker_thread+0x32/0x440
    kthread+0x127/0x140
    ? process_one_work+0x430/0x430
    ? kthread_create_on_node+0x40/0x40
    ret_from_fork+0x35/0x40

Signed-off-by: He Zhe 
---
    mm/vmstat.c | 2 --
    1 file changed, 2 deletions(-)

diff --git a/mm/vmstat.c b/mm/vmstat.c
index 84fd6eb..0d17b8f 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1782,11 +1782,9 @@ static void vmstat_update(struct work_struct *w)
     * to occur in the future. Keep on running the
     * update worker thread.
     */
-    preempt_disable();
    queue_delayed_work_on(smp_processor_id(), mm_percpu_wq,
    this_cpu_ptr(&vmstat_work),
    round_jiffies_relative(sysctl_stat_interval));
-    preempt_enable();
    }
    }
   












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

[yocto] How to enable http2 for Apache?

[Simon Chamlian]

Hi,


What is the best way to enable http2 for Apache?

Do I add

COMMON_EXTRA_OECONF_append_pn-apache2 = "--enable-http2"

in local.conf ?

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

Re: [yocto] Can't get *.a's into SDK sysroot

[Greg Wilson-Lindberg]

Hi Andre,
The RDEPENDS did what I needed.

Thank you very much,


Greg Wilson-Lindberg

Principal Firmware Engineer | Sakura Finetek USA, Inc.



1750 W 214th Street | Torrance, CA 90501 | U.S.A.

T: +1 310 783 5075

F: +1 310 618 6902 | E: gwil...@sakuraus.com

www.sakuraus.com



[cid:image002.png@01D35D7D.179A7510]

[cid:image003.png@01D35D7D.179A7510]




Confidentiality Notice: This e-mail transmission may contain confidential or 
legally privileged information that is intended only for the individual or 
entity named in the e-mail address. If you are not the intended recipient, you 
are hereby notified that any disclosure, copying, distribution, or reliance 
upon the contents of this e-mail is strictly prohibited. If you have received 
this e-mail transmission in error, please reply to the sender, so that Sakura 
Finetek USA, Inc. can arrange for proper delivery, and then please delete the 
message from your inbox. Thank you.



From: Andre McCurdy [mailto:armccu...@gmail.com]
Sent: Tuesday, July 24, 2018 05:09 PM
To: Greg Wilson-Lindberg 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Can't get *.a's into SDK sysroot

On Tue, Jul 24, 2018 at 4:53 PM, Greg Wilson-Lindberg 
mailto:gwil...@sakuraus.com>> wrote:

I've created a recipe for Canfestival (a CAN bus CANOpen support library). I 
have had it building for a while, but I had the configuration set up to build 
all parts of it as .so's. I need to change it so that parts of the library are 
.a's. My problem is that I can't get the .a's to copy to the SDK sysroot 
/usr/lib directory. The .a's are in the canfestival image/usr/lib & 
sysroot-destdir/usr/lib directories, but nothing that I've tried has gotten 
them to the SDK sysroot.



Here is the canfestival_3-asc.bb file that I'm 
using:



SUMMARY = "Independent CANOpen® stack"

DESCRIPTION = "CanFestival focuses on providing an ANSI-C platform independent \

   CANOpen® stack that can be built as master or slave nodes on 
PCs, \

   Real-time IPCs, and Microcontrollers."



HOMEPAGE = 
"http://www(dot)canfestival(dot)org/"
 // obfuscated to get past our email system



SRCREV = "895:8973dd8be7e8"



SRC_URI = 
"hg://bitbucket.org/Mongo;protocol=https;module=canfestival-3-asc
 \

   
file://canfestival_3-asc-configure.patch
 \

   
file://canfestival_3-asc-makefile.in.patch
 \

   
file://canfestival_3-asc-src_makefile.in.patch
 \

   \

   file://sdo.c.patch \

   file://def.h.patch \

   "

PR = 'r01'



LICENSE = "LGPLv2"

LIC_FILES_CHKSUM = "file://COPYING;md5=46ec399d3928b6c91e3634ab7263af44 \


file://LICENCE;md5=085e7fb76fb3fa8ba9e9ed0ce95a43f9"



TARGET_CC_ARCH += "${LDFLAGS}"







do_configure() {

bbplain "Starting Configure"

#bbplain "rootfs: ${D}"

./configure --target=unix --prefix=${D}/usr/ --can=socket --timers=unix  
--SDO_MAX_SIMULTANEOUS_TRANSFERS=30 --SDO_MAX_LENGTH_TRANSFER=4096 
--MAX_NB_TIMER=128 --SDO_TIMEOUT_MS=3000 --debug="WAR"



bbplain "Configure Done"

}



do_compile() {

oe_runmake canfestival

}



do_install() {

bbplain "Starting Install"

#bbplain "rootfs: ${D}"

oe_runmake install PREFIX=${D}/usr/



bbplain "Install Done"

}



FILES_${PN}-dbg = "/usr/src/debug/canfestival"

FILES_${PN}-dev = "/usr/lib/libcanfestival*.a /usr/include/canfestival/*.h"

FILES_${PN} = "/usr/lib/libcanfestival*.a /usr/lib/libcanfestival*.so"



#PACKAGE_BEFORE_PN = "${PN}-info"

#FILES_${PN}-info = "usr/lib/pkgconfig"


I've fiddled with the various FILES lines, but nothing that I do gets the .a 
files copied to the SDK sysroot /usr/lib directory.



Any insight into what is going wrong would be greatly appreciated.

Assuming the static libs are being built and installed correctly they should be 
packaged correctly by the default packaging rules. ie you shouldn't need to 
tweak any FILES_xxx values.

However you will need to ensure that the -staticdev package gets included in 
the SDK. Assuming you always want the static libs for this particular recipe to 
be available then you can try adding the following to the recipe:

  RDEPENDS_${PN}-dev += "${PN}-staticdev"


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

Re: [yocto] How to enable http2 for Apache?

[Andre McCurdy]

On Wed, Jul 25, 2018 at 11:17 AM, Simon Chamlian  wrote:
> Hi,
>
> What is the best way to enable http2 for Apache?
>
> Do I add
>
> COMMON_EXTRA_OECONF_append_pn-apache2 = "--enable-http2"
>
> in local.conf ?

No.

Wondering what process you went through to arrive at that?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to enable http2 for Apache?

[Simon Chamlian]

Trial and errors.

Is there another way of enabling http2  ?

In general, if we wish to add flags to a compilation of a package, what is
the proper way of doing it?
Changing the local.conf or the recipe of a given package?





On Wed, Jul 25, 2018 at 3:26 PM, Andre McCurdy  wrote:

> On Wed, Jul 25, 2018 at 11:17 AM, Simon Chamlian 
> wrote:
> > Hi,
> >
> > What is the best way to enable http2 for Apache?
> >
> > Do I add
> >
> > COMMON_EXTRA_OECONF_append_pn-apache2 = "--enable-http2"
> >
> > in local.conf ?
>
> No.
>
> Wondering what process you went through to arrive at that?
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [ANNOUNCEMENT] Yocto Project 2.2.4 (morty 16.0.4) Released

[Tracy Graydon]

Hello,

The latest release of the Yocto Project 2.2.4 (morty-16.0.4) is now available 
for download at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/poky-morty-16.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.4/poky-morty-16.0.4.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/RELEASENOTES

Full pass test report is available at:

https://wiki.yoctoproject.org/wiki/WW28_-_2018-07-13_-_Full_Test_Cycle_2.2.4_rc1

Thank you to everyone for your contributions to this release!

Tracy Graydon
Yocto Project Build and Release
tracy.gray...@intel.com


--
yocto-2.2.4 Errata


Release Name: eclipse-poky-neon-morty-16.0.4
Branch: neon/morty
Tag: neon/morty-16.0.4
Hash: a5dbc01b96be55c4ec2f774af9996a8086e402ab
md5: 729602a68642b33c340209e02caad8e2
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/eclipse-poky-neon-morty-16.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.4/eclipse-poky-neon-morty-16.0.4.tar.bz2

Release Name: eclipse-poky-oxygen-morty-16.0.4
Branch: oxygen/morty
Tag: oxygen/morty-16.0.4
Hash: 020fc5814d2028654879356296b647002caf30b6
md5: f247ab6afc58ab04cdac5edce1149f7f
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/eclipse-poky-oxygen-morty-16.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.4/eclipse-poky-oxygen-morty-16.0.4.tar.bz2

Release Name: meta-qt3-morty-16.0.4
Branch: morty
Tag: morty-16.0.4
Hash: f33b73a9563f2dfdfd0ee37b61d65d90197a456f
md5: d3fcb000c74c412cc74afc39e3f0e365
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/meta-qt3-morty-16.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.4/meta-qt3-morty-16.0.4.tar.bz2

Release Name: meta-qt4-morty-16.0.4
Branch: morty
Tag: morty-16.0.4
Hash: f389368dc86e745df14cab9eeb9a94bc02bd273e
md5: 22f8f65ac57f88525c37a5be13e0f6ab
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/meta-qt4-morty-16.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.4/meta-qt4-morty-16.0.4.tar.bz2

Release Name: poky-morty-16.0.4
Branch: morty
Tag: morty-16.0.4
Hash: df76669bdd70aa0d903c4211dde731221c7e756d
md5: c3c59465832e77ea79fe7aa9f9bd0742
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-2.2.4/poky-morty-16.0.4.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-2.2.4/poky-morty-16.0.4.tar.bz2


---
 Known Issues
---
N/A


---
Security Fixes
---
libvorbis: CVE-2018-5146
libvorbis: CVE-2017-14632
libvorbis: CVE-2017-14633
libtirpc: Fix CVE-2017-8779
gcc: Fix CVE-2016-6131 in libiberty
glib.inc: set CVE_PRODUCT to glib
glibc-common.inc: set CVE_PRODUCT to glibc
sqlite3.inc: set CVE_PRODUCT to sqlite
python.inc: set CVE_PRODUCT to python
icu.inc: set CVE_PRODUCT to international_components_for_unicode
bluez5.inc: set CVE_PRODUCT to bluez
acpid.inc: set CVE_PRODUCT to acpid2
binutils: CVE-2017-15938
binutils: CVE-2017-15024
binutils: CVE-2017-14729
binutils: CVE-2017-9955
binutils: CVE-2017-9954
binutils: CVE-2017-9745
binutils: CVE-2017-9756
binutils: CVE-2017-9755
binutils: CVE-2017-9753_and_CVE-2017-9754
binutils: CVE-2017-9752
binutils: CVE-2017-9750
binutils: CVE-2017-9747
binutils: CVE-2017-9748
binutils: CVE-2017-9746
binutils: CVE-2017-9749
binutils: CVE-2017-9751
binutils: CVE-2017-7299
binutils: CVE-2017-8398
binutils: CVE-2017-8394
binutils: CVE-2017-8421
binutils: CVE-2017-8396
binutils: CVE-2017-8397
binutils: CVE-2017-8395
binutils: CVE-2017-8393
binutils: CVE-2017-7304
binutils: CVE-2017-7303
binutils: CVE-2017-7302
binutils: CVE-2017-7301
binutils: CVE-2017-7227
binutils: CVE-2017-7225
binutils: CVE-2017-7224
binutils: CVE-2017-7223
binutils: CVE-2017-12450_12452_12453_12454_12456
binutils: CVE-2017-12451
binutils: CVE-2017-12449, CVE-2017_12455, CVE-2017-12457, CVE-2017-12458, 
CVE-2017-12459
binutils: CVE-2017-12448
binutils: CVE-2017-7226
binutils: Security Fix CVE-2017-9041
binutils: Security fix for CVE-2017-9040 and 2017-9042
binutils: Security Fix CVE-2017-9039
binutis: Security fix CVE-2017-9038
binutis: Security fix CVE-2017-7614


---
Fixes
---
documentation: Updated manual revision tables with 2.2.4 release date
documentation: Updated title page notes.
build-appliance-image: Update to morty head revision
poky: Bump distro version to 2.2.4
ruby: Update to 2.4.4
ruby: fix typo in gmp PACKAGECONFIG option
ruby: remove spurious db build dependency
test-dependencies.sh: remove /sysroots* between component builds
sstate-diff-machines.sh: Replace MACHINE_ARCH only at the beginning and 
separated with dash
sstate-sysroot-cruft.sh: Extend the whitelist
byacc: Fic SRC_URI to use yocto sources loc.
oe-selftest: no need to parse gpg output to determine the name of the signing 
key
libmpc: fix SRC_URI
sanity.bbclass: Improved error message
packa

Re: [yocto] How to enable http2 for Apache?

[Andre McCurdy]

On Wed, Jul 25, 2018 at 12:45 PM, Simon Chamlian  wrote:
> Trial and errors.
>
> Is there another way of enabling http2  ?
>
> In general, if we wish to add flags to a compilation of a package, what is
> the proper way of doing it?

Start by reading the recipe and see what variables or PACKAGECONFIG
options it uses to derive the configure options.

If there's no PACKAGECONFIG option to control the feature then
(assuming it's an autotools recipe - which again you need to read the
recipe to determine) you can add additional options to EXTRA_OECONF.

> Changing the local.conf or the recipe of a given package?

Once you know what variable you are trying to change (e.g. appending
to PACKAGECONFIG, EXTRA_OECONF, etc) then there are many ways you can
do so. Editing the recipe, creating a .bbappend for the recipe or
setting via local.conf (which case you'll need to use a recipe
specific over-ride since local.conf is a global config file and you
only want your change to apply to one particular recipe) would all
work.

The basic advice though is to try to understand the change you need to
make a how to make it by reading documentation or existing recipes etc
and trying to figure out how and why they work. Trial and error is not
a good way to try to learn OE.

>
> On Wed, Jul 25, 2018 at 3:26 PM, Andre McCurdy  wrote:
>>
>> On Wed, Jul 25, 2018 at 11:17 AM, Simon Chamlian 
>> wrote:
>> > Hi,
>> >
>> > What is the best way to enable http2 for Apache?
>> >
>> > Do I add
>> >
>> > COMMON_EXTRA_OECONF_append_pn-apache2 = "--enable-http2"
>> >
>> > in local.conf ?
>>
>> No.
>>
>> Wondering what process you went through to arrive at that?
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Ordering of anonymous Python functions and task signature calculations

[Richard Purdie]

On Wed, 2018-07-25 at 08:47 -0500, Matt Hoosier wrote:
> Quite a while ago I wrote the following message:
> On Tue, Jan 24, 2017 at 11:55 AM Matt Hoosier  > wrote:
> > In order to support a use-case that embeds information about the
> > Git revision of Yocto itself that was used to make a build, I would
> > like to run some arbitrary Python code and dump the results (Git
> > SHA1's, tag names, etc) into a Bitbake variable.
> > 
> > The idea is that the variable would get consumed in a do_install()
> > task to populate some cookie-crumb file in the package payload.
> > 
> > Something like:
> > 
> >   DEPENDS = "git-native"
> > 
> >   python () {
> > # This pseudocode isn't strictly functional for invoking Git,
> > but you get the idea
> > d.setVar('GIT_INFO', subprocess.Popen(['git', 'rev-list',
> > ...]).communicate().stdout)
> >   }
> > 
> >   do_install () {
> > install -d ${D}/etc
> > echo "${GIT_INFO}" > ${D}/etc/git-info.txt
> >   }
> > 
> > This all works on a fresh run, but Bitbake appears not to be
> > evaluating the anonymous Python function on each execution. This
> > leads it to have out-of-date information about the Git working copy
> > when global state changes but happens not to impact the particular
> > recipe holding this logic.
> > 
> > 
> 
> The replies given at the time were very helpful in letting me
> accomplish my immediate goals, but I never really did get to the
> bottom of the real question:
>  
> > Is there any trick available to cause the Python function to
> > execute (and hence update the value of ${GIT_INFO} each Bitbake
> > execution so that the up-to-the-moment contents of it filter into
> > the calculation of the signature for do_install()? Or am I just
> > trying a wrong-headed approach and doing something illegitimate? 
> > 
> 
> Some build systems I know of [1] that are based on hashes rather than
> timestamps have a way that you can inform the task execution engine
> to always poison the inputs to a certain task's up-to-dateness check.
> Is there anything in Bitbake that would allow a declaration to force
> such-and-such variable in a recipe always to be re-evaluated:
> 
>   EXTERNALLY_INFLUENCED_VARIABLE = "${@int(random.random() * 10)}"
>   do_install[vardepsalwaysdirty] = " EXTERNALLY_INFLUENCED_VARIABLE "
> 
>   do_install() {
> echo '${ EXTERNALLY_INFLUENCED_VARIABLE }' > ${D}/etc/stuff.txt
>   }
> 
> Don't read too much into the example calling random() here. That's
> not really what I want to do; the point is just that the variable's
> value (though deterministic) isn't computed strictly from Bitbake
> metadata. So I'm searching for a way to get the value of
> EXTERNALLY_INFLUENCED_VARIABLE to be re-computed each time Bitbake
> starts. If the computed value ends up matching what was seen on the
> last execution, then any dependent tasks wouldn't need re-run.
> 
> Any ideas?
> 
> [1] I'm thinking particularly of Waf's hash-based task graph, which
> supports annotations that can be used to always cause a task to be
> re-run even if all the inputs feeding into it appear up-to-date.

>From a bitbake perspective there are two things you need to ensure
here, that the recipe gets reparsed at every execution and that the
task dependency exists. You have the dependency above and that is the
easier piece to fix.

If the recipe is reparsed, the anon python reruns and the task hash
recalculated.

If a recipe sets BB_DONT_CACHE, it will be reparsed upon each run and
the hashes will dynamically change as you want. BB_SRCREV_POLICY !=
"cache" uses that behind the scenes so that it can dynamically update
srcrevs.

Hope that helps...

Cheers,

Richard


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

Re: [yocto] can bitbake build offline ?

[MOHAMMAD RASIM]

I tried that and bitbake still fails when disabling the network


On 07/21/2018 11:42 AM, Alexander Kanavin wrote:

This page has a tip on what might be causing 'git ls-remote':

https://wiki.yoctoproject.org/wiki/How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F

Alex

2018-07-21 10:32 GMT+02:00 MOHAMMAD RASIM :

Hi, is there a way I can run a bitbake build offline? I have all the
required sources of the target in the sources directory, and I have built
the target multiple times with internet connection, but when I build offline
it fails because it needs internet access during parsing recipes.
Can I tell bitbake to skip running `git ls-remote` during parsing recipes so
I can build offline?

Thanks
--
___
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] can bitbake build offline ?

[Paul Eggleton]

Hi Mohammad,

If it's failing during parsing that means you still have a recipe that does 
not have a proper SRCREV set, which you need to fix as described by the page 
that Alex linked. The error will be reporting which recipe that is.

Cheers,
Paul

On Thursday, 26 July 2018 5:44:26 AM CEST MOHAMMAD RASIM wrote:
> I tried that and bitbake still fails when disabling the network
> 
> 
> On 07/21/2018 11:42 AM, Alexander Kanavin wrote:
> > This page has a tip on what might be causing 'git ls-remote':
> >
> > https://wiki.yoctoproject.org/wiki/
How_do_I#Q:_How_do_I_create_my_own_source_download_mirror_.3F
> >
> > Alex
> >
> > 2018-07-21 10:32 GMT+02:00 MOHAMMAD RASIM :
> >> Hi, is there a way I can run a bitbake build offline? I have all the
> >> required sources of the target in the sources directory, and I have built
> >> the target multiple times with internet connection, but when I build 
offline
> >> it fails because it needs internet access during parsing recipes.
> >> Can I tell bitbake to skip running `git ls-remote` during parsing recipes 
so
> >> I can build offline?
> >>
> >> Thanks
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> 
> 


-- 

Paul Eggleton
Intel Open Source Technology Centre


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

Re: [yocto] Can't get *.a's into SDK sysroot

[Zoran Stojsavljevic]

Andre,

> If you are asking why building your image from a completely clean tree
> doesn't result in building your recipe (or changing your recipe
> doesn't result in the image being rebuilt) then yes it suggests that
> your image doesn't include and packages created by your recipe.

Your answer remains me of this story:
https://joke4fun.com/text/engineer-vs-manager-19418

Well... ;-)

I'll try to do some more testings, and to find out what is really wrong here.

The useful info is that out of clean tree nothing is visible in
${TMPDIR}/work, so, after all, might be that YOCTO build system does
not see my layer (for some unknown reason) at all.

Thank you,
Zoran
___

On Wed, Jul 25, 2018 at 8:15 PM, Greg Wilson-Lindberg
 wrote:
> Hi Andre,
>
> The RDEPENDS did what I needed.
>
>
>
> Thank you very much,
>
> Greg Wilson-Lindberg
>
> Principal Firmware Engineer | Sakura Finetek USA, Inc.
>
>
>
> 1750 W 214th Street | Torrance, CA 90501 | U.S.A.
>
> T: +1 310 783 5075
>
> F: +1 310 618 6902 | E: gwil...@sakuraus.com
>
> www.sakuraus.com
>
>
>
> 
>
> Confidentiality Notice: This e-mail transmission may contain confidential or
> legally privileged information that is intended only for the individual or
> entity named in the e-mail address. If you are not the intended recipient,
> you are hereby notified that any disclosure, copying, distribution, or
> reliance upon the contents of this e-mail is strictly prohibited. If you
> have received this e-mail transmission in error, please reply to the sender,
> so that Sakura Finetek USA, Inc. can arrange for proper delivery, and then
> please delete the message from your inbox. Thank you.
>
>
>
>
>
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Tuesday, July 24, 2018 05:09 PM
> To: Greg Wilson-Lindberg 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Can't get *.a's into SDK sysroot
>
>
>
> On Tue, Jul 24, 2018 at 4:53 PM, Greg Wilson-Lindberg 
> wrote:
>
> I've created a recipe for Canfestival (a CAN bus CANOpen support library). I
> have had it building for a while, but I had the configuration set up to
> build all parts of it as .so's. I need to change it so that parts of the
> library are .a's. My problem is that I can't get the .a's to copy to the SDK
> sysroot /usr/lib directory. The .a's are in the canfestival image/usr/lib &
> sysroot-destdir/usr/lib directories, but nothing that I've tried has gotten
> them to the SDK sysroot.
>
>
>
> Here is the canfestival_3-asc.bb file that I'm using:
>
>
>
> SUMMARY = "Independent CANOpen® stack"
>
> DESCRIPTION = "CanFestival focuses on providing an ANSI-C platform
> independent \
>
>CANOpen® stack that can be built as master or slave nodes on
> PCs, \
>
>Real-time IPCs, and Microcontrollers."
>
>
>
> HOMEPAGE = "http://www(dot)canfestival(dot)org/" // obfuscated to get past
> our email system
>
>
>
> SRCREV = "895:8973dd8be7e8"
>
>
>
> SRC_URI = "hg://bitbucket.org/Mongo;protocol=https;module=canfestival-3-asc
> \
>
>file://canfestival_3-asc-configure.patch \
>
>file://canfestival_3-asc-makefile.in.patch \
>
>file://canfestival_3-asc-src_makefile.in.patch \
>
>\
>
>file://sdo.c.patch \
>
>file://def.h.patch \
>
>"
>
> PR = 'r01'
>
>
>
> LICENSE = "LGPLv2"
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=46ec399d3928b6c91e3634ab7263af44 \
>
> file://LICENCE;md5=085e7fb76fb3fa8ba9e9ed0ce95a43f9"
>
>
>
> TARGET_CC_ARCH += "${LDFLAGS}"
>
>
>
>
>
>
>
> do_configure() {
>
> bbplain "Starting Configure"
>
> #bbplain "rootfs: ${D}"
>
> ./configure --target=unix --prefix=${D}/usr/ --can=socket --timers=unix
> --SDO_MAX_SIMULTANEOUS_TRANSFERS=30 --SDO_MAX_LENGTH_TRANSFER=4096
> --MAX_NB_TIMER=128 --SDO_TIMEOUT_MS=3000 --debug="WAR"
>
>
>
> bbplain "Configure Done"
>
> }
>
>
>
> do_compile() {
>
> oe_runmake canfestival
>
> }
>
>
>
> do_install() {
>
> bbplain "Starting Install"
>
> #bbplain "rootfs: ${D}"
>
> oe_runmake install PREFIX=${D}/usr/
>
>
>
> bbplain "Install Done"
>
> }
>
>
>
> FILES_${PN}-dbg = "/usr/src/debug/canfestival"
>
> FILES_${PN}-dev = "/usr/lib/libcanfestival*.a /usr/include/canfestival/*.h"
>
> FILES_${PN} = "/usr/lib/libcanfestival*.a /usr/lib/libcanfestival*.so"
>
>
>
> #PACKAGE_BEFORE_PN = "${PN}-info"
>
> #FILES_${PN}-info = "usr/lib/pkgconfig"
>
>
>
> I've fiddled with the various FILES lines, but nothing that I do gets the .a
> files copied to the SDK sysroot /usr/lib directory.
>
>
>
> Any insight into what is going wrong would be greatly appreciated.
>
>
>
> Assuming the static libs are being built and installed correctly they should
> be packaged correctly by the default packaging rules. ie you shouldn't need
> to tweak any FILES_xxx values.
>
>
>
> However you will need to ensure that the -staticdev package gets included in
> the SDK. Assuming you always want the static libs for this p