[yocto] [meta-raspberrypi][PATCH] sdcard_image: Depend on do_deploy for kernel

[Khem Raj]

SD image is expecting dtb files to be deployed in
deploy area, this step however is done when do_deploy
of kernel is finished and we need to pin that in
dependency list, otherwise there are build race conditions
during builds especially visible when building with initramfs
enabled.

Signed-off-by: Khem Raj 
---
 classes/sdcard_image-rpi.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 2e9bdb3..f20ff04 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -53,7 +53,7 @@ IMAGE_DEPENDS_rpi-sdimg = " \
parted-native \
mtools-native \
dosfstools-native \
-   virtual/kernel \
+   virtual/kernel:do_deploy \
${IMAGE_BOOTLOADER} \
${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage', 
'u-boot', '',d)} \
"
-- 
2.7.3

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

Re: [yocto] Problems building live image

[K Richard Pixley]

On 3/14/16 15:58 , Rudolf Streif wrote:

Richard,

On Mon, Mar 14, 2016 at 1:55 PM, K Richard Pixley > wrote:


If I add that line, (

IMAGE_FSTYPES = "vmdk"

), to my local.conf, I get:

rich@burgess> time bitbake core-image-minimal
ERROR:  OE-core's config sanity checker detected a potential
misconfiguration.
Either fix the cause of this error or at your own risk
disable the checker (see sanity.conf).
Following is the list of potential problems / advisories:

Error, IMAGE_FSTYPES vmdk and live can't be built together


Summary: There was 1 ERROR message shown, returning a non-zero
exit code.

Building yocto-2.0 for genericx86-64.  What am I doing wrong?

Nothing really. The issue is conflicting SYSLINUX_LABELS for the boot 
options. For the live image the labels are boot and install while 
there is only boot for the vmdk image. Prior to 2.0 Jethro you could 
specify both, live and vmdk, in IMAGE_FSTYPES. It built both but the 
live image was missing the install boot option (it had two boot 
options instead). This function in syslinux.bbclass now flags the issue:


# Some of the vars for vm and live image are conflicted, this function
# is used for fixing the problem.
def syslinux_set_vars(d, suffix):
   vars = ['SYSLINUX_ROOT', 'SYSLINUX_CFG', 'LABELS', 'INITRD']
   for var in vars:
   var_with_suffix = var + '_'+ suffix
   if d.getVar(var, True):
   bb.warn('Found potential conflicted var %s, please use %s 
rather than %s'% \

   (var, var_with_suffix, var))
   elif d.getVar(var_with_suffix, True):
   d.setVar(var, d.getVar(var_with_suffix, True))


 Technically, in my opinion, you should be able to build both at the 
same time. You may want to disable the sanity checker.

Thank you.

What stops us from building different boot labels for different images?  
That seems like the obvious choice.  Or perhaps, using "boot" for all 
syslinux images and adding "install" for "live" images.


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

[yocto] OpenEmbedded Developer meeting April 8 after ELC/Yocto Project developer day

[Philip Balister]

Yes, I am nagging.

On the Friday after ELC in San Diego (Yocto Project Dev Day is
Thursday), we will have a developer meeting near the conference venue
Jefro has arranged for a room at the Marriot next to the conference
venue, sponsored by the Yocto Project.

