[yocto] Resend QA cycle report for 2.4.2 RC2

[Yeoh, Ee Peng]

Hello All,
Resend the full report for 2.4.2 RC2 with updated information:  
https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2

=== Summary 

The QA cycle for release 2.4.2 RC2 was completed including the performance 
test.  Team had discovered 3 new bugs 
(oeselftest.sstatetests.test_sstate_sametune_samesigs failed, x11perf failed on 
minnowmax and nuc, toaster run again button does not behaved as expected).

For testrun# 9206-9212, testopia testcases not 100% completed as there are some 
outdated testcases that were no longer available in oeqa/selftest testsuite, 
pending testopia data cleanup. 

Performance tests were executed for both 2.4.2 RC2 and 2.4.1 RC1 (as regression 
and benchmark) on these new machines in linux foundation. 

=== QA-Hints

QA shows no major bug.

=== Bugs 

New Bugs
[1] 12587 - [2.4.2 rc2] test_sstate_sametune_samesigs (sstatetests.SStateTests) 
[2] 12590 - [2.4.2 rc2] No. of Chars/sec For Yocto Image is very Low To that of 
Ubuntu [3] 12591 - [2.4.2 rc2] Run again button from all builds page must run 
the specified task

 Links =
1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12587
2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12590
3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12591

Regards
Ee Peng 


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

Re: [yocto] [meta-raspberrypi] how to install rpi-config package?

[Paul Barker]

On Thu, Mar 8, 2018 at 6:20 AM, kk  wrote:
> This is ok:
> $ bitbake rpi-config
> But I check the image directory under workdir, I found nothing in it, and no
> command raspi-config.
>

The rpi-config recipe creates the config.txt file in the
"tmp/deploy/images//bcm2835-bootfiles/" directory (if I've
got the path right) which is then copied to the boot partition for an
SD card image.

I believe raspi-config is specific to the Raspbian distribution and
isn't used in images built with OpenEmbedded.

-- 
Paul Barker
Togán Labs Ltd
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] how to install rpi-config package?

[Andrei Gherzan]

On Thu, Mar 8, 2018 at 11:17 AM, Paul Barker  wrote:

> On Thu, Mar 8, 2018 at 6:20 AM, kk  wrote:
> > This is ok:
> > $ bitbake rpi-config
> > But I check the image directory under workdir, I found nothing in it,
> and no
> > command raspi-config.
> >
>
> The rpi-config recipe creates the config.txt file in the
> "tmp/deploy/images//bcm2835-bootfiles/" directory (if I've
> got the path right) which is then copied to the boot partition for an
> SD card image.
>
> I believe raspi-config is specific to the Raspbian distribution and
> isn't used in images built with OpenEmbedded.


Paul is correct. Actually there is almost a name clash here. rpi-config in
meta-raspberrypi is a recipe which deploys the config.txt in deploy
directory. The raspbian tool that you refer to is not included / integrated
in oe but has a very similar name: raspi-config . So at this point when
baking rpi-config all you get is a config.txt in the deploy directory.

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

Re: [yocto] Resend QA cycle report for 2.4.2 RC2

[Jolley, Stephen K]

Why are we showing 62 (2%) of the test cases as Idle.  (Not Run).  Were they 
blocked? What happened to them?

Thanks,

Stephen

-Original Message-
From: Yeoh, Ee Peng 
Sent: Thursday, March 08, 2018 1:41 AM
To: 'yocto@yoctoproject.org' ; Purdie, Richard 
; Jolley, Stephen K ; 
Jordan, Robin L ; Zhang, Jessica 
; Lock, Joshua G ; Eggleton, 
Paul 
Cc: Sangal, Apoorv 
Subject: Resend QA cycle report for 2.4.2 RC2

Hello All,
Resend the full report for 2.4.2 RC2 with updated information:  
https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2

=== Summary 

The QA cycle for release 2.4.2 RC2 was completed including the performance 
test.  Team had discovered 3 new bugs 
(oeselftest.sstatetests.test_sstate_sametune_samesigs failed, x11perf failed on 
minnowmax and nuc, toaster run again button does not behaved as expected).

For testrun# 9206-9212, testopia testcases not 100% completed as there are some 
outdated testcases that were no longer available in oeqa/selftest testsuite, 
pending testopia data cleanup. 

Performance tests were executed for both 2.4.2 RC2 and 2.4.1 RC1 (as regression 
and benchmark) on these new machines in linux foundation. 

=== QA-Hints

QA shows no major bug.

=== Bugs 

New Bugs
[1] 12587 - [2.4.2 rc2] test_sstate_sametune_samesigs (sstatetests.SStateTests) 
[2] 12590 - [2.4.2 rc2] No. of Chars/sec For Yocto Image is very Low To that of 
Ubuntu [3] 12591 - [2.4.2 rc2] Run again button from all builds page must run 
the specified task

 Links =
1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12587
2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12590
3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12591

Regards
Ee Peng 


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

[yocto] New Release Number 2.99 in Bugzilla

[Stephano Cetola]

The Yocto Project team is moving to a new release planning process and I
want to provide an overview as there will be some things I need from
those of you making changes and adding things to Bugzilla.

Overview:
We are moving to a “Pull” process for planning rather than a “Push”
process.  What this means is that we will start with an empty 2.6
release bucket and pull bugs and enhancements in that map to our top
priorities rather than push things out of a giant bucket.  We are hoping
this will help us start 2.6 with a very clear idea as to what we will
focus on and be much less overwhelming than pushing a giant snowball
through each release.

How does this effect you?
If you are pushing bugs/enhancements to the next release or adding new
bugs/enhancements for the next release you need to be aware of the
following:

-We have a M+ Future status that holds items that are important and need
to be addressed soon.  This bucket is pretty big.
-We have moved all 2.6 features and bugs to a 2.99 release.  This bucket
is a temporary hold for the items that didn’t make it into 2.5 and are
at the very top of our list for review to pull in.  We don’t want them
to get lost in the M+ Future bucket.  Once 2.6 planning is complete,
this 2.99 bucket will be empty and removed.
-If you are adding new bugs and enhancements that you believe should be
slotted for 2.6, please enter them as 2.99.
-If you are pushing anything from 2.5 to 2.6, please enter it as 2.99.

Please let me know if you have any questions about this.

Thanks,
Stephano

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[robert_joslyn]

"Marcelo E. Magallon"  wrote on 03/08/2018 
01:00:28 PM:

> From: "Marcelo E. Magallon" 
> To: , 
> Cc: "yocto@yoctoproject.org" 
> Date: 03/08/2018 01:01 PM
> Subject: Re: [yocto] btrfs-tools Requires libgcc_s.so.1
> 
> Sorry to go off on a tangent:
> 
> On Fri, Mar 04, 2016 at 04:12:54PM -0800, robert_jos...@selinc.com 
wrote:
> 
> >> > root@test:~# btrfs scrub start /
> >> > scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd
> >(pid=333)
> >> > libgcc_s.so.1 must be installed for pthread_cancel to work
> >> >
> >> > I can solve this by adding libgcc to RDEPENDS for btrfs-tools.
> 
> I ran into the same thing with my device, different package. I 
> don't understand the fix:
> 
> >Signed-off-by: Robert Joslyn 
> >---
> >diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
> >b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
> >index 37c622b..cc2ccfc 100644
> >--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
> >+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
> >@@ -11,6 +11,7 @@ LICENSE = "GPLv2"
> > LIC_FILES_CHKSUM = "
file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067"
> > SECTION = "base"
> > DEPENDS = "util-linux attr e2fsprogs lzo acl"
> >+RDEPENDS_${PN} = "libgcc"
> 
> What is this doing?
> 
> My understanding until a couple of days ago is that this will 
> simply pull the "libgcc" package into the image, add a dependency 
> in the binary package and NOTHING more. It won't change the way 
> binaries are linked, it won't change flags passed to the 
> compiler, etc.

Your understanding is basically correct, RDEPENDS specifies a runtime 
dependency. For btrfs-tools, it doesn't change the build, it simply makes 
sure that the libgcc package is installed on the target if btrfs-tools is 
also installed on the target. If there is more going on with RDEPENDS 
besides the final rpm/ipk/deb packaging, someone with more bitbake 
knowledge will have to provide more information.

> I'm confused because in my case libgcc_s.so.1 is already in the 
> image, before this change, but this change seems to be fixing the 
> issue, and I don't understand why.