OpenEmbedded would like to thank the Yocto Project for sponsoring the
room. If you would like to sponsor a future meeting, let me know. Also,
we can accept tax deductible contributions via Software in the Public
Interest (http://spi-inc.org/).

http://openembedded.org/wiki/OEDAM_2016

At these meetings we try to follow an agenda we develop before hand on
the wiki page. I've created a rough agenda by posting notes from the
meeting in Dublin. Everyone, please go over the notes and add remarks
for completed items.

Please add your name to the attendee list on the wiki. You'll need an
account, I should get an email when you sign up, but nag me if it isn't
approved quickly. I've seen some issues with the emails from the wiki.

You can also bring up issues at the meeting. We only have one day
scheduled for the meeting, so a little pre-planning helps keep us on time.

Everyone involved in the project is welcome to attend, no how
knowledgeable in the overall OpenEmbedded project We like to hear from
people from many different use cases.

Thanks for reading and we are looking forward to meeting new people!

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

Re: [yocto] Problems building live image

[Rudolf Streif]

Richard,

On Mon, Mar 14, 2016 at 1:55 PM, K Richard Pixley  wrote:

> If I add that line, (
>
> IMAGE_FSTYPES = "vmdk"
>
> ), to my local.conf, I get:
>
> rich@burgess> time bitbake core-image-minimal
> ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
> Either fix the cause of this error or at your own risk disable the
> checker (see sanity.conf).
> Following is the list of potential problems / advisories:
>
> Error, IMAGE_FSTYPES vmdk and live can't be built together
>
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
> Building yocto-2.0 for genericx86-64.  What am I doing wrong?
>
> Nothing really. The issue is conflicting SYSLINUX_LABELS for the boot
options. For the live image the labels are boot and install while there is
only boot for the vmdk image. Prior to 2.0 Jethro you could specify both,
live and vmdk, in IMAGE_FSTYPES. It built both but the live image was
missing the install boot option (it had two boot options instead). This
function in syslinux.bbclass now flags the issue:

# Some of the vars for vm and live image are conflicted, this function
# is used for fixing the problem.
def syslinux_set_vars(d, suffix):
   vars = ['SYSLINUX_ROOT', 'SYSLINUX_CFG', 'LABELS', 'INITRD']
   for var in vars:
   var_with_suffix = var + '_' + suffix
   if d.getVar(var, True):
   bb.warn('Found potential conflicted var %s, please use %s rather
than %s' % \
   (var, var_with_suffix, var))
   elif d.getVar(var_with_suffix, True):
   d.setVar(var, d.getVar(var_with_suffix, True))


 Technically, in my opinion, you should be able to build both at the same
time. You may want to disable the sanity checker.

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

Re: [yocto] Problems building live image

[K Richard Pixley]

If I add that line, (

IMAGE_FSTYPES = "vmdk"

), to my local.conf, I get:

   rich@burgess> time bitbake core-image-minimal
   ERROR:  OE-core's config sanity checker detected a potential
   misconfiguration.
Either fix the cause of this error or at your own risk disable
   the checker (see sanity.conf).
Following is the list of potential problems / advisories:

Error, IMAGE_FSTYPES vmdk and live can't be built together


   Summary: There was 1 ERROR message shown, returning a non-zero exit
   code.

Building yocto-2.0 for genericx86-64.  What am I doing wrong?

--rich

On 3/13/16 23:09 , Khem Raj wrote:

just use IMAGE_FSTYPES = "vmdk" if you plan to use virtualbox and need
a raw image.

On Sun, Mar 13, 2016 at 10:16 PM, Gary Thomas  wrote:

I'd like to to some testing that qemu just doesn't seem up to
so I attempted to build a live ISO per the documentation. I
added these lines to local.conf:
   IMAGE_FSTYPES_genericx86 += "live"
   NOISO_genericx86 = "0"

When I try to build core-image-base I get this error:
   ERROR: INITRD_IMAGE_LIVE core-image-minimal-initramfs cannot use image
live, hddimg or iso.
   ERROR: Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.
   ERROR: Failed to parse recipe:
/local/poky-cutting-edge/meta/recipes-core/images/core-image-minimal-initramfs.bb

I'm using a recent Poky checkout (d53413d3a8444c38a83ea37867c8af7754d8e702)

Am I just doing something wrong here? I was following this section of the
mega-manual:

   26.56. image-live.bbclass¶

   The image-live class supports building "live" images.

   Normally, you do not use this class directly. Instead, you add "live" to
IMAGE_FSTYPES.
   For example, if you were building an ISO image, you would add "live" to
IMAGE_FSTYPES,
   set the NOISO variable to "0" and the build system would use the
image-live class to
   build the ISO image.

I don't have any available hardware for this testing, so I thought
I'd use VirtualBox.  Is this a reasonable approach?  I want to use
a live ISO so I get a writable file system.  I tried just using the
.hddimage but that doesn't boot with VirtualBox :-(

To be clear, along with the additions above in local.conf, I tried:
   $ MACHINE=genericx86 bitbake core-image-base

Thanks for any ideas

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
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] kernel: "devtool modify -x" issue

[Steve Rae]

awesome! Thanks

On Mon, Mar 14, 2016 at 1:53 PM, Paul Eggleton
 wrote:
> I hope we are talking a week or less, but I'm not able to give you a 
> definitive
> answer - it depends on patch review and how busy we are dealing with issues on
> the master branch among other things.
>
> Cheers,
> Paul
>
> On Mon, 14 Mar 2016 13:49:40 Steve Rae wrote:
>> thanks much...
>> I am very new to this: does "not long though" mean 2-3 days or 2-3 weeks or
>> ???
>>
>>
>> On Mon, Mar 14, 2016 at 1:47 PM, Paul Eggleton
>>
>>  wrote:
>> > Hi Steve,
>> >
>> > I've just sent out the patches; beyond that it's a matter of the stable
>> > branch testing and integration process. I hope not long though.
>> >
>> > Cheers,
>> > Paul
>> >
>> > On Mon, 14 Mar 2016 11:51:08 Steve Rae wrote:
>> >> Paul -- please ETA for getting this into the "jethro" branch.
>> >> Thanks, Steve
>> >>
>> >> On Fri, Mar 11, 2016 at 10:11 AM, Steve Rae 
> wrote:
>> >> > OK - this seems to build successfully - Thanks!
>> >> >
>> >> >>> although I still do see the line:
>> >> >  Cloning into '/tmp/devtool6ZA4IK/workdir/source'...
>> >> >
>> >> > On Thu, Mar 10, 2016 at 7:07 PM, Paul Eggleton
>> >> >
>> >> >  wrote:
>> >> >> On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
>> >> >>> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
>> >> >>> > ( using jethro )
>> >> >>> >
>> >> >>> > I have a 'linux-yocto-custom' layer which builds successfully; then
>> >> >>> > I
>> >
>> > run:
>> >> >>> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
>> >> >>> > >>
>> >> >>> > >> I see a line:
>> >> >>> >   Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
>> >> >>> >
>> >> >>> > Then I run:
>> >> >>> > devtool build linux-yocto-custom
>> >> >>> > >>
>> >> >>> > >> it reports the following:
>> >> >>> > Log data follows:
>> >> >>> > | DEBUG: Executing shell function do_kernel_configme
>> >> >>> > | NOTE: kernel configme
>> >> >>> > | [INFO] Configuring target/machine combo: "standard/bcmjava"
>> >> >>> > | [ERROR] frag
>> >> >>> >
>> >> >>> > /tmp/devtoolfgiLXr/workdir/source/.meta/cfg/scratch/obj/tmp/devtool
>> >> >>> > fgi
>> >> >>> > LXr/
>> >> >>> > wo rkdir/defconfig does not exist
>> >> >>> >
>> >> >>> > | [ERROR] No configuration fragments found, this typically is a
>> >> >>> >
>> >> >>> > misconfigured BSP.
>> >> >>> >
>> >> >>> > | Check that fragments (or defconfigs) are referenced by
>> >> >>> > | the
>> >> >>> > | board
>> >> >>> >
>> >> >>> > description.
>> >> >>> >
>> >> >>> > | config of "standard/bcmjava" failed
>> >> >>> > | WARNING: exit code 1 from a shell command.
>> >> >>> >
>> >> >>> > which is true, because "devtool modify -x" deletes the temp
>> >> >>> > directory
>> >> >>> > ("/tmp/devtoolfgiLXr") that it used to create this specified
>> >> >>> > workspace
>> >> >>>
>> >> >>> Hmm, it looks like the temporary path is leaking in somewhere. Is
>> >> >>> there
>> >> >>> an
>> >> >>> easy way I can reproduce this here so I can debug it?
>> >> >>
>> >> >> Actually I just realised, this task ought not to be running at all -
>> >> >> in
>> >> >> master we've disabled it under these circumsances. There's also one
>> >> >> other fix on master that you'd benefit from in jethro - I've put them
>> >> >> both on this>>
>> >> >>
>> >> >> contrib branch:
>> >> >>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/
>> >> >>   jet
>> >> >>   hro-fixes4>>
>> >> >>
>> >> >> If you could let me know how it works for you that would be great;
>> >> >> I'll
>> >> >> send it out soon.
>> >> >>
>> >> >> Cheers,
>> >> >> Paul
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Paul Eggleton
>> >> >> Intel Open Source Technology Centre
>> >
>> > --
>> >
>> > Paul Eggleton
>> > Intel Open Source Technology Centre
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel: "devtool modify -x" issue

[Paul Eggleton]

I hope we are talking a week or less, but I'm not able to give you a definitive 
answer - it depends on patch review and how busy we are dealing with issues on 
the master branch among other things.

Cheers,
Paul

On Mon, 14 Mar 2016 13:49:40 Steve Rae wrote:
> thanks much...
> I am very new to this: does "not long though" mean 2-3 days or 2-3 weeks or
> ???
> 
> 
> On Mon, Mar 14, 2016 at 1:47 PM, Paul Eggleton
> 
>  wrote:
> > Hi Steve,
> > 
> > I've just sent out the patches; beyond that it's a matter of the stable
> > branch testing and integration process. I hope not long though.
> > 
> > Cheers,
> > Paul
> > 
> > On Mon, 14 Mar 2016 11:51:08 Steve Rae wrote:
> >> Paul -- please ETA for getting this into the "jethro" branch.
> >> Thanks, Steve
> >> 
> >> On Fri, Mar 11, 2016 at 10:11 AM, Steve Rae  
wrote:
> >> > OK - this seems to build successfully - Thanks!
> >> > 
> >> >>> although I still do see the line:
> >> >  Cloning into '/tmp/devtool6ZA4IK/workdir/source'...
> >> > 
> >> > On Thu, Mar 10, 2016 at 7:07 PM, Paul Eggleton
> >> > 
> >> >  wrote:
> >> >> On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
> >> >>> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
> >> >>> > ( using jethro )
> >> >>> > 
> >> >>> > I have a 'linux-yocto-custom' layer which builds successfully; then
> >> >>> > I
> > 
> > run:
> >> >>> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
> >> >>> > >> 
> >> >>> > >> I see a line:
> >> >>> >   Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
> >> >>> > 
> >> >>> > Then I run:
> >> >>> > devtool build linux-yocto-custom
> >> >>> > >> 
> >> >>> > >> it reports the following:
> >> >>> > Log data follows:
> >> >>> > | DEBUG: Executing shell function do_kernel_configme
> >> >>> > | NOTE: kernel configme
> >> >>> > | [INFO] Configuring target/machine combo: "standard/bcmjava"
> >> >>> > | [ERROR] frag
> >> >>> > 
> >> >>> > /tmp/devtoolfgiLXr/workdir/source/.meta/cfg/scratch/obj/tmp/devtool
> >> >>> > fgi
> >> >>> > LXr/
> >> >>> > wo rkdir/defconfig does not exist
> >> >>> > 
> >> >>> > | [ERROR] No configuration fragments found, this typically is a
> >> >>> > 
> >> >>> > misconfigured BSP.
> >> >>> > 
> >> >>> > | Check that fragments (or defconfigs) are referenced by
> >> >>> > | the
> >> >>> > | board
> >> >>> > 
> >> >>> > description.
> >> >>> > 
> >> >>> > | config of "standard/bcmjava" failed
> >> >>> > | WARNING: exit code 1 from a shell command.
> >> >>> > 
> >> >>> > which is true, because "devtool modify -x" deletes the temp
> >> >>> > directory
> >> >>> > ("/tmp/devtoolfgiLXr") that it used to create this specified
> >> >>> > workspace
> >> >>> 
> >> >>> Hmm, it looks like the temporary path is leaking in somewhere. Is
> >> >>> there
> >> >>> an
> >> >>> easy way I can reproduce this here so I can debug it?
> >> >> 
> >> >> Actually I just realised, this task ought not to be running at all -
> >> >> in
> >> >> master we've disabled it under these circumsances. There's also one
> >> >> other fix on master that you'd benefit from in jethro - I've put them
> >> >> both on this>>
> >> >> 
> >> >> contrib branch:
> >> >>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/
> >> >>   jet
> >> >>   hro-fixes4>>
> >> >> 
> >> >> If you could let me know how it works for you that would be great;
> >> >> I'll
> >> >> send it out soon.
> >> >> 
> >> >> Cheers,
> >> >> Paul
> >> >> 
> >> >> --
> >> >> 
> >> >> Paul Eggleton
> >> >> Intel Open Source Technology Centre
> > 
> > --
> > 
> > Paul Eggleton
> > Intel Open Source Technology Centre

-- 

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

Re: [yocto] kernel: "devtool modify -x" issue

[Steve Rae]

thanks much...
I am very new to this: does "not long though" mean 2-3 days or 2-3 weeks or ???


On Mon, Mar 14, 2016 at 1:47 PM, Paul Eggleton
 wrote:
> Hi Steve,
>
> I've just sent out the patches; beyond that it's a matter of the stable branch
> testing and integration process. I hope not long though.
>
> Cheers,
> Paul
>
> On Mon, 14 Mar 2016 11:51:08 Steve Rae wrote:
>> Paul -- please ETA for getting this into the "jethro" branch.
>> Thanks, Steve
>>
>> On Fri, Mar 11, 2016 at 10:11 AM, Steve Rae  wrote:
>> > OK - this seems to build successfully - Thanks!
>> >
>> >>> although I still do see the line:
>> >  Cloning into '/tmp/devtool6ZA4IK/workdir/source'...
>> >
>> > On Thu, Mar 10, 2016 at 7:07 PM, Paul Eggleton
>> >
>> >  wrote:
>> >> On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
>> >>> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
>> >>> > ( using jethro )
>> >>> >
>> >>> > I have a 'linux-yocto-custom' layer which builds successfully; then I
> run:
>> >>> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
>> >>> > >>
>> >>> > >> I see a line:
>> >>> >   Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
>> >>> >
>> >>> > Then I run:
>> >>> > devtool build linux-yocto-custom
>> >>> > >>
>> >>> > >> it reports the following:
>> >>> > Log data follows:
>> >>> > | DEBUG: Executing shell function do_kernel_configme
>> >>> > | NOTE: kernel configme
>> >>> > | [INFO] Configuring target/machine combo: "standard/bcmjava"
>> >>> > | [ERROR] frag
>> >>> >
>> >>> > /tmp/devtoolfgiLXr/workdir/source/.meta/cfg/scratch/obj/tmp/devtoolfgi
>> >>> > LXr/
>> >>> > wo rkdir/defconfig does not exist
>> >>> >
>> >>> > | [ERROR] No configuration fragments found, this typically is a
>> >>> >
>> >>> > misconfigured BSP.
>> >>> >
>> >>> > | Check that fragments (or defconfigs) are referenced by the
>> >>> > | board
>> >>> >
>> >>> > description.
>> >>> >
>> >>> > | config of "standard/bcmjava" failed
>> >>> > | WARNING: exit code 1 from a shell command.
>> >>> >
>> >>> > which is true, because "devtool modify -x" deletes the temp directory
>> >>> > ("/tmp/devtoolfgiLXr") that it used to create this specified
>> >>> > workspace
>> >>>
>> >>> Hmm, it looks like the temporary path is leaking in somewhere. Is there
>> >>> an
>> >>> easy way I can reproduce this here so I can debug it?
>> >>
>> >> Actually I just realised, this task ought not to be running at all - in
>> >> master we've disabled it under these circumsances. There's also one
>> >> other fix on master that you'd benefit from in jethro - I've put them
>> >> both on this>>
>> >> contrib branch:
>> >>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/jet
>> >>   hro-fixes4>>
>> >> If you could let me know how it works for you that would be great; I'll
>> >> send it out soon.
>> >>
>> >> Cheers,
>> >> Paul
>> >>
>> >> --
>> >>
>> >> Paul Eggleton
>> >> Intel Open Source Technology Centre
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] kernel: "devtool modify -x" issue