In the case of btrfs-tools, it was simply that it needed libgcc_s.so.1 at 
runtime on the target, which my patch fixed. For me, the image I was 
building normally worked fine because some other package would pull in 
libgcc, but when testing on a minimal image, I would get that error. I'm 
not sure about your specific case. If you do have libgcc on the target, an 
application that needs it doesn't really care what package pulled it into 
the image, all that matters is that it's installed.

Robert

> 
> Any clues?
> 
> Thanks!
> 
> Marcelo
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Marcelo E. Magallon]

Sorry to go off on a tangent:

On Fri, Mar 04, 2016 at 04:12:54PM -0800, robert_jos...@selinc.com wrote:


> root@test:~# btrfs scrub start /
> scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd

(pid=333)

> libgcc_s.so.1 must be installed for pthread_cancel to work
>
> I can solve this by adding libgcc to RDEPENDS for btrfs-tools.


I ran into the same thing with my device, different package. I 
don't understand the fix:



Signed-off-by: Robert Joslyn 
---
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
index 37c622b..cc2ccfc 100644
--- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
+++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
@@ -11,6 +11,7 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067"
SECTION = "base"
DEPENDS = "util-linux attr e2fsprogs lzo acl"
+RDEPENDS_${PN} = "libgcc"


What is this doing?

My understanding until a couple of days ago is that this will 
simply pull the "libgcc" package into the image, add a dependency 
in the binary package and NOTHING more. It won't change the way 
binaries are linked, it won't change flags passed to the 
compiler, etc.


I'm confused because in my case libgcc_s.so.1 is already in the 
image, before this change, but this change seems to be fixing the 
issue, and I don't understand why.


Any clues?

Thanks!

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Marcelo E. Magallon]

On Thu, Mar 08, 2018 at 03:16:44PM -0600, Mark Hatle wrote:


RDEPENDS are automatically promoted to DEPENDS (build-time).  I would normally
expect libgcc_s.so.1 to be present via the typical default depends.  Does your
recipe have an INHIBIT_DEFAULT_DEPENDS (I think that is it?) defined?  If so,
you would need to manually add all build dependencies then.


INHIBIT_DEFAULT_DEPS.

No, it doesn't, but that's a good hint.


An executable or library with a stated library dependency (soname) will
automatically get an RDEPENDS.  The only time you should have to do an
RDEPENDS_${PN} of a library is when that library is 'dlopened'.  (This is the
case for things like pam modules.)


This is also the case in this situation.

glibc has this bit of code in pthread_cancel_init:

  handle = __libc_dlopen_mode (LIBGCC_S_SO, RTLD_NOW | __RTLD_DLOPEN);

  if (handle == NULL
  || (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
  || (personality = __libc_dlsym (handle, "__gcc_personality_v0")) 
== NULL
  || (forcedunwind = __libc_dlsym (handle, "_Unwind_ForcedUnwind"))
 == NULL
  || (getcfa = __libc_dlsym (handle, "_Unwind_GetCFA")) == NULL
#ifdef ARCH_CANCEL_INIT
  || ARCH_CANCEL_INIT (handle)
#endif
  )
__libc_fatal (LIBGCC_S_SO " must be installed for pthread_cancel to 
work\n");

it's dlopen()ing libgcc_s.so.1 in order to get thread 
cancellation to work via exception unwinding.


In my case, libgcc_s.so.1 is installed in the image before adding 
the RDEPENDS.


What doesn't make sense to me is why in both the OP's and my 
case, adding RDEPENDS_${PN} += "libgcc" is fixing anything. As 
you said, this is promoted to a DEPENDS, so libgcc is available 
at compile time, but that shouldn't change anything that I can 
see.


Thanks for looking at this,

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Mark Hatle]

On 3/8/18 3:00 PM, Marcelo E. Magallon wrote:
> Sorry to go off on a tangent:
> 
> On Fri, Mar 04, 2016 at 04:12:54PM -0800, robert_jos...@selinc.com wrote:
> 
 root@test:~# btrfs scrub start /
 scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd
>> (pid=333)
 libgcc_s.so.1 must be installed for pthread_cancel to work

 I can solve this by adding libgcc to RDEPENDS for btrfs-tools.
> 
> I ran into the same thing with my device, different package. I 
> don't understand the fix:
> 
>> Signed-off-by: Robert Joslyn 
>> ---
>> diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
>> b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
>> index 37c622b..cc2ccfc 100644
>> --- a/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
>> +++ b/meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb
>> @@ -11,6 +11,7 @@ LICENSE = "GPLv2"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=fcb02dc552a041dee27e4b85c7396067"
>> SECTION = "base"
>> DEPENDS = "util-linux attr e2fsprogs lzo acl"
>> +RDEPENDS_${PN} = "libgcc"
> 
> What is this doing?
> 
> My understanding until a couple of days ago is that this will 
> simply pull the "libgcc" package into the image, add a dependency 
> in the binary package and NOTHING more. It won't change the way 
> binaries are linked, it won't change flags passed to the 
> compiler, etc.
> 
> I'm confused because in my case libgcc_s.so.1 is already in the 
> image, before this change, but this change seems to be fixing the 
> issue, and I don't understand why.

RDEPENDS are automatically promoted to DEPENDS (build-time).  I would normally
expect libgcc_s.so.1 to be present via the typical default depends.  Does your
recipe have an INHIBIT_DEFAULT_DEPENDS (I think that is it?) defined?  If so,
you would need to manually add all build dependencies then.

An executable or library with a stated library dependency (soname) will
automatically get an RDEPENDS.  The only time you should have to do an
RDEPENDS_${PN} of a library is when that library is 'dlopened'.  (This is the
case for things like pam modules.)

--Mark

> Any clues?
> 
> Thanks!
> 
> Marcelo
> 

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Marcelo E. Magallon]