[Paul Eggleton]

Hi Steve,

I've just sent out the patches; beyond that it's a matter of the stable branch 
testing and integration process. I hope not long though.

Cheers,
Paul

On Mon, 14 Mar 2016 11:51:08 Steve Rae wrote:
> Paul -- please ETA for getting this into the "jethro" branch.
> Thanks, Steve
> 
> On Fri, Mar 11, 2016 at 10:11 AM, Steve Rae  wrote:
> > OK - this seems to build successfully - Thanks!
> > 
> >>> although I still do see the line:
> >  Cloning into '/tmp/devtool6ZA4IK/workdir/source'...
> > 
> > On Thu, Mar 10, 2016 at 7:07 PM, Paul Eggleton
> > 
> >  wrote:
> >> On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
> >>> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
> >>> > ( using jethro )
> >>> > 
> >>> > I have a 'linux-yocto-custom' layer which builds successfully; then I 
run:
> >>> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
> >>> > >> 
> >>> > >> I see a line:
> >>> >   Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
> >>> > 
> >>> > Then I run:
> >>> > devtool build linux-yocto-custom
> >>> > >> 
> >>> > >> it reports the following:
> >>> > Log data follows:
> >>> > | DEBUG: Executing shell function do_kernel_configme
> >>> > | NOTE: kernel configme
> >>> > | [INFO] Configuring target/machine combo: "standard/bcmjava"
> >>> > | [ERROR] frag
> >>> > 
> >>> > /tmp/devtoolfgiLXr/workdir/source/.meta/cfg/scratch/obj/tmp/devtoolfgi
> >>> > LXr/
> >>> > wo rkdir/defconfig does not exist
> >>> > 
> >>> > | [ERROR] No configuration fragments found, this typically is a
> >>> > 
> >>> > misconfigured BSP.
> >>> > 
> >>> > | Check that fragments (or defconfigs) are referenced by the
> >>> > | board
> >>> > 
> >>> > description.
> >>> > 
> >>> > | config of "standard/bcmjava" failed
> >>> > | WARNING: exit code 1 from a shell command.
> >>> > 
> >>> > which is true, because "devtool modify -x" deletes the temp directory
> >>> > ("/tmp/devtoolfgiLXr") that it used to create this specified
> >>> > workspace
> >>> 
> >>> Hmm, it looks like the temporary path is leaking in somewhere. Is there
> >>> an
> >>> easy way I can reproduce this here so I can debug it?
> >> 
> >> Actually I just realised, this task ought not to be running at all - in
> >> master we've disabled it under these circumsances. There's also one
> >> other fix on master that you'd benefit from in jethro - I've put them
> >> both on this>> 
> >> contrib branch:
> >>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/jet
> >>   hro-fixes4>> 
> >> If you could let me know how it works for you that would be great; I'll
> >> send it out soon.
> >> 
> >> Cheers,
> >> Paul
> >> 
> >> --
> >> 
> >> Paul Eggleton
> >> Intel Open Source Technology Centre

-- 

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

Re: [yocto] kernel: "devtool modify -x" issue

[Steve Rae]

Paul -- please ETA for getting this into the "jethro" branch.
Thanks, Steve

On Fri, Mar 11, 2016 at 10:11 AM, Steve Rae  wrote:
> OK - this seems to build successfully - Thanks!
>
>>> although I still do see the line:
>  Cloning into '/tmp/devtool6ZA4IK/workdir/source'...
>
> On Thu, Mar 10, 2016 at 7:07 PM, Paul Eggleton
>  wrote:
>> On Fri, 11 Mar 2016 07:55:25 Paul Eggleton wrote:
>>> On Wed, 09 Mar 2016 10:12:30 Steve Rae wrote:
>>> > ( using jethro )
>>> >
>>> > I have a 'linux-yocto-custom' layer which builds successfully; then I run:
>>> > devtool modify -x linux-yocto-custom ../../poky-dev/kernel
>>> > >>
>>> > >> I see a line:
>>> >   Cloning into '/tmp/devtoolfgiLXr/workdir/source'...
>>> >
>>> > Then I run:
>>> > devtool build linux-yocto-custom
>>> > >>
>>> > >> it reports the following:
>>> > Log data follows:
>>> > | DEBUG: Executing shell function do_kernel_configme
>>> > | NOTE: kernel configme
>>> > | [INFO] Configuring target/machine combo: "standard/bcmjava"
>>> > | [ERROR] frag
>>> >
>>> > /tmp/devtoolfgiLXr/workdir/source/.meta/cfg/scratch/obj/tmp/devtoolfgiLXr/
>>> > wo rkdir/defconfig does not exist
>>> >
>>> > | [ERROR] No configuration fragments found, this typically is a
>>> >
>>> > misconfigured BSP.
>>> >
>>> > | Check that fragments (or defconfigs) are referenced by the board
>>> >
>>> > description.
>>> >
>>> > | config of "standard/bcmjava" failed
>>> > | WARNING: exit code 1 from a shell command.
>>> >
>>> > which is true, because "devtool modify -x" deletes the temp directory
>>> > ("/tmp/devtoolfgiLXr") that it used to create this specified workspace
>>>
>>> Hmm, it looks like the temporary path is leaking in somewhere. Is there an
>>> easy way I can reproduce this here so I can debug it?
>>
>> Actually I just realised, this task ought not to be running at all - in 
>> master
>> we've disabled it under these circumsances. There's also one other fix on
>> master that you'd benefit from in jethro - I've put them both on this
>> contrib branch:
>>
>>   
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=paule/jethro-fixes4
>>
>> If you could let me know how it works for you that would be great; I'll send
>> it out soon.
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Two or more _append()'s on same task

[Christopher Larson]

On Mon, Mar 14, 2016 at 10:56 AM Daniel.  wrote:

> Hi all,
>
> I was wondering how OE/Yocto would respond if the same task is appended
> twice.
>
> If I have a .bbclass that already creates a do_install_append() and I
> inherit this class at my recipe, will my do_install_append be aplied:
>
> - Before .bbclass do_install_append()
> - After it
> - Will not be aplied
>
> Now if I declare my do_install_append before the inherit line, will it
> be aplied before the .bbclass's do_install_append?
>
> How Yocto handles this _append stuff?
>

Append/prepend are cumulative, just like +=/+=/.=/=.. *all* appends are
applied, in the order they're seen while parsing.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Two or more _append()'s on same task

[Daniel.]

Hi all,

I was wondering how OE/Yocto would respond if the same task is appended twice.

If I have a .bbclass that already creates a do_install_append() and I
inherit this class at my recipe, will my do_install_append be aplied:

- Before .bbclass do_install_append()
- After it
- Will not be aplied

Now if I declare my do_install_append before the inherit line, will it
be aplied before the .bbclass's do_install_append?

How Yocto handles this _append stuff?

Best regards,


-- 
"Do or do not. There is no try"
  Yoda Master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problems building live image

[Radzykewycz, T (Radzy)]

> While we're on it...
> 
> Can anyone explain what a "live" image is intended to be?
> 
> (I haven't gotten a live image to "work", but I'm not entirely
> sure I know what "work" means for a live image.)
> 
> Or how hdddirect is intended to be different from hddimg?
> 
> --rich

Can't say as how I'm anything close to an expert on it, but

My impression was that a live image was one that

- Booted from removable media

- Did not mount a local hard disk as rootfs, but instead copied
  the rootfs from the boot media

- Optionally, might include an installer to install the image
  onto a local hard disk.

Enjoy!

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

Re: [yocto] Problems building live image

[K Richard Pixley]

On 3/14/16 10:16 , Khem Raj wrote:

On Mon, Mar 14, 2016 at 10:11 AM, K Richard Pixley  wrote:

While we're on it...

Can anyone explain what a "live" image is intended to be?

it can either boot from the disk or you can run the installer to
install it to another media on your device.
How is that different from an ISO?  I mean, isn't that what an ISO image 
does?

(I haven't gotten a live image to "work", but I'm not entirely sure I know
what "work" means for a live image.)

what issues do you see ? may that can help answer this

Mostly build time issues with "live" conflicting with "vmdk" and the like.

Or how hdddirect is intended to be different from hddimg?

hdddirect is raw disk image.
I thought hddimg was a raw disk image.  If hdddirect is a raw disk 
image, then what's hddimg?


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

Re: [yocto] Problems building live image

[Khem Raj]

On Mon, Mar 14, 2016 at 10:11 AM, K Richard Pixley  wrote:
> While we're on it...
>
> Can anyone explain what a "live" image is intended to be?

it can either boot from the disk or you can run the installer to
install it to another media on your device.

>
> (I haven't gotten a live image to "work", but I'm not entirely sure I know
> what "work" means for a live image.)

what issues do you see ? may that can help answer this

>
> Or how hdddirect is intended to be different from hddimg?

hdddirect is raw disk image.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problems building live image

[K Richard Pixley]

While we're on it...

Can anyone explain what a "live" image is intended to be?

(I haven't gotten a live image to "work", but I'm not entirely sure I 
know what "work" means for a live image.)


Or how hdddirect is intended to be different from hddimg?

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

Re: [yocto] Problems building live image

[Khem Raj]

> On Mar 14, 2016, at 10:01 AM, Gary Thomas  wrote:
> 
> On 03/14/2016 05:34 PM, K Richard Pixley wrote:
>> On 3/13/16 22:16 , Gary Thomas wrote:
>>> I'd like to to some testing that qemu just doesn't seem up to
>>> so I attempted to build a live ISO per the documentation. I
>>> added these lines to local.conf:
>>>  IMAGE_FSTYPES_genericx86 += "live"
>>>  NOISO_genericx86 = "0"
>>> 
>>> When I try to build core-image-base I get this error:
>>>  ERROR: INITRD_IMAGE_LIVE core-image-minimal-initramfs cannot use image 
>>> live, hddimg or iso.
>>>  ERROR: Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.
>>>  ERROR: Failed to parse recipe: 
>>> /local/poky-cutting-edge/meta/recipes-core/images/core-image-minimal-initramfs.bb
>>> 
>>> I'm using a recent Poky checkout (d53413d3a8444c38a83ea37867c8af7754d8e702)
>>> 
>>> Am I just doing something wrong here? I was following this section of the 
>>> mega-manual:
>>> 
>>>  26.56. image-live.bbclass¶
>>> 
>>>  The image-live class supports building "live" images.
>>> 
>>>  Normally, you do not use this class directly. Instead, you add "live" to 
>>> IMAGE_FSTYPES.
>>>  For example, if you were building an ISO image, you would add "live" to 
>>> IMAGE_FSTYPES,
>>>  set the NOISO variable to "0" and the build system would use the 
>>> image-live class to
>>>  build the ISO image.
>>> 
>>> I don't have any available hardware for this testing, so I thought
>>> I'd use VirtualBox.  Is this a reasonable approach?  I want to use
>>> a live ISO so I get a writable file system.  I tried just using the
>>> .hddimage but that doesn't boot with VirtualBox :-(
>>> 
>>> To be clear, along with the additions above in local.conf, I tried:
>>>  $ MACHINE=genericx86 bitbake core-image-base
>>> 
>>> Thanks for any ideas
>> You can boot the .hddimg on VirtualBox by first converting it to vdi, (or 
>> vmdk), using:
>> 
>> qemu-img convert -O vdi foo.hddimg foo.vdi
>> 
>> The vmdk doesn't seem to work for me on VMware, oddly.  And adding vmdk to 
>> IMAGE_FSTYPES doesn't seem to work either as
>> it is apparently built from hdddirect, (no clue why that's distinct from 
>> hddimg but it doesn't boot for me).
> 
> Thanks.  I got the .vmdk to boot but I had to manually select
> the root device during boot to root=/dev/hda2.  After that, it
> worked as expected.
> 


you can also set
SYSLINUX_ROOT = "root=/dev/hda2”
in some place in your configuration metadata



> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Problems building live image

[Gary Thomas]

On 03/14/2016 05:34 PM, K Richard Pixley wrote:

On 3/13/16 22:16 , Gary Thomas wrote:

I'd like to to some testing that qemu just doesn't seem up to
so I attempted to build a live ISO per the documentation. I
added these lines to local.conf:
  IMAGE_FSTYPES_genericx86 += "live"
  NOISO_genericx86 = "0"

When I try to build core-image-base I get this error:
  ERROR: INITRD_IMAGE_LIVE core-image-minimal-initramfs cannot use image live, 
hddimg or iso.
  ERROR: Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.
  ERROR: Failed to parse recipe: 
/local/poky-cutting-edge/meta/recipes-core/images/core-image-minimal-initramfs.bb

I'm using a recent Poky checkout (d53413d3a8444c38a83ea37867c8af7754d8e702)

Am I just doing something wrong here? I was following this section of the 
mega-manual:

  26.56. image-live.bbclass¶

  The image-live class supports building "live" images.

  Normally, you do not use this class directly. Instead, you add "live" to 
IMAGE_FSTYPES.
  For example, if you were building an ISO image, you would add "live" to 
IMAGE_FSTYPES,
  set the NOISO variable to "0" and the build system would use the image-live 
class to
  build the ISO image.

I don't have any available hardware for this testing, so I thought
I'd use VirtualBox.  Is this a reasonable approach?  I want to use
a live ISO so I get a writable file system.  I tried just using the
.hddimage but that doesn't boot with VirtualBox :-(

To be clear, along with the additions above in local.conf, I tried:
  $ MACHINE=genericx86 bitbake core-image-base

Thanks for any ideas

You can boot the .hddimg on VirtualBox by first converting it to vdi, (or 
vmdk), using:

qemu-img convert -O vdi foo.hddimg foo.vdi

The vmdk doesn't seem to work for me on VMware, oddly.  And adding vmdk to 
IMAGE_FSTYPES doesn't seem to work either as
it is apparently built from hdddirect, (no clue why that's distinct from hddimg 
but it doesn't boot for me).


Thanks.  I got the .vmdk to boot but I had to manually select
the root device during boot to root=/dev/hda2.  After that, it
worked as expected.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Problems building live image

[K Richard Pixley]

On 3/13/16 22:16 , Gary Thomas wrote:

I'd like to to some testing that qemu just doesn't seem up to
so I attempted to build a live ISO per the documentation. I
added these lines to local.conf:
  IMAGE_FSTYPES_genericx86 += "live"
  NOISO_genericx86 = "0"

When I try to build core-image-base I get this error:
  ERROR: INITRD_IMAGE_LIVE core-image-minimal-initramfs cannot use 
image live, hddimg or iso.

  ERROR: Check IMAGE_FSTYPES and INITRAMFS_FSTYPES settings.
  ERROR: Failed to parse recipe: 
/local/poky-cutting-edge/meta/recipes-core/images/core-image-minimal-initramfs.bb


I'm using a recent Poky checkout 
(d53413d3a8444c38a83ea37867c8af7754d8e702)


Am I just doing something wrong here? I was following this section of 
the mega-manual:


  26.56. image-live.bbclass¶

  The image-live class supports building "live" images.

  Normally, you do not use this class directly. Instead, you add 
"live" to IMAGE_FSTYPES.
  For example, if you were building an ISO image, you would add "live" 
to IMAGE_FSTYPES,
  set the NOISO variable to "0" and the build system would use the 
image-live class to

  build the ISO image.

I don't have any available hardware for this testing, so I thought
I'd use VirtualBox.  Is this a reasonable approach?  I want to use
a live ISO so I get a writable file system.  I tried just using the
.hddimage but that doesn't boot with VirtualBox :-(

To be clear, along with the additions above in local.conf, I tried:
  $ MACHINE=genericx86 bitbake core-image-base

Thanks for any ideas
You can boot the .hddimg on VirtualBox by first converting it to vdi, 
(or vmdk), using:


qemu-img convert -O vdi foo.hddimg foo.vdi

The vmdk doesn't seem to work for me on VMware, oddly.  And adding vmdk 
to IMAGE_FSTYPES doesn't seem to work either as it is apparently built 
from hdddirect, (no clue why that's distinct from hddimg but it doesn't 
boot for me).


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

Re: [yocto] New message

[Burton, Ross]

On 14 March 2016 at 15:58, Christopher Larson  wrote:

> You're using the poky distribution which for build performance uses
>> uninative (from 477b8fb), which means that instead of building native
>> dependencies per-host-distribution there's a static libc which is built
>> against to enable native binaries to be host-agnostic.
>>
>
> To clarify, I believe 'static' here is meant to mean fixed, not a static
> library :)
>

Yes, it's basically a nativesdk-libc that everything else is built against.

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

Re: [yocto] New message

[Christopher Larson]

On Mon, Mar 14, 2016 at 5:50 AM Burton, Ross  wrote:

> On 14 March 2016 at 03:10, Gary Thomas  wrote:
>
>> I just started a new build and saw a message that's new to me:
>>   NOTE: Fetching uninative binary shim from
>> http://downloads.yoctoproject.org/releases/uninative/0.95/x86_64-nativesdk-libc.tar.bz2;md5sum=4b6fb2106c2f18b8f9c8ac67e1cf9e57
>>
>> * What is this about?
>>
>
> You're using the poky distribution which for build performance uses
> uninative (from 477b8fb), which means that instead of building native
> dependencies per-host-distribution there's a static libc which is built
> against to enable native binaries to be host-agnostic.
>

To clarify, I believe 'static' here is meant to mean fixed, not a static
library :)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Strange build dependency