On Thu, Mar 08, 2018 at 01:30:28PM -0800, robert_jos...@selinc.com wrote:


In the case of btrfs-tools, it was simply that it needed libgcc_s.so.1 at
runtime on the target, which my patch fixed. For me, the image I was
building normally worked fine because some other package would pull in
libgcc, but when testing on a minimal image, I would get that error. I'm
not sure about your specific case. If you do have libgcc on the target, an
application that needs it doesn't really care what package pulled it into
the image, all that matters is that it's installed.


Ah, that makes sense in your case. Thanks for clarifying!

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

[yocto] passwd fails for other users than root

[Arno Steffens]

I have 2 extra users (added with useradd_example.bb). Login works for all 3 
parties.

While login works, passwd (to change it) doesn't work for the extra users. They 
will asked for the old one - which fails.
Root is not to be asked for old password. That's way root can change password 
for all. 

The strange issue is, that after root changes password for users, they can do 
it by themselves.
Seems that login and passwd use different algos!?!?

Same password, but different hashes:
before (created by yocto)
user:$6$bk.Az/8KVV$v3TyAlroQeBZA3faJ.DxCVsCUBZaSAvB4FkuNkLDdsIchrmz6OnUGRnQI5BOgOjQ3mvj9QL3US6Amf2VWr0.j/:17598:0:9:7:::
behind (changed by root):
user:$1$d3Uo1g82$Il2kYQj8qadzQvkwUU4Ia.:17598:0:9:7:::

Edit: After a few further test I found that this has an effect:
I used EXTRA_IMAGE_FEATURES += "read-only-rootfs" to create a read-only-rootf 
(by default). 
But of course I did make the partition writeable before attempting to change 
the password.
But for some strange reasons this is not same. What might be the reason?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Version numbering of dependencies

[radioconfusion]

Hello all

I'm confused with version numbering of shared libs dependencies on yocto
environment. I’m using Morty but the thing looks like same with newer releases.

Let me explain the problem.

I'll take Curl package for example. We all know that the Curl recipe makes
libcurl-package also. Ok, now I want to add some important compiling options
to Curl and I make curl_%.bbappend file to my custom layer with the wanted
customizations. I don't want to raise the original version number of Curl
and I use PR_append = "-myver1" instead. Now I get packages
curl_x.y.z-r0-myver1_blabla.ipk and
libcurl_x.y.z-r0-myver1_blabla.ipk. That’s very good for me.

The problem is that: Now the Curl ipk package dependencies are

Depends: libc6 (>= a.b), libcurl4 (>= x.y.z), libz1 (>= c.d.e)

And I think there should be:

Depends: libc6 (>= a.b), libcurl4 (>= x.y.z-r0-myver1), libz1 (>= c.d.e)

or something like that.

Now I can upgrade Curl from x.y.z to x.y.z-r0-myver1 on my device without
upgrading the libcurl and that breaks a lot of things. Ok, normally
'opkg upgrade' installs both of them but in case of network failure or an other
failure this problem can be happened.

I found that package.bbclass uses PKGV, PKGV_+pkg and PV_+pkg environment
variables to get version number for dependencies.
If I change it to use EXTENDPKGV, I get expected results.

Is this a bug or am I doing something wrong?

The patch I tried:

--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1620,7 +1620,9 @@ python package_do_shlibs() {
 needs_ldconfig = False
 bb.debug(2, "calculating shlib provides for %s" % pkg)

-pkgver = d.getVar('PKGV_' + pkg, True)
+pkgver = d.getVar('EXTENDPKGV', True)
+if not pkgver:
+pkgver = d.getVar('PKGV_' + pkg, True)
 if not pkgver:
 pkgver = d.getVar('PV_' + pkg, True)
 if not pkgver:

Best Regards,
Jussi
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How and where does yocto find lighttpd-module-fastcgi?

[Wayne Witzke]

Hello everyone,

I'm very new to Yocto, and I'm currently building an embedded system 
with a web interface. As I worked through the process of creating a 
Yocto configuration and layer to configure the specific build I needed 
(based on core-image-minimal), I discovered that I could add packages to 
my image by adding it to the configuration file via 
CORE_EXTRA_IMAGES_INSTALL. In this way, I was able to add lighttpd, php, 
php-cgi, and lighttpd-module-fastcgi to my build. It worked great!


However, now I am attempting to determine if mod_openssl is installed on 
my server, and using "CORE_EXTRA_IMAGES_INSTALL += 
'lighttpd-module-openssl'" to simply add it does NOT magically work like 
it did with lighttpd-module-fastcgi. My original guess was that adding 
"CORE_EXTRA_IMAGES_INSTALL += 'lighttpd-module-fastcgi'" caused a 
configuration option to be matched in the lighttpd.bb file so that the 
appropriate build option was used when building lighttpd. However, 
fastcgi doesn't actually show up in that file at all, and openssl does, 
so that clearly isn't the option . . . furthermore, mod_fastcgi doesn't 
appear in *any* of the layers I'm using to build, except in the 
lighttpd.conf portion of the recipe-extended/lighttpd directory structure.


So, my question is, how does bitbake know what to do when I add 
lighttpd-module-fastcgi, and where in the world does it find the source 
for mod_fastcgi?


Thank you in advance for your help :)

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Patrick Ohly]

On Thu, 2018-03-08 at 19:18 -0600, Mark Hatle wrote:
> Yes, the dlopen means the automated processing can't identify the
> need.. and
> then the RDEPEND is the correct solution.
> 
> (This might be a reasonable bug/enhancement request to the
> system.  Look for
> pthread_cancel and automatically infer that libgcc is required.)

There is already a feature request for that:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10954

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


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

Re: [yocto] How and where does yocto find lighttpd-module-fastcgi?

[Andre McCurdy]

On Thu, Mar 8, 2018 at 1:52 PM, Wayne Witzke  wrote:
>
> However, now I am attempting to determine if mod_openssl is installed on my
> server, and using "CORE_EXTRA_IMAGES_INSTALL += 'lighttpd-module-openssl'"
> to simply add it does NOT magically work like it did with
> lighttpd-module-fastcgi. My original guess was that adding
> "CORE_EXTRA_IMAGES_INSTALL += 'lighttpd-module-fastcgi'" caused a
> configuration option to be matched in the lighttpd.bb file so that the
> appropriate build option was used when building lighttpd.

No, that's not how it works. A very key point to understand with OE is
that options associated with one recipe can never affect the build of
another recipe (in this case, the image recipe can't affect the build
of the lighttpd recipe).

If adding lighttpd-module-fastcgi to your image worked, it's because
the lighttpd recipe was already creating that package.

> However, fastcgi
> doesn't actually show up in that file at all, and openssl does, so that
> clearly isn't the option . . . furthermore, mod_fastcgi doesn't appear in
> *any* of the layers I'm using to build, except in the lighttpd.conf portion
> of the recipe-extended/lighttpd directory structure.

If lighttpd doesn't have a configure option to control building of the
fastcgi module, then there won't be a PACKAGECONFIG option for it in
the recipe - it will just always be built.