[Christopher Larson]

On Mon, Mar 14, 2016 at 6:55 AM Martin Jansa  wrote:

> On Mon, Mar 14, 2016 at 02:44:58PM +0100, Gary Thomas wrote:
> > On 03/14/2016 01:51 PM, Gary Thomas wrote:
> > > On 03/14/2016 01:46 PM, Burton, Ross wrote:
> > >>
> > >> On 14 March 2016 at 12:41, Gary Thomas  g...@mlbassoc.com>> wrote:
> > >>
> > >> How can I find out what's going on here?
> > >>
> > >>
> > >> bitbake-whatchanged is generally helpful here.  Do a build in one
> configuration, switch to the other, run
> > >> bitbake-whatchanged.  It will identify the hashes that have changed
> and try and chase them down.
> > >>
> > >> That said perl is quite a deep recipe so rebuilding that will
> certainly bubble up the tree causing all sorts of rebuilds.
> > >
> > > Thanks, I'll give this a try.
> > >
> >
> > I've run this and I still don't have a clue.  Here's what I got.  Maybe
> > you can explain what I'm seeing?
>
> You can also create snapshot before and after the change with
> scripts/sstate-diff-machines.sh and compare the signatures manually.
>

bitbake -S printdiff is a useful option as well.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH 3/6] remove lksctp-tools from meta-cgl

[Adrian Dudau]

lksctp-tools was initially added with the aim to fulfill STD.3.1. The
Linux kernel >2.6 includes support for the base features of SCTP, so
there is no need for the package.

Besides that, there is already a recipe defined in meta-networking that
is kept up to date. If a P2 requirement will require lksctp-tools, we
can add it from there.

CGL requirement STD.3.1

Signed-off-by: Adrian Dudau 
Signed-off-by: Siva Borra 
---
 .../packagegroups/packagegroup-cgl-middleware.bb   |  1 -
 .../lksctp-tools/files/static-libraries-fix.patch  | 60 --
 .../recipes-cgl/lksctp-tools/lksctp-tools.inc  | 47 -
 .../recipes-cgl/lksctp-tools/lksctp-tools_1.0.7.bb | 38 --
 4 files changed, 146 deletions(-)
 delete mode 100644 
meta-cgl-common/recipes-cgl/lksctp-tools/files/static-libraries-fix.patch
 delete mode 100644 meta-cgl-common/recipes-cgl/lksctp-tools/lksctp-tools.inc
 delete mode 100644 
meta-cgl-common/recipes-cgl/lksctp-tools/lksctp-tools_1.0.7.bb

diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb 
b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
index 23735f3..448e038 100644
--- a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
+++ b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
@@ -49,7 +49,6 @@ RDEPENDS_packagegroup-cgl-middleware = "\
 vlan \
 corosync \
 iscsi-initiator-utils \
-lksctp-tools \
 openais \
 openipmi \
 openhpi \
diff --git 
a/meta-cgl-common/recipes-cgl/lksctp-tools/files/static-libraries-fix.patch 
b/meta-cgl-common/recipes-cgl/lksctp-tools/files/static-libraries-fix.patch
deleted file mode 100644
index 745db9b..000
--- a/meta-cgl-common/recipes-cgl/lksctp-tools/files/static-libraries-fix.patch
+++ /dev/null
@@ -1,60 +0,0 @@
-When running "./configure --disable-shared --enable-
-static" the build fails with the following error:
-
-gcc -g -Wall -Wstrict-prototypes -Wimplicit-function-
-declaration -g -O2 -o nagle_snd
-nagle_snd.o ../../src/lib/.libs/libsctp.a ../../src/t
-estlib/.libs/libsctputil.a
-../../src/testlib/.libs/libsctputil.a(sctputil.o): In
-function `test_peer_addr':
-/home/roubert/src/lksctp/lksctp-tools-
-1.0.6/src/testlib/sctputil.c:376: undefined reference
-to `sctp_getpaddrs'
-/home/roubert/src/lksctp/lksctp-tools-
-1.0.6/src/testlib/sctputil.c:382: undefined reference
-to `sctp_freepaddrs'
-/home/roubert/src/lksctp/lksctp-tools-
-1.0.6/src/testlib/sctputil.c:416: undefined reference
-to `sctp_freepaddrs'
-/home/roubert/src/lksctp/lksctp-tools-
-1.0.6/src/testlib/sctputil.c:400: undefined reference
-to `sctp_freepaddrs'
-collect2: ld returned 1 exit status
-make[3]: *** [nagle_snd] Error 1
-
-Changing the order of libsctp.a and libsctputil.a
-fixes this. The attached patch updates
-src/apps/Makefile.am and src/func_tests/Makefile.am
-to do that.
-
-Patch submitted by Fredrik Roubert .
-Patch needed reformatation because it did not applies as it was.
-
-diff -Naur a/src/apps/Makefile.am b/src/apps/Makefile.am
 a/src/apps/Makefile.am 2014-07-04 14:57:42.707977872 +0200
-+++ b/src/apps/Makefile.am 2014-07-04 14:59:12.336231677 +0200
-@@ -8,8 +8,8 @@
- INCLUDES = -I. -I$(top_srcdir)/src/include -I$(top_srcdir)/src/testlib 
- AM_CFLAGS = -g -Wall -Wstrict-prototypes -Wimplicit-function-declaration
- AM_LDFLAGS = 
--LDADD = $(top_builddir)/src/lib/libsctp.la \
--  $(top_builddir)/src/testlib/libsctputil.la
-+LDADD = $(top_builddir)/src/testlib/libsctputil.la \
-+  $(top_builddir)/src/lib/libsctp.la
- 
- # programs to be installed with the distriubution
- bin_PROGRAMS = sctp_darn sctp_test
-diff -Naur a/src/func_tests/Makefile.am b/src/func_tests/Makefile.am
 a/src/func_tests/Makefile.am   2014-07-04 15:04:48.678188041 +0200
-+++ b/src/func_tests/Makefile.am   2014-07-04 15:13:24.624769819 +0200
-@@ -8,8 +8,8 @@
- INCLUDES = -I. -I$(top_srcdir)/src/include -I$(top_srcdir)/src/testlib 
- AM_CFLAGS = -g -Wall -Wstrict-prototypes -Wimplicit-function-declaration
- AM_LDFLAGS = -lpthread
--LDADD = $(top_builddir)/src/lib/libsctp.la \
--  $(top_builddir)/src/testlib/libsctputil.la
-+LDADD = $(top_builddir)/src/testlib/libsctputil.la \
-+  $(top_builddir)/src/lib/libsctp.la
- 
- V6FLAGS = -DCONFIG_IPV6=1 -DTEST_V6=1 ${DEFS} ${INCLUDES} ${CFLAGS}
- 
diff --git a/meta-cgl-common/recipes-cgl/lksctp-tools/lksctp-tools.inc 
b/meta-cgl-common/recipes-cgl/lksctp-tools/lksctp-tools.inc
deleted file mode 100644
index 08a2073..000
--- a/meta-cgl-common/recipes-cgl/lksctp-tools/lksctp-tools.inc
+++ /dev/null
@@ -1,47 +0,0 @@
-DESCRIPTION = "The Linux Kernel Stream Control Transmission Protocol (lksctp) 
project"
-SECTION = "libs"
-PRIORITY = "optional"
-LICENSE = "LGPLv2"
-LIC_FILES_CHKSUM = "file://COPYING;md5=0c56db0143f4f80c369ee3af7425af6e"
-
-S = "${WORKDIR}/${BPN}-${PV}"
-
-INC_PR = "r1"
-
-BBCLASSEXTEND = "native"
-
-inherit autotools-brokensep pkgconfig binconfig
-
-EXTRA_OEMAKE="LIB=${libdir} exec_prefix=

[yocto] [meta-cgl][PATCH 6/6] cgl_common_security_flags.inc: Remove compiler override for openhpi

[Adrian Dudau]

Compiling openhpi with -fPIE works well now, so the override
doesn't seem necessary anymore.

Signed-off-by: Adrian Dudau 
---
 meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc 
b/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc
index 563a6e4..42c612c 100644
--- a/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc
+++ b/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc
@@ -1,2 +1 @@
-SECURITY_CFLAGS_pn-openhpi = "${SECURITY_NO_PIE_CFLAGS}"
 SECURITY_LDFLAGS_remove_pn-audit = "-fstack-protector-strong"
-- 
1.9.1

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

[yocto] [meta-cgl][PATCH 2/6] packagegroup-cgl-middleware: update drbd package name

[Adrian Dudau]

drbd recipe has been renamed to drbd-utils in meta-networking

Signed-off-by: Adrian Dudau 
---
 meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb 
b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
index 9d9790e..23735f3 100644
--- a/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
+++ b/meta-cgl-common/packagegroups/packagegroup-cgl-middleware.bb
@@ -57,7 +57,7 @@ RDEPENDS_packagegroup-cgl-middleware = "\
 cluster-glue \
 resource-agents \
 ifenslave \
-drbd \
+drbd-utils \
 openl2tp \
 umip \
 dmidecode \
-- 
1.9.1

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

[yocto] [meta-cgl][PATCH 5/6] cgl_common_security_flags.inc: Add linker override for audit

[Adrian Dudau]

Building audit with -fstack-protector-strong throws link errors on the
native compiler. Add exception to avoid that.
---
 meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc 
b/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc
index 358ce58..563a6e4 100644
--- a/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc
+++ b/meta-cgl-common/conf/distro/include/cgl_common_security_flags.inc
@@ -1 +1,2 @@
 SECURITY_CFLAGS_pn-openhpi = "${SECURITY_NO_PIE_CFLAGS}"
+SECURITY_LDFLAGS_remove_pn-audit = "-fstack-protector-strong"
-- 
1.9.1

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

[yocto] [meta-cgl][PATCH 4/6] makedumpfile: compile with shared libraries

[Adrian Dudau]

poky distro doesn't include static libraries by defaule anymore, so we
should use shared libraries. If at a later point it proves that we must
compile with static library we can override the no-static-libs include
in our distro definition.

Signed-off-by: Adrian Dudau 
---
 meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb 
b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
index 6c32306..21e0954 100644
--- a/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
+++ b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
@@ -12,7 +12,7 @@ SRC_URI[makedumpfile.sha256sum] = 
"dd9c6c40c1ae6774b61bbe7b53f5ebbee9734f576d8ec
 
 DEPENDS = "zlib elfutils bzip2"
 
-EXTRA_OEMAKE = "TARGET=${TARGET_ARCH}"
+EXTRA_OEMAKE = "TARGET=${TARGET_ARCH} LINKTYPE=dynamic"
 
 do_install() {
install -d ${D}${bindir}/
-- 
1.9.1

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

[yocto] [meta-cgl][PATCH 1/6] sysvinit: remove permissions override

[Adrian Dudau]

This leads to shutdown command being executable by everybody,
which is a huge security issue. If there are issues related to the way
this is configured in the main recipe, they should be handled
differently.

Signed-off-by: Adrian Dudau 
---
 meta-cgl-common/recipes-core/sysvinit/sysvinit_2.%.bbappend | 3 ---
 1 file changed, 3 deletions(-)
 delete mode 100644 meta-cgl-common/recipes-core/sysvinit/sysvinit_2.%.bbappend

diff --git a/meta-cgl-common/recipes-core/sysvinit/sysvinit_2.%.bbappend 
b/meta-cgl-common/recipes-core/sysvinit/sysvinit_2.%.bbappend
deleted file mode 100644
index 4fd3c00..000
--- a/meta-cgl-common/recipes-core/sysvinit/sysvinit_2.%.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-do_install_append(){
-chmod o+x ${D}${base_sbindir}/shutdown
-}
-- 
1.9.1

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

Re: [yocto] Strange build dependency

[Martin Jansa]

On Mon, Mar 14, 2016 at 02:44:58PM +0100, Gary Thomas wrote:
> On 03/14/2016 01:51 PM, Gary Thomas wrote:
> > On 03/14/2016 01:46 PM, Burton, Ross wrote:
> >>
> >> On 14 March 2016 at 12:41, Gary Thomas  >> > wrote:
> >>
> >> How can I find out what's going on here?
> >>
> >>
> >> bitbake-whatchanged is generally helpful here.  Do a build in one 
> >> configuration, switch to the other, run
> >> bitbake-whatchanged.  It will identify the hashes that have changed and 
> >> try and chase them down.
> >>
> >> That said perl is quite a deep recipe so rebuilding that will certainly 
> >> bubble up the tree causing all sorts of rebuilds.
> >
> > Thanks, I'll give this a try.
> >
> 
> I've run this and I still don't have a clue.  Here's what I got.  Maybe
> you can explain what I'm seeing?

You can also create snapshot before and after the change with
scripts/sstate-diff-machines.sh and compare the signatures manually.

> e.g. why did the kernel need to be rebuilt if all I did was change perl?
> what about mobile-broadband-info (which I think is pretty much just
> static data)?
> 
> Thanks
> 
> -- 
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 

> Figuring out the STAMPS_DIR ...
> Generating the new stamps ... (need several minutes)
> === Newly added tasks: (945 tasks)
>   renderproto-native: do_populate_sysroot do_patch do_install do_populate_lic 
> do_unpack do_build do_configure do_fetch do_compile
>   shadow-native: do_fetch do_unpack do_populate_lic do_populate_sysroot 
> do_patch do_build do_compile do_configure do_install
>   qemu-helper-native: do_build do_install do_fetch do_populate_sysroot 
> do_compile do_populate_lic do_configure do_unpack do_patch
>   ncurses-native: do_populate_lic do_populate_sysroot do_build do_compile 
> do_patch do_install do_configure do_unpack
>   xtrans-native: do_configure do_build do_unpack do_install do_compile 
> do_fetch do_populate_lic do_populate_sysroot do_patch
>   elfutils-native: do_configure do_populate_lic do_fetch do_compile do_unpack 
> do_install do_populate_sysroot do_build do_patch
>   e2fsprogs-native: do_unpack do_configure do_patch do_build do_compile 
> do_populate_sysroot do_install do_populate_lic
>   libtool-native: do_unpack do_build do_patch do_compile do_install 
> do_populate_lic do_fetch do_populate_sysroot do_configure
>   ldconfig-native: do_build do_unpack do_install do_configure do_compile 
> do_patch do_fetch do_populate_lic do_populate_sysroot
>   randrproto-native: do_configure do_install do_populate_sysroot do_unpack 
> do_patch do_build do_fetch do_compile do_populate_lic
>   intltool-native: do_compile do_configure do_install do_populate_lic 
> do_fetch do_unpack do_build do_patch do_populate_sysroot
>   tzcode-native: do_unpack do_fetch do_configure do_populate_sysroot 
> do_populate_lic do_compile do_install do_build do_patch
>   texinfo-dummy-native: do_unpack do_configure do_fetch do_install do_compile 
> do_populate_sysroot do_populate_lic do_build do_patch
>   core-image-base: do_configure do_compile do_install
>   opkg-native: do_install do_compile do_configure do_unpack do_fetch 
> do_populate_sysroot do_build do_patch do_populate_lic
>   pbzip2-native: do_install do_fetch do_compile do_build do_populate_sysroot 
> do_populate_lic do_unpack do_configure do_patch
>   bc-native: do_populate_sysroot do_configure do_populate_lic do_install 
> do_compile do_patch do_unpack do_build
>   xextproto-native: do_unpack do_build do_populate_sysroot do_install 
> do_fetch do_configure do_patch do_compile do_populate_lic
>   libsdl-native: do_compile do_unpack do_populate_lic do_fetch do_install 
> do_populate_sysroot do_build do_configure do_patch
>   libarchive-native: do_populate_lic do_unpack do_patch do_install do_compile 
> do_configure do_build do_populate_sysroot do_fetch
>   xz-native: do_configure do_patch do_install do_unpack do_fetch do_compile 
> do_populate_lic do_build do_populate_sysroot
>   dtc-native: do_populate_lic do_configure do_unpack do_compile do_patch 
> do_populate_sysroot do_build do_fetch do_install
>   libxml-parser-perl-native: do_configure do_install do_patch do_build 
> do_populate_lic do_populate_sysroot do_unpack do_compile
>   automake-native: do_compile do_patch do_unpack do_populate_lic do_install 
> do_configure do_populate_sysroot do_build do_fetch
>   m4-native: do_install do_patch do_configure do_fetch do_unpack 
> do_populate_sysroot do_populate_lic do_compile do_build
>   dbus-native: do_populate_sysroot do_install do_patch do_configure do_unpack 
> do_build do_populate_lic do_compile
>   prelink-native: do_compile do_populate_lic do_configure do_fetch do_build 
> do_install do_unpack do_patch do_populate_sysroot
>   packagegroup-core-ssh-openssh: do_populate_sysroot do_packagedata 
> do_pac

Re: [yocto] Strange build dependency

[Gary Thomas]

On 03/14/2016 01:51 PM, Gary Thomas wrote:

On 03/14/2016 01:46 PM, Burton, Ross wrote:


On 14 March 2016 at 12:41, Gary Thomas mailto:g...@mlbassoc.com>> wrote:

How can I find out what's going on here?


bitbake-whatchanged is generally helpful here.  Do a build in one 
configuration, switch to the other, run
bitbake-whatchanged.  It will identify the hashes that have changed and try and 
chase them down.

That said perl is quite a deep recipe so rebuilding that will certainly bubble 
up the tree causing all sorts of rebuilds.


Thanks, I'll give this a try.



I've run this and I still don't have a clue.  Here's what I got.  Maybe
you can explain what I'm seeing?

e.g. why did the kernel need to be rebuilt if all I did was change perl?
what about mobile-broadband-info (which I think is pretty much just
static data)?

Thanks

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

Figuring out the STAMPS_DIR ...
Generating the new stamps ... (need several minutes)
=== Newly added tasks: (945 tasks)
  renderproto-native: do_populate_sysroot do_patch do_install do_populate_lic 
do_unpack do_build do_configure do_fetch do_compile
  shadow-native: do_fetch do_unpack do_populate_lic do_populate_sysroot 
do_patch do_build do_compile do_configure do_install
  qemu-helper-native: do_build do_install do_fetch do_populate_sysroot 
do_compile do_populate_lic do_configure do_unpack do_patch
  ncurses-native: do_populate_lic do_populate_sysroot do_build do_compile 
do_patch do_install do_configure do_unpack
  xtrans-native: do_configure do_build do_unpack do_install do_compile do_fetch 
do_populate_lic do_populate_sysroot do_patch
  elfutils-native: do_configure do_populate_lic do_fetch do_compile do_unpack 
do_install do_populate_sysroot do_build do_patch
  e2fsprogs-native: do_unpack do_configure do_patch do_build do_compile 
do_populate_sysroot do_install do_populate_lic
  libtool-native: do_unpack do_build do_patch do_compile do_install 
do_populate_lic do_fetch do_populate_sysroot do_configure
  ldconfig-native: do_build do_unpack do_install do_configure do_compile 
do_patch do_fetch do_populate_lic do_populate_sysroot
  randrproto-native: do_configure do_install do_populate_sysroot do_unpack 
do_patch do_build do_fetch do_compile do_populate_lic
  intltool-native: do_compile do_configure do_install do_populate_lic do_fetch 
do_unpack do_build do_patch do_populate_sysroot
  tzcode-native: do_unpack do_fetch do_configure do_populate_sysroot 
do_populate_lic do_compile do_install do_build do_patch
  texinfo-dummy-native: do_unpack do_configure do_fetch do_install do_compile 
do_populate_sysroot do_populate_lic do_build do_patch
  core-image-base: do_configure do_compile do_install
  opkg-native: do_install do_compile do_configure do_unpack do_fetch 
do_populate_sysroot do_build do_patch do_populate_lic
  pbzip2-native: do_install do_fetch do_compile do_build do_populate_sysroot 
do_populate_lic do_unpack do_configure do_patch
  bc-native: do_populate_sysroot do_configure do_populate_lic do_install 
do_compile do_patch do_unpack do_build
  xextproto-native: do_unpack do_build do_populate_sysroot do_install do_fetch 
do_configure do_patch do_compile do_populate_lic
  libsdl-native: do_compile do_unpack do_populate_lic do_fetch do_install 
do_populate_sysroot do_build do_configure do_patch
  libarchive-native: do_populate_lic do_unpack do_patch do_install do_compile 
do_configure do_build do_populate_sysroot do_fetch
  xz-native: do_configure do_patch do_install do_unpack do_fetch do_compile 
do_populate_lic do_build do_populate_sysroot
  dtc-native: do_populate_lic do_configure do_unpack do_compile do_patch 
do_populate_sysroot do_build do_fetch do_install
  libxml-parser-perl-native: do_configure do_install do_patch do_build 
do_populate_lic do_populate_sysroot do_unpack do_compile
  automake-native: do_compile do_patch do_unpack do_populate_lic do_install 
do_configure do_populate_sysroot do_build do_fetch
  m4-native: do_install do_patch do_configure do_fetch do_unpack 
do_populate_sysroot do_populate_lic do_compile do_build
  dbus-native: do_populate_sysroot do_install do_patch do_configure do_unpack 
do_build do_populate_lic do_compile
  prelink-native: do_compile do_populate_lic do_configure do_fetch do_build 
do_install do_unpack do_patch do_populate_sysroot
  packagegroup-core-ssh-openssh: do_populate_sysroot do_packagedata 
do_package_write_rpm do_package_qa do_build do_compile do_install 
do_populate_lic do_package do_configure
  dbus-glib-native: do_unpack do_populate_sysroot do_populate_lic do_compile 
do_install do_patch do_build do_configure
  libpthread-stubs-native: do_build do_configure do_compile do_unpack 
do_populate_sysroot do_populate_lic do_patch do_install
  xcb-proto-native: do_install do_populate_sysroot do_build do_comp

Re: [yocto] Strange build dependency

[Gary Thomas]

On 03/14/2016 01:46 PM, Burton, Ross wrote:


On 14 March 2016 at 12:41, Gary Thomas mailto:g...@mlbassoc.com>> wrote:

How can I find out what's going on here?


bitbake-whatchanged is generally helpful here.  Do a build in one 
configuration, switch to the other, run
bitbake-whatchanged.  It will identify the hashes that have changed and try and 
chase them down.

That said perl is quite a deep recipe so rebuilding that will certainly bubble 
up the tree causing all sorts of rebuilds.


Thanks, I'll give this a try.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] New message

[Burton, Ross]

On 14 March 2016 at 03:10, Gary Thomas  wrote:

> I just started a new build and saw a message that's new to me:
>   NOTE: Fetching uninative binary shim from
> http://downloads.yoctoproject.org/releases/uninative/0.95/x86_64-nativesdk-libc.tar.bz2;md5sum=4b6fb2106c2f18b8f9c8ac67e1cf9e57
>
> * What is this about?
>

You're using the poky distribution which for build performance uses
uninative (from 477b8fb), which means that instead of building native
dependencies per-host-distribution there's a static libc which is built
against to enable native binaries to be host-agnostic.

Poky has enabled this for performance, but others may wish to do the same
for other reasons: for example, you want to publish a sstate feed that
works for all host distributions without having to build for all of them.

* Can this file be served by my local mirror?
>

It can (see meta/conf/distro/include/yocto-uninative.inc), or you can
uninherit uninative, or use your own DISTRO instead of poky.

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

Re: [yocto] Strange build dependency

[Burton, Ross]

On 14 March 2016 at 12:41, Gary Thomas  wrote:

> How can I find out what's going on here?
>

bitbake-whatchanged is generally helpful here.  Do a build in one
configuration, switch to the other, run bitbake-whatchanged.  It will
identify the hashes that have changed and try and chase them down.

That said perl is quite a deep recipe so rebuilding that will certainly
bubble up the tree causing all sorts of rebuilds.

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

[yocto] Strange build dependency

[Gary Thomas]

I'm trying to sort out a problem with perl and have been switching
between two different versions.  What I don't understand is why
so many recipes are being rebuilt when I change.  I tried examining
the dependencies with -g -u depexp but I'm unable to see why it's
happening.

I'm building core-image-base (+perl) from a recent Poky checkout.
I notice that a number of packages that don't seem to be related
to perl (or even hardly to each other) are rebuilt, e.g. avahi,
openssl and others.

How can I find out what's going on here?

BTW, I'm using this [testing] layer for this effort (related to
my perl question from last week):
  https://github.com/GaryThomas/meta-amanda.git

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] [meta-selinux][PATCH] net-tools: Rebase netstat-selinux-support.patch

[Adrian Dudau]

Signed-off-by: Adrian Dudau 
---
 .../net-tools/netstat-selinux-support.patch| 55 +++---
 1 file changed, 28 insertions(+), 27 deletions(-)

diff --git a/recipes-extended/net-tools/net-tools/netstat-selinux-support.patch 
b/recipes-extended/net-tools/net-tools/netstat-selinux-support.patch
index 2a97216..f089041 100644
--- a/recipes-extended/net-tools/net-tools/netstat-selinux-support.patch
+++ b/recipes-extended/net-tools/net-tools/netstat-selinux-support.patch
@@ -5,13 +5,14 @@ Subject: [PATCH] net-tools: netstat add SELinux support.
 Upstream-Status: Inappropriate [configuration]
 
 Signed-off-by: Xin Ouyang 
+Signed-off-by: Adrian Dudau 
 ---
- Makefile  |9 +++-
- netstat.c |   69 ++--
+ Makefile  |  9 -
+ netstat.c | 69 ---
  2 files changed, 74 insertions(+), 4 deletions(-)
 
 diff --git a/Makefile b/Makefile
-index 8fcc55c..dca8fbc 100644
+index 8fcc55c..0b5c395 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -116,6 +116,13 @@ NET_LIB = $(NET_LIB_PATH)/lib$(NET_LIB_NAME).a
@@ -38,12 +39,12 @@ index 8fcc55c..dca8fbc 100644
  iptunnel: $(NET_LIB) iptunnel.o
$(CC) $(LDFLAGS) -o iptunnel iptunnel.o $(NLIB) $(RESLIB)
 diff --git a/netstat.c b/netstat.c
-index c3a7bb1..71be41f 100644
+index fc10414..a773e81 100644
 --- a/netstat.c
 +++ b/netstat.c
-@@ -86,6 +86,12 @@
- #include 
- #include 
+@@ -90,6 +90,12 @@
+ #include 
+ #include 
  
 +#if HAVE_SELINUX
 +#include 
@@ -54,7 +55,7 @@ index c3a7bb1..71be41f 100644
  #include "net-support.h"
  #include "pathnames.h"
  #include "version.h"
-@@ -97,6 +103,7 @@
+@@ -101,6 +107,7 @@
  #include "proc.h"
  
  #define PROGNAME_WIDTH 20
@@ -62,7 +63,7 @@ index c3a7bb1..71be41f 100644
  
  #if !defined(s6_addr32) && defined(in6a_words)
  #define s6_addr32 in6a_words  /* libinet6 */
-@@ -153,6 +160,7 @@ int flag_wide= 0;
+@@ -180,6 +187,7 @@ int flag_wide= 0;
  int flag_prg = 0;
  int flag_arg = 0;
  int flag_ver = 0;
@@ -70,7 +71,7 @@ index c3a7bb1..71be41f 100644
  
  FILE *procinfo;
  
-@@ -216,12 +224,17 @@ FILE *procinfo;
+@@ -243,12 +251,17 @@ FILE *procinfo;
  #define PROGNAME_WIDTH1(s) PROGNAME_WIDTH2(s)
  #define PROGNAME_WIDTH2(s) #s
  
@@ -88,7 +89,7 @@ index c3a7bb1..71be41f 100644
  } *prg_hash[PRG_HASH_SIZE];
  
  static char prg_cache_loaded = 0;
-@@ -229,9 +242,12 @@ static char prg_cache_loaded = 0;
+@@ -256,9 +269,12 @@ static char prg_cache_loaded = 0;
  #define PRG_HASHIT(x) ((x) % PRG_HASH_SIZE)
  
  #define PROGNAME_BANNER "PID/Program name"
@@ -101,7 +102,7 @@ index c3a7bb1..71be41f 100644
  #define PRG_LOCAL_ADDRESS "local_address"
  #define PRG_INODE  "inode"
  #define PRG_SOCKET_PFX"socket:["
-@@ -253,7 +269,7 @@ static char prg_cache_loaded = 0;
+@@ -280,7 +296,7 @@ static char prg_cache_loaded = 0;
  /* NOT working as of glibc-2.0.7: */
  #undef  DIRENT_HAVE_D_TYPE_WORKS
  
@@ -110,7 +111,7 @@ index c3a7bb1..71be41f 100644
  {
  unsigned hi = PRG_HASHIT(inode);
  struct prg_node **pnp,*pn;
-@@ -274,6 +290,14 @@ static void prg_cache_add(unsigned long inode, char *name)
+@@ -301,6 +317,14 @@ static void prg_cache_add(unsigned long inode, char *name)
  if (strlen(name)>sizeof(pn->name)-1) 
name[sizeof(pn->name)-1]='\0';
  strcpy(pn->name,name);
@@ -125,7 +126,7 @@ index c3a7bb1..71be41f 100644
  }
  
  static const char *prg_cache_get(unsigned long inode)
-@@ -286,6 +310,16 @@ static const char *prg_cache_get(unsigned long inode)
+@@ -313,6 +337,16 @@ static const char *prg_cache_get(unsigned long inode)
  return("-");
  }
  
@@ -142,7 +143,7 @@ index c3a7bb1..71be41f 100644
  static void prg_cache_clear(void)
  {
  struct prg_node **pnp,*pn;
-@@ -357,6 +391,7 @@ static void prg_cache_load(void)
+@@ -384,6 +418,7 @@ static void prg_cache_load(void)
  const char *cs,*cmdlp;
  DIR *dirproc=NULL,*dirfd=NULL;
  struct dirent *direproc,*direfd;
@@ -150,7 +151,7 @@ index c3a7bb1..71be41f 100644
  
  if (prg_cache_loaded || !flag_prg) return;
  prg_cache_loaded=1;
-@@ -426,7 +461,15 @@ static void prg_cache_load(void)
+@@ -453,7 +488,15 @@ static void prg_cache_load(void)
}
  
snprintf(finbuf, sizeof(finbuf), "%s/%s", direproc->d_name, cmdlp);
@@ -167,7 +168,7 @@ index c3a7bb1..71be41f 100644
}
closedir(dirfd); 
dirfd = NULL;
-@@ -546,6 +589,8 @@ static void finish_this_one(int uid, unsigned long inode, 
const char *timers)
+@@ -573,6 +616,8 @@ static void finish_this_one(int uid, unsigned long inode, 
const char *timers)
  }
  if (flag_prg)
printf(" %-16s",prg_cache_get(inode));
@@ -176,7 +177,7 @@ index c3a7bb1..71be41f 100644
  if (flag_opt)
printf(" %s", timers);
  putchar('\n');
-@@ -1238,6 +1283,8 @@ static void unix_do_one(int nr, const char *line)
+@@ -1566,6 +1611,8 @@ static void unix_do_one(int nr, const char *l