(Even if lighttpd does have a configure option for the fastcgi module,
there's no guarantee that the recipe will allow it to be controlled -
it's common for PACKAGECONFIG options in recipes to only reflect the
configure options which people care about the most).

> So, my question is, how does bitbake know what to do when I add
> lighttpd-module-fastcgi,

The build for lighttpd isn't affected by whether or not you add
lighttpd-module-fastcgi to your image.

ie running "bitbake lighttpd", should always result in a package for
lighttpd-module-fastcgi being placed in tmp/deploy/ipk/i586/ (or
whatever your packaging format / architecture combination is). It
doesn't matter what image you may choose to build later, or what
packages you choose to include in it.

> and where in the world does it find the source for
> mod_fastcgi?

The source which gets compiled into lighttpd-module-fastcgi must be
coming from lighttpd.

> Thank you in advance for your help :)
>
> Wayne
> --
> ___
> 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] New Release Number 2.99 in Bugzilla

[akuster]

Stephano


On 03/08/2018 10:46 AM, Stephano Cetola wrote:
> The Yocto Project team is moving to a new release planning process and I
> want to provide an overview as there will be some things I need from
> those of you making changes and adding things to Bugzilla.
>
> Overview:
> We are moving to a “Pull” process for planning rather than a “Push”
> process.  What this means is that we will start with an empty 2.6
> release bucket and pull bugs and enhancements in that map to our top
> priorities rather than push things out of a giant bucket.  We are hoping
> this will help us start 2.6 with a very clear idea as to what we will
> focus on and be much less overwhelming than pushing a giant snowball
> through each release.
>
> How does this effect you?
> If you are pushing bugs/enhancements to the next release or adding new
> bugs/enhancements for the next release you need to be aware of the
> following:
>
> -We have a M+ Future status that holds items that are important and need
> to be addressed soon.  This bucket is pretty big.
> -We have moved all 2.6 features and bugs to a 2.99 release.  This bucket
> is a temporary hold for the items that didn’t make it into 2.5 and are
> at the very top of our list for review to pull in.  We don’t want them
> to get lost in the M+ Future bucket.  Once 2.6 planning is complete,
> this 2.99 bucket will be empty and removed.
> -If you are adding new bugs and enhancements that you believe should be
> slotted for 2.6, please enter them as 2.99.
> -If you are pushing anything from 2.5 to 2.6, please enter it as 2.99.
>
> Please let me know if you have any questions about this.

thanks for the explanation. I wonder if this should be sent to core list
as I believe some bug categories may be non yocto project based or folks
using Poky may not be on list list, like bitbake, yocto-linux etc. Cross
posting may be ok in this case.

- Armn
>
> Thanks,
> Stephano
>

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

Re: [yocto] btrfs-tools Requires libgcc_s.so.1

[Mark Hatle]

On 3/8/18 4:10 PM, Marcelo E. Magallon wrote:
> On Thu, Mar 08, 2018 at 03:16:44PM -0600, Mark Hatle wrote:
> 
>> RDEPENDS are automatically promoted to DEPENDS (build-time).  I would 
>> normally
>> expect libgcc_s.so.1 to be present via the typical default depends.  Does 
>> your
>> recipe have an INHIBIT_DEFAULT_DEPENDS (I think that is it?) defined?  If so,
>> you would need to manually add all build dependencies then.
> 
> INHIBIT_DEFAULT_DEPS.
> 
> No, it doesn't, but that's a good hint.
> 
>> An executable or library with a stated library dependency (soname) will
>> automatically get an RDEPENDS.  The only time you should have to do an
>> RDEPENDS_${PN} of a library is when that library is 'dlopened'.  (This is the
>> case for things like pam modules.)
> 
> This is also the case in this situation.
> 
> glibc has this bit of code in pthread_cancel_init:
> 
> handle = __libc_dlopen_mode (LIBGCC_S_SO, RTLD_NOW | __RTLD_DLOPEN);
>   
> if (handle == NULL
> || (resume = __libc_dlsym (handle, "_Unwind_Resume")) == NULL
> || (personality = __libc_dlsym (handle, "__gcc_personality_v0")) 
> == NULL
> || (forcedunwind = __libc_dlsym (handle, "_Unwind_ForcedUnwind"))
>== NULL
> || (getcfa = __libc_dlsym (handle, "_Unwind_GetCFA")) == NULL
>   #ifdef ARCH_CANCEL_INIT
> || ARCH_CANCEL_INIT (handle)
>   #endif
> )
>   __libc_fatal (LIBGCC_S_SO " must be installed for pthread_cancel to 
> work\n");
> 
> it's dlopen()ing libgcc_s.so.1 in order to get thread 
> cancellation to work via exception unwinding.

Yes, the dlopen means the automated processing can't identify the need.. and
then the RDEPEND is the correct solution.

(This might be a reasonable bug/enhancement request to the system.  Look for
pthread_cancel and automatically infer that libgcc is required.)

> In my case, libgcc_s.so.1 is installed in the image before adding 
> the RDEPENDS.
> 
> What doesn't make sense to me is why in both the OP's and my 
> case, adding RDEPENDS_${PN} += "libgcc" is fixing anything. As 
> you said, this is promoted to a DEPENDS, so libgcc is available 
> at compile time, but that shouldn't change anything that I can 
> see.

I'm guessing if it's not available at compile time that some behavior is
changing (maybe not using pthread_cancel?)

Not sure... but at least the reason the RDEPEND resolves the runtime issue is
now clear to me, and within the design.

--Mark

> Thanks for looking at this,
> 
> Marcelo
> 

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

Re: [yocto] Resend QA cycle report for 2.4.2 RC2

[Yeoh, Ee Peng]

Hi Stephen,

Those idle test cases are actually belongs to the outdated testcases inside 
Testopia, GDC had opened a Bugzilla ticket to remove and replace outdated and 
duplicated test cases. We are in progress of removing ducplicated test cases, 
next step is to remove outdated test cases using automated script that utilize 
testopia python api. 

https://bugzilla.yoctoproject.org/show_bug.cgi?id=12435

For testrun# 9206-9212, testopia testcases not 100% completed as there are some 
outdated testcases that were no longer available in oeqa/selftest testsuite, 
pending testopia data cleanup.

Please let me know if any more question.

Thanks,
Ee Peng 

-Original Message-
From: Jolley, Stephen K 
Sent: Friday, March 9, 2018 12:48 AM
To: Yeoh, Ee Peng ; 'yocto@yoctoproject.org' 
; Purdie, Richard ; Jordan, 
Robin L ; Zhang, Jessica ; 
Lock, Joshua G ; Eggleton, Paul 

Cc: Sangal, Apoorv 
Subject: RE: Resend QA cycle report for 2.4.2 RC2

Why are we showing 62 (2%) of the test cases as Idle.  (Not Run).  Were they 
blocked? What happened to them?

Thanks,

Stephen

-Original Message-
From: Yeoh, Ee Peng 
Sent: Thursday, March 08, 2018 1:41 AM
To: 'yocto@yoctoproject.org' ; Purdie, Richard 
; Jolley, Stephen K ; 
Jordan, Robin L ; Zhang, Jessica 
; Lock, Joshua G ; Eggleton, 
Paul 
Cc: Sangal, Apoorv 
Subject: Resend QA cycle report for 2.4.2 RC2

Hello All,
Resend the full report for 2.4.2 RC2 with updated information:  
https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2

=== Summary 

The QA cycle for release 2.4.2 RC2 was completed including the performance 
test.  Team had discovered 3 new bugs 
(oeselftest.sstatetests.test_sstate_sametune_samesigs failed, x11perf failed on 
minnowmax and nuc, toaster run again button does not behaved as expected).

For testrun# 9206-9212, testopia testcases not 100% completed as there are some 
outdated testcases that were no longer available in oeqa/selftest testsuite, 
pending testopia data cleanup. 

Performance tests were executed for both 2.4.2 RC2 and 2.4.1 RC1 (as regression 
and benchmark) on these new machines in linux foundation. 

=== QA-Hints

QA shows no major bug.

=== Bugs 

New Bugs
[1] 12587 - [2.4.2 rc2] test_sstate_sametune_samesigs (sstatetests.SStateTests) 
[2] 12590 - [2.4.2 rc2] No. of Chars/sec For Yocto Image is very Low To that of 
Ubuntu [3] 12591 - [2.4.2 rc2] Run again button from all builds page must run 
the specified task

 Links =
1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12587
2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12590
3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12591

Regards
Ee Peng 


